Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Twitch
Twitch
A model citizen
Member since Jan 6, 2019
Oct 14 2024
Community Record
160
Posts
78
Kudos
0
Solutions
Badges
May 26 2021
8:26 AM
@Inderdeep- Thanks for the reply! I am going to assume that this only applies if we're running Systems Manager, correct? We don't have SM configured on our network, at least not that I am aware of. SM isn't an option in the left-hand menu list.
... View more
May 25 2021
1:05 PM
Hey everyone - is there any way to delete entries out of the client list in Network Wide --> Clients? The list has a lot of entries with Device Removed from Network, and I would like to remove those entries if possible. I don't even know where they came from, but I know where I would like them to go. Also, I don't suppose there is any way to force the client list to re-populate/update itself, is there? Thanks! Twitch
... View more
May 24 2021
8:05 AM
1 Kudo
@cmr @KarstenI - Turns-out that our last mile circuit provider had their end of the circuit at the demarc configured wrong. As soon as they fixed it, speeds became normal. So, at this point, our first VPLS connection is up-and-running successfully. I'm going to go home and get some sleep now. Cheers! Twitch
... View more
May 23 2021
10:18 AM
@cmr @KarstenI - This is interesting. Screenshot from the main plant 2901 interface Gig 0/1, which connects to the switch stack. Take note of the interface errors, particularly the Input Errors and the Unknown Protocol Drops. I wonder if something is not talking correctly between the stack and this interface? In contrast, the Gig 0/0 VPLS interface is looking good:
... View more
May 23 2021
9:37 AM
Thanks @KarstenI - we have OSPF running on the VPLS links. That is the reason for putting the 2901s at the edge of each remote site. We tried plugging directly to the stack way back when the circuits were first put in. Our thought was to run VLAN tags over the VPLS between each site, but we have basic circuits that can't pass VLAN tags. The 100/Full requirement was set by the circuit provider. If it is set to anything else, including autonegotiate, the circuit won't connect correctly. What is your setup to have the circuit connected to the Meraki directly?
... View more
May 23 2021
9:31 AM
1 Kudo
@cmr- Good to know that your setup works and is similar to ours. I can try your suggestion, but not until the dsy shift stops working later this afternoon. A few weeks ago with nothing but the two 2901s connected to the VPLS and laptops connected to the internal LAN port (Gig 0/1), iPerf was running at ~95 Mbps consistently. Thanks for the reply!
... View more
May 23 2021
8:29 AM
Morning all. I'm hoping some folks have their ears on. We finally were able to get our VPLS circuit working between two of our plant. It's been one hell of a learning curve for me, but last night I was finally able to get everything working. The only issue I am seeing is terrible speed over the circuit, but only in one direction - download. The circuit is 100 Mbps, but on iPerf, even with the window size increased to fill the pipe so it consumes the most bandwidth, we are only seeing speeds in the neighborhood 4 or 5 Mbps. Speedtest.net shows the same, around 5 Mbps down, and 85+ Mbps up. Traceroute shows traffic taking the correct path. Pings work perfectly. But the speed is terrible. The connection path is as follows, from our south plant to our main plant (datacenter): Meraki Switch-->Cisco 2901-->VPLS Circuit-->Cisco 2901-->Meraki Switch Stack-->MX100-->Internet Routing is being handled via OSPF with Layer 3 Switching on the stack. I have default routes on the Cisco 2901s and the stack has a default as well. OSPF neighbor relationships are up and correct. The route tables are correct. South Plant default route is 0.0.0.0 0.0.0.0 172.16.50.1 (IP of the 2901 VPLS interface at Main Plant) Main Plant default route is 0.0.0.0 0.0.0.0 10.0.0.2 (Gateway/SVI interface of the 10.0.0.0/22 network) Stack default route points to the MX IP of the Transit VLAN. Main Plant 2901 has the following config: Gig 0/0 172.16.50.1/24 Gig 0/1 10.0.0.3/22 We have full connectivity over the VPLS between both plant (finally!), but the speed is bad. The 2901s have their VPLS interfaces set to 100/Full. I know there are quirks of Meraki when it comes to reachability of SVI interfaces, especially in terms of ping, tracroute, etc, but they still work correctly. What I am wondering is this: since the default route of the Main Plant 2901 points to the SVI of the 10.0.0.0/22 network, would this cause issues with speed since SVIs are notoriously unreachable? I tried pointing the default route to the IPs of the Transit VLAN instead, both on the stack and on the MX, but that brought the Internet connection for south plant down completely. I'm guessing that since routing works fine despite the ping issue with the SVI, pointing a default route to the SVI should work fine also? The default route on the 2901 certainly does it's job correctly. I just can't figure-out why the speed is so bloody awful. I attempted to point the Main Plant 2901 default route to the exit interface, but received the following message about the route not having a gateway, and this also took down the South Plant internet connection: Has anyone else experienced this issue with circuit speed when a default route points to an SVI? Or a speed issue in general when connecting Meraki gear to traditional Cisco routers? I have a ticket in with the circuit provider. Thanks!! Twitch
... View more
May 21 2021
6:10 AM
@Bruce- It appears that your theory about excessive STP activity is correct: **Update** I just spoke with support and they told me the overall STP topology looks stable, and that these events in the log are most likely not having much of an impact.
... View more
May 20 2021
2:54 PM
Good points, @Bruce. I have opened a case with support. Thanks much!
... View more
May 20 2021
12:46 PM
Get Woke, Go Broke. Be careful playing around with the critical race theory stuff. Keep your customers happy, not the woke mob, not woke celebrities, not woke politicians.Your customers and stakeholders are what matter, not the woke garbage. Cisco makes awesome networking gear. That is the company's job. Please, for the love of networking, stick to doing that, and don't go Woke. It won't end well. Just ask Coca-Cola and Disney.
... View more
May 20 2021
7:34 AM
@Bruce- I have to say, though, that the ratio of failed pings to successful pings HEAVILY favors failure, probably in the vicinity of 95%+ failed. I could see if it was an intermittent issue, but the failed pings seem to be the norm. I can't imagine that would be considered normal? The implication is once I put our data center production network on OSPF in the next few days, I will no longer be able to ping the default gateway for our 10.0.0.0/22 network, which is 10.0.0.2. It's the layer 3 address on the stack for the 10. network. I would imagine it will be reachable for production traffic, but quite possibly not reachable to ping tests to the gateway address when troubleshooting an issue.
... View more
May 20 2021
5:17 AM
Morning @Bruce - the pings do come back eventually, but then then disappear again. Functionality seems to be fine - pings out to the interwebs work fine, websites can be reached, etc. The pings only fail when going to the layer 3 interface. Since they work then fail, then come back again, perhaps the issue is the switch dropping the ICMP packets due to demand for resources and pings are just a low priority operation like you said. Thanks for the reply!! Twitch
... View more
May 19 2021
7:22 PM
Evening all. I did a test with enabling OSPF for several Layer 3 interfaces on our switch stack this evening. A few moments after clicking save I lost ping to those interfaces. For example, I had a continuous ping going to the 10.0.100.1 interface that lives on the stack and had 100% successful replies with 0% loss. I then enabled OSPF for that interface and a few moments later I had 100% loss. Is there a quirk with OSPF on Meraki that causes loss of ping to an Interface after OSPF is enabled? Or is this a sign that there is a another issue within the network that is causing this?? Thanks!
... View more
May 18 2021
9:55 AM
@RomanMDOur network here consists of an MX, a three switch stack, a lot of access switches, and access points. The point of the Management VLAN that I created is provide a network for devices to use to reach the Dashboard separate from the Production VLANs that exist on the stack. There is a caveat with layer 3 switching that the management network cannot have an interface on the switch stack (though there is an exception in SNMP is not running, as @PhilipDAth shared in a reply to a different post recently). Using the Management VLAN allows all of my switches to reach the Dashboard on a network that is separate from the production network. I have it on the MX so my devices will remain connected to the Dashboard even if I royally screw something up with the production network config. The only reason I have an interface for the Management VLAN is because a support rep I spoke with said it needed to be there, and I respected his knowledge on the subject. I do not have enough knowledge/experience with Meraki to be able to argue otherwise. The Meraki world is new to me. Hope this isn't clear as mud. 😉 Twitch
... View more
May 18 2021
8:54 AM
@CptnCrnch @Inderdeep - Thanks much! This turned-out to be the solution to my problem I was having with my client VPN after transitioning to L3 switching on our stack. The authentication between the MX and RADIUS server was broken, and the client VPN was failing when using RADIUS. I reset the Secret password on the MX and the client VPN started working perfectly again. Thanks for the response!! Twitch
... View more
May 18 2021
8:40 AM
2 Kudos
Hey @cmr - Your suggestion to turn on logging for RADIUS as well as the 16 code got me there. In addition, some other threads I found on the Community helped a great deal as well. This link as well: https://documentation.meraki.com/MX/Client_VPN/Troubleshooting_Client_VPN#Windows_Error_789 What a relief. Ironically, I managed to fix it 20 minutes before my ECMS2 class was set to begin. I'm really looking forward to this class filling in the many gaps in my Meraki knowledge, and if it isn't obvious, those gaps are many. Thanks again everyone!! Twitch
... View more
May 18 2021
8:12 AM
1 Kudo
@cmr @Bruce @PhilipDAth @RomanMD - Gents - I was able to get it working. It appears that the shared secret used between the MX and the RADIUS server had somehow unsynced themselves (for lack of a better term). I reset the secret on the MX and the Client VPN connected via RADIUS like a hot knife through butter once again. It connected via 192.168.20.2, which is the MX IP of the Transit VLAN. All shares and network resources are accessible. Thank you so much for all of the replies and assistance. Please excuse my inexperience with RADIUS and NPS and my lack of understanding of how the Client VPN setup works on the MX, especially the role of the shared secret between the MX and RADIUS server. This community is awesome. Probably the best support community on the interwebs. Now I just have to get OSPF running. Have a great day everyone! I know my day just got a WHOLE lot better. Cheers!! Twitch
... View more
May 18 2021
7:52 AM
@cmr- With 192.168.100.1 configured in the RADIUS NPS I did not see any requests coming in. With 192.168.20.2 configured, I did see a request come in and a log file was created. I don't see anything in the log, however, that indicates success or failure, but the connection did fail. I did see this however. Not sure if it helps: <Proxy-Policy-Name data_type="1">MX Radius Authentication</Proxy-Policy-Name><Packet-Type data_type="0">3</Packet-Type><Reason-Code data_type="0">16</Reason-Code></Event>
... View more
May 18 2021
7:32 AM
Thanks @cmr - I will get the logging enabled and see what I can find. I'm stuck between comments here and what support told me as far as which interface the RADIUS server is going to use to reach the MX - support said it will use the IP of the Transit VLAN, and @Bruce believes it will use the MX IP of the Management VLAN. What's strange is I can ping the Transit VLAN MX (192.168.20.2) IP, but I cannot ping the Management VLAN MX IP (192.168.100.1) from the RADIUS server. If the RADIUS server does in fact need to use the Management VLAN MX IP, the server can't reach it for some reason. I can, however, ping both ends of the Management VLAN between the MX and the stack. Nor can I ping 192.168.100.1 from my desktop. From the RADIUS server to the MX Management IP: From my computer (in 10.0.0.0/22) to the same destination IP:
... View more
May 18 2021
6:58 AM
@CptnCrnch- Perfect! Thank you. So the second one needs to be the same on both the MX and the RADIUS server, correct, or the connection between the two will fail?
... View more
May 18 2021
5:57 AM
Can someone explain the difference between the Shared Secret and the Secret passwords in the screenshot below, please? Thanks!! Twitch
... View more
May 18 2021
5:52 AM
1 Kudo
Morning @cmr - here is the trace from a laptop connected to the client VPN (via Meraki Authentication since RADIUS is down) back to my computer -
... View more
May 18 2021
5:10 AM
Here is the current MX config: And here is the Layer 3 on the stack:
... View more
May 18 2021
4:56 AM
Good morning, @Bruce. You raise some interesting points. Management is 100. Meraki support told us that we needed to use the MX IP of the Transit VLAN for the RADIUS config on the domain controller. At the same time, they also said we need a Layer 3 interface for the Management VLAN on both the MX and the switch stack. I will check on the Layer 3 issue that you raised. I do know that pings to the Transit VLAN MX interface - 192.168.20.2 - are solid with no drops. Here are two traceroute results, one to the Transit VLAN MX interface which drops the second attempt, and another to the Data VLAN IP gateway, 10.0.0.2 (it's also the gateway for my computer) with no drops at all. It seems that the drop is only happening when sending a trace to the Transit VLAN MX IP. This has been such a mess. I really appreciate everyone's help. Thanks.
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 7 | 42394 | |
| 5 | 1208 | |
| 3 | 20572 | |
| 3 | 9863 | |
| 3 | 24394 |
© 2024 Cisco Systems, Inc.
