Rapid STP Cisco and non

[lamav]

Quick sanity check...

I have a non-Cisco access layer switch that is dual homed to cisco distros.

The non-Cisco switch is running 802.1w. Cisco is running rapid pvst+.

When I disconnect the active uplink, I fail over almost immediately to the other uplink and barely drop a ping. When I reconnect what was the active link, it has to go through the LIS and LRn states, meanwhile Im dropping all my pings.

This cant be helped given the non-Cisco switch that isnt running uplink fast, correct?

Thanks

[Ziga M]

Hey lamav,

I can't delete my post, but I will reply to yours:

1. with RSTP, BF and UF are NOT automaticly activated. UF is a feature that is used on access layer switches that can't become transit and it's never in use on RB. Simillar stands for BBF.

2.  yes

3. no - again - UF and BBF can't be used on RB. Well, I think you can enable them, but it will cause the network not to work properly.

4. this is almost the same question as mine and I found the answer:

Cisco will send it's propriatery rapid-PVST+ BPDUs. Non-cisco switch will use open-standard CST - BPDUs will be sent on native VLAN untagged. I assume cisco will understand them, but non-cisco switch won't understand BPDUs.

Destination mac address of PVST+ BPDUs is multicast mac address, so non-cisco switch, will simply forward it out on all ports, without looking on it's payload. If another cisco switch is connected, it will understand them. Otherwise sooner or later, they will be dropped.

Cisco won't assume anything and won't try to "switch to standard" or something similar like when choosing STP & RSTP.

hope it helps...

[lamav]

Ziga, thank you very much. Good stuff.

As for point 1, you are absolutely right. What I was trying to say was that UF and BBF are built in to Rapid-PVST+, but yes, they are disabled by default, You would turn on UF on the access switch, of course, and BBF on the D switches.

As for point 3, awhat I mean is that in an all-Cisco environment, Cisco would use its proprietary add-ons, like UF and BBF. Although, I must say I am surprised that Giuseppe is saying that Cisco does not use UF and BBF on its own routers anymore. Unless I am misunderstanding him. I wonder what platforms what is true for.

As for point 4. I found the same info. So, I guess it is safe to say that EVERY 3rd party switch that uses 802.1w and has to interact with a Cisco switch using rapid-PVST+ will behave the same way. On every VLAN, except perhaps for VLAN 1 (which I will test as soon as I get back home), reconvergence is going to be slow when the downed link recovers.

Giuseppe:

Glad you're OK, my friend. I am going to run that test on VLAN 1 as soon as I get back to my home lab. Right now I am away visiting a friend (wink) for a few days. Es una bella signora. Deve essere pazzo per essere interessato a me! LOL

So, youre saying Cisco doesnt use UF and BBF anymore? Is this on the Nexus platforms or all of them?

Thanks, guys

[lamav]

moved to top of page.

[Giuseppe Larosa]

Hello Victor,

yes long time I have very busy days at work, and so I have become a ghost here.

Let me try to give my feedback

1) uplink fast and backbone fast are cisco proprietary. RSTP 802.1W has functionally equivalent features to both, but does not use uplink fast and backbone fast anymore, so it should happen for Rapid PVST instances.

2) yes as stated above

3) no, they should use the functionally equivalent features but in each RSTP instance ( one per Vlan this is the key point here)

4) when interacting with an 802.1W compliant switch interaction can happen only in Vlan1 with the untagged BPDUs sent using IEEE standard. Cisco proprietary BPDUs using proprietary encapsulation and a proprietary L2 multicast destination address are used on tagged Vlans (vlan-id <> 1).

So to see if my point 4) has some foundation I would suggest to repeat your test, but this time on Dell uplinks,  on both sides, you should permit Vlan 2 AND Vlan 1. At least in Vlan1 you should see a correct interaction and a fast convergence, this might lead to some benefits also in Vlan 2 or not.

Hope to help

Giuseppe

[Ziga M]

Hey guys,

I flew throught all replies, but didn't found answer to my question:

I have cisco and non-cisco switch connected with trunk. On this trunk, cisco uses PVSTP+ which non-cisco switch doesn't understand. Is it possible to configure cisco switch to start using some standard frame?? Both switches are root bridge in this case, since they don't understand each other.

BR, Ziga

[lamav]

Ziga, can you kindly do me a favor and delete your post and ask your question in a new thread? I dont want my thread to get sidetracked.

Thank you

[lamav]

moved to top

[lamav]

Hi, I never heard back from anyone, so I figured I would close this thread out with the following summary:

1.  The results I obtained during failover testing were absolutely  consistent with a 3rd party bridge that runs 802.1w RSTP when  interacting with a Cisco switch running rapid-PVST+.

2.  In order to interoperate with a standards-compliant 802.1Q bridge, a  Cisco switch running rapid-PVST+ will send its BPDUs to the  Spanning-Tree Protocol's well-known multicast address of 01:80:C2:00:00:00,  DSAP 42, SSAP 42 for untagged/VLAN 1 on an 802.1Q trunk. This is what  is referred to as the CST or Mono STP. The MAC-address of 01:80:C2:00:00:00 is the multicast address that 802.1w/802.1D-2004-compliant switches  listen to for STP configuration and topology change notification/acks,  as well as for rapid-STP proposal and agreement BPDUs. The takeaway here  is that VLAN 1 must be allowed on all 802.1Q trunks that interconnect  Cisco and non-Cisco switches.

3. For all 802.1Q tagged VLANs, Cisco switches send their BPDUs to the reserved Cisco multicast address of 01-00-0C-CC-CC-CD (SNAP HDLC protocol type 0x010b). Unless the 3rd party switch is also  listening to this multicast address, its STP process will only have  visibility to the logical topology of the CST. That means the rapid  failover and convergence offered by RSTP will only be evident on VLAN 1.

4. Item 3 explains  why, upon restoring the downed link for VLAN 2, the Cisco switch port  (designated port) had to go through all the STP port states before  shifting to the forwarding state, thereby resulting in the loss of many  PINGs. The RSTP proposal and agreement BPDUs that should normally be  exchanged by access and distribution layer switches operating PVST+ were  ignored by the Dell switches for all BUT the untagged VLAN. With no  agreement in place, the Cisco switch port had no choice but to go  through all the STP port states.

5.  The Dell switch simply received the multicast packets destined for the  reserved Cisco multicast address and flooded them out all corresponding  VLAN ports, much the same way broadcasts are handled. In other words,  the BPDUs for the tagged 802.1Q VLANs were simply tunneled through the  non-Cisco region.

6.  There are non-Cisco switches that do listen to the Cisco multicast  address of 01-00-0C-CC-CC-CD for  interoperability sake, such as Extreme  Networks, Force 10, some  Foundry (now Brocade) switches and Juniper's  VSTP.