Policy-Based Routing (PBR), How PBR works and How we can use PBR?

PBR:

• Destination based routing systems make it quite hard to change the routing behavior of specific traffic. With PBR, a network engineer has the ability to dictate the routing behavior based on a number of different criteria other than destination network, including source or destination network, source or destination address, source or destination port, protocol, packet size, and packet classification among others.
• 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.
• In a way, it allows traffic engineering at interface level. It allows to route the packets over specific traffic engineered paths, which provide the desired QoS through the network.

WORKING WITH 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. For example, to forward traffic based-on source
• PBR could match on only destination as well, but typically we would match on more. Even if we use PBR to match only on destination, sometimes, we may wish to override the route for a IP destination and may wish to use our own next-hops for traffic on an interface instead of using those learnt from routing protocols for a variety of reasons.
• PBR is considered to be an exception to the RIB and is looked at before examining the RIB.
• Within the policy-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 also match on QoS marking, such as IP precedence or differentiated services code point (DSCP)
• 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 using a qos policy-map along with this pbr policy-map.
• The class-map of policy-map can have multiple statements (typically sequenced in increments of 10), giving us the control to match on multiple sets of match conditions. The class-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 policy-map type pbr <policy-map-name>. 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).

VERIFYING PBR:

• We can verify that the PBR has taken effect using ‘traceroute’
• Before configuring PBR, run traceroute for that IP from the device originating traffic and we will see that the next-hop after our device will be taken based on routing protocol
• After configuring PBR, if we verify on traceroute, we will see that the route passed through our PBR’s configured next-hop

HOW CAN WE 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. It can be used to control the specific paths of network traffic, however, we need to make sure to only use PBR when it is needed as destination based routing methods work very well by themselves. Like many other features offered, this feature is designed for a specific set of circumstances and should be used only for those purposes to maintain efficiency.
• The most common use of PBR 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.