Inserting Transceiver causes spanning-tree disruption?

[dansken82]

I can't find any documentation on this. When we inserted a transceiver in a 4900M (stp root bridge), it disrupted spanning-tree. We are running MST, and it caused a topology change in every instance, that again caused a couple of seconds of outage.

Have anyone else experienced this?

[Somasundaram Jayaraman]

Hi,

if the interface belongs to any vlan then definetly a tcn will get generated when the links go down and the TCN it will instruct the other switches to flush the mac table of the other switches in that vlan

You can configure that interface as port-fast so that no TCNS will be generated from that port.

Hope this helps

Cheers

Somu

Rate helpful posts

[dansken82]

It was configured as an access port in a vlan, so my prediction would be that it should only cause a TCN fort the MST instance that the vlan belonged to. TCN's are normal, and shouldn't be disruptive, other than the flushing of the cam table as you say.

What we experienced was a topology change for instance 0 and all the other instances, which also caused a short outage. No root changes or anything else, just topology change for all instances.

My guess is that the insertion of the sfp caused this, and maybe because it was inserted into the root bridge.

[Peter Paluch]

Somu,

You wrote:

if the interface belongs to any vlan then definetly a tcn will get generated when the links go down

Please correct me if I am wrong but as the MSTP is built on top of RSTP, the TCN should be generated only if a port becomes forwarding - not if a port goes down. See the following document:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#topchng

In particular, it states: "In RSTP, only non-edge ports that move to the forwarding state cause a       topology change. This means that a loss of connectivity is not considered as a       topology change any more, contrary to 802.1D (that is, a port that moves to       blocking no longer generates a TC)."

Dansken, am I understanding you correctly that a simple insertion of a SFP into a switch - with no cable or fiber connected to the SFP module - caused an outage?

Best regards,

Peter

[dansken82]

Yes, it looks very much so. I inserted 2 SFP's, with a few seconds between. Around 7 seconds after each sfp was inserted, there was a topology trap for instance 0 (log wouldn't show for any other instance, but a "show spanning-tree active detail | i from|change") would say there had been a change for all instances. I also connected fiber to one of the modules, and the link came up, but it didn't look as that was the reason for all the topology changes.

Either way, the port (access mode) should only have caused a TCN in it's respective MST instance.

[Peter Paluch]

Dansken,

Topology changes in MSTP are still eluding me so I won't comment on whether an access port going up should cause a TC only in its own instance, or in the IST+its own instance (as the IST runs on all ports regardless of their VLAN), or in all instances.

There is a couple of things here that I find curious:

1. Just as you mentioned, a TC should not cause network outage. It may cause a temporary flooding but not a loss of connectivity.
2. An edge port should not cause TCs at all. I assume that the access port was not configured as an edge (i.e. PortFast) port.
3. A transient outage in an MSTP network can be caused by the Proposal/Agreement mechanism. However, the Proposal/Agreement itself is fast enough not to cause an outage that lasts for several seconds. Also, a simple port coming up will not cause other ports on the same switch to start sending Proposals. Hence, no Proposal/Agreement wave could be induced into the network by simply plugging an SFP into the switch with no fiber connected to it.
4. An outage could also be caused on region boundaries if the MSTP is forced to fall back to STP operation, and a topology change is generated in the network. Is your entire network running in a single MSTP region?

I am wondering if there is actually a different explanation to the outage - some other event taking place, and whether we are incorrectly attributing the outage to the TC that simply occured around the same time. As expained before by both of us, a TC can not cause a network outage.

Or perhaps... hmmm. This is a strong speculation, but let's see: Is it possible that by inserting a SFP into a switch, the MSTP Port IDs have been renumbered (the port indexes being shifted because of activation of a previously non-present interface)? That would essentially mean resetting the entire MSTP process on the respective switch, along with the Proposal/Agreement stuff. The Port IDs can be displayed simply in the show spanning-tree command output in the column Prio.Nbr - this would, however, need making an experiment with removing and reinserting the SFP, or perhaps comparing older and current outputs of show spanning-tree if there are any stored.

Best regards,

Peter

[dansken82]

Those are some very interesting points.

- I forgot to mention that the port is configured with bpdufilter, I am not sure if it does a proposal/agreement, or if it filters all bpdu's in this state.

- the port is connected to a switch which we dont have control over, I am not sure what flavour of stp they are running.

- we are running mst for the most, with a few boundaries to rpvst switchblocks. and also some pre-standard MST.

- Your last point is an interesting one, but hard to prove, as I don't have a record of potential previous numbers.