ASA and policy based routing

[Andrew White]

Hello,

We have 2 x 5516x ASAs in active/standby and their outside interfaces go into a stack of 2 x 3750s.  In this switch we also have our ISP routers which are setup as a HSRP.  The active router is on 100MB line and the standby router is on 30MB.

Out 100MB line is quite heavily used and I was wondering if it's possible to router certain traffic to the standby router (physical IP) by using policy based routing?

I've only every seen this on routers and we don't manage our routers, our ISP do and will charge for any changes.  I thought maybe the ASAs could do it?

As a test I was wondering if I can just route my laptop IP through the backup router for traffic destined for the internet on port 80 via the ASA and policy based routing on it?

Our current route for all users for http/https uses the 0.0.0.0 0.0.0.0 x.x.x.65 which is the HSRP public IP of the routers.  THe primary router is on .71 and standby on .72.

Thanks in advanced for your help.

[Andrew White]

The inside PC's gateway is the SVI of the switch for it's VLAN which then routes to the inside interface of the ASA.  It then seems to got .65 (HSRP) then .74 (Active router).

[ngkin2010]

Hi,

Sorry that I asked a wrong question, it isn't relevant to the default gateway... what I should ask is the next hop address on your switch. That's is .65, you answered.

As mentioned, could you check if there is any hit for the access list? And could you try with the debug command to check with the PBR?

[ngkin2010]

Hi,

I have also created a GNS3 lab, and here is the full configuration for your reference.

[Andrew White]

I will grab some debugs, but the switch beyond the ASA is just a L2 switch all in VLAN1.

.66 the (ASA) next hop is .65 (the routers HSRP), but the policy maps next hop is set to .65.

The primary router is .74 and standby is .75 which is where I want to icmp/http/https to route to.

So what does this route map do (sorry not used one before as you can probably tell)

route-map ISP1 permit 10

match ip aw_address interesting_traffic

set ip next-hop verify-availability x.x.x.75 1 track 1

set ip next-hop x.x.x.65

The way I read it is, if traffic in ACL 'aw_address interesting_traffic' is matched then check the standby router (.75) is up and if it is route to .65 (the HSRP).  Shouldn't the next hop be .75?

Thanks

[ngkin2010]

Hi,

Yes, your interpretation is correct.

set {ip | ipv6} next-hop ipv4_or_ipv6_address
-- You can configure multiple next-hop IP addresses in which case they are evaluated in the specified order until a valid routable next-hop IP address is found.

set ip next-hop verify-availability next-hop-address sequence_number track object
-- You can configure an SLA monitor tracking object to verify the reachability of the next-hop.

When multiple set actions are configured, the ASA evaluates them in the following order:set ip next-hop verify-availability;set ip next-hop;set ip next-hop recursive;set interface; set ip default next-hop;set default interface.

The more detailed information can be found on:
https://www.cisco.com/c/en/us/td/docs/security/asa/asa96/configuration/general/asa-96-general-config/route-policy-based.html#ID-2182-00000032

[Andrew White]

I think it must be our ISP.

I added the route map on our production network just for my local workstation IP and Spanned/mirrored the port leading to the backup router.  When I pinged 8.8.8.8 or tried a http site from my workstation I saw the traffic go to the backup router in Wireshark, but the ping failed as did the http site.  I think the route back must go via the active router and drop.

[ngkin2010]

That's interesting, is there is any return traffic received by ASA's outside interface? You could set a capture on your ASA to check on it:

# capture temp input buff 2048 interface Outside match ip host <source ip address> any
# show capture temp
## -- when the buffer is fully filled, you could clear it by:
# clear capture temp
## -- to remove the capture
## no capture temp

I don't think ISP today would drop the customer's Internet packet..

When you captured the traffic was gone through the backup router, but you see no any return traffic (from either backup / active router), you could the reason from your ISP.