02-26-2019 02:38 AM - edited 02-26-2019 03:57 AM
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
02-26-2019 03:54 AM
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.
02-26-2019 04:01 AM
Seb, this route is already created , but with AD=20, the primary route has 10 as AD
02-26-2019 04:30 AM
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.
02-26-2019 04:45 AM
Yes, it`s in a connected subnet
02-26-2019 12:22 PM
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
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: