5

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:

GRE 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.

7
  • 2
    protip: Cisco 2600 and 2800 series routers are extremely cheap on eBay. Packet Tracer is nice for simple stuff, but it certainly has weaknesses as complexity increases. IMHO, GNS3 (another way to simulate Cisco devices) is not fast enough Jan 23, 2014 at 13:02
  • The solution in Edit2 doesn't make any sense. RA has no knowledge of network 172.31.1.0/24.
    – Ryan Foley
    Jan 23, 2014 at 13:13
  • @serv If your edit2 works, then your network is not as you describe in your diagram. RA has no route to 173.31.1.0. The default wouldn't work because the internet router doesn't know how to get to 172.31.1.0 (unless you have configured static routes)
    – Ron Trunk
    Jan 23, 2014 at 13:14
  • I am recreating the solution as of now. Might take some minutes since Packet tracer creashed and nothing was saved
    – Marco
    Jan 23, 2014 at 13:14
  • @serv Step 3 is wrong. change it to 209.165.122.2
    – Ron Trunk
    Jan 23, 2014 at 13:26

3 Answers 3

5

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.

5
  • This does not make sense to me. t0 source on RA is 172.31.0.1 - its attached LAN on g0/0. What is the fault there?
    – Marco
    Jan 23, 2014 at 12:05
  • Ron, the 172.31.x.x subnets are inbound on his network.
    – Ryan Foley
    Jan 23, 2014 at 12:06
  • That's what I get for answering before coffee. I fixed the post.
    – Ron Trunk
    Jan 23, 2014 at 12:29
  • You were right all along. But I do not understand why - yet.
    – Marco
    Jan 23, 2014 at 16:04
  • @Serv join me in the chat room and we can go over it.
    – Ron Trunk
    Jan 23, 2014 at 16:15
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.

11
  • Take note of the source and destination on both ends.
    – Ryan Foley
    Jan 23, 2014 at 12:07
  • Thanks for the hint with the IP address, but this did not fix the issue. Furthermore: The task is to tunnel the 172.x.x.x traffic. not the traffic coming from the serial interfaces
    – Marco
    Jan 23, 2014 at 12:12
  • @Serv Give it a try with the source interfaces pointing to Ge0/0 (updated). Your destinations were really just wrong.
    – Ryan Foley
    Jan 23, 2014 at 12:18
  • I'll need a few minutes until I can check back. Basically, the desitnation address MUST NOT be a tunnel endpoint?
    – Marco
    Jan 23, 2014 at 12:23
  • 1
    I have changed the sources appropriatly after you first answered. However the destinations are still wrong. The ought to be 172.31.x.x as written at the bottom of my question, where described the solution which worked
    – Marco
    Jan 23, 2014 at 13:02
0

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/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.