Tag Archives: MSTP

Some of you may know Cisco’s err-disable recovery feature, which allows to automatically bring a port from err-disable back to UP state. Huawei switches have similar functionality, which is called error-down auto-recovery.

There are five reasons a port can enter into error-down state:

• BPDU protection
• EFM threshold
• EFM remote failure
• Auto defend
• Link flapping
• MAC address flapping

Let’s take a look, how this feature works, in a network running STP, when BPDU protection is the reason that a port goes into DOWN state. If you are not familiar with BPDU protection feature, read my previous article “Protecting STP on Huawei switches”.

I have configured STP BPDU protection on the Ethernet 0/0/1 interface of labnarioSW1 switch as follows:

[labnarioSW1]int e0/0/1
[labnarioSW1-Ethernet0/0/1]stp edged-port enable
[labnarioSW1]stp bpdu-protection

As a continuation of the STP Root Protection feature I want to describe additional STP protection functions and show you, where these functions should be implemented, in a typical campus LAN environment.

BPDU Protection feature can be used to protect switches against STP BPDU attacks. It should be implemented on every switch, which has ports directly connected to end-user workstations. This is because we do not expect receiving STP BPDU from user workstations. When STP BPDUs are received on the edge port, STP topology recalculation occurs, causing network flapping. If the port is configured with BPDU Protection and the switching device receives STP BPDUs, then the port is placed into shutdown state, protecting STP topology from recalculation. By default BPDU Protection feature is disabled on Huawei switches. To enable it:

<labnario_sw>system-view 
[labnario_sw]interface Ethernet 0/0/1
[labnario_sw-Ethernet0/0/1]stp edged-port enable 
[labnario_sw-Ethernet0/0/1]quit
[labnario_sw]stp bpdu-protection

When a switch port is configured as a STP Edged and STP BPDU is received, the port is placed into shutdown state:

May 13 2013 20:17:00-08:00 labnario_sw%%01MSTP/4/BPDU_PROTECTION(l)[4]:This edged-port Ethernet0/0/1 that enabled BPDU-Protection will be shutdown, because it received BPDU packet!

[labnario_sw-Ethernet0/0/1]dis cur int e0/0/1
#
interface Ethernet0/0/1
 shutdown
 stp edged-port enable

[labnario_sw-Ethernet0/0/1]dis int eth0/0/1
Ethernet0/0/1 current state : Administratively DOWN
Line protocol current state : DOWN

Spanning Tree protocol is a loop prevention mechanism in a bridged LAN. Every STP topology has its own root bridge, which determines how STP topology is calculated. The role of the root bridge is to act as a reference point in the network, so that all other switches can determine, how far each of their ports is from the root bridge. The port, which has the lowest path cost, is placed into a forwarding state. All other ports, that can lead to the root bridge, are blocked. Ports in the switching topology, which lead away from the Root Bridge, remain forwarding. You can recall STP operations reading the following article: “Multiple Spanning Tree Protocol on Huawei switch“.

How does the root bridge election process work?

The root bridge for each STP instance is determined by the bridge ID. The bridge ID consists of a configurable bridge priority and the MAC address of the bridge:

[Huawei]display stp
-------[CIST Global Info][Mode MSTP]-------
CIST Bridge         :32768.4c1f-ccd4-1c03

Topology Change (TC) packets are sent when MSTP-enabled interface in a network flaps. If a physical interface frequently alternates between Up and Down, the MSTP status of the device in the network becomes unsteady. As a result, a large number of TC messages are generated, ARP entries are frequently deleted and services are interrupted.

How to find the source of TC packets?

Let’s look at the log, generated on one of the switches in a network. Let’s take Huawei S9300 switch as an example:

Dec 19 2012 11:32:56+10:00 S9300 %%01MSTP/6/RECEIVE_MSTITC(l)[40922]:MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet6/0/0.

What can we find in this log?

The most important for us is the port number on which the switch received TC packet, in this case interface GE6/0/0. To troubleshoot this problem we have to go to the next switch, connected to interface GE6/0/0 and check logs of that switch. If the neighbouring switch receives TC packets as well, we have to do further troubleshooting. If we find in the logs that MSTP-enabled interface is flapping, we can consider that this interface is the source of the TC packet. If this interface is still flapping, just make it down, to avoid unsteady behaviour.

The Multiple Spanning Tree Protocol (MSTP) was originally defined as the IEEE 802.1s standard protocol. Now the standard IEEE 802.1Q-2005 includes MSTP. The basic role of this protocol is to prevent L2 loops. I do not want to explain MSTP in details, as this can be easily found on the Internet. I just want to show you:

• how to configure this protocol using Huawei CLI
• how to load balance traffic over redundant links.

Let’s assume that we have the following physical topology: