Meraki Campus Gateway vs. MX concentrator - WiFi client throughput

JonathanDixon
Here to help

Meraki Campus Gateway vs. MX concentrator - WiFi client throughput

TL;DR: Is the tunnelling method used between the MR APs and Campus Gateway (VXLAN) any more or less AP CPU intensive than the method used between the MR APs and MX Concentrator (IPSec)?

 

I've been doing some testing with MR36H and MR86 APs tunnelling SSIDs via a MX85 configured as a one-armed concentrator. This is all isolated testing in a lab, single switch, 1Gbps interfaces. Using an iPerf tool capable of about 600Mbps I get the following results:

 

  • A client connected to the MR36H bridged to the LAN can achieve around 570Mbps on an iPerf test. When traffic is tunneled via the MX concentrator, throughput drops to around 220Mbps (ie. around 60% drop in throughput). I get similar results breaking out the test SSID to a wired port on the MR36H.

 

  • A client connected to the MR86 bridged to the LAN can achieve around 400Mbps on an iPerf test. When traffic is tunneled via the MX concentrator, throughput drops to around 244Mbps (ie. around 39% drop in throughput)

 

I'm mainly testing with iPerf but I see a similar drop in throughput when doing an internet speed test. I'm assuming this drop is due to the AP's CPU having to do the IPSec tunnelling. Has anyone done similar tests and observed similar things? Does the VXLAN encapsulation used by the Campus Gateway require more or less CPU power?  Is performance likely to be the same / better or worse? 

 

In reality 200-ish Mbps is fine for our use case and we only see about 1ms extra latency having the MX concentrator in play.

3 Replies 3
DarrenOC
Kind of a big deal
Kind of a big deal

Interested to see how this one pans out.  Also exploring the options around deploying campus gateway.

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
GIdenJoe
Kind of a big deal
Kind of a big deal

Hmm that is strange:  The MX85 is rated to have about 1 Gbps of total VPN throughput.

It is possible that the AP is losing speed due to having to tunnel it's traffic instead of local bridging.

If possible if you could test with a newer AP model that has a faster CPU.

 

The Campus gateway is a multiple more expensive and geared towards large environments with many AP's and large throughput.

VXLAN is still a header that must be added to the header just like in case of VPN and that will have the possibility to be DTLS encrypted so that will probably be a similar drag on the CPU.

 

So the campus gateway itself is more performant than an MX85 but you're still limited of what the AP's can do.

gregpalmer2
Getting noticed

This is certainly going to be a great topic! All things being equal, I expect VXLAN to perform slightly better.

 

A quick AI search reveals the VXLAN header itself is 8 bytes long. However, the complete VXLAN encapsulation adds a total of about 50 bytes to the original Ethernet frame, including an 8-byte VXLAN header, an 8-byte UDP header, a 20-byte outer IPv4 header, and a 14-byte outer Ethernet header. An additional 4 bytes for an 802.1Q tag may be included for a total of 54 bytes.

 

The size of an IPsec header, on the other hand, varies depending on the protocol (ESP or AH), the mode (transport or tunnel), and the algorithms used for encryption and authentication. For example, in tunnel mode with an outer IPv4 header, the additional overhead is at least 58-73 bytes for ESP, which includes an 8-byte ESP header and a 16-byte Initialization Vector (IV).  
 
 

 


If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
Get notified when there are additional replies to this discussion.