Manchmal ist es nützlich, ein physikalisches Netzwerk (wie ein Ethernetsegment) in zwei separate Netzwerke aufzuteilen, ohne gleich IP-Subnetze zu erzeugen, die über einen Router miteinander verbunden sind. Ein Gerät, das zwei Netze auf diese Weise verbindet, wird als Bridge bezeichnet. Jedes FreeBSD-System mit zwei Netzwerkkarten kann als Bridge fungieren.
Die Bridge arbeitet, indem sie die MAC Layeradressen (Ethernet Adressen) der Geräte in ihren Netzwerksegmenten lernt. Der Verkehr wird nur dann zwischen zwei Segmenten weitergeleitet, wenn sich Sender und Empfänger in verschiedenen Netzwerksegmenten befinden.
In vielerlei Hinsicht entspricht eine Bridge daher einem Ethernet-Switch mit sehr wenigen Ports.
Es gibt zahlreiche Situationen, in denen der Einsatz einer Bridge sinnvoll ist:
Die Hauptaufgabe einer Bridge ist die Verbindung von zwei oder mehreren Netzwerksegmenten zu einem gemeinsamen Netzwerk. Es ist oft sinnvoller, eine hostbasierte Bridge anstelle normaler Netzwerkkomponenten (wie Kabelverbindungen), Firewalls oder Pseudonetzwerken über die Schnittstelle einer virtuellen Maschine einzusetzen. Eine Bridge kann außerdem ein drahtloses Gerät mit einem Kabelnetzwerk verbinden. Diese Fähigkeit der Bridge wird als HostAP-Modus bezeichnet. Die Bridge agiert in diesem Fall als Access Point für das drahtlose Gerät.
Häufig kommt es vor, dass Firewallfunktionen benötigt werden, ohne dass Routing oder Network Adress Translation (NAT) verwendet werden soll.
Ein Beispiel dafür wäre ein kleines Unternehmen, das über DSL oder ISDN an seinen ISP angebunden ist. Es verfügt über 13 weltweit erreichbare IP-Adressen, sein Netzwerk besteht aus 10 Rechnern. In dieser Situation ist der Einsatz von Subnetzen sowie einer routerbasierten Firewall schwierig.
Eine brigdebasierte Firewall kann konfiguriert und in den ISDN/DSL-Downstreampfad ihres Routers eingebunden werden, ohne dass Sie sich um IP-Adressen kümmern müssen.
Eine Bridge kann zwei Netzwerksegmente miteinander verbinden und danach alle Ethernet-Rahmen überprüfen, die zwischen den beiden Netzwerksegmenten ausgetauscht werden. Dazu verwendet man entweder bpf(4)/tcpdump(1) auf dem Netzgerät der Bridge oder schickt Kopien aller Rahmen an ein zusätzliches Netzgerät (den sogenannten Span Port).
Zwei Ethernetnetzwerke können über einen IP-Link miteinander verbunden werden, indem Sie die beiden Netzwerke über einen EtherIP-Tunnel koppeln oder eine tap(4)-basierte Lösung wie OpenVPN einsetzen.
Die Systeme eines Netzwerks können redundant miteinander verbunden sein. In diesem Fall verwenden Sie das Spanning Tree Protocol, um redundante Pfade zu blockieren. Damit ein Ethernetnetzwerk korrekt arbeitet, darf immer nur ein aktiver Pfad zwischen zwei Geräten des Netzwerks existieren. Aufgabe des Spanning Tree Protocols ist es daher, Schleifen zu entdecken und redundante Links in den Status blockiert zu versetzen. Fällt ein aktiver Link aus, so berechnet das Protokoll einen neuen Pfad. Dazu wird ein blockierter Pfad in den Status aktiv versetzt, damit alle Systeme des Netzwerks wieder miteinander kommunizieren können.
Dieser Abschnitt beschreibt nur die if_bridge(4)-Bridge-Implementierung. Ein Netgraph-Bridge-Treiber ist ebenfalls verfügbar, wird hier aber nicht behandelt. Lesen Sie die Manualpage ng_bridge(4), wenn Sie diesen Treiber einsetzen wollen.
Bei diesem Treiber handelt es sich um ein
Kernelmodul, das von ifconfig(8) automatisch geladen
wird, wenn ein Bridge-Interface erzeugt wird. Alternativ ist
es aber auch möglich, die Unterstützung für
den Treiber in Ihren Kernel zu kompilieren. Dazu fügen
Sie die Zeile device if_bridge
in Ihre
Kernelkonfigurationsdatei ein und bauen danach den Kernel
neu.
Paketfilter können mit allen Firewallpaketen verwendet werden, die das pfil(9)-Framework benutzen. Die Firewall kann dabei entweder als Kernelmodul geladen oder in den Kernel kompiliert werden.
Eine Bridge kann auch als Traffic Shaper verwendet werden, wenn Sie altq(4) oder dummynet(4) einsetzen.
Eine Bridge wird durch das Klonen von Schnittstellen erzeugt. Um eine Bridge zu erzeugen, verwenden Sie den Befehl ifconfig(8). Ist der Bridge-Treiber nicht in Ihren Kernel kompiliert, wird er automatisch geladen.
#
ifconfig bridge create
bridge0
#
ifconfig bridge0
bridge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 96:3d:4b:f1:79:7a
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0Im obigen Beispiel wird die Bridge erzeugt und erhält
automatisch eine zufällig generierte Ethernet-Adresse
zugewiesen. Die Parameter maxaddr
sowie
timeout
legen fest, wie viele MAC-Adressen
die Bridge in ihrer Forward-Tabelle halten kann beziehungsweise
wie viele Sekunden jeder Eintrag erhalten bleiben soll, nachdem
er zuletzt verwendet wurde. Die restlichen Parameter sind
für die Konfiguration von Spanning Tree notwendig.
Im nächsten Schritt werden die Schnittstellen, die die Bridge verbinden soll, zugewiesen. Damit die Bridge Datenpakete weiterleiten kann, müssen sowohl die Bridge als auch die Schnittstellen (der zu verbindenden Netzwerksegmente) aktiviert sein:
#
ifconfig bridge0 addm fxp0 addm fxp1 up
#
ifconfig fxp0 up
#
ifconfig fxp1 up
Danach ist die Bridge in der Lage, Ethernet-Rahmen zwischen
den Schnittstellen fxp0
und
fxp1
weiterzuleiten. Um diese
Konfiguration beim Systemstart automatisch zu aktivieren,
müssen Sie folgende Einträge in die Datei
/etc/rc.conf
aufnehmen:
Benötigen Sie für die Bridge eine IP-Adresse, müssen Sie diese der Schnittstelle der Bridge zuweisen (und nicht einer der Schnittstellen der gekoppelten Netzwerksegmente). Dabei können Sie die IP-Adresse sowohl statisch als auch dynamisch über DHCP zuweisen:
#
ifconfig bridge0 inet 192.168.0.1/24
Sie können der Bridge-Schnittstelle auch eine IPv6-Adresse zuweisen.
Nachdem ein Paketfilter aktiviert wurde, können Datenpakete, die von den Schnittstellen der gekoppelten Netzwerksegmente gesendet und empfangen werden, über die Bridge weitergeleitet oder nach bestimmten Regeln gefiltert oder auch komplett geblockt werden. Ist die Richtung des Paketflusses wichtig, ist es am besten, eine Firewall auf den Schnittstellen der einzelnen Netzwerksegmente einzurichten und nicht auf der Bridge selbst.
Eine Bridge verfügt über verschiedene Optionen, über die Sie die Weiterleitung von Nicht-IP- und ARP-Paketen sowie den Einsatz von Layer 2-Firewalls (mit IPFW) steuern können. Lesen Sie die Manualpage if_bridge(4), wenn Sie diese Funktionen benötigen.
Der Bridge-Treiber implementiert das Rapid Spanning Tree Protocol (RSTP oder 802.1w), das abwärtskompatibel zum veralteten Spanning Tree Protocol (STP) ist. Spanning Tree dient dazu, Schleifen in einer Netzwerktopologie zu entdecken und zu entfernen. RSTP arbeitet dabei schneller als das veraltete STP. RSTP tauscht Informationen mit benachbarten Switchen aus, um Pakete korrekt weiterzuleiten und eine Schleifenbildung zu verhindern.
FreeBSD unterstützt die Betriebsmode RSTP sowie STP, von denen RSTP als Standardmodus voreingestellt ist.
Spanning Tree kann auf den Schnittstellen der
durch die Bridge verbundenen Netzwerksegmente über die
Option stp
aktiviert werden. Für eine
Bridge, die die Schnittstellen fxp0
und
fxp1
verbindet, aktivieren Sie STP wie
folgt:
#
ifconfig bridge0 stp fxp0 stp fxp1
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether d6:cf:d5:a0:94:6d
id 00:01:02:4b:d4:50 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:01:02:4b:d4:50 priority 32768 ifcost 0 port 0
member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
port 3 priority 128 path cost 200000 proto rstp
role designated state forwarding
member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
port 4 priority 128 path cost 200000 proto rstp
role designated state forwardingDiese Bridge hat die Spanning-Tree-ID
00:01:02:4b:d4:50
und die Priorität
32768
. Da diese ID mit der
Root-ID
identisch ist, handelt es sich um die
Root-Bridge dieses Netzwerks.
Auf einer anderen Bridge des Netzwerks ist Spanning Tree ebenfalls aktiviert:
Die Zeile root id 00:01:02:4b:d4:50 priority 32768
ifcost 400000 port 4
zeigt an, dass die Root-Bridge wie
im obigen Beispiel die ID 00:01:02:4b:d4:50
hat. Die Pfadkosten hin zur Root-Bridge betragen
400000
, wobei der Pfad zur Root-Bridge
über Port 4
geht (der wiederum
der Schnittstelle fxp0
entspricht).
Die Bridge unterstützt den Monitormodus. Dabei werden alle Pakete verworfen, nachdem sie von bpf(4) verarbeitet wurden. In diesem Modus erfolgt keine weitere Bearbeitung und auch keine Weiterleitung von Datenpaketen. Es ist daher möglich, die Eingabe von zwei oder mehr Netzwerkschnittstellen in einen einzigen gemeinsamen bpf(4)-Stream zu vereinen. Ein solcher Datenstrom ist beispielsweise nützlich, um den Datenverkehr für ""network taps"" zu rekonstruieren, die ihre RX/TX-Signale über verschiedene Schnittstellen senden.
Um die Eingabe von vier Netzwerkschnittstellen in einzigen gemeinsamen Datenstrom zu vereinen, geben Sie Folgendes ein:
#
ifconfig bridge0 addm fxp0 addm fxp1 addm fxp2 addm fxp3 monitor up
#
tcpdump -i bridge0
Eine Kopie jedes Ethernet-Rahmens, der an der Bridge ankommt, wird über einen festgelegten Span Port verschickt. Auf einer Bridge können beliebig viele Span Ports festgelegt werden. Wird eine Schnittstelle als Span Port konfiguriert, kann sie nicht mehr als normaler Bridge-Port verwendet werden. Eine derartige Konfiguration ist beispielsweise sinnvoll, um den Datenverkehr, der in einem Netzwerk über die Bridge läuft, auf einen Rechner zu übertragen, der mit einem Span Port der Bridge verbunden ist.
Um eine Kopie aller Ethernet-Rahmen über die
Schnittstelle fxp4
zu verschicken,
geben Sie Folgendes ein:
#
ifconfig bridge0 span fxp4
Eine private Schnittstelle leitet keine Daten an einen Port weiter, bei dem es sich ebenfalls um eine private Schnittstelle handelt. Der Datenverkehr wird dabei komplett blockiert, auch Ethernet-Rahmen und ARP-Pakete werden nicht weitergeleitet. Wollen Sie hingegen nur spezifische Datenpakete blockieren, sollten Sie eine Firewall einsetzen.
Wenn die Schnittstelle eines über eine Bridge verbundenen Netzwerksegments als sticky gekennzeichnet wird, werden alle dynamisch gelernten Adressen als statische Adressen behandelt, sobald sie in den Forward-Cache der Bridge aufgenommen wurden. Sticky-Einträge werden niemals aus dem Cache entfernt oder ersetzt. Selbst dann nicht, wenn die Adresse von einer anderen Schnittstelle verwendet wird. Sie können dadurch die Vorteile statischer Adresseinträge nutzen, ohne die Forward-Tabelle vor dem Einsatz der Bridge mit statischen Einträgen füllen zu müssen. Clients, die sich in einem bestimmten von der Bridge verwalteten Segmente befinden, können dabei nicht in ein anderes Segment wechseln.
Ein weiteres Beispiel für den Einsatz von
Sticky-Adressen wäre die Kombination einer Bridge mit
mehreren VLANs, um einen Router zu konfigurieren, der in
in der Lage ist, einzelne Kundennetzwerke voneinander zu
trennen, ohne IP-Adressbereiche zu verschwenden. Für das
folgende Beispiel nehmen wir an, dass sich der Client
CustomerA
im VLAN
vlan100
und der Client
CustomerB
im VLAN
vlan101
befinden. Die Bridge hat die
IP-Adresse 192.168.0.1
und ist
als Internet-Router konfiguriert.
#
ifconfig bridge0 addm vlan100 sticky vlan100 addm vlan101 sticky vlan101
#
ifconfig bridge0 inet 192.168.0.1/24
Beide Clients sehen 192.168.0.1
als Ihr Default-Gateway.
Da der Brücken-Cache sticky ist,
sind Sie nicht dazu in der Lage, die MAC-Adresse des
anderen Kunden zu spoofen und dessen Datenverkehr
abzufangen.
Sie können die Kommunikation zwischen den VLANs vollständig unterbinden, wenn Sie private Schnittstellen (oder eine Firewall) einsetzen:
#
ifconfig bridge0 private vlan100 private vlan101
Die Kunden sind nun komplett voneinander isoliert und
der komplette /24
-Adressbereich
kann zugewiesen werden, ohne dass Sie Subnetze einsetzen
müssen.
Die maximale mögliche Anzahl an eindeutigen MAC-Adressen hinter einer Schnittstelle kann festgelegt werden. Sobald das Limit erreicht ist, werden Pakete mit einer unbekannten Quell-Adresse solange verworfen, bis ein exisitierender Eintrag gelöscht wird oder abläuft.
Das folgende Beispiel setzt die maximale Anzahl von
Netzgeräten für
CustomerA
für
das VLAN vlan100
auf 10.
#
ifconfig bridge0 ifmaxaddr vlan100 10
Die Schnittstelle der Bridge sowie die STP-Parameter können durch den bereits im Basissystem enthaltenen SNMP-Daemon überwacht werden. Die exportierten Bridge-MIBs entsprechen den IETF-Standards, daher können Sie einen beliebigen SNMP-Client oder ein beliebiges Monitoring-Werkzeug einsetzen, um die benötigten Daten zu erhalten.
Auf dem Rechner, auf dem die Bridge konfiguriert ist,
aktivieren Sie die Zeile
begemotSnmpdModulePath."bridge" = "/usr/lib/snmp_bridge.so"
in der Datei /etc/snmp.config
und starten
danach den bsnmpd-Daemon.
Eventuell benötigen Sie noch weitere
Konfigurationsparameter wie Community-Namen und
Zugriffslisten. Die Konfiguration dieser Parameter wird
in den Manualpages bsnmpd(1) sowie snmp_bridge(3)
beschrieben.
Die folgenden Beispiele verwenden das Softwarepaket
Net-SNMP (net-mgmt/net-snmp
), um die Bridge
abzufragen. Alternativ können Sie dafür auch den
Port net-mgmt/bsnmptools
einsetzen. Auf dem SNMP-Client fügen Sie danach die
folgenden Zeilen in die Datei
$HOME/.snmp/snmp.conf
ein, um die
MIB-Definitionen der Bridge in
Net-SNMP zu importieren:
Um eine einzelne Bridge über den IETF BRIDGE-MIB (RFC4188) zu überwachen, geben Sie Folgendes ein:
%
snmpwalk -v 2c -c public bridge1.example.com mib-2.dot1dBridge
BRIDGE-MIB::dot1dBaseBridgeAddress.0 = STRING: 66:fb:9b:6e:5c:44
BRIDGE-MIB::dot1dBaseNumPorts.0 = INTEGER: 1 ports
BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (189959) 0:31:39.59 centi-seconds
BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 2
BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 80 00 00 01 02 4B D4 50
...
BRIDGE-MIB::dot1dStpPortState.3 = INTEGER: forwarding(5)
BRIDGE-MIB::dot1dStpPortEnable.3 = INTEGER: enabled(1)
BRIDGE-MIB::dot1dStpPortPathCost.3 = INTEGER: 200000
BRIDGE-MIB::dot1dStpPortDesignatedRoot.3 = Hex-STRING: 80 00 00 01 02 4B D4 50
BRIDGE-MIB::dot1dStpPortDesignatedCost.3 = INTEGER: 0
BRIDGE-MIB::dot1dStpPortDesignatedBridge.3 = Hex-STRING: 80 00 00 01 02 4B D4 50
BRIDGE-MIB::dot1dStpPortDesignatedPort.3 = Hex-STRING: 03 80
BRIDGE-MIB::dot1dStpPortForwardTransitions.3 = Counter32: 1
RSTP-MIB::dot1dStpVersion.0 = INTEGER: rstp(2)Der Wert der Variable
dot1dStpTopChanges.0
ist hier 2, die
STP-Topologie der Bridge wurde also bereits zweimal
geändert. Unter einer Änderung versteht man dabei
die Anpassung eines oder mehrerer Links und die Kalkulation
eines neuen Baums. Der Wert der Variable
dot1dStpTimeSinceTopologyChange.0
gibt an,
wann dies zuletzt geschah.
Um mehrere Bridge-Schnittstellen zu überwachen, können Sie den privaten BEGEMOT-BRIDGE-MIB einsetzen:
%
snmpwalk -v 2c -c public bridge1.example.com
enterprises.fokus.begemot.begemotBridge
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge0" = STRING: bridge0
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge2" = STRING: bridge2
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge0" = STRING: e:ce:3b:5a:9e:13
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge2" = STRING: 12:5e:4d:74:d:fc
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge0" = INTEGER: 1
BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge2" = INTEGER: 1
...
BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge0" = Timeticks: (116927) 0:19:29.27 centi-seconds
BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge2" = Timeticks: (82773) 0:13:47.73 centi-seconds
BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge0" = Counter32: 1
BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge2" = Counter32: 1
BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge0" = Hex-STRING: 80 00 00 40 95 30 5E 31
BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge2" = Hex-STRING: 80 00 00 50 8B B8 C6 A9Um die über den
mib-2.dot1dBridge
-Subtree überwachte
Bridge-Schnittstelle zu ändern, geben Sie Folgendes
ein:
%
snmpset -v 2c -c private bridge1.example.com
BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.