Stuck at GRE troubleshooting with recursive route

Question

As with my last question, I am learning for my CCNA exam and currently I am bashing my head against the wall, while trying to solve "7.2.2.4 Troubleshooting GRE"

I'll explain the topology in a second. First let me document, which steps I have taken so far:

1. RA's Ip addresses on t0 and G0/0 were switched. I corrected them
2. RA's tunnel 0 interface had the wrong source and destination addresses. I set them to s:172.31.0.1 d: 192.168.1.1

Now, on RB theres this message:

 %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
 %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of 0 65E900C0 - looped chain attempting to stack
 %TUN-5-RECURDOWN: 0 temporarily disabled due to recursive routing

Topology:

Every IP address/network address as shown on the image is correct.

This is show interface tunnel 0 on RA:

Tunnel0 is up, line protocol is up (connected)
  Hardware is Tunnel
  Internet address is 192.168.1.1/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 172.31.0.1 (GigabitEthernet0/0), destination 192.168.1.2
  Tunnel protocol/transport GRE/IP

Show interface tunnel 0 on RB:

Tunnel0 is up, line protocol is up (connected)
  Hardware is Tunnel
  Internet address is 192.168.1.1/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 172.31.0.1 (GigabitEthernet0/0), destination 192.168.1.2
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled

Show ip route on RA:

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.31.0.0/24 is directly connected, GigabitEthernet0/0
L       172.31.0.1/32 is directly connected, GigabitEthernet0/0
     192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.1.0/30 is directly connected, Tunnel0
L       192.168.1.1/32 is directly connected, Tunnel0
     209.165.122.0/24 is variably subnetted, 2 subnets, 2 masks
C       209.165.122.0/30 is directly connected, Serial0/0/0
L       209.165.122.2/32 is directly connected, Serial0/0/0
S*   0.0.0.0/0 is directly connected, Serial0/0/0

Show ip route on RB:

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     64.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       64.103.211.0/30 is directly connected, Serial0/0/0
L       64.103.211.2/32 is directly connected, Serial0/0/0
     172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.31.1.0/24 is directly connected, GigabitEthernet0/0
L       172.31.1.1/32 is directly connected, GigabitEthernet0/0
     192.168.1.0/32 is subnetted, 1 subnets
L       192.168.1.2/32 is directly connected, Tunnel0
S*   0.0.0.0/0 is directly connected, Serial0/0/0

Please help me understand this error by explaining what I am missing here and how to resolve this.

Kind regards.

**//EDIT: ** The task which needs to be fullfilled is that traffic from the 172.31.x.x networks on both sides needs to be tunneled.

//EDIT2: As it turns out Iw as talking Bullsh**. Here are the steps taken so far:

1. RA's Ip addresses on t0 and G0/0 were switched. I corrected them

2. RA's tunnel 0 interface had the wrong source and destination addresses. I set them to s:172.31.0.1 d: 192.168.1.1

3. Changed Source address of tunnel 0 on RA to 172.31.0.1

4. Changed Destination address of tunnel 0 on RB to 209.165.122.2
5. copy run start on RB and then reload
6. Tunnel 0 on RB is now up and connected.

//EDIT3:

I finally worked it out. I went back in my curriculum to an earlier task, which did guide me through the whole configuration task.

The source on both routers for the tunnel is the S0/0/0 interface and the destination is the other routers S0/0/0 interface IP address. This is highly counter intuitive, since in my head I was under the impression, the source is the traffic form the local LANs (the 172 interfaces), since the traffic from there needs to be tunneled.

Just for good measure I added 2 static routes for both routers, to make sure the packets get routed this way in case OSPF / EIGRP or RIP think otherwise.

I have upvoted both answers, but accepted Ron's, since he answered first with a correct set up.

Answer 1

Serv,

Your tunnel source and destination addresses are wrong. They should be 209.165.122.2 and 64.103.211.2 on RA and the opposite on RB.

There are many different ways to explain this, but essentially, the route to the tunnel endpoint cannot be through the tunnel. In your case, in order to send a packet (from RA) to 192.168.1.2, RA has to encapsulate it in a GRE packet and then send it to the tunnel destination. But the route to the tunnel destination is through the tunnel itself. that is not allowed because you would be infinitely encapsulating the packet.

Another explanation (metaphor):

Think of a bridge being built across a river. the bridge engineers need to know where on each side of the river to put the bridge. Once they have built the bridge, you can route people to use the bridge to get to the other side. But that is separate from where the bridge has to be built.

The bridge (tunnel) is built from RA's s0/0/0 interface to RB s0/0/0. Once the tunnel is up, you can then route traffic from 172.31.x.x through the tunnel. In other words, building the tunnel is separate from routing traffic through the tunnel.

Answer 2

You can't have a destination to a GRE tunnel that hasn't been established yet.

RA:

Tunnel0 is up, line protocol is up (connected)
  Hardware is Tunnel
  Internet address is 192.168.1.1/30
  ! Can't have the same IP on the GRE tunnel on both ends
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 209.165.122.2 (Serial0/0/0), destination 64.103.211.2
  ! Assuming S0/0/0 is 209.165.122.2

RB:

Tunnel0 is up, line protocol is up (connected)
  Hardware is Tunnel
  Internet address is 192.168.1.2/30
  ! Can't have the same IP on the GRE tunnel on both ends
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 64.103.211.2 (Serial0/0/0), destination 209.165.122.2 
  ! Assuming S0/0/0 is 64.103.211.2

Edit

Let me break down how this works a little better. Your goal is to tunnel the 172.31.x.x networks through a tunnel you’ve established between RA and RB.

RA has no knowledge of 172.31.1.0/24 ; hence, you don’t see it in the RIB. RB has no knowledge of 172.31.0.0/24; which you can also see in his RIB.

If RA attempts to contact anything in 172.31.1.0/24, the packet will be sent to its default router (which we’ll assume is S0/0/0). Once the cloud gets that address, he will drop it since he doesn’t have any knowledge of any networks except 209.165.122.0/30 and 64.103.211.1/30.

A GRE tunnel needs a valid destination to build a tunnel and this tunnel will traverse the WAN. Your RA tunnel will be from Source 209.165.122.2 to destination 64.103.211.2 with a virtual IP of 192.168.1.1. Your RB will have source 64.103.211.2 and destination 209.165.122.2 with a virtual IP of 192.168.1.2.

You can then set a default route in RA that effective says 172.31.1.0/24 via 192.168.1.2.
You can then set a default route in RB that effective says 172.31.0.0/24 via 192.168.1.1.

These default routes will force their respective traffic through the GRE tunnel to reach their end-points.

Answer 3

The basic answer to this issue lies in the %TUN-5-RECURDOWN: 0 temporarily disabled due to recursive routing error message. When the Routing Process needs to decide where to route a specific packet, it essentially needs to find out what interface to send the packet out of. In case of a GRE tunnel, Recursive Routing occurs when a more advantageous route (lower metric) to the tunnel endpoints gets learned through the tunnel it self. When that happens we will end up with a Recursive Loop where the traffic is identified to be routed via the Tunnel which is identified to be routed via the Ethernet (or Serial) interface which again is identified to be routed via the Tunnel; Resulting in an infinitive loop:

Ingress Interface -> Tun. Interface -> Eth. Interface -> Tun. Interface -> etc.

If dynamic routing needs to be enabled on the tunnel this situation can be resolved in one of many ways (more options may exist):

1. Add static routes to the tunnel endpoints with a net mask of /32 to ensure that these always will be the preferred routes.
2. Apply a distribution-list outbound on the tunnel interface (configured under the routing protocol configuration) to filter the tunnel endpoint addresses from getting advertised.
3. Change the metric of the routes learned through the tunnel by changing the properties of the tunnel interface (delay / bandwidth), resulting in these routes being less attractive than the same routes learned over the Ethernet (or Serial) interface.
4. Use FVRF to create a logical routing table segregation (see more about solving Recursive Route by FVRF here: http://www.packetu.com/2013/10/15/using-gre-tunnel-vrf-separate-physical-interface/