Cisco to 3COM STP

DevilWAH

Hi all,

do any of you guys run cisco/3com network where you have spanning tree across running across them?

I have been trying to add in CISCO 2960s and 6500 to a 3 com network, and while I sue single links and the CSICO switch is set as default STP the network is stable.

however as soon as I try to enable MSTP on the cisco devices to match the current 3com I see lots of these errors on the cisco device.

Blocking root port Gi2/1: Inconsitent inferior PVST BPDU received on VLAN 10, claiming root 32778:b4e9.b04c.8100

the BPDU are coming it seems from other CISCO switches that are still running default STP. No cisco devices are directly connected but are all running through the STP root which is a 3com 4800.

Any thoughts/ideas?

it_consultant

DevilWAH wrote: »

Hi all,

do any of you guys run cisco/3com network where you have spanning tree across running across them?

I have been trying to add in CISCO 2960s and 6500 to a 3 com network, and while I sue single links and the CSICO switch is set as default STP the network is stable.

however as soon as I try to enable MSTP on the cisco devices to match the current 3com I see lots of these errors on the cisco device.

Blocking root port Gi2/1: Inconsitent inferior PVST BPDU received on VLAN 10, claiming root 32778:b4e9.b04c.8100

the BPDU are coming it seems from other CISCO switches that are still running default STP. No cisco devices are directly connected but are all running through the STP root which is a 3com 4800.

Any thoughts/ideas?

Change your port priority on the Cisco to make it inferior to the other Ciscos. Port inconsistent is a 802.1W state, if your 3COMM is running 802.1D instead of 802.1W and your ciscos are running 802.1W (preferred or required) then your Ciscos will attempt to create a root port of their own.

One more thing, this is specific to PVSTs, in HP/3COMM you can (and you should) set the switch to ignore PVST inconsistencies, I am not sure if the Cisco has a similar feature, but I would investigate that avenue as well.

DevilWAH

Let me just check this is right.

suppose I have 3 3COM switch arranged in a loop, Switchs A,B and C.

Switch A is the current root with a Priority of 0
Switch B is the secondary root using the command "root secondary"
Switch C is defaults

Then I have three Cisco devices each patched through to one of the above switches running PVST with default values.

What you are saying if I am correct is that before I change the mode of the CISCO switches to MSTP, I should set the priority to >32768.

So the 3com root and primary will still be lowest over all, then the random CISCO switches next and the Cisco switch I am about to swap to MSTP the highest priority of all? I am going to have to do this on a live network so jsut want to get my facts stright before I do. No need to add to the "most embarrassing mistake" thread if I can help it.



Thanks

DevilWAH

Seems however I set this up it falls over

on a few test switches I can get it working, but as soon as I try it on live it blocks ports all over the place. And forming ether-channels between the two is not with out issues either.

What I am going to do is move all the Cisco access switch to connect directly to the 6500's and then have them interface to the rest of the network via a single etherchannel to the 3com network.

It only has to work for a short while until I replace all the 3Com devices.

getting 802.1d and 802.1w to work together seems to be a bit of a mine field.

it_consultant

DevilWAH wrote: »

Seems however I set this up it falls over

on a few test switches I can get it working, but as soon as I try it on live it blocks ports all over the place. And forming ether-channels between the two is not with out issues either.

What I am going to do is move all the Cisco access switch to connect directly to the 6500's and then have them interface to the rest of the network via a single etherchannel to the 3com network.

It only has to work for a short while until I replace all the 3Com devices.

getting 802.1d and 802.1w to work together seems to be a bit of a mine field.

Well, yeah, I wouldn't recommend it. In fact, on my Brocades if a switchport gets a 802.1D TCN BPDU it will automatically shut off 802.1W and run in compatibility mode. That setting is buried in HP OS somewhere also, I am not sure of its default setting -- the problem is that your two spans are not aware of each other, so your switches are running amok doing their own thing.

The principle difference between D and W is that when a switch boots in W mode, it automatically assumes it is root until it receives lower priority BPDUs. That is why failover can be so quick, no switch has to wait for a TCN. When you are setting it all up and you get an error like you have (where two switches cant agree on the election), you get to go in and be the tiebreaker. Getting this to work in production while also running 802.1D, scary.

I have read a lengthy article on how to set up your networking stack to host tenant organizations who have their own equipment, one of the first things it says is to either run BPDU Filter (silently drop BPDUs and assume a forwarding state permanently) or BPDU Guard (disable the port on reception of a BPDU) because of problems like the ones you are experiencing.

DevilWAH

Cheer good explanation

What i am doing is moving all the cisco access switchs to the 6500 new cores. And then setting up the links from them to the rest of the 3com network. and avoid the whole issue

thanks

DevilWAH

Interestingly I had ore of a look at this, from documentation this is what I can find out.

First what modes the switches can run, and the standards.

Cisco 6500


MST = 802.1s (IEEE 802.1s defined MST and was incorporated into IEEE 802.1Q.)
Rapid PVST+ = 802.1w builds on 802.1d (IEEE 802.1w defined the Rapid Spanning Tree Protocol (RSTP) and was incorporated into IEEE 802.1D.)




3com 5500/4800


mstp Multiple spanning tree protocol mode


MSTP is documented in:
■ IEEE 802.1d: Spanning Tree Protocol
■ IEEE 802.1w: Rapid Spanning Tree Protocol
■ IEEE 802.1s: Multiple Spanning Tree Protoco




pvst Per-VLAN spanning tree protocol mode (Cisco Priporitory??)
rstp Rapid spanning tree protocol mode (802.1w)
stp Spanning tree protocol mode (802.1d)


So from what I can make out either running rapid PVST+ and rstp or running MST and MSTP should work. But as before running MST and MSTP caused a lot of ports getting disabled.

Also seeing lots of TCN packets flying around and topology changes taking 30+ seconds to converge (falling back to STP me thinks).

So i think when I get back from holiday it will be time to pull it apart and re-do the lot, how it was left by the previous engineer was a nightmare and it seems that I wont be able to complete a refresh as quick as I would like. I also might simply disable STP on any access switches that don't need it.

it_consultant

I had thought about this a while and everything should be compatible. Even if you are running rstp on one switch and stp on another switch it should still converge properly. It sounds like you have a problem with the root election process. Maybe some strategically placed ports in stp root protect status is what is needed. Keep in mind that TCNs in rSTP only get generated if a non-edge port goes into a forwarding state; so check all your ports to make sure your aren't shooting yourself in the foot with something like UDLD or bpdu filtering which could be causing flapping.

As far as your access switches, if you want to disable STP (I friggin hate STP) then I would recommend you run a LACP bond to your core or distribution layer (to different switches if you can swing a TRILL or multi-chassis trunk configuration) then put the port-channel in a rSTP link type point to point, all edge ports in a link type edge, then bpdu-guard(or filter depending on the manufacturer) all your edge ports. That is how my access switches are set up, they are in a high speed stack (ironstack) with the top and bottom switch forming a LACP bond to the collapsed core/distribution layer which are set up as an MCT. The most annoying thing about that is when someone plugs in a switch at their desk it shuts down their port. Annoying, but hey, I have to enforce my STP boundaries and prevent them from putting a loop in the topology.