Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

GRE with ospf question

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

1 ACCEPTED SOLUTION

Accepted Solutions

Re: GRE with ospf question

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

14 REPLIES

Re: GRE with ospf question

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

Community Member

Re: GRE with ospf question

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

Re: GRE with ospf question

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.

Community Member

Re: GRE with ospf question

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

Re: GRE with ospf question

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.

Re: GRE with ospf question

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

Re: GRE with ospf question

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

Re: GRE with ospf question

Working with you?

Community Member

Re: GRE with ospf question

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

Re: GRE with ospf question

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

Community Member

Re: GRE with ospf question

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

Re: GRE with ospf question

Sorry i can not get ur point.

Re: GRE with ospf question

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.

Community Member

Re: GRE with ospf question

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

1505
Views
28
Helpful
14
Replies
CreatePlease to create content