Meraki

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.

Ryan_Miles · ‎Apr 5 2022

Yes. You can see in what I pasted there's a section for fixed assignments. I just don't have any for that VLAN. But yes, it will show if any are configured.

Ryan_Miles · ‎Apr 5 2022

You can get this via api (baseUrl/networks/:networkId/appliance/vlans). Example from one of my MX. "applianceIp": "172.17.30.1", "subnet": "172.17.30.0/24", "fixedIpAssignments": {}, "reservedIpRanges": [ { "start": "172.17.30.2", "end": "172.17.30.9", "comment": "reserved" } ], "dnsNameservers": "google_dns", "dhcpHandling": "Run a DHCP server", "dhcpLeaseTime": "1 week",

Ryan_Miles · ‎Apr 5 2022

https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX

Ryan_Miles · ‎Apr 1 2022

My guess is the network has some older devices with maximum supported firmware versions below what the network is set at. What model devices are in the network returning this result for you?

Ryan_Miles · ‎Mar 31 2022

In dashboard look at the URL. nxxx.meraki.com. The xxx number is your shard.

Ryan_Miles · ‎Mar 31 2022

My basic testing produced the following results

Ryan_Miles · ‎Mar 30 2022

∞. It's honor based. https://documentation.meraki.com/MX/AnyConnect_on_the_MX_Appliance/AnyConnect_Licensing_on_the_MX#How_does_AnyConnect_licensing_work_with_the_Meraki_MX.2FvMX_appliance.3F

Ryan_Miles · ‎Mar 30 2022

Yes, when firmware MX16 moved to stable AnyConnect also went stable (meaning not beta).

Ryan_Miles · ‎Mar 25 2022

We use the standard Cisco NBAR protocol packs. That includes 1500+ apps. You can create custom expressions in addition to that. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Network-Based_Application_Recognition_(NBAR)_integration

Ryan_Miles · ‎Mar 25 2022

MX supports layer 7 rules with any license level. https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#Layer_7_Firewall_Rules

Ryan_Miles · ‎Mar 23 2022

From what I gather firmware 28 might show false positives for AP spoofs and engineering is working on root cause & a fix. Sounds like it's purely a cosmetic issue at the moment. I see a few occurrences of it on my network. And checked some other larger networks and they also see a number of events especially if they've seen a lot of connected clients.

Ryan_Miles · ‎Mar 23 2022

Likely this issue https://community.meraki.com/t5/Security-SD-WAN/NAT-Type-Unfriendly/m-p/50760

Ryan_Miles · ‎Mar 23 2022

Meaning the MX with fiber uses private WAN to form tunnels (NATs to same IP as the hub does) and VDSL & Cell would use internet path? AutoVPN should figure that out. It should be the same as if a single MX had a private WAN link and internet link. It can/prefers to build the tunnel over the private IP network. If that doesn't work it will use public IPs/internet path.

Ryan_Miles · ‎Mar 23 2022

Correct, you wouldn't use VIPs anymore. As for the bandwidth differences. The MX is going to use whatever it has access to. Not sure I understand the question.

Ryan_Miles · ‎Mar 23 2022

One approach would be this then. LB the main connections on MX1. If both fail or the MX fails it will roll to the spare MX in which you could use VDSL as primary then fail to cellular/MG (in this example) or whatever uplink behavior you want. Additional benefit is on the newer MX models WAN 2 provides PoE for a clean deployment with the MG. Requires additional MX purchase, but only one license.

Ryan_Miles · ‎Mar 23 2022

Going to be well off in the future. Are you deploying HA MXs? You can always connect provider 1 & 2 to MX1 (primary) and provider 3 to MX2 (spare). This doesn't allow load balancing across all three, but it does meet the failover requirement. And one could argue having 3 WAN providers, but only a single MX isn't a great disaster avoidance design.

Ryan_Miles · ‎Mar 23 2022

New & known issue under review for fixing now. If you keep clicking the column header it seems to eventually show the correct sort order. But it seems to take 5-6 clicks and if you keep clicking appears to cycle all the way through the incorrect orders before coming back around to the correct order. In short, already reported and will be fixed soon.

About Ryan_Miles

Ryan_Miles

Ryan Miles

Community Record

Badges