01-12-2008 09:01 PM - edited 03-03-2019 08:14 PM
Hi,
I have set up two routers with GRE tunnel 1 with OSPF running. R1 has 10.1.1.0/24 network and R2 has 172.24.1.0/24 network. when I look at the routing table from R1 I can see 172.24.1.0 learned from OSPF on tunnel 1.
172.24.0.0/24 is subnetted, 2 subnets
O 172.24.1.0 [110/11121] via 2.2.2.1, 00:00:06, Tunnel1
So far so good!!
As soon as I create another tunnel 0 between the two routers and use the netwok command for tunnel 0, I get the following message
Router#
Jun 1 11:51:11.823: %OSPF-5-ADJCHG: Process 1, Nbr 203.117.1.1 on Tunnel1 from
FULL to DOWN, Neighbor Down: Dead timer expireds
and the OSPF neighbout goes away for tunnel 1. Is there any reason for this?
here is the configuration for R1, R2 is similar.
!
interface Tunnel0
ip address 1.1.1.2 255.255.255.0
tunnel source Serial0
tunnel destination 192.168.1.1
!
interface Tunnel1
ip address 2.2.2.2 255.255.255.252
tunnel source Serial0
tunnel destination 192.168.1.1
!
interface FastEthernet0
description LAN_ABC
ip address 10.1.1.1 255.255.255.0
speed 10
fair-queue
!
router ospf 1
log-adjacency-changes
redistribute static subnets
network 2.2.2.2 0.0.0.0 area 0
network 10.1.1.1 0.0.0.0 area 0
network 203.117.1.0 0.0.0.255 area 0
default-information originate
I was expecting to see two equal path route in the routing table ...... any explaination.
thaks,
Arana
Solved! Go to Solution.
01-13-2008 06:55 AM
Dear Arana,
Sure you can play around with the OSPF cost.
R5(config-if)#ip ospf cost
Please rate the case as solved if your problem has been solved with the above solution.
Best Regards,
Mounir Mohamed
01-13-2008 12:45 AM
It's seems that you have some recursive or route feeding issue, so please could you send your router configurations (At least Serial / Tunnel / Static routes / show ip route / OSPF Configurations), if you can not I believe âdebug ip routingâ will shown you the problem.
Pls rate helpful posts
Best Regards,
Mounir Mohamed
01-13-2008 02:48 AM
Thanks Mohamed,
As soon as I configure the second tunnel on Router1 the OSPD neighbour between the two routers goes down. here is the configuration:
Router1
!
interface Loopback0
ip address 203.117.1.2 255.255.255.255
!
interface Tunnel0
ip address 1.1.1.2 255.255.255.252
tunnel source Serial0
tunnel destination 192.168.1.1
!
interface Tunnel1
ip address 2.2.2.2 255.255.255.252
tunnel source Serial0
tunnel destination 192.168.1.1
!
interface FastEthernet0
description LAN_ABC
ip address 10.1.1.1 255.255.255.0
speed 10
fair-queue
!
interface Serial0
ip address 192.168.1.2 255.255.255.252
no fair-queue
!
router ospf 1
log-adjacency-changes
redistribute static subnets
network 1.1.1.2 0.0.0.0 area 0
network 2.2.2.2 0.0.0.0 area 0
network 10.1.1.1 0.0.0.0 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.2
ip route 172.24.3.0 255.255.255.0 10.1.1.2
no ip http server
Router2
interface Loopback0
ip address 203.117.1.1 255.255.255.255
!
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
tunnel source Serial0/0
tunnel destination 192.168.1.2
!
interface Tunnel1
ip address 2.2.2.1 255.255.255.252
tunnel source Serial0/0
tunnel destination 192.168.1.2
!
interface Ethernet0/0
ip address 172.24.1.1 255.255.255.0
half-duplex
!
interface Serial0/0
ip address 192.168.1.1 255.255.255.252
no fair-queue
clock rate 1000000
interface Ethernet0/1
no ip address
shutdown
half-duplex
!
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 2.2.2.1 0.0.0.0 area 0
network 172.24.1.1 0.0.0.0 area 0
network 203.117.1.1 0.0.0.0 area 0
!
ip classless
ip route 172.24.2.0 255.255.255.0 172.24.1.2
ip http server
!
thanks,
Arana
01-13-2008 02:24 AM
Hi,
Totally agree with Mounir here, this might be related to the fact that the tunnel destination must not recurse to the tunnel interface itself (Tunnel destination must not be reachable via the tunnel IP itself - must not be advertised or received over routing protocol over the tunnel interface itself) - best practice is to filter the tunnel destination IP from any routes received on the tunnel. This is most commonly if you run tunnel over the same routing protocol's domain which is enabled on tunnel itself > Always filter the tunnel IPs from the advertisement over the tunnel itself.
Please check if you get this in your log "%TUN-5-RECUDOWN: Tunnel0 temporarily disabled due to recursive routing".
BR,
Mohammed Mahmoud.
01-13-2008 03:08 AM
Hi, the two routers are dorectly connected to each other. could this be the reason?
here is the routing table:
ateway of last resort is 10.1.1.2 to network 0.0.0.0
1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Tunnel0
2.0.0.0/30 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Tunnel1
203.117.1.0/32 is subnetted, 1 subnets
C 203.117.1.2 is directly connected, Loopback0
172.24.0.0/24 is subnetted, 1 subnets
S 172.24.3.0 [1/0] via 10.1.1.2
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, FastEthernet0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Serial0
S* 0.0.0.0/0 [1/0] via 10.1.1.2
Router2#
here is the OSPF debug:
Jun 1 17:55:01.830: OSPF: Rcv hello from 203.117.1.1 area 0 from Tunnel0 1.1.1.
1
Jun 1 17:55:01.830: OSPF: End of hello processing
Jun 1 17:55:04.034: OSPF: Rcv pkt from 2.2.2.1, Tunnel0, area 0.0.0.0 : src not
on the same network
Jun 1 17:55:04.874: OSPF: 203.117.1.1 address 2.2.2.1 on Tunnel1 is dead
Jun 1 17:55:04.874: %OSPF-5-ADJCHG: Process 1, Nbr 203.117.1.1 on Tunnel1 from
FULL to DOWN, Neighbor Down: Dead timer expired
Jun 1 17:55:04.878: OSPF: Rcv pkt from 2.2.2.1, Tunnel0, area 0.0.0.0 : src not
on the same network
Jun 1 17:55:04.926: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 1.1.1.
2
Jun 1 17:55:05.250: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0 from
10.1.1.1
here is the log
outer2#sho log
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes,
0 overruns, xml disabled)
Console logging: level debugging, 460 messages logged, xml disabled
Monitor logging: level debugging, 0 messages logged, xml disabled
Buffer logging: disabled, xml disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level informational, 106 message lines logged
tunnel
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 1.1.1.2/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 192.168.1.2 (Serial0), destination 192.168.1.1
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
108 packets input, 12300 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
51 packets output, 5300 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
both the tunnels are up. yet the ospf is
Neighbor ID Pri State Dead Time Address Interface
203.117.1.1 0 INIT/ - 00:00:33 1.1.1.1 Tunnel0
Let me know if there are anything I can send to solve this.
thanks,
Arana
01-13-2008 04:35 AM
Hi Arana,
Mounir and my self have discussed this issue (we are work mates by the way :) ), below is our opinion.
We think that the issue here is that both tunnels are using the same source and destination over the same interfaces, thus the 2 routers won't be able to differentiate to which tunnel the exchanged GRE packets belong to and thus the GRE packets processing is unpredictable.
If you configure keepalive on the tunnels we believe that it will go up/down.
The only work around that we can see here is to make sure that both tunnels are not using the same source and destination (make sure to avoid the recurse issue described earlier, for example if you used 2 different loopbacks for the source and destination, then use static routes to point the loopback IP to the respective serial interface, in order not to face a recurse problem over the tunnel).
Finally we believe that you are just playing around with GRE and OSPF and that this is not for a production solution, as this will have no significance for a running in production network.
Mounir will reply on you later with the tested configuration for more convenience.
BR,
Mohammed Mahmoud.
01-13-2008 04:37 AM
First of all due to NetPro #words limitation i will post the cause of the problem and the solution on 2 different posts.
As Mohamed said above After we lab it up we found that, this issue happen because both tunnels running over the same interface and using the same source and destination IP address/interface which is confused the IOS about which tunnel Owen the GRE encapsulated packet, also if the keep alive were enabled on the GRE tunnels, there is one tunnel will be placed in UP/down statue which is ensure the testing result.
Finally this issue can be solved if you use different tunnel source and destination for each tunnel interface and the best practice in this case to use separated loopback interfaces as a source and destination for each tunnel in order to let the IOS differentiate between GRE encapsulated packets.
Example of how the case happens in details:
##R5####
interface Tunnel0
ip address 1.1.1.5 255.255.255.252
keepalive 2 3
tunnel source GigabitEthernet0/1
tunnel destination 192.168.1.6
###R6####
interface Tunnel0
ip address 1.1.1.6 255.255.255.252
keepalive 2 3
tunnel source GigabitEthernet0/1
tunnel destination 192.168.1.5
R5#ping 1.1.1.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
R5#show ip ospf int brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo100 1 0 10.10.10.1/24 1 P2P 0/0
Tu0 1 0 1.1.1.5/30 11111 P2P 0/0
R6#show ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O 10.10.10.0 [110/11112] via 1.1.1.5, 00:00:00, Tunnel0
##NOW the problem will appears below after creat the second tunnel with the same src-dst IP/INT##
R5(config)#interface Tunnel1
R5(config-if)# ip address 2.2.2.5 255.255.255.252
R5(config-if)#tunnel source g0/1
R5(config-if)#tunnel destination 192.168.1.6
*Jan 13 12:05:14.331: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
*Jan 13 12:05:21.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
*Jan 13 12:05:21.947: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.6 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or deta
##As you see above once tunnel1 created, tunnel0 went down and the OSPF neighbor went down also##
###To make sure, once the second tunnel removed tunnel0 will come up as soon as the OSPF neighbor##
R5(config-if)#no int tun 1
R5(config)#
*Jan 13 12:08:49.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
*Jan 13 12:08:49.955: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.6 on Tunnel0 from LOADING to FULL, Loading Done
01-13-2008 04:38 AM
So now let's solve the problem by changing the source and destination for the second tunnel interface (Tunnel1)
(Loopback 1 will be used from both sides as source and destination for tunnel 1, but please make sure that the loopback IP address is reachable from both sides, and the best practice for this to use /32 static route)
((R5))
R5#show run int lo 1!
interface Loopback1
ip address 50.50.50.50 255.255.255.255
R5#show run int tun 1
interface Tunnel1
ip address 2.2.2.5 255.255.255.252
keepalive 2 3
tunnel source Loopback1
tunnel destination 60.60.60.60
R5#show run | inc ip route 60.60
ip route 60.60.60.60 255.255.255.255 192.168.1.6
((R6))
R6#show run int lo 1
interface Loopback1
ip address 60.60.60.60 255.255.255.255
R6#show run int tun 1
interface Tunnel1
ip address 2.2.2.6 255.255.255.252
keepalive 2 3
tunnel source Loopback1
tunnel destination 50.50.50.50
R6#show run | inc ip route 50.50
ip route 50.50.50.50 255.255.255.255 192.168.1.5
##OSPF For both R5/R6##
router ospf 1
log-adjacency-changes
network 1.1.1.x 0.0.0.0 area 0
network 2.2.2.x 0.0.0.0 area 0
network 10.10.10.x 0.0.0.0 area 0
R5#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
192.168.1.6 0 FULL/ - 00:00:32 2.2.2.6 Tunnel1
192.168.1.6 0 FULL/ - 00:00:32 1.1.1.6 Tunnel0
As you see above, both tunnels is up and the OSPF adjecancy established over the tunnels.
Pls rate helpful posts
Best Regards,
Mounir Mohamed
01-13-2008 05:45 AM
Working with you?
01-13-2008 06:27 AM
Hi Mounir and Mohamed,
That's great!! thanks for going extra miles to get this sorted out. I am a newbe in GRE and I just wanted to play around with some ideas. I wanted to play around with the ospf cost on two GRE tunnels.
I got the two tunnels running.
Neighbor ID Pri State Dead Time Address Interface
203.117.1.2 1 FULL/ - 00:00:37 2.2.2.2 Tunnel1
203.117.1.2 1 FULL/ - 00:00:39 1.1.1.2 Tunnel0
thanks for the help.
Thanks,
Arana
01-13-2008 06:55 AM
Dear Arana,
Sure you can play around with the OSPF cost.
R5(config-if)#ip ospf cost
Please rate the case as solved if your problem has been solved with the above solution.
Best Regards,
Mounir Mohamed
01-13-2008 07:17 AM
Hi Mounir,
Yes. I got this working as well. On R2 I changed the cost (lower metric) on tunnel 1 interface so that traffic from R2 was using tunnel 1. That is what I wanted. One last question, is this the correct way playing with the metric if I wanted traffic to go from tunnel 1 from R2? or are there other ways to do it as well. Like from R1?
thanks,
Arana
01-13-2008 07:55 AM
Sorry i can not get ur point.
01-13-2008 11:12 AM
If you mean this is the same way to force the router to select one path over another path, the answer in your case is Yes.
01-13-2008 03:12 PM
Hi Mounir,
Yes that is what I meant. i was not sure if this was the correct way of doing it, or it there were better way of doing it.
thanks,
Arana
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: