About PaulMcG

PaulMcG · ‎03-08-2022

You can only go from co-term to per device. There is no possibility of going back. You can try your luck and open a case but it's pretty much a one-way deal.

PaulMcG · ‎03-07-2022

It happens just as documentation says it will. I had to monitor an upgrade once for a worried customer with a HA setup, and when I informed them it was done, they hadn't even noticed it took place. https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practices_for_Meraki_Firmware

PaulMcG · ‎03-04-2022

Could it be some kind of virtual MAC address generated by the MX for it's own routing purposes? I looked at 2 different client MXs and every VPN client connected had some kind of 03: MAC address.

PaulMcG · ‎03-03-2022

If there is no MESH needed for outdoor, we run 7-17 for both 2.4 and 5GHz. If there are MESH APs, we run 10-21 on 5GHz and only broadcast client SSIDs on 2.4.

PaulMcG · ‎03-01-2022

For indoor profiles we run 7-14 on 2.4GHz and 10-17 for 5GHz. I see you have a few APs running MESH, those could justify running higher power on 5GHz to improve throughput. Outdoor profiles depend on the use case and whether or not MESH is required.

PaulMcG · ‎02-28-2022

Could be something on the WAN switch blocking the VIP like an access list. You could do a capture on the ISP side of the WAN switch to see if the ping goes out to the ISP. On the ISP side, if your VIP is part of the /29 attributed to you, I don't see any reason for them to be blocking the VIP.

PaulMcG · ‎02-24-2022

Pings to 8.8.8.8 should also work from the virtual IP source. Might have something upstream from the MX interfering?

PaulMcG · ‎02-07-2022

Place all unused APs into a temporary network. Any that are able to reach the Meraki cloud will show up as online. The status page should give you some info on which switch/port it is connected to. Once you have what you need, remove them from the temporary network as to not affect licensing.

PaulMcG · ‎02-07-2022

One time I moved an active MX with static IP to a different organization and it kept it's static IP. But I've only done it once, so to be on the safe side, you should have someone on site who can configure the static IP if the device loses it in the transfer. That way you won't be stuck if the MX loses dashboard connectivity.

PaulMcG · ‎01-12-2022

Are there any Layer 3 firewall rules on either MX that might be blocking the subnet?

PaulMcG · ‎01-12-2022

I just noticed in the image of routing from your first post you have a route for 10.69.10.0/24 but none for 10.69.11.0/24. Is your VPN configured to be full or split tunnel?

PaulMcG · ‎01-12-2022

Have you enabled Client VPN subnet in the site-to-site VPN settings?

PaulMcG · ‎01-11-2022

The datasheets for MR42 are still available online but they don't include the converage patterns for bluetooth, only wifi.

PaulMcG · ‎01-10-2022

Going from one template to the other is simply unbinding the network from template 1 and then binding it to template 2. This can be done under Organization->Configuration templates and selecting the template to unbind and then bind. The actual changing of templates is pretty straightforward, but how seemless this will be for end users depends on how each template is configured, as well as the network upstream of the APs. If everything is in place, vlans, DHCP servers, etc. it should be pretty smooth. This can all be looked at and planned ahead of time to minimize any impact during the actual switchover.

PaulMcG · ‎12-31-2021

Options for redudancy for non-Meraki VPN is limited. For point 1, you need to use the VIP, doesn't seem to be much in the documentation on the subject but the VPN might not even come up if a VIP is configured but you use the WAN IP of the primary MX. Point 2, I don't think this is possible, but I could be wrong. Point 3, dual WANs only work for VPN resilience in an auto VPN setup. Does nothing in a non-Meraki VPN situation. The only way to get the best resilience in a DC with Meraki is with either a vMX or physical MX(HA) setup at the DC.

PaulMcG · ‎12-30-2021

Yeah like you said sounds like a combination of things. I've seen some ISP modems have the sticky MAC problem as well. Any time I have an install with an ISP I know that can be an issue I reboot the modem at the same time I have the MX connected. You could make rebooting the ISP modem part of the setup process for a few sites and see if that solves the problem. But taping a paperclip to the box is a good backup.

PaulMcG · ‎12-30-2021

If the devices come online and giving a DNS error, just give it time and the warning will go away. If you really it gone sooner, you could send a reboot command, but if the device shows as connected but with an error, it's still functionnal, the error is more informative than anything.

PaulMcG · ‎12-30-2021

That's kind of an odd behavior, I've done the same thing with MX devices with DHCP for the WAN port and moved from site to site with no issues. Depending on the model of MX you are using, you could always use WAN2 in your office and then WAN1 when on site. But it shouldn't behave in the way you describe.

PaulMcG · ‎12-29-2021

There's no control over DHCP for VPN clients, but you can specify what DNS server is given to the clients from the "Client VPN" configuration page. Don't know if that will fix the issue you're having though.

PaulMcG · ‎12-22-2021

If the same subnet is configured on your home router and on the MX LAN, this could cause an issue like this. Most home routers have something like 192.168.0.0/24 or 192.168.1.0/24, and if this is the same as a vlan on the MX, the computer doesn't know which way to route.

PaulMcG · ‎12-22-2021

Topology rarely comes out from left to right as you have it depicted in your diagram. Would be nice if it did. The reason sw1 shows up on the left might have to do with it being the lowest STP bridge priority, but other than that, there really isn't anything you can do to change how the topology comes out on dashboard.

PaulMcG · ‎12-21-2021

The alert only is only to advise that the port is down for the time indicated. There's nothing done automatically to determine why it's down, only that it is down. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alerts_and_Notifications

PaulMcG · ‎11-05-2021

While connected to client VPN, are you able to ping the RDP server address, or any other address on the LAN?

PaulMcG · ‎11-05-2021

Check layer3 rules in the firewall menu. You might have rules restricting the subnet for the RDP server from reaching the client VPN subnet.

PaulMcG · ‎11-03-2021

This is the dashboard telling you that your local subnets overlap with a configured static route. Even if you created a vlan with a 192.168.x.x subnet, you will still get the same message as your 10.0.0.0/16 as well as client VPN subnets are the reason for the message. Also, creating a vlan with a /16 mask is unnecessarily large, with over 65,000 possible host adresses. Most of the time vlans are created with a /24 mask, giving you 254 possible host adresses, as well as less chances of overlaps.

PaulMcG

Community Record

Badges