GRE Tunneling and Recursive Routing

Task  

● Create a GRE tunnel between R3 and R4 using the IPv4 addresses 172.16.0.Y/24, where Y is the router number. 

● The tunnel should be sourced from and destined to these devices’ Loopback0 IPv4 addresses. 

● Configure Loopback1 on R3 and R4 with IPv4 addresses 10.1.YY. YY/32, where Y is the router number. 

● Configure RIP version 2 on R1, R3. and R4 as follows: 

Enable it on VLAN 13 and VLAN 146. 

Enable it on the GRE tunnel. 

● Advertise Loopback0 and Loopback1 prefixes of R3 and R4. 

● Use traceroute on R3 and R4 to verify connectivity between Loopback1 networks of R3 and R4 through the GRE tunnel. 

● Configure distribute-list filtering on R3 and R4 to fix the recursive routing error for the GRE tunnel. 

Explanation  

Verify the RIP routing table on R3 and R4 before enabling RIP on Tunnel34, and note that there is IPv4 connectivity between Loopback0 and Loopback1 prefixes.

R4 

show ip route rip | b Gateway 📋

R3

show ip route rip | b Gateway 📋

ping 10.1.4.4 source loopback0 📋

ping 10.1.44.44 source loopback1 📋

When RIP is enabled on the GRE tunnel of R3 and R4, a recursive routing error will happen on either R3 or R4, based on the order of configuration. A recursive routing error is when a lookup for prefix X points at prefix Y for the next-hop, and a lookup for prefix Y points at prefix X for the next-hop.

For tunnel interfaces, this occurs when the tunnel destination is dynamically learned through the tunnel interface itself. This problem can be easily identified by the IOS log message %TUN-5-RECURDOWN: Tunnel34 temporarily disabled due to recursive routing. The step-by-step process by which this error occurs is as follows.

First, the GRE tunnel interface is enabled and goes into UP state as the router has a route for tunnel destination learned through RIP; IOS logs the message %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel34, changed state to up to signal this.

At this moment, let's enable RIP over the tunnel interface, which will determine both routers, R3 and R4, to prefer routes learned over the GRE tunnel against routes learned over the physical Ethernet path, because of the lower metric/hop-count of 1 on the GRE tunnel versus the metric/hop-count of 2 on the physical Ethernet path: 

R4

show ip route rip | b Gateway  📋

Because at this moment R4 learns about the GRE tunnel destination through the GRE tunnel itself, a route-recursive error is triggered, and the Tunnel interface goes to DOWN state.

This will allow the router to re-learn the RIP routes over the physical path, but this process will repeat itself when R4 will bring UP again the GRE tunnel interface: 

R4

show ip route rip | b Gateway 📋

In general, there are several solutions to the problem, depending on the IPv4 addressing scheme, routing protocol being used, and network design: 

● Do not advertise in the routing protocol the same networks over both the physical/Ethernet path and the tunneling/GRE path. 

● Do not advertise in the routing protocol used over the tunneling/GRE path the tunnel endpoints. 

● Use route filtering techniques to filter tunnel endpoints IPv4 addresses from being learned over the GRE tunnel. 

● Do not use same routing protocol over both the physical and tunneling paths; this is recommended but it requires correct routing protocol configuration. 

● In this case, one of multiple route filtering solutions has been selected, basically configuring R3 and R4 to not advertise Loopback0 prefix over the GRE tunnel. After applying the filtering, the network is stable and routes are correctly learned over both physical and tunneling paths.

Note that route filtering was configured strictly to fix the recursive routing problem; some Ethernet link subnets will be learned over the GRE tunnel, which is functional but maybe not optimal. 

R3

show ip route rip | b Gateway 📋

R4

show ip route rip | b Gateway 📋

Verify there is IPv4 connectivity between Loopback0 and Loopback1 prefixes of R3 and R4, and that traffic for Loopback1 is routed over the GRE tunnel.

R4 

ping 10.1.3.3 source loopback0 📋

ping 10.1.33.33 source loopback1 📋

traceroute 10.1.33.33 📋

traceroute 10.1.44.44  📋

Configuration  

R1: 

router rip 
version 2 
no auto-summary 
network 172.16.0.0
📋

R3: 

interface Tunnel34
ip address 172.16.0.3 255.255.255.0
tunnel mode gre ip
tunnel source 10.1.3.3
tunnel destination 10.1.4.4
no shutdown
!
interface Loopback1
ip address 10.1.33.33 255.255.255.255
!
ip prefix-list STOP_RECURSIVE_ERROR seq 5 deny 10.1.3.3/32
ip prefix-list STOP_RECURSIVE_ERROR seq 10 permit 0.0.0.0/0 le 32
!
router rip
version 2
no auto-summary
network 172.16.0.0
network 172.16.0.0
network 172.16.0.0
distribute-list prefix STOP_RECURSIVE_ERROR out Tunnel34
📋

R4: 

interface Tunnel34
ip address 172.16.0.4 255.255.255.0
tunnel mode gre ip
tunnel source 10.1.4.4
tunnel destination 10.1.3.3
no shutdown
!
interface Loopback1
ip address 10.1.44.44 255.255.255.255
!
ip prefix-list STOP_RECURSIVE_ERROR seq 5 deny 10.1.4.4/32
ip prefix-list STOP_RECURSIVE_ERROR seq 10 permit 0.0.0.0/0 le 32
!
router rip
version 2
no auto-summary
network 172.16.0.0
network 172.16.0.0
network 172.16.0.0
distribute-list prefix STOP_RECURSIVE_ERROR out Tunnel34
📋