GRE Tunnels are “Transport Protocol” in the way that they can encapsulate almost any type of traffic (making them ideal for DMVPN), and create a point-to-point Tunnel through a network, specific to the TSHOOT exam to allow IPv6 packets to route over an IPv4 network segment!
Very crucial Tunnel vs Transport mode for IPSec over GRE Tunnel interfaces:
IETF IPSec Tunnel vs Transport mode: Pro’s and Con’s
GRE Tunnel review
Before going to deep into GRE, want to display a graphic to visually show the differences between Tunnel and Transport modes for exam day:
IPSec uses AH (Authentication Header) and ESP (Encryption Security Payload) as its two main types when running over GRE, and its important to note the differences:
- ESP Encrypts the packets while AH only Authenticates
- Tunnel Mode requires a new IP Header due to encapsulating the original packet inside of a new packet, whereas Transport Mode uses the original IP Header
- Note how the packets are formatted, the AH Mode has an AH header that must authenticate for the Data to be read, however it is NOT encrypted!
Also a good note is that Tunnel Mode works better with GRE Tunnels due to the lower MTU size / overhead, the new IP Header works well for NAT, whereas AH mode needs a NAT-T (NAT Traversal) because its packet needs to avoid the NAT on the router!
Now back to GRE Tunnel details for exam day!
Some of the basics of GRE to review quick:
- GRE uses IP Protocol 47, so if that is blocked by an ACL, GRE will be blocked!
- Default tunnel mode for GRE is Point-to-Point / GRE IP
- “tunnel mode gre ip” on tunnel interface to config it back to default tunnel mode
- “sh int tunnel#” to view tunnels interface configuration
- Tunnel interface IP = Overlay Addy RFC 1918), Tunnel interface IP = Underlay Addy (Internet / Publicly routed IP Address)
- GRE allows for Routing Updates to occur between sites (over the internet) by encapsulating the protocol and payload in a GRE packet for transport
- “sh ip route” will show remote routes with the Next-Hop of Tunnel# interface
Some initial questions to ask when troubleshooting GRE related issues:
- Can the remote devices ping the WAN / Underlay IP Addresses? Can be found by pinging the Tunnel Destination IP in “sh int tu0” output
- Are the WAN / Underlay Address in the same Subnet? Can be found with “sh int tu0” and “sh ip int brief” on both routers to verify information matches on both sides as they will reference each others Source and Destination IP Addresses
- Is the Tunnel Source / Destination configured in “sh int tu#” correct?
- Is the “Tunnel Mode” correct? In “sh int tu0” under Transport Protocol section it should be the GRE / IP basically at all times, but especially for IPv6 packet transport
- Is an ACL blocking GRE traffic on either Router? “sh ip int (int)” and “sh access-list” to check for ACL’s applied to interface / any ACL’s blocking traffic on port 47 which GRE uses will indicate an ACL issue with Tunnel traffic
- Is fragmentation occurring due to incorrectly configured MTU? The MTU for a GRE Tunnel should be 1476, assuming the Physical Interface MTU that it is bound to is default 1500 MTU, for troubleshooting / identifying MTU fragmentation issues over a GRE tunnel review the extended ping section of this page.
- Is the ‘Recursive Routing Table Lookup’ pointing back to the tunnel? This can be identified with the syslog message “%TUN-5-RECDOWN” and is caused when traffic is attempting to route over the logical Tunnel interface rather than the physical interface out to the internet, this can also occur if dynamic neighbor adjacencies flapping that are formed over the Tunnel (more on this shortly)
- Is the Routing Protocol enabled on the Tunnel interface itself? For Dynamic Routing to occur on the tunnel, it must be enabled on the Tunnel interface.
Understanding Recursive Routing and how to fix it
Recursive Routing will most likely rear its ugly head when a GRE Tunnels destination is being Advertised by a Dynamic Routing Protocol (OSPF / EIGRP), which causes the neighbor adjacency to flap, because the remote side of the Tunnel MUST be reachable via the WAN interface!
So if the Tunnel Destination IP is learned by the Routing Protocol via the Tunnel, it then thinks the Tunnel is the best path to get there due to longest prefix matching, which drops the tunnel because the Tunnel must be formed over the WAN interface.
There are two ways to fix this issue:
- Create a Host Route to the tunnel destination pointing out to the WAN
- Avoid advertising the Tunnel Destination network over the Dynamic Routing Protocol if possible (if trying to monitor the Tunnel Destination IP via Dynamic Routing Protocol use the static route option)
Basically the Tunnel has to connect over the WAN, it cannot try connecting to itself via itself, or it will drop the tunnel until something is done to correct the routing.
Data destined for networks going over the “GRE Tunnel” are really just being routed out the WAN with a GRE header / Outer IP shown once more in this graphic:
Basically you want the Tunnel Destination / Remote IP reachable off the WAN interface.
Verifying correct information on the GRE Tunnel interface
A couple different ways to view the Tunnel information for a tunnel interface:
- “sh tu0” – Shows the tunnel interface / configurations in its current state
- “sh run int tu0” – Shows the manual configs entered to configure the interface
Kind of “sh ip proto” VS “sh run | b router eigrp 100” outputs, one will show you what the current state of things is with the running router process (or tunnel interface), while the other (running config) will show you the manually entered configs.
Contrasting these two sets of information may flush out the config issue for both a GRE Tunnel and for Dynamic Routing Protocols
GRE Tunnel configs to look for on the Tunnel Interface (to confirm they are correct):
- Tunnel “Source” can either be WAN Egress interface or IP Address
- Tunnel “Destination” must be remote IP Address of peer devices WAN interface
- If using IPv6 confirm “ipv6 enable” and “ipv6 (eigrp/ospf) (AS # / Area #” is configured as both IPv6 routing and the IPv6 routing protocols need to be enabled on the Tunnel
As long as IPv6 and the IPv6 routing protocol is enabled on the interface, the IPv6 networks can be added to the router process and it will be shared across the tunnel, though advertising the GRE Tunnel Destination is a bad idea due to Recursive Lookup issues without a Host Address Static Route configured to force it to reach its peer out the WAN interface / Internet connection.
Last but not least, GRE adds no security during Transport, but works with IPSec!
This has already been discussed / labbed in this article so I won’t go deep into it here, however the GRE packets are only encapsulated with a GRE Header, but no type of ESP Header / Trailer to encrypt the contents of the packet.
To visually explain the Authentication (AH) and Encryption (ESP) that IPSec offers:
I won’t go into this in this TSHOOT article as this has been labbed exhaustively in the article link above this graphic, however essentially GRE will encapsulate most any Layer 3 traffic Protocol, then IPSec will encapsulate that GRE packet before Transport to encrypt its contents or at least provide Authentication to its Peer.
With that I will conclude the review of GRE for TSHOOT exam day
This article is definitely not all inclusive for everything you may need to know for exam day and on the job to spot GRE related issues, however it is a very good start, and using the search function on this site or a search engine on the internet can fill in the rest 🙂
The DEVNET GRIND! 