Skip to content
Oct 12 / Greg

Cisco Policy Based Routing – Violate Route Table – Send Some Traffic One Way and Everything Else The Other

The idea in this scenario is as follows: You have two ISPs. You want all of your user’s web traffic to exit and enter ISP1 and everything else to exit and enter ISP2. You also need the ISP connections to backup each other in the case of a failure of either.

Here’s our lovely diagram for this exercise.


PBR Diagram

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:

  1. int fa0/0
  2. ip address
  3. desc Inside-to-firewall
  4. !configure this interface as inside for NAT
  5. ip NAT inside
  6. !add the route-map on the traffic's incoming interface
  7. ip policy route-map alternate-routing
  8. !
  9. int fa0/1
  10. ip address
  11. desc Outside-to-ISP1
  12. !setup ip NAT for outside
  13. ip NAT outside
  14. !
  15. int fa0/2
  16. ip address
  17. desc Outside-to-ISP2
  18. !setup ip NAT for outside
  19. ip NAT outside
  20. !
  21. !NAT AVL. Specify what should be NAT'd.
  22. ip access-list ext NAT
  23. permit ip
  24. !
  25. !specify interesting traffic for our policy
  26. ip access-list ext web-traffic-users
  27. permit tcp any eq 80
  28. permit tcp any eq 443
  29. !
  30. !setup the NAT statements for our outside interfaces
  31. ip NAT inside source list NAT int fa0/1
  32. ip NAT inside source list NAT int fa0/2
  33. !
  34. !default route out ISP2
  35. ip route
  36. !floating static default route out ISP1
  37. ip route 254
  38. !
  39. route-map alternate-routing permit 10
  40. match ip address web-traffic-users !Match the AVL web-traffic
  41. set ip next-hop !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!

Leave a Comment