I initially stuck my TSHOOT GRE Deep Dive into the CCIE DMVPN bucket, but there is no such thing as too much practice or repetition, so get ready for some more here 🙂
Back to the basics of GRE and why this ancient protocol has any relevance
It routes almost ANY kind of traffic which is a must in todays networks, and though it does not itself secure the payload, it can have IPSec configured on top of it for that.
For exmple MultiCast traffic does not traverse IPSec, however it can be encapsulated via GRE, then encrypted via IPSec and sent on its way.
Another intersting scenario – Lets say on a Cisco Exam you have two OSPF networks that are not in the same Area 0 Domain, and one task is to connect them without using a Virtual-Link which is of course the VL’s main purpose is to connect these kind of sites.
What then? GRE Then! Its not optimal, but its so flexible, it can patch up just about any connectivity issue in a pinch (but of course without security added by default!)
Configuring two customer routers, and a Service Provider router between
***One thing to be up front about, is that between the two customer sites, these NEED to have static routes to their remote tunnel endpoints, or you will end up with recursive routing that in production will really ruin your day if manage the network!***
So a quick set of all 3 devices IP Addressing (and static routes between the two sites)
Site1
Site1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Site1(config)#int fa0/0
Site1(config-if)#ip add 172.16.12.1 255.255.255.252
Site1(config-if)#no shut
Site1(config-if)#
*Dec 4 10:51:51.279: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Dec 4 10:51:52.279: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Site1(config-if)#exit
Site1(config)#ip route 172.16.21.0 255.255.255.252 172.16.12.2
Site1(config)#
Loopbacks will be setup later for testing.
ISP
ISP#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ISP(config)#int fa0/0
ISP(config-if)#ip address 172.16.12.2 255.255.255.0
ISP(config-if)#no shut
ISP(config-if)#int fa1/0
ISP(config-if)#
*Dec 4 10:56:38.847: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state t o up
*Dec 4 10:56:39.847: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to up
ISP(config-if)#ip add 172.16.21.2 255.255.255.252
ISP(config-if)#no shut
*Dec 4 10:56:52.491: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state t o up
*Dec 4 10:56:53.491: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et1/0, changed state to up
ISP#
The odd thing is they should all be in OSPF Area 0, its a very simple network, why at 330am do all the weird glitchy issues pop up!?
Site2
Site2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Site2(config)#int fa1/0
Site2(config-if)#ip add 172.16.21.1 255.255.255.252
Site2(config-if)#no shut
*Dec 4 11:03:18.211: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Dec 4 11:03:19.211: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
Site2(config)#ip route 172.16.12.0 255.255.255.252 172.16.12.2
Site2(config)#
From here we have base configurations of IP Addressing, with Static Routes which are needed for GRE Tunnel Reach-ability, and now to run a ping test between Site1 and Site2:
Site1#ping 172.16.21.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.21.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/54/76 ms
Site1#
This has literally taken me 2+ hours to work around EVE-NG’s glitches the get this working, so this ping being successful just about made me fall out of my seat 🙂
NOW DOWN TO GRE TUNNEL BUSINESS!
Yes, my GRE tunnel is part pickle in this diagram, the IP Address #’s will match the site #.
Site1
Site1(config-if)#int tu0
Site1(config-if)#
*Dec 4 12:21:02.019: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
Site1(config-if)#tunnel source fa0/0
Site1(config-if)#tunnel destination 172.16.21.1
Site1(config-if)#
*Dec 4 12:21:26.579: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Site1(config-if)#ip add 10.0.0.1 255.255.255.0
Site1(config-if)#
Site2
Site2(config)#int lo2
*Dec 4 12:18:40.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback2, changed state to up
Site2(config-if)#ip add 2.2.2.2 255.255.255.255
Site2(config-if)#int tu0
Site2(config-if)#tunnel source
*Dec 4 12:23:00.171: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
Site2(config-if)#tunnel source fa1/0
Site2(config-if)#tunnel dest 172.16.12.1
*Dec 4 12:23:13.043: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Site2(config-if)#ip add 10.0.0.2 255.255.255.0
Site2(config-if)#
Site2(config-if)#
Site2(config-if)#
Site2(config-if)#
Verification
Site2(config-if)#do sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
FastEthernet1/0 172.16.21.1 YES manual up up
FastEthernet2/0 unassigned YES unset administratively down down
Loopback2 2.2.2.2 YES manual up up
Tunnel0 10.0.0.2 YES manual up up
Site2(config-if)#
Adding a routing protocol on top of GRE to share routes (Loopbacks)
A very important point about what you are about to see configured:
When adding networks to an IGP on top of a GRE Tunnel, we should have static routes for tunnel reachability, so we will only add additional networks (Like loopbacks in this lab) as well as the Tunnel Network itself to propagate them!
Why the Tunnel Network itself? Several reasons!
- The Tunnel can then propagate routes between sites
- The Tunnel has an IGP Hold Timer to that will bring the Tunnel Interface down if the Static Route becomes unavailable, as the IGP will too then become toast!
- We do NOT want the Tunnel learning of its destinations through an IGP, say if a default route is pointed to the ISP, or we already have an IGP running and think “Why not just add the Tunnel Interface to it? What could it hurt?”
I go over recursive routing (and MANY GRE TSHOOT topics in my post I will add under CCIE Topics), I highly suggest reading it if you are at all unfamiliar with GRE issues!
Anyways.
Site2 first this time
Site2(config-if)#router eigrp 100
Site2(config-router)#no auto
Site2(config-router)#network 10.0.0.0
Site2(config-router)#network 2.0.0.0
Site2(config-router)#
Site1
Site1(config)#router eigrp 100
Site1(config-router)#network 10.0.0.0
*Dec 4 12:28:52.731: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.2 (Tunnel0) is up: new adjacency
Site1(config-router)#network 1.0.0.0
Now for some testing and verification:
Site1(config)#do sh ip route
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route, H – NHRP, l – LISP
+ – replicated route, % – next hop override
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/27008000] via 10.0.0.2, 00:06:10, Tunnel0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/24 is directly connected, Tunnel0
L 10.0.0.1/32 is directly connected, Tunnel0
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.12.0/30 is directly connected, FastEthernet0/0
L 172.16.12.1/32 is directly connected, FastEthernet0/0
S 172.16.21.0/30 [1/0] via 172.16.12.2
Site1(config)#
Note that 2.2.2.2/32 is learned via EIGRP, however the Tunnel Interfaces / IP’s are both “L” and “C” rather than learned via IGP, because of the static route which is how it should be!
One last ping test to verify connectivity and I am out!
Site1(config)#do ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/54/60 ms
Site1(config)#
That is is for this demo, this lab took forever navigating EVE-NG glitches!
I almost gave up several times with just off the wall glitches that I would troubleshoot for 30-60+ minutes thinking there is no way I am blaming this on EVE, and sure enough.
Anyways we got it working, and that is the what we set out to do, I will attack the TSHOOT GRE Deep Dive and the CCIE – DMVPN Header as it is filled with tons of good information that I believe belongs both under TSHOOT and CCIE DMVPN.
Anyways, until next time! 🙂
The DEVNET GRIND! 