Now I’ve spent hours and hours trying to figure GRE out, this was not included in my CCNP ROUTE material except for some DMVPN using mGRE, however I did want to know for practical purposes how to encapsulate broadcast / multicast traffic over an IPSec tunnel which in turn needs a GRE tunnel as there is none.
Now GRE is not a LAN-to-LAN (L2L) tunnel as I had expected it to be, so I spent hours trying to figure out why it showed as Up / Up and debugs showed packet encapsulation and decapsulation, but my traceroutes would NOT take the tunnel interface!
After mentioned hours of researching, I found that GRE is actually a router to router tunnel, and IPSec is a L2L tunnel type. I was wondering this because, when I did a traceroute from SW1 to R3 with a default route pointed at R2 (To route it around the NBMA), it was replying back with router addresses and not the tunnels address.
So first let me get to the configuration, its so easy, I cannot believe how hard it was to configure properly:
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int tu0
*Mar 31 20:44:11.041: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add 10.1.1.3 255.255.255.0
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel dest 172.12.123.2
R3(config-if)#
*Mar 31 20:45:39.374: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#
R3(config)#router ospf 1
R3(config-router)#network 10.1.1.0 0.0.0.255 area 0
ASR#2
[Resuming connection 2 to r2 … ]
R2(config)#
R2(config)#router ospf 1
R2(config-router)#network 10.1.1.0 0.0.0.255 area 0
R2(config-router)#int tu0
*Mar 30 23:52:58.962: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add 10.1.1.2 255.255.255.0
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel dest 172.12.123.3
R2(config-if)#
*Mar 30 23:53:36.644: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#do sh ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 172.12.23.2 YES manual up up
Serial0/0 172.12.123.2 YES manual up up
FastEthernet0/1 unassigned YES unset administratively down down
Serial0/1 unassigned YES unset administratively down down
Loopback2 2.2.2.2 YES manual up up
Tunnel0 10.1.1.2 YES manual up up
What I was really, reaaaally struggling with is the “recursive lookup” which essentially is a route lookup loop on the local router, which is an issue when running dynamic routing protocols, because your router will take the best path it knows how to get there and that dynamic protocol might provide it – This is why looking at GRE you see a lot of talk about default and static routing.
For example, consider this IP route table and traceroute:
R2#traceroute 172.12.34.3
Type escape sequence to abort.
Tracing the route to 172.12.34.3
1 172.12.123.1 32 msec 32 msec 32 msec
2 172.12.123.3 92 msec * 72 msec
If we look at the route table, there is already actually two entries that would route traffic to its destination:
R2#sh ip route
Gateway of last resort is 172.12.123.1 to network 0.0.0.0
1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:40:50, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback2
3.0.0.0/32 is subnetted, 1 subnets
O IA 3.3.3.3 [110/65] via 172.12.123.3, 00:40:50, Serial0/0
172.12.0.0/24 is subnetted, 4 subnets
O IA 172.12.34.0 [110/65] via 172.12.123.3, 00:32:09, Serial0/0
O IA 172.12.15.0 [110/65] via 172.12.123.1, 00:40:50, Serial0/0
C 172.12.23.0 is directly connected, FastEthernet0/0
C 172.12.123.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Tunnel0
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:32:14, Serial0/0
Because instead of just making a static route I used “default-information originate always” on R1, so it is a Type 5 LSA (External), which of course has the same AD as any OSPF route, so both routes essentially said take OSPF and not the tunnel.
So I added a static route to get thing moving along:
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip route 172.12.34.0 255.255.255.0 tu0
R2(config)#exit
R2#traceroute 172.12.34.3
Type escape sequence to abort.
Tracing the route to 172.12.34.3
1 10.1.1.3 104 msec * 92 msec
R2#
ASR#3
[Resuming connection 3 to r3 … ]
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip route 2.2.2.2 255.255.255.255 tu0
R3(config)#exit
R3#traceroute
*Mar 31 21:29:59.414: %SYS-5-CONFIG_I: Configured from console by console
R3#traceroute 2.2.2.2
Type escape sequence to abort.
Tracing the route to 2.2.2.2
1 10.1.1.2 100 msec * 100 msec
R3#
So essentially it just needed a static route so the AD would be lower than 110 from the OSPF learned routes.
How IPSec you actually create an ACL to define interesting traffic, with GRE you simply have to tell the router to route traffic to the remote destination over your tunnel interface, and make sure you have connectivity between your source ad dest IP’s.
Now that I have a thorough understanding of this, and have spent hours / days researching this topic and different approaches to GRE despite it being the oldest pile of dirt VPN there is, this is how it is not only configured but how routes are created to take the tunnel to the destination network when dynamic routing is running.
This has really cost me some DEEP Diving time so up next will be IPSec configuration, and then integrating GRE with it to encapsulate GRE traffic, but for now it is nap time to let my brain cool off!
- Note that Cisco recommends you use a logical loopback interface as your source address, in case of a link failure, however I’ve spent so much time on this already I am just using the outside interfaces.
The DEVNET GRIND! 