Policy-Based Routing: What Is It and How Is It Used?

PolicyBasedRoutingRouting 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
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
Broadcast address is
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined:
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#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
DCUFI – Implementing Cisco Data Center Unified Fabric v5.0

In this article

Join the Conversation


  1. Harm Kanters Reply

    You had made a clear story on PBR.
    PBR can be of great use. I used it in a few networks.
    These items might need to be considered when applying PBR for manipulating the path taken; async routing and reliability.
    Async: As you stated :”There is no effect on egress traffic..”, so PBR does not affect the returning traffic. If return-traffic followes the path paved by a routing protcol, the return-traffic can travel via other paths as the outgoing traffic.
    Reliability: The path-redundacy created by mechanisms of routing-protocols will not used if traffic has a positive matches within the route map. The reliability can be ugraded if we combine “verify-availability” with PBR. Thus checking the upstream path before applicy the Set-statements.

  2. Rev Ernest Vewes Reply

    Are you sure about “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”?
    What would be the point of that? What would be the difference if the deny line wasn’t there at all? This sounds like “if it doesn’t match, go to the next statement; if it does match, still go to the next statement ”
    I thought that ‘deny’ was in fact a misnomer for ‘ignore’, i.e. if you get a match, don’t proceed any further with PBR and drop back to standard routing?

    1. Zane Reply

      That is the behavior. And it’s as simple as “because you can.” If you have a group of addresses, but one is to be treated differently than the others, you can deny the one within the ACL and permit the rest of the subnet after. If it matches the deny statement then that would then move to the next statement within the route-map. If there is no match anywhere within ACL, then it will match the deny at the end of the ACL, which then makes it move to the next statement in the route-map to try to implement a policy. It’s the same behavior and would depend on how the ACL was written. Another reason and probably more valid is that this was an existing policy that needed to be updated and rather then re-writing it, the deny may be inserted into the ACL and a new statement added to the route map. The other option of course would be to put in the route-map statement the match for the more specific item above that with a more general match (this would be preferred.) As you can tell, there are options.