The GRE encap on a software based router like an ISR should be resolved in CEF from the start, so it shouldn't be two CEF lookups. However, on the software based platforms, every feature you turn on takes a little more CPU so even with a single lookup I wouldn't expect the same performance from GRE that I would from non-GRE traffic. 6k/7600 requires recirculation in hardware and the story is completely different as you are basically running the packet through the hardware twice. -Pete On Fri, Nov 19, 2010 at 12:28 PM, Michael Ulitskiy <mulitskiy@acedsl.com> wrote:
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