[132294] in North American Network Operators' Group
Re: Cisco GRE/IPSec performance, 3845 ISR/3945 ISR G2
daemon@ATHENA.MIT.EDU (Michael Ulitskiy)
Fri Nov 19 12:29:05 2010
From: Michael Ulitskiy <mulitskiy@acedsl.com>
To: nanog@nanog.org
Date: Fri, 19 Nov 2010 12:28:45 -0500
In-Reply-To: <5D2B264604643843B933666791F5D52F09FCC806@nhrglma1.networkhardware.local>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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?
Michael
