01-12-2019 07:54 AM - edited 03-05-2019 11:10 AM
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,
Solved! Go to Solution.
01-12-2019 08:50 AM
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
01-12-2019 08:29 AM
Hello,
post your Packet Tracer project file (zip the .pkt first otherwise you cannot upload)...
01-12-2019 08:50 AM
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
01-12-2019 09:57 AM
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,
01-12-2019 10:06 AM
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
01-12-2019 10:18 AM
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,
01-12-2019 01:44 PM
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
01-12-2019 02:37 PM
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
01-12-2019 04:19 PM
01-12-2019 05:22 PM
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
01-12-2019 09:50 AM
Hi Sir,
I have attached the file,
Thank you for your support,
01-12-2019 09:59 AM
Hi
it could be caused a bug in packet tracer, have you tested in gns3?
01-12-2019 12:00 PM
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...
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: