Skip to main content
ispcolohost
ispcolohost
New Member
February 8, 2017
Question

Site to site 100d ipsec throughput?

  • February 8, 2017
  • 1 reply
  • 5706 views

Hi all, are there any known issues with throughput of the 100D for point to point ipsec vpns?  We have a bunch of locations where there are either 200D's or 60D's, but only one location with a 100D, and traffic to that one seems to be much slower than the actual internet connection.  Using iperf I'm seeing perhaps 30 to 50 Mbit/sec.  If I measure between 60D's and 200D's, no problem achieving multi-hundred megabit rates.  The same location with the 100D has no throughput issues with traffic that does not cross the VPNs, so we know it's not a connection and/or speed/duplex mismatch type issue.  I've tried lowering MTU on both ends as well to test, no significant change.

 

If I look at diag vpn ipsec stat, I can see that my 100D obviously does not have an NP chip like the 200D, but it does show all aes / sha256 packets being handled by CP8_0 and not SOFTWARE, if that matters.  Also, for reference, our tunnels are AES256/SHA256 DH 14.

 

Thanks

    1 reply

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    February 8, 2017

    100D doesn't have NPU, only SPU. IPSec throughput on the datasheet is showing only 450Mbps. 60D has NP4 and the number is 1Gbps. 200D has NP4Lite and 1.3Gbps. This is the fact I found on datasheets. Encryption/hash algorithms affect performance significantly if the unit doesn't have an NPU in the architecture. We recently tested and compared 50E(no NPU) and 60D(NP4) sandwitched by two iperf servers to find this out. You can test 100D yourself since you have iperf test environment.

     

    Then you're not exhausting all factors to conclude Internet path is not the issue to the particular location you see lower number. Are those all locations served by the same ISPs? Have you checked internet paths for two separate directions A->B and B->A (they could be different) how to get to the other side?

    We've been dealing with this in many situations (no 100D though). But every time Comcast is on the VPN path on the west coast of US the test result fluctuate significantly. You should test publicIP-to-pablicIP outside of the tunnel to rule out the internet path issue.

     

    ispcolohost
    ispcolohostAuthor
    New Member
    July 14, 2017

    Sorry for the delayed reply Toshi, I never got notified of your post.  You were correct on the 100D, it was entirely CPU-bound and apparently is pretty poor when SHA256 is involved since it only has a little 1.6ghz Atom.  Unfortunately, on the 200D side, it appears that while its NP4Lite can do SHA256, that's only the case when the traffic is IPv4 and we have a decent mix of IPv6, which the "diagnose vpn tunnel list" command confirms is hitting the CPU.

     

    I'm waiting to hear back on whether the SoC8 (60E/80E/100E) and the NP6Lite/CP8 in the 200E fully accelerate AES256/SHA256 tunnels for reasonable throughput, if it includes IPv6 tunnels, and what type of throughput to expect.

    Terms & ConditionsAccessibility statement