Loopguard and dual sup32 problem

Question

Hi I'm having a problem with loopguard.
The topology is as follows.
Two 6500 Sup720 IOS core switches connected together via a trunk with two vlans - VLAN 300 a routed interlink and VLAN99 is layer two for management of access switches.
Multiple 6500 Sup32 CatOS access switches each connect via two uplinks, one to each core. Each access switch has 3 VLAN's - 2 User VLAN's that terminate on L3 interfaces on each core (ie No STP loop). And one management VLAN99.
Loopguard is configured on all uplink and interlink interfaces on the access and core.
This topology works fine, if I fail the primary uplink, cutover is nice and quick.
However the wierd thing is that if I install a second Sup32 at the access and move the second uplink onto the second Sup32 - If I now fail the primary uplink failover is around 30 secs, it looks as if the loopguard is blocking the port at the core. If I turn loopgaurd off on the uplinks to access switches with dual sup32's failover recovery is fine again.
Any ideas please, perhaps loopguard is not relevant in this topology?

Answer 1

Les,
Loopguard can only be triggered on ports that receive BPDUs (as you mentioned, alternate and root ports). So it will definitely apply here, even for vlans on which there is no physical loop. You are right about point 2, however, you are probably wrong on point 1. The user vlans are not carried between the cores, so the access bridge is probably designated on its uplink to the second core. There is in theory no problem applying loopguard everywhere, but as there is no physical loop for your user vlans, there is no need for loopguard on the core-access links. If you absolutely want to enable loopguard on these links, in your particular scenario, it may be better to configure the access switches as the root for their respective user vlans (even if it seems unconventional;-))
You said that you are afraid that loopguard blocks the channel between the two cores. I agree that it would be a catastrophic event, however, that's probably what you want. Loopguard is supposed to help preventing uni directional link failure from opening a bridging loop. It would only be triggered on the secondary core switch (assuming that the primary core is root for vlan 99) and only to prevent a more catastrophic failure. Also, loopguard is applied on a per-vlan basis, not per interface, so its trigger on the channel could only affect vlan 99.
Loopguard assumes that a designated port will start sending inferior BPDUs should it loses its designated role as a result of a reconfiguration. If a designated port suddently stops sending superior BPDUs without sending inferior BPDUs, there is a link issue. This assumption is not true on a shared segment, where a designated port can become root or alternate as a result of receiving superior information from a third bridge (and thus become silent immediately). That's why loopguard is a point to point feature. The IEEE introduced recently a new feature much better than loopguard (the dispute mechanism) but it's only available in the latest MST implentation so far (will be extend to rapid-pvst soon).
Hope this helps!
Regards,
Francois