12-08-2014 11:45 AM - edited 03-05-2019 12:18 AM
Hello all!
I set up a GRE tunnel.
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)
Solved! Go to Solution.
12-08-2014 05:32 PM
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
12-08-2014 01:07 PM
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.
12-08-2014 03:21 PM
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
12-08-2014 04:36 PM
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
12-08-2014 04:42 PM
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 ?
12-08-2014 05:32 PM
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
12-08-2014 05:52 PM
thank you sir, and since you didn't mention RIP I guess RIP is not an option is it ?
12-08-2014 05:57 PM
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
12-09-2014 05:00 AM
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
12-09-2014 06:57 AM
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.
12-09-2014 07:29 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide