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

Unanswered Question
Mar 8th, 2012
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
John Blakley Thu, 03/08/2012 - 08:13
User Badges:
  • Purple, 4500 points or more

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.

Kevin Dorrell Thu, 03/08/2012 - 08:44
User Badges:
  • Green, 3000 points or more

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 Fri, 03/09/2012 - 06:23
User Badges:

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 Sun, 03/11/2012 - 01:56
User Badges:
  • Green, 3000 points or more

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 Mon, 03/12/2012 - 03:14
User Badges:

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 Mon, 03/12/2012 - 05:35
User Badges:

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

Actions

This Discussion

Related Content