Cisco asa PBRouting + SLA monitor attached

[Gerorymo]

Friends, desperately need your help 

I have a two ISP (ISP1 primary, ISP2 backup) connected to cisco ASA on the edge of my net. I have a task to route DMZ subnet to ISP2, and if the link to ISP2 (backup) is down I have to route it to ISP1 (primary). 

I have two static routes like: 

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 254

1) I created 2 sla monitors - one to monitor primary ISP1 link (via 8.8.8.8 as remote object); second to monitor ISP2 link as well and created tracks for this two objects 

sla monitor 1

type echo protocol ipIcmpEcho 8.8.8.8 interface ISP 1 

sla monitor schedule 1 life forever start-time now 

track 1 rtr 1 reachability 

sla monito 2 

type echo protocol ipIcmpEcho 8.8.8.8 interface ISP2 

sla monitor schedule 2 life forever start-time now

track 2 rtr 2 reachability

2)created acl DMZ_PBR and used it in PBR

access-list DMZ_PBR extended permit ip object DMZ_LAN any

route-map DMZ_MAP permit 10

match ip address DMZ_PBR

set ip next-hop verify-availability 20.1.1.158 1 track 2  

set ip next-hop verify-availability 10.1.1.145 2 track 1

3) applied this map to DMZ interface 

interface g0/3

policy-route route-map DMZ_PBR

But when I check the tracks (1 track for primary; 2 for backup) 

I see that track 1 is up, but track 2 is down. I believe this is because SLA track 2 for ISP2 backup goes via static default route via ISP1 interface and when the reply comes from 8.8.8.8 it is being dropped. 

Does anyone had such issue, or how can I do it or show working configuration for such scenario, cause I'm stuck here. People were suggestion to make redundant interface for OUTSIDE interfaces but I don't think this is the case.

Thank you in advance!

[Georg Pauwen]

Hello,

I recreated your setup in GNS3, using loopbacks on the ISP routers rather than 8.8.8.8, and both tracks are up.

What if you change the SLAs to:

sla monitor 1

type echo protocol ipIcmpEcho 10.1.1.145 interface ISP 1

sla monitor schedule 1 life forever start-time now

track 1 rtr 1 reachability

sla monito 2

type echo protocol ipIcmpEcho 20.1.1.158 interface ISP2

sla monitor schedule 2 life forever start-time now

track 2 rtr 2 reachability

[Gerorymo · Accepted solution]

Hello Georg,
Thanks for your reply. I'm using EVEng as well for checking this. Just did it when I saw your comment and I believe we are in the same point. I've also started using not 8.8.8.8 as trackable object but ISPs DNS servers. Also one more thing which I was confronting with it is that the reply packet from ISP2 was dropping. I believe it is because of the default route through the ISP1 outside interface is set here so that ingress traffic
from ISP2 was not coming.

What I did is I add two static routes directly to those DNS for each ISP and each interface. Working now without a problem. Could be a bottleneck somewhere, but so far no issues found.

Here is my config:

interface GigabitEthernet0/1
description ISP 2
nameif ISP2
security-level 0
ip address 20.1.1.157 255.255.255.248
!
interface GigabitEthernet0/3
description ISP 1
nameif ISP1
security-level 0
ip address 10.1.1.157 255.255.255.240
!
interface GigabitEthernet0/4
description DMZ
nameif DMZ
security-level 50
ip address 192.168.150.252 255.255.255.0
policy-route route-map PBR_DMZ_MAP
!

object network DMZ_SUBNET
subnet 192.168.150.0 255.255.255.0

access-list PBR_DMZ extended permit ip object DMZ_SUBNET any

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

route ISP1 0.0.0.0 0.0.0.0 10.1.1.145 1 track 1
route ISP2 0.0.0.0 0.0.0.0 20.1.1.158 2
route ISP2 20.1.1.6 255.255.255.255 20.1.1.158 1
route ISP1 10.1.1.8 255.255.255.255 10.1.1.145 1

sla monitor 1
type echo protocol ipIcmpEcho 10.1.1.8 interface ISP1
sla monitor schedule 1 life forever start-time now
sla monitor 2
type echo protocol ipIcmpEcho 20.1.1.6 interface ISP2
sla monitor schedule 2 life forever start-time now
!
track 1 rtr 1 reachability
!
track 2 rtr 2 reachability

[Georg Pauwen · Accepted solution]

Hello,

that looks better. I guess you need to configure the SLA to monitor something that actually belongs to the ISP (whereas 8.8.8.8 is not really ISP specific). That is what the DNS servers are, ISP specific.

Anyway, keep monitoring, it should work this way...good luck.

[Gerorymo]

Thanks, man, appreciate the help!

[paul driver]

Hello

---

@Gerorymo wrote:
 see that track 1 is up, but track 2 is down

---

You need to track a destination that is reachable between the source and this case it looks like because your tracking 8.8.8.8 ISP2 interface isn't able to reach 8.8.8.8 via ISP1 which is you default route at present, so track something that is significant to either ISP

May I ask if ISP1 is down I assume you want to route all traffic via ISP 2?  - if so you may also need to track both availability's via a boolean 

Example:

track 3 list boolean and
object 1
object 2

track 1 rtr 1 reachability
track 2 rtr 2 reachability

route-map DMZ_MAP permit 10
match ip address DMZ_PBR
set ip next-hop verify-availability ISP2 1 track 2
set ip next-hop verify-availability ISP1 2 track 1
set ip next-hop ISP1 ISP2

ip route 0.0.0.0 0.0.0.0 <interface) 10.1.1.145 track 3
ip route 0.0.0.0 0.0.0.0 <interface) 20.1.1.158 254

[Gerorymo]

Hello Paul,

This is interesting syntax, I've never saw one. To say honestly I'm newbie with cisco devices, especially ASA which has some differencies with other products they've released. I will test this workaround in lab and let you know. Really appreciate your response. And btw I've also added the tracking to the static routes so it is changing both for PBR and other routing, but your option is more interesting to me, I didn't know that you can have boolean for tracks. 

I've also shared my conf above your reply. I would really appreciate if you point me some problematic areas, but so far this config is working. 

[paul driver]

Hello

you know what I missed a vital point so apologies - your using ASA ! - however the Boolean should still work but if you any issues with it let me know