Meraki

RaphaelL

Still can't belive that something that simple isn't supported without an additionnal licence in 2025.

RaphaelL

Yes but it is either coming back or I have to 'x' it on every 1500 networks that I have 😣

RaphaelL

In my case , those endpoints were targeted : ( getDeviceWirelessConnectionStats or getNetworkWirelessClientsConnectionStats ) But my feeling is that any "Wireless" stats endpoint will behave like that

RaphaelL

support@meraki.com Nov 07 2024 03:53 Hello, This API is outdated and is not planned to be fixed. There shall be new APIs available with Assurance Overview in the future. We can leave this case open until it is resolved. ### There is a couple of operations related to wireless stats , and I was never able to get a 1:1 match with the dashboard so I couldn't trust either one. I ended up giving up on the possibility to report wireless stats.

RaphaelL

Hi there , Case opened in 2022. Won't be fixed. API operation will be replaced by another "Assurance" operation in the near future.

RaphaelL

@John_on_API Sorry to tag you. Is there a way to open tickets about API documentation and probably an error with the Meraki python SDK ?

RaphaelL

Not exactly the same but this MX related message is annoying :

RaphaelL

Hi , I Just tested it and it works. The documentation is wrong and probably the SDK. https://api.meraki.com/api/v1/organizations/XXXXXXX/summary/top/applications/byUsage?networkIds[]=XXXXX https://developer.cisco.com/meraki/api-v1/get-organization-summary-top-applications-by-usage/

RaphaelL

Best way to do it is with the API. Dashboard is unrealiable as you saw. I had a case opened years ago about WAN2 not showing up from Organization > Overview > Devices , the response was : it's working as designed.

RaphaelL

The MX is in concentrator ( ONE arm ) mode ?

RaphaelL

Hi , Yes with this call you will get the Public IP of the device https://developer.cisco.com/meraki/api-v1/get-organization-devices-uplinks-addresses-by-device/

RaphaelL

The goal is probably to mimic what almost every vendor supports : client assoc limit. https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-9/config-guide/b_wl_17_9_cg/m_client_limit_ewlc.html

RaphaelL

You should avoid "device" specific calls and use this one : https://developer.cisco.com/meraki/api-v1/get-organization-summary-top-appliances-by-utilization/ You can use any value for quantity

RaphaelL

Same exact notes as MS17.1.3 except for : Resolved an issue that prevented an active stack member from managing STP state on other stack members after the active member rebooted General important notes MS17 introduces a change to the default login credentials for the device local status page, using "admin" as the username, and the device serial number (upper case with dashes) as the password Ms12x important notes If DAI is enabled prior to upgrading the network to MS 16, ensure that trusted ports and/or DAI-allow lists are configured prior to upgrading to avoid potential network outages. Ms420 important notes Devices configured for this version will run MS 15.22 New feature highlights Support for MS150 devices DOM (Digital Optical Monitoring) Intelligent Capture RSPAN and VLAN Based SPAN SmartPorts New ms130x feature highlights Adaptive Policy on MS130X/R models General fixed issues Fixed a bug that caused some 802.3af devices to display as 802.3at in Switch Port Details Fixed a bug that caused switches to forward some RADIUS requests that included an invalid source MAC address Fixed a cross-stack port mirroring bug that incorrectly showed CDP/LLDP traffic from the source port as being connected to other members of the stack Fixed an issue that caused boot loops when attempting to upgrade to MS17 while using an externally calibrated third party SFP Fixed an issue that caused clients to get stuck in an auth_pending status until the switch port the client was connected to was bounced Resolved an issue that prevented an active stack member from managing STP state on other stack members after the active member rebooted Resolved an issue that sometimes prevented stack ports from being correctly reconfigured after stack link flaps Ms130 fixed issues Resolved a bug that caused some MS130s to stop reporting to Dashboard while upstream switches reported UDLD issues Ms210 fixed issues Fixed a bug that caused MS210 stack port LEDs to incorrectly indicate an orange light rather than the expected green Ms220 fixed issues Fixed an issue that caused the packet capture files generated by the Local Status Page to be empty Ms355 fixed issues Fixed a bug that occasionally caused some MS355 switches to reboot Ms425 fixed issues Fixed a bug that caused high device utilization on MS425 stacks when multicast routing was enabled Resolved an issue that caused pNIC errors when forwarding some LLC packets General known issues If voice and data are configured to use the same VLAN DHCP discovery messages may not be correctly forwarded from client devices after being authenticated via 802.1x on the voice VLAN LACP links may take an extended time to come back up when the Active Member of a stack reboots RADIUS communications may not recover after an initial failure when Critical Auth is enabled Some clients may be incorrectly added to a configured Guest VLAN when authenticated via RADIUS immediately after a switch reboot Some switches may encounter an error, "incompatible configuration for attributes: allowed_vlans" when attempting to aggregate ports regardless of allowed VLANs configured in Dashboard Switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 or other Catalyst switches unless the bundles are configured on the MS390/Catalyst switches first. All non-catalyst ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present) Ms120 known issues Some client devices may fail to authenticate via MAB in an access policy with hybrid authentication enabled, resulting in 802.1X authentication failures Switches may fail to provide PoE power to legacy access points (always present) Ms12x known issues MS120/125s may fail to forward link-local multicast (224.0.0.x) traffic when 'Flood unknown multicast traffic' is disabled Ms130 known issues MS130-X switches may experience slow upstream throughput when connected directly to an MX device via an mGig port Ms250 known issues Switchport with Multi-Domain Hybrid auth access policy randomly goes into a port not forwarding state Ms2xx/35x/4xx known issues Switch stacks will learn MAC addresses from ports in the STP blocking state which can trigger a constant flood of MAC flaps in the event log Ms350 known issues Cable tests may fail to execute on mGig ports Enabling Auto-stacking on MS350s may remove existing L3 SVIs Ms35x known issues In rare instances, stack ports fail to initialize after an upgrade (always present) Incorrect SFP port mappings may disrupt SFP functionality Switches may experience an unexpected reboot (present since MS 15) Ms425 known issues In rare circumstances MS425 switches may encounter a software crash that results in a reboot In some circumstances ARP requests may not be correctly forwarded after connectivity is restored following an inter-DC VPLS DCI outage MS425s in stack configurations may periodically trigger New DHCP Server alerts that include mismatched VLANs/subnets Ms4xx known issues When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12)

RaphaelL

This is the diff between 18.212 and 18.211.5 : MX appliances will now more gracefully apply firewall rule configuration changes. This will resolve several instances where updating large sets of L3 or site-to-site VPN firewall rules could impact packet processing and network control traffic. Fixed an additional issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances reporting an erroneous spike in network traffic usage. Fixed an issue that resulted in Z4(C) appliances failing to properly forward STP frames received on its LAN interfaces. Corrected an issue that resulted in Z4(C) appliances failing to forward ARP messages that had a VLAN tag, even when the VLAN tagging correctly matched with the Z4(C)'s port configuration. Added proactive mitigations that should prevent new or unforeseen internal packet routing issues from resulting in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization.

RaphaelL

This version has been renamed 18.211.5

RaphaelL

Got it. Do you have a MX with a recent firmware ? if so can you try the live firewall log : It might help.

RaphaelL

Hi , Your DNS flow ( UDP 53 ) is a different flow from TCP/443. Different flow means they each need to be processed and match some rule. Where is that GP applied ? On a client connected to a MS , MR , MX ?

RaphaelL

I was only able to test it in a controlled lab environnement with 2 APs. So my experience is very limited but I will be trying it after we finaly upgrade from MR28.7 next month.

RaphaelL

I wished you guys could announce the products here. I always hear about the products first on linkedin and couple days later they get announced here. ☹️

RaphaelL

This row is also duplicated somehow.

RaphaelL

For those who would like to view the detailed specs : https://documentation.meraki.com/MS/MS_Overview_and_Specifications/MS150_Datasheet

RaphaelL

I don't wish for much only for : STP on MX LACP on MX Port stats on MX Port cycle ports on MX Be able to have firewall rules with Ports , Ports range and different protocols in the same rule on MX.

RaphaelL

As much as I love Meraki and the fact that I don't know how large your environnement is, I wouldn't use a Meraki MX for that.

RaphaelL

You guys rock ! Thanks for the update

About RaphaelL

RaphaelL

Raphael Letourneau

Community Record

Badges