Manual:Spanning Tree Protocol

Spanning Tree Protocol

RouterOS is capable of running bridge interfaces with (R/M)STP support in order to create loop-free and Layer2 redundant environment. It is always recommended to manually set up each bridge priority, port priority and port path cost to ensure proper Layer2 functionality at all times. Leaving STP related values to defaults are acceptable for a network that consists of of 1 to 2 bridges running with (R/M)STP enabled, but it is highly recommended to manually set these values for larger networks. Since STP elects a root bridge and root ports by checking STP related values from bridges over the network, then leaving STP settings to automatic may elect a undesired root bridge and root ports and in case of a hardware failure can result in an inaccessible network.

You can check the STP status of a bridge by using the /interface bridge monitor command, for example:

/interface bridge monitor bridge
                  state: enabled
    current-mac-address: 64:D1:54:D9:27:E6
            root-bridge: yes
         root-bridge-id: 0x3E8.64:D1:54:D9:27:E6
         root-path-cost: 0
              root-port: none
             port-count: 5
  designated-port-count: 5

You can check the STP status of a bridge port by using the /interface bridge port monitor command, for example:

/interface bridge port monitor 2
               interface: ether3
                  status: in-bridge
             port-number: 3
                    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
          root-path-cost: 10
       designated-bridge: 0x3E8.64:D1:54:D9:27:E6
         designated-cost: 0
  designated-port-number: 4
        hw-offload-group: switch1

Note that root-bridge-id consists of the bridge priority and the bridge's MAC address, for non-root bridges the root bridge will be shown as designated-bridge. One port can have one role in a STP enabled network, below is a list of possible port roles:

• root-port - port that is facing towards the root bridge and will be used to forward traffic from/to the root bridge.
• alternate-port - port that is facing towards root bridge, but is not going to forward traffic (a backup for root port).
• backup-port - port that is facing away from the root bridge, but is not going to forward traffic (a backup for non-root port).
• designated-port - port that is facing away from the root bridge and is going to forward traffic .
• disabled-port - disabled or inactive port.

STP and RSTP

STP and Rapid STP are used very widely across many networks, but almost all networks have switched over using only RSTP since of its benefits. STP is a very old protocol and has a convergence time (the time needed to fully learn network topology changes and to continue properly forwarding traffic) even up to 50 seconds, which was acceptable for 1980s when it was invented. RSTP has a lot smaller convergence time, a few seconds or even a few milliseconds), which is acceptable for nowadays network requirements. It is recommended to use RSTP instead of STP since it is a lot faster and is also backwards compatible with STP. One of the reason why RSTP is faster is because of reduced possible port states, below is a list of possible STP port states:

• Forwarding - port participates in traffic forwarding and is learning MAC addresses, is receiving BPDUs.
• Listening - port does not participate in traffic forwarding and is not learning MAC addresses, is receiving BPDUs.
• Learning - port does not participate in traffic forwarding, but is learning MAC addresses.
• Blocking - port is blocked since it is causing loops, but is receiving BPDUs.
• Disabled - port is disabled or inactive.

In RSTP the disabled, listening and blocking port states are replaced with just one state called the Discarding state:

• Forwarding - port participates in traffic forwarding and is learning MAC addresses, is receiving BPDUs.
• Learning - port does not participate in traffic forwarding, but is learning MAC addresses.
• Discarding - port does not participate in traffic forwarding and is not learning MAC addresses, is receiving BPDUs.

In STP connectivity between bridges is determined by sending and receiving BPDUs between neighbour bridges. Designated ports are sending BPDUs to root ports. If a BPDU is not received 3 times the HelloTime in a row, then connection is considered as unavailable and network topology convergence will commence. It is possible for STP to reduce the convergence time in certain scenarios by reducing the forward-delay timer, which is responsible for how long can port be in the learning/listening state.

Default values

When creating a bridge or adding a port to a bridge the following are the default values that are assigned by RouterOS:

• Default bridge priority: 32768 / 0x8000
• Default bridge port path cost: 10
• Default bridge port priority: 0x80
• BPDU message age: 1
• HelloTime: 2
• Default max message age: 20

RouterOS does not change port path cost based on the link speed, for 10M, 100M, 1000M and 10000M link speeds the default path cost value when a port is added to a bridge is always 10. The age of a BPDU is determined by how many bridges has the BPDU passed times the message age, since RouterOS uses 1 as the message age, then the BPDU packet can pass as many bridges as specified in the max-message-age parameter. By default this value is set to 20, this means that after the 20th bridge the BPDU packet will be discarded and the next bridge will become a root bridge, note that if max-message-age=20on is set, then it is hard to predict which ports will be the designated port on the 21st bridge and may result in traffic not being able to be forwarded properly. In case bridge filter rules are used, make sure you allow packets with DST-MAC address 01:00:0C:CC:CC:CC since these packets carry BPDUs that are crucial for STP to work properly.

Election process

To properly configure STP in your network you need to understand the election process and which parameters are involved in which order. In RouterOS the root bridge will be elected based on the smallest priority and the smallest MAC address in this particular order:

1. Bridge priority (lowest)
2. Bridge MAC address (lowest)

In RouterOS root ports are elected based on lowest port path cost, lowest port priority and lowest bridge port ID in this particular order:

1. Port path cost (lowest)
2. Port priority (lowest)
3. Bridge port ID (lowest)

Note: Make sure you are using path cost and priority on the right ports. For example, setting path cost on a ports that are in a root bridge has no effect, only port priority has effect on them. Path cost has effect on ports that are facing towards the root bridge and port priority has effect on ports that are facing away from the root bridge.

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 incompatibility 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

Note: When electing a root port the path cost will be checked first. If the path cost for multiple paths is the same, then port priority is checked. If port priority is the same, then bridge port ID is checked, port with the lowest values will be elected as a root port. Make sure you take into account the election process when designing your network with STP enabled.

Example

Topology of a STP enabled network

In this example we want to ensure Layer2 redundancy for connections from ServerA to ServerB. If a port is connected to a device that is not a bridge and not running (R)STP, then this port is considered as an edge port, in this case ServerA and ServerB is connected to an edge port. This is possible by using STP in a network. Below are configuration examples for each switch.

• Configuration for SW1:

/interface bridge
add name=bridge priority=0x1000
/interface bridge port
add bridge=bridge interface=ether1 priority=0x60
add bridge=bridge interface=ether2 priority=0x50
add bridge=bridge interface=ether3 priority=0x40
add bridge=bridge interface=ether4 priority=0x30
add bridge=bridge interface=ether5

• Configuration for SW2:

/interface bridge
add name=bridge priority=0x2000
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3

• Configuration for SW3:

/interface bridge
add name=bridge priority=0x3000
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3

• Configuration for SW4:

/interface bridge
add name=bridge priority=0x4000
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2 path-cost=20
add bridge=bridge interface=ether3

In this example SW1 is the root bridge since it has the lowest bridge priority. SW2 and SW3 has ether1,ether2 connected to the root bridge and ether3 is connected to SW4. When all switches are working properly, the traffic will be flowing from ServerA through SW1_ether2, through SW2, through SW4 to ServerB. In case of SW1 failure, the SW2 becomes the root bridge because of the next lowest priority. Below is a list of ports and their role for each switch:

• root-port - SW2_ether2, SW3_ether2, SW4_ether1
• alternate-port - SW2_ether1, SW3_ether1, SW4_ether2
• designated-port - SW1_ether1, SW1_ether2, SW1_ether3, SW1_ether4, SW1_ether5, SW2_ether3, SW2_ether3, SW4_ether3

Note: By the 802.1W recommendations, you should use bridge priorities in steps of 4096. To set a recommended priority it is more convenient to use hexadecimal notation, for example, 0 is 0x0000, 4096 is 0x1000, 8192 is 0x2000 and so on (0..F).

http://en.wikipedia.org/wiki/Spanning_Tree_Protocol

Multiple Spanning Tree Protocol

Since RouterOS v6.41rc1 it is possible to enable Multiple Spanning Tree Protocol (MSTP) on a bridge interface to ensure loop-free topology across multiple VLANs, MSTP can also provide Layer2 redundancy and can be used as a load balancing technique for VLANs since it has the ability to have different paths across different VLANs. MSTP is operating very similarly to (R)STP and many concepts from (R)STP can be applied to MSTP and it is highly recommended to understand the principles behind (R)STP before using MSTP, but there are some differences that must be taken into account when designing a MSTP enabled network.

In case (R)STP is used, the BPDUs are sent across all physical interfaces in a bridge to determine loops and stop ports from being able to forward traffic, if it causes a loop. In case there is a loop inside a certain VLAN, (R)STP might not be able to detect it. Some STP variants solve this problem by running a STP instance on every single VLAN (PVST), but this has been proven to inefficient and some STP variants solve this problem by running a single STP instance across all VLANs (CST), but it lacks the possibility to do load balancing for each VLAN or VLAN group. MSTP tends to solve both problems by using MST instances that can define a group of VLANs (VLAN mapping) that can be used for load balancing and redundancy, this means that each VLAN group can have a different root bridge and a different path. Note that it is beneficial to group multiple VLANs in a single instance to reduce the amount of CPU cycles for each network topology change.

Warning: In RouterOS with MSTP enabled the bridge priority is the CIST's root bridge priority, as stated in the IEEE 802.1Q standard the bridge priority must be in steps of 4096, the 12 lowest bits are ignored. These are valid bridge priorities: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, 61440. When setting an invalid bridge priority, RouterOS will warn you about it and trunk the value to a valid value, but will save the original value in the configuration since invalid bridge priority values can still be used in (R)STP between devices running RouterOS, though it is recommended to use valid a bridge priority instead.

MSTP Regions

MSTP works in groups called regions, for each region there will be a regional root bridge and between regions there will be a root bridge elected. MSTP will use Internal Spanning Tree (IST) to build the network topology inside a region and Common Spanning Tree (CST) outside a region to build the network topology between multiple regions, MSTP combines these two protocols into Common and Internal Spanning Tree (CIST), which holds information about topology inside a region and between regions. From CST's perspective a region will seemingly be as a single virtual bridge, because of this MSTP is considered very scalable for large networks. In order for bridges to be in the same region, their configuration must match, BPDUs will not include VLAN mappings since they can be large, rather a computed hash is being transmitted. If a bridge receives a BPDU through a port and the configuration does not match, then MSTP will consider that port as a boundary port and that it can be used to reach other regions. Below is a list of parameters that need to match in order for MSTP to consider a BPDU from the same region:

• Region name
• Region revision
• VLAN mappings to instance IDs (computed hash)

It is possible to create MSTP enabled network without regions, though to be able to do load balancing per VLAN group it is required for a bridge to receive a BPDU from a bridge that is connected to it with the same parameters mentioned above. In RouterOS the default region name is empty and region revision is 0, which are valid values, but you must make sure that they match in order to get multiple bridges in a single MSTP region. A region cannot exist if their bridges are scattered over the network, these bridges must be connected at least in one way, in which they can send and receive BPDUs without leaving the region, for example, if a bridge with different region related parameters is between two bridges that have the same region related parameters, then there will exist at least 3 different MSTP regions.

Topology of a MSTP enabled network with boundary ports

The downside of running every single bridge in a single MSTP region is the excess CPU cycles. In comparison, PVST(+) creates a Spanning Tree Instance for each VLAN ID that exists on the network, since there will be very limited paths that can exist in a network, then this approach creates a lot of overhead and unnecessary CPU cycles, this also means that this approach does not scale very well and can overload switches with not very powerful CPUs. MSTP solves this problem by dividing the network into MSTP regions, where each bridge inside this region will exchange and process information about VLANs that exist inside the same region, but will run a single instance of Spanning Tree Protocol in background to maintain the network topology between regions. This approach has been proven to be much more effective and much more scalable, this means that regions should be used for larger networks to reduce CPU cycles.

In regions you can define MST Instances, which are used to configure load balancing per VLAN group and to elect the regional root bridge. It is worth mentioning that in each region there exists a pre-defined MST Instance, in most documentations this is called as MSTI0· This MST Instance is considered as the default MST Instance, there are certain parameters that apply to this special MST Instance. When traffic is passing through a MSTP enabled bridge, MSTP will look for a MST Instance that has a matching VLAN mapping, but if a VLAN mapping does not exists for a certain VLAN ID, then traffic will fall under MSTI0.

Note: Since MSTP requires VLAN filtering on the bridge interface to be enabled, then make sure that you have allowed all required VLAN IDs in /interface bridge vlan, otherwise the traffic will not be forwarded and it might seem as MSTP misconfigured, although this is a VLAN filtering misconfiguration.

Election process

The election process in MSTP can be divided into two sections, intra region and inter region. For MSTP to work properly there will always need to be a regional root, that is the root bridge inside a region, and a CIST root, that is the root bridge between regions. A regional root is the root bridge inside a region, regional root bridge will be needed to properly set up load balancing for VLAN groups inside a region. CIST root will be used to configure which ports will be alternate/backups ports (inactive) and which ports will be root ports (active).

Note: Between regions there is no load balancing per VLAN group, root port election process and port blocking between regions is done the same way as in (R)STP. If CIST has blocked a port that is inside a region to prevent traffic loops between regions, then this port can still be active for IST to do load balancing per VLAN group inside a region.

• The following parameters are involved to elect a regional root bridge or its root ports:

Sub-menu: /interface bridge msti

Property	Description
priority (integer: 0..65535 decimal format or 0x0000-0xffff hex format; Default: 32768 / 0x8000)	MST instance priority, used to determine the root bridge for a group of VLANs in a MSTP region.

internal-path-cost (integer: 1..200000000; Default: 10) Path cost for a MST instance's VLAN mapping, used on VLANs that are facing towards the root bridge to manipulate path selection, lower path cost is preferred. priority (integer: 0..240; Default: 128) The priority a MST instance's VLAN, used on VLANs that are facing away from the root bridge to manipulate path selection, lower priority is preferred. internal-path-cost (integer: 1..200000000; Default: 10) Path cost to the interface for MSTI0 inside a region. The following parameters are involved to elect a CIST root bridge or its root ports:

• /interface bridge priority
• /interface bridge port priority
• /interface bridge port path-cost

MST Instance

Sub-menu: /interface bridge msti

This section is used to group multiple VLAN IDs to a single instance to create a different root bridge for each VLAN group inside a MSTP region.

Property	Description
bridge (text; Default: )	Bridge to which assign a MST instance.
identifier (integer: 1..31; Default: )	MST instance identifier.
priority (integer: 0..65535 decimal format or 0x0000-0xffff hex format; Default: 32768 / 0x8000)	MST instance priority, used to determine the root bridge for a group of VLANs in a MSTP region.
vlan-mapping (integer: 1..4094; Default: )	The list of VLAN IDs to assign to MST instance. This setting accepts VLAN ID range as well as comma separated values. E.g. vlan-mapping=100-115,120,122,128-130

MST Override

Sub-menu: /interface bridge port mst-override

This section is used to select desired path for each VLAN mapping inside a MSTP region.

Property	Description
disabled (yes | no; Default: no)	Whether entry is disabled.
internal-path-cost (integer: 1..200000000; Default: 10)	Path cost for a MST instance's VLAN mapping, used on VLANs that are facing towards the root bridge to manipulate path selection, lower path cost is preferred.
identifier (integer: 1..31; Default: )	MST instance identifier.
priority (integer: 0..240; Default: 128)	The priority a MST instance's VLAN, used on VLANs that are facing away from the root bridge to manipulate path selection, lower priority is preferred.
interface (name; Default: )	Name of the port on which use configured MST instance's VLAN mappings and defined path cost and priority.