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.
|
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. # Enable digest snooping on 10GE1/0/1. 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. 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. 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 14:17.373+08:00 PER2-CE6810-MI-SER %%01MSTP/7/MSTP_DEBUG_PACKET(d):CID=0x80542723; Therefore the port status mode on Cloudengine is STP, instead of MSTP. CIST Port Information: 1.  Root CauseThe 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. SolutionWe can filter all PVST+ BPDUs that the CE might receive. Customer is not using PVST in their network.
We managed to resolve the problem using this setup, after we restart the STP process the Cisco interface is not bound to MSTP. SuggestionsA 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. |
|
Reply
Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
