About RaphaelL

RaphaelL

I was a bit wrong. The MX will honor the value but it won't perform MSS clamping , which I'm trying to confirm with Support if that's the expected behavior.

RaphaelL

Edit : I tried a more common MTU value ( 1492 = PPPoE ) and still the MX won't honor it : Might have to try with a different firmware version ( running 18.107.4 and 18.107.5 )

RaphaelL

Hi , Have you tried removing the .serial from the line result = dashboard.organizations.getOrganizationInventoryDevices.serial(organization_id)

RaphaelL

I have a packet capture running on the "WAN" side of the MX and I can see the MX sourcing packets > 1400 bytes. It "should" be using my option 26 which is set to 1280.

RaphaelL

Hi , I'm trying to test DHCP option 26. I have 1 DHCP device ( another MX ) configured with DHCP option 26 with a value of 1280. My second MX ( the DHCP client ) sends a DHCP Discover ( D-O-R-A ) and requests in DHCP option 55 ( PRL ) the option 26. The DHCP server responds ( D-O-R-A ) with the option 26 , but the MX ends up ignoring that value. The MTU stays unchanged. I'm wondering if that has ever worked or simply bugged in MX18.107.x

RaphaelL

That's because Meraki thinks that it is a normal condition. You probably don't have BPDU guard on that port , hence you don't have any warnings. In that case , I don't think you will be able to spot those via the API.

RaphaelL

Hi , They are different and you should probably apply both. https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering_Powered_By_Cisco_Talos They are also listed on Talos Website. https://talosintelligence.com/categories#contentcats

RaphaelL

Go to your firewall settings of that MX100 : Do you see any L3 firewall rules ? : You will need atleast one rule to allow the flow between your workstations on vlan 200-300 to your vlan 100. You can add an 'allow any any any' rule to see if that works , and adjust the details later.

RaphaelL

An orange port like that one will show up as a 'error' or 'warning' : {"portId":"13","enabled":true,"status":"Connected","isUplink":false,"errors":[],"warnings":["BPDU guard activated, STP discarding packets"],"speed":"100 Mbps","duplex":"full","usageInKb" https://api.meraki.com/api/v1/devices/{'serial'}/switch/ports/statuses I have to "thank" my users for that example... haha

RaphaelL

Can you telnet the printer on some port ? 515 , 9100 or any other printing ports used by your printer ? Are you sure that you don't have any L3 firewall rules blocking that type of trafic ?

RaphaelL

Hey @PhilipDAth , I think it is now fixed in 1.37.2 https://github.com/meraki/dashboard-api-python/releases/tag/1.37.2

RaphaelL

It would be : https://developer.cisco.com/meraki/api-v1/get-device-switch-ports-statuses/ You would see the port status

RaphaelL

Not only that , but the default behavior for templates and standalone networks is different. That means you have to check every single network and templates to make sure that it is disabled. This used to be a backend option 🙂

RaphaelL

Hi , We need a bit more info on your setup. WPA2-Enterprise ? What firmware ? Anything in Wireless Health ?

RaphaelL

https://documentation.meraki.com/MX/Site-to-site_VPN/Troubleshooting_Non-Meraki_Site-to-site_VPN_Peers Non-Meraki VPN connections are established using the primary Internet uplink. In the event the primary uplink fails, the VPN connection will use the secondary Internet uplink. Closest I could find

RaphaelL

Do you have client sampling enabled on uplinks ?

RaphaelL

If you are load balancing , I don't see the need to swap the cables. As stated just adjust the settings in your flow preferences / Shaping and uplink selection

RaphaelL

It is not the fix that I have been waiting for !

RaphaelL

Important note While Meraki APs have traditionally relied on UDP port 7351 for cloud communication, and TCP ports 80 and 443 for backup communications, with MR 28+ we are beginning the transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that all “Meraki cloud communication” traffic specified in the "Help" > "Firewall Info" page is allowed through any firewalls or security devices that are deployed upstream of your Meraki APs. These requirements have been updated in November of 2022, so it is important that you review them. (Wi-Fi 6 and Wi-Fi 6E APs) WEP deprecation (https://documentation.meraki.com/MR/Encryption_and_Authentication/WEP_Deprecation_on_MRs) Legacy product notice When configured for this version, MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 will run MR 26.8.3 Bug fixes General stability and performance improvements WPA3 OWE AKM suite missing in beacons Incomplete configurations when using VLAN profiles Intermittent connectivity loss for Windows client devices When using WPN, DHCP requests are missing option 55 Known issues Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) In high capacity wireless networks APs may experience instability when the “Client Balancing” or "Band Steering" feature are enabled Could that be the magic fix that I have been waiting for months !?

RaphaelL

I don't have the answer sadly , but I would guess 4G, LTE and 5G ? I will check if I have any MG around.

RaphaelL

According to RFC, the first 3 octets are derived by OUI, and from OUI lookups cc:03:d9 and 88:15:44 are Cisco Meraki. Hence, RFC is followed. Which RFC ? Because VRRP RFC states that there is already an official IANA OUI reserved for VRRP. The next two octets (00-01) indicate the address block assigned to the VRRP for IPv4 protocol

RaphaelL

I agree. By "Meraki's limitation" I meant to limited segmentation between flows (start/end) and firewall rule logging. By disabling the flow start/end , that would solve 90% of my issues.

RaphaelL

Hi , We are currently busting our SIEM capacity due to Meraki limitation regarding syslogs. Eg : We have a client connected to an MR36 AP and the traffic is routed by an MX68. Syslog is enabled for flows,Urls. Logging is enabled on the rule. MX version is 18.107.5 Doing a get to www.microsoft365.com will generate : 1 "flows" on the AP and the MX 1 ip_flow_start on the MX , 1 ip_flow_end on the MX , 1 'URLS' on the AP 1 'URLS' on the MX 1 'firewall' on the MX. 7 syslog event for a simple get. Mutiply that for 40K users and we have our nightmare. 1- Removing the 'logging' for the web browsing rule will only remove the 'firewall' logs. 2- Removing 'flows' from the syslog configuration will remove ALL ip_flow AND firewall logs Ughhh , I can't seem to be able to find a solution.

RaphaelL

Well it all begins with Meraki not following RFCs. https://documentation.meraki.com/MS/Layer_3_Switching/MS_Warm_Spare_(VRRP)_Overview The virtual MAC address will always begin with 88-15-44 The screenshot of the documentation shows otherwise , and your packet captures will show otherwise. If my memory serves me right , I had 2 posts. My MX450 and MX250 were behaving "the Meraki way" but a MX68 HA wasn't. https://datatracker.ietf.org/doc/html/rfc5798#section-7.3 The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the following format: IPv4 case: 00-00-5E-00-01-{VRID} (in hex, in Internet-standard bit- order) The first three octets are derived from the IANA's Organizational Unique Identifier (OUI). The next two octets (00-01) indicate the address block assigned to the VRRP for IPv4 protocol. {VRID} is the VRRP Virtual Router Identifier. This mapping provides for up to 255 IPv4 VRRP routers on a network In real world : cc:03:d9:xx:xx:xx Documentation : 88:15:44:xx:xx:xx RFC : 00:00:5E:00:01:XX Bit confusing eh ?

RaphaelL

Hi , It seems like there is a global outage touching Meraki - Insight ( WAN Health ) - Speed tests : Tried multiple shards , Orgs , Network , devices , users , browsers , computer and so on. It is not a client-side issue. Opening a ticket. And once again this should be added to https://status.meraki.net/ ... Cheers ,

RaphaelL

Raphael Letourneau

Community Record

Badges