Meraki

RaphaelL

Hi Kory ! I had the pleasure to work with you on multiple cases 😉 Welcome aboard !

RaphaelL

Hi , I have read the Microsoft documentation about the network requirement about MS MTR : https://learn.microsoft.com/en-us/microsoftteams/rooms/security?tabs=Windows#network-security Has anyone deployed MTR with Meraki ? What did your firewall rules looked like ? I'm hearing that I have to allow almost all of Azure which I really doubt.

RaphaelL

Hi , In your pcap , do you see TLS issues ? Invalid certs / expired ?

RaphaelL

That document is for MR , if those behaviors are the same for MXs that would be nice to add the changes to the MX doc. Thanks ,

RaphaelL

Hi , https://documentation.meraki.com/MX/Access_Control_and_Splash_Page/MX_Access_Policies_(802.1X) I think this page is lacking a lot of crucial information. 1- What happens if you put multiple RADIUS servers ? Is it round-robin ? 2- How is the MX made aware of RADIUS failures / timeout ? Will it go to the next RADIUS server ? 3- Is there a fallback mecanism ? If RADIUS #1 is unreachable and it going to RADIUS #2 , Will it comeback to RADIUS #1 or only switchback if RADIUS #2 comes unreachable ? I do know most of these answers , but I'm pretty sure that would help a lot of people.

RaphaelL

I was going to comment this , even if it sounds stupid a MX cannot snoop a TCP DNS request. It must be UDP unencrypted.

RaphaelL

Hi , Haven't tested all of them , but if you look at the API index there are a few that might help : https://developer.cisco.com/meraki/api-v1/api-index/ getNetworkWirelessDevicesConnectionStats getNetworkWirelessFailedConnections getNetworkWirelessClientConnectionStats

RaphaelL

Hi , Deny LAN won't deny access to the Internet. If you have a MX and MR , I would put the rules on the MX. 1- Deny LAN on the MR 2- Deny RFC1918 on the MX 3- Allow "internet" on the MX That is how we have our Guest SSID configured.

RaphaelL

Hi , https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/SD-WAN_and_Traffic_Shaping Note: ICMP traffic is not subject to traffic shaping rules. As a result, Flow Preference will have no impact on ICMP traffic Traceroute and ping are ICMP based so your flow preference rules will be ignored.

RaphaelL

Just to add to the answer provided by cmr : MX devices running MX 19+ firmware, MS devices running MS 17+ firmware and MS390/Catalyst devices running CS 17+ firmware will use the username admin and the password will be the serial number (Cloud ID) of the device (upper case letters and dashes). All devices running other firmware versions will use the serial number (Cloud ID) of the device (upper case letters and dashes) as the username with no password. https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page

RaphaelL

I'm not sure to quite understand your concern about IP overlap / conflict.

RaphaelL

An update has been posted A mitigation is being deployed to our systems and we are continuing to monitor the results. Your MX device may experience a further onetime reboot now during this remediation. It fits with what we saw

RaphaelL

I think a "fix" was just pushed. We see that they pushed a older SNORT rule. snort_rules_version: 20250409-1715

RaphaelL

Thank you all for the confirmation

RaphaelL

Also experiencing this issue. Can someone confirm they have the issue with any version from 18.211 to 19.2

RaphaelL

Important note Wi-Fi 5 Wave 2 MRs support - This version and subsequent MR 31.x.x are only supported on 802.11ax (Wi-Fi 6) and newer MR models. 802.11ac Wave 2 and older products will upgrade to the backup version (MR 30.7.1) if they are in networks configured for MR 31.x.x versions, and thus, the new features will not be available. The bug fixes listed below will also not apply to Wi-Fi 5 Wave 2 and older MRs. (https://documentation.meraki.com/MR/Other_Topics/Cisco_Meraki_MR_Firmware_Restrictions_Overview_and_FAQ) Bug fixes General stability and performance improvements False positive DFS alerts in Japan on MR56 APs APs stop transmitting on wired interfaces (Wi-Fi 6 APs) Clients disconnect with error code 17 (Wi-Fi 6, Wi-Fi 6E, Wi-Fi 7 APs) Clients disconnect with reason code 0 (reserved) (Wi-Fi 6, Wi-Fi 6E, Wi-Fi 7 APs) Association ID mismatch (Wi-Fi 6, Wi-Fi 6E, Wi-Fi 7 APs) 2.4GHz 802.11n clients unable to connect (Wi-Fi 7 APs)

RaphaelL

Great memes ! Earned a vote

RaphaelL

Added "Modifying the enabled/disabled status of any LAN interface will reset the WAN interfaces, resulting in a connectivity loss on both Internet uplinks for up to 2 minutes. To minimize disruption, follow best practice and only make changes during a planned maintenance window." 😤MX never cease to amaze me in the worse possible way ! I just tested this and I lost 1 ping on both enable / disable , which is still odd.

RaphaelL

Org-wide GP ? Is that a private beta feature ?

RaphaelL

Yes you can. It's called meshing.https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings

RaphaelL

As mentionned by Ryan , pretty pretty sure this is normal. They all group up in one big bucket : Which also explains all the different BSSIDs ( MACs )

RaphaelL

Don't worry Phil , AI won't replace us 😂

RaphaelL

That's weird. /networks/{networkId}/appliance/uplinks/settings is not a valid path. it's /devices/{serial}/appliance/uplinks/settings which return WAN settings ( dhcp , PPPoE [...])

RaphaelL

Hi , I'm trying to find this exact setting with the API : I can't find it. It would be way easier to find endpoints if they would match the dashboard description. Eg : getNetworkApplianceTrafficShapingUplinkBandwidth is not a valid dashboard section. It should be UplinkConfiguration just like getNetworkApplianceTrafficShapingUplinkSelection is a valid section : I feel like the whole dashboard page TrafficShaping is scattered into so many api endpoints. Way too confusing for no reason. 6 dashboard section : Uplink configuration getNetworkApplianceTrafficShapingUplinkBandwidth getNetworkApplianceConnectivityMonitoringDestinations ( doesn't follow the name scheme + named Uplink statistics ) Uplink selection getNetworkApplianceTrafficShapingUplinkSelection ( missing WAN failover and failback behavior on templates ... ) SD-WAN policies getNetworkApplianceTrafficShapingUplinkSelection ( parts of the result is from 2 sections. Confusion +1 ) getNetworkApplianceTrafficShapingCustomPerformanceClasses Local internet breakout getOrganizationApplianceTrafficShapingVpnExclusionsByNetwork ( only a org-wide call ? ) Global bandwidth limits getNetworkApplianceTrafficShaping ( doesn't follow the name scheme ) Traffic shaping rules getNetworkApplianceTrafficShapingRules I might be missing some due to the confusion.

RaphaelL

I would say capwap on large campuses. L3 roaming with Meraki is not the thing.

About RaphaelL

RaphaelL

Raphael Letourneau

Community Record

Badges