I you have that firmware, it just works?  No need to call Meraki for their magic fix? ... View more

Exclude Uplinks ... View more

Back to the archives and v11?  Nice!  Yes - some sort of CoPP would be helpful for sure.  I'm also still looking into ChromeOS - I feel it's misbehaving re DNS and certainly not helping the issue. ... View more

I'm not NEAR as familiar with Meraki switch architecture as I was with traditional Cisco, such as the Catalyst platform.  But, I can assume like many platforms they have ASIC's or SOCs... whatever - that handle the basic packet switching functions really fast - no issues there.  But, all the functions people like; such as traffic analytics, need traditional CPU power.  Looking at DNS packets is how they can can tell you what urls are being used and by which clients.  Similarly, functions such as dynamic arp inspection - or even STP, IGMP snooping, and basic ARP likely all need CPU cycles - so any sort of flood/storm (high pps for these packet types) may cause issues. It's unfortunate we (users) can't control this at any level in Meraki.  Perhaps if you disable traffic analytics entirely, but I don't have any details on what that influences.  These issues also don't present themselves in the logs we have access to; so challenging to troubleshoot. Would be awesome if this stuff was logged AND we could control it at the switch level.  Ie:  Enable it on access layer switches (and/or AP's) so we still collect the telemetry, but disable it on aggregation and core layers if/when it's problematic. ... View more

Interesting.....  Maybe - but Meraki may have resolved it with their double top-secret access.  Disable "dns analytics", which we had asked earlier to disable anything related to dns inspection. It's apparently a known bug.  😞 ... View more

How were you able to go back to 16.x?  Not an option in my dashboard. ... View more

17.1.4 is stable.     Would be nice if I could disable any sort of DPI type stuff.  Just give me a firmware that will move packets and have basic Meraki mgmt functionality.  Or just fix it - that would also be a good option. ... View more

Hi,  Sorry for delayed reply. Most I know of in our customer base is maybe 10.  Since Meraki is vague at best re the root problem and solution, can't say if 25 will be fine - guessing so.  The more active translations you have (port contention) the more likely you are to have issues.  May have to restart switches over and over until the ports they use locally can align with the ports the MX has available to NAT. ... View more

PS: This location uses ChromeOS - which I don't think local dns caching is actually working, but haven't done enough testing to be certain.  google apps resolve a lot of name - so add all this together and it's making for a bad week. ... View more

I think I saw that bug - don't think it's related.  The throughput seems fine, assuming they can actually resolve the names to connect.   Once the client doesn't get a response, then it retries...  things get amplified.  Colleague just noticed ~ 7000 dns pps.   ... View more

Glad it's working!   "Proprietary"....   🙂   Like the KFC recipe?  Hopefully they will publish a KB / tech-note / whatever on it soon.     ... View more

PS: You have a case number I can reference?  Want to ensure the same changes that worked for you were applied to my customer.  When I stated the issues persisted after the change, of 5 NS's, only 2 got NAT B - other 3 got NAT D.  As mentioned, I believe if the UDP ports are already in use, one would have to reboot NS over and over until it works....  How many NS's you have? ... View more

See my response to @RowellDomingo .   Adding a network switch does nothing - it's all about the NAT.  If adding that network switch helps you build another network and your NS's can then get a dedicated public IP address - sure - that will work.  Not the best option for sure...   if you have the public IP space, 1:1 NAT is your best bet.  If you don't...  Maybe the quickest/easiest option is a 5G WiFi HotSpot dedicated to eSports?  Not great either - as latency will be a bit higher, but it will at least work, and those are like $50/month - maybe less depending where you are.  OR - if someones phone has a good 5G hotspot and data plan, that may also be a temporary option. I'll know a bit later if some of my other ideas may work - stay tuned. ... View more

Sounds similar to what they told me.  They made a change on one firewall in question, but the problem persists.     I believe the issue is; any change in udp port for the NS will break it.  Ie:  I boot up a NS and it randomly decides to use udp 55000.  If it hits a NAT device, and 55000 is available - no problem - NAT type B everything is happy.  But what if 55000 is already used?  NAT device will pick something else, 55001 or whatever - now it's NAT type D and breaks.  (I have not done extensive testing on this - but I think it's what's happening)   There are two potential sources of the problem then; both break the 1:1 UDP port mapping NS's must have for some dumb reason:  - Port Randomization on NAT device.       - Disable Randomization  - NS wants to use a port already in use.     - Reboot NS until it grabs a UDP port not in use. The problem with "in use" ports, the more devices/students - the more ports will likely be in use and higher probably your NS will get NAT-D.   Especially if using google QUIC or other apps using UDP vs TCP. The MX's don't support NAT pools (WHY?!?!_ , so you can't say...map the NS's to a different public IP address basically reserved for them.  (Less devices on an IP means more likely NAT will work correctly.) I'm testing another solution now, but the only 100% solution I know of is 1:1 NAT for NS's: each NS gets its own unique public IP address.  Many schools I work with don't have large IP pools, sometimes just a single IP, so this can be problematic to say the least. Will keep this list updated with my testing, but in general, try to limit the number of devices using the same public IP as the NS's.  And definitely disable port randomization - whatever Meraki calls it.   ... View more

Hello, thanks for reply.  I sorta like the IPv6 idea.  But, let me explain a bit further:    - Cisco routers/NAT do not randomize source ports by default.    - pfSense does randomize by default, but you can disable it - which we have.   Source port randomization is...   1.1.1.1 tcp 55555 to 2.2.2.2 tcp 443 when NAT'd becomes 1.1.1.1 tcp 31673* to 2.2.2.2 tcp 443.  * is the randomized source port.   I know in theory non-random ports are more vulnerable to certain attack vectors, but in practice - it's not even in my top 10 list of worries.   I opened a case with Meraki support.  We'll see...  ... View more