About Ryan_Miles

Ryan_Miles

Thanks for the note Blake. I edited all docs to use the same sentence and link to the same doc/section.

Ryan_Miles

This endpoint? https://developer.cisco.com/meraki/api-v1/get-network-wireless-ssids/ https://api.meraki.com/api/v1/networks/L_xxxxxxxxxxx/wireless/ssids works fine for me. Same with the call in Postman.

Ryan_Miles

Reject or accept? On accept yes it can apply a GP by using filter-ID https://documentation.meraki.com/MS/Access_Control/Meraki_MS_Group_Policy_Access_Control_Lists#Configure_Access_Policy_to_use_Filter-Id

Ryan_Miles

Well, yeah that too 🙂

Ryan_Miles

No it will just obviously reboot that one switch. And I'm assuming you have the stack properly cabled in a ring topology already?

Ryan_Miles

Working ok in multiple browsers here (link to table & link to image file)

Ryan_Miles

The Sensors were connected fine before moving them into the new network? Sensors need to be somewhat close to Gateways (AP or Cameras). Distance depends on the environment, but typically 50 ft or closer. If Gateways don't hear Sensors at -85 dBm or better they will not accept the traffic from the Sensor. From what I can tell only one Sensor is connected right now and only seen by a single Camera. Two of the Cameras in that network are MV21s which don't have BLE radios to support Sensors. The other 3 gen2 Cameras don't see any Sensors.

Ryan_Miles

I suppose the con would be it's not the official recommendation per documentation. I've not had issues with the design as long as STP is properly configured downstream (and if it wasn't you'd still have problems even without the MX<>MX link anyway).

Ryan_Miles

Subscriptions has just launched and there are some caveats today with what and where it can be used. Co-term is still the default licensing mechanism and supports Display. I imagine at some point Subscriptions will include Meraki Display.

Ryan_Miles

Subscriptions don't today support Meraki Display just as PDL doesn't either

Ryan_Miles

While there's not a "reload in" command in Meraki world (and I too used that plenty pre cloud managed days) when I was a Network Engineer Meraki devices have a number of routines built in to help avoid loss of connectivity. Much of this is covered in this doc https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Behavior_during_Connection_Loss_to_Cisco_Meraki_Cloud But to highlight a few of them one is that if the mgmt IP of a device is using DHCP even if you were to change the mgmt VLAN the device would pull a new IP from its new subnet and still be reachable by dashboard. Additionally, if a device has a static mgmt IP and that stops functioning the device will attempt to obtain a DHCP IP from reachable VLANs and if successful would be reachable by dashboard. There's also the idea of "safe config" which is covered in the doc linked above. But in short means if a device becomes unreachable and based on a few conditions mentioned in the doc it would revert to its prior known good config. Both of these functions go a long way to addressing the possibility of cutting a device off from reachability. I'm sure other Meraki users here on the Community can provide their insights and experiences on the topic.

Ryan_Miles

I've requested an update to the doc. Thanks for pointing that out.

Ryan_Miles

Several years back guidance did change to recommend using the LAN connections through the switching layer to provide the pathway for VRRP packets. The article you linked to is several years old (from a now shutdown site/past employee). Nothing wrong with that, but just pointing it out. I too call out the pros & cons of this in my animated slide deck and I agree that providing a MX to MX direct link can help avoid a dual active scenario should all LAN links to the primary MX fail, but WAN(s) are still active.

Ryan_Miles

HA power is supported default https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR57_Dual_Uplink_High_Availability#High_Availability From my MR57

Ryan_Miles

Split the network, delete the one that ends with - environmental, recombine the network.

Ryan_Miles

I followed the guide @alemabrahao posted and got it working pretty easily. @meraki-newbie If you run into any issues post back in this thread and we can assist you.

Ryan_Miles

Do you have photos of one of these installed APs and antenna?

Ryan_Miles

Is this AP2? I see a few clients have connected and have passed some traffic. Is it still not working? Are both SSIDs affected or just the PSK SSID? You could also try a factory reset of the AP. https://documentation.meraki.com/General_Administration/Support/Resetting_Cisco_Meraki_Devices_to_Factory_Defaults#MR_Access_Points And side note, Layer 3 Roaming doesn't apply to a single VLAN SSID. You should disable/uncheck that box.

Ryan_Miles

That line is the default for any AP not using a tag. If you only need a single VLAN for the SSID you could honestly just leave the VLAN tagging disabled and then the SSID would be mapped to whatever VLAN is the native on the switchport connected to the AP.

Ryan_Miles

Configure tags for your APs. Example, add a tag name of floor_1, floor_2, etc tag to the APs based on their respective location. Tags can be whatever name you want to use. Then on the SSID configure it for Bridged mode and in the VLAN tagging section configure tag to VLAN mappings. That is how you can define the users VLAN per AP/floor.

Ryan_Miles

https://developer.cisco.com/meraki/api/get-organization-uplinks-statuses/

Ryan_Miles

Are you saying link aggregation is enabled on the switches? It is a requirement for proper operation. https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/MR_Link_Aggregation_Configuration_Guide Just looking for clarity as you mention "out the box". If you connected a MR57 straight out of the box with both ports and did nothing else I would not expect link aggregation to be working correctly as it requires config on both the AP and switch side.

Ryan_Miles

Have you you've ensured all APs have LAG enabled as well as the corresponding switch side ports? If yes and the problem persists I would open a Support case. From what I've seen the topology page will only show the primary port (eth0) of the MR57 if using LAG.

Ryan_Miles

You should also update the firmware on your Sensors to the current stable MT 1.5.

Ryan_Miles

@DexterLaBora should the banner in the visualizer section have the download csv and other buttons like your example gif? Mine looks like this.

Ryan_Miles

Ryan Miles

Community Record

Badges