OSPF problem when routing through IPSEC tunnels

[CristiaV]

Hello,

I have the following situation

2 ISP, one with public ip yyy.yyy.yyy.yyy as main, the other one is secondary, with ip xxx.xxx.xxx.xxx.

2 IPSEC tunnels with the public ip of my datacenter, zzz.zzz.zzz.zzz

I want all trafic from this branch to pass through my datacenter, so my primary default route should be through the primary tunnel with the datacenter. I also want to use OSPF for routing.

Here is the config for the tunnels:

-  interface Tunnel23
ip address 10.29.129.5 255.255.255.252
desc "secondary tunnel"
ip ospf network point-to-point
ip ospf cost 3000
ip ospf mtu-ignore
tunnel source xxx.xxx.xxx.xxx
tunnel destination zzz.zzz.zzz.zzz
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN-Profile

interface Tunnel24
desc "Primary tunnel"
ip address 10.29.129.13 255.255.255.252
ip ospf network point-to-point
ip ospf mtu-ignore
tunnel source yyy.yyy.yyy.yyy
tunnel destination zzz.zzz.zzz.zzz
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN-Profile

This is the config for OSPF:

router ospf 1
router-id 2.2.2.2
log-adjacency-changes
passive-interface FastEthernet0.2
passive-interface FastEthernet0.3
network 10.29.129.5 0.0.0.0 area 0
network 10.29.129.13 0.0.0.0 area 0
network 172.29.2.1 0.0.0.0 area 0
network 172.29.3.1 0.0.0.0 area 0

And these are the static routes:

ip route 0.0.0.0 0.0.0.0 <default gw of primary ISP> 112 track 1
ip route 8.8.4.4 255.255.255.255 <default gw of primary ISP> 10 track 1
ip route zzz.zzz.zzz.zzz 255.255.255.255 <default gw of primary ISP> 10 track 1
ip route 0.0.0.0 0.0.0.0 Tunnel24 110
ip route 0.0.0.0 0.0.0.0 Tunnel23 111
ip route 0.0.0.0 0.0.0.0 <default gw of secondary ISP> 113
ip route zzz.zzz.zzz.zzz 255.255.255.255 <default gw of secondary ISP> 20

As long the primary IPS is up, everything is ok:

Router(config)#do sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
172.29.0.1 0 FULL/ - 00:00:38 10.29.129.14 Tunnel24
172.29.0.1 0 FULL/ - 00:00:37 10.29.129.6 Tunnel23

When the primary ISP fails, the tunnel through the primary ISP fails (it`s logic), but the secondary tunnel fails also, due to recursive routing.

.Feb 25 15:01:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel23, changed state to up
.Feb 25 15:01:53: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel23 85AE87A0 - looped chain attempting to stack
.Feb 25 15:01:56: %TUN-5-RECURDOWN: Tunnel23 temporarily disabled due to recursive routing
.Feb 25 15:01:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel23, changed state to down

Things I have also checked:

- The tracking for the primary ISP works fine

- after the primary ISP fails, the default route is through the primary ISP, the one with AD 113

Where is the problem and why is this recursive routing? Would setting the default routes through the tunnels via a next hop and not via an exit interface resolve the issue ? ... 

Thanks 

[Seb Rupik]

Hi there,

your conclusion is correct. To resolve the recursive routing issue you need to create a static route for the tunnel24 remote endpoint via the ISP2 next-hop IP.

!
ip route zzz.zzz.zzz.zzz 255.255.255.255 <default gw of secondary ISP> 113
!

cheers,

Seb.

[CristiaV]

Seb, this route is already created , but with AD=20, the primary route has 10 as AD 

[Seb Rupik]

Ah sorry.

Does <default gw of secondary ISP> actually reside on a connected subnet? I suspect the router performing a recursive lookup using the now active default route via tunnel24?

cheers,

Seb.

[CristiaV]

Yes, it`s in a connected subnet 

[Richard Burts]

I had an experience that I believe was similar to yours. We were running ipsec tunnels and running a dynamic routing protocol over the tunnel. We had static routes configured for the tunnel destination and learned default route from the dynamic protocol over the tunnel. We kept getting reports of recursive routing which was very puzzling. We opened a case with Cisco TAC. What we learned is that it was an issue of timing. There would be some event that took down the physical interface. When the interface changed state then IOS immediately removed the static route to the tunnel destination. But it took convergence a little time to remove the default route learned from the dynamic protocol. So for a brief time the router had a route to get to the tunnel destination that was through the tunnel and that is the definition of recursive routing. As soon as convergence removed the default route then the recursive routing stopped. 

HTH

Rick