Root bridge does not know it is root bridge........

anthonykahwati · ‎03-08-2012

Hello

I have a strange one here, anyone seen this before or any idea what is going on?

Thanks

Anthony

core01#show spanning-tree vlan 8

VLAN0008
Spanning tree enabled protocol rstp
Root ID    Priority    24592
             Address     000d.292b.7100
             Cost        16
             Port        641 (Port-channel1)
             Hello Time   2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority    32776 (priority 32768 sys-id-ext 8)
             Address     000d.292b.7100
             Hello Time   2 sec Max Age 20 sec Forward Delay 15 sec
             Aging Time 14400 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi7/5               Desg FWD 19        128.389 P2p
Po1                 Root FWD 3         128.641 P2p
Po8                 Desg FWD 3         128.648 P2p

gpl-1-core01#show int gi1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 000d.292b.7100 (bia 000d.292b.7100)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 80/255, rxload 58/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX
input flow-control is on, output flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:51, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 93249
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 230598000 bits/sec, 53254 packets/sec
5 minute output rate 451592000 bits/sec, 60020 packets/sec
     120048852136 packets input, 57061049922532 bytes, 0 no buffer
     Received 8722380322 broadcasts (119867518 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     164441471676 packets output, 174372748376360 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
gpl-1-core01#show int gi2/1
GigabitEthernet2/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 000d.292b.7102 (bia 000d.292b.7102)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 82/255, rxload 15/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX
input flow-control is on, output flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:54, output never, output hang never
Last clearing of "show interface" counters 6w4d
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 3851
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 62623000 bits/sec, 24796 packets/sec
5 minute output rate 324902000 bits/sec, 35409 packets/sec
     86375616789 packets input, 43280325517602 bytes, 0 no buffer
     Received 6065659196 broadcasts (1749732733 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     119236932961 packets output, 144710052143142 bytes, 0 underruns
     0 output errors, 0 collisions, 4 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
gpl-1-core01#show spann
gpl-1-core01#show spanning-tree root port
VLAN0001         Port-channel1
VLAN0005         Port-channel1
VLAN0007         Port-channel1
VLAN0008         Port-channel1
VLAN0016         This bridge is root
VLAN0020         This bridge is root
VLAN0101         This bridge is root
VLAN0102         This bridge is root
VLAN0103         This bridge is root
VLAN0104         This bridge is root
VLAN0105         Port-channel1
VLAN0106         This bridge is root
VLAN0108         Port-channel1
VLAN0109         Port-channel1
VLAN0110         Port-channel1
VLAN0111         Port-channel1
VLAN0120         This bridge is root
VLAN0121         Port-channel1
VLAN0150         This bridge is root
VLAN0151         Port-channel1
VLAN0181         Port-channel1
VLAN0184         This bridge is root
VLAN0194         This bridge is root
VLAN0196         This bridge is root
VLAN0999         This bridge is root

John Blakley · ‎03-08-2012

Can you post your spanning-tree config? There are multiple vlans on the port-channel that doesn't believe it's the root. Are you splitting vlans among switches because it believes that the mac address 000d.292b.7100 is the root.

HTH, John *** Please rate all useful posts ***

Kevin Dorrell · ‎03-08-2012

I don't think it is the root bridge on VLAN 8. Go to the switch that is connected to Po1 and do a show spanning-tree vlan 8. You will find that that is not the root bridge either: it will have a cost of 13, at least lower than the one you are on now.

Then follow the VLAN 8 root port on that switch to the next switch in line, and do the same. You will find the root cost decreases with each step. Eventually you will find the switch that really is the root. Then you can work out why it it the root.

Kevin Dorrell

Luxembourg

anthonykahwati · ‎03-09-2012

Thank you for your response. I have attached a diagram.

Basically, we have a riverbed in place as an inline device on one of the switches in the LAN. If I enable the trunk link between wansw01 and wansw02 we lose all connectivity on vlan 8. The config for the 2 ports attached to the Riverbed is below.

Please note that vlan 8 and 16 are on the whole topology, except for vlan 16 which is on every single interswitch link, but the VLAN itself does not exist on the remote wan switch... it does however exist on the links to it at both ends.

interface GigabitEthernet1/0/3

description RB01-LAN0_0

switchport access vlan 8

switchport mode access

speed 1000

duplex full

srr-queue bandwidth share 10 10 20 60

srr-queue bandwidth shape 10 0 0 0

priority-queue out

mls qos trust dscp

no cdp enable

spanning-tree bpduguard disable

end

gpl-1-wansw02#show run int gi1/0/4

Building configuration...

Current configuration : 312 bytes

!

interface GigabitEthernet1/0/4

description RB01-WAN0_0

switchport access vlan 16

switchport mode access

speed 1000

duplex full

srr-queue bandwidth share 10 10 20 60

srr-queue bandwidth shape 10 0 0 0

priority-queue out

mls qos trust dscp

no cdp enable

spanning-tree bpduguard disable

end

The Root of VLAN 8 is seen on wansw02 int gi1/0/3. We can see what is happenning, and correct me if I am wrong, but the bpdu for vlan 16 is being sent out of int gi1/0/4 and then being forwarded by the RB into gi1/0/3, untagged but arriving on a vlan 8 interface, so the switch thinks that there is another vlan 8 switch there and it is the root.

The plan is to put bpdu filter on each interface. I think this will fix it, btu I just dont understand, 100%, why this is happenning, I know the cause, but, why does the core think its interface is the root and why does the switch not realise what is going on evertime we enable the link between the 2 wan switches?

Happy to give any more information if needed..

Thanks

Anthony

Kevin Dorrell · ‎03-11-2012

Still looking at your config, but I would strongly advise against configuring bpdufilter until we have thought this through.

Looking at your original posting again, I had not picked up on how wierd it really is. The bridge MAC is the same as the root MAC, but the priorities are different and the root cost is non-zero. In fact, it supports your analysis, because 24592 would actually be a VLAN 16 priority (24576 + ext. 16).

Now, how to solve it safely ... ?

Who should actually be the root of VLAN 8? If the VLAN 16 root bridge is becoming the false root of VLAN 8, it looks like you don't have anything configured for VLAN 8. But I fear that if you did configure a root for VLAN 8, the problem would simply reverse, and the VLAN 8 root would become the false root of VLAN 16.

Interesting ...

I don't know the riverbed, but does it pass broadcasts and multicasts, and does it flood unknown unicasts? If so, we have to tread very carefully.

anthonykahwati · ‎03-12-2012

Thanks Kevin

We have not put the BPDUFILTER tune on as yet. Can you tell me why we should not? The reasoning behind doing so was that we would stop any BPDU's either going to or coming from the RiverBed.

In answer to your question, our RB support company have said that they believe that the RB does pass broadcasts and multicasts and that any unknown unicasts would go via the default gateway, however, at a layer 2 level, anything that goes in one interface will be popped out the other.

Any idea why we lose all our VLAN 8 devices everytime we enable the link between wansw01 and wansw02? I was suspecting we may be causing a loop, however, at the time of the issue (and we werent on the trail of spannign tree unfortuately otherwise I would have more information) we saw no high CPU processes. We did however have a closer correlation of received to sent BPDU's on the 2 VLANs, but not any others on the switches.

I'm hopefully getting a definitive answer from RB today on how it treats traffic.

Thanks

Anthony

anthonykahwati · ‎03-12-2012

From RiverBed:

From: employee at riverbed

Subject: RE: Riverbed Support Case

Sure, the Steelhead will forward L2 b/cast, m/cast and unicast packets. In addition it will forward any L3 UDP traffic as pass-through. TCP traffic will optimized were relevant or passed through

Kind Regards,

RiverBed