Cisco GRE/IPSec performance, 3845 ISR/3945 ISR G2

Thu Nov 18 22:39:59 UTC 2010

This is probably more appropriate for the cisco-nsp list, but what
process is taking up the CPU or is it due to interrupts?
To the best of my knowledge the crypto should be hardware accelerated,
while everything else is going to be done in software on the 3800.

-Pete

On Thu, Nov 18, 2010 at 11:10 AM, Christopher J. Pilkington <cjp at 0x1.net> wrote:
> We're running GRE/IPSec transport over a point-to-point DS3.
> We're also doing some QoS.  The traffic mix is voice; our
> average packet size can be as low as 250 bytes at times.
>
> We are seeing incredibly high CPU when the traffic levels
> approach 30Mb/s and around 11kpps in each direction, at times
> over 95%.  We've seen packet loss as well in the priority queue.
>
> We recently forklifted the routers on a point-to-point DS3 from
> 3845s to 3945s, thinking we'd see an improvement in performance.
> We saw no such improvement, and some on our team argue it's
> worse.
>
> I'm assuming here that the packet rate coupled with the QoS and
> GRE is just killing the router's CPU.  That said, are there any
> optimizations that we could consider before ripping this thing
> out completely?
>
> Yes, cef is enabled.
>
> I'm considering changing from GRE/IPSec to VTI, but I suspect
> this will still have the same actual switching behavior through
> the router, and may not change anything.
>
> One other possibility was to run IPSec tunnel mode and just
> exclude EIGRP from the tunnel, but that may be risky (IPSec
> fails == black hole).
>
> Our fall back plan is swap out the DS3 with an ethernet and get
> a L2 ethernet encryptor, but that can't happen until 2011-01-01.
>
> Any suggestions, wisdom?
>
> Thanks,
> -cjp
>
>