Meraki

Ryan_Miles · ‎May 18 2022

When API is enabled and a key is created per account each admin has a unique API key. That key has the same permissions as the user.

Ryan_Miles · ‎May 17 2022

It's covered here https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/MX_Templates_Best_Practices#Templates_with_MXs_of_Different_Port_Counts

Ryan_Miles · ‎May 11 2022

A simple L2 roam should be the fastest and most reliable. Your issue is likely around the SSID RF config. Can you post your RF profile config for these APs? Also, have you opened a Support case?

Ryan_Miles · ‎May 5 2022

Nope that won't work

Ryan_Miles · ‎May 2 2022

The second image is when you use standalone Meraki APs. That's different than the wireless settings & capabilities in the MX-W.

Ryan_Miles · ‎Apr 29 2022

In your example a client first connecting on floor 1 would get an IP from VLAN 10. When the client roams to 2 or 3 they would associate to an AP on those floors while maintaining their VLAN 10 IP. This is accomplished by a dynamically created AP to AP tunnel. This is with using Client IP Assignment type of "Layer 3 Roaming". This is assuming the switchports connected to the floor 2 & 3 APs DON'T have the 1st floor VLAN on the trunk port. If the trunk ports contain VLAN 10 the client would still remain on VLAN 10, but without the need for an AP to AP tunnel to be created and they would simply join the new AP. This is a nuance of our distributed layer 3 roaming folks often overlook in that a VLAN check occurs and based on presence of the client VLAN on the upstream switchport the roam could be a simple L2 roam or a tunneled L3 roam. It's outlined in great detail here There's also a large building example in the doc based on a deployment I did some years back. I also created a simplified version of this example.

Ryan_Miles · ‎Apr 26 2022

I can see they're rebooting. You need to engage Support.

Ryan_Miles · ‎Apr 26 2022

Yes and it worked as advertised in my experience

Ryan_Miles · ‎Apr 25 2022

MS120-8FP is not a layer 3 switch. So, in this design you'll need to put all the L3 interfaces on your MX and use your switch has basic L2 transport. So, make port 1 on the switch a trunk. Create the L3 interfaces/subnets on the MX. I assume the /30 to the main site is just a LAN type link essentially? What traffic will take that route? You'll need static(s) on the MX to send traffic destined for the main site to the next hop 10.1.1.1 (guessing that's the IP of the far end).

Ryan_Miles · ‎Apr 25 2022

Support or your Meraki sales team

Ryan_Miles · ‎Apr 25 2022

I checked it again. It's running the highest supported firmware version a Z1 support (14.56). I don't actually see it rebooting with any scary messages related to firmware, panics, etc. Running the ping tool against 8.8.8.8 I see a fair amount of loss here and there along with some fairly high latency spikes. If you bypass the Z and connect directly to the modem is it stable? Mostly looks like an upstream issue from the Z from what I can tell. Is the modem ethernet port 1 gig capable? The Z is showing the WAN port being at 100 Mbps at the moment.

Ryan_Miles · ‎Apr 25 2022

Can you try a factory reset on the Z1? Poke the reset button with a paperclip or whatever. Hold in for ~10 seconds then release.

Ryan_Miles · ‎Apr 24 2022

DM me your org link

Ryan_Miles · ‎Apr 21 2022

Yes, Support can enable that.

Ryan_Miles · ‎Apr 21 2022

Requires MX SD-WAN license https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/SD-WAN_Internet_Policies_(SD-Internet)

Ryan_Miles · ‎Apr 20 2022

Little tough to follow without a diagram. But, in general if the MX WAN interface shows as down then it means it cannot reach dashboard. Does that interface have a proper route & NAT to reach internet/dashboard?

Ryan_Miles · ‎Apr 18 2022

Liquid detection would be the MT12. Stick the MT10 in liquid and you're bound to have a bad day. As for the MT12 its primary targeted use case is to be dry and when liquid contacts the leak detection cable send an alert. Not sure we've tested the reverse in which the cable spends its time wet all/most of the time. What would you be monitoring here?

Ryan_Miles · ‎Apr 13 2022

It's only an alert under the MX (network wide > alerts > security appliance)

Ryan_Miles · ‎Apr 13 2022

https://developer.cisco.com/meraki/api-v1/#!get-organization-api-requests

Ryan_Miles · ‎Apr 11 2022

15.2 is an old deprecated beta. So, I would start by upgrading to either the last stable or beta and see if the issue persists.

Ryan_Miles · ‎Apr 8 2022

Is this a new MX install? Or, did you recently upgrade firmware? If yes, was the issue occurring on the previous firmware? Also, how are the MXs connected to the downstream switching infrastructure? The recommendation is to not use a direct link between MXs and use the downstream paths for the VRRP packets. VRRP is sent on all configured VLANs anyway. So even with a single VLAN link between MXs directly that really accomplishes nothing different and actually is a more trouble prone design.

Ryan_Miles · ‎Apr 8 2022

I wouldn't say there's zero mechanism for transferring hardware. The process is outlined here. Granted the typical scenario for transferring serials between orgs is when it's all part of one company or during a company split in which the admins exists in both orgs. Problem with the whole ebay thing is the source of the gear is totally unknown. There are 7M+ APs online globally. That opens up plenty of opportunities for theft. So it's understandable why Meraki wouldn't just blindly unclaim gear from an org and let someone else claim it. Heck, someone wouldn't even need to physically have the gear. They could just jot down the serial, open a Support case, claim they physically have it, and ask a Support tech to boot it from the rightful owners org taking it offline. And yes, there's been a huge uptick of people selling promo gear, CCNA gear, etc.

Ryan_Miles · ‎Apr 6 2022

MX blocks all inbound traffic by default. What specifically are you seeing happen in your network? I tested and while I couldn't ping 141.98.11.14 .13 did respond to ping. So, I tried both a L7 rule denying the entire /24 and also tested blocking Lithuania. In both cases pings no longer went through. So, it appears to be doing its job in my test.

Ryan_Miles · ‎Apr 6 2022

Your rule blocks the destination of 141.98.11.0/24 from inside traffic heading out through your MX

Ryan_Miles · ‎Apr 5 2022

Can you access the root domain of that site? I can hit that and the long link pdf from your screenshot.

About Ryan_Miles

Ryan_Miles

Ryan Miles

Community Record

Badges