Policy-Based Routing: What Is It and How Is It Used?
- Date: 08 January, 2015
Routing is the process of discovering destination networks, advertising them, determining best path and maintaining that information. Routing is not the process of moving data through a router, that’s refered to switching within the router. Which should not to be confused with a switch, which in today’s definition is a hardware-based device, forwarding typically based on Layer 2 addressing (but could be multiLayer). There are different routing protocols that are available, depending on the Layer 3 protocol. A protocol that has addressing at Layer 3 is called a routed protocol or routable. The protocols used to advertise information about those Layer 3 protocols are routing protocols.
All this is CCNA level type of information, but it’s important to see that the routing protocols do not pass user traffic, they pass information about destination networks. It doesn’t matter if we’re talking about RIP, OSPF, EIGRP, ISIS or BGP — they all do the same thing. They advertise networks, build some type of local table, select a best path, try to contribute to the routing table (also known as the routing information base, or RIB) and then have to maintain that information to know that it is still current. We can implement policy within these protocols, but this is not Policy-based routing (PBR). Policy within the dynamic protocols listed will filter or manipulate the way we use the information. With static routing, we (or whomever configured the static) are the routing protocol; we decide the path to take to a given destination network or host. PBR gives us more control and can match on more than just the destination in the process of forwarding traffic.
What is PBR?
PBR is the process of using a route map to match on something more than the destination and then defining the path out of the router based on those conditions. PBR could match on destination only, but typically we would match on more. PBR is considered to be an exception to the RIB and is looked at before examining the RIB. Within the route map used for PBR, we can match on an access control list (ACL) that then matches on source, destination, protocol type and/or port numbers; we can match on QoS marking, such as IP precedence or differentiated services code point (DSCP); and we can match on size of the packets.
Once we have a positive match, then we can set the next hop devices address and/or egress interface. Plus, we can also set QoS values at the same time. The route map can have multiple statements (typically sequenced in increments of 10), giving us the control to match on multiple sets of match conditions. The route map can also have deny statements (the default if not specified is permit), that then can be used to act as a filter. When the route map matches on an ACL, if it matches a deny in the ACL, it drops out of that statement of the route map and continues to the next statement in the route map. The deny or drop is defined by the route map, not the ACL that is referenced by the route map.
If there are no positive matches within the route map or we hit a route map statement that has no set condition (that is a permit statement, not deny), then it is policy rejected. If we have a policy rejected condition, then the traffic is forwarded normally based on the RIB. When you do a show ip route or show ipv6 route command, you will not see that PBR is in use. You can do a show ip policy or show ipv6 policy. This will show you that there is a policy defined for PBR, but not where it’s allied. To see it applied to an interface, use the show ip interface (not brief). Of course, you could just look at the configuration if you have access rights.
How can I use PBR?
Normal routing is only concerned about destination-based forwarding, while PBR gives us more control. We can use PBR to direct traffic down links that are reserved for specific types of traffic or levels of priority. We can use PBR to direct traffic based on the source, not the destination, to steer specific customer traffic down links that match their service level agreement. We can use PBR in combination with MPLS TE (multi-protocol label switching traffic engineering) to direct traffic into specific MPLS TE tunnels. When applying a policy to an interface, there is no direction in the syntax, it will always ingress. There is no effect on egress traffic or on traffic originating from the router itself. If you need to apply policy against the router itself, then apply it as a local policy in the global configuration. One issue with PBR is that it is like a static route in that it is locally significant. If you need to have policy applied on multiple routers in a path between devices, PBR would have to be configured hop by hop.
PBR is an interesting tool for controlling the traffic flow based on something other than normal destination-based routing, but most find it cumbersome and not scalable. The most common place that I see it today is in the provider space in combination with MPLS TE to direct customer traffic through specific MPLS TE tunnels. There are other use cases, but it tends to be very specific fixes to specific local issues.
PBR Examples
R1#show run Interface FastEthernet0/1 Ip address 192.168.12.1 255.255.255.0 Ip policy route-map test ! route-map test permit 10 description This matches the source IP of my PC and sets a prec of 5 match ip address MyPC set ip precedence critical set interface FastEthernet0/0 ! route-map test permit 20 description This is a filter statement match ip address NotMyFriend ! route-map test permit 30 description To act as a filter with a permit match ip address Stranger set interface Null0 ! route-map test permit 999 description This is a common statement in route maps, but without a set condition it will be ! |
R1#show ip policy Interface Route map Fa0/1 test |
R1#show ip interface fastEthernet 0/1 FastEthernet0/1 is up, line protocol is up Internet address is 192.168.12.1/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.2 Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP Flow switching is disabled IP CEF switching is enabled IP CEF switching turbo vector IP CEF turbo switching turbo vector Associated unicast routing topologies: Topology "base", operation state is UP IP multicast fast switching is enabled IP multicast distributed fast switching is disabled IP route-cache flags are Fast, CEF Router Discovery is disabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled RTP/IP header compression is disabled Probe proxy name replies are disabled Policy routing is enabled, using route map test Network address translation is disabled BGP Policy Mapping is disabled Input features: Policy Routing, MCI Check WCCP Redirect outbound is disabled WCCP Redirect inbound is disabled WCCP Redirect exclude is disabled R1# |
R1#show route-map route-map test, permit, sequence 10 Match clauses: ip address (access-lists): MyPC Set clauses: ip precedence critical interface FastEthernet0/0 Policy routing matches: 0 packets, 0 bytes route-map test, permit, sequence 20 Match clauses: ip address (access-lists): NotMyFriend Set clauses: Policy routing matches: 0 packets, 0 bytes route-map test, permit, sequence 30 Match clauses: ip address (access-lists): Stranger Set clauses: interface Null0 Policy routing matches: 0 packets, 0 bytes route-map test, permit, sequence 999 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes |
Policy-based routing adds flexibility and control that other routing techniques do not. It give you a level of control that a routing protocol by itself does not. With flexibility, there is typically a cost and in this case its scalability and manageability. It is a great tool but not one to be used for all cases. When you have a need to forward base on something other than destination, then PBR is your answer.
Related Resource
Cisco White Papers
Related Courses
IP6FD - IPv6 Fundamentals, Design, and Deployment v3.0
ROUTE - Implementing Cisco IP Routing v2.0
TSHOOT - Troubleshooting and Maintaining Cisco IP Networks v2.0
DCII - Implementing Cisco Data Center Infrastructure v6.2
