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 Twitch
Community Record
109
Posts
44
Kudos
0
Solutions
Badges
Monday
@Greenberet- Thanks for sharing that! We will definitely check that out. Fortunately, my boss is a Code Monkey. Much appreciated.
... View more
Monday
3 Kudos
@cmr- If I am correctly reading this document: https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Best_Practices_for_Merging_Networks_and_Organizations Merging the organizations involves completely dismantling all of our networks and rebuilding them from scratch in the new merged organization. From what I am gathering, nothing is transferable except the devices and the licenses - the configuration and all settings would be toast and have to be rebuilt from scratch. That does not sound like a fun weekend...
... View more
Monday
@cmr- That is the other option on the table. I have not started digging into that one yet. Hopefully Meraki has some documentation on how to do that. Without having to go into too much detail, how complicated is it to combine organizations?
... View more
Monday
@Bruce- Interesting idea. That almost makes my head hurt just reading it. 🤣 I can see how that would work, though.
... View more
Monday
1 Kudo
@Inderdeep @UCcert - Thanks for the replies. You both have confirmed my suspicions about how the VPN would have to be setup. @Inderdeep- That first bullet item causes me to wonder if the route advertisements will work with L3 switching enabled on our switch stack. We no longer have any subnets that are local to the MX, only static routes that point down to the stack. I'm thinking the static routes will still be advertised, since most of the routes have the "In VPN" box selected to advertise the static route to other VPN peers, which should work just fine for the non-Meraki peer VPN connection as well.
... View more
Monday
2 Kudos
Hey gang - what is the best practice for configuring a site-to-site VPN between two different organizations, for example, between our company organization and the organization of the parent company who just purchased us? Both sides have Meraki MXs at the edge. Based on reading that I have done, it looks like the site-to-site will need to be established as non-Meraki peers since two different organizations are involved. If that's the case, the docs also state (if I'm understanding it correctly), that route information will not be shared between the non-Meraki peers, which presents a problem of reachability for remote networks on both sides. Thoughts and/or clarifications would be greatly appreciated. Cheers! Twitch
... View more
3 weeks ago
@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
3 weeks ago
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
4 weeks ago
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
4 weeks ago
@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
4 weeks ago
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
4 weeks ago
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
4 weeks ago
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
a month ago
@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
a month ago
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
a month ago
@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
a month ago
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
a month ago
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
a month ago
@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
a month ago
@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
a month ago
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
a month ago
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
a month ago
@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
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 3 | 116 | |
| 3 | 2954 | |
| 3 | 3106 | |
| 3 | 217 | |
| 2 | 212 |
