Odd behaviour on network - RSTP and BDPU sanity check

[Killerbot]

I need to preface this with I'm not a network specialist.  I know a little from Network+ and CCNA many years ago but new to the world of Ruckus and, as I work in education, it's typically only something I dabble in when there's an issue.

We experienced some odd behaviour at one of our sites on Friday and I'm going out tomorrow as the troubleshooting needs a local console connection.

I'll detail the odd behaviour we're seeing, and my plans to troubleshoot on site, but was hoping someone could sanity check the example config from the core (cleaned to remove any potential security issues).

I see 802.1w is enabled but I don't see any ports configured as edge nor admin, no bdpu guard nor any 'loop protect'.  Some of this could be assumed in Ruckus' 802.1w config but can't see anything to suggest that may be the case.  CPU usage wasn't significantly high when I got them to check for me on site so it may not be a loop, but I've come across 2 'loop' issues in the last year with these Ruckus installs and that's 2 more than I've come across in over a decade which makes me question the setup.

I'll post an example core and edge setup below but wanted to detail the behaviour and see if anything jumps out to those of you who are kindly reading this.

SOME traffic could not access the internet.  But there was no rhyme nor reason to it.

For example, device with ip 192.168.0.10/24 could ping it’s default gateway and access the internet.  Device 192.168.0.11/24 could ping it’s default gateway but could NOT access the internet.  .10 could ping the default route of the core, .11 couldn’t.  The setup as is has been running for almost a year now and working fine until late Friday afternoon.

Annoyingly I can’t access the device that sits at the default route of the core as it’s our ISPs firewall but they’re assuring us that nothing has changed. The only changes I’ve been made aware of at the site are old handsets have been reprovisioned for another provider and this caused a similar issue at another site with Ruckus (I’m awaiting details on the actual issue but I get the impression they’re not actually sure).  Again, this was done earlier in the week but I believe the VOIP providers are making changes remotely to troubleshoot various issues so wondering if they’ve done something that’s potentially affecting the network.

I’m going to head to site and do the usual show cpu, log, 802.1, dm raw, etc. to see if anything jumps out at me but would appreciate it if someone could give the setup below a once over and tell me if I need to be configuring edge ports and admin ports as well as enabling bdpu-guard or any other form of loop protect (and disabling said protection on uplinks).

I’ve removed a bunch of vlans and obfuscated anything remotely relating to actual addressing but hopefully it’s enough to tell you if we’re at risk of loops or broadcast storms currently.
Original got marked as spam so trying again with the configurations to follow.

Appreciate any advice people may have with regards to troubleshooting further.  I’ll look at active traffic first but eventual plan if I can’t suss it is to all the lags down and disable all ports on the core, other than the link to the SRV stack (as that’s where the internet sits).  See if things stabilise and then slowly bring interfaces back up until there’s an issue.

[BenBeck]

Hey there, 

A couple items:

1) For spanning tree best practices, please check this post: https://community.ruckuswireless.com/t5/RUCKUS-Self-Help/Configuring-RSTP-802-1w-and-Spanning-Tree-B...

2) Please upgrade the 8200s to 10010e (10010a is a bit rough to be blunt)

Regarding the connectivity example, it is very hard to say. I would recommend opening a support case for that and having one of our engineers assist in troubleshooting if it persists on 10010e. The forum is probably not the best bet for that one. 

EDIT: I also see rstp hello parameters have been tweaked. Please ensure these match throughout the network or remove them if unnecessary. 

[Killerbot]

Hi Ben,

Got to site and couldn't find anything untoward happening on the network at all but behaviour persisted.  Rebooted the core and all came back up without issue.  I'll speak to the team onsite and ask that they schedule the update for out of hours asap.

Tested what happend when creating loops and STP would block one and keep the other as a forwarder.  I may advise they put bdpuguard on to properly kill the links instead.