Blocking a link on GbE2?

[DaGuru]

Anders,

In stead of dissabling the trunk, try dissabling the physical uplinks themselves. This will assure no traffic gets through. Being that you had a topology change, I would agree with the others in that the ports probably managed to forward data.

I clipped the following from the CLI Guide.

To temporarily disable a port without changing its stored configuration attributes, enter the following command at any prompt:
Main# /oper/port /dis
Note: Be sure to dissable all 4 trunk members.

Because this configuration sets a temporary state for the port, you do not need to use apply or save. The port state
will revert to its original configuration when the GbE2 Interconnect Switch is reset.

[Anders_35]

Hi, Dennis.

>In stead of dissabling the trunk, try
>dissabling the physical uplinks

Well, that's what I was trying to avoid.
Two commands vs. eight for the entire operation reduces likelyhood of errors significantly.


>Being that you had a topology change, I
>would agree with the others in that the
>ports probably managed to forward data.


Only RSTP data. No switched data came through from the servers hanging off that switch.
And herein lies the mystery...
Since RSTP kept the ports open, why was there even a TCN? The STP didn't really change.

[DaGuru]

Purely speculation on my part, but if the VLAN(s) are assigned to the Trunk, disabling the trunk may have allowed the member ports to revert back to their pre-configured state (transmitting BPDUs on the native VLAN.) This may have been enough to signify a TCN as dropping the trunk could have generated a 'flapping' state.

You might be able to catch the anomaly with a protocol analyzer?

I'll be interested to see what direction your support ticket leads you.

[Anders_35]

Yeah, that sounds like it. HP pointed me to an advisory (EB050408_CW01) for a similar situation, in which a broadcast storm occurs because disabling trunks momentarily puts ports in that "flapping state".
(I don't recall all details, and that web page is not available just now..)

This teaches me another lesson.
In a discussion here the other day (also with Matt Hobbs), I made the assumption
that a port would only change into a bridge link following a "link up".

Apparently, that was very wrong.

[Connery]

Anders,
One of the easiest ways to manually force a particular port (or trunk) to become the root port/trunk is to manually change the STP port cost value.

In your setup, you could have increased the port cost value on Switch A's uplinks, forcing it to start using the interconnect ports (17/18) because they would then have a lower STP port cost. Or, you could have decreased the port cost on the interconnect ports to achieve the same thing.

In regards to TCNs, you'll get TCN's anytime a non-Host port changes it's status (examples: blocking to forwarding, forwarding to blocking, link up, link down, etc.)

regards,
-sean