Cisco - Huawei MSTP problem

Publication Date:  2016-09-30 Views:  1091 Downloads:  0
Issue Description

We are running a Huawei + Cisco MSTP network but for some reason there are 2 root bridges into the network. Funny is Cisco elect a Cisco Root-bridge, Huawei elect a Huawei root bridge.

Topology is as follows:

Huawei's sees itself as the root bridge.

Cisco sees itself as root bridge.


Alarm Information
none.
Handling Process

I follow the whitepaper of Huawei for MSTP and adjust the configuration according to it.

1. Enable digest snooping on the interface that is directly connected to Cisco/non-Huawei system, in order to solve the BPDU keys inconsistency.
If Huawei and non-Huawei devices have the same region name, revision level, and VLAN mapping table but different BPDU keys, the stp config-digest-snoop command can be used to enable the Huawei and non-Huawei devices to exchange BPDUs.

# Enable digest snooping on 10GE1/0/1.
<HUAWEI> system-view
[~HUAWEI] interface 10ge 1/0/1
[~HUAWEI-10GE1/0/1] stp config-digest-snoop

2. On Cisco C4500/C3750/3560/ME3400 SW default road-cost algorithm is short, corresponding Huawei is 802.1d-1998. However Huawei device default way is 802.1t, corresponding Cisco long algorithm. Different algorithm can explain why there are 2 different RBs in the MSTP network.

# Use the IEEE 802.1d-1998 to calculate the path cost.
<HUAWEI> system-view
[~HUAWEI] stp pathcost-standard dot1d-1998

3. Disable Proposal/Agreement mechanism. Huawei devices and non-Huawei devices may fail to communicate with each other, because they have different Proposal/Agreement mechanisms.

# Configure the common fast transition mechanism for the interface that connects to non-Huawei device.
<HUAWEI> system-view
[~HUAWEI] interface 10ge 1/0/1
[~HUAWEI-10GE1/0/1] stp no-agreement-check

By default, the enhanced transition mechanism is configured on an interface.

After we modify the configuration accordingly the problem was not resolved. So we need to do further troubleshooting.

By checking the interface status on Cisco side we find out the switch sees the interface connecting to Huawei as an PVST port instead of MSTP. So most probably Cisco device is receiving PVST+ BPDU from downstream network via Po104. This will trigger the PVST simulation component of MSTP that will transform the port into a PVST port.

Po104               Desg FWD 500       128.2418 P2p Bound(PVST)

Since Po104 is working as PVST interface, it will send STP BPDUs to Huawei CloudEngine device, and not MSTP . We can see this from debugging that the BPDUs system’s received is having BPDU type = 00, which is STP BPDU.

2016-08-10 22:17:26.373+08:00 PER2-CE6810-MI-SER %%01MSTP/7/MSTP_DEBUG_PACKET(d):CID=0x80542723;
Port64 Rcvd Packet(Length: 43)
ProtocolVersionID               : 00
BPDUType                        : 00
Flags                           : 00
Root Identifier                 : 24576.38ed-1866-7700
Root Path Cost                  : 0
Bridge Identifier               : 28672.38ed-1866-4c00
Port Identifier                 : 128.2418
Message Age                     : 0
Max Age                         : 20
Hello Time                      : 2
Forward Delay                   : 15

Therefore the port status mode on Cloudengine is STP, instead of MSTP.

CIST Port Information:
Port Id :64
Port Name :Eth-Trunk104
Port State :Forwarding
Port Protocol :Enabled
---- More ----[16D [16D Port Role :Root Port
Port Priority :128
Port Cost(Dot1D) :Config=auto / Active=1
Designated Bridge/Port :28672.38ed-1866-4c00 / 128.2418
Port Edged :Config=default / Active=disabled
Point-to-point :Config=auto / Active=true
Transit Limit :6 packets/s
Protection Type :None
Config-digest-snoop :Snooped=true
Port STP Mode :STP
Port Protocol Type :Config=auto / Active=dot1s
BPDU Encapsulation :Config=stp / Active=stp
PortTimes :Hello 2s MaxAge 20s FwDly 15s RemHop 0

1.     

Root Cause

The Cisco switch receives PSVT packets from the customer network via cloudengine switch. On CE6800 default behavior is to transparently transfer PVST BPDU and not process them in any way.


Solution
We can filter all PVST+ BPDUs that the CE might receive. Customer is not using PVST in their network.  


#                                                                              
acl number 4000                                                                
 rule 10 permit destination-mac 0100-0ccc-cccd                                 
#                                                                              
traffic classifier c1 type or                                                                                                                
 if-match acl 4000                                                             
#                                                                              
traffic behavior b1                                                            
 statistics enable                                                             
 deny             \\\\\ to filter the BPDUs you will need to change behavior to Deny.                                                        
#                                                                              
traffic policy p1                                                              
 classifier c1 behavior b1 precedence 5                                        


then apply the policy on the system globally.
[~R7_U18_CE6850]traffic-policy p1 global inbound

We managed to resolve the problem using this setup, after we restart the STP process the Cisco interface is not bound to MSTP.

Suggestions
A more elegant solution should be to disable PVST simulation process on Cisco side. This function will transform a STP/MSTP port into a PVST port when PVST BPDUs are received on the interface. This was not required in our scenario.

END