just want to let everyone know, that if you are experiencing weird performance issues while using L3 in Meraki, lags, retransmissions in packets and you have the "A client is detected sharing its IP address via NAT" option enabled, then disable it - might solve the issue.
Had the exact same issue. Avoid switching this feature on as it will bring you network to its knees!!!
Great work Meraki 😡 Why if its a know issue still have the feature available to enable???
Along our case (which took ~2 months to figure out!) I heard from the support, that they have at least one case with the same symptoms (while we were still having issues) - maybe it was you? 🙂
The experience in this case was way below expectations, to get any info I needed to call them each time, we lost a lot of time waiting in the phone queue, not to mention the network issues we had with internal and external traffic, all the time.
This took me 2 YEARS to figure out. Just noticed it in the 15.18 release notes as a known issue since MS14, but the MS 14 release notes didn't mention it. WHY IS THIS STILL ABLE TO BE TURNED ON???
Now that i'm done complaining i'll add some of the symptoms we had so others can find this post.
Our copiers would fail to log in via the papercut software
Our copiers would not scan to email with papercut software. It would get an http error that was likely due to dropped packets.
Loading microsoft portals would time out. endpoint.microsoft.com and portal.azure.com would run extremely slow or fail completely. This was especially noticeable when trying to load our licenses on portal.azure.com
Microsoft online o365 logins would frequently fail/timeout. we would have to try try again.
All of this was apparently caused by this "known" issue.
"Enabling NAT detection may cause issues with TCP streams resulting in pages failing to load entirely or taking longer than usual to load (present since MS 14)"
This is listed as a known issue for 15.18, but was not listed in our previous 14.33.1. Didn't get to see this known issue until we update our firmware this week.
Please Meraki, disable this feature. It should not be able to be turned on. No one would want the trade off of TCP connections failing just to detect NAT. If you MUST leave the option please put giant warnings in the dashboard when it is turned on.
We started noticing issues with MS O365 services exactly as you mentioned (also SSO and so on).
Their support on these cases was just way under expectations.
After someone on their side figured this out and asked us to disable the option I went back to them and said that nowhere on the dashboard or in their documentation is a mention about the load this feature causes (it’s basically overloading the CPUs, that was the symptom that a few technicians confirmed) and that there might be issues.
I asked them to add a note and to add the info to the known bugs and as you can see, they never did that.
They also don’t give you a option to monitor the load on switches, just in case.
The support experience with this case was just rubbish, they would run captures and then say they weren’t correct and they need to do them again (a few weeks in, wasting my time numerous times). And then I would explain to them that they are not able to run proper captures, and we as well, because something is wrong.
And to sum up, most of the support experience is bad, they will tell you that the internal team has analyzed some internal logs and the switch is ok, but if you ask them to provide the logs, to show me as a proof - they would just ignore that part of the message.
Hey folks! I'm sorry that anyone has experienced issues with NAT detection - while it works well overall, we agree that it's not meeting our expectations so we're making arrangements to turn it off until we can tune it to be helpful without causing issues.
Thank you for the feedback and patience!
Thank you for the response! I appreciate that approach, because I don't think anyone would want it on considering it's current performance.
That is some good news, I must say that our case was closed on the 14 of June 2022, so this took quite some time, but still - better this than nothing for all other customers that simply don't know about the bug.