What is PBR? Policy Based Routing

Nowadays, network traffic nature becomes very complicated in terms of the mixture of applications and their connectivity requirements. Achieving these requirements by means of traditional routing mechanisms may become cumbersome or even impossible and requires special dedicated solutions.

Additionally, organizations need to focus on operational costs more strictly than in the past. One good direction to achieve this goal is the optimization of resource usage within different domains. Networking is one such domain, where the objective is to rationally maximize the usage of existing infrastructure rather than making an investment in increasing its capacity.

Policy Based Routing (PBR) is a great tool to help achieve both of these goals.

What is the difference between classic routing and policy based routing?

The traditional routing takes place in Layer 3 of the OSI model. Despite many Layer 3 protocols defined, the vast majority of traffic uses IPv4 and IPv6 protocols (we will refer to them as IP protocols in the remaining part of this article). Upon receiving a packet, the router examines the destination address in the IP header and consults its own routing table (performs route lookup) for information needed to process the packet further: transmit the packet data into the appropriate interface card, rebuild the Layer 2 header and transmit the packet back into the network. Required information includes the next-hop IP address and the outgoing interface.

What is policy based routing (PBR)?

Policy based routing (PBR) also performs those steps but enhances the initial packet examination phase and, depending on the case, may completely skip the route lookup phase. PBR and traditional routing are compatible and can coexist on the same networking device.

Multiple values gathered from contents of received packet headers and data are usually combined with desired values using Boolean algebra operators to yield a single bool value. This process is called packet matching. If the resulting value is “true”, configured PBR actions will alter packet handling flow. Despite the packet matching result, the normal routing takes place at the end. This process will be described in greater detail later after discussing a few popular PBR use cases.

A few real-life examples

Many organizations may be divided into functional departments, each having its own connectivity requirements. Additionally, for redundancy purposes, organizations may use multiple internet uplinks towards different service providers. The primary link, in most cases, will have better parameters (bandwidth, SLA) and also a higher price, while the backup will be a cost-effective service. With traditional routing, all traffic would go through the primary ISP provider, and routing business traffic through Deep Packet Inspection (DPI) device would require slight changes in the topology (move DPI behind the organization router) or usage of VLANs.

Let’s consider a simple scenario where the IT department wants to perform backups of large files (Virtual Machine disk images might be a good example here) and place them within cloud services. Such activity is likely to disturb the operation of other departments sharing the same primary link and, therefore, would have to be scheduled during the night.

With PBR, these activities may be performed during day time using the underutilized backup link without impacting other organization traffic. This is possible because PBR allows us to configure routing based on traffic source address. Therefore IT department employees can freely use any new cloud service without worrying about the need to constantly update organization router configuration.

Such an approach saves some costs by maximizing the usage of available internet connectivity bandwidth. The following figure shows such a scenario. In our example, traffic originates from networks A and B, while router R1 is configured with PBR policy to send traffic to selected ISP, based on the packet’s source address.

Another way to reduce costs is to automate your network. Check how we can help you.

Fig.1: Policy based routing - a real life example

Policy Based Routing has many more applications. These may include:

Selecting network path based on device source network – in traditional routing network path used by traffic is determined by the destination address found within packet headers. With PBR, a network administrator can also take into account the source address. This naturally allows us to implement special treatment of traffic coming from different departments, as each of them may have assigned a dedicated IP subnet.
Our organization may have some business services that require applying special security measures. Since not all organization traffic requires such security, it is desired that only business service related traffic should be routed through a DPI device. With this approach, an organization requires a less powerful (and cheaper) DPI device model. With traditional routing, the DPI device would have to be placed closer to the servers, which stands against the rule that malicious traffic should be dropped as soon as possible, or the solution would require more complex network topology.
PBR may also be used to implement more sophisticated traffic classification mechanisms to ensure that certain types of applications get better quality of service treatment. For instance, the organization structure may be reflected by applying appropriate PBR configuration.

Policy Based Routing operation in detail

With traditional routing in place, every data plane interface containing IP configuration is subject to the routing. In contrast, the PBR routing is disabled by default and can be enabled on a per-logical interface basis (like VLAN, for instance). Such default configuration helps save resources on the router device because PBR requires constant packet matching on the incoming traffic on enabled interfaces. As stated before, all packets that are positively matched are subject to additional operations before they can finally be routed in the traditional way.

The following pseudocode expresses in a very generic way operations performed by PBR.

If
	<match packet>

Then:
	replace next-hop

One of the fundamental building blocks of the PBR policy is the if – then conditional statement. Its role is to bind the packet matching configuration with a list of actions that should be performed on matched packets. It is available in different forms on different systems. Depending on the vendor, these could be:

route-map - command is available on the vast majority of network devices containing Cisco–like configuration CLI. It usually combines the name of a conditional expression with a set of actions.
ip rule – is a policy routing functionality available within linux systems
firewall filter – some vendors allow setting custom actions directly within the firewall configuration. An example includes devices with Juniper–like CLI.

A more detailed example of PBR configuration pseudocode:

If
	ip.src == 10.0.0.10 AND
          L4_protocol == TCP AND
          tcp.dst_port == 80
Then:
put packet in routing table 100

In this example, we are matching packets belonging to the HTTP session that originated from a host with IP address 10.0.0.10. Matched packets will be routed according to a custom routing table - that is, a lookup will be performed in IP routing table 100.

The presented examples do not show all possibilities for both the matching part and the action part.

Depending on the hardware capabilities, the packet matching options may include the following:

IP source and destination IP address
Layer 4 protocol type
Layer 4 protocol source and destination ports, if applicable
Packet size (may be a range)
an access control list
packet data of a given size at a given offset
application type
deep packet inspection pattern matching

After positively matching a packet, several actions are possible (these may vary depending on the hardware):

Replace next-hop – this is the most common operation performed by PBR. Replacing the next hop will instruct the router to send the packet over an alternate path pointed by the new next-hop address. Sometimes a list of available next-hop addresses may be specified.
Specify outgoing interface – allows configuring a specific interface that should be used by matched packets if, for instance, the existing next-hop may be reached through several local interfaces.
Place packet in a given routing table – this option instructs the router software to place a packet within a specified routing table or VRF. The packet is then routed according to a new routing table. With this option specifying the new next-hop is not mandatory and allows the device to make a bit more flexible and dynamic routing decisions.
Modify packet IP precedence – this setting may influence the quality of service level applied to a packet and, as such, may change transmission delay, throughput and reliability.

Does policy based routing have any limitations?

Increased functionality usually comes with some additional costs.

As mentioned before, PBR requires the router to constantly match incoming traffic on enabled interfaces. This consumes some resources of interface card ASICs or CPU time in the case of software solutions. Even the biggest and most advanced and expensive routers are not capable of matching all the traffic at the maximum rate supported by their interface cards.
PBR requires a static configuration on a local device. Therefore it may not scale well with large configurations.
Static configuration may lead to problems during outages in the network because under some circumstances traffic may not switch automatically.
Configuring a large number of devices may be cumbersome.

Conclusion

Policy Based Routing is a well-known and mature feature available on the majority of hardware and software routing appliances. Configuration follows the principles of an if – then programming statement and binds packet matching conditions with actions to be performed. PBR is enabled at the interface level.

Policy Based Routing allows organizations to achieve packet forwarding based not only on destination addresses. It also allows the implementation of many new applications that are out of scope in the case of traditional routing. However, PBR needs to be used wisely because it requires a static configuration (although this can be to some extent automated with an automation tool), and during some network outages, may lead to a situation where network devices will not be able to automatically recover connectivity.

Network infrastructure usage may be optimized with the help of PBR. Bandwidth usage can be maximized in a controlled way, and as a consequence, investments in network infrastructure capacity may be postponed.