cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
993
Views
0
Helpful
8
Replies

Wireless AP Bridging - Whole Network Crashes When I Configure the Root Bridge. Why?

Dean Romanelli
Level 4
Level 4

I have a Cisco 1602 SAP that I've set as the non-root bridge.  I have a Cisco 1261 SAP connected to the backbone that I've set as the root bridge where I want the non-root bridge to establish to.  Both sides also have wireless clients associating to the SSID.  Flat network w/ everything on VLAN 1.  When I configure the AP connected to the backbone to be the root bridge, it takes down the WHOLE network --> Switches, AP's, Clients, All Services.  If I reboot the root bridge AP so it reverts back to previous configuration before setting to root bridge, everything comes back.

Why? Loop? Broadcast storm? Blackhole? Bad bridge-group configs?

Configs attached.

1 Accepted Solution

Accepted Solutions

I would suspect a L2 loop. If possible please share the switch logs while this issue is happening, that will give us an indicated why switch is crashing

 

If you have a basic topology diagram showing connectivity (ie interfaces, etc) that would be useful too

 

HTH

Rasika

View solution in original post

8 Replies 8

I would suspect a L2 loop. If possible please share the switch logs while this issue is happening, that will give us an indicated why switch is crashing

 

If you have a basic topology diagram showing connectivity (ie interfaces, etc) that would be useful too

 

HTH

Rasika

Hi Rasika,

Thanks for replying. Topology diagram is attached. The AP's I've circled in green are the root bridge AP and non-root bridge AP respectively. Users on the 5th floor will connect to the non-root bridge wirelessly.  As for switch logs, unfortunately the site flipped the breaker in the whole warehouse to power cycle the root bridge AP, so the logs from the switch are gone.

Again, everything on this diagram except for the ASA firewall and the ISP's router crashes as soon as I configure the root bridge on the .171 AP.  Any help you could provide would be most appreciated.

Thanks for the topplogy & detailed information.

I would check g2 interface configuration of warehous switch.

which switch is STP root bridge for vlan 1 ? I would think it is Main Flor switch where ASA connects.

If issue is due to spanning tree related, I would implement some protections. Eg enable "spanning-tree guard root" on g2

 

https://supportforums.cisco.com/t5/network-infrastructure-documents/spanning-tree-protection/ta-p/3116493

 

Cannot pin point exact problem, without having any logs from your switch end

 

HTH

Rasika

Hi Rasika,

I agree that it does "feel" like a spanning-tree loop. These warehouse guys connected unmanaged junk to the network all the time, so it wouldn't surprise me. What I don't get though is why setting the radio interface to root bridge for wireless clients causes the loop to manifest. If there is a potential loop somewhere on the network that is being activated by that command, I would think it would be cropping up whether I configure the AP as such or not. 

What I'll do is wait for them to go home today, set a scheduled reload on the AP, then make the change, wait for the network to crash, wait for the AP to reboot which will restore the network, then I will check the switch logs.

Rasika,

 

What if I enable spanning-tree on the radio interfaces between root bridge and non-root bridge AP?  It is disabled currently. 

 

interface Dot11Radio0
no ip address
no ip route-cache
!
encryption mode ciphers aes-ccm
!
ssid WIRELESS
!
antenna gain 0
station-role root bridge wireless-clients
no cdp enable
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled

Ok the site has gone home for the day and I've had a chance to play with this again.  This time I set a scheduled reload on the AP that will have the root bridge configs so that everything comes back after the crash.  Here is what I've found:

1. There is absolutely nothing logged in the switch during the outage, once I am able to access it again. Only the down-up message for when the scheduled reload of the AP goes off.

2. If I disable spanning-tree and turn on BPDU filtering on the switchport on the switch that connects to the AP that I am trying to make the root bridge, I seem to stay connected. 

3. There is no switch or intermediate device in between the root bridge AP and the main POE switch. It is a direct connection. 

No idea how this is a spanning-tree problem. 

By using "show spanning tree vlan 1" check where is STP root bridge on your network.

 

I would suspect newly added switch/ap may be trying to be root. Also check if there is any STP loop across this bridge link

 

HTH

Rasika

It was a spanning-tree loop, and I have it working now. I had to enable spanning-tree on the root bridge AP, and put a BPDU filter and disable spanning-tree on the switchport on the switch that connects to it, but I don't understand how/why it was a spanning-tree loop.  The root bridge is the switch you mentioned before with priority 0, and I made the root bridge AP priority 57344 and the non-root bridge AP priority 61440, so I don't see any way how it could have been a loop, especially because spanning-tree is disabled and BPDU Filter is dropping all BPDU's on the switchport that faces this AP, yet somehow it still knows where the root bridge is on the switched network.

 

Oct  9 2017 14:58:17.678: STP: Bridge group 1 heard root     0-008e.73c0.cb9b on Vi0 <-- Root SW
Oct  9 2017 14:58:17.678: current Root has 57344-f4ea.6762.3d40 <-- This root bridge AP
Oct  9 2017 14:58:17.678:     supersedes 57344-f4ea.6762.3d40 <-- Root SW priority better value
Oct  9 2017 14:58:17.678: STP: Bridge group 1 new root is 0, 008e.73c0.cb9b on port Vi0, cost 20052
Oct  9 2017 14:58:17.678: STP: Bridge group 1 sent Topology Change Notice on Vi0
Oct  9 2017 14:58:17.678: STP: opt: Bridge group 1: get ports: no free chunk available
Oct  9 2017 14:58:17.977: STP block packet on port Vi0.

So the issue is resolved, but I still don't understand why it was a loop. 

Review Cisco Networking products for a $25 gift card