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

Michael Ulitskiy mulitskiy at
Fri Nov 19 11:28:45 CST 2010

On Thursday 18 November 2010 18:18:04 Sam Chesluk wrote:
> There are a couple potential issues, that when looked at in whole, add
> up to a significant performance impact.
> 1) IPSec + GRE involves two forwarding operations, one to send it to the
> tunnel interface , and another to send the now-encapsulated packet out
> the WAN interface.  This effectively halves the total forwarding rate
> before any other considerations.

> 2) While the IPSec portion is hardware accelerated, the GRE
> encapsulation is not, unless this is a Cat6500/CISCO7600 router, or
> 7200VXR with C7200-VSA card.  Because of this, the GRE process itself
> will consume a fairly large amount of CPU, as this is also a per-packet
> process.  The impact is similar to a forwarding decision, so that
> throughput level is halved again.

I would like to question this one.
I always thought that GRE header is pre-calculated and kept in the CEF adjacency table,
thus GRE encapsulation involves no additional processing overhead compared to regular ethernet encapsulation. 
The only difference with 6500/7600 is that encapsulation is done by CPU, not PFC.
I'm in no way an expert in this, but I'd imagine the whole process to be like this:
1. a sinlge CEF lookup/encapsulation produces a GRE packet
2. packet encryption/ESP encapsulation
3. another CEF lookup/encapsulation to get the encrypted packet out
So forwarding rate halved, but just once.
Am I wrong?


More information about the NANOG mailing list