GRE vs IPIP Tunneling
By stretch | Monday, February 27, 2012 at 3:51 a.m. UTC
Generic Routing Encapsulation (GRE) and IP-in-IP (IPIP) are two rather similar tunneling mechanisms which are often confused. In this article, we'll examine the operation of each, how they differ, and when each should be used.
IPIP
IP-in-IP encapsulation is exactly what it sounds like: one IP packet encapsulated inside another. The protocol field of the outer header is set to 4 for IPv4 or 41 for IPv6.
Here's a sample capture of IPv4-in-IPv4, and here's IPv6-in-IPv4. All combinations of IPv4/IPv6 encapsulation are technically possible, though not all may be supported on a given platform. Three IPIP encapsulation methods are possible on IOS: IPv4/IPv4, IPv6/IPv6, and IPv6/IPv4.
Router(config)# interface tun0 Router(config-if)# tunnel 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 ipsec IPSec tunnel encapsulation iptalk Apple IPTalk encapsulation ipv6 Generic packet tunneling in IPv6 ipv6ip IPv6 over IP encapsulation mpls MPLS encapsulations nos IP over IP encapsulation (KA9Q/NOS compatible) rbscp RBSCP in IP tunnel
GRE
GRE (defined in RFC 2784 and updated by RFC 2890) goes a step further than IP-in-IP, adding an additional header of its own between the inside and outside IP headers.
The GRE header is variable in length, from 4 to 16 bytes, depending on which optional features have been enabled.
- C, K, and S: Bit flags which are set to one if the checksum, key, and sequence number fields are present, respectively
- Ver: GRE version number (zero)
- Protocol: Ethertype of the encapsulated protocol
- Checksum: Packet checksum (optional)
- Key: Tunnel key (optional)
- Sequence Number: GRE sequence number (optional)
Here's a sample capture of GRE in action. Note that GRE can theoretically encapsulate any layer three protocol with a valid Ether type, unlike IPIP, which can only encapsulate IP.
GRE can be encapsulated by either IPv4 or IPv6 on IOS. (The multipoint option is used for Dynamic Multipoint VPN (DMVPN).)
Router(config)# interface tun0 Router(config-if)# tunnel mode gre ? ip over IP ipv6 over IPv6 multipoint over IP (multipoint)
By default, only a minimal header of four bytes will be included. Additional GRE options can be turned on and off independently of one another:
Router(config-if)# tunnel ? bandwidth Set tunnel bandwidth informational parameter checksum enable end to end checksumming of packets destination destination of tunnel flow flow options key security or selector key mode tunnel encapsulation method mpls MPLS tunnel commands path-mtu-discovery Enable Path MTU Discovery on tunnel protection Enable tunnel protection rbscp Set tunnel RBSCP parameters route-via Select subset of routes for tunnel transport sequence-datagrams drop datagrams arriving out of order source source of tunnel packets tos set type of service byte ttl set time to live udlr associate tunnel with unidirectional interface vrf set tunnel vrf membership
To summarize, GRE can:
- Encapsulate any layer three protocol (versus just IP)
- Add an additional checksum (which isn't useful for TCP/IPv4)
- Specify a tunnel key
- Enforce packet sequencing
Of course, these features come at a cost of additional overhead; in cases where the extra capabilities of GRE aren't needed, IPIP will do just fine.
Posted in VPN
Comments
February 27, 2012 at 8:33 p.m. UTC
GRE on most platforms is in software right? How about IP IN IP?
February 28, 2012 at 2:12 p.m. UTC
Kam, I think there is support for GRE on most router platforms and they don't have problems when it comes to speed. Only switches may have problems when dealing with GRE tunneling, I think on most lower level switches it's not even officially supported, and 6500s are not very recommended to be used as tunnel termination points either.
March 6, 2012 at 11:05 p.m. UTC
Yep IP-IP can be very useful. Surprised it doesn't get more use.
Don't forget to adjust MTU accordingly though. Most transport will expect an MTU of 1500. Since you have some overhead on your tunnel you need to bring down the MTU and adjust TCP MSS to account for the overhead of the tunnel. Otherwise you'll end up with some funky MTU issues to troubleshoot.
Example in IOS for an IP-IP tunnel interface:
ip mtu 1480
ip tcp adjust-mss 1440
May 21, 2013 at 1:12 p.m. UTC
I tested both, and ip over ip tunnel has not keepalive option. In fact, if you specify a wrong tunnel destination ip, the tunnel will be always up.
In gre setup, unless you enter a valid destination, the tunnel will not come up.
October 8, 2013 at 2:58 a.m. UTC
Thanks for the informative article.
I am wondering if you could direct me to some type of open source code that would allow me to encapsulate one packet type within another - either using GRE or IP-in-IP - I would like to look at both otpions. Ideally I would like a matrix:
For node 1 sending to node 2:
In - I pick any packet type to be encapsulated
Out - I pick what packet type 1 should be encapsulated in
At node 2:
Encapsulated packets reassembled as if they had been originally sent
Your response to this is appreciated in advance,
Arlester
April 23, 2016 at 6:16 p.m. UTC
Question: what will be the structure of layers if I tunnel with GRE? Something like : ARP()/IP()/GRE()/IP()/TCP() ??