my LAN hosts do not use GRE

[mohamedayach]

Hello all!
 

I set up a GRE tunnel. 

1. traceroute between tunnel interfaces : OK
2. traceroute between LANs interfaces : NOT OK

Here is my setup : (in the attached picture)

R1

Tunnel0 is up, line protocol is up (connected)

Hardware is Tunnel

Internet address is 10.0.0.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 192.168.1.1 (Serial0/0/0), destination 192.168.3.2

Tunnel protocol/transport GRE/IP

Key disabled, sequencing disabled

Checksumming of packets disabled

Tunnel TTL 255

Fast tunneling enabled

Tunnel transport MTU 1476 bytes

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

R4

Tunnel0 is up, line protocol is up (connected)

Hardware is Tunnel

Internet address is 10.0.0.2/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 192.168.3.2 (Serial0/0/0), destination 192.168.1.1

Tunnel protocol/transport GRE/IP

Key disabled, sequencing disabled

Checksumming of packets disabled

Tunnel TTL 255

Fast tunneling enabled

Tunnel transport MTU 1476 bytes

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

[michael o'nan]

What are you using for routing? Static routes or a dynamic protocol? Make sure you are pointing the traffic to the neighbor tunnel interface. If you would like to attach some more config I'm sure that would help.

[mohamedayach]

Thank you sir for your reply, for your convenience I attached a rar file in a zip format containing  the .pkt file.

Here is the routing table of the two routers:

R1

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets

C 1.1.1.1 is directly connected, Loopback0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C 10.0.0.0/30 is directly connected, Tunnel0

C 10.10.10.0/24 is directly connected, FastEthernet0/0

R 172.16.0.0/16 [120/3] via 192.168.1.2, 00:00:04, Serial0/0/0

192.168.1.0/30 is subnetted, 1 subnets

C 192.168.1.0 is directly connected, Serial0/0/0

R 192.168.2.0/24 [120/1] via 192.168.1.2, 00:00:06, Serial0/0/0

R 192.168.3.0/24 [120/2] via 192.168.1.2, 00:00:06, Serial0/0/0

R4

Gateway of last resort is not set

R 1.0.0.0/8 [120/3] via 192.168.3.1, 00:00:02, Serial0/0/0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

R 10.0.0.0/8 [120/3] via 192.168.3.1, 00:00:02, Serial0/0/0

C 10.0.0.0/30 is directly connected, Tunnel0

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.1.0 is directly connected, FastEthernet0/0

R 192.168.1.0/24 [120/2] via 192.168.3.1, 00:00:02, Serial0/0/0

R 192.168.2.0/24 [120/1] via 192.168.3.1, 00:00:02, Serial0/0/0

192.168.3.0/30 is subnetted, 1 subnets

C 192.168.3.0 is directly connected, Serial0/0/0

[Richard Burts]

From the limited information in this thread it seems that the GRE tunnels are appropriately configured. Am I understanding correctly that traceroute from 10.0.0.1 to 10.0.0.2 is successful but that traceroute from 192.168.1.1 to 192.168.3.2 fails? I find that puzzling. If the GRE tunnel is working and traceroute from one end to the other end is successful then there must be IP connectivity between the source and the destination.

The routing tables show the remote tunnel peer address as being learned via the serial interface which is the way that it should be. It makes me wonder if there is something on R2 that is preventing the traceroute beetween physical interfaces.

HTH

Rick

[mohamedayach]

Hello ,

Thank you sir for the reply, the issue is when I traceroute frome 10.0.0.1 to 10.0.0.2 the result is :

R1#traceroute

Protocol [ip]:

Target IP address: 10.0.0.2

Source address: 10.0.0.1

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Type escape sequence to abort.

Tracing the route to 10.0.0.2

1 10.0.0.2 25 msec 5 msec 5 msec 

One hop which is logic !

Now when I try to traceroute from the lan connected to R1 to the LAN connected to R4:

R1#traceroute

Protocol [ip]:

Target IP address: 172.16.1.100

Source address: 10.10.10.1

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Type escape sequence to abort.

Tracing the route to 172.16.1.100

1 192.168.1.2 22 msec 1 msec 1 msec

2 192.168.2.2 3 msec 0 msec 1 msec

3 192.168.3.2 1 msec 1 msec 6 msec

4 172.16.1.100 15 msec 11 msec 14 msec

you see all the hops are there it is like if the GRE was never there???

do you have any idea ?

[Richard Burts · Accepted solution]

Indeed I do have an idea. The first thing to note is that on R1 the routing table indicates that the way to get to 172.16.1.100 is to go via the serial interface. The second thing to note is that there are no routes learned which use the tunnel (except for the connected subnet of 10.0.0.0/30). So the issue is that while you have correctly configured the GRE tunnel there is no routing logic that makes use of the GRE tunnel.

The solution is to provide some routing logic which does use the tunnel. Probably the easiest solution is to configure static routes on R1 and R4 for the LAN subnet of the remote router with the tunnel interface address as the next hop. For example on R1

ip route 172.16.0.0 255.255.0.0 10.0.0.2

A slightly more complicated solution would be to run a dynamic routing protocol over the tunnel and to advertise the LAN subnets in that protocol. For example you could run OSPF or EIGRP on R1 and R4 and include the LAN subnet in that routing protocol. This would send LAN to LAN traffic over the tunnel instead of over the serial interface.

Be careful that one thing that you do not want to do is to advertise the tunnel end point in the routing protocol running over the tunnel. For example on R1 you do not want to learn a route for 192.168.1.0 on the routing protocol running over the tunnel.

HTH

Rick

[mohamedayach]

thank you sir, and since you didn't mention RIP I guess RIP is not an option is it ?

[Richard Burts]

From the output that you posted it appears that you are running RIP over the serial interfaces. In that case running RIP over the tunnel as well as the serial interfaces would create problems.

I am glad that my response was helpful. Thank you for using the rating system to mark this question as answered.

HTH

Rick

[Richard Burts]

I want to be sure that my point was clear. There is not anything about RIP as a protocol that prevents running it over the GRE tunnel. You could very successfully run RIP over the tunnel - if you were not already running RIP on the serial interfaces. The important thing is that the routing protocol running over the tunnel be different from the routing protocol running over the source and destination interfaces. In fact you could use static routes to send traffic over the tunnel, or could use static routes for the tunnel destination address and not require two different dynamic routing protocols.

HTH

Rick

[mohamedayach]

Thank you sir!

am studying for the CCNA exam using the official cert guide...I think it lacks a lot of things I feel like they are just scratching the surface, it makes it hard to grasp the full picture.

[Richard Burts]

You are welcome. These forums are a wonderful place to learn about networking and supplement the various cert guides very well.

In a sense you are quite right that the CCNA cert guides are scratching the surface. But we have to start somewhere and while we are in the early stages of learning it is frequently difficult to grasp the full picture (especially when the picture is so big and has so much depth). The CCNA is designed as a first step in learning about networking. When you complete the CCNA there will still be lots to learn, but you should have acquired a working understanding of the fundamentals of how networks work.

Good luck as you continue your studies. I hope to see more activity from you in the forums.

HTH

Rick