Meraki

Ryan_Miles · ‎Apr 3 2023

There's a note on the SSID config page for the RADIUS Client Trust settings "Configure wireless supplicants to expect RADIUS server certificates with the following properties. Use the 'Current organization' certificate name to trust all APs in this organization. Use the 'Current network' certificate name to only trust APs in this network."

Ryan_Miles · ‎Apr 3 2023

The roaming tab is under client details not on the AP page. And the Network Service Health banner is on the Health / Overview tab. And, you have to have magnetic enabled or it won't show.

Ryan_Miles · ‎Apr 1 2023

@FrancWest when you delete a stack you will get this warning message. So, just be aware in case there are L3 interfaces configured on the stack today. Aside from that, no, the config of the switchports is not impacted nor will it reboot either switch. You can delete the stack then remove the stack cables later and it should be fine. If you have any cross stack LACP aggregation groups configured that will of course be impacted and you'll need to accommodate with a new design. With any network changes/maintenance though always prepare for the unexpected should something not go as planned.

Ryan_Miles · ‎Mar 29 2023

First part. Yes, you can have provider 1 on MX 1 (primary) and provider 2 on MX 2 (spare). Second part. As long as VRRP packets make it across the switches & wireless bridges the MXs will work in HA mode. My concern would be reliability of the wireless link and if you drop VRRP here and there you could end up with both MXs thinking they're primary (dual master issue).

Ryan_Miles · ‎Mar 27 2023

Yes, change it to just have VLAN 200 in the default line. No need for that "demo" line.

Ryan_Miles · ‎Mar 27 2023

Do your APs also have that tag "demo"?

Ryan_Miles · ‎Mar 26 2023

@nlatta42 What was the resolution? I don't see anything in the case other than you closed it.

Ryan_Miles · ‎Mar 26 2023

I sent you a PM

Ryan_Miles · ‎Mar 26 2023

I think you're seeing stale info in the UI route table page. Example, I checked one of the spokes you were testing with and I see multiple routes for 10.130.0.0/16. However, when checking the actual route table on the backend I only see the proper route via the only configured hub 1. I've noticed BGP routes can take a long time to flush from the UI even after deactivated/removed. MX17+ uses iBGP for AutoVPN routes (meaning the MX to MX routing). Your two new hubs are running MX18.x vs. hub 1 which is on MX16.x. A number of your spokes are also on MX17.x+. So , I assume this is where all the IBGP routes are coming from. Your hub to hub tunnel disablement is applied org wide and I don't see hub routes on other hubs so I believe that is working as intended.

Ryan_Miles · ‎Mar 26 2023

I didn't catch the new hubs were on MX18.x so the routing stuff is on the new separate page 😉

Ryan_Miles · ‎Mar 25 2023

The easiest option would probably just be to add that route to hubs 2 and 3. For the hub to hub tunnel feature. I'd review that with your Meraki SE as it's a larger design consideration. Without a very thorough understanding of your entire network I wouldn't want to make a recommendation of that magnitude. Also, noticed hub 2 and 3 have OSPF disabled. Is that temporary or are you using some other process to direct spoke routes back to those hubs?

Ryan_Miles · ‎Mar 25 2023

10.0.0.0/9 wouldn't cover 10.130.0.0/16. 10.0.0.0/9 only goes up to 10.128.0.0. So, when you remove hub 1 from a spoke's hub list the spoke no longer has a route that covers 10.130.0.0. If your hubs were using their default hub to hub tunnels there still would be a path via hub 2 and 3. All three of your hubs have various 10.x.x.x routes all pointing to the same next hop (per hub location). Could you just use a 10.0.0.0/8 instead to cover it all with one route? The hub to hub tunnel disablement is typically done to deal with routing loops when the hubs use OSPF and there is other DC side OSPF peering happening. It can be dealt with by changing metrics on the peering gear or moving to BGP (albeit that requires concentrator mode, which would be a larger discussion on if that would work better for your design than NAT mode hubs). I always aim for concentrator mode for a variety of reasons, but I know sometimes folks want/need NAT mode for various reasons.

Ryan_Miles · ‎Mar 23 2023

A Support case is the best option

Ryan_Miles · ‎Mar 17 2023

No worries. Just wanted to make sure we had it corrected. The list of local overrides does grow over time so the best reference for what's available is the doc link.

Ryan_Miles · ‎Mar 17 2023

Correction on that example above. PSK can be overridden in a template bound network. A list of all the overrides can be found HERE

Ryan_Miles · ‎Mar 16 2023

Could be related to this https://status.meraki.net/

Ryan_Miles · ‎Mar 16 2023

I'd look into whatever is supposed to be providing DHCP for VLAN 20. Replies are not being seen from whatever that device is. Be aware your other 7 cameras at this site are operating on wireless right now. If you want them to communicate via their wired interface you either need to change the 7 switchports to VLAN 1 or resolve the VLAN 20 DHCP issue.

Ryan_Miles · ‎Mar 16 2023

Your switch is a MS210. It cannot do L3 or act as a DHCP server. Your 7 online cameras are working via wireless and VLAN 1. So, you could move the switchports connected to the cameras to VLAN 1 and they presumably would get IPs and work.

Ryan_Miles · ‎Mar 16 2023

As others mentioned this should work fine. I'd recommend setting the bridge priority on the switches to make the blocked ports predictable. I'd set the top switch as root (example, 4096) and the bottom switch as secondary (example, 8192).

Ryan_Miles · ‎Mar 15 2023

Have you tried multiple mobile devices? I just tested your splash page on a Macbook Air and iPhone 14 Pro Max (chrome browser on both) and I see the email address on both devices.

Ryan_Miles · ‎Mar 15 2023

For anyone else following along. There must have been some misunderstanding. The case is logged against the correct bug that impacts gen3 MVs (MV63/93). This is not a gen2 issue.

Ryan_Miles · ‎Mar 15 2023

I found the case. I'll ping the engineer.

Ryan_Miles · ‎Mar 15 2023

Ok, I think I see the issue. Your 7 working cameras are working via their wireless interface which maps to VLAN 1 based on your SSID config. The two offline cameras don't have wireless profiles and they fail to get DHCP via the wired interface (VLAN 20 switchports). All the DHCP discovers I see are coming from the wired MACs of the cameras. So, it appears your VLAN 20 is the problem as nothing appears to be providing DHCP. And while unrelated (maybe) starting 2 days ago your APs are all producing this alert in the event log "Multiple DHCP servers detected".

Ryan_Miles · ‎Mar 15 2023

What provides the DHCP? The firewall? Any logs on that showing activity from the 2 offline cameras? I found your dashboard and can see the offline cameras sending DHCP discovers, but I don't see any reply. Actually, I see all 9 cameras sending DHCP discovers and no response from anything.

Ryan_Miles · ‎Mar 13 2023

Does the firewall rule allow UDP 7351 to these 4 IPs/subnets per the firewall info page? 64.62.142.12/32 158.115.128.0/19 209.206.48.0/20 216.157.128.0/20 Checking a location of yours that didn't have the outage shows passing 7351 test to 209.206.x.x IPs. Comparing to sites with the outage those APs still show failures for 7351 checks to various 209.206.x.x IPs. The AP's failing the test are the ones also showing the warning "Connection to the Cisco Meraki Cloud is using the backup Cloud connection."

About Ryan_Miles

Ryan_Miles

Ryan Miles

Community Record

Badges