cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
826
Views
0
Helpful
3
Replies

Route Tracking - Tracked Route Doesn't Re-Install After Failover

venom43212
Level 4
Level 4

I have setup the below for a primary tracked default route, and then a floating static default route using the same interface (pointed to two different upstream routers). When the primary goes down, the floating static route is inserted. Problem is, when the primary comes backup, the tracked route is never re-installed. Manually removing the routes and re-adding them resolved. I've tried using two different interfaces, and don't seem to have the issue. Is this a known behavior for the ASA, and any workaround using the same interface if so? Version is 9.6(4)3. Thanks.

 

sla monitor 1
type echo protocol ipIcmpEcho 1.1.1.1 interface inside
num-packets 5
timeout 29000
frequency 30

!

sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1 reachability
!
route inside 0.0.0.0 0.0.0.0 10.10.10.2 1 track 1
route inside 0.0.0.0 0.0.0.0 10.10.10.3 254

!

 

1 Accepted Solution

Accepted Solutions

Thanks for the reply. I didn't include internal routes because it's not germane to this, but that points to 10.10.10.1, which is an HSRP address that is active on the MPLS router. 10.10.10.2 is the interface address of the DIA router and 10.10.10.3 is the interface address of the MPLS router, 10.10.10.1 shared between them. Internet destined traffic should go DIA first, and if that drops, which is being tracked via 1.1.1.1 (FYI - none of these IPs are actual) - the firewall has reach-ability to it via both IPs and when the ICMP probes are successful again, the tracked route re-inserts, as stated by testing using two different interfaces. 

 

I went over this with someone from the ASA team at CLUS last week, and they said it was a software defect and to open a TAC case, which is in process.

View solution in original post

3 Replies 3

Florin Barhala
Level 6
Level 6
I think this is a flaw by design: you're polling 1.1.1.1 through inside interface source IP.
Unless really 1.1.1.1 is reachable only through 10.10.10.2 gateway I can only wonder how can it failover in the first place?

A better redundancy idea in my view would be to bind both 10.10.10.2 and 10.10.10.3 with VRRP or HSRP and provide a virtual IP.

Thanks for the reply. I didn't include internal routes because it's not germane to this, but that points to 10.10.10.1, which is an HSRP address that is active on the MPLS router. 10.10.10.2 is the interface address of the DIA router and 10.10.10.3 is the interface address of the MPLS router, 10.10.10.1 shared between them. Internet destined traffic should go DIA first, and if that drops, which is being tracked via 1.1.1.1 (FYI - none of these IPs are actual) - the firewall has reach-ability to it via both IPs and when the ICMP probes are successful again, the tracked route re-inserts, as stated by testing using two different interfaces. 

 

I went over this with someone from the ASA team at CLUS last week, and they said it was a software defect and to open a TAC case, which is in process.

Good news then - keep us posted if it works after all. I still have my doubts about the design.
Review Cisco Networking products for a $25 gift card