Make sure you are running MX 16.13 on your MX85, there are performance issues in older versions. ... View more

For the sake of thoroughness I ran some additional numbers on the passthrough test case.   Test client: 2018 Macbook Pro, MacOS 11.6, Safari 15.0.   I am testing using fast.com My fast.com settings are: Connections: 8 min, 16 max Duration: 15 sec min, 30 sec max   Test Case 1: test client -- MX85 (passthrough) -- MS120-8LP -- MS120-8 -- MS120-8LP -- Cisco Firepower 1010 ASA Mode 9.16(2)3 -- Google Fiber -- Fast.com   Results - download / upload:   630/770 390/780 640/790 620/790 560/780 510/740 520/730 680/710   All numbers in mbps.   Test Case 2: test client -- RJ45 coupler -- MS120-8LP -- MS120-8 -- MS120-8LP -- Cisco Firepower 1010 ASA Mode 9.16(2)3 -- Google Fiber -- Fast.com   Results - download / upload:   1.1gbps/710 1.1gbps/740 990/770 1.0gbps/730 1.0gbps/790 1.0gbps/730 990/720 1.0gbps/750   All numbers in mbps unless otherwise indicated.   Interestingly, upload speeds seem to be fairly consistent. Download speeds are not. I've tested this on 16.8 and 16.12. The results are the same. No other clients are connected to the MX85 except this test client. ... View more

@NateF I do not have any of those features enabled. The MX is attached a completely new MX network, the config is default. There's no firewall rules, no IPS, no AMP, nothing. Just raw L3/L4 firewalling. ... View more

I'm going to reply to my own thread again just to keep documentation of the testing I'm doing. With the MX85 out of as my main router, I've now got this topology:   Google Fiber (1gbps) --- FP1010 (asa mode version 9.16(2)3) --- various MS120-8 switches --- MX85 (bridge mode) --- test client   In this setup, the MX85 is in bridge mode. The rest of the MX network settings are default. I'm doing a simple speedtest using fast.com. The results are all over the map. Some as low as 250mbps down, to as high as 650-700mbps. Nothing that shows a 1gbps. If I disconnect both cables from the MX85 and connect them together using an RJ45 coupler (eww), I immediately get 1gbps download on the next test on fast.com.   I'm not sure what else to even look at. I'll get to a point where I think I've narrowed down a set of consistent test results / conditions only to have the results change dramatically on the next test.   Another oddity is that I've been getting a warning in the dashboard that the MX isn't connected using TCP/443 for its tunnel to Meraki when attempting a code upgrade (16.8 -> 16.12). I never saw that on the MX67, ever. There is no firewall blocking it. Maybe there's a process on the MX85 that keeps crashing / restarting causing unnecessary processor load that would explain the wonky performance. ... View more

@ww Are you using VLANs in your configuration? I've adjusted my test setup and moved my MX85 up to my test bench. I also moved it to a fresh MX network so it has a near default configuration on it. My results are:   No VLANs - test client connected to port 5 - 960mbps combined upload/download throughput. So this is pretty much near line rate, which is the expected performance.   5 VLANs (1, 10, 20, 30, 40) - test client connected to port 5, access port, VLAN 1, consistently gets a combined throughput of ~860ish mbps.   The behavior is repeatable. The weird thing about it, the extra VLANs, 10, 20, 30, 40, don't have any active clients, or, any active ports. They're simply configured. VLAN1 is the only VLAN that's actually in use because that's the only client connected. In either test scenario the test client is just an access port in VLAN1. It's unclear to me why just the presence of other VLANs (everything else is MX network defaults) would drop the performance so severely. The MX67 this MX85 is going to replace had no issues hitting the 450mbps rated max, even with VLANs enabled. ... View more

@cmr You are correct, MX 16 seems to be the only supported version at the moment. I obviously recognize that it's the beta release, but I don't have any other options. This performance delta is not called out as a known issue. If it is, it should be listed. ... View more

@Dunky It's not supported on v14. v16 the only supported train at the moment. ... View more

Following up on my own post here. I replaced the MX85 with a Cisco Firepower1010 running ASA 9.16(2)3. It performed both tests, Test1 and Test2 at full line rate (930mbps). This is a direct swap using the same cables, same test hosts, same WAN link, same background noise traffic.   The MX85 is not performing to spec on 16.12. ... View more

@Brash While I certainly agree that routed operation takes more horsepower than switching, this is a question of the device performing to the specs as outlined in the datasheet, which it currently is not, by almost 25%. These are large (1500 byte) packets, in a single long lived flow. This should be one of the easiest flows to reach the max throughput of this device.   I will note that there is other background traffic/noise present on the network but not enough to explain the consistent impact to the performance. That noise would also impact Test1, which is consistently reporting line rate transfers on the gigabit links. The results thus far are very consistent which rules out any impact from the background traffic.   Interestingly, when I disabled traffic analytics I saw a small, but measurable difference in throughput, 730 vs 700. My theory was that disabling traffic analytics, and thus NBAR2, would lower the CPU-load on the device. My results suggest that this is the case. This would 100% reproducible as well.   I've got a case open with Meraki support but I was curious to know what the rest of the community is seeing. ... View more

Look for an "rport" option inside the phone's configuration. This helps deal with NAT, especially when there's multiple phones behind the same NAT device. ... View more

It's nice to see the packet loss for voip/rtp packets on the old APs (MR42s) finally being fixed after two+ years. The timeline there is a big ridiculous, but a fix is a fix, so that's good to see. I installed this on my MR44s last night with no ill-effects.  ... View more

The switches will essentially seem them as connected directly to one another. So, you should plan your STP deployment accordingly. Also, if you trunks are carrying different VLANs be prepared to see VLAN mismatch errors in the dashboard unless you configure both trunks identically. ... View more

I may be mistaken, but I believe those pre-canned policies to also be group policies, just not custom-defined ones. ... View more

I believe this is listed in the release notes as:   Known Issues Group policies do not correctly apply to client devices     ... View more

Its unlikely that they'll replace it. Water damage from a water leak would typically fall on your insurance company to deal with. ... View more

Not that I know of, NAT is only for (V)LAN --> WAN flows. I'm curious though, what is the design situation requiring internal NAT? ... View more

Replying to myself again. I've identified the trigger that causes the dataplane crash. I've passed the info on to support. ... View more

Unfortunately, it isn't going well. I spent a good deal of time analyzing the packet captures trying to identify a problematic flow that might be causing the problem but wasn't able to find one. Support is asking to troubleshoot live over the phone, which is difficult for me to support because each time the switch goes out it takes the rest of my network with it. I'm not sure what they'd see from the "backend" as they call it because the entire switch control plane dies, it won't be talking to the backend once the problem happens. ... View more

Replying to my own thread, again. I ran an additional test. I deleted and reconfigured the IGMP querier on another switch in the network. The same problem happened, 18 minutes after the IGMP querier was configured. During the test I ran a packet capture on a span port of the switch's uplink port. At the 18 minute mark five different control plane flows from the switch stopped responding:   1. A mtunnel link to the Dashboard went from a two-way traffic flow to one-way, with only traffic from the Dashboard being observed.   2. The second mtunnel link to the Dashboard went from a two-way traffic flow to one-way, with only traffic from the Dashboard being observed.   3. ICMP ping requests from my laptop to the switch started failing.   4. LLDP broadcasts from the switch stopped.   5. IGMP queries from the switch stopped.   All five of these flows stopped with 4 seconds of each other. The switch rebooted itself (presumably because the watchdog timer expired) around 7 minutes later. I've passed this all along to Support via the case I have open. ... View more

Replying to my own thread here. I've dug further into the surrounding evidence and it appears to enabling the IGMP querier for the first time on an MS120-8 switch is hosing up its control plane. Specifically:   1. The Dashboard reports "No Connectivity" for this switch when the problem occurs. This is an incorrect status as the MX67 which sits in front of the switch does not report the same. I believe "No Connectivity" is shown here because the control plane of the switch stops working. This makes it unable to properly send and/or respond to keepalives or heartbeats across its mtunnel to the Meraki Dashboard.   2. Once this problem occurs, DNS is no longer able to traverse the switch. I believe this is because the switch does some form of DNS snooping so that it can intercept queries to "switch.meraki.com" to be able to display the local status page. With the control plane jammed up/broken this DNS snooping fails. This is supported by the Dashboard status for all Meraki devices BEHIND this switch reporting "DNS Problem" during the same time period. I've also taken packet captures from the DNS server in the network at the same time and observed no incoming DNS requests.   3. There is a spanning tree topology change when this issue occurs. The other two switches in the network, which are only connected to this problematic switch, change from root ports to designated ports (as shown in the event log during the issue). This should not happen. I have specific spanning-tree priorities configured. This problematic switch should ALWAYS be the root switch. Spanning tree is a control plane process. When the control plane fails, spanning tree will also.   4. ICMP and SSH through traffic does traverse the switch during the issue. Presumably this type of traffic doesn't require any control plane processing so it is switched in hardware, as expected.   5. I suspect the unexpected reboot of the switch is because the platform watchdog timer embedded in the switch isn't being serviced because the control plane is hosed up. Once the control plane stops processing any traffic from the network I assume it also stops processing/servicing the watchdog as well. Based on the timing of events I suspect the watchdog timer is around 10 minutes.   6. I suspect other functions that require control plane processing are also failing though I haven't captured any data yet to be sure. DHCP (because of DHCP snooping), LLDP transmission, and the IGMP querier itself are probably also impacted by this when the control plane locks up.   For whatever reason the initialization of the IGMP Querier feature is locking/hosing up the switch's control plane. Unfortunately I don't have access to any platform logs so I can't tell if this is a CPUHOG issue, an input queue wedge, or something else bizarre. ... View more

How is this still not fixed?   Downstream VOIP RTP Packet Loss (MR42/MR42E/MR52/MR53/MR53E/MR84)   This has been broken for at least 18+ months. It makes Facetime calls absolutely unusable. The only workaround it to reset all DSCP values on the switch side to (presumably) prevent the traffic from landing in whatever queue on the AP is jacked up.  ... View more