Meraki

Ryan_Miles · ‎Dec 6 2022

I suggest you open a Support case. I see your email listed in 5 different orgs and at a glance they appear to all be fine. Status says ok and not locked or unverified. Support should be able to get it sorted out.

Ryan_Miles · ‎Nov 29 2022

This is MT14 specific. It's explained here https://documentation.meraki.com/MT/MT_General_Articles/MT14_Metrics_Explained

Ryan_Miles · ‎Nov 26 2022

Ok found it. It's already mentioned HERE. There’s a bug on the MX84 in that any LAN port shows as 0 in LLDP. No other models should be affected.

Ryan_Miles · ‎Nov 26 2022

Not sure. Added to my to do list for next week to see if it is documented. And if not, I will create it. But it's probably the case that all MX models are 0,1 for WAN ports and 0-x for the LAN ports.

Ryan_Miles · ‎Nov 26 2022

For example this is how my MX95 is cabled and how the LLDP info looks from downstream switches

Ryan_Miles · ‎Nov 26 2022

AFAIK the WAN port numbering internally is 0 & 1. And the LAN port numbering also starts at 0. So, for a MX85 the LAN ports from an ifconfig or LLDP perspective would appear as LAN 0-9. Using that numbering your info of physical ports 11 & 12 would equate to the internal numbering scheme mapping to 6 & 7.

Ryan_Miles · ‎Nov 23 2022

The feature went live 11/16/22. Requires MX17 firmware. And only works in non-templated networks.

Ryan_Miles · ‎Nov 19 2022

If firmware is locked or pinned on a device it will not change regardless of what the network is set to. A pinned device would simply ignore whatever the network is set to. It won't upgrade, reboot, etc. I also see the full notes in the case. The issue you're running into is due to your spoke having 192.168.1.0/24 as the WAN subnet and you also have the same route available via an AutoVPN peer. The fix is either change your spoke subnet so it doesn't overlap. Or, upgrade to MX 18. If it were me I'd just change the spoke WAN subnet to something non overlapping.

Ryan_Miles · ‎Nov 18 2022

Have any additional photos of the deployment? Or details on mounting height, coverage patterns, etc? We often get questions on deployments like this and all additional examples are helpful.

Ryan_Miles · ‎Nov 18 2022

Yes https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Meraki_Status_Page

Ryan_Miles · ‎Nov 15 2022

Welcome! We used to live in Grants Pass and Eagle Point in the early 2000s.

Ryan_Miles · ‎Oct 30 2022

The issue has already been logged. Open a case and they can attach your issue to the parent case and update you once resolved.

Ryan_Miles · ‎Oct 30 2022

Under Network wide alerts you can set an alert for when a sensor becomes unreachable. And the USB power requirement for PM 2.5 is mentioned in pretty much every document PDF datasheet https://meraki.cisco.com/product-collateral/mt14-datasheet-20220310-english/?file Web datasheet https://documentation.meraki.com/MT/MT_Datasheets/MT14_Datasheet_-_Indoor_Air_Quality_Monitor#Ordering_information Install guide https://documentation.meraki.com/MT/MT_Installation_Guides/MT14_Installation_Guide_-_Indoor_Air_Quality#Operating_Modes MT14 metrics explained doc https://documentation.meraki.com/MT/MT_General_Articles/MT14_Metrics_Explained#PM2.5_(.CE.BCg.2Fm3)

Ryan_Miles · ‎Oct 28 2022

What specifically is the error? Throughout all the Ventura betas the native L2TP VPN client would break (when previously working) and not allow config through the settings page. The fix is to create a VPN config using Apple Configurator or push a VPN config from a MDM like Meraki SM or another platform. The Apple Configurator option is pretty easy and the app is free.

Ryan_Miles · ‎Oct 27 2022

@MyHomeNWLab Fixed https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/General_MX_Best_Practices

Ryan_Miles · ‎Oct 21 2022

Yes, it does sound like this is a known issue and one that's expected based on specific hardware platforms. So, my calling it a bug was perhaps misleading as that suggests something to be fixed.

Ryan_Miles · ‎Oct 19 2022

My recommendation is open a Support case. They can attach it to a bug and then you'll be updated when it's resolved. As for the platform list - seeking info on that. But from anecdotal info it might be everything MX75 and up.

Ryan_Miles · ‎Oct 19 2022

@RaphaelL got confirmation there's a bug with certain platforms allowing non local VLAN traffic through. The expected behavior is only MX local VLAN traffic should pass through per this doc.

Ryan_Miles · ‎Oct 19 2022

To be clear the MS390 (and Cat9K) only allow 1,000 active VLANs. You can use VLAN IDs higher than 1000. It's covered HERE.

Ryan_Miles · ‎Oct 18 2022

Have you opened a Support case for this? It would be good to get it confirmed and noted in documentation if it's expected behavior.

Ryan_Miles · ‎Oct 18 2022

Not a supported topology https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link#Unsupported_Topology_Example:_Additional_MR_on_Remote_Side You have to use a L3 switch on the remote end like this in order to make it work https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link#Example_Topology_2

Ryan_Miles · ‎Sep 28 2022

https://developer.cisco.com/meraki/api-v1/#!update-network-wireless-ssid

Ryan_Miles · ‎Sep 28 2022

It's working in my org using this format networks/L_(my network string)/wireless/ssids/2/identityPsks SSID 2 is my IPSK SSID

Ryan_Miles · ‎Sep 28 2022

Fairly common issue and one we have noted HERE

Ryan_Miles · ‎Sep 28 2022

👍

About Ryan_Miles

Ryan_Miles

Ryan Miles

Community Record

Badges