Recursive Routing with Tunnels - study case: GRE over IPsec

This post represents the solution and explanation for quiz-6.
Have a look at the quiz to understand the problem.

This quiz was made more difficult with the addition of IPsec configuration, which was intended to make it more close to real life scenarios - remember: real networks run a lot of features blended together !

Quiz Review

Before explaining the problem, let's briefly discuss this scenario, as per below diagram:

• the scenario uses a point-to-point GRE tunnel over IPsec
• GRE (Generic Route Encapsulation) is a protocol that "carries" other passanger protocols - for example, IP multicast, which allows us to run routing protocols
• with GRE over IPsec, all traffic between GRE endpoints is encrypted by IPsec
• this scenarios uses the method of crypto-maps - only one line in the crypto ACL is enough: the GRE protocol (IP Prot 47) between the endpoints
• crypto-maps is the "old" method as opposed to newer method using VTIs (Virtual Tunnel Interface) - VTIs are more flexible with the folloing benefits: simpler configuration, support multicast, capable of running IP routing protocols, etc

Going back to the quiz, the problem within this scenario is a typical recursive routing !
Depending on your level of logging, you may be able to see the following entries in the logs:

HQ-Router#
*Mar  1 00:01:39.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
*Mar  1 00:01:39.587: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.16.255.2 (Tunnel1) is up: new adjacency
HQ-Router#
HQ-Router#
*Mar  1 00:01:48.031: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Mar  1 00:01:49.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Mar  1 00:01:49.063: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.16.255.2 (Tunnel1) is down: interface down

Before the tunnel is established:

Remote-Router#sh ip cef 155.1.1.1
0.0.0.0/0, version 7, epoch 0, cached adjacency to Serial0/0
0 packets, 0 bytes
  via 155.2.2.1, 0 dependencies, recursive
    next hop 155.2.2.1, Serial0/0 via 155.2.2.0/30
    valid cached adjacency

Tunnel is UP and tunnel destination is learned by routing protocols running over the tunnel

Remote-Router#sh ip cef 155.1.1.1
155.1.1.0/30, version 29, epoch 0
0 packets, 0 bytes
  via 172.16.255.1, Tunnel1, 0 dependencies
    next hop 172.16.255.1, Tunnel1
    valid adjacency

In order to solve recursive routing problems, we need to ensure that tunnel destination is never learned via the tunnel itself - let's see some solutions:

1. Do not advertise the tunnel destination into the routing protocol

From design perspective, especially when deploying the tunnels over a private WAN, it's desired to split the addressing so that WAN addresses (used as tunnel destinations) will not leak into the routing protocol.
In our quiz, we don't have a private WAN and the tunnel destinations are public IP addresses, but the error exists in the command network 0.0.0.0 that is configured under the EIGRP routing process => the first solution would be to configure more specific network commands that do not contain the tunnel destination, like below:

on the HQ Router

HQ-Router#sh run | s router eigrp
router eigrp 100
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 no passive-interface FastEthernet1/0
 no passive-interface Tunnel1
 network 172.16.0.0
 no auto-summary

on the Remote Offce

Remote-Router#sh run | s router eigrp
router eigrp 100
 passive-interface default
 no passive-interface Tunnel1
 network 172.16.0.0
 no auto-summary

2. Filter tunnel destinations from being sent/learned via the routing protocol

When you have same addressing/subnets for tunnels as internal network (private WAN), the solution would be to filter tunnel destinations from being advertised (sent) or learned (received) over the IP routing protocol.
In the example below, we configure a distribute list that denies tunnel destinations from being learned via the EIGRP over the tunnel:

on the HQ Router

HQ-Router#sh run | i access-list
access-list 10 deny   155.2.2.0
access-list 10 permit any
!
HQ-Router#sh run | s router eigrp
router eigrp 100
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 no passive-interface FastEthernet1/0
 no passive-interface Tunnel1
 network 0.0.0.0
 distribute-list 10 in
 no auto-summary#

on the Remote Office

Remote-Router#sh run | i access-list
access-list 10 deny   155.1.1.0
access-list 10 permit any
Remote-Router#
Remote-Router#sh run | s router eigrp
router eigrp 100
 passive-interface default
 no passive-interface Tunnel1
 network 0.0.0.0
 distribute-list 10 in
 no auto-summary
Remote-Router#

3. Use static routes for tunnel destinations

Another solution is to configure static host routes for the tunnel destinations (/32 routes would be the most specific & static has the best administrative distance):

on the HQ Router

HQ-Router#sh run | i ip route
ip route 0.0.0.0 0.0.0.0 155.1.1.2
ip route 155.2.2.2 255.255.255.255 155.1.1.2

on the Remote Route

Remote-Router#sh run | i ip route
ip route 0.0.0.0 0.0.0.0 155.2.2.1
ip route 155.1.1.1 255.255.255.255 155.2.2.1

Thanks everyone for your comments in the quiz !