Hi there ,   I'm using the new API call for switch Port status but I'm always getting a HTTP 502.   I have also tried the console / debug call from https://developer.cisco.com/meraki/api/#/rest/api-endpoints/switch-ports/get-device-switch-port-statuses but I'm still getting 502.    I have tried with switches from MS11.22 to MS11.30 and still no luck.    Any clues before I open a ticket ?  Thanks. ... View more

Hi ,   I'm always receiving DHCP leases exhausted alerts but when I take a deep look , the DHCP pool is far from exhausted.   10h52 MX came online ( was down for 24h ) 10h54 alarm received 10h56 Validations were made on the MX ( see results below )    I don't get it...    We are running 14.39   Thanks !  ... View more

Hi folks ,    I have been through a strange behavior.    We have a Security appliance template with some ports with 802.1X enabled and some on a Open access policy.    When I applied the 802.1X policy on a open port ( on the template) , ALL the ports went into a reauth or something like that. Result : 300-400 phone calls droppped and phone were unregistered for a solid minute.   This is what support responded :  ( which I was unabled to reproduced in my labs.. )   Unfortunately, this particular outage is expected behavior. In order to make sure that all of the devices are properly authenticating to the ports. Making changes to the ports that are using radius causes the MX to reevaluate ports that use radius. So even though you were just modifying 12, the MX needed to revaluate 11 as well which caused the phone to go down. Has anyone ever experienced this ? ... View more

Hi guys ,   This is fairly new right ? :    https://documentation.meraki.com/MX/Monitoring_and_Reporting/Client_Tracking_Options   Cloud Track Cloud Track is a Meraki technology that leverages network topology and device information to uniquely identify and track clients. It uses an algorithm that intelligently correlates client MAC and IP addresses seen across the Meraki stack, allowing the security appliance to generate a unique identifier for each client in a combined network   with other Meraki devices. This is specifically useful when there are Meraki MS switches routing layer 3 between end clients and the security appliance, which segregates broadcast traffic containing the client's MAC address. This method should be used   only   if the network has downstream layer 3 routing devices that are all Meraki devices. In this deployment scenario, tracking by IP would otherwise require the security appliance to be split into a separate dashboard network, as tracking by IP is not supported in combined networks. Tracking by MAC would fail to identify end client devices due to the layer 3 boundary, associating downstream client traffic to the routing switch and negatively affecting network usage numbers in dashboard ... View more