Tracking with route-map or on route statement, which is better for this scenario?

[Gerard Roy]

I have two ISP's, I want to utilize both circuits in an active/active scenario (not active/active as in a dual asa scenario). Would a route map for each ISP traffic be an answer for this? We have load balancers up front and they do round robin, I would like traffic that came in on one ISP to go out the same ISP link. Are the sla's typically only for a failover scenario? Which would be a better option between doing track under the route map vs track on default route?

IP SLA Tracking on route-map:

route-map PolicyRoute-vz permit 20
match ip address route-VZ
set ip next-hop verify-availability x.x.x.x 1 track 1

route-map PolicyRoute-cl permit 30
match ip address route-CL
set ip next-hop verify-availability y.y.y.y 2 track 2

IP SLA Tracking on routes:
route outside-VZ 0.0.0.0 0.0.0.0 x.x.x.x 1 track 1
route outside-CL 0.0.0.0 0.0.0.0 y.y.y.y 2 track 2
ip sla 1

icmp-echo x.x.x.x source-interface outside-VZ

ip sla schedule 1 life forever start-time now
ip sla 2

icmp-echo x.x.x.x source-interface outside-CL

ip sla schedule 1 life forever start-time now

[Francesco Molino]

Hi

Based on your snippet config, you're using an asa device.

You won't be able to do active/active for inbound connections. 

How have you built your acls?

You're doing PBR which is the way to achieve this for outgoing access.

[Gerard Roy]

Hi Francesco,

Thanks for the reply. Yes, It is an ASA, sorry I was not clear initially. You stated "You won't be able to do active/active for inbound connections". Can you give me the reasoning behind this? 

The ACL's (see below snippet) are applied under the route-map to objects that have been defined. What do you recommend?

access-list route-VZ remark #### Avoid internal traffic to route through outside VZ int ####
access-list route-VZ extended deny ip object UAT_NET object DMZ
access-list route-VZ extended deny ip object UAT_NET object INSIDE-VZ
access-list route-VZ extended deny ip object DMZ object UAT_NET
access-list route-VZ extended deny ip object DMZ object INSIDE-VZ
access-list route-VZ extended deny ip object INSIDE-VZ object UAT_NET
access-list route-VZ extended deny ip object INSIDE-VZ object DMZ
access-list route-VZ extended permit ip object INSIDE-VZ any
access-list route-VZ extended permit ip object DMZ any
access-list route-VZ extended permit ip object UAT_NET any
access-list route-VZ remark #### route below through VZ outbound ####
access-list route-VZ extended permit ip object ns2-VZ any
access-list route-VZ extended permit ip object ns1-VZ any
access-list route-VZ extended permit ip object sqlbench-VZ any
access-list route-VZ extended permit ip object Sandbox-PAT any
access-list route-VZ extended permit ip object uatImg01-VZ any
access-list route-VZ extended permit ip object uatMgt01-VZ any
access-list route-VZ extended permit ip object haproxy_VIP-VZ any
access-list route-VZ extended permit ip object wwwimg-VZ any
access-list route-VZ extended permit ip object bkup01-VZ any
access-list route-VZ extended permit ip object util100-VZ any
access-list route-VZ extended permit ip object bssmgt-VZ any
access-list route-VZ extended permit ip object webcache-VZ any
access-list route-VZ extended permit ip object nagios-VZ any

Thanks!

[Francesco Molino]

What i meant by active/active was more in a load balancer way, having 1 ip = 1 fqdn. To have both links working, you need to load balance yourself manually all services by playing with dns so service A goes over link 1 and service B over link 2. If link 2 fails, you need to update your dns to re-route traffic to link1.
The PBR solution is what works to ensure a service coming to link B always goes out over the same link.