One of the frustrating things about the Cisco ASA is that it does not support policy based routing, or pbr. With pbr, an administrator can get very granular with routing IP traffic. For example, an access-list can match traffic and steer it to an alternative next hop based on things like TCP/UDP port or IP source address. The ASA does not have the same level of granularity. However, a solid understanding of the interface selection process will allow an administrator to get creative and achieve some of the same results.
Prior to discussing the interface selection process, it is important to understand one of the other nuances of the ASA. That nuance is the arp behavior. The reason this is so important is that some of the configuration options discussed will cause the ASA to respond to any arp request on the inside interface. This can cause unpredictable behavior for communications between hosts connected to the inside interface. This is discussed more thoroughly in the article below.
The ASA’s ARP Behavior
http://packetu.com/2011/11/07/the-asas-arp-behavior/
Cisco has published the egress interface selection process for the ASA at the following URL
Cisco ASA 5500 Series Configuration Guide
An excerpt from this article states:
1. If destination IP translating XLATE already exists, the egress interface for the packet is determined from the XLATE table, but not from the routing table.
2. If destination IP translating XLATE does not exist, but a matching static translation exists, then the egress interface is determined from the static route and an XLATE is created, and the routing table is not used.
3. If destination IP translating XLATE does not exist and no matching static translation exists, the packet is not destination IP translated. The ASA processes this packet by looking up the route to select egress interface, then source IP translation is performed (if necessary).
For regular dynamic outbound NAT, initial outgoing packets are routed using the route table and then creating the XLATE. Incoming return packets are forwarded using existing XLATE only. For static NAT, destination translated incoming packets are always forwarded using existing XLATE or static translation rules.
Next Hop Selection Process
Understanding and Testing this Process
In order to test the selection process, a small lab can be constructed. This needs to include an inside host and two external routers to be configured as next hop addresses.
As a starting point, the ASA should be configured with addressing that matches the drawing.
//base ASA configuration
ASA# show run interface
!
interface Vlan1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
!
interface Vlan2
nameif isp1
security-level 0
ip address 1.1.1.2 255.255.255.0
!
interface Vlan3
nameif isp2
security-level 0
ip address 2.2.2.2 255.255.255.0
!
interface Ethernet0/0
description Connected to ISP1
switchport access vlan 2
!
interface Ethernet0/1
description Connected to Inside
!
interface Ethernet0/2
description Connected to ISP2
switchport access vlan 3
At this point, it is a good idea to test the local connectivity.
ASA(config)# ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
ASA(config)# ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
ASA(config)# ping 2.2.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
In order to route packets to both ISPs, there will need to be a route out each interface. This should probably look something like the following.
//route to isp1
route isp1 0.0.0.0 0.0.0.0 1.1.1.1//route to isp2
route isp2 0.0.0.0 0.0.0.0 2.2.2.1
However when this configuration is attempted, the ASA will throw an error because the routes overlap.
ASA(config)#
ASA(config)# route isp1 0.0.0.0 0.0.0.0 1.1.1.1ASA(config)#
ASA(config)# route isp2 0.0.0.0 0.0.0.0 2.2.2.1
ERROR: Cannot add route entry, conflict with existing routesASA(config)# show run route
route isp1 0.0.0.0 0.0.0.0 1.1.1.1 1
Only one route was accepted and it has an administrative distance of “1″. A second route to the same destination can be added by using a higher administrative distance.
ASA(config)#
ASA(config)# route isp2 0.0.0.0 0.0.0.0 2.2.2.1
ASA(config)# show run route
route isp1 0.0.0.0 0.0.0.0 1.1.1.1 1
route isp2 0.0.0.0 0.0.0.0 2.2.2.1 2
At this point, packets originating from or going through the ASA going with “unknown” destinations will have a next hop of 1.1.1.1. This is because of the lower administrative distance of that default route and the absence of a destination nat configuration. If the administrative distance of the first route is set to “3″, the route to 2.2.2.1 will be preferred.
If some traffic should be routed to one interface and other traffic should be routed to another interface, the second step in the egress interface selection process (step 2 from Cisco’s excerpt above) should be looked at. With the default route to 1.1.1.1 set with an administrative distance of 1, traffic can still be steered traffic to 2.2.2.1. This is done by creating a destination translation. Actually the destination translation that is used below is an exemption, but it works the same for egress interface selection. Basically it translates w.x.y.z to w.x.y.z. Prior to attempting this, it is recommended that proxy arp be disabled on the inside interface.
//disable proxy arp on inside
ASA(config)#sysopt noproxyarp inside//create a destination translation to match everything
ASA(config)#static (isp2,inside) 0.0.0.0 0.0.0.0 netmask 0.0.0.0
At this point, all traffic going through the ASA would be routed to the isp2 interface. Alternatively, half of the traffic could be routed to isp2.
//delete the existing translation
ASA(config)#no static (isp2,inside) 0.0.0.0 0.0.0.0 netmask 0.0.0.0//create a destination translation for 128-255
ASA(config)#static (isp2,inside) 128.0.0.0 128.0.0.0 netmask 128.0.0.0
At this point, packets destined to 0-127.x.x.x will go to isp1. Packets with a destination of 128-255.x.x.x will go to ISP2. That still is not too interesting. This could actually be accomplished with two routes in the route table.
One of the more interesting things that some desire to achieve with policy based routing in IOS is routing by traffic type. For example, traffic to port 80 and 443 might go to isp2. All other traffic could go to isp1. This can be accomplished in the ASA by using a configuration similar to the following.
//delete the previous destination translation
ASA(config)#no static (isp2,inside) 128.0.0.0 128.0.0.0 netmask 128.0.0.0//create destination translations that include tcp/udp ports
static (isp2,inside) tcp 0.0.0.0 80 0.0.0.0 80 netmask 0.0.0.0
static (isp2,inside) tcp 0.0.0.0 443 0.0.0.0 443 netmask 0.0.0.0
Unlike IOS based routers, the ASA does not support policy based routing. While this certainly creates limitations, there are options that will allow an administrator to achieve some of the same goals. Prior to implementing destination translation or destination translation exemptions, it is very important to understand the proxy arp behavior on the ASA. When a destination translation or exemption exists, outbound packets use the entry to determine the egress interface. Once the egress interface is chosen, the ASA does a route lookup specific to the chosen interface. By understanding these interactions, an administrator can use destination translation exemptions to steer packets to the desired interface. This can alleviate some of the limitations found in the ASA.
