Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Become a member of the Cisco Meraki Community today
Get answers from our community of experts in record time.
Join now- About ErnestG
About ErnestG
Community Record
7
Posts
2
Kudos
1
Solution
Badges
Wednesday
Update: We have identified the issue or at least found where it resides. Turns out the problem is indeed related to high latency/packet loss somewhere in the AT&T MPLS network. We set up PCs at each end of the MPLS circuit, directly connected to the PE routers and configured with static IPs in the same network as the 2 switches. We used PRTG network monitoring software so that we could monitor the circuit without spanning-tree related interference. We had 2 root-bridge reelections again this afternoon. The event logs in the Meraki network showing this and the testing logs from PRTG align perfectly for both events, down to almost the second. We see errors/timeouts in ping/traceroute testing, and usually the first successful trace after the timeouts shows latency between 700-950ms in the monitoring event log for PRTG. So, it does not appear that the Cisco or Meraki devices are having any issues, and the Meraki is just doing what it's programmed to do when the root-bridge is no longer reachable. Thanks all for your help on this one.
... View more
2 weeks ago
Not a whole lot, to be honest, which is why I came to the Community site. They said to get packet captures on the Catalyst 4500 side of the link, to see if the Catalyst is "receiving superior BPDUs". That doesn't seem likely as we have all the switches in the Meraki network side of the link accounted for, and all are set via the Switch Settings page with a far higher (less preferred) priority. The one thing about the Meraki network in question is the MPLS/Switched Ethernet link between it and the HQ network where the 4500 is located. It's the only site connected in this way to extend the layer 2 topology, so I keep wondering if there's something within the provider network causing just enough of a delay in BPDU packet communication for the Meraki side. The Event Logs were clear all the way up until just prior to midnight, then I see a sudden burst of a few root changes, where the Meraki switch becomes root, gives it up after a brief period, becomes root again, and so on. Very random, and then it goes quiet again and there have been no issues on the link for at least 9 hours now.
... View more
2 weeks ago
We have a Meraki Switch (MS250-48P) that is set w/ an STP priority of 61440, and it has a single uplink to the Internet that is reached via an AT&T Switched Ethernet Circuit (MPLS) that extends the L2 network over to another location where the ISP DIA resides. At that location, there's a Cisco Catalyst 4500 that the Meraki connects to, and that 4500 is the root-bridge for the L2 network. The 4500 is set with a priority of 4096 for all vlan's, and has root-guard configured on every port that downlinks to another switch so that the 4500 will remain the root-bridge. Root-guard is also applied on the catalyst 4500 port that links back to the abovementioned Meraki switch over the MPLS circuit. However, at least twice a day (and sometimes more than that) the uplink port on the Meraki switch transitions from a root port to designated, and the Meraki switch becomes the root-bridge. Usually this does not last for long (less than a minute in most cases) and the switch quickly loses the root bridge designation, and the Catalyst 4500 again becomes the root bridge. To my knowledge, no other switch in the Layer 2 network is set with a better (lower) priority. My question is this: what could be causing the Meraki switch to become the root? The Physical ports on both ends of the AT&T MPLS circuit (at least the ports on our gear) are clean: no crc's, no fragmentation, no output drops, etc. Could this be due to an issue with Spanning-Tree mode incompatibility? The 4500 is running rapid-pvst and the Meraki of course is running RSTP. The inconsistent/intermittent nature of the problem makes it a bit more confusing to me, tbh. When I run the "show spanning-tree detail" command on the 4500, each vlan shows that it "is executing the rstp compatible Spanning-Tree protocol", so that sounds promising, though I'm still not sure. Any ideas, suggestions, or questions are welcome. Really turning into a headscratcher at this point, thanks for your help in advance! -Ernest
... View more
Thanks for the info, we will look into this and try to just upgrade a small network first. Thanks!
... View more
Jun 5 2023
7:23 AM
We had the customer roll back from 15.21.1 to 14.33.1 and all issues were resolved. I had wanted them to reboot their DHCP server, and/or the uplink switch where the UDLD alerts and DHCP blocked events were occurring before doing that, but they could not afford any further downtime. Is there a way for a customer to isolate a network device or devices with a newer firmware version before deploying it to the full network? I'm not sure that there is but thought I'd ask. I'll leave this thread open another day or so then close it.
... View more
Thanks for the feedback. I'm fairly convinced the issue is more isolated to the switch we were having issues on, and the fact that it worked fine after we bypassed the wireless bridge uplink tells me the firmware is likely not the problem. TAC recommended a rollback since the customer states that it worked fine on the prior firmware version, and I'll be curious to see if that resolves the issue. If no one else is seeing similar types of problems though, I can't see how the firmware is a problem. Thanks again cmr!
... View more
May 30 2023
11:55 AM
We have a customer that recently upgraded some of their Meraki switches to 15.21.1. After doing so, they started to notice issues with DHCP (external server, no Meraki-run DHCP) and devices only getting 169.254.x.x self-assigned IP addresses. Checking the uplink switch that this switch connects to, we ran packet captures on the uplink port that feeds the problematic switch. We noticed DHCP Discovers and Requests, no Offers or Acknowledgements coming to and through the port. Also, the event log showed a ton of DHCP blocked messages. Digging further, we also saw UDLD alerts on this port, and the link negotiating at 100 Mbps instead of 1 Gbps. I learned at this point that the uplink switch and problem switch are connected via a wireless bridge that uses a Ubiquiti wireless device on each end. Back on the switch in question, one of the AP's connected to it appears to be getting assigned dozens and dozens of IP addresses from within the DHCP pool, which is probably why there's a lot of DHCP blocked messages on the uplink side. The customer states that this issue was non-existent before the upgrade. The main troubleshooting step we have tried thus far is to have them move the problem AP and the problem switch over to the same location as the uplink switch, and instead of connecting over wireless bridge, connect physically direct. Once this was done, all problems vanished. DHCP worked fine and there were no further disruptions. While it seems like the wireless bridge is the problem, the customer is frustrated by the fact that it worked just fine prior to the code upgrade. In addition, he's now saying there are other switches in their network that are running on that code and experiencing "intermittent" connectivity issues as well. Has anyone else encountered these issues and do you think the focus should be on the firmware? Any suggestions welcome as this is a weird one.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 130 | Wednesday |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 2 | 5162 |
© 2025 Cisco Systems, Inc.
