That was how it worked previously, but I'm told that is pretty much impossible now.  ... View more

This article describes the only way you can have 3 ISPs setup: https://documentation.meraki.com/MX/MultiWAN_Backup_Uplink You can have 3 ISPs, but you would need SFPs for Ports 1 and 2, and Port 4 would be the tertiary. ... View more

Just FYI as of the 26th, you can no longer return licenses. You will have to upgrade/downgrade the existing/new respectively or use 2 different orgs. https://documentation.meraki.com/General_Administration/Other_Topics/Returns_(RMAs)_Warranties_and_End-of-Life_Information#Refund_Requests ... View more

You need to contact support, here is the no login backup form: https://meraki.cisco.com/meraki-support/open-a-support-case/ ... View more

There is not a posted known issue, in the latest CS release notes. They actually fixed a bug in 17.2.3 related to the container. Regardless, It's just been something that has been experienced often by users and that problem will no longer exist once on Native IOS-XE ... View more

If comcast side is reporting the modem down at the time you see the Meraki reporting things down, the issue is 100% comcast. The status of the modem relies on power and the coax cable, that's it.  ... View more

The MX's port or the SFP could definitely be damaged somehow. Perhaps an electrical surge at some point? Have you asked Meraki support? I've not had issues in general with comcast handoffs through a wide variety of gear (Cienas, Junipers, Coax Modems, etc) Do you have a spare SFP you can try? Do you see the issue if you connect the Comcast gear to another device? ... View more

The fun thing for me, is there were other stacking bugs in MS17 that made me go to 18. 🙃 But 99% of the time, we put our MX uplinks in 47/48. 🤦‍♂️ ... View more

No, Meraki doesn't support both relaying and running DHCP on the same device. You  must separate those functions if both are needed. ... View more

You cannot. However if you have another switch capable of relaying, you could create interfaces there using another IP on the same VLAN and then relay to clearpass. ... View more

I think we will all have the same problem. F4s_v2 was the default SKU for vMXs in Azure. While there are a couple of other supported SKUs, not sure how many people use them. I'm sure Meraki just got the info like we did, so we have to wait for them to develop a new preferred sku and I presume we will have to redeploy our vMXs. ... View more

If you do a packet capture of the MX lan port and the AP Uplink do you see the DHCP requests for VLAN 120? If you statically IP something on wireless on vlan 120, does it work? ... View more

All vlans is fine, so the uplinks to the APs are trunk native vlan 1, and all allowed, an the uplinks between the switches and up to the MX are the same? Did you check addressing and vlans on the mx and make sure it matches? ... View more

Is there a switch involved or are the APs plugged directly into the MX? Does the SSID possibly have the Local LAN firewall rule set to deny? SSID is set to the below?:   ... View more

This article was just published in the last week and appears useful to your issue: https://documentation.meraki.com/General_Administration/Licensing/Managing_Cisco_Networking_Subscription_on_EA ... View more

Yeah that's a bigger problem, definitely see if support is aware and can do something ... View more

If something is missing from the live mac table and you are sure it's generating traffic, I would open a support case, as that would be a bug of some sort. Should be pretty easy to prove and log to get a bug filed. ... View more

Are you on CS Firmware or IOS-XE? If on CS, I suggest trying IOS-XE or going to the latest CS if not on it. It is known that the Container that runs on the CS firmware sometimes just crashes and a reboot is required.   If you are already on IOS-XE, I'm presuming you mean you can't ping even locally or see the device online in any state and then the following might help. Are you using a Static IP or DHCP? If DHCP, have you done a packet capture to see if what is happening when the connectivity is initially lost? Secondarily have you tried switching to a static IP to see if that has the same problem? If your switch is already static, this is a stranger problem and I'd be doing packet captures on the port it uplinks to see if you can see any of the management packets and what's happening with them." Have you tried accessing the local status page? Does it say anything? ... View more

It's not something you can do from the dashboard. Support may be able to do something on the backend for you. MAC Flapping is generally a spurious error as long as the macs in question are originating from access points. In Meraki Managed Switches this error shows up all the time in the logs. More an FYI if you ever went down that road. Support may be able to help you now, but if your longer term path includes fully managed they will be back and unconfigurable (as things currently work). ... View more

Any single MX config that could have those ips would possibly cause that error, that includes DHCP, Traffic Shaping, Firewall Rules ... View more

I do not recognize and cannot find an API call with that name. Where did you find that? It may have existed in the past and been replaced by the live tools call for the mac table. They would be duplicative I believe. ... View more

The mac timer is 300s since the port has seen the mac, if the port goes offline, the entry should clear regardless of the timer. If the device stops responding, power save, etc, basically anything where it doesn't generate any traffic, it can also drop out. ... View more

The mac table is going to be the most accurate information at any given time.  MAC tables are live from the switch showing devices connected in the last 300s. Forwarding Tables are MAC Tables Client info is going to have a bit of a delay in showing up, and it includes historical info for up to 30 days. I would stick with the mac table if you are looking for live data. ... View more

Given the intermittent nature and the fact that it's random clients and not even all clients at site, this is going to be hard to track down. Do your VDI clients or servers have any logs that indicate what the issue is? I could see perhaps it being a utilization issue at the sites where it's happening and it just happens that the client in question is the one getting dropped. Are your vdi clients capable of doing testing of any sort when the issue occurs like pings, traceroutes, etc? For monitoring and historical information on utilization, I'd recommend something that monitors with SNMP. IMO, Outside of the live uplink monitor at the exact moment of the problem it's harder to track down historical utilization issues with the dashboard. Something else you could do is setup traffic shaping for the VDI services to try and prevent drops: https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/SD-WAN_and_Traffic_Shaping ... View more

Sounds like a bad definition may have gotten out there OR something got screwed up on the Umbrella servers. I suggest opening a support case. You definitely shouldn't be seeing something like this. ... View more