as further information, the GRE header is 20 bytes, and the entire GRE
header plus payload is then encapsulated within a new IP header of 20 bytes.
This is discussed in RFC 1701. If another protocol is used as transport,
obviously a new header in the appropriate format of that protocol would be
used.
In any case, to return to the point, for a 1000 byte IP packet using a GRE
tunnel, there would be an additional 40 bytes overhead.
I did some experiments with GRE vs non GRE routing a while back. My
recollection of those experiments ( using a pod of 3x2501 routers ) was that
performance differences were not incredibly great. there was some latency
added, obviously. The real killer was that CPU usage skyrocketed. as with
everything else in the world of routing YMMV
GRE IP over IP is covered in RFC 1702, wherein the specifics of the GRE
option fields are discussed. Someone will have to help me out here. The
RFC's don't clarify the nature of the "routing" field, in my mind.
Someone else will also have to help me here. The implication of 1701 is that
any protocol may be encapsulated within any other protocol using GRE. But
why would the IETF care about encapsulating vines over SNA, for example. To
look at the list of protocol numbers, and from other reading I have done,
the whole point of GRE is to provide a mechanism for using IP to transport
other protocols. A quick look at a router options for tunnels:
MANAGER(config-if)#tun mode ?
aurp AURP TunnelTalk AppleTalk encapsulation
cayman Cayman TunnelTalk AppleTalk encapsulation
dvmrp DVMRP multicast tunnel
eon EON compatible CLNS tunnel
gre generic route encapsulation protocol
ipip IP over IP encapsulation
iptalk Apple IPTalk encapsulation
mpls IP over MPLS encapsulations
nos IP over IP encapsulation (KA9Q/NOS compatible)
MANAGER(config-if)#tun mode gre ?
ip over IP
multipoint over IP (multipoint)
Maybe I'm misunderstanding something here? GRE for IP only. Cisco offers
options for using other protocols as the carrier?
Chuck
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Tony Medeiros
Sent: Saturday, July 07, 2001 9:49 AM
To: [EMAIL PROTECTED]
Subject: Re: IPsec tunnel mode vs. GRE tunnel with IPsec [7:11236]
IPSEC over GRE:
The advantages of this configuration is you can run routing protocols
through the tunnel. That means that routing protocols treat it like an
interface or a separate link. That allows you to impliment an ISDN or
something like a zero CIR frame backup for the tunnel. You have to be
carefull how you configure this though. Tunnel interfaces don't go up and
down like normal interfaces. Also, They don't support all the metrics in
EIGRP like "reliability" if you wanted to bring that metric into the
picture. At least they didn't as of 12.0 (last time I looked)
The main disadvantage is overhead. GRE is pretty inefficient. I have not
investigated it personnally, but somebody told me that the overhead for GRE
averages around 40%. Add the overhead of IPSEC to the picture and your
wasting a lot of bandwidth for protocol overhead. Depending on the
switching path, router cpu utilization might be a issue too.
Hope this helps
Tony M
#6172
----- Original Message -----
From: Ciscodog
To:
Sent: Saturday, July 07, 2001 12:32 AM
Subject: IPsec tunnel mode vs. GRE tunnel with IPsec [7:11236]
> I was recently looking at these two options for connecting branch offices
for
> an alternative to a point-to-point WAN link. I have in the past
implemented
> IPsec which by default is in tunnel mode for any packet that doesn't
> originate
> from the direct peers. However I was reading a bit the other day and came
> across the GRE tunnel with IPsec solution and was wondering if this was
> legacy, or better option for my situation. Does anyone have a quick
pros/cons
> response to the 2 scenarios?
>
>
> Thanks
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=11259&t=11236
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
