cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4283
Views
15
Helpful
9
Replies

OSPF problems by tunnel GRE

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

9 Replies 9

Richard Burts
Hall of Fame Guru Hall of Fame Guru
Hall of Fame Guru

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

HTH

Rick

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

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

HTH

Rick

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.

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

HTH

Rick

So,

 

ip route 10.10.0.2 255.255.255.252 192.168.0.1

 

Correct?

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

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

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.

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
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:

Recognize Your Peers