Enabling UDLD agressive & root guard on some 3560's

From: Joseph Brunner (joe@affirmedsystems.com)
Date: Wed Oct 01 2008 - 00:39:01 ART


Hi group,

 

Since the 3560 is lab equipment, I thought I would share a real-world issue
I just spent some time working with.

 

Company had all 3560G's with 12.2(25) IP Base. Not the newest code, but
definitely not ancient.

 

The topology was

 

SW1(primary root 4096, all vlans)---------PO1-----------SW2(secondary root
8192, all vlans)

  |
|

  |
|

  |
|

  |
|

SW4-----------------------------------------------------------------------

 

The issue was SW3 a stub switch (and the root for vlan 1 and with a
connection ONLY to SW2) would be reached

Invariably by SW1 using either its direct port-channel to SW2 to reach SW3
and (when switch sw4 transitioned to forwarding)

via SW4 to reach SW3.

 

So obviously, when SW4 started forwarding vlan 1 on its link to SW2 (instead
of blocking), SW1<->SW2 would BLOCK!!!!

This caused outages as SW1 and SW2 are running HSRP on vlan1, etc.

 

This is a clear case for root guard, but to rule out any other possible
switches being in the path (Linksys?)

I enabled UDLD aggressive between SW1 to SW4 and SW2 to SW4.

 

One thing (pain for someone working remotely) UDLD aggressive required
either the port be shut/no shut to take effect on both sides, or

Rebooted.

 

Once UDLD aggressive activated, all connections were verified with the show
cdp neighbor command using show udld g0/48, etc.

 

Also, root guard on this IOS did not work as expected. enabling it on SW1
and SW2 to SW4 caused SW4 to NOT HEAR BPDU's from SW2, and of course

Become designated, start forwarding and send its own bpdu's! SW2,
immediately put the link to SW4 in a root-inconsistent state, as SW4 was
attempting to report

Its root path to SW1.

 

One little thing I must mention, SW1 and SW2 booted with root guard
configured and then I changed SW2's stp priority to 8192)

 

To fix this issue I had to do 3 things.

 

1. remove root guard from SW2's links to SW4
2. reboot switch 4 (sure could have probably just downed the ports)
3. re-config root guard on SW2's links to SW4.

 

Just an FYI, as I could see doing these little things taking valuable time
if you weren't expecting these quirks!

 

Also here is the output I captured from SW2 when SW4 was continuing to
forward, when it should have blocked.

 

switch02#show spanning-tree int g0/48 detail

 Port 48 (GigabitEthernet0/48) of VLAN0001 is broken (Root Inconsistent)

   Port path cost 4, Port priority 128, Port Identifier 128.48.

   Designated root has priority 32769, address 001a.e217.b600

   Designated bridge has priority 8193, address 001a.e217.b600

   Designated port id is 128.48, designated path cost 0

   Timers: message age 15, forward delay 0, hold 0

   Number of transitions to forwarding state: 0

   Link type is point-to-point

   Root guard is enabled on the port

   BPDU: sent 0, received 564

 

Check out how SW2 sees SW1 with a priority of 32769 (it had already been
configured to 4096+1!!!!)

Check out how SW2 sees itself with a priority of 8192+1 (as it was
configured)

 

(Yes, vlan 1 is allowed on ALL TRUNKS including SW1<->SW2) so no reason it
should not have seen

SW1, with 4096+1 as the designated root at that moment. hmmm it finally did
when root guard worked.

 

Switch02#show spanning-tree int g0/48 de

 Port 48 (GigabitEthernet0/48) of VLAN0001 is designated forwarding

   Port path cost 4, Port priority 128, Port Identifier 128.48.

   Designated root has priority 4097, address 001a.e200.b300

   Designated bridge has priority 8193, address 001a.e217.b600

   Designated port id is 128.48, designated path cost 3

   Timers: message age 0, forward delay 0, hold 0

   Number of transitions to forwarding state: 1

   Link type is point-to-point

   Root guard is enabled on the port

   BPDU: sent 2425, received 974

 

-Joe

Blogs and organic groups at http://www.ccie.net



This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:18 ARST