Mikrotik – Interface – Bridge

Mikrotik Interface Bridge – Notes und Warnings

/interface bridge

Ethernet-ähnliche Netzwerke (Ethernet, Ethernet over IP, IEEE 802.11 im ap-Bridge- oder Bridge-Modus, WDS, VLAN) können über MAC-Bridges miteinander verbunden werden. Die Bridge-Funktion ermöglicht die Verbindung von Hosts, die an separate LANs angeschlossen sind (mit EoIP können auch geografisch verteilte Netzwerke überbrückt werden, wenn zwischen ihnen irgendeine Art von IP-Netzwerkverbindung besteht), so als wären sie an ein einzelnes LAN angeschlossen. Da Bridges transparent sind, erscheinen sie nicht in der Traceroute-Liste, und kein Dienstprogramm kann zwischen einem Host, der in einem LAN arbeitet, und einem Host, der in einem anderen LAN arbeitet, unterscheiden, wenn diese LANs überbrückt werden (je nachdem, wie die LANs miteinander verbunden sind, können Latenzzeit und Datenrate zwischen den Hosts variieren).

In komplexen Topologien können (gewollt oder ungewollt) Netzwerkschleifen entstehen. Ohne spezielle Behandlung würden Schleifen ein normales Funktionieren des Netzwerks verhindern, da sie zu einer lawinenartigen Paketvermehrung führen würden. Jede Brücke führt einen Algorithmus aus, der berechnet, wie die Schleife verhindert werden kann. STP und RSTP ermöglichen es den Brücken, miteinander zu kommunizieren, so dass sie eine schleifenfreie Topologie aushandeln können. Alle anderen alternativen Verbindungen, die sonst Schleifen bilden würden, werden auf Standby geschaltet, so dass bei Ausfall der Hauptverbindung eine andere Verbindung an deren Stelle treten kann. Dieser Algorithmus tauscht periodisch Konfigurationsnachrichten (BPDU – Bridge Protocol Data Unit) aus, so dass alle Brücken mit den neuesten Informationen über Änderungen in der Netzwerktopologie aktualisiert werden. (R)STP wählt eine Root-Bridge aus, die für die Neukonfiguration des Netzwerks verantwortlich ist, z.B. für das Blockieren und Öffnen von Ports auf anderen Bridges. Die Root-Bridge ist die Bridge mit der niedrigsten Bridge-ID.

Notes – Hinweise

Spanning Tree Protocol

  • Note: By the IEEE 802.1ad standard the BPDUs from bridges that comply with IEEE 802.1Q are not compatible with IEEE 802.1ad bridges, this means that the same bridge VLAN protocol should be used across all bridges in a single Layer2 domain, otherwise (R/M)STP will not function properly.

Per port STP

Bridge Settings

  • Note: In case you want to assign Simple Queues (Simple QoS) or global Queue Trees to traffic that is being forwarded by a bridge, then you need to enable the use-ip-firewall property. Without using this property the bridge traffic will never reach the postrouting chain, Simple Queues and global Queue Trees are working in the postrouting chain. To assign Simple Queues or global Queue Trees for VLAN or PPPoE traffic in a bridge you should enable appropriate properties as well.

Port settings:

  • unknown-multicast-flood (yes | no; Default: yes)
    • Note that local multicast addresses (224.0.0.0/24) are not flooded when unknown-multicast-flood is disabled, as a result some protocols that rely on local multicast addresses might not work properly, such protocols are RIPv2m OSPF, mDNS, VRRP and others. Some protocols do send a IGMP join request and therefore are compatible with IGMP Snooping, some OSPF implementations are compatible with RFC1584, RouterOS OSPF implementation is not compatible with IGMP Snooping. This property should only be used when igmp-snooping is set to yes.

Interface lists:

  • Note: The second parameter when moving interface lists is considered as “before id”, the second parameter specifies before which interface list should be the selected interface list moved. When moving first interface list in place of the second interface list, then the command will have no effect since the first list will be moved before the second list, which is the current state either way.

Bridge Hardware Offloading

  • Note: When upgrading from previous versions (before RouterOS v6.41), the old master-port configuration is automatically converted to the new Bridge Hardware Offloading configuration. When downgrading from newer versions (RouterOS v6.41 and newer) to older versions (before RouterOS v6.41) the configuration is not converted back, a bridge without hardware offloading will exist instead, in such a case you need to reconfigure your device to use the old master-port configuration.
  • NOTES:
    1. Feature will not work properly in VLAN switching setups. It is possible to correctly snoop DHCP packets only for a single VLAN, but this requires that these DHCP messages get tagged with the correct VLAN tag using an ACL rule, for example, /interface ethernet switch acl add dst-l3-port=67-68 ip-protocol=udp mac-protocol=ip new-customer-vid=10 src-ports=switch1-cpu. DHCP Option 82 will not contain any information regarding VLAN-ID.
    2. Feature will not work properly in VLAN switching setups.
  • Note: When upgrading from older versions (before RouterOS v6.41), only the master-port configuration is converted. For each master-port a bridge will be created. VLAN configuration is not converted and should not be changed, check the Basic VLAN switching guide to be sure how VLAN switching should be configured for your device.

Example:

  • Note: Port switching in RouterOS v6.41 and newer is done using the bridge configuration. Prior to RouterOS v6.41 port switching was done using the master-port property, for more details check the Master-port page.

Bridge VLAN Filtering

  • Note: Currently only CRS3xx series devices are capable of using bridge VLAN filtering and hardware offloading at the same time, other devices will not be able to use the benefits of a built-in switch chip when bridge VLAN filtering is enabled. Other devices should be configured according to the method described in the Basic VLAN switching guide. If an improper configuration method is used, your device can cause throughput issues in your network.
  • Note: Make sure you have added all needed interfaces to the bridge VLAN table when using bridge VLAN filtering. For routing functions to work properly on the same device through ports that use bridge VLAN filtering, you will need to allow access to the CPU from those ports, this can be done by adding the bridge interface itself to the VLAN table, for tagged traffic you will need to add the bridge interface as a tagged port and create a VLAN interface on the bridge interface. Examples can be found at the Management port section.

VLAN Example #1 (Trunk and Access Ports)

  • Note: Improperly configured bridge VLAN filtering can cause security issues, make sure you fully understand how Bridge VLAN table works before deploying your device into production environments.

Management access configuration

  • Note: If connection to the router/switch through an IP address is not required, then steps adding this IP address can be skipped since connection to the router/switch through Layer2 protocols (e.g. MAC-telnet) will be working either way.

VLAN Tunneling (Q-in-Q)

  • Note: Currently only CRS3xx series switches are capable of hardware offloading VLAN filtering based on SVID (Service VLAN ID) tag when ether-type is set to 0x88a8.

Fast Forward

  • Note: Fast Forward disables MAC learning, this is by design to achieve faster packet forwarding. MAC learning prevents traffic from flooding multiple interfaces, but MAC learning is not needed when a packet can only be sent out trough just one interface.
  • Note: If packets are processed by Fast Path, then Fast Forward is not active. Packet count can be used as an indicator whether Fast Forward is active or not.

IGMP Snooping

  • Note: IGMP membership reports are only forwarded to ports that are connected to a multicast router or to another IGMP Snooping enabled bridge. If no port is marked as a multicast-router then IGMP membership reports will not be forwarded to any port.
  • Note: CRS series switches are capable of running IGMP Snooping along with hardware offloading, but CRS1xx and CRS2xx series switches will not work properly with IGMP Snooping if VLAN filtering is configured on the switch chip. It is possible to use IGMP Snooping along with VLAN filtering, but then you must make sure that IGMP packets are sent out with the correct VLAN tag using egress ACL rules.

DHCP Snooping and DHCP Option 82

  • Note: Currently only CRS3xx devices fully support hardware DHCP Snooping and Option 82. For CRS1xx and CRS2xx series switches it is possible to use DHCP Snooping along with VLAN switching, but then you must make sure that DHCP packets are sent out with the correct VLAN tag using egress ACL rules. Other devices are capable of using DHCP Snooping and Option 82 features along with hardware offloading, but you must make sure that there is no VLAN related configuration applied on the device, otherwise DHCP Snooping and Option 82 might not work properly. See Bridge Hardware Offloading section with supported features.

Bridge Firewall:

  • filter – bridge firewall with three predefined chains:
    • input – filters packets, where the destination is the bridge (including those packets that will be routed, as they are destined to the bridge MAC address anyway)
    • output – filters packets, which come from the bridge (including those packets that has been routed normally)
    • forward – filters packets, which are to be bridged (note: this chain is not applied to the packets that should be routed through the router, just to those that are traversing between the ports of the same bridge)

Properties – Notes:

  • Notes

    • STP matchers are only valid if destination MAC address is 01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF (Bridge Group address), also stp should be enabled.
    • ARP matchers are only valid if mac-protocol is arp or rarp
    • VLAN matchers are only valid for 0x8100 or 0x88a8 ethernet protocols
    • IP or IPv6 related matchers are only valid if mac-protocol is either set to ip or ipv6
    • 802.3 matchers are only consulted if the actual frame is compliant with IEEE 802.2 and IEEE 802.3 standards (note: it is not the industry-standard Ethernet frame format used in most networks worldwide!). These matchers are ignored for other packets.

WARNINGS

Bridge Interface Setup – Properties

  • Warning: Changing certain properties can cause the bridge to temporarily disable all ports. This must be taken into account whenever changing such properties on production environments since it can cause all packets to be temporarily dropped. Such properties include vlan-filteringprotocol-modeigmp-snoopingfast-forward and others.

Spanning Tree Protocol

  • Warning: In RouterOS it is possible to set any value for bridge priority between 0 and 65535, the IEEE 802.1W standard states that the bridge priority must be in steps of 4096. This can cause incompatibility issues between devices that does not support such values. To avoid compatibility issues, it is recommended to use only these priorities: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, 61440

Per port STP

  • Warning: Be careful when changing the default (R/M)STP functionality, make sure you understand the working principles of STP and BPDUs. Misconfigured (R/M)STP can cause unexpected behaviour.
  • Warning: If you intend to drop received BPDUs on a port, then make sure to prevent BPDUs from being sent out from the interface that this port is connected to. A root bridge always sends out BPDUs and under normal conditions is waiting for a more superior BPDU (from a bridge with a lower bridge ID), but the bridge must temporarily disable the new root-port when transitioning from a root bridge to designated bridge. If you have blocked BPDUs only on one side, then a port will flap continuously.

Bridge Hardware Offloading

  • Warning: Certain bridge and Ethernet port properties are directly related to switch chip settings, changing such properties can trigger a switch chip reset, that will temporarily disable all Ethernet ports that are on the switch chip for the settings to have an effect, this must be taken into account whenever changing properties on production environments. Such properties are DHCP Snooping, IGMP Snooping, VLAN filtering, L2MTU, Flow Control and others (exact settings that can trigger a switch chip reset depends on the device’s model).

Bridge Vlan Filtering

  • Warning: The vlan-ids parameter can be used to specify a set or range of VLANs, but specifying multiple VLANs in a single bridge VLAN table entry should only be used for ports that are trunk ports. In case multiple VLANs are specified for access ports, then tagged packets might get sent out as untagged packets through the wrong access port, regardless of the PVID value.
  • Warning: When allowing access to the CPU, you are allowing access from a certain port to the actual router/switch, this is not always desirable. Make sure you implement proper firewall filter rules to secure your device when access to the CPU is allowed from a certain VLAN ID and port, use firewall filter rules to allow access to only certain services.

VLAN Example #2 (Trunk and Hybrid Ports)

  • Warning: You don’t have to add access ports as untagged ports, they will be added dynamically as untagged port with the VLAN ID that is specified in PVID, you can specify just the trunk port as tagged port. All ports that have the same PVID set will be added as untagged ports in a single entry. You must take into account that the bridge itself is a port and it also has a PVID value, this means that the bridge port also will be added as untagged port for the ports that have the same PVID. You can circumvent this behaviour by either setting different PVID on all ports (even the trunk port and bridge itself), or to use frame-type set to accept-only-vlan-tagged.

VLAN Tunneling (Q-In-Q)

  • Warning: By enabling vlan-filtering you will be filtering out traffic destined to the CPU, before enabling VLAN filtering you should make sure that you set up a Management port. The difference between using different EtherTypes is that you must use a Service VLAN interface. Service VLAN interfaces can be created as regular VLAN interface, but the use-service-tag parameter toggles if the interface will use Service VLAN tag.
  • Warning: When ether-type=0x8100, then the bridge checks the outer VLAN tag if it is using EtherType 0x8100. If the bridge receives a packet with an outer tag that has a different EtherType, it will mark the packet as untagged. Since RouterOS only checks the outer tag of a packet, it is not possible to filter 802.1Q packets when 802.1ad protocol is used.
  • Warning: By enabling vlan-filtering you will be filtering out traffic destined to the CPU, before enabling VLAN filtering you should make sure that you set up a Management port.

Fast Forward

  • Warning: Fast Forward is disabled when hardware offloading is enabled. Hardware offloading can achieve full write-speed performance when it is active since it will use the built-in switch chip (if such exists on your device), fast forward uses the CPU to forward packets. When comparing throughput results, you would get such results: Hardware offloading > Fast Forward > Fast Path > Slow Path.
  • Warning: Disabling or enabling fast-forward will temporarily disable all bridge ports for settings to take effect. This must be taken into account whenever changing this property on production environments since it can cause all packets to be temporarily dropped.
Dieser Beitrag wurde unter Bridge abgelegt und mit , , , , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.