Bridging en switching

Ethernet-achtige netwerken (Ethernet, Ethernet over IP, IEEE 802.11 in ap-bridge- of bridge-modus, WDS, VLAN) kunnen met MAC-bridges met elkaar verbonden worden. De bridge-functie maakt het mogelijk hosts die op afzonderlijke LAN's zijn aangesloten met elkaar te verbinden (met EoIP kunnen ook geografisch verspreide netwerken gebridged worden als er een IP-netwerkverbinding tussen bestaat) alsof ze op één enkel LAN zijn aangesloten. Omdat bridges transparant zijn, verschijnen ze niet in de traceroute-lijst en kan geen enkel hulpprogramma onderscheid maken tussen een host die in het ene LAN werkt en een host die in het andere LAN werkt wanneer deze LAN's gebridged zijn. Afhankelijk van de manier waarop de LAN's met elkaar verbonden zijn, kunnen de latency en de datasnelheid tussen hosts echter variëren.

In complexe topologieën kunnen (al dan niet bedoeld) netwerklussen ontstaan. Zonder speciale maatregelen zouden lussen het netwerk beletten normaal te functioneren, omdat ze tot lawineachtige pakketvermenigvuldiging leiden. Elke bridge voert een algoritme uit dat berekent hoe de lus kan worden voorkomen. (R/M)STP stelt bridges in staat met elkaar te communiceren, zodat ze een lusvrije topologie kunnen onderhandelen. Alle andere alternatieve verbindingen die anders een lus zouden vormen, worden in stand-by gezet, zodat een andere verbinding de plaats kan innemen mocht de hoofdverbinding uitvallen. Dit algoritme wisselt periodiek configuratieberichten uit (BPDU's - Bridge Protocol Data Unit), zodat alle bridges over de nieuwste informatie beschikken over wijzigingen in de netwerktopologie. (R/M)STP selecteert een root bridge, die verantwoordelijk is voor de netwerkherconfiguratie, zoals het blokkeren en openen van poorten op andere bridges. De root bridge is de bridge met de laagste bridge-ID.

Instellen van de bridge-interface

Om een aantal netwerken in één bridge te combineren, moet er een bridge-interface worden aangemaakt. Vervolgens moeten alle gewenste interfaces als poorten daarvan worden ingesteld. Standaard wordt het MAC-adres van de bridge automatisch gekozen, afhankelijk van de configuratie van de bridgepoorten. Om ongewenste wijzigingen van het MAC-adres te voorkomen, wordt aangeraden auto-mac uit te schakelen en het MAC-adres handmatig op te geven met admin-mac.

Submenu: /interface/bridge

Gevaar Het wijzigen van bepaalde eigenschappen kan ertoe leiden dat de bridge alle poorten tijdelijk uitschakelt. Hier moet rekening mee worden gehouden bij het wijzigen van zulke eigenschappen in productieomgevingen, aangezien alle pakketten tijdelijk verworpen kunnen worden. Tot zulke eigenschappen behoren vlan-filtering, protocol-mode, igmp-snooping, fast-forward en andere.

Example

Het volgende voorbeeld demonstreert hoe u een basis bridge-interface aanmaakt en verifieert voor eenvoudige Layer 2 switching. Deze configuratie maakt een bridge die meerdere Ethernet-poorten combineert tot één geschakeld netwerksegment.

[admin@MikroTik] > /interface/bridge/add
[admin@MikroTik] > interface bridge print 
Flags: X - disabled, R - running 
0 R name="bridge1" mtu=auto actual-mtu=1500 l2mtu=65535 arp=enabled arp-timeout=auto mac-address=5E:D2:42:95:56:7F protocol-mode=rstp fast-forward=yes 
igmp-snooping=no auto-mac=yes ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=no 
dhcp-snooping=no 

Bridge-monitoring

Gebruik het commando monitor om de huidige status van een bridge-interface te bewaken.

Submenu: /interface/bridge/monitor

[admin@MikroTik] /interface/bridge/monitor bridge1
                    state: enabled                         
      current-mac-address: 2C:C8:1B:FF:92:F4               
                bridge-id: 0x1000.2C:C8:1B:FF:92:F4        
              root-bridge: yes                             
           root-bridge-id: 0x1000.2C:C8:1B:FF:92:F4        
  regional-root-bridge-id: 0x1000.2C:C8:1B:FF:92:F4        
           root-path-cost: 0                               
                root-port: none                            
               port-count: 2                               
    designated-port-count: 2                               
        mst-config-digest: d2b171a8ad95f593c241fc33d419a88c
             fast-forward: no                              
         multicast-router: no                              
             igmp-querier: none                            
              mld-querier: none                            
        declared-vlan-ids: 1                               
      registered-vlan-ids: 1                               

Spanning Tree Protocol

RouterOS bridge-interfaces kunnen het Spanning Tree Protocol draaien om een lusvrije en redundante topologie te garanderen. Voor kleine netwerken met slechts 2 bridges levert STP niet veel voordelen op, maar voor grotere netwerken is een correct geconfigureerde STP zeer cruciaal; het op de standaardwaarden laten staan van STP-gerelateerde waarden kan resulteren in een volledig onbereikbaar netwerk, zelfs bij het uitvallen van één enkele bridge. Om een goede lusvrije en redundante topologie te bereiken, is het noodzakelijk de bridge-prioriteiten, port path costs en poortprioriteiten correct in te stellen.

Gevaar In RouterOS is het mogelijk om voor de bridge-prioriteit elke waarde tussen 0 en 65535 in te stellen, terwijl de IEEE 802.1W-standaard voorschrijft dat de bridge-prioriteit in stappen van 4096 moet gaan. Dit kan compatibiliteitsproblemen veroorzaken tussen apparaten die zulke waarden niet ondersteunen. Om compatibiliteitsproblemen te voorkomen wordt aangeraden alleen deze prioriteiten te gebruiken: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, 61440

STP kent meerdere varianten; momenteel ondersteunt RouterOS STP, RSTP en MSTP. Afhankelijk van de behoeften kan elk daarvan gebruikt worden; sommige apparaten kunnen enkele van deze protocollen uitvoeren met hardware offloading; gedetailleerde informatie over welke apparaten dit ondersteunen is te vinden in het gedeelte Hardware Offloading. STP wordt als verouderd en traag beschouwd; het is in vrijwel alle netwerktopologieën vervangen door RSTP, dat achterwaarts compatibel is met STP. Voor netwerktopologieën die afhankelijk zijn van VLAN's wordt aanbevolen MSTP te gebruiken, aangezien het een VLAN-bewust protocol is en de mogelijkheid biedt load balancing per VLAN-groep uit te voeren. Er zijn veel overwegingen die gemaakt moeten worden bij het ontwerpen van een netwerk met STP; meer gedetailleerde casestudy's zijn te vinden in het artikel Spanning Tree Protocol. In RouterOS bepaalt de eigenschap protocol-mode welke STP-variant gebruikt wordt.

Info De RouterOS-bridge werkt niet met PVST en varianten daarvan. De PVST-BPDU's (met MAC-bestemming 01:00:0C:CC:CC:CD) worden door RouterOS-bridges als gewone multicast-pakketten behandeld. Eenvoudig gezegd doorlopen ze de forwarding-logica van de RouterOS-bridge/switch en kunnen ze getagd of ongetagd worden.

Info Volgens de IEEE 802.1ad-standaard zijn de BPDU's van bridges die aan IEEE 802.1Q voldoen niet compatibel met IEEE 802.1ad-bridges. Dit betekent dat binnen één Layer2-domein op alle bridges hetzelfde bridge-VLAN-protocol moet worden gebruikt; anders werkt (R/M)STP niet goed.

STP per poort

Er kunnen bepaalde situaties zijn waarin u de STP-functionaliteit op een enkele poort of meerdere poorten wilt beperken. Hieronder vindt u voorbeelden voor verschillende use cases.

Gevaar Wees voorzichtig bij het wijzigen van de standaard (R/M)STP-functionaliteit; zorg ervoor dat u de werkingsprincipes van STP en BPDU's begrijpt. Een verkeerd geconfigureerde (R/M)STP kan onverwacht gedrag veroorzaken.

Maak edge-poorten aan

Edge-poorten worden gebruikt voor verbindingen met eindapparaten waaraan geen andere bridges zijn gekoppeld, zoals werkstations of routers. Door een bridge-poort als edge-poort in te stellen, wordt voorkomen dat de poort BPDU's (Bridge Protocol Data Units) verstuurt en negeert de poort alle ontvangen BPDU's. Hierdoor kan de poort direct naar de forwarding-status overgaan, waarbij de standaard STP learning- en listening-fasen worden overgeslagen, wat de convergentietijd van het netwerk verkort.

/interface/bridge
add name=bridge1
/interface/bridge/port
add bridge=bridge1 interface=ether1 edge=yes
add bridge=bridge1 interface=ether2

Ontvangen BPDU's verwerpen

De bridge firewall filter- en NAT-regels kunnen geen BPDU's verwerpen wanneer op de bridge STP/RSTP/MSTP is ingeschakeld, omdat BPDU's binnen de bridge een speciale verwerking krijgen. Het verwerpen van ontvangen BPDU's op een specifieke poort kan op sommige switchchips echter wel via ACL-regels worden gerealiseerd:

Op MikroTik-apparaten met een Marvell Prestera-switch:

/interface/ethernet/switch/rule
add dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF new-dst-ports="" port=ether1 switch=switch1

Op apparaten uit de CRS1xx/CRS2xx-serie met ondersteuning voor Access Control List (ACL):

/interface/ethernet/switch/acl
add action=drop mac-dst-address=01:80:C2:00:00:00 src-ports=ether1

Deze configuratie laat alle ontvangen BPDU's op ether1 vallen.

Gevaar Als u van plan bent ontvangen BPDU's op een poort te verwerpen, zorg er dan voor dat er ook geen BPDU's worden verzonden via de interface waarmee deze poort verbonden is. Een root bridge verzendt altijd BPDU's en wacht normaal gesproken op een superieure BPDU (van een bridge met een lagere bridge-ID). De bridge moet echter de nieuwe rootpoort tijdelijk uitschakelen bij de overgang van root bridge naar designated bridge. Als u BPDU's slechts aan één kant blokkeert, blijft de poort voortdurend tussen statussen heen en weer schakelen.

BPDU guard inschakelen

De BPDU Guard-functie biedt een extra beveiligingslaag voor bridge-poorten. Deze is bedoeld om potentiële netwerkproblemen te voorkomen door een poort te blokkeren als deze een BPDU (Bridge Protocol Data Unit) ontvangt, wat erop wijst dat er een ongeautoriseerd bridge-apparaat is aangesloten. Dit is met name nuttig voor edge-poorten die alleen op eindapparaten aangesloten zouden moeten zijn. Als in dit voorbeeld ether1 een BPDU ontvangt, wordt de poort automatisch geblokkeerd en is handmatig ingrijpen nodig om deze weer in te schakelen.

/interface/bridge
add name=bridge1
/interface/bridge/port
add bridge=bridge1 interface=ether1 bpdu-guard=yes
add bridge=bridge1 interface=ether2

Root Guard inschakelen

Root Guard is een spanning tree beveiligingsfunctie die voorkomt dat een poort de root-poort wordt, waardoor de actieve spanning tree topologie beschermd wordt tegen beïnvloeding door externe bridges. In dit voorbeeld is ether1 geconfigureerd met restricted-role=yes. Deze instelling voorkomt dat de poort de root-poort wordt voor de CIST of een MSTI, ongeacht de beste spanning tree prioriteitsvector. Zo'n poort wordt geselecteerd als Alternate Port (in discarding-status) en blijft in die status zolang hij superieure BPDU's blijft ontvangen. Hij gaat automatisch over naar de forwarding-status wanneer hij geen superieur root-pad meer detecteert. Netwerkbeheerders kunnen deze instelling inschakelen om zich te beschermen tegen externe bridges die de actieve spanning tree beïnvloeden.

/interface/bridge
add name=bridge1
/interface/bridge/port
add bridge=bridge1 interface=ether1 restricted-role=yes
add bridge=bridge1 interface=ether2
[admin@MikroTik] /interface/bridge/port/monitor [find]
                  interface: ether1                   ether2            
                     status: in-bridge                in-bridge          
                    port-id: 0x80.1                   0x80.2            
                       role: alternate-port           designated-port
                  edge-port: no                       yes           
        edge-port-discovery: yes                      yes            
        point-to-point-port: yes                      yes            
               external-fdb: no                       no             
               sending-rstp: yes                      yes            
                   learning: no                       yes            
                 forwarding: no                       yes            
           actual-path-cost: 2000                     2000           
    internal-root-path-cost: 2000                                    
       designated-bridge-id: 0x7000.64:D1:54:C7:3A:6E                
   designated-internal-cost: 0                        0              
         designated-port-id: 0x80.1                   0x80.2         
  designated-remaining-hops: 20                       20             
                 tx-rx-bpdu: 2/363                    4/1049         
        discard-transitions: 0                        0              
        forward-transitions: 0                        0              
                   tx-rx-tc: 0/2                      2/4            
           topology-changes: 0                        1              
       last-topology-change:                          34m53s         
           multicast-router: no                       yes            
           hw-offload-group: switch1                  switch1        
          declared-vlan-ids:                          
        registered-vlan-ids:                          

Bridge-instellingen

In het menu met bridge-instellingen kunnen bepaalde functies voor alle bridge-interfaces worden geregeld en kunnen globale bridge-tellers worden gemonitord.

Submenu: /interface/bridge/settings

Waarschuwing Als u Simple Queues of globale Queue Trees wilt toewijzen aan verkeer dat door een bridge wordt doorgestuurd, dan moet u de eigenschap use-ip-firewall inschakelen. Zonder deze eigenschap bereikt het bridgeverkeer nooit de postrouting-chain. Simple Queues en globale Queue Trees werken in de postrouting-chain. Om Simple Queues of globale Queue Trees toe te wijzen aan VLAN- of PPPoE-verkeer in een bridge, moet u ook de bijbehorende eigenschappen inschakelen.

Poortinstellingen

Het submenu Port wordt gebruikt om interfaces aan een bepaalde bridge toe te voegen.

Submenu: /interface/bridge/port

Info RouterOS kan maximaal 1024 gebridgede interfaces per bridge aan; deze limiet ligt vast en kan niet worden gewijzigd. Als u meer interfaces als bridgepoort probeert toe te voegen, kan dat tot onvoorspelbaar gedrag leiden.

Example

Dit voorbeeld laat zien hoe u Ethernet-poorten toevoegt aan een bestaande bridge-interface om een eenvoudige Layer 2-switchingopstelling te maken. Door ether1 en ether2 aan bridge1 toe te voegen, worden deze fysieke poorten deel van één geschakeld netwerksegment, waardoor apparaten die op een van beide poorten zijn aangesloten met elkaar kunnen communiceren alsof ze zich in hetzelfde LAN bevinden.

Voeg eerst elke poort toe aan de bridge-interface:

[admin@MikroTik] /interface/bridge/port/add bridge=bridge1 interface=ether1
[admin@MikroTik] /interface/bridge/port/add bridge=bridge1 interface=ether2

Controleer de configuratie door de bridge port-tabel weer te geven:

[admin@MikroTik] /interface/bridge/port/print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE       BRIDGE       HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     ether1          bridge1      yes  100     0x80         10                 10       none
 1     ether2          bridge1      yes  200     0x80         10                 10       none

De uitvoer bevestigt dat beide poorten nu samen gebridged zijn. De H-vlag geeft aan dat hardware-offloading actief is, wat betekent dat de switchchip de pakketdoorsturing verzorgt voor optimale prestaties. Elke poort krijgt een standaard PVID (Port VLAN ID) van respectievelijk 100 en 200 toegewezen, en beide gebruiken de standaard STP-prioriteit van 0x80.

Interfacelijsten

Vanaf RouterOS v6.41 kunnen interface lists als bridge-poorten worden toegevoegd en gesorteerd. Interface lists vereenvoudigen de configuratie van firewallregels door meerdere interfaces te groeperen. Het volgende voorbeeld laat zien hoe u een interface list aan een bridge toevoegt:

/interface/list
add name=LAN1
add name=LAN2
/interface/list/member
add interface=ether1 list=LAN1
add interface=ether2 list=LAN1
add interface=ether3 list=LAN2
add interface=ether4 list=LAN2
/interface/bridge/port
add bridge=bridge1 interface=LAN1
add bridge=bridge1 interface=LAN2

Wanneer er interface lists aan een bridge worden toegevoegd, verschijnen de afzonderlijke poorten uit die lijsten als dynamische poortvermeldingen:

[admin@MikroTik] /interface/bridge/port> pr
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE       BRIDGE       HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     LAN1            bridge1      yes    1     0x80         10                 10       none
 1  D  ether1          bridge1      yes    1     0x80         10                 10       none
 2  D  ether2          bridge1      yes    1     0x80         10                 10       none
 3     LAN2            bridge1      yes    1     0x80         10                 10       none
 4  D  ether3          bridge1      yes    1     0x80         10                 10       none
 5  D  ether4          bridge1      yes    1     0x80         10                 10       none

De volgorde waarin interfacelijsten verschijnen kan worden gewijzigd met het commando move. De tweede parameter geeft de positie aan waarvóór de geselecteerde interfacelijst moet worden geplaatst. Het volgende voorbeeld laat zien hoe u interfacelijsten sorteert:

[admin@MikroTik] > /interface/bridge/port/move 3 0
[admin@MikroTik] > /interface/bridge/port/print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE       BRIDGE       HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     LAN2            bridge1      yes    1     0x80         10                 10       none
 1  D  ether3          bridge1      yes    1     0x80         10                 10       none
 2  D  ether4          bridge1      yes    1     0x80         10                 10       none
 3     LAN1            bridge1      yes    1     0x80         10                 10       none
 4  D  ether1          bridge1      yes    1     0x80         10                 10       none
 5  D  ether2          bridge1      yes    1     0x80         10                 10       none

Waarschuwing Bij gebruik van het move-commando vertegenwoordigt de tweede parameter de "before id"-positie, die bepaalt waarheen de geselecteerde interface list wordt verplaatst. Als de eerste interface list naar de positie van de tweede interface list wordt verplaatst, heeft het commando geen effect, aangezien de eerste lijst al vóór de tweede lijst zou staan.

Interface Lists in de VLAN-tabel

Vanaf RouterOS versie 7.17 kunt u interface lists gebruiken voor de eigenschappen tagged en untagged in de bridge VLAN-tabel. Deze verbetering maakt een flexibelere VLAN-toewijzing aan poorten mogelijk door eenvoudigweg de leden van de interface list aan te passen, in plaats van elk bridge VLAN-item afzonderlijk bij te werken.

Als er verschillende interface lists zijn opgegeven voor de instellingen tagged en untagged, en er overlap is tussen de interfaceleden, krijgt de untagged lijst voorrang. U kunt de huidige interfaceconfiguratie controleren met de eigenschappen current-tagged en current-untagged in combinatie met het print commando.

Het volgende voorbeeld demonstreert hoe nieuwe interfaces kunnen worden toegevoegd aan bestaande interface lists, waarbij de bridge port en VLAN-tabel automatisch worden bijgewerkt zonder de instellingen in die menu's direct te wijzigen:

/interface/list
add name=vlan10_untagged
add name=vlan20_untagged
add name=vlan_tagged
/interface/list/member
add interface=ether2 list=vlan10_untagged
add interface=ether3 list=vlan10_untagged
add interface=ether4 list=vlan20_untagged
add interface=sfp-sfpplus1 list=vlan_tagged
/interface/bridge
add frame-types=admit-only-vlan-tagged name=bridge1 vlan-filtering=yes
/interface/bridge/port
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=vlan10_untagged pvid=10
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=vlan20_untagged pvid=20
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan_tagged
/interface/bridge/vlan
add bridge=bridge1 tagged=vlan_tagged vlan-ids=10
add bridge=bridge1 tagged=vlan_tagged vlan-ids=20

[admin@MikroTik] /interface/bridge/port/print 
Flags: D - DYNAMIC; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, HORIZON
#    INTERFACE        BRIDGE   HW   PVID  PRIORITY  HORIZON
0    vlan10_untagged  bridge1  yes    10  0x80      none   
1 DH ether2           bridge1  yes    10  0x80      none   
2 DH ether3           bridge1  yes    10  0x80      none   
3    vlan20_untagged  bridge1  yes    20  0x80      none   
4 DH ether4           bridge1  yes    20  0x80      none   
5    vlan_tagged      bridge1  yes     1  0x80      none   
6 DH sfp-sfpplus1     bridge1  yes     1  0x80      none   

[admin@MikroTik] /interface/bridge/vlan/print
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE   VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by pvid
0 D bridge1        10                  ether2          
                                       ether3          
;;; added by pvid
1 D bridge1        20                  ether4          
2   bridge1        10  sfp-sfpplus1                    
3   bridge1        20  sfp-sfpplus1                 

# make necessary changes to interface list members:
/interface/list/member/add list=vlan20_untagged interface=ether5
/interface/list/member/add list=vlan_tagged interface=sfp-sfpplus2 

# verify changes in bridge port and vlan menus:
[admin@MikroTik] > /interface/bridge/port/print 
Flags: D - DYNAMIC; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, HORIZON
#    INTERFACE        BRIDGE   HW   PVID  PRIORITY  HORIZON
0    vlan10_untagged  bridge1  yes    10  0x80      none   
1 DH ether2           bridge1  yes    10  0x80      none   
2 DH ether3           bridge1  yes    10  0x80      none   
3    vlan20_untagged  bridge1  yes    20  0x80      none   
4 DH ether4           bridge1  yes    20  0x80      none   
5 DH ether5           bridge1  yes    20  0x80      none   
6    vlan_tagged      bridge1  yes     1  0x80      none   
7 DH sfp-sfpplus1     bridge1  yes     1  0x80      none   
8 DH sfp-sfpplus2     bridge1  yes     1  0x80      none   

[admin@MikroTik] > /interface/bridge/vlan/print 
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE   VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by pvid
0 D bridge1        10                  ether2          
                                       ether3          
;;; added by pvid
1 D bridge1        20                  ether4          
                                       ether5          
2   bridge1        10  sfp-sfpplus1                    
                       sfp-sfpplus2                    
3   bridge1        20  sfp-sfpplus1                    
                       sfp-sfpplus2                    

Monitoring van bridge-poorten

Gebruik het commando monitor om de huidige status van bridge-poorten te bewaken.

Submenu: /interface/bridge/port/monitor

[admin@MikroTik] /interface/bridge/port/monitor [find interface=ether1] 
                  interface: ether1                  
                     status: in-bridge               
                    port-id: 0x80.1                  
                       role: root-port               
                  edge-port: no                      
        edge-port-discovery: yes                     
        point-to-point-port: yes                     
               external-fdb: no                      
               sending-rstp: yes                     
                   learning: yes                     
                 forwarding: yes                     
           actual-path-cost: 20000                   
    internal-root-path-cost: 20000                   
       designated-bridge-id: 0x1000.2C:C8:1B:FF:92:F4
   designated-internal-cost: 0                       
         designated-port-id: 0x80.1                  
  designated-remaining-hops: 20                      
                 tx-rx-bpdu: 3/63                    
        discard-transitions: 0                       
        forward-transitions: 1                       
                   tx-rx-tc: 2/0                     
           topology-changes: 1                       
       last-topology-change: 2m5s                    
           multicast-router: no                      
           hw-offload-group: switch1                 
          declared-vlan-ids: 1                       
        registered-vlan-ids: 1                       

Hosts-tabel

De hosts-tabel toont MAC-adressen die op een bridge-interface zijn geleerd. Deze tabel toont ook diverse flags die aanvullende informatie geven over elke host-regel. U benadert de hosts-tabel via het /interface/bridge/host submenu.

Submenu: /interface/bridge/host

Monitoring

Om de tabel met actieve hosts te bekijken, gebruikt u het commando print. De tabel toont alle MAC-adressen die op de bridge-interface zijn geleerd, samen met vlagindicatoren en verbindingsdetails.

[admin@MikroTik] /interface/bridge/host/print
Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external 
 #       MAC-ADDRESS        VID ON-INTERFACE            BRIDGE
0   D   B8:69:F4:C9:EE:D7      ether1                  bridge1
1   D   B8:69:F4:C9:EE:D8      ether2                  bridge1
2   DL  CC:2D:E0:E4:B3:38      bridge1                 bridge1
3   DL  CC:2D:E0:E4:B3:39      ether2                  bridge1

De uitvoer toont:

• D-vlag: Dynamisch geleerde MAC-adressen
• DL-vlag: MAC-adressen van lokale interfaces (de bridge zelf en de interfaces van zijn poorten)
• VID: VLAN ID die aan de hostvermelding is gekoppeld
• ON-INTERFACE: De bridge-poort waarop de host is geleerd
• BRIDGE: De bridge-interface waartoe de host behoort

Statische items

De bridge host-tabel ondersteunt het configureren van statische MAC-adresentries. Statische entries zijn nuttig in twee hoofdscenario's: het sturen van specifiek verkeer via een aangewezen poort, en het beveiligen van apparaatresources door dynamisch MAC-leren uit te schakelen en uitsluitend te vertrouwen op vooraf geconfigureerde statische entries.

De volgende tabel toont alle configureerbare parameters voor statische MAC-adresregels:

Submenu: /interface/bridge/host

Voorbeeld: Gebruik het volgende commando om al het verkeer bestemd voor MAC-adres 4C:5E:0C:4D:12:43 uitsluitend via ether2 door te sturen:

/interface/bridge/host
add bridge=bridge1 interface=ether2 mac-address=4C:5E:0C:4D:12:43

Multicast-tabel

De Multicast Table toont informatie over multicast-groepslidmaatschappen die via IGMP/MLD snooping is geleerd. Wanneer IGMP/MLD snooping op een bridge is ingeschakeld, monitort het apparaat actief de IGMP/MLD-netwerkcommunicatie om een Multicast Database (MDB) op te bouwen van actieve multicast-groepen en de daarop geabonneerde poorten. De bridge gebruikt deze informatie vervolgens om multicastverkeer slim door te sturen, alleen naar poorten waarop geïnteresseerde ontvangers zijn aangesloten, in plaats van alle poorten te overspoelen met multicastverkeer.

Merk op dat pakketten die zijn geadresseerd aan de link-local multicastgroepen 224.0.0.0/24 en ff02::1 een uitzondering vormen op dit gedrag. Deze adressen worden altijd zonder beperking naar alle poorten en VLAN's geflood, omdat ze worden gebruikt voor de werking van netwerkprotocollen.

Om de huidige tabel met multicast database-items te bekijken, gebruikt u het commando print in het submenu van de multicast database.

Submenu: /interface/bridge/mdb

[admin@MikroTik] /interface/bridge/mdb/print 
Flags: D - DYNAMIC
Columns: GROUP, VID, ON-PORTS, BRIDGE
 #   GROUP              VID  ON-PORTS  BRIDGE 
 0 D ff02::2              1  bridge1   bridge1
 1 D ff02::6a             1  bridge1   bridge1
 2 D ff02::1:ff00:0       1  bridge1   bridge1
 3 D ff02::1:ff01:6a43    1  bridge1   bridge1
 4 D 229.1.1.1           10  ether2    bridge1
 5 D 229.2.2.2           10  ether3    bridge1
                             ether2           
 6 D ff02::2             10  ether5    bridge1
                             ether3           
                             ether2           
                             ether4           

Statische items

Sinds RouterOS versie 7.7 is het mogelijk statische MDB entries te maken voor IPv4 en IPv6 multicast groepen.

Submenu: /interface/bridge/mdb

Om bijvoorbeeld een statische MDB-entry aan te maken voor multicastgroep 229.10.10.10 op de poorten ether2 en ether3 in VLAN 10, gebruikt u het onderstaande commando:

/interface/bridge/mdb
add bridge=bridge1 group=229.10.10.10 interface=ether2,ether3 vid=10

Controleer de resultaten met het commando print:

[admin@MikroTik] > /interface/bridge/mdb/print where group=229.10.10.10
Columns: GROUP, VID, ON-PORTS, BRIDGE
 # GROUP         VID  ON-PORTS  BRIDGE 
12 229.10.10.10   10  ether2    bridge1
                      ether3   

Als een bepaalde IPv6-multicastgroep niet gesnoopt hoeft te worden en het gewenst is dat deze op alle poorten en VLAN's wordt gefloodt, is het mogelijk om een statische MDB-vermelding op alle VLAN's en poorten aan te maken, inclusief de bridge-interface zelf. Gebruik het onderstaande commando om een statische MDB-vermelding aan te maken voor multicastgroep ff02::2 op alle VLAN's en poorten (pas de instelling ports aan uw specifieke opstelling aan):

/interface/bridge/mdb
add bridge=bridge1 group=ff02::2 interface=bridge1,ether2,ether3,ether4,ether5

[admin@MikroTik] > /interface/bridge/mdb/print where group=ff02::2
Flags: D - DYNAMIC
Columns: GROUP, VID, ON-PORTS, BRIDGE
 #   GROUP    VID  ON-PORTS  BRIDGE 
 0   ff02::2                 bridge1
15 D ff02::2    1  bridge1   bridge1
16 D ff02::2   10  bridge1   bridge1
                   ether2           
                   ether3           
                   ether4           
                   ether5           
17 D ff02::2   20  bridge1   bridge1
                   ether2           
                   ether3           
18 D ff02::2   30  bridge1   bridge1
                   ether2           
                   ether3     

Hardwarematige offloading van de bridge

Het is mogelijk om meerdere poorten samen te schakelen als een apparaat een ingebouwde switch-chip heeft. Waar een bridge een softwarefunctie is die CPU-resources verbruikt, stelt bridge hardware offloading u in staat de ingebouwde switch-chip te gebruiken om pakketten op wire speed door te sturen. Hiermee kunt u een hogere doorvoer bereiken als het correct is geconfigureerd.

Een pakket dat door een van de poorten wordt ontvangen, gaat altijd eerst door de switchlogica. De switchlogica bepaalt naar welke poorten het pakket moet gaan, meestal op basis van het bestemmings-MAC-adres. Hardwarematig doorgestuurde pakketten zijn niet zichtbaar voor RouterOS (alleen de statistieken laten zien dat er een pakket is gepasseerd). Dat komt doordat het pakket al door de switchchip is verwerkt en de CPU nooit heeft bereikt.

Pakketten kunnen via de switch-CPU-poort naar de CPU worden doorgestuurd voor beheertoegang, routing, firewallregels of verkeersregeling. Dit vereist configuratie die specifiek is voor uw apparaat en toepassing. Raadpleeg de handleidingpagina van uw specifieke apparaat:

• Functies van de Marvell Prestera switch chip
• Switches uit de CRS1xx/2xx-serie
• Switches buiten de CRS-serie

Gevaar Bepaalde eigenschappen van de bridge en van Ethernet-poorten zijn direct gerelateerd aan de instellingen van de switchchip. Het wijzigen van zulke eigenschappen kan een reset van de switchchip veroorzaken, waardoor alle Ethernet-poorten tijdelijk worden uitgeschakeld. Hier moet rekening mee worden gehouden bij het wijzigen van eigenschappen in productieomgevingen. Tot zulke eigenschappen behoren DHCP Snooping, IGMP Snooping, VLAN-filtering, L2MTU, Flow Control en andere. Welke instellingen precies een reset van de switchchip kunnen veroorzaken, hangt af van het model van het apparaat.

Waarschuwing Switches uit de CRS1xx/2xx-serie ondersteunen meerdere hardware offloaded bridges per switchchip. Alle andere apparaten ondersteunen er slechts één. Gebruik hw=yes/no onder /interface/bridge/port om te selecteren welke bridge hardware offloading gebruikt.

De volgende tabellen tonen welke bridge-functies ondersteund worden met hardware offloading (✓) of hardware offloading uitschakelen (✗) voor elk type switchchip:

MikroTik-apparaten met een Marvell Prestera Switch

Bijvoorbeeld: CRS3xx, CRS4xx, CRS5xx, CRS8xx, CCR2116, CCR2216, RDS2216. Zie Marvell Prestera switch chip features.

¹ Alleen bonding-interfaces met mode=802.3ad (LACP), mode=balance-xor (statische LAG) en mode=active-backup worden in hardware offloaded. Andere modi ondersteunen geen HW offloading. De switch gebruikt altijd Layer2+Layer3+Layer4 voor de transmit hash policy; het wijzigen van de transmit hash policy heeft geen effect.

88E6393X, 88E6191X, 88E6190

Bijvoorbeeld: RB5009-serie, L009-serie, CCR2004-16G-2S+. Zie Switch Chip Features.

¹ Ondersteunt geen ether-type=0x88a8 of ether-type=0x9100 (alleen de standaard ether-type=0x8100 wordt ondersteund). Geen ondersteuning voor tag-stacking=yes. Het gebruik van deze functies schakelt HW offload uit.
² Geen QinQ-ondersteuning, alleen de eerste VLAN-tag wordt geparseerd. Dubbel getagde DHCP- of IGMP-pakketten kunnen onjuist worden verwerkt.
³ Alleen bonding-interfaces met mode=802.3ad (LACP), mode=balance-xor (statische LAG) en mode=active-backup worden in hardware offloaded. Andere modi ondersteunen geen HW offloading. Beperkt tot Layer2 transmit hash; het wijzigen van de transmit hash policy heeft geen effect.

MT7621, MT7531, EN7523, RTL8367

Bijvoorbeeld: hEX S, hAP ax lite, hEX Refresh, RBM33G, RB4011, RB1100AHx4. Zie Switch Chip Features.

¹ Ondersteunt geen ether-type=0x88a8 of ether-type=0x9100 (alleen de standaard ether-type=0x8100 wordt ondersteund). Geen ondersteuning voor tag-stacking=yes. Het gebruik van deze functies schakelt HW offload uit.

CRS1xx/CRS2xx-serie

Bijvoorbeeld: CRS105, CRS106, CRS109, CRS112, CRS125, CRS210, CRS212, CRS226. Zie CRS1xx/2xx series switches.

¹ Functie werkt niet correct in VLAN-switchingopstellingen.

QCA8337, Atheros8327, Atheros8316

Bijvoorbeeld: RB3011, RB1100AHx2, RB850Gx2, cAP ac, wAP ac, Audience, mANTBox, CCR1009. Zie Switch Chip Features.

¹ Functie werkt niet correct in VLAN-switchingopstellingen.

Atheros8227, Atheros7240

Bijvoorbeeld: hAP lite, hEX lite, PowerBox, wsAP ac lite, RBmAP2nD. Zie Switch Chip Features.

IPQ-PPE, QCA8386, PIPE 98PX1012

Bijvoorbeeld: hAP ax-serie, cAP ax, Chateau ax-serie, hAP be³ Media, CCR2004-1G-12S+2XS. Zie Switch Chip Features.

Gevaar Het gebruik van protocol-mode=none op IPQ-PPE schakelt een HW-offloaded bridge in en kan problemen veroorzaken.
Het wordt aanbevolen een niet-HW-offloaded bridge te gebruiken door de standaardinstelling protocol-mode=rstp te behouden of door handmatig hw=no in te stellen onder /interface/bridge/port.

Example

Het volgende voorbeeld demonstreert hoe u port switching configureert met een bridge waarbij hardware offloading is ingeschakeld. Deze configuratie maakt een bridge-interface aan en voegt meerdere Ethernet-interfaces toe als bridge ports. De bridge port instelling hw=yes wordt standaard gebruikt.

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5

Controleer of hardware offloading actief is door de H-vlag in de bridge port-tabel te bekijken:

[admin@MikroTik] /interface/bridge/port/print 
Flags: H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, TRUSTED-RA, TRUSTED-DHCPV6, FAST-LEAVE, BPDU-GUARD, EDGE, POINT-TO-POINT, PVID, FRAME-TYPES
#   INTERFACE  BRIDGE   HW   HORIZON  TRUSTED  TRUSTED-RA  TRUSTED-DHCPV6  FAST-LEAVE  BPDU-GUARD  EDGE  POINT-TO-POINT  PVID  FRAME-TYPES
0 H ether2     bridge1  yes  none     no       no          no              no          no          auto  auto               1  admit-all  
1 H ether3     bridge1  yes  none     no       no          no              no          no          auto  auto               1  admit-all  
2 H ether4     bridge1  yes  none     no       no          no              no          no          auto  auto               1  admit-all  
3 H ether5     bridge1  yes  none     no       no          no              no          no          auto  auto               1  admit-all  

VLAN-filtering op de bridge

VLAN-filtering op de bridge maakt VLAN-bewust forwarding op Layer 2 mogelijk en staat het wijzigen van VLAN-tags binnen de bridge toe. Door deze functie werkt de bridge meer als een traditionele Ethernet-switch en worden compatibiliteitsproblemen met Spanning Tree opgelost die kunnen optreden wanneer VLAN-interfaces gebridged worden. Het configureren van VLAN-filtering op de bridge wordt sterk aanbevolen om te voldoen aan de standaarden STP (IEEE 802.1D) en RSTP (IEEE 802.1W), en het is verplicht om ondersteuning voor MSTP (IEEE 802.1s) in RouterOS in te schakelen.

De belangrijkste VLAN-instelling is vlan-filtering, die globaal de VLAN-bewustheid en de verwerking van VLAN-tags voor de bridge regelt. Wanneer vlan-filtering op no is ingesteld, negeert de bridge VLAN-tags, werkt hij in de modus shared-VLAN-learning (SVL) en kan hij de VLAN-tags van pakketten niet wijzigen. Het inschakelen van vlan-filtering activeert alle VLAN-gerelateerde functionaliteit van de bridge en schakelt over naar de modus independent-VLAN-learning (IVL). Naast het samenvoegen van poorten voor Layer 2-forwarding functioneert de bridge zelf als een interface en heeft daarom een Port VLAN ID (pvid).

Waarschuwing Momenteel kunnen MikroTik-apparaten met een Marvell Prestera-switch en met RTL8367-, 88E6393X-, 88E6191X-, 88E6190-, MT7621-, MT7531- en EN7523-switchchips (sinds RouterOS v7) bridge VLAN filtering en hardware offloading tegelijkertijd gebruiken. Andere apparaten kunnen niet profiteren van de voordelen van een ingebouwde switchchip wanneer bridge VLAN filtering is ingeschakeld. Deze apparaten moeten worden geconfigureerd volgens de methode die in de handleiding Basic VLAN switching wordt beschreven. Het gebruik van een onjuiste configuratiemethode kan doorvoerproblemen in uw netwerk veroorzaken.

Bridge VLAN-tabel

De Bridge VLAN-tabel definieert het poortlidmaatschap per VLAN en geeft de VLAN-tag-actie voor uitgaand verkeer aan. Poorten die als tagged zijn geconfigureerd, verzenden frames met hun bijbehorende VLAN ID, terwijl poorten die als untagged zijn geconfigureerd de VLAN-tag verwijderen voordat ze frames verzenden. Bridge-poorten waarbij frame-types is ingesteld op admit-all of admit-only-untagged-and-priority-tagged worden automatisch als untagged poorten toegevoegd voor hun geconfigureerde PVID.

Submenu: /interface/bridge/vlan

Gevaar Met de parameter vlan-ids kan een set of een bereik van VLAN's worden opgegeven, maar dit mag alleen worden gebruikt voor configuraties van tagged poorten. Wanneer er meerdere VLAN's worden opgegeven voor configuraties van access-poorten, kunnen tagged pakketten als untagged pakketten via de verkeerde access-poort worden verzonden, ongeacht de PVID-waarde.

Waarschuwing Zorg ervoor dat alle vereiste interfaces aan de bridge VLAN-tabel worden toegevoegd wanneer u bridge VLAN filtering gebruikt.

Om routingfuncties op hetzelfde apparaat correct te laten werken via poorten die bridge VLAN filtering gebruiken, moet u toegang tot de bridge-interface toestaan (dit omvat de switch-cpu poort wanneer hardware-offloaded VLAN filtering wordt gebruikt). Dit kan handmatig worden gedaan door de bridge-interface zelf als tagged poort aan de VLAN-tabel toe te voegen. Sinds RouterOS v7.16 gebeurt dit automatisch wanneer een VLAN-interface wordt toegevoegd aan een bridge waarop VLAN filtering is ingeschakeld (er verschijnt een dynamische entry met de opmerking "added by vlan on bridge" onder het menu /interface/bridge/vlan). Meer voorbeelden vindt u in de secties over inter-VLAN-routing en beheertoegang.

Sinds RouterOS 7.20 wordt er een dynamisch getagd item met de naam "added by switch-cpu" toegevoegd wanneer hetzelfde VLAN ID zich over meerdere switchchips uitstrekt of zowel op hardware- als softwarepoorten wordt gebruikt.

Gevaar Wanneer u toegang tot de CPU toestaat, geeft u vanaf een specifieke poort toegang tot de router/switch zelf. Dat is niet altijd gewenst. Zorg ervoor dat u passende firewall filter-regels instelt om uw apparaat te beveiligen wanneer CPU-toegang vanaf een specifieke VLAN-ID en poort is toegestaan. Gebruik firewall filter-regels om alleen toegang tot de benodigde services toe te staan.

Waarschuwing Onjuist geconfigureerde bridge VLAN filtering kan beveiligingsproblemen veroorzaken. Zorg ervoor dat u volledig begrijpt hoe de Bridge VLAN table werkt voordat u uw apparaat in een productieomgeving inzet.

Instellingen van bridge-poorten

Elke bridge-poort heeft meerdere VLAN-gerelateerde instellingen die het untagged VLAN-lidmaatschap, het gedrag voor VLAN-tagging en -untagging en de pakketfiltering op basis van de aanwezigheid van een VLAN-tag regelen.

Submenu: /interface/bridge/port

Hosttabel van de bridge

De Bridge-hosttabel toont MAC-adressen die op een bridge-interface zijn geleerd. Wanneer vlan-filtering is ingeschakeld, toont de tabel ook het VLAN ID dat bij elk geleerd MAC-adres hoort, waardoor de modus independent VLAN learning (IVL) mogelijk wordt.

[admin@MikroTik] > /interface/bridge/host/print where !local 
Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external 
 #       MAC-ADDRESS        VID ON-INTERFACE       BRIDGE
0   D   CC:2D:E0:E4:B3:AA  300 ether3             bridge1
1   D   CC:2D:E0:E4:B3:AB  400 ether4             bridge1

VLAN-voorbeeld: trunk- en access-poorten

Deze sectie laat zien hoe u een eenvoudige VLAN-opzet configureert met één trunkpoort en meerdere accesspoorten. De trunkpoort (ether2) transporteert getagd VLAN-verkeer tussen switches of naar een router, terwijl accesspoorten (ether6, ether7, ether8) verbinding maken met eindapparaten en ongetagd VLAN-verkeer gebruiken.

Stap 1: Maak de bridge-interface aan

Maak een bridge-interface met vlan-filtering uitgeschakeld. Dit is belangrijk omdat het inschakelen van VLAN-filtering het verkeer onmiddellijk beperkt, waardoor u buitengesloten kunt raken van het apparaat voordat de configuratie voltooid is. Raadpleeg voor gedetailleerde informatie over het beheren van toegang tot het apparaat tijdens de VLAN-configuratie de sectie Management access configuration.

/interface/bridge
add name=bridge1 vlan-filtering=no

Stap 2: Voeg bridge-poorten toe en configureer de PVID

Voeg de fysieke interfaces toe aan de bridge en configureer de Port VLAN ID (pvid) voor accesspoorten. De pvid bepaalt aan welk VLAN untagged verkeer wordt toegewezen wanneer het de bridge binnenkomt. De instelling frame-types bepaalt welk soort verkeer elke poort accepteert: alleen tagged, alleen untagged, of beide.

/interface/bridge/port
add bridge=bridge1 interface=ether2 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=ether6 pvid=200 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether7 pvid=300 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether8 pvid=400 frame-types=admit-only-untagged-and-priority-tagged

Stap 3: Bridge VLAN Table-vermeldingen aanmaken

Maak de vermeldingen in de bridge VLAN-tabel aan. De trunkpoort (ether2) moet geconfigureerd worden als tagged lid, wat betekent dat deze frames met VLAN-tags verzendt en ontvangt. Accesspoorten worden automatisch toegevoegd als untagged leden op basis van hun pvid-instelling, dus u hoeft alleen de tagged poort in elke VLAN-vermelding op te geven.

/interface/bridge/vlan
add bridge=bridge1 tagged=ether2 vlan-ids=200
add bridge=bridge1 tagged=ether2 vlan-ids=300
add bridge=bridge1 tagged=ether2 vlan-ids=400

Stap 4: VLAN-filtering inschakelen

Zodra alle VLAN-instellingen zijn geconfigureerd, schakelt u VLAN-filtering in op de bridge om de VLAN-functionaliteit te activeren.

/interface/bridge/set bridge1 vlan-filtering=yes

Stap 5: (Optioneel) Ongetagd verkeer weigeren

Als optionele beveiligingsmaatregel kunt u de bridge zo instellen dat untagged verkeer wordt geweigerd door het frame-type te wijzigen. Dit voorkomt dat het standaard VLAN 1 (pvid=1) wordt gebruikt en zorgt ervoor dat alleen correct getagd verkeer wordt geaccepteerd.

/interface/bridge/set bridge1 frame-types=admit-only-vlan-tagged

VLAN-voorbeeld - Trunk- en hybride poorten

Maak een bridge met uitgeschakelde vlan-filtering om te voorkomen dat u de toegang tot de router verliest voordat de VLAN's volledig zijn geconfigureerd. Als u beheertoegang tot de bridge nodig hebt, raadpleeg dan de sectie Management access configuration.

/interface/bridge
add name=bridge1 vlan-filtering=no

Voeg bridge-poorten toe en geef de pvid op voor hybride VLAN-poorten om untagged verkeer aan het bedoelde VLAN toe te wijzen. Gebruik de instelling frame-types om op ether2 alleen tagged pakketten te accepteren.

/interface/bridge/port
add bridge=bridge1 interface=ether2 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=ether6 pvid=200
add bridge=bridge1 interface=ether7 pvid=300
add bridge=bridge1 interface=ether8 pvid=400

Voeg Bridge VLAN-entries toe en geef daarin de tagged poorten op. In dit voorbeeld wordt egress VLAN-tagging ook gedaan op de poorten ether6, ether7 en ether8, waardoor het hybride poorten worden. Bridge-poorten waarbij frame-types is ingesteld op admit-all worden automatisch toegevoegd als untagged poorten voor het pvid VLAN.

/interface/bridge/vlan 
add bridge=bridge1 tagged=ether2,ether7,ether8 vlan-ids=200
add bridge=bridge1 tagged=ether2,ether6,ether8 vlan-ids=300
add bridge=bridge1 tagged=ether2,ether6,ether7 vlan-ids=400

Schakel tot slot, wanneer de VLAN-configuratie voltooid is, Bridge VLAN Filtering in.

/interface/bridge/set bridge1 vlan-filtering=yes 

Een optionele stap is om frame-types=admit-only-vlan-tagged in te stellen op de bridge interface om het standaard untagged VLAN 1 (pvid=1) uit te schakelen.

/interface/bridge/set bridge1 frame-types=admit-only-vlan-tagged

Gevaar U hoeft access-poorten niet als untagged poorten toe te voegen, omdat ze dynamisch worden toegevoegd als untagged poorten met de VLAN-ID die in pvid is opgegeven; u kunt alleen de trunkpoort als tagged poort opgeven. Alle poorten met dezelfde pvid worden als untagged poorten in één entry toegevoegd. U moet er rekening mee houden dat de bridge zelf ook een poort is en ook een pvid-waarde heeft; dat betekent dat de bridgepoort eveneens als untagged poort wordt toegevoegd voor de poorten met dezelfde pvid. U kunt dit gedrag omzeilen door op alle poorten een andere pvid in te stellen (ook op de trunkpoort en de bridge zelf), of door frame-type op accept-only-vlan-tagged te zetten.

VLAN-voorbeeld - InterVLAN-routering via een bridge

Maak een bridge met uitgeschakelde vlan-filtering om te voorkomen dat u de toegang tot de router verliest voordat de VLAN's volledig zijn geconfigureerd. Als u beheertoegang tot de bridge nodig hebt, raadpleeg dan de sectie Management access configuration.

/interface/bridge
add name=bridge1 vlan-filtering=no

Voeg bridge-poorten toe en geef de pvid op voor VLAN-accesspoorten om hun untagged verkeer aan het bedoelde VLAN toe te wijzen. Gebruik de instelling frame-types om alleen untagged pakketten te accepteren.

/interface/bridge/port
add bridge=bridge1 interface=ether6 pvid=200 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether7 pvid=300 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge1 interface=ether8 pvid=400 frame-types=admit-only-untagged-and-priority-tagged

Voeg Bridge VLAN-entries toe en geef daarin de tagged poorten op. In dit voorbeeld is de bridge1 interface de VLAN-trunk die verkeer verder stuurt voor InterVLAN-routing. Bridge-poorten waarbij frame-types is ingesteld op admit-only-untagged-and-priority-tagged worden automatisch toegevoegd als untagged poorten voor het pvid VLAN.

/interface/bridge/vlan
add bridge=bridge1 tagged=bridge1 vlan-ids=200
add bridge=bridge1 tagged=bridge1 vlan-ids=300
add bridge=bridge1 tagged=bridge1 vlan-ids=400

Configureer VLAN-interfaces op bridge1 om de verwerking van getagd VLAN-verkeer op routingniveau mogelijk te maken en stel IP-adressen in om routering tussen de VLAN's te waarborgen zoals gepland.

/interface/vlan
add interface=bridge1 name=VLAN200 vlan-id=200
add interface=bridge1 name=VLAN300 vlan-id=300
add interface=bridge1 name=VLAN400 vlan-id=400

/ip/address
add address=20.0.0.1/24 interface=VLAN200
add address=30.0.0.1/24 interface=VLAN300
add address=40.0.0.1/24 interface=VLAN400

Schakel tot slot, wanneer de VLAN-configuratie voltooid is, Bridge VLAN Filtering in:

/interface/bridge/set bridge1 vlan-filtering=yes 

Een optionele stap is om frame-types=admit-only-vlan-tagged in te stellen op de bridge interface om het standaard untagged VLAN 1 (pvid=1) uit te schakelen.

/interface/bridge/set bridge1 frame-types=admit-only-vlan-tagged

Sinds RouterOS v7 is het mogelijk verkeer te routeren met L3 HW offloading op bepaalde apparaten. Zie voor meer details L3 Hardware Offloading.

Configuratie van de beheertoegang

Er zijn meerdere manieren om beheertoegang in te stellen op een apparaat dat bridge VLAN filtering gebruikt. Hieronder staan enkele van de meest populaire benaderingen om de toegang tot een router/switch correct in te schakelen. Begin met het aanmaken van een bridge zonder VLAN filtering ingeschakeld:

/interface/bridge
add name=bridge1 vlan-filtering=no

Untagged toegang zonder VLAN-filtering

In gevallen waarin VLAN-filtering niet op de bridge is ingeschakeld en beheertoegang via untagged verkeer vereist is, is de configuratie eenvoudig. De enige noodzakelijke stap is het rechtstreeks toewijzen van een IP-adres aan de bridge-interface zelf. Aangezien de bridge op Layer 2 zonder VLAN-tagging werkt, kan al het untagged verkeer dat de bridge-poorten binnenkomt zonder aanvullende configuratie communiceren met het IP-adres dat aan de bridge-interface is toegewezen.

/ip/address
add address=192.168.99.1/24 interface=bridge1

Deze aanpak biedt de eenvoudigste methode om de router of switch te benaderen voor beheerdoeleinden wanneer VLAN-filtering geen deel uitmaakt van het netwerkontwerp.

Getagde toegang zonder VLAN-filtering

Deze methode wordt gebruikt wanneer u de router/switch wilt beheren via getagd VLAN-verkeer, maar zonder bridge VLAN-filtering in te schakelen. In dit scenario wordt bovenop de bridge een aparte VLAN-interface gemaakt om het getagde beheerverkeer af te handelen. Deze aanpak is nuttig wanneer u het apparaat via een specifiek VLAN ID moet benaderen terwijl u de bridge-configuratie eenvoudig en overzichtelijk houdt.

Om getagde managementtoegang te configureren, maakt u eerst een VLAN-interface op de bridge met het gewenste VLAN ID, en wijst u vervolgens een IP-adres aan die VLAN-interface toe. Hierdoor is de router bereikbaar via het getagde VLAN terwijl de bridge in zijn standaardtoestand blijft (zonder dat VLAN-filtering is ingeschakeld). De VLAN-interface fungeert als een logische sub-interface die het MAC-adres van de bovenliggende bridge-interface overneemt.

/interface/vlan
add interface=bridge1 name=MGMT vlan-id=99
/ip/address
add address=192.168.99.1/24 interface=MGMT

Deze configuratie maakt een management-VLAN (VLAN 99) op de bridge, waardoor het apparaat bereikbaar is op IP-adres 192.168.99.1 via elke poort die met VLAN 99 getagd verkeer transporteert.

Getagde toegang met VLAN-filtering

In scenario's waarin VLAN filtering is ingeschakeld op de bridge en beheertoegang via tagged verkeer vereist is, zijn aanvullende configuratiestappen nodig. Met deze methode kunt u de beheerinterface van de router/switch bereiken via een specifiek VLAN ID (VLAN 99 in dit voorbeeld) met tagged verkeer op aangewezen poorten.

Maak eerst een VLAN-interface bovenop de bridge en wijs er een IP-adres aan toe. Deze VLAN-interface verwerkt het getagde beheerverkeer:

/interface/vlan
add interface=bridge1 name=MGMT vlan-id=99
/ip/address
add address=192.168.99.1/24 interface=MGMT

Vervolgens moet u de juiste items toevoegen aan de bridge VLAN-tabel om tagged verkeer toe te staan op de poorten waarvandaan beheertoegang wordt gestart. Als u het apparaat bijvoorbeeld wilt benaderen vanaf de poorten ether3, ether4 en sfp-sfpplus1 met VLAN 99 tagged verkeer, neem dan de interface bridge1 zelf op in de lijst met tagged poorten (de bridge-interface moet tagged zijn zodat de VLAN-interface met de switch-CPU kan communiceren):

/interface/bridge/vlan
add bridge=bridge1 tagged=bridge1,ether3,ether4,sfp-sfpplus1 vlan-ids=99

Zodra de VLAN-tabel correct is geconfigureerd, kunt u VLAN-filtering op de bridge inschakelen:

/interface/bridge/set bridge1 vlan-filtering=yes

Deze configuratie maakt beheertoegang mogelijk via getagd VLAN 99-verkeer, met behoud van de beveiligingsvoordelen van VLAN-filtering. De bridge-interface zelf is opgenomen als getagd lid om correcte communicatie tussen de VLAN-interface en de switch-CPU te garanderen voor routering en beheer.

Untagged toegang met VLAN-filtering

Wanneer bridge VLAN-filtering is ingeschakeld en u het apparaat via untagged verkeer moet benaderen, moet u ervoor zorgen dat de management-VLAN-interface hetzelfde VLAN ID gebruikt als het VLAN ID van de untagged poort (ingesteld via de parameter pvid). Zo kan untagged verkeer van access-poorten correct communiceren met de beheerinterface van de router.

Maak eerst een VLAN-interface op de bridge en wijs er een IP-adres aan toe, net zoals in het vorige voorbeeld. Deze VLAN-interface verwerkt het beheerverkeer:

/interface/vlan
add interface=bridge1 name=MGMT vlan-id=99
/ip/address
add address=192.168.99.1/24 interface=MGMT

Als u bijvoorbeeld wilt dat de untagged poorten ether2 en ether3 kunnen communiceren met de VLAN 99-beheerinterface, moeten deze poorten worden geconfigureerd met een pvid-waarde die overeenkomt met het VLAN-ID van het beheer-VLAN. Daarnaast moet u de bridge-interface zelf als tagged poortlid aan de VLAN-tabel toevoegen, waardoor de router het getagde beheerverkeer kan verwerken. U kunt indien nodig voor uw specifieke netwerktopologie ook extra tagged poorten toevoegen (zie de vorige voorbeelden voor meer details over de configuratie van tagged poorten):

/interface/bridge/port
set [find interface=ether2] pvid=99
set [find interface=ether3] pvid=99
/interface/bridge/vlan 
add bridge=bridge1 tagged=bridge1 untagged=ether2,ether3 vlan-ids=99

Zodra u de configuratie van de VLAN-tabel hebt voltooid, kunt u VLAN-filtering op de bridge inschakelen. Hiermee wordt alle VLAN-gerelateerde functionaliteit geactiveerd en begint het filteren van verkeer op basis van uw VLAN-instellingen:

/interface/bridge/set bridge1 vlan-filtering=yes 

Het ongetagde VLAN voor de bridge-interface wijzigen

Als VLAN-filtering wordt gebruikt, is het mogelijk om het untagged VLAN ID voor de bridge-interface te wijzigen met de instelling pvid. Merk op dat het aanmaken van routeerbare VLAN-interfaces en het toestaan van getagd verkeer op de bridge een flexibelere en over het algemeen aanbevolen optie is.

Maak eerst een IP-adres aan op de bridge-interface.

/ip/address
add address=192.168.99.1/24 interface=bridge1

Untagged verkeer van bridge1 moet bijvoorbeeld kunnen communiceren met de untagged poorten ether2 en ether3 en de tagged poort sfp-sfpplus1 in VLAN 99. Om dit te bereiken moeten bridge1, ether2 en ether3 met dezelfde pvid worden geconfigureerd en moet sfp-sfpplus1 als tagged lid worden toegevoegd.

/interface/bridge
set [find name=bridge1] pvid=99
/interface/bridge/port
set [find interface=ether2] pvid=99
set [find interface=ether3] pvid=99
/interface/bridge/vlan
add bridge=bridge1 tagged=sfp-sfpplus1 untagged=bridge1,ether2,ether3 vlan-ids=99

Daarna kunt u VLAN-filtering inschakelen:

/interface/bridge/set bridge1 vlan-filtering=yes 

Waarschuwing Als de verbinding met de router/switch via een IP-adres niet nodig is, kunnen de stappen voor het toevoegen van een IP-adres worden overgeslagen, aangezien een verbinding met de router/switch via Layer2-protocollen (bijv. MAC-telnet) hoe dan ook werkt.

VLAN Tunneling (QinQ)

Sinds RouterOS v6.43 voldoet de RouterOS bridge aan IEEE 802.1ad en is het mogelijk VLAN IDs te filteren op basis van het Service VLAN ID (0x88a8) in plaats van het Customer VLAN ID (0x8100). Dezelfde principes kunnen worden toegepast als bij IEEE 802.1Q VLAN filtering (dezelfde voorbeeldopstellingen kunnen worden gebruikt). Hieronder staat een topologie voor een gebruikelijke Provider bridge:

In dit voorbeeld kunnen R1, R2, R3, en R4 willekeurig VLAN-getagd verkeer versturen via 802.1Q (CVID), maar SW1 en SW2 moeten het verkeer tussen de routers zo isoleren dat R1 alleen met R3 kan communiceren en R2 alleen met R4. Daarvoor kunt u al het inkomende verkeer taggen met een SVID en deze VLAN's alleen op bepaalde poorten toestaan. Begin met het inschakelen van de service tag 0x88a8, geïntroduceerd door 802.1ad, op de bridge. Gebruik deze commando's op SW1 en SW2:

/interface/bridge
add name=bridge1 vlan-filtering=no ether-type=0x88a8

In deze opstelling worden ether1 en ether2 access ports (untagged); gebruik de parameter pvid om al het inkomende verkeer op elke poort te taggen en gebruik deze commando's op SW1 en SW2:

/interface/bridge/port
add interface=ether1 bridge=bridge1 pvid=200
add interface=ether2 bridge=bridge1 pvid=300
add interface=ether3 bridge=bridge1

Geef de tagged en untagged poorten op in de bridge VLAN-tabel. Gebruik deze commando's op SW1 en SW2:

/interface/bridge/vlan
add bridge=bridge1 tagged=ether3 untagged=ether1 vlan-ids=200
add bridge=bridge1 tagged=ether3 untagged=ether2 vlan-ids=300

Wanneer de bridge VLAN-tabel is geconfigureerd, kunt u bridge VLAN-filtering inschakelen. Gebruik deze commando's op SW1 en SW2:

/interface/bridge/set bridge1 vlan-filtering=yes 

Gevaar Door vlan-filtering in te schakelen filtert u verkeer weg dat voor de CPU bestemd is. Voordat u VLAN-filtering inschakelt, moet u ervoor zorgen dat u een beheerpoort hebt ingesteld.

Merk op dat als u het nieuwe EtherType/TPID 0x88a8 (service tag) gebruikt en u ook een VLAN-interface nodig hebt voor uw Service VLAN, u ook de parameter use-service-tag op de VLAN-interface moet toepassen.

Gevaar Wanneer ether-type=0x8100 is geconfigureerd, controleert de bridge de buitenste VLAN-tag om te zien of deze EtherType 0x8100 gebruikt. Als de bridge een pakket ontvangt met een buitenste tag met een andere EtherType, markeert hij het pakket als untagged. Aangezien RouterOS alleen de buitenste tag van een pakket controleert, is het niet mogelijk om 802.1Q-pakketten te filteren wanneer het 802.1ad-protocol wordt gebruikt.

Waarschuwing Momenteel kunnen alleen MikroTik-apparaten met een Marvell Prestera-switch hardware offloaded VLAN filtering uitvoeren met de Service tag, EtherType/TPID 0x88a8.

Gevaar Apparaten met de switch chip Marvell-98DX3257 (bijv. de CRS354-serie) ondersteunen geen VLAN filtering op 1Gbps Ethernet-interfaces voor andere VLAN-types (0x88a8 en 0x9100).

Tag stacking

Sinds RouterOS v6.43 is het mogelijk geforceerd een nieuwe VLAN tag toe te voegen bovenop bestaande VLAN tags. Deze functie kan worden gebruikt om een CVID stacking opstelling te realiseren, waarbij een CVID (0x8100) tag vóór een bestaande CVID tag wordt geplaatst. Dit type opstelling lijkt sterk op de Provider bridge opstelling. Om dezelfde opstelling te realiseren, maar met meerdere CVID tags (CVID stacking), kunnen we dezelfde topologie gebruiken:

In dit voorbeeld kunnen R1, R2, R3, en R4 willekeurig VLAN-getagd verkeer versturen; dat kan 802.1ad, 802.1Q of een ander type verkeer zijn, maar SW1 en SW2 moeten het verkeer tussen de routers zo isoleren dat R1 alleen met R3 kan communiceren en R2 alleen met R4. Daarvoor kunt u al het inkomende verkeer taggen met een nieuwe CVID-tag en deze VLAN's alleen op bepaalde poorten toestaan. Begin met het selecteren van het juiste EtherType; gebruik deze commando's op SW1 en SW2:

/interface/bridge
add name=bridge1 vlan-filtering=no ether-type=0x8100

In deze opstelling negeren ether1 en ether2 alle aanwezige VLAN-tags en voegen ze een nieuwe VLAN-tag toe. Gebruik de parameter pvid om al het inkomende verkeer op elke poort te taggen en sta tag-stacking toe op deze poorten. Gebruik deze commando's op SW1 en SW2:

/interface/bridge/port
add interface=ether1 bridge=bridge1 pvid=200 tag-stacking=yes
add interface=ether2 bridge=bridge1 pvid=300 tag-stacking=yes
add interface=ether3 bridge=bridge1

Geef de tagged en untagged poorten op in de bridge VLAN-tabel. U hoeft alleen de VLAN ID van de buitenste tag op te geven. Gebruik deze commando's op SW1 en SW2:

/interface/bridge/vlan
add bridge=bridge1 tagged=ether3 untagged=ether1 vlan-ids=200
add bridge=bridge1 tagged=ether3 untagged=ether2 vlan-ids=300

Wanneer de bridge VLAN-tabel is geconfigureerd, kunt u bridge VLAN-filtering inschakelen, wat vereist is om de parameter pvid enig effect te laten hebben. Gebruik deze commando's op SW1 en SW2:

/interface/bridge/set bridge1 vlan-filtering=yes

Gevaar Door vlan-filtering in te schakelen filtert u verkeer weg dat voor de CPU bestemd is; voordat u VLAN-filtering inschakelt, moet u ervoor zorgen dat u een beheerpoort hebt ingesteld.

MVRP

Multiple VLAN Registration Protocol (MVRP) is een protocol gebaseerd op Multiple Registration Protocol (MRP) waarmee attributen (VLAN ID's in het geval van MVRP) kunnen worden geregistreerd bij andere leden van een bridged LAN.

Een MRP-applicatie kan declaraties van attributen doen of intrekken, wat resulteert in registratie of het verlaten van die attributen bij andere MRP-deelnemers.

Zo werkt het.

MRP bestaat uit twee delen:

• Applicant - verantwoordelijk voor het verzenden van declarations (of leaves). Het gedrag ervan kan per poort worden geconfigureerd met de instelling mvrp-applicant-state, en per VLAN met de instelling mvrp-forbidden.
• Registrar - verantwoordelijk voor het registreren van binnenkomende declaraties. De configuratie hiervan kan per poort worden ingesteld met de instelling mvrp-registrar-state en per VLAN met de instelling mvrp-forbidden.

Propagatie van registraties: Een binnenkomende registratie op een bridge-poort maakt die specifieke poort dynamisch lid van een tagged VLAN. Daarnaast worden de bij deze registratie horende attributen als declaratie verspreid naar alle actieve (forwarding) bridge-poorten.

Declaration Operation: Bij MVRP worden de geconfigureerde VLAN's op elke poort gedeclareerd, maar ze worden pas als lid van die VLAN's geconfigureerd wanneer er een declaratie vanuit het LAN wordt ontvangen (de Registrar registreert het VLAN dan). Vanuit het perspectief van een eindstation wordt er één declaratie geregistreerd op elke upstream-poort in het hele LAN. Wanneer een ander eindstation hetzelfde attribuut declareert, ontstaat er een pad van registraties tussen de twee (of meer) eindstations, zie de afbeelding hieronder.

MVRP helpt om VLAN-informatie dynamisch door het bridged netwerk te verspreiden en VLAN's alleen op de benodigde poorten te configureren. Dit maakt het netwerk efficiënt doordat onnodige verkeersflooding wordt vermeden.

Zoals eerder opgemerkt is MVRP alleen actief op poorten die forwarden. In het geval van MSTP worden declaraties en registraties alleen gedaan als de poort forwardt in de MSTI waarin het VLAN is gemapt.

De point-to-point-poorten versnellen het registratieproces (of het verlaten ervan). Het handmatig instellen van point-to-point=yes kan voordelig zijn voor niet-Ethernet-interfaces.

Eigenschappenreferentie

Submenu: /interface/bridge

Submenu: /interface/bridge/port

Het poortmenu maakt het mogelijk de applicant- en registrar-instellingen per poort te beheren.

Om de momenteel gedeclareerde en geregistreerde VLAN IDs te bewaken, gebruikt u het commando monitor.

[admin@MikroTik] > /interface/bridge/port/monitor [find interface=sfp-sfpplus1]
            interface: sfp-sfpplus1
               status: in-bridge
          port-number: 1
                 role: designated-port
            edge-port: no
  edge-port-discovery: yes
  point-to-point-port: yes
         external-fdb: no
         sending-rstp: yes
             learning: yes
           forwarding: yes
     actual-path-cost: 2000
     hw-offload-group: switch1
    declared-vlan-ids: 1,10,20-21
  registered-vlan-ids: 1,10,20,30-33

Submenu: /interface/bridge/vlan

Alle poorten die lid zijn van statische VLAN's of van dynamische untagged VLAN's die door de pvid-instelling van de poort zijn aangemaakt, worden als "fixed" behandeld. Dit betekent dat de registrar alle MRP-berichten negeert en geregistreerd (IN) blijft voor die VLAN's.

Wanneer een VLAN noch handmatig is geconfigureerd, noch is aangemaakt door de pvid-instelling van de poort, kunnen binnenkomende registraties op een bridge-poort die specifieke poort dynamisch aanwijzen als getagd VLAN-lid. Met de functie mvrp-forbidden kunt u een lijst maken van poorten die geen registratie mogen doen voor een specifiek VLAN ID.

VLAN's die statisch of dynamisch zijn, worden door de applicants aangekondigd, tenzij deze functionaliteit is uitgeschakeld via de mvrp-applicant-state van de poort of via de instelling mvrp-forbidden van het VLAN.

Submenu: /interface/bridge/vlan/mvrp

Het menu met MVRP-attributen kan worden gebruikt om interne MVRP-attribuutstatussen te bekijken, zoals gespecificeerd in IEEE 802.1Q-2011.

[admin@Mikrotik] /interface/bridge/vlan/mvrp/print where vlan-id=10
Columns: BRIDGE, PORT, VLAN-ID, REGISTRAR-STATE, APPLICANT-STATE, LAST-EVENT
 #  BRIDGE    PORT           VLAN-ID  REGISTRAR-STATE  APPLICANT-STATE  LAST-EVENT
 1  bridge67  sfp-sfpplus1        10  IN               Quiet Active     JoinIn    
 9  bridge67  sfp-sfpplus5        10  MT               Quiet Active     JoinEmpty 
17  bridge67  sfp-sfpplus9        10  MT               Quiet Active     JoinEmpty 
25  bridge67  sfp-sfpplus13       10  IN               Quiet Active     JoinIn 

Fast Forward

Fast Forward maakt het mogelijk pakketten sneller door te sturen onder speciale omstandigheden. Wanneer Fast Forward is ingeschakeld, kan de bridge pakketten nog sneller verwerken omdat meerdere bridge-gerelateerde controles, waaronder MAC-learning, kunnen worden overgeslagen. Hieronder vindt u een lijst met voorwaarden waaraan MOET worden voldaan om Fast Forward actief te laten zijn:

• Bij de bridge is fast-forward ingesteld op yes.
• De bridge heeft slechts 2 actieve poorten.
• Beide bridge-poorten ondersteunen Fast Path; Fast Path is actief op de poorten en globaal op de bridge.
• Hardwarematige offloading van de bridge is uitgeschakeld.
• VLAN-filtering op de bridge is uitgeschakeld.
• DHCP snooping op de bridge is uitgeschakeld.
• unknown-multicast-flood is ingesteld op yes.
• unknown-unicast-flood is ingesteld op yes.
• broadcast-flood is ingesteld op yes.
• Het MAC-adres van de bridge komt overeen met een MAC-adres van een van de slave-poorten van de bridge.
• horizon voor beide poorten is ingesteld op none.

Waarschuwing Fast Forward schakelt MAC learning uit; dit is met opzet zo ontworpen om snellere pakketdoorsturing te bereiken. MAC learning voorkomt dat verkeer meerdere interfaces overspoelt, maar MAC learning is niet nodig wanneer een pakket slechts via één interface kan worden verzonden.

Gevaar Fast Forward is uitgeschakeld wanneer hardware offloading is ingeschakeld. Hardware offloading kan volledige wire-speed-prestaties bereiken wanneer het actief is, omdat het de ingebouwde switchchip gebruikt (als uw apparaat die heeft). Fast forward gebruikt de CPU om pakketten door te sturen. Bij het vergelijken van doorvoerresultaten krijgt u het volgende beeld: hardware offloading > Fast Forward > Fast Path > Slow Path.

Het is mogelijk om te controleren hoeveel pakketten door Fast Forward zijn verwerkt:

[admin@MikroTik] /interface/bridge/settings> pr
              use-ip-firewall: no
     use-ip-firewall-for-vlan: no
    use-ip-firewall-for-pppoe: no
              allow-fast-path: yes
      bridge-fast-path-active: yes
     bridge-fast-path-packets: 0
       bridge-fast-path-bytes: 0
  bridge-fast-forward-packets: 16423
    bridge-fast-forward-bytes: 24864422

Waarschuwing Als pakketten door Fast Path worden verwerkt, dan is Fast Forward niet actief. Het aantal pakketten kan worden gebruikt als indicator of Fast Forward actief is of niet.

Sinds RouterOS 6.44 is het mogelijk de Fast Forward status te monitoren, bijvoorbeeld:

[admin@MikroTik] /interface/bridge/monitor bridge1 
                  state: enabled
    current-mac-address: B8:69:F4:C9:EE:D7
            root-bridge: yes
         root-bridge-id: 0x8000.B8:69:F4:C9:EE:D7
         root-path-cost: 0
              root-port: none
             port-count: 2
  designated-port-count: 2
           fast-forward: yes

Gevaar Het uit- of inschakelen van fast-forward schakelt tijdelijk alle bridgepoorten uit zodat de instellingen van kracht worden. Hier moet rekening mee worden gehouden bij het wijzigen van deze eigenschap in productieomgevingen, aangezien alle pakketten tijdelijk verworpen kunnen worden.

IGMP/MLD Snooping

De bridge ondersteunt IGMP/MLD snooping. Het reguleert multicaststromen en voorkomt multicast flooding op onnodige poorten. De instellingen staan in het bridge-menu en werken onafhankelijk op elke bridge-interface. De softwarematige implementatie werkt op alle apparaten met RouterOS, maar MikroTik-apparaten met een Marvell Prestera switch en met de switchchips 88E6393X, 88E6191X en 88E6190 ondersteunen IGMP/MLD snooping ook met hardware offloading. Zie voor meer details de handleiding over IGMP/MLD snooping.

DHCP Snooping en DHCP Option 82

DHCP Snooping en DHCP Option 82 worden ondersteund door de bridge. DHCP Snooping is een Layer2-beveiligingsfunctie die voorkomt dat ongeautoriseerde DHCP-servers kwaadaardige informatie aan gebruikers verstrekken. In RouterOS kunt u aangeven welke bridge-poorten vertrouwd zijn (waar zich een bekende DHCP-server bevindt en DHCP-berichten doorgestuurd moeten worden) en welke niet vertrouwd zijn (meestal gebruikt voor accesspoorten; ontvangen DHCP-serverberichten worden gedropt). DHCP Option 82 is aanvullende informatie (Agent Circuit ID en Agent Remote ID) die verstrekt wordt door apparaten met DHCP Snooping ingeschakeld en waarmee het apparaat zelf en de DHCP-clients geïdentificeerd kunnen worden.

In dit voorbeeld zijn SW1 en SW2 apparaten met DHCP Snooping en Option 82 ingeschakeld. Eerst moeten we een bridge aanmaken, interfaces toewijzen en trusted ports markeren. Gebruik deze commando's op SW1:

/interface/bridge
add name=bridge
/interface/bridge/port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2 trusted=yes

Voor SW2 is de configuratie vergelijkbaar, maar we moeten ether1 ook als trusted markeren, omdat deze interface DHCP-berichten gaat ontvangen waaraan Option 82 al is toegevoegd. U moet alle poorten als trusted markeren als ze DHCP-berichten met toegevoegde Option 82 gaan ontvangen, anders worden deze berichten gedropt. Daarnaast voegen we ether3 toe aan dezelfde bridge en laten we deze poort untrusted, waarbij we ons voorstellen dat er een ongeautoriseerde (rogue) DHCP-server is. Gebruik deze commando's op SW2:

/interface/bridge
add name=bridge
/interface/bridge/port
add bridge=bridge interface=ether1 trusted=yes
add bridge=bridge interface=ether2 trusted=yes
add bridge=bridge interface=ether3

Vervolgens moeten we DHCP Snooping inschakelen en Option 82 configureren. Vanaf RouterOS versie 7.23 is het mogelijk aangepaste Remote ID- en Circuit ID-waarden te configureren met vooraf gedefinieerde variabelen (zoals BRIDGEMAC, HOSTNAME, INTERFACE, VID). Zie de eigenschappen dhcp-agent-circuit-id en dhcp-agent-remote-id voor meer details. Als uw DHCP-server DHCP Option 82 niet ondersteunt of u geen Option 82-gerelateerd beleid toepast, is deze stap niet verplicht. In dit configuratievoorbeeld gebruiken we deze commando's op SW1 en SW2:

/interface/bridge
set [find where name="bridge"] dhcp-snooping=yes dhcp-agent-circuit-id="interface: \$(INTERFACE), vlan: \$(VID)" dhcp-agent-remote-id="ip: 192.168.88.1, identity: \$(HOSTNAME), mac: \$(BRIDGEMAC)"

Nu zullen beide apparaten analyseren welke DHCP-berichten op de bridgepoorten worden ontvangen. De SW1 is verantwoordelijk voor het toevoegen en verwijderen van DHCP Option 82. De SW2 zal voorkomen dat ongewenste DHCP-servers discovery-berichten ontvangen en zal kwaadaardige DHCP-serverberichten van ether3 droppen.

Waarschuwing Momenteel ondersteunen MikroTik-apparaten met een Marvell Prestera-switch en met 88E6393X-, 88E6191X- en 88E6190-switchchips volledig hardware offloaded DHCP Snooping en Option 82. Voor switches uit de CRS1xx- en CRS2xx-serie is het mogelijk om DHCP Snooping samen met VLAN-switching te gebruiken, maar dan moet u ervoor zorgen dat DHCP-pakketten met de juiste VLAN-tag worden verzonden met behulp van egress ACL-regels. Andere apparaten kunnen DHCP Snooping- en Option 82-functies samen met hardware offloading gebruiken, maar u moet ervoor zorgen dat er geen VLAN-gerelateerde configuratie op het apparaat is toegepast, anders werken DHCP Snooping en Option 82 mogelijk niet correct. Zie de sectie Bridge Hardware Offloading met de ondersteunde functies.

Info Vanaf RouterOS v7.17 wordt DHCP snooping ondersteund met hardware offloading op bonding-interfaces.

DHCP Snooping-bindingstabel

De DHCP snooping binding-database is een runtime-tabel die door een bridge wordt gegenereerd en bedoeld is om DHCP-leases op te slaan die worden verstrekt door DHCP-servers die op vertrouwde poorten zijn aangesloten. Elke invoer registreert het MAC-adres van de client, het toegekende IP-adres, de vervaltijd van de lease, het VLAN ID en de fysieke interface waarop de client is gezien. De bridge kan deze database gebruiken om de beveiliging te versterken. Wanneer een frame op een niet-vertrouwde poort binnenkomt, controleert de switch namelijk of het bron-MAC/IP-paar overeenkomt met een opgeslagen binding voordat het pakket wordt doorgestuurd, waardoor verkeer van rogue DHCP-servers of gespoofde hosts wordt geblokkeerd, adresdiefstalaanvallen worden voorkomen en functies zoals IP-Source-Guard en ARP-Inspection mogelijk worden.

De huidige implementatie van de DHCPv4 snooping binding table is gebouwd bovenop de bestaande /interface/bridge/host-tabel. De relevante DHCP-informatie wordt opgehaald uit DHCP-berichten die de bridge passeren.

Gevaar De bindingstabel van DHCP snooping wordt gewist telkens wanneer de configuratie van de bridge-interface wordt gewijzigd, inclusief het inschakelen van de functies arp-inspection of ip-source-guard. Als gevolg daarvan wordt IPv4- en ARP-verkeer op untrusted poorten onderbroken totdat clients hun DHCP-leases verkrijgen of vernieuwen. Om de bindingstabel sneller opnieuw te vullen, schakelt u de untrusted Ethernet-interfaces uit en weer in, of start u de switch opnieuw op.

De huidige status van de DHCP client wordt aangegeven door dhcpv4-status. De mogelijke statuswaarden zijn: searching, requesting, bound, renewing, rebinding, expired en relay-agent. De laatste kan alleen voorkomen wanneer er een DHCP request-bericht wordt ontvangen van een DHCP client die zich achter een relay agent bevindt.

De dhcpv4-ip toont de IP-adressen die door DHCP-servers zijn toegekend, terwijl de kolom dhcpv4-server-id de server-ID aangeeft. De kolom dhcpv4-expires-after toont de resterende tijd tot het einde van de huidige lease-periode die door de DHCP-server aan een client is verstrekt.

Wanneer VLAN-filtering op de bridge is ingeschakeld, wordt elke host niet alleen geidentificeerd aan de hand van zijn MAC-adres, maar aan de hand van een paar MAC - VLAN ID.

De actieve entries in de DHCP binding-tabel in Winbox:

De actieve entries in de DHCP binding-tabel in de console:

ARP Inspection en IP Source Guard

ARP Inspection en IP Source Guard zijn Layer 2-beveiligingsfuncties die de DHCP snooping binding table gebruiken om spoofing-aanvallen op adressen te voorkomen. ARP Inspection valideert ARP-pakketten aan de hand van de bindingdatabase en verwerpt alle pakketten die niet overeenkomen. IP Source Guard valideert het bron-IP-adres van IPv4-pakketten en verwerpt de pakketten die niet in een bindingvermelding voor de ingangspoort worden gevonden. Op trusted poorten worden alle ARP-pakketten en al het IP-verkeer zonder verificatie doorgestuurd.

Schakel eerst DHCP snooping in op de bridge en markeer de poorten die met uw DHCP-server zijn verbonden als trusted:

/interface/bridge/set [find name="bridge1"] dhcp-snooping=yes
/interface/bridge/port/set [find interface=ether1] trusted=yes

Schakel ARP-inspectie in en wijs vertrouwde ARP-poorten aan:

/interface/bridge/set [find name="bridge1"] arp-inspection=yes
/interface/bridge/port/set [find interface=ether1] trusted-arp=yes

IP Source Guard inschakelen:

/interface/bridge/set [find name="bridge1"] ip-source-guard=yes

Gevaar De bindingstabel van DHCP snooping wordt gewist telkens wanneer de configuratie van de bridge-interface wordt gewijzigd, inclusief het inschakelen van de functies arp-inspection of ip-source-guard. Als gevolg daarvan wordt IPv4- en ARP-verkeer op untrusted poorten onderbroken totdat clients hun DHCP-leases verkrijgen of vernieuwen. Om de bindingstabel sneller opnieuw te vullen, schakelt u de untrusted Ethernet-interfaces uit en weer in, of start u de switch opnieuw op.

Toon de bridge host table om te controleren of de DHCP-bindings worden geleerd:

/interface/bridge/host/print where dhcpv4-status

Controleer /interface/ethernet/switch/rule om te verifiëren dat de switch ACL-regels zijn toegepast (alleen ondersteund op Marvell Prestera switchchips):

[admin@MikroTik] > /interface/ethernet/switch/rule/print 
Flags: D - DYNAMIC
0 D switch=switch1 mac-protocol=ip protocol=udp src-port=67-68 dst-port=67-68 copy-to-cpu=no redirect-to-cpu=yes mirror=no
 
1 D switch=switch1 ports=ether2,ether3,ether4 mac-protocol=arp copy-to-cpu=no redirect-to-cpu=yes mirror=no
 
2 D ;;; IPSG (Pass Untrusted)
    switch=switch1 ports=ether2 src-mac-address=D6:3F:38:20:8D:2B/FF:FF:FF:FF:FF:FF mac-protocol=ip src-address=192.168.88.8/255.255.255.255 copy-to-cpu=no redirect-to-cpu=no mirror=no
 
3 D ;;; IPSG (Pass Untrusted)
    switch=switch1 ports=ether3 src-mac-address=6C:3B:6B:EB:76:AA/FF:FF:FF:FF:FF:FF mac-protocol=ip src-address=192.168.88.9/255.255.255.255 copy-to-cpu=no redirect-to-cpu=no mirror=no
 
4 D ;;; IPSG (Drop Untrusted)
    switch=switch1 ports=ether2,ether3,ether4 mac-protocol=ip copy-to-cpu=no redirect-to-cpu=no mirror=no new-dst-ports=""

Zoek naar bridge,warning-logregels om geblokkeerde pakketten te detecteren:

/log/print where topics~"bridge" and topics~"warning"

2026-07-26 12:08:29 bridge,warning ether2: dropped IP packet on untrusted port - MAC/IP does not match binding table entry (IP=192.168.88.55, MAC=6c:3b:6b:eb:76:aa)

2026-07-26 13:55:02 bridge,warning ether2: dropped ARP packet on untrusted port - unknown MAC/IP combination (src IP=192.168.88.55, MAC=6c:3b:6b:eb:76:aa)

DHCPv6 Snooping / DHCPv6 Shield

DHCPv6 Snooping is een Layer2-beveiligingsfunctie die voorkomt dat ongeautoriseerde DHCPv6-servers kwaadaardige informatie aan gebruikers verstrekken. In RouterOS kunt u aangeven welke bridge-poorten vertrouwd zijn (waar zich de bekende DHCPv6-server bevindt en DHCPv6-berichten doorgestuurd moeten worden) en welke niet vertrouwd zijn (meestal gebruikt voor accesspoorten; ontvangen DHCPv6-serverberichten worden gedropt, wat feitelijk DHCPv6-Shield implementeert).

DHCPv6 Option 18 (Interface-Id) en Option 37 (Remote-Id) zijn aanvullende informatie die wordt geleverd door apparaten met DHCPv6 Snooping ingeschakeld, waarmee het apparaat zelf en DHCPv6-clients kunnen worden geïdentificeerd.

IPv6 biedt een fijnmaziger aanpak en flexibiliteit bij het proces van de DHCPv6 Relay-agent. Functioneel dienen deze precies hetzelfde doel als Option 82 van IPv4: Option 18 fungeert als de Circuit ID (die de specifieke poort/VLAN identificeert waarop de client is aangesloten), en Option 37 fungeert als de Remote ID (die de relay-agent of de switchhardware zelf identificeert).

• Option 18 - identificeert de specifieke interface (poort) waarop het bericht van de client is ontvangen. Het zorgt ervoor dat de server precies weet waar het verzoek doorheen is gekomen, zodat de juiste policy kan worden toegepast.
• Option 37 - identificeert de relay agent (de switch of router) zelf. Hij bevat een unieke caller ID (zoals de DUID, DHCP Unique Identifier). Hij vertelt de server welk specifiek apparaat in het netwerk met hem communiceert.

RA Guard

De RA guard-functie is bedoeld om IPv6-pakketten met router advertisement (RA) berichten te verwijderen wanneer deze binnenkomen op bridgepoorten die door de gebruiker als untrusted zijn aangemerkt, waardoor mogelijke aanvallen met valse RA-berichten of onbedoelde netwerkconfiguratiefouten voorkomen kunnen worden. Wanneer deze functie is ingeschakeld, kan elke bridgepoort als trusted of untrusted worden ingesteld (standaard zijn alle bridgepoorten ingesteld als RA untrusted).

Hier ziet u het netwerkschema en het kernprincipe achter IPv6 RA Guard (Router Advertisement Guard).

Het probleem: waarom is dit nodig?

In IPv6 gebruiken apparaten ICMPv6 om zichzelf automatisch te configureren.

Router Advertisements (Type 134): Routers verzenden deze berichten via broadcast om hosts te vertellen: "Ik ben de gateway, en hier is uw netwerkprefix."

De dreiging: als een gebruiker per ongeluk een consumentenrouter (zoals een thuis-wifi-router) aansluit of een kwaadwillende een tool (zoals Rogue RA) start op een access-poort, gaat dat apparaat RA's uitzenden.

Het resultaat: andere hosts in het netwerk configureren hun IPv6-adressen automatisch op basis van het frauduleuze apparaat en stellen dit apparaat in als hun default gateway. Dit veroorzaakt een Man-in-the-Middle-aanval of een volledige denial of service.

Hier ziet u het netwerkschema en het kernprincipe achter IPv6 RA Guard (Router Advertisement Guard).

Het kernprincipe: "Trust vs. Untrust"

Het fundamentele principe van IPv6 RA Guard is logisch identiek aan DHCP Snooping in IPv4. Het creëert een beveiligingsgrens binnen de Layer 2 switch-infrastructuur door switchpoorten in twee rollen in te delen:

• Trusted Ports: poorten die zijn verbonden met legitieme, geautoriseerde IPv6-routers. Deze poorten mogen Router Advertisement (RA)-pakketten verzenden.
• Untrusted Ports: poorten die verbonden zijn met eindgebruikershosts. Deze poorten worden geblokkeerd voor het verzenden van RA-pakketten.

Het parseerproces van pakketten

Bij poorten die niet als RA Trusted zijn geconfigureerd, doorloopt de RA Guard-parser de keten van extension headers totdat een header wordt aangetroffen die geen extension header is. Het parseerproces en de daaropvolgende acties worden bepaald door de volgende regels:

Beëindiging van de transportlaag: Als de parser een geldige transportlaagheader tegenkomt, zoals TCP, UDP, ESP, RSVP of een ingekapselde IPv4/IPv6-header, stopt het parsen en wordt het pakket doorgestuurd (met inachtneming van de standaard bridge-controles).

• Drop Conditions - Het pakket wordt verworpen als:

1. Het bevat geen transportlaag-header.
2. De laatste extension header in de keten specificeert geen NO_NEXT_HEADER (59) in zijn "Next Header" veld.
3. Als blijkt dat het ICMP-berichttype 134 is, wordt het pakket verworpen.

• Omgaan met fragmentatie: deze parseerregels gelden uitsluitend voor het eerste fragment van gefragmenteerde IPv6-pakketten. Volgende fragmenten worden ongeacht hun inhoud doorgestuurd, omdat ze niet de protocolheaders bevatten die nodig zijn voor RA-identificatie.

Bridge Firewall

De bridge firewall implementeert pakketfiltering en biedt daarmee beveiligingsfuncties waarmee de datastroom naar, van en door de bridge wordt beheerd.

Het packet flow-diagram laat zien hoe pakketten door de router worden verwerkt. Het is mogelijk om bridgeverkeer via de regels van /ip/firewall/filter te laten lopen (zie de bridge-instellingen).

Er zijn twee bridge firewall-tabellen:

• filter - bridge-firewall met drie voorgedefinieerde chains:
  • input - filtert pakketten waarvan de bestemming de bridge is (inclusief de pakketten die gerouteerd zullen worden, omdat die toch aan het MAC-adres van de bridge zijn geadresseerd).
  • output - filtert pakketten die van de bridge komen (inclusief de pakketten die normaal zijn gerouteerd).
  • forward - filtert pakketten die gebridged moeten worden (let op: deze chain wordt niet toegepast op pakketten die door de router gerouteerd moeten worden, alleen op pakketten die tussen de poorten van dezelfde bridge passeren).
• nat - bridge network address translation biedt manieren om de bron-/bestemmings-MAC-adressen te wijzigen van pakketten die een bridge passeren. Heeft twee ingebouwde chains:
  • srcnat - wordt gebruikt om een host of een netwerk te "verbergen" achter een ander MAC-adres. Deze chain wordt toegepast op pakketten die de router via een gebridgede interface verlaten.
  • dstnat - wordt gebruikt om bepaalde pakketten naar andere bestemmingen om te leiden.

Je kunt packet marks in de bridge firewall (filter en NAT) plaatsen, die dezelfde zijn als de packet marks in de IP firewall die worden geconfigureerd met '/ip/firewall/mangle'. Op deze manier kunnen packet marks die door de bridge firewall zijn geplaatst in de 'IP firewall' worden gebruikt, en omgekeerd.

De algemene eigenschappen van de bridge firewall worden in deze sectie beschreven. Sommige parameters die verschillen tussen nat- en filterregels worden in verdere secties beschreven.

Submenu: /interface/bridge/filter, /interface/bridge/nat

Voetnoten:

• STP-matchers zijn alleen geldig als het bestemmings-MAC-adres 01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF is (Bridge Group-adres); bovendien moet STP ingeschakeld zijn.

• ARP-matchers zijn alleen geldig als mac-protocol arp of rarp is.

• VLAN-matchers zijn alleen geldig voor de ethernetprotocollen 0x8100 en 0x88a8.

• Matchers die betrekking hebben op IP of IPv6 zijn alleen geldig als mac-protocol is ingesteld op ip of ipv6.

• 802.3-matchers worden alleen geraadpleegd als het daadwerkelijke frame voldoet aan de standaarden IEEE 802.2 en IEEE 802.3. Deze matchers worden genegeerd voor andere pakketten.

Pakketfilter van de bridge

Deze sectie beschrijft specifieke bridge filter-opties.

Submenu: /interface/bridge/filter

Bridge NAT

Deze sectie beschrijft specifieke bridge NAT-opties.

Submenu: /interface/bridge/nat

Zie ook

• Switches uit de CRS1xx/2xx-serie
• Functies van de Marvell Prestera switch chip
• Switchchip-functies
• MTU op RouterBOARD
• Layer2-misconfiguratie
• Bridge VLAN-tabel