SLA Monitoring in Policy Based Routing on Cisco ASA 5516-x

[Gerorymo]

Hello Community members!

I would really use some help regarding the situation I'm in now. I want to ask apologies in advance, this is my first post. 

I have two ISP connected to my Cisco ASA 5516-x to Gi0/3  and Gi0/1(details in the photo below or in the attachment). I have a task to route DMZ subnet to ISP2 (Beeline_Router) and other traffic via ISP1 (Tojnet Gateway), but also this should be a failover scenario, for instance if ISP2 link is down I need to reroute DMZ to ISP1. For this I have created access list which applied to PBR and applied this PBR to my DMZ interface. I have two static routes - ISP1 as primary, ISP2 with higher metric. I've created two SLA monitor which are pinging 8.8.8.8 host (as internet simulation) from each Outside interface. Issue here that since route to ISP1 is in priority my second SLA monitor which is looking to ISP2 side is not routed correctly. How can I make both tracks ping the desired ip? Is it possible or am I doing something wrong? Below are the configs and some details.

-------------------------------------SHOW RUN------------------------------------------------------------

!
interface GigabitEthernet0/0
nameif LAN0-g0/0
security-level 100
ip address 192.168.1.251 255.255.255.0
!
interface GigabitEthernet0/1
nameif ISP2
security-level 0
ip address 20.1.1.157 255.255.255.248
!
interface GigabitEthernet0/3
nameif ISP1
security-level 0
ip address 10.1.1.157 255.255.255.224
!
interface GigabitEthernet0/4
nameif DMZ4-g0/4
security-level 50
ip address 192.168.150.251 255.255.255.0
policy-route route-map PBR_DMZ_MAP
!
object network DMZ_Server2
host 192.168.150.11

object network DMZ_Server
host 192.168.150.88

object network Google_Dns
host 8.8.8.8

object-group network DMZ_Servers
network-object object DMZ_Server
network-object object DMZ_Server2

access-list PBR_DMZ_Servers extended permit ip object-group DMZ_Servers object Google_Dns

route-map PBR_DMZ_MAP permit 10match ip address PBR_DMZ_Servers
set ip next-hop verify-availability 20.1.1.158 1 track 1
set ip next-hop verify-availability 10.1.1.145 2 track 2

!
route ISP1 0.0.0.0 0.0.0.0 10.1.1.145 1
route ISP2 0.0.0.0 0.0.0.0 20.1.1.158 20

!

sla monitor 1
type echo protocol ipIcmpEcho 8.8.8.8 interface ISP2
timeout 3000
frequency 3
sla monitor schedule 1 life forever start-time now
sla monitor 2
type echo protocol ipIcmpEcho 8.8.8.8 interface ISP1
timeout 3000
frequency 3
sla monitor schedule 2 life forever start-time now

!
track 1 rtr 1 reachability
!
track 2 rtr 2 reachability

--------------------------------------------------------------------------------------------

------------------------------------SHOW TRACK-------------------------------------------

ciscoasa(config)# show track
Track 1
Response Time Reporter 1 reachability
Reachability is Down
1 change, last change 00:35:37
Latest operation return code: Timeout
Tracked by:
ROUTE-MAP 0
Track 2
Response Time Reporter 2 reachability
Reachability is Up
2 changes, last change 00:08:31
Latest operation return code: OK

Latest RTT (millisecs) 1
Tracked by:
ROUTE-MAP 0

---------------------------------SHOW ROUTE MAP-----------------------------------------------

ciscoasa(config)# show route-map
route-map PBR_DMZ_MAP, permit, sequence 10
Match clauses:
ip address (access-lists): PBR_DMZ_Servers
Set clauses:
ip next-hop verify-availability 20.1.1.158 1 track 1 [down]
ip next-hop verify-availability 10.1.1.145 2 track 2 [up]

[Dennis Mink]

Geronymo,

your track 2 is down. this is why you essentially only have one default route available so route ISP2 0.0.0.0 0.0.0.0 20.1.1.158 20 is down. even though you have the same tracking object 8.8.8.8, tracking it though 2 different IPS. I think what is happening is the icmp on the way back from 8.8.8.8 is entering the ASA on another interface as the egress traffic and thus dropping it.

[Gerorymo]

Hello, Dennis! Thanks for your prompt reply, I really appreciate that.

Yes, I believe this is the issue, now it makes sense to me. But is there a workaround for this? Since there is only one default route, how could I check the ISP2 link is not down via SLA (or maybe another tool)? I was finding some bits of info regarding this and just found that it can be solved by setting next hop on default gateway, but I'm not sure and I didn't get how to set this up to say honestly.

[Dennis Mink]

good question, what i would try is to find out if ISP2 has its own DNS servers and use these as your polling object instead of 8.8.8.8. so if isp2 DNS server is for instance 140.40.40.40 the add a host route in for that IP pointing to ISP2 and change the sla object to 140.40.40.40. not sure if it will work, but try. let me know how you go

[Gerorymo]

Hi, Dennis,
I believe it will have the same outcome regardless which remote host I will ping, it is all about the answer coming from 8.8.8.8 for ISP2 interface don't know where to go as you have stated.
Why I chose 8.8.8.8 just because it is available for both ISP. Here is some feedback for our local ISPs, I'm not sure for 100% but sometimes they have no peering agreement between each other and this can be a botlleneck here.
Also i was thinking that SLA works through the interface for which it was chosen for and looks up for that interface set route, but it seems it just works as a standard icmp going through the default gateway, which is kinda bummer.