Community Record
12
Posts
16
Kudos
1
Solution
Badges
Sep 21 2022
1:39 PM
2 Kudos
Back to early in my career, I had a Mentor - Wally T. He taught me two VERY useful things in my career: "It is far easier to beg for forgiveness than it is to ask for permission." "It still sucks to beg for forgiveness. Make sure you have carefully thought through what you are about to do, so you can explain why you did what you did if/when needed." Thanks Wally!
... View more
Just to make sure readers see this: Thanks to the efforts of our SE, fix for Layer 3 Roaming is confirmed in 28.7 and 29.X beta. Both should be available in the July timeframe.
... View more
Long time no see! Look me up - my cell number hasn't changed since we last talked. It was not Ziply. The ISP in question got the circuit in for us in a hurry, so I'm leaving them unnamed. That said, jumping from 27.7.1 to 28.6 on MR33s made a HUGE difference in network performance with a Layer 2 Bridging configuration. (From almost unusable to pretty good.)
... View more
I know it impacts MR56s, but I do not know if it impacts other MR WAPs. Speculation based on incomplete info: Probably platform-independant.
... View more
UPDATE: Fixed code levels confirmed. See below. There is a known issue with Meraki MR wireless code with the MTU changing when L3 Roaming. Using Ping on macOS, I am seeing an MTU of 1448 on WiFi. It should be 1500 to match the interface MTU on the client machines. I'm posting this to save others time and aggravation. Symptom Of The Issue Pinging on a SSID that uses Layer 3 Roaming. The WAP is actually telling us its MTU. Generate 1500 byte Ping packets - look at the 3rd line below % ping -c 2 -D -s 1472 www.boeing.com PING www.lb.boeing.com (130.76.184.142): 1472 data bytes 556 bytes from 10.34.130.34: frag needed and DF set (MTU 1448) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 dc05 c58d 0 0000 40 01 9294 10.34.152.2 130.76.184.142 Request timeout for icmp_seq 0 556 bytes from 10.34.130.34: frag needed and DF set (MTU 1448) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 dc05 a50c 0 0000 40 01 b315 10.34.152.2 130.76.184.142 --- www.lb.boeing.com ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss Lowering Ping packet size to 1448 - and it now works % ping -c 2 -D -s 1420 www.boeing.com PING www.lb.boeing.com (130.76.184.142): 1420 data bytes 1428 bytes from 130.76.184.142: icmp_seq=0 ttl=49 time=45.630 ms 1428 bytes from 130.76.184.142: icmp_seq=1 ttl=49 time=43.216 ms --- www.lb.boeing.com ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss Note: For the pings above, ICMP has a 28 byte overhead. (1472 + 28 = 1500 bytes.) Code levels impacted: Issue was found in MR 27 code and is still present in MR 28.6.1. Meraki Engineering is aware of this issue. Fix Incoming: The next 28.X firmware release is likely (but not yet confirmed) to have that issue resolved. No ETA for the next firmware release. Thanks to the efforts of our SE, fix is confirmed in 28.7 and 29.X beta. Both should be available in the July timeframe. Workaround from Meraki Support: Use Bridge Mode for now if it is not absolutely necessary to have L3 roaming. If you are having this issue, please open a case with Meraki Support so that they know you are impacted by the issue.
... View more
Labels:
- Labels:
-
Other
This is still an ongoing issue - See the thread on the subject at the URL below for all the details: https://community.meraki.com/t5/Wireless-LAN/MR46-MR55-WIFI-6-AP-s-disconnect-from-dashboard/m-p/149868#M20809. I'm running MR56 WAPs with 28.6.1 and they are unable to stay connected to the Meraki cloud for more than a few minutes a time. Going back to 27.7.1 is not a great option due to bugs fixed in 28 code.
... View more
My Accepted Solutions
Subject | Views | Posted |
---|---|---|
3001 | Jun 4 2022 12:09 PM |
My Top Kudoed Posts
Subject | Kudos | Views |
---|---|---|
3 | 3094 | |
2 | 20819 | |
1 | 3001 | |
1 | 3063 |