loopguard and dual sup32 problem

[les.flack]

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?

[ybajpai]

I am having some difficulty in understanding your topology:

if the two core cat6k's are a trunk with only vl300 and vl99 and is not passing user vlan's then there is no physical loop for any of the user vlans, right?

Furthermore, you mention each access cat6k has 2 user vlans that terminate on a L3 link on the core. How is that implemented? sub-interfaces?

If the answer to above questions are a yes then you dont have any physical loop in your network. Remember that loopguard feature works on the blocked ports and kicks in when the blocked port has stopped receiving BPDU's from the desginated port. But all this doesnt apply in your case then as you dont HAVE any blocked ports in your switches.

Also, on a side note, if you ARE using a subinterfaces then your management vlan99 must NOT be working as each L3 port (physical or subinterface) segregates the vlans on the switch.

Let me know if you need me to explain somethings more clearly

[les.flack]

Thanks ybajpai,

You are correct there are no physical loops for the user subnets.

Aplogies I did not explain that the uplinks to each L2 access switch are trunks carrying two user subnets and Vlan 99 for management.

The user subnets for each access switch are terminated at the core switches on SVI's.

Vlan 99 has an SVI at each core also but is carried across the core-core trunk, hence there is a physical loop for v99.

From your explanation I only need loopguard for vlan 99 ???

From reading:

http://www.cisco.com/en/US/partner/tech/tk389/tk621/technologies_tech_note09186a0080094640.shtml#rootguard

I now understand that loopguard should only be applied on Root Ports and Alternate ports which in my case I believe means:

1. On both the uplink ports at the access switches.

2. On the Root port on the Core-Core interlink but only on the non root switch for Vlan99.

But regarding 2. My Core-Core interlink is an Etherchannel and I am concerned that loopguard can potentially block the whole channel, so I'm inlined to leave loopguard off here and rely on UDLD - what do you think?

Also from that doc please could you expand on the statement "Additionally, loop guard does not work on shared links" ?

thanks again

Les

[Francois Tallet]

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

[ybajpai]

Hey Les,

"Additionally, loop guard does not work on shared links" simply means that loopguard can only be used on a point-to-point link. This is usually an uplink segment that does not have any users connected to it.

Loopguard and UDLD do pretty much the same thing. so i would suggest you choose one protocol and use consistently in your network. UDLD is more from a physical layer standpoint and Loopguard is from a spanning-tree point of view.

Since rootguard and loopguard are mutually exclusive and it seems like you are interested in the rootguard feature, you might want to use UDLD on all your links for unidirectional link failures and issue rootguard on your access switches to prevent any downstream switch taking over the root role for vlan 99. Note that you cannot turn ON these features on a per vlan basis. they are enabled globally.

Regards,

Yash

[les.flack]

Francois/Yash

Tks for the detailed response. RE Point 1 - FYI, vlan 99 IS carried between the core so I think that at the access the uplinks will be root port and alternate port for Vlan 99, I'm not on site so cannot confirm, do you agree??

Interesting point re the access as the root bridge for the user vlan's, is this done often?

RE loopguard should only block vlan 99 in this case - thats what I expected - per vlan, but in my fault scenario I definately lost user traffic (I admit I had loopguard in the wrong places) which is worrying given the loop free topology for the user subnets. loopguard seemed to block the whole trunked uplink. At a later date I'll retest in the lab and let you know.

In summary I have no plans for rootguard as I am not concerned about external bridge priorities.

hence I see two options:

1. to rely on solely on UDLD applied everywhere:-

Reason - given that my user Vlans are loopfree and vlan 99 would require selective placement of loopguard which may not be so good for ease understanding by support staff.

2. Use UDLD and loopguard as follows:-

a) Apply loopguard on the access switch uplinks that point to the Root on Core 1 and the NDR on Core 2.

b) apply loopguard on the Core 2 interlink toward the vlan 99 root on Core 2. and

c) apply UDLD everywhere.

Have I understood correctly?

thanks again

rgds

Les

[Francois Tallet · Accepted solution]

Les,

We are not really focusing on the real problem here;-) The real problem is that loopguard should not kick in in the scenario you describe. You should be able to enable loopguard everywhere with no problem, regardless of the role of the ports (most ports in you network have different roles depending on the vlan, so it would not be possible to configure loopguard if it was dependent on the role without a per-vlan configuration.)

So first, I think you should try to identify the issue with your loopguard configuration (which is again not related to the roles, be firm with the TAC if you open a ticket;-)). If this cannot be sorted out on time, you can still live without loopguard and rely on UDLD.

The IEEE implemented in 802.1D-2004 a very nice feature that performs much better than loopguard by the way. This is the "dispute" mechanism. Right now it is only available in the latest MST implementation but should be ported soon to rapid-PVST+. We have some other new options coming out that would be perfectly adapted to your design, but it might take some few months before they are available in an IOS release.

Regards,

Francois