OSPF problems by tunnel GRE

[krystianstrycharz]

I would like to configure redistribution of routing protocols but first i need to do an OSPF routing between R0 and R2 via tunnel GRE.

Routers connect a neigbourhood but only for a while. Tunnel GRE is ok. Where is a problem? 

Alerts are shown first on R0:

17:03:14: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.0.10 on Tunnel0 from LOADING to FULL, Loading Done

%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of 0 65E900C0 - looped chain attempting to stack

%TUN-5-RECURDOWN: 0 temporarily disabled due to recursive routing

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down

17:03:19: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.0.10 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached

After on R2:

17:17:53: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Dead timer expired

17:17:53: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached

Routing on R0:

router eigrp 1

redistribute static

network 10.0.0.0 0.0.0.3

network 10.0.0.4 0.0.0.3

!

router ospf 1

network 10.10.0.0 0.0.0.3 area 0

!

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/2

Routing on R2:

router ospf 1

network 172.16.0.8 0.0.0.3 area 0

network 172.16.0.16 0.0.0.3 area 0

network 10.10.0.0 0.0.0.3 area 0

default-information originate

!

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0

[Richard Burts]

The key to identifying this issue is the message

%TUN-5-RECURDOWN: 0 temporarily disabled due to recursive routing

Recursive routing is a fairly common problem when using GRE tunnels. It is caused when the router believes that the next hop to get to the tunnel end point is reached through the tunnel itself. The most common cause of the problem is running a dynamic routing protocol over the tunnel and including the subnet of the tunnel source in a network statement for the routing protocol. You have not showed us the config of the tunnel so we can not tell what is the source address for the tunnel. Can you post the configuration of the interfaces (physical and tunnel) and of the routing protocols?

HTH

Rick

[krystianstrycharz]

R0:

interface Tunnel0

ip address 10.10.0.1 255.255.255.252

mtu 1476

tunnel source GigabitEthernet0/2

tunnel destination 192.168.0.6

!

interface GigabitEthernet0/2

description Connection with ISP

ip address 192.168.0.2 255.255.255.252

!

router ospf 1

network 10.10.0.0 0.0.0.3 area 0

!

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/2

R2:

interface Tunnel0

ip address 10.10.0.2 255.255.255.252

tunnel source GigabitEthernet0/0

tunnel destination 192.168.0.2

!

interface GigabitEthernet0/0

description Connection with ISP

ip address 192.168.0.6 255.255.255.252

!

router ospf 1

network 172.16.0.8 0.0.0.3 area 0

network 172.16.0.16 0.0.0.3 area 0

network 10.10.0.0 0.0.0.3 area 0

default-information originate

!

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0

[Richard Burts]

Thank you for posting the additional information. I wonder if the issue might be the default-information originate in the config of R2. Would you remove that and tell us if the behavior changes.

HTH

Rick

[krystianstrycharz]

Yes, remove of default-information originate resolves the problem and OSPF works stably.

So now local routers behind R2 need to know route to INTERNET by write gateway of last resort on both routers .

Thank you master once again! I feel it was not last time :) 

I will try to do a redistribution and encrypt traffic by IPSec. I hope with no problems.

[Richard Burts]

I am glad that my suggestion did lead you to the solution of the problem. I would also like to comment on your static routes. Using a static route which just identifies the outbound interface when that interface is Ethernet is not a good way to do it

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0

There are several aspects of this that are factors. 1) this forces the router to arp for every destination to which it tries to forward a packet. 2) this uses more cpu cycles to do the arp. 3) this then increases the size of the arp cache. 4) this then increases the cpu cycles to maintain the arp cache. 5) it works only if the neighbor router has enabled proxy arp. Increasingly there are service providers who do not enable proxy arp because of the security concerns associated with proxy arp.

So it would be better if your static routes specified the next hop IP address (or specify both the next hop address and the outbound interface).

Good luck with implementing redistribution and encrypting traffic with IPsec. They may raise some issues and if they do then you can open another discussion on the forum.

HTH

Rick

[mlenco]

So,

ip route 10.10.0.2 255.255.255.252 192.168.0.1

Correct?

[jain.manish94]

Please can you let me know that after removing default-information originate in the config of R2 it is working why ?

[Bekzod Fakhriddinov]

default-information originate  imports that  route via source int  to ospf and tunnel will think again next hop is via tunnel-recursive route . 

[paul driver]

Hello

The tunnel destination is being learned over the gre tunnel via ospf causing the recursive routing.

So you need to remove either the default originate advertised in ospf and define via static routes what networks will be reach via the gre tunnel OR  remove the static default route from the router and static route the tunnel destination via the gig0/0 physical interface nexhop address.