Soms is het handig om één fysiek netwerk (zoals een Ethernet-segment) in twee gescheiden netwerksegmenten te verdelen zonder de noodzaak om een IP-subnet aan te maken en een router te gebruiken om de segmenten met elkaar te verbinden. Een apparaat dat twee netwerken op deze manier met elkaar verbindt wordt een “bridge (brug)” genoemd. Een FreeBSD-systeem met twee netwerkkaarten kan als bridge dienen.
De bridge werkt door de adressen van de MAC-laag (Ethernetadressen) van de apparaten op elke netwerkinterface te leren. Het stuurt alleen verkeer tussen twee netwerken door indien de bron en het doel zich op verschillende netwerken bevinden.
In vele opzichten is een bridge als een Ethernet-switch met erg weinig poorten.
Er zijn vandaag de dag veel situaties waarin een bridge gebruikt wordt.
Het basisgebruik van een bridge is het met elkaar verbinden van twee of meer netwerksegmenten. Er zijn vele redenen om een hostgebaseerde bridge te gebruiken in plaats van simpele netwerkapparaten zoals kabelbeperkingen, firewalling of het verbinden van pseudonetwerken zoals een interface van een virtuële machine. Een bridge kan ook een draadloze interface die in hostap-modus draait met een bedraad netwerk verbinden en als een toegangspunt dienen.
Een gebruikelijke situatie dient zich voor wanneer de functionaliteit van een firewall nodig is zonder routing of network address translation (NAT).
Een voorbeeld is een klein bedrijf dat via DSL of ISDN met hun internetprovider verbonden is. Dit bedrijf heeft 13 wereldwijd bereikbare IP-adressen van de internetprovider en 10 PC's op hun netwerk. In deze situatie is een firewall die op een router gebaseerd is lastig wegens subnet-problemen.
Een firewall die op een bridge gebaseerd is kan ingesteld en net na de DSL- of ISDN-router geplaatst worden zonder dat er problemen met IP-nummers optreden.
Een bridge kan twee netwerksegmenten verbinden en kan gebruikt worden om alle Ethernetframes die tussen dezen voorbijkomen te inspecteren. Dit kan òfwel vanuit het gebruik van bpf(4)/tcpdump(1) op de bridge-interface òfwel door een kopie van alle frames naar een extra interface (overspanpoort) te versturen.
Twee Ethernetnetwerken kunnen over een IP-verbinding verbonden worden door de netwerken naar een EtherIP-tunnel te bridgen of met een oplossing gebaseerd po tap(4) zoals OpenVPN.
Een netwerk kan met meerdere verbindingen verbonden worden en het Spanning Tree Protocol gebruiken om overbodige paden te blokkeren. Een Ethernetnetwerk kan alleen juist functioneren indien er slechts één actief pad bestaat tussen twee apparaten, Spanning Tree zal lussen detecteren en de overbodige verbindingen in een geblokkeerde toestand zetten. Indien een van de actieve verbindingen faalt zal het protocol een andere boom berekenen en een van de geblokkeerde paden weer activeren om de verbindingen naar alle punten in het netwerk te herstellen.
Deze sectie behandelt de bridges geïmplementeerd met if_bridge(4), een stuurprogramma dat bridges met netgraph implementeert is ook beschikbaar, zie voor meer informatie de hulppagina ng_bridge(4).
Het bridge-stuurprogramma is een kernelmodule en zal
automatisch door ifconfig(8) worden geladen wanneer er een
bridge-interface wordt aangemaakt. Het is mogelijk om de bridge
in de kernel te compileren door
device if_bridge
aan het
kernelinstellingenbestand toe te voegen.
Pakketfiltering kan met elk firewall-pakket worden gebruikt dat via het raamwerk pfil(9) aankoppelt. De firewall kan als een module worden geladen of in de kernel worden gecompileerd.
De bridge kan als met altq(4) of dummynet(4) als een verkeersregelaar worden gebruikt.
De bridge wordt aangemaakt door interfaces te klonen. Om een bridge aan te maken wordt ifconfig(8) gebruikt, indien het bridge-stuurprogramma niet in de kernel aanwezig is zal het automatisch worden geladen.
#
ifconfig bridge create
#
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 0
Een bridge-interface is aangemaakt en er is automatisch een
random gegenereerd Ethernetadres aan toegekend. De parameters
maxaddr
en timeout
bepalen
hoeveel MAC-adressen de bridge in de doorstuurtabel houdt en
hoeveel seconden voordat elke regel wordt verwijderd nadat het
voor het laatst gezien is. De andere parameters bepalen hoe
Spanning Tree werkt.
Voeg de netwerkinterfaces die lid zijn aan de bridge toe. Om de bridge pakketten te laten doorsturen dienen alle lidinterfaces en de bridge actief te zijn:
#
ifconfig bridge0 addm fxp0 addm fxp1 up
#
ifconfig fxp0 up
#
ifconfig fxp1 up
De bridge stuurt nu Ethernet-frames door tussen
fxp0
en fxp1
.
De overeenkomstige configuratie in
/etc/rc.conf
zodat de bridge tijdens het
opstarten wordt aangemaakt is:
cloned_interfaces="bridge0" ifconfig_bridge0="addm fxp0 addm fxp1 up" ifconfig_fxp0="up" ifconfig_fxp1="up"
Indien de bridge-gastheer een IP-adres nodig heeft dan is de juiste plaats om dit in te stellen op de bridge-interface zelf in plaats van op een van de lidinterfaces. Dit kan statisch of via DHCP worden ingesteld:
#
ifconfig bridge0 inet 192.168.0.1/24
Het is ook mogelijk om een IPv6-adres aan een bridge-interface toe te kennen.
Wanneer pakketten worden gefilterd, zullen gebridgede pakketten het filter inbound op de vertrekkende interface passeren, op de bridge-interface en outbound op de bestemde interface. Elke stap kan uitgezet worden. Wanneer de richting van het pakketverkeer belangrijk is, kan de firewall het beste op de lidinterfaces draaien en niet op de bridge zelf.
De bridge heeft verschillende aanpasbare instellingen voor het doorlaten van non-IP- en ARP-pakketten, en een laag 2 firewall met IPFW. Zie if_bridge(4) voor meer informatie.
Het bridge-stuurprogramma implementeert het Rapid Spanning Tree Protocol (RSTP of 802.1w) met terugwaartse compatibiliteit met het verouderde Spanning Tree Protocol (STP). Spanning Tree wordt gebruikt om lussen in een netwerktopologie te detecteren en verwijderen. RSTP biedt snellere convergentie naar een opspannende boom dan het verouderde STP, het protocol wisselt informatie met naburige switches uit om snel naar forwarding over te gaan zonder lussen te creëren. FreeBSD ondersteunt RSTP en STP als opties, waarbij RSTP de standaard is.
Spanning Tree kan op lidinterfaces worden geactiveerd met
het commando stp
. Voor een bridge met
fxp0
en fxp1
alle huidige interfaces, wordt STP met het volgende
geactiveerd:
#
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 forwarding
De bridge heeft spanning tree ID
00:01:02:4b:d4:50
en prioriteit
32768
. Aangezien het
root id
hetzelfde is geeft dit aan dat dit de
hoofdbridge voor de boom is.
Een andere bridge in het netwerk heeft spanning tree ook geactiveerd:
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 96:3d:4b:f1:79:7a id 00:13:d4:9a:06:7a 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 400000 port 4 member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 4 priority 128 path cost 200000 proto rstp role root state forwarding member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 5 priority 128 path cost 200000 proto rstp role designated state forwarding
De reegl root id 00:01:02:4b:d4:50 priority 32768
ifcost 400000 port 4
geeft aan dat de hoofdbridge
00:01:02:4b:d4:50
is zoals boven en dat de
padkosten 400000
zijn vanaf deze bridge, het
pad naar de hoofdbridge gaat via port 4
welke fxp0
is.
De bridge ondersteunt monitormodus, waarin de pakketten worden verwijderd nadat ze door bpf(4) zijn verwerkt, en ze niet verder verwerkt of doorgestuurd worden. Dit kan worden gebruikt om de invoer van twee of meer interfaces naar een enkele bpf(4)-stroom te multiplexen. Dit is nuttig voor het reconstrueren van het verkeer voor netwerktaps welke de RX/TX-signalen over twee verschillende interfaces uitzenden.
Om de invoer van vier netwerkinterfaces als één stroom te lezen:
#
ifconfig bridge0 addm fxp0 addmfxp1 addm fxp2 addm fxp3 monitor up
#
tcpdump -i bridge0
Van elk Ethernet-frame dat door de bridge wordt ontvangen wordt er een kopie naar de aangewezen SPAN-poort verstuurd. Het aantal geconfigureerde SPAN-poorten op een bridge is onbeperkt, indien een interface aangewezen is als SPAN-poort kan het niet ook als gewone bridgepoort gebruikt worden. Dit is het nuttigste voor het passief afluisteren van een gebridged netwerk op een andere host die met een van de SPAN-poorten van de bridge verbonden is.
Om een kopie van alle frames naar de interface
fxp4
te versturen:
#
ifconfig bridge0 span fxp4
Een privé-interface stuurt geen verkeer door naar poorten die niet ook een privé-interface zijn. Het verkeer wordt onvoorwaardelijk geblokkeerd, dus worden er geen Ethernetframes doorgestuurd, inclusief ARP. Indien verkeer selectief dient te worden geblokkeerd dient er in plaats hiervan een firewall gebruikt te worden.
Indien een lidinterface van een bridge als klevend is gemarkeerd worden dynamisch geleerde adresregels als statisch behandelt wanneer ze in de doorstuurcache komen. Klevende interfaces vallen nooit uit de cache en worden nooit vervangen, zelfs niet als het adres op een andere interface wordt gezien. Dit biedt het voordeel van statische adresregels zonder dat de doorstuurtabel van te voren gevuld hoeft te worden, cliënten die geleerd zijn op een bepaald segment van de bridge kunnen niet roamen naar een ander segment.
Een ander voorbeeld voor het gebruik van klevende adressen
zou het combineren van de bridge met VLANs zijn om een router
te creëren waar klantnetwerken geïsoleerd zijn
zonder dat IP-adresruimte verspild wordt. Neem aan dat
KlantA
op
vlan100
zit en KlantB
op
vlan101
. De bridge heeft het adres
192.168.0.1
en is tevens een
internet-router.
#
ifconfig bridge0 addm vlan100 sticky vlan100 addm vlan101 sticky vlan101
#
ifconfig bridge0 inet 192.168.0.1/24
Beide cliënten zien 192.168.0.1
als hun standaard gateway
en aangezien de bridge-cache kleverig is kunnen ze niet het
MAC-adres van de andere klant spoofen om hun verkeer op te
vangen.
Alle communicatie tussen de VLANs kan geblokkeerd worden door het gebruik van privé-interfaces (of een firewall):
#
ifconfig bridge0 private vlan100 private vlan101
De klanten zijn compleet geïsoleerd van elkaar, het
volledige /24
adresruimte kan
zonder subnetten toegewezen worden.
Het aantal unieke bron-MAC-adressen achter een interface kan beperkt zijn. Wanneer de limiet bereikt is worden pakketten met een onbekend bronadres gedropt totdat een bestaande ingang in de host-cache vervalt of wordt verwijderd.
Het volgende voorbeeld stelt het maximum aantal
Ethernetapparaten voor KlantA
op
vlan100
in op 10.
#
ifconfig bridge0 ifmaxaddr vlan100 10
De bridge-interface en STP-parameters kunnen gemonitord worden via het SNMP-daemon dat met het basis FreeBSD-systeem wordt meegeleverd. De geëxporteerde bridge-MIBs houden zich aan de standaarden van de IETF zodat elke SNMP-cliënt of monitorpakket kan worden gebruikt om de gegevens te verzamelen.
Op de bridge-machine dient de regel
begemotSnmpdModulePath."bridge" =
"/usr/lib/snmp_bridge.so"
van
/etc/snmp.config
geactiveerd te worden en
het daemon bsnmpd gestart te worden.
Andere instellingen zoals gemeenschapsnamen en toegangslijsten
dienen eventueel aangepast te worden. Zie bsnmpd(1) en
snmp_bridge(3) voor meer informatie.
Het volgende voorbeeld gebruikt de software
Net-SNMP (net-mgmt/net-snmp om een bridge te
ondervragen, de port net-mgmt/bsnmptools kan ook worden
gebruikt. Voeg de volgende regels toe aan
$HOME/.snmp/snmp.conf
op de
SNMP-cliënt-host om de MIB-definities van de bridge in
Net-SNMP te importeren:
mibdirs +/usr/share/snmp/mibs mibs +BRIDGE-MIB:RSTP-MIB:BEGEMOT-MIB:BEGEMOT-BRIDGE-MIB
Om een enkele bridge via de IETF BRIDGE-MIB (RFC4188) te monitoren:
%
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)
De waarde dot1dStpTopChanges.0
is twee
wat betekent dat de topologie van de STP-bridge twee maal
veranderd is, een topologieverandering houdt in dat
één of meerdere links in het netwerk zijn
veranderd of hebben gefaald en dat er een nieuwe boom is
berekend. De waarde
dot1dStpTimeSinceTopologyChange.0
laat zien
wanneer dit gebeurde.
Om meerdere bridge-interfaces te monitoren kan men het privé BEGEMOT-BRIDGE-MIB gebruiken:
%
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 A9
Om de bridge-interface die via de subboom
mib-2.dot1dBridge
wordt gemonitord te
veranderen:
%
snmpset -v 2c -c private bridge1.example.com
BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.