Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About jwwork
Community Record
27
Posts
1
Kudos
1
Solution
Badges
This is annoying that they do this. When I upgraded from 10.45 to 11.30 (waited until the ARP table stacking issues were resolved) it went very badly. Basically to the point where we had a total network outage for a day while support tried to figure out what was going on and they pointed me to this in the release notes: Routing to a particular next-hop can fail under specific conditions for non-MS390 switch stacks It seems like there were two causes of this issue and 11.30 only fixed one of them. Now they are pushing out new firmware with what in the release notes? Routing to a particular next-hop can fail under specific conditions for non-MS390 switch stacks I'm starting to give up on the idea that these will ever be ready for work in any type of even medium sized organization.
... View more
Dec 9 2019
12:12 PM
Thank you! Is there a different message that is logged when there is actually a topology change?
... View more
Dec 9 2019
12:08 PM
I know, in the screenshot you can see that I have BPDU guard enabled on this port like I do all my access ports. Just curious if the STP messages in the log are normal.
... View more
Dec 9 2019
10:51 AM
I am working with support on an issue where randomly we have a network interruption that looks like it's caused by some aggregate ports on our MS425 going down and back up and causing spanning tree topology change. The MS425 is the core switch stack. Anyway, looking in the event log I see this a lot on all of our access ports on our MS350's. This is just a normal port connected to a desktop computer. This happens every time a computer is turned on. Is it normal for that to be logged as a STP change? I assume it's normal just wanted to make sure. Here is an example: Here is the config from that port.
... View more
I agree, I enable BPDU Guard on every access port without exception. I was having an issue where it wouldn't disable on a switch to switch trunk which I had not seen before.
... View more
My process when I configure a new switch or stack has always been to set all the ports except for the uplink to disabled, change them to access, and set BPDU guard to enabled. That way when I start configuring the access ports I just have to set the VLAN and enable them. I hadn't had an issue until yesterday. I should have thought to try the cycle port option, I tried to disable and re-enable the port with no luck.
... View more
Yep, It's doesn't really look like a spanning tree problem. The 2960's were set to mst and while the Meraki side is showing its discarding packets because of BPDU Guard the Cisco side of the link is up and it shows the Meraki as the STP root. What it looked like to me is that even though I was disabling BPDU Guard on the port it wasn't actually disabling it. I called support and they had me try a few things and what seemed to work is physically reseating the cable on the Meraki end after disabling BPDU Guard.
... View more
I just installed a new stack of MS350's running 10.40 that has a couple Cisco 2960's trunked off of it. On the Meraki side of the trunks I usually set Root Guard to enabled. When I do that the port shows BPDU Guard activated. I even have tried to set the port to disable STP Guard but I still get the bpdu guard activated error. I have tried cycling ports on both sides but no luck. Is this an issue with 10.40?
... View more
These are completely different subnets. This is happening when I create a new subnets I was working on for an upcoming wireless project. I didn't modify the subnets that any of our VoIP stuff is in.
... View more
Jul 2 2018
8:18 AM
I have a stack of 4 MS425's at the core of my network doing all my layer 3 routing. At the edge I have a mix of mostly traditional Cisco switches with some MS350's starting to get mixed in. We have a Cisco VoIP system that we host on-prem. The other day I had to create some additional layer 3 interfaces on the core stack and I noticed that while doing this, all of our VoIP handsets drop their connection to call manger (display goes blank for a couple seconds, phone shows "registering" then comes back to life). We are running 9.36 on all of the Meraki switches. Any ideas what is going on here?
... View more
May 14 2018
10:03 AM
I just replaced a 6500 core with a stacked 425 core. Edge is a combination of 2960 and 3560 and all running rapid-pvst. Once I migrated all the connections to the new 425 stack I had massive problems with links going up and down etc. Once I changed spanning tree to mst on the switches directly connected back the Meraki stack the problems went away. We have a loop free topology but still had issues until switching to mst. I have additional Cisco switches trunked off those switches that connect back to the core and they are still running rapid-pvst. The switch running mst in front of it will do a pvst simulation to the downstream switches.
... View more
Apr 12 2018
9:27 AM
@MRCURDo you have multicast routing enabled on any vlans or flood unknown multicast traffic? Do you have Cisco phones that also participate in the paging? I was under the impression that they would need IGMP snooping enabled to work.
... View more
Apr 12 2018
9:00 AM
I just posted this in a different thread but it probably goes here also. I too have a network with stacked 425's at the core but currently Cisco 2960's at the edge. We tested our voip paging for the first time since implementing the 425's today and the Cisco voip phones worked but not the Valcom speakers we have. I don't have multicast routing enabled on any of the vlans (425's handle all routing) but have IGMP snooping and Flood Unknown Multicast enabled (by default). I suspected the Valcom horns need multicast routing so I enabled it only on the vlan they are in and stuff all across the network started to drop offline. I had to disable multicast routing on that vlan to get things back to normal.
... View more
Apr 12 2018
8:56 AM
Tested today and the paging to the voip phones worked but we have some Valcom speakers that did not work. I thought the speakers may need multicast routing enabled so I enabled it on only the vlan the horns are in (horns and synapps server are in same vlan) and things all across the network started to go down in every vlan. I turned multicast routing back off and everything went back to normal. I currently don't have multicast routing enabled on any vlan and have IGMP snooping and flood unknown multicast enabled (were enabled by default).
... View more
Apr 10 2018
8:48 PM
The options for IGMP snooping and flood unknown multicast traffic are already on. We haven't tested it yet but plan to in the next day or two. Just wanted to make sure there was nothing else I needed to do. I do not have multicast routing enabled on the vlans.
... View more
Apr 10 2018
4:04 PM
I have a 425 stack running at the core doing all my layer 3 routing. We have around 10 vlans with Cisco voip phones in them. We use synapps to do paging to all phones. What do I need to configure under multicast for this to work? Do I need to enable multicast routing on each VOIP vlan and then create an RP for each?
... View more
Apr 10 2018
3:46 PM
So I discovered that with using the firewall as the gateway DNS requests were not being routed back to my internal DNS servers. Using external DNS servers has got it working. I think when I tried using external DNS the first time I didn't wait long enough for the error to clear.
... View more
Apr 1 2018
10:56 PM
Correct, the switches now have static IP's in the same VLAN as the firewall inside interface. I am offsite and don't have VPN access at the moment. I will check the local status pages on Tuesday.
... View more
Apr 1 2018
11:47 AM
That worked a little. I now have them online with static IP address in that same vlan and using the firewall as the gateway. I pointed them to my internal DNS servers and they went green for a minute but then went back to orange saying DNS misconfigured. I tried using Google public DNS servers as well but got the same error. There should be nothing blocking them from using Google DNS servers at the moment.
... View more
Apr 1 2018
12:20 AM
I will change them on Monday and let you know. Thanks for all the help!
... View more
Mar 31 2018
9:21 PM
Thanks! The firewall inside interface is at 10.X.X.1 and the interface in that vlan on the 425 stack is 10.X.X.2.
... View more
Mar 31 2018
8:51 PM
Ok maybe that is my problem. The default gateway for this switch stack is the stack itself, it handles all layer 3 routing on the network. That would explain why my static IP and DHCP test didn't work but why the DSL connection works, that uses the DSL modem as the gateway. I'm not sure what to set the gateway to.
... View more
Mar 31 2018
8:44 PM
Yes, the behavior is the same if I set the IP info at the local configuration page. The laptop has a static IP, gateway, and DNS set. Same as I tried on the 425's (no DHCP in vlan 2) The laptop can do DNS lookups and get to the internet just fine.
... View more
Mar 31 2018
5:52 PM
The native vlan on the network is 1. The path that the switches would take out to the internet is through a Cisco switch stack and the trunk between the 425's and Cisco allows all vlans. These are the only Meraki switches on the network currently, everything else is Cisco. The Cisco's all also have their management in vlan 2 and they can ping out to the internet fine. I also have my laptop connected to vlan 2 (not direct to the 425's) and it can get to the internet. I have the site wide management vlan set to 1, I just specified vlan 2 on the individual switches.
... View more
Mar 31 2018
3:02 PM
Today I completed a cutover from our Cisco 6509 core to a 4 switch 425 stack. During initial configuration I had the 425 stack connected to an outside DSL that it was getting an IP address on vlan 1. I now want them to ultimately have an IP in vlan 2 set statically (no DHCP on vlan 2). When I change the management IP settings the switches show an error a few minutes later saying they are using an DHCP address on vlan 1 instead of the assigned static IP. I also tried just setting the management IP to use DHCP in a vlan on our internal network but I get the same message. Once I disconnect that DSL connection the switches disconnect from the dashboard. This switch stack does all our layer 3 routing and all my existing Cisco switches on the network have static IP's set in vlan 2 and can ping out to the internet just fine. Any ideas?
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 11104 | Apr 10 2018 3:46 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 1 | 7251 |
© 2024 Cisco Systems, Inc.
