Here’s our lovely diagram for this exercise.

You will notice that I have a firewall in place. This configuration works with or without the firewall. You can ditch the firewall and move the VLAN interfaces to the router. I added the firewall, because the question was asked from someone who has this configuration. So, in this configuration with the firewall, we won’t do any NATing in the firewall, it will all be done in the router. This will allow me to be as granular as possible. We are also assuming that each ISP is giving you a single static public IP.

So, what is Policy Based Routing(PBR)? This allows you to put a policy incoming on an interface that will move or manipulate traffic in a variety of ways. Here’s the quick and dirty from Cisco.

We are going to:

• Specify a default route for ISP2
• Create an ACL that will specify which traffic we want to exit ISP1
• Create a route-map that will match our ACL and divert that traffic to ISP1
• We will then apply the route-map to the incoming interface of the source traffic

Router Config:

	
int fa0/0
	
ip address 192.168.0.2 255.255.255.0
	
desc Inside-to-firewall
	
!configure this interface as inside for NAT
	
ip NAT inside
	
!add the route-map on the traffic's incoming interface
	
ip policy route-map alternate-routing
	
!
	
int fa0/1
	
ip address 1.1.1.1 255.255.255.252
	
desc Outside-to-ISP1
	
!setup ip NAT for outside
	
ip NAT outside
	
!
	
int fa0/2
	
ip address 2.2.2.2 255.255.255.252
	
desc Outside-to-ISP2
	
!setup ip NAT for outside
	
ip NAT outside
	
!
	
!NAT AVL.  Specify what should be NAT'd.
	
ip access-list ext NAT
	
 permit ip 192.168.0.0 0.0.255.255
	
!
	
!specify interesting traffic for our policy
	
ip access-list ext web-traffic-users
	
 permit tcp 192.168.20.0 0.0.0.255 any eq 80
	
 permit tcp 192.168.20.0 0.0.0.255 any eq 443
	
!
	
!setup the NAT statements for our outside interfaces
	
ip NAT inside source list NAT int fa0/1
	
ip NAT inside source list NAT int fa0/2
	
!
	
!default route out ISP2
	
ip route 0.0.0.0 0.0.0.0 2.2.2.1
	
!floating static default route out ISP1
	
ip route 0.0.0.0 0.0.0.0 1.1.1.2 254
	
!
	
route-map alternate-routing permit 10
	
 match ip address web-traffic-users !Match the AVL web-traffic
	
 set ip next-hop 1.1.1.2 2.2.2.1 !set the next hop for this traffic out ISP1, if it fails, use ISP2

On line 26, we configure an ACL that specifies which traffic will be grabbed and sent out ISP1.

Line 39 begins our route-map. These guys are the heart of our configuration. You name it, specify permit and give it a sequence number. After that we provide a match statement. Here we match the ACL we created on line 26. The action to be performed is specified with set commands. Our set command is setting the next-hop IP address for ISP1 and then secondary ISP2. The idea is if ISP1’s interface is up, the user web traffic will dump out there. If ISP1 goes down, the web traffic will kick to ISP2.

On line 35 we have the default route pointing out ISP2. This will send all traffic that direction by…well…default..heh. You will notice that on line 37 we have what appears to be another default route. In reality, we are using a floating static route. We have the metric for the route set to 254. What this does is make the route look undesirable, and so the ISP2 route will normally be used. If ISP2’s interface goes down, then ISP2’s route will go away and ISP1’s route will be used. This gives us failover for both providers.
A note on using floating routes: The failover only happens if the interface goes down. What this means is that if routing in the provider’s network bricks on us, we will continue to send traffic to them, because our interface never goes down, so we still have our routes pointing to them! How do we work around this? We can use IPSLA. I’m not going to go into these configurations, because I’ve already done this! The command sets should be almost identical for IOS as it is for ASAs. Here’s the ASA article.

Last, on line 7 we apply the route-map to the inside interface on the router. Route-maps for PBR can only be applied inbound on interfaces. We do this because if we are going to violate the route table, we have to do it before the routing table gets hold of the traffic.

Questions and comments are more than just welcome, they are demanded!