cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3513
Views
15
Helpful
12
Replies

GRE tunnel and OSPF issue

Hi team,

 

Im having a hard time to make this topology work, 

the requirement is the following: 

 

1- use ospf for the entire topology

2- make static routes for the GRE tunnel for LAN31 and LAN41 only

3- LAN31 and LAN41 should NOT be appearing in the R1 and R2 routing table

4- GRE tunnel should be active for LAN31 and LAN41 regardless  of which of the two interfaces are active in R3 and R4, for instance, if I shutdown serial 0/0/0 on R3, the tunnel should be active

 

Can someone help me with the packet tracer file, 

 

I have tried using static routes and each of the tunnel is up but cant reach each other, not sure if Im doing something wrong, 

any feedback since most of the topologies I have seen just involved 3 routers, but in this case, based on the requirement, I have 4 routers

 

I have attached the files of R3 and R4 and the topology

 

I will highly appreciate it your assistance, 

 

Regards, 

 

1 Accepted Solution

Accepted Solutions

The posted config files are a good start. But they have issues that must be solved.

1) The config of tunnel 0 specifies an ip address for the tunnel (172.16.0.1 for R3) which is fine. But it specifies the destination as the tunnel remote address (172.16.0.2 specified as destination for tunnel on R3. The tunnel destination address can not be the same as the tunnel remote end address. You need to specify a different destination.

2) The config of tunnel 0 specifies that the tunnel source is serial0/0/0. But part of the requirement was that if that serial interface is shut down that the tunnel should still work. But in this config if the serial interface is down then then tunnel does not work.

 

As a solution I suggest this. For the tunnel source use the local loopback. For the tunnel destination use the remote loopback. Add network statements under OSPF 1 for the loopback address. If you make those changes then the tunnel should work and should work regardless of whether a serial interface is up or is down.

 

You have a network statement for the tunnel address 172.16.0.0. You should remove this. Otherwise you have the risk of recursive routing.

 

HTH

 

Rick

HTH

Rick

View solution in original post

12 Replies 12

Hello,

 

post your Packet Tracer project file (zip the .pkt first otherwise you cannot upload)...

The posted config files are a good start. But they have issues that must be solved.

1) The config of tunnel 0 specifies an ip address for the tunnel (172.16.0.1 for R3) which is fine. But it specifies the destination as the tunnel remote address (172.16.0.2 specified as destination for tunnel on R3. The tunnel destination address can not be the same as the tunnel remote end address. You need to specify a different destination.

2) The config of tunnel 0 specifies that the tunnel source is serial0/0/0. But part of the requirement was that if that serial interface is shut down that the tunnel should still work. But in this config if the serial interface is down then then tunnel does not work.

 

As a solution I suggest this. For the tunnel source use the local loopback. For the tunnel destination use the remote loopback. Add network statements under OSPF 1 for the loopback address. If you make those changes then the tunnel should work and should work regardless of whether a serial interface is up or is down.

 

You have a network statement for the tunnel address 172.16.0.0. You should remove this. Otherwise you have the risk of recursive routing.

 

HTH

 

Rick

HTH

Rick

I see, intersting, let me give it a shot, using loopbacks, I did not see the fact that serial0/0/0 if I shutdown, like no failover will occur, but the requirement confused when it said, use only static routes for GRE LAN :/

 

super thanks for your feedback, 

The requirement was pretty clear that the tunnel should continue to work if one of the serial interfaces was shut down. Using a serial interface as the tunnel source clearly does not meet that requirement. You need the tunnel source to be some interface that is advertised via OSPF and the loopback interface was an obvious choice.

 

Your original statement of requirements 2 and 3 both deal with the advertisement of the lan for R3 and R4. Part of the requirement was that these lan subnets not be in the routing table of R1 and R2. So that means that these subnets should not be advertised in OSPF. So a static route on R3 and R4 directing the lab subnets go through the tunnel is an obvious choice.

 

HTH

 

Rick

HTH

Rick

Understood Sir,

 

You are absolutely right, let me use the loopbacks instead and give it a shot, if it does not work because PT limitations, I will give it a try like Julio states, 

 

 

thanks for your feedback, Im still trying to set it up for the packet tracer, Im just giving my last shot before trying on GNS3 or any other platform,

 

I did what was recommended, the tunnel comes up via the loopbacks, I made the static routes and each LAN is known, but as soon as I shut down the serial 0/0/0 on R3, I get this output like it does not know how to reach it, despite the fact that the loopback is reachable via OSPF when trying to ping the LAN of R3 from R4:

 

R4#ping 10.0.4.129

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.4.129, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

 

==========================================

 

this is the config of R3 so far: 

 

interface Loopback0

ip address 4.4.4.4 255.255.255.255

ip ospf 1 area 0

!

interface Tunnel0

ip address 172.16.0.4 255.255.255.0

mtu 1476

tunnel source Loopback0

tunnel destination 3.3.3.3

!

!

interface GigabitEthernet0/0

ip address 10.0.4.1 255.255.255.128

duplex auto

speed auto

!

interface GigabitEthernet0/1

no ip address

duplex auto

speed auto

shutdown

!

interface Serial0/0/0

ip address 200.0.0.13 255.255.255.252

clock rate 2000000

!

interface Serial0/0/1

ip address 200.0.0.6 255.255.255.252

!

interface Vlan1

no ip address

shutdown

!

router ospf 1

log-adjacency-changes

network 200.0.0.12 0.0.0.3 area 0

network 200.0.0.4 0.0.0.3 area 0

!

ip classless

ip route 10.0.4.128 255.255.255.224 3.3.3.3

!

================================BELOW CONFIG OF R3==================================

 

interface Loopback0

ip address 3.3.3.3 255.255.255.255

ip ospf 1 area 0

!

interface Tunnel0

ip address 172.16.0.3 255.255.255.0

mtu 1476

tunnel source Loopback0

tunnel destination 4.4.4.4

!

!

interface GigabitEthernet0/0

ip address 10.0.4.129 255.255.255.224

duplex auto

speed auto

!

interface GigabitEthernet0/1

no ip address

duplex auto

speed auto

shutdown

!

interface Serial0/0/0

ip address 200.0.0.14 255.255.255.252

clock rate 2000000

shutdown

!

interface Serial0/0/1

ip address 200.0.0.10 255.255.255.252

clock rate 2000000

!

interface Vlan1

no ip address

shutdown

!

router ospf 1

log-adjacency-changes

network 200.0.0.8 0.0.0.3 area 0

network 200.0.0.12 0.0.0.3 area 0

!

ip classless

ip route 10.0.4.0 255.255.255.128 4.4.4.4

 

 

============PERSPECTIVE FROM R3 WHEN SERIAL 0/0/0 IS ACTIVE=============

 

R3#show ip route 10.0.4.0

Routing entry for 10.0.4.0/25

Known via "static", distance 1, metric 0

Routing Descriptor Blocks:

* 4.4.4.4

Route metric is 0, traffic share count is 1

 

R3#show ip route 4.4.4.4

Routing entry for 4.4.4.4/32

Known via "ospf 1", distance 110, metric 65, type intra area

Last update from 200.0.0.13 on Serial0/0/0, 00:00:20 ago

Routing Descriptor Blocks:

* 200.0.0.13, from 4.4.4.4, 00:00:20 ago, via Serial0/0/0

Route metric is 65, traffic share count is 1

 

R3#

 

R3#show ip int brief

Interface IP-Address OK? Method Status Protocol

GigabitEthernet0/0 10.0.4.129 YES manual up up

GigabitEthernet0/1 unassigned YES unset administratively down down

Serial0/0/0 200.0.0.14 YES manual up up

Serial0/0/1 200.0.0.10 YES manual up up

Loopback0 3.3.3.3 YES manual up up

Tunnel0 172.16.0.3 YES manual up up

 

===================PERSPECTIVE WHEN SERIAL IS SHUTDOWN FROM R3==========================

 

R3#show ip route 4.4.4.4

Routing entry for 4.4.4.4/32

Known via "ospf 1", distance 110, metric 193, type intra area

Last update from 200.0.0.9 on Serial0/0/1, 00:00:06 ago

Routing Descriptor Blocks:

* 200.0.0.9, from 4.4.4.4, 00:00:06 ago, via Serial0/0/1

Route metric is 193, traffic share count is 1

 

R3#show ip route 10.0.4.0

Routing entry for 10.0.4.0/25

Known via "static", distance 1, metric 0

Routing Descriptor Blocks:

* 4.4.4.4

Route metric is 0, traffic share count is 1

 

R3#

 

but still I cannot reach the other ends LAN

 

R3#ping 10.0.4.1

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds:

U.U

 

any ideas on what I might be missing as far as the config is related to?

 

thanks so much

 

 

Thank you for making (most of) the changes that I suggested. I am a bit puzzled why you changed the IP addresses on the tunnel - but do not think it makes a significant difference. The major issue with the changes that you made is about the static routes. On R3 this is the route that you have configured 

ip route 10.0.4.0 255.255.255.128 4.4.4.4

you have specified that the next hop is the remote loopback - which is advertised by OSPF (we hope) and is not reachable via the tunnel. Change the static route so that the next hop becomes the address of the remote end of the tunnel (172.16.0.4 in your current config). 

The same issue is on R4 so you need to correct its static route also.

 

I am a bit puzzled about the changes you made for OSPF and the loopback interfaces. In the new config you have specified under the loopback interfaces the OSPF parameters while the serial interfaces are represented by network statements under router ospf 1. Perhaps both approaches work on the version of router that you are running in PT. But I am concerned. Can you post the output of show ip ospf interface from both routers? If both serials and the loopback interface show up in the output then we are good. Otherwise please add a network statement under OSPF 1 for the loopback interfaces.

 

HTH

 

Rick

HTH

Rick

Thank you so much Richard, Im truly glad with had the time to assist me, I gave a shot on PT after making the changes and it did not work, 
 
However, I remade it on Eve NG, and this time, it worked very well, I did the test and both subnets can reach each other after using the proper static routes, using the tunnel 
 
For sure, PT still it not on stable and has soo many limitations, but anyhow, 
 
I want to thank you for all your support and the other feedback I got,
output1.JPG
 
 
 
 
 
 
 
 
 
 
 
R3#ping 10.0.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R3#ping 172.16.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.4, timeout is 2 seconds:
!!!!!
 
I tested shutting down one of the uplinks of R3 and the packets always arrive achieving its objective, 
 
R3(config)#int e0/0
R3(config-if)#shut
R3(config-if)#end
*Jan 13 00:02:49.219: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
R3(config-if)#end
R3#traceroute 10.0.4.1
*Jan 13 00:02:51.195: %SYS-5-CONFIG_I: Configured from console by console
*Jan 13 00:02:51.214: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
*Jan 13 00:02:52.219: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
R3#ping 10.0.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds:
!!!!!
output1.JPG
 
 
 
 
 
 
 
 
 
output1.JPG
 
 
 
 

Thanks for the update letting us know that the problem is solved and that you have a working solution. And thank you for marking this question as solved. This will help other participants in the community to identify discussions that have helpful information. It has been an interesting discussion. And I believe that it has several points that would be helpful to other participants. My perspective focused on the need to get the architectural design right and to get the configuration consistent with the design. Several of my colleagues focused on potential issues with the emulator. And it turns out that both perspectives were right ! Without a correct config nothing can work right. And with a correct config there still may be issues with the emulator. So as we approach troubleshooting we need to remember both perspectives.

 

HTH

 

Rick

HTH

Rick

Hi Sir, 

 

I have attached the file, 

 

Thank you for your support, 

Hi

it could be caused a bug in packet tracer, have you tested in gns3?




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

I would agree with Julio, I just configured this in GNS3, with static routes to the tunnel endpoints through the directly connnected interfaces, and it works like a charm. Packet Tracer is a very nice tool, but I think it is more designed to perform preset tasks that only work if you use the exact right commands.

I often cannot get RIP to work at all in Packet Tracer, for no apparent reason.

So, Julio has a good point, try GNS3...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: