Meraki

Ryan_Miles

A common approach for your network would look something like this. - No direct link between MXs - Lowest physical port(s) of "Active" stack member switch become root port(s), port(s) on the member switch in the stack would be in STP blocking under normal conditions - All LAN ports on the MXs and MSs would be trunks, allow all VLANs (or you can specify the exact VLANs in use if you like), and have matching native VLANs - The native VLAN can be whatever you want. Often that could be the mgmt VLAN for the Switches for config simplicity. - Use link aggregation groups between the MS425 stack and the downstream Switches @DevinM what issues are you currently seeing with the deployment today?

Ryan_Miles

Is this a single MX or HA config? If HA be aware the LAN uses a virtual MAC and not the base chassis MAC. If you're blocking all DHCP, but the primary MX MAC you'll be blocking legit DHCP traffic to the cc:03:d9:xx:xx:xx virtual MAC. https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Virtual_MAC_addresses

Ryan_Miles

Hey @DevinM, This doc has two of the commonly used and supported designs. You're correct in that MX doesn't support LAG today. So, the common practice is connect each MX in a HA pair to a set of LAN switches (be it a physical stack or not). These links would typically be trunks with the native and allowed VLAN list matching on the MX and switch side. Of course the MX could just have a single transit network to a L3 core switch as well. But in your case it does sound like all your L3 interfaces (or at least many of them) live on the MX - which is very common. You may also want to check out the Meraki Campus LAN Planning, Design Guidelines and Best Practices doc which goes deeper into recommended designs and config details.

Ryan_Miles

Nothing like that exists today beyond the listed known issues in the firmware release notes pages in dashboard

Ryan_Miles

Workload, backlog, limited resources, prioritization would be my guess.

Ryan_Miles

Did you configured a SSO subdomain in the Meraki dashboard? https://documentation.meraki.com/General_Administration/Managing_Dashboard_Access/SP-Initiated_SAML_SSO_Configuration_Guide#Defining_a_unique_subdomain_for_your_organization If you do that you can navigate to that URL to login. Something like https://example.sso.meraki.com

Ryan_Miles

Known issue/bug logged since Feb 2024.

Ryan_Miles

"Note: Virtual MX (vMX) devices are not supported as Wireless concentrators. As a result, Security & SD-WAN > Configure > Wireless Concentrator is not available on vMX devices." https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Tunneling_and_Layer_3_Roaming_-_VPN_Concentration_Configuration_Guide#SSID_Tunneling_to_an_MX_VPN_Concentrator

Ryan_Miles

They would need to be at least a network admin. So, if it's a combined network they would have admin access to all the devices. Only option would be split cameras into their own network and have admins only have write access to that network.

Ryan_Miles

The path to MX1 is through MX2

Ryan_Miles

If the MXs are directly connected to each other MX1 would remain primary and therefore retain answering to the virtual MAC.

Ryan_Miles

VRRP is sent on all links and all VLANs. So yes, in that example of losing LAN 1 & 2 LAN 3 would still carry VRRP packets between the MXs and keep MX1 as primary and MX2 as spare. Traffic flow of clients downstream would be from the switch up to MX2 then over to MX1 as that would still be the primary unit in the HA pair.

Ryan_Miles

The only option at that point is to connect the MXs to each other directly so there's a remaining path for VRRP. Example

Ryan_Miles

VRRP only occurs on the LAN side of the MX. Do you have redundant links between the MXs and the Switch(es)? If you only have a single LAN link from each MX you'd want to add another to provide some redundancy.

Ryan_Miles

It appears to want something selected even for the disabled SSIDs. So, just check any of the boxes for SSIDs 2-4 and it should save. They're disabled so it doesn't matter anyway.

Ryan_Miles

That's the goal

Ryan_Miles

There is documentation, but it's no live/public yet. I can check with PM tomorrow morning to inquire on timing.

Ryan_Miles

MV52 aperture is not user adjustable just FYI

Ryan_Miles

Can you provide some examples from this camera showing the plates? Feel free to block out some of the plate for privacy if you like. I have a MV52 set to 80% zoom and 1080p/high and can easily read plates at 250+ feet. Feeding this video into ALPR also deciphers the plates accurately. Are the vehicles in your scenario stationary or moving? And if moving, at what speed? Also, what are the lighting conditions?

Ryan_Miles

It's a bug and not intended behavior nor a supported feature.

Ryan_Miles

Maybe this has changed over time, not sure. Anyhow you can edit Sensor profiles including the Default profile for template bound networks. Sensor Alerts have always existed at the network level for template bound networks. The config doesn't live under the template.

Ryan_Miles

Traffic should route between VLANs by default. There are no deny firewall rules by default (aside from outside to inside.)

Ryan_Miles

There's no 3rd party recommendation. But the connectors are RP-SMA if you want to try something at your own risk.

Ryan_Miles

This is a known issue/open bug for the Camera list page

Ryan_Miles · ‎Oct 22 2024

The policy is outlined here https://meraki.cisco.com/meraki-support/policies/#product-end-of-life-eol-policy An end of support device will still connect to dashboard and function normally. As the policy states you wouldn't receive tech support on the device if you were to open a case online or by phone.

About Ryan_Miles

Ryan_Miles

Ryan Miles

Community Record

Badges