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 17 2021
3:41 PM
@cmr- No worries! The trace went just like you thought it would: 192.168.20.2 is the Transit VLAN IP on the MX. I need two VLANs to run over the link between the MX and stack - the Transit VLAN, and the Management VLAN. For that reason, I don't think I can make it an access link.
... View more
May 17 2021
1:38 PM
So this is a strange one - one of the computers that runs a machine in our shop is reporting an IP address that is not even remotely close to what it is actually configured with via static IP. The client should be reporting 10.0.8.196, but instead, it is reporting what you see here: The subnet that the client resides in is 10.0.8.0/22, nowhere near the IP listed above. In fact, the client is configured with 10.0.8.196, which is pingable and reachable from within the network it resides in. However, from across town at our other plant, the program that is used to reach the machine itself and program jobs into it cannot reach it - the program crashes and throws and error. I do not have access to the client config, unfortunately - that is managed by the manufacturer (Voortman). That 5.x.x.x IP address has to be coming from the client computer. We do not have anything on our network that uses a 5. address range. In keeping with tradition, however, the vendor says it has to be coming from within out network. The MAC address is correct, but the IP is waaaaay off. I think this address issue is the cause of the reachability issue, but talking to the vendor about it is worse than beating my head against a brick wall covered in spikes lathered in COVID. The make things even stranger, I ran this 5. address through Advanced IP Scanner and received this back: ??? What I am wondering is if there is a way to clear possibly stale and/or incorrect information out of the Merakis? I would like to delete this client entry and let it refresh itself, or clear the ARP cache. Does anyone know if there is a way to get rid of the cache on Meraki gear? Thanks. Twitch
... View more
May 17 2021
12:30 PM
@cmr- Traceroute actually returns no results: Both the 192.168.20.3 and 10.0.0.2 are VLAN interfaces on the switch stack. Could this be a Native VLAN issue? Is Client VPN traffic tagged or untagged? One the Meraki support reps that I spoke with told me to set my Native VLAN to match the Transit VLAN, which is 20. He had me configure this on the Per-port VLAN Settings on the trunk link between the stack and the MX, as well at the stack end of the trunk. The rest of the network is using Native VLAN 1. Could it be that the traffic is being dropped as it's coming back up from the stack? Our data center traffic is using VLAN 1.
... View more
May 17 2021
10:36 AM
@cmr- No joy. Added the static route pointing to the Transit VLAN interface on the MX and we still have the same problem. We tried with RADIUS and Meraki Authentication, but the problem remains.
... View more
May 17 2021
10:24 AM
@cmr- I read your message backwards. I didn't see that you said from the stack to the MX. There is not a route there, either. I'll add it. Hang-on.
... View more
May 17 2021
10:19 AM
@cmr- No, there is not a static route currently. Does a layer 3 interface need to be added to the stack for the 10.10.10.0/24 network, or just a static route pointing to the stack Transit VLAN interface?
... View more
May 17 2021
10:06 AM
Would this have anything to do with the mode our MX is in? Currently the MX is in Routed Mode since all of the VLANs lived there. Does the mode need to be changed to Passthrough or Concentrator Mode now to accommodate layer 3 switching????
... View more
May 17 2021
9:42 AM
Thanks for the replies, Gents. @RomanMD- I believe you are correct. Meraki support recommended using the transit VLAN interface that resides on the MX, in our case 192.168.20.2, and used to be 10.0.0.2, which is the default gateway for our data network. I added a RADIUS client with 192.168.20.2 to the domain controller via Network Policy Server (based on a doc I received from support), but that didn't change anything - clients are still unable to authenticate via the VPN because a "domain controller cannot be found." We are using Meraki authentication for the VPN as a temporary workaround until we can get RADIUS working again. @PhilipDAth- You are correct - I deleted the VLAN interface that the VPN was using on the MX and moved it to the switch stack (10.0.0.0/22). The only remaining interfaces on the MX are the Management VLAN (192.168.100.0/24) and the Transit VLAN (192.168.20.0/24). All other interfaces now reside on the stack. You are also correct regarding the default route on the stack which points to the MX IP of the transit VLAN, 192.168.20.2. There should not be any subnet conflicts that would be overriding each other. The client VPN is using 10.10.10.0/24, which is unique in our environment. It seems like the traffic is arriving via the client VPN but not being passed correctly to the 10.0.0.0/22 network to reach the DC for authentication. There is a static route on the MX for each subnet that points down to the stack Transit VLAN interface of 192.168.20.3. Internal to the network traffic is flowing like a hot knife through butter. Traffic on the site-to-site VPN is also working fine from all remote locations - everything is accessible. @cmr- You are correct - users connecting via the client VPN are unable to reach the DC for authentication or reach the primary data center network of 10.0.0.0/22, which is also where the DC resides along with the file shares. I re-used every interface - same IP scheme, gateways, and VLAN numbers. The VLANs that were living on the MX now live on the switch stack dot for dot - I figuratively picked them up and stuck them on the stack. In fact, the only new VLANs are the management VLAN and the Transit VLAN, both of which live on the MX and the stack with their respective interfaces on each. Our stack is comprised of three MS250-48 switches, stacked together. We do not yet have an active/standby setup, so all switches are active in the stack. All production VLANs have been removed from the MX as noted earlier. I truly appreciate your thoughts, guys. This is the only fallout of the change. If I can figure this out and get it going I can move on to getting OSPF implemented. Thanks!! Twitch
... View more
May 16 2021
11:52 AM
Hey folks - I have a situation that I could use some help and suggestions with. I transitioned our network from inter-VLAN routing on the MX to inter-VLAN routing via layer 3 switching on the switch stack. I started this process last night at 10:00 pm and had to deal with several frustrating issues, mostly related to OSPF. We finally have it running without OSPF for the moment after many hours with Meraki support trying to figure-out what in the heck was going on. We have one lingering issue that we can't seem to beat: Before moving the VLANs to the stack, the client VPN worked great. Now, not so much. Clients were connecting via RADIUS authentication without issue, and network resources such as file shares and databases were available for the using. Unfortunately, after moving the subnets to the stack, that accessibility has all but vanished. We had to switch to Meraki Authentication from RADIUS because clients could not get authenticated. We updated the Network Policy Server to reflect the changes in the network, but still no joy getting authenticated and connected. Also, access to network shares and databases, etc., has all but disappeared. Has anyone else experienced such a loss of connectivity after implementing layer 3 switching??? Thanks! Twitch
... View more
May 16 2021
11:38 AM
1 Kudo
@wwYour suggestion worked perfectly! Marked as solution. Thanks! Twitch
... View more
May 14 2021
6:04 AM
Good morning to the Crew - We block social media websites with content filtering. Our HR department has a need to access Facebook in order to post job openings. We would like to allow Facebook for the HR team but no one else in the company. I know that I can just whitelist their computers, but is a more granular approach available that will allow me to grant access to Facebook for specific users without having to whitelist them and open-up everything else as well? Thanks. Twitch
... View more
Apr 27 2021
12:09 PM
@PhilipDAthGreat point. I'll have to try that during the upcoming downtime we have scheduled.
... View more
Apr 27 2021
12:05 PM
One more question for everyone - when you enable layer 3 switching on a stack, that enables it for all of the switches in the stack, correct? So if I enable layer 3 switching for switch 1 in the stack, that turns it on for all three, correct? Or do I need to enable it for the stack separately?
... View more
Apr 27 2021
9:40 AM
Hey gang - anyone really good with iPerf? I'm getting a really bizarre result that appears to demonstrate that our circuit provider is throttling our speed over a site-to-site VPN connection. The connection is supposed to be 100 Mbps, with 1 Gbps within the network at either end. A screenshot of the iPerf3 result is below. Notice how it starts at 679 Mbps in our network, and then just plummets to roughly 30 Mbps over the site-to-site circuit. Repeated tests show the site-to-site circuit running in the teens on occasion. The circuit provider claims we are not being throttled. I can't find anything in the Meraki gear on either end (MX100 and MX84) that would throttle the connection. We have had a network performance issue between these two plants for a while now, and repeated attempts to try and determine why have come back empty. When I run the test over our new 100 Mbps VPLS circuit, I get an average of 94 Mbps end-to-end consistently. Has anyone else seen similar results? Thanks. Twitch This test is running from a domain controller at our other plant over the site-to-site to my workstation:
... View more
Apr 27 2021
4:10 AM
@PhilipDAthThanks for the info. Where do you typically put the management VLAN - on the layer 3 switch, or on the MX?
... View more
Apr 24 2021
4:36 AM
Good morning everyone. I have a question about layer 3 switching and the management VLAN. We have a switch stack comprised of three MS250-48 switches. I am preparing to move from inter-VLAN routing on the MX to L3 routing on the switch stack. Our current config has the management network in VLAN 1, network 10.0.0.0/22. All network devices have a management IP in this subnet. This is also the subnet that just about all network devices reside in, including all of our servers (WiFi and VoIP have their own VLANs). All VLANs currently reside on the MX100, which is also where all inter-VLAN routing occurs. All of the VLANs will be moving to the switch stack in order to use OSPF to route traffic across our VPLS circuits, including VLAN 1. The screenshot below is from the Layer 3 Switch Example document found here: https://documentation.meraki.com/MS/Layer_3_Switching/Layer_3_Switch_Example There is a statement about switch stacks and the management interface that has me concerned: For switch stacks performing L3 routing, ensure that the management IP subnet does not overlap with the subnet of any of it's own configured L3 interfaces. Overlapping subnets on the management IP and L3 interfaces can result in packet loss when pinging or polling (via SNMP) the management IP of stack members. Given that I will be moving VLAN 1 to the switch stack, and since our management addresses also reside in VLAN 1, will there be a conflict between the management IP addresses and the layer 3 interface on the stack? I would think no, considering that there is no overlap in subnets since the management IP addresses reside within VLAN 1, but I also know that in the world of Meraki, things can operate slightly differently than one would expect. My concern is that I will have to create a new management VLAN and touch each device in our network to change it. I do plan on changing the management VLAN as well as the VLANs that the servers, etc., reside in, but there is too much going on to tackle that at the same time as bringing these new circuits online. One thing at a time, right? So, will I need to create a new management VLAN in order to move VLAN 1 to the switch stack, or will there be no conflict with the management IPs and the VLAN 1 layer 3 interface coexisting on the switch stack? Thanks everyone. I really appreciate all of the help and advice I have received from everyone as I figure-out how to make these VPLS circuits work. Cheers! Twitch
... View more
Apr 21 2021
1:30 PM
@PhilipDAth That would be ideal, and I agree completely. Unfortunately, it's not a decision I get to make. I made the request, but I was asked to see if I could get the test working without needing to spend money on a separate internet circuit. So, I separated the two networks in the Dashboard and I was able to get the MX and switches connected to the Internet using our existing circuit. Not ideal, but so far so good. Twitch
... View more
Apr 21 2021
5:44 AM
I know this isn't a Meraki solution, but have you considered just running dark fiber between the two buildings, if possible?
... View more
Apr 21 2021
5:06 AM
Morning to the Crew - has anyone set-up a parallel Meraki test network in their environment? I need to test some configuration changes that I want to make before changing our production network to make sure that everything will work as intended. We are considering incorporating Cisco 2811s (or newer, I'm testing with some of my personal equipment) at the edge of our VPLS to handle inter-site routing since we won't be using QinQ to pass VLAN tags. The test lab will include an MX and several MS250 switches, along with 2 2811s. Our main office here has one internet connection which feeds our production network. I need to get the test network connected to the internet also so I can create a test org in the dashboard, but I don't want the test network to handle any production routing and switching while it shares the internet connection with the production network. I'm considering creating an isolated VLAN on the production MX and routing the test network through that to the internet. Has anyone else done something similar in their environment? Did you go the same route with an isolated VLAN, or did you use another method to get the test network connected to the dashboard? Happy Hump Day, everyone! Twitch
... View more
Apr 15 2021
8:50 AM
1 Kudo
Well, damn. The situations you inherit sometimes... Thanks, @cmr. New onmi antennas are being installed tomorrow. Hopefully it's not too late.
... View more
Apr 15 2021
7:34 AM
Hey @MarcP - correct. Currently, there is no terminating resistor attached to the 2.4 GHz poles, they are just uncovered with no antennas attached.
... View more
Apr 15 2021
6:13 AM
Good morning to the crew. I have what may sound like a hair-brained question, but here it goes... Will an MR74 AP transmit a signal without antennas being attached? In other words, will the physical body of the AP itself send out a usable WiFi signal? Does it house an antenna, or just the electronic guts of the AP? We have a situation in one of our shops where, because of a miscommunication with a contractor and an error on an order, only one directional antenna was installed on just about every AP in the shop. The antennas were only connected to the 5 GHz band, leaving 2.4 GHz without antennas. As a result of this, wireless devices in the shop are having issues with getting and maintaining a connection. The fix for this is already in the works, but the problem got me thinking about how much signal transmission occurs with MR access points if antennas are not attached? Cheers! Twitch
... View more
Apr 12 2021
2:00 PM
1 Kudo
After much waiting, I finally managed to get a seat in ECMS 2 for a May training session. Can't wait. Many, many thanks to our Meraki sales rep for getting me an invite to register. I received confirmation of my seat today. Cheers!! Twitch
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 7 | 42198 | |
| 5 | 1197 | |
| 3 | 20444 | |
| 3 | 9810 | |
| 3 | 24341 |
© 2024 Cisco Systems, Inc.
