JRA

Had it in mind to give that another look. Did check that early on in the process but didn't see anything, though wasn't sure if it'd dropped before anything registered. Not super-recently, end of Sept, still on Leeds 62. Oooohh, yeah we are in an SFP. I might keep that idea in my pocket. Did spot that from your earlier messages and isolating clients from other clients on the same APs now in Ruckus, though haven't turned on the option available to isolate from all hosts on subnet (option there too to whitelist GW, might also try and re-jig the NIC on the Mac server/s to live in that VLAN also for the cache-ing should I enable that one.) Thanks much for all that.

Okay so we're still getting them. Student wifi off overnight and no dropouts, student wifi on in the morning, dropouts (mostly) every even-numbered hour throughout the day. What I'm wondering is if the routing here is contributing to it. The network transitioned to VLANs from a flat network about 2 years back, but the next hop is on the same VLAN (VLAN1, default) as the rest of the switches. I have made a diagram (beautifully) in MS paint: "Normal" network with the next hop on a firewall <> core switch VLAN (example IPs: ) This network: So the thing I'm thinking is, the Jamf check-in from the ipads is looking like a broadcast storm on VLAN1 to the core switch, which then wets itself and breaks the stack. The stack then quickly rebuilds and we're all fine until the next one. On the rare occasions there are NO dropouts with the student wifi on, on the even-numbered hours, we may just be squeaking enough traffic through to not upset it. To that end I'm tempted to take a bravey pill and turn off spanning tree completely just on the core stack and let it chew through all that traffic just for the 2 min it needs to, see if that does it. Failing that the core stack is due a firmware update later so I'll run that too, changing two variables in one night like a good scientist. Anyone passing have any thoughts on that one? Thanks whoever's still reading!

Cheers for that, from what I'm digging up setting that priority lower looks indeed to be the way (I take it you mean set the priority lower, not the bridge ID.) No idea how I knock off the root port yet but will be one to try as part of all this. Haha deep joy, my network here comprises these Cisco small business switches.

Ok, now I think I might be even closer to it. It's likely the iPads causing the issue to manifest rather than them being the actual culprit. Which is a shame, I enjoyed it being Apple's fault. Looking at the spanning tree config on the core stack, I see this: Now, my knowledge of the guts of spanning tree isn't amazing, but I should imagine (and please do steer me right if I'm not right) that I should INSTEAD be seeing the root bridge ID as being the bridge ID here (as in the "boss" route for spanning tree should be the links twixt the four switches in the stack which make up my core switch here.) And also, that priority for the "boss" bridge should be 0. Or lower than default at any rate. So, what the heck is that odd bridge ID? Well it's this: Looks like one of the edge switches in an out-building we have has the LAG connection (going to switches #1 and #2 of the core stack) with the root bridge ID! And by my reading of it, port TE2/0/14 is a major culprit in the flap logs, which plugs into my favourite suspect in this, being switch #2 of the core stack (the other being in port 14 of core switch #1.) A couple more edge switches to rub it in: That looks to be worth re-working. As I mention not super with Cisco gear so if anyone passing can check my thinking that'd be great.

So I'm fairly certain at this stage it's something iPad-ey. Dropped in for a few quiet Sunday hours, scheduled the student wifi off over the weekend and have had NO dropouts. Thanks for this one. Had a good rummage through your thread, also have some options to explore in our (ancient) Ruckus wifi along those lines. Happy to say though the problem is at least pinned down! Cheers everyone who helped.

Well I surely am trying to do exactly that. Did you have any suggestions on the issue?

Could be for sure. I'll check over those if my Jamf theory doesn't pan out, though I'm pretty sure it's quacking like that particular duck at this point. Cheers.

Juicy juicy clue this morning from Jamf; dropouts seem to coincide with the iPads "checking in". I knew it was Apple's fault. Let's see if (hopefully) we can throttle that...

I'll see if I can try that somehow, that might be worth finding out indeed. Ok with my Sherlock Holmes hat on I've sniffed out the following schedule to the dropouts: 16th Jan: 14:00 18:00 20:00 22:00 17th Jan: 00:00 02:00 04:00 06:00 10:00 14:00 16:00 20:00 22:00 18th Jan: 00:00 02:00 06:00 08:00 To me that heavily implies it's something traffic-ey overloading the poor things. Currently exploring options in the phone system spamming out updates, maybe the iPads now (recently moved to Jamf.) After that I dunno, cosmic rays I guess. Thanks everyone for carrying on with me.

And as luck would have it, just had a dropout. Lost the ping to the other building AND the ping to the device going into switch #2. So I'm thinking some issue with that switch as I can still get onto the stack by the IP address, and switch 1 shows as the only member of the stack. Of course, only lasts a minute then it's all back on. Urgh. :/

I mean it could be I guess, any easy ways to tell? I haven't changed anything stacking-wise at all. Which I know is not the same thing as saying nothing has changed, more meaning it wasn't me if so I swear! Pinging a ubuntu box I had sat around which is now in switch #2, also pinging a switch on the far end of the fibre run in the other building, logging both to text files. Hoping that'll show me a clue in if they BOTH drop out at the same time then switch #2 might be the issue, and if that ubuntu box ping carries on at any time the other drops out then more likely connectivity between switch #2 and the other building might be it. Thanks everyone for joining me on my annoying network adventure!

Running that gives me "incomplete command" - actually did have to turn on telnet earlier as it looks like nobody's ever putty-ed/CLI-ed into these before now. Did wonder that briefly but I'm not sure on how I'd determine that. Anything useful in the logs? (if you can even see those there ofc.) Sure could be a possibility. I suppose a good test would be to -t ping switch #2 in the stack for a day and see if that ping ever drops throughout the dropouts. I myself (bear with me here) connect to another switch which is on an LACP trunk to switches #1 and #2 so if I drop packets to switch #2 during a dropout it's a clue switch #2 is upset, and if I don't it's likely connectivity between switches #1 and #2 <--> switches #3 and #4. Worth a stab?

Thanks there! Ok hopefully these pictures come out. Cisco SX550X switches, switches 1 and 2 in the server room, switches 3 and 4 in another building. All over fibre but not sure what VSS is tbh. Snips of all those bits here: Interesting #2 switch says it's on "standby". Cheers again.

Morning all, Well this one is truly mashing my swede. Not long been at a new place and having network dropouts. Just a minute or two maybe once or twice a day during school hours, but definitely get a couple overnight too ( set a -t ping going.) Cisco switches throughout (except a couple of lil Netgears in the office,) only major change I've made here was moving to Jamf over Christmas. Have a Mac mini here as cache which seems to be working ok. Could be a red herring, could maybe not be. No real pattern to it it seems, and whenever I seem to find one suddenly there's not one. However logging onto the core switch (which is four switches stacked, two in the server room and two across in another building) things get very curious. Firstly, logs have this repeating loads: Next, this blip appears just the one time I noticed: A full-on crash (amidst the SSL cert howling on it) looks like this (lots and lots of pics of this one:) From dashing to the server room it does look for all the world like switch #2 in the stack is flapping somehow, but I'm not seeing at the moment what those logs are trying to show me. If anyone who is a whizz with Cisco gear is looking and it's really obvious please do let me know! If I crack it in the meantime I'll post up what fixes it. Really has me stumped for now though. Thanks all.

This still going on there? Do other phones in the same switch work ok? Wondering if the VLANs may or may not be there on the trunks between switches if not (check both ports on the trunk. And also triple check the VLANs are right on the port you're configuring on the phone been MANY times I've just not saved something and chased my tail for a day.)

Very very newly rolled out Jamf (though used it before now) but mine's been ok. Are you still having issues?

I'd say go a bit further with it and, if you can deploy genetic re-working of animals through nanomachines then we could group them up and deploy templates to them. Like Jamf but for animals. There'd be teething problems I'd imagine, like all the lions go "quack" until the new firmware comes out and all the marmosets display "incorrect password" until we manually reset them.

Is the Smoothie box official hardware or is it something else, perhaps with RealTek cards in it?

Or one of those giant squid.

And today I learned there are people jamming ALL SORTS OF ANIMALS down pipes and crevices in networks all across the world. This thread is real, right? I gotta stop day-drinking...

I mean I just don't think we're beating this one. "I fixed the network with a ferret."

Whatever you get try a demo model first. Have a cautionary tale in an interview we did back in the summer. We asked one guy a question on "what's the biggest mistake you've made in your career and how did you resolve it?" The poor bloke answered that he'd bought about forty interactive touchscreen TVs and whenever you exited a fullscreen Powerpoint it'd do something to them and they'd not see the PC input again until you restarted the TV itself. As you might imagine now we've started demo-ing that's the FIRST thing I tried out lol. Cannot for the life of me remember what the make was though.

Ahhh it's like you're here! Just taken the helm myself at a (rather decent) place but with ancient WiFi. One Ruckus ZD1112 on 9.8.3.0. Hopefully I'm not too late also. I've expanded what we had with more R500 APs (we were licensed for 25 but only used 18 or 19 when I got here.) Mostly buying them off eBay, scraping the cobwebs and barnacles off them and downgrading or cross-then-downgrading firmware. Now have all 25 provisioned and ready. And come Easter it'll all be going in the bin but hey at least until then I can beef up what we have. With the R500s I found the ZD will, in the process of adopting them, try to downgrade the firmware itself from 100.1.0.0.194 to 9.8.3.0.14, but getting them onto a downgrade-able version was the thing. If an AP arrived on a firmware that'd just go down nicely using R500_100.1.0.0.194.BL7 then all well and good and the ZD would do the rest on adoption, but if not I found I needed to stick on the solo ap firmware 104.0.0.0.1347 to get it to behave, and THEN put on R500_100.1.0.0.194 and proceed. More here: https://community.ruckuswireless.com/t5/ZoneDirector/R500-wont-downgrade-from-10-1-1-0-55-to-9-9-0-0-216-on-ZD-or/td-p/16333

I'm legit doing the same thing as you over Christmas, except I've only got 300. Going from Mosyle and unending suffering to Jamf and no doubt blissful academic perfection. I'll race you.

I had often wondered how the GDPR vs CLOUD Act business would work itself out when it came to an inevitable head. "Messily" seems to be the answer!