Policy-Based Routing (PBR) Explained

Policy-based routing (PBR) does for networking one of the things that the postal service does for the real world. Imagine you're sending a package across the country: it passes through your local post office, an airport, a truck stop, and finally a national hub. And from there, another airport, another truck stop, the recipient's local post office, and then to their door.

But what if you're sending a letter to an address in your own city?

If the mail went from you all the way through the post office, airport, truck stop and to the national hub every time, it'd be a pretty obvious failure and waste. Network traffic can sometimes be inefficient in the same way. Fortunately there's policy-based routing. Learning policy-based routing helps you maximize your network's efficiency by changing paths based on traffic metadata.

What is Policy-Based Routing?

Quick definition: Also known as PBR, policy-based routing is a technique used in computer networks for forwarding and routing data according to pre-written policies or filters. Many different parameters can be used to choose what packets get special treatment — parameters like source and destination IP address or ports, traffic type, what protocol is used, and more. Packets get routed according to predefined routes based on what filters apply.

An Overview of Policy-Based Routing [VIDEO]

In this video, Keith Barker covers the introduction, configuration, and verification of policy based routing on a Cisco router. This is all about having special types of routing for certain types of traffic. PBR gives you the ability to override the default behavior of the routing table.

When to Use Policy-Based Routing?

Policy-based routing is ideal for overriding the default behavior of a routing table. When default protocols or metrics send packets through an inefficient or just undesirable path, PBR lets us divert traffic to a route that's more desirable.

For this post, we'll be talking about policy-based routing on a Cisco IOS router. The Cisco Internetwork Operating System (IOS) is a family of Cisco OSs that run on their switches and routers, and enabling, configuring and verifying PBR on IOS is quite easy.

To prepare for our PBR configuration, we should start with imagining a network topology. Admittedly, that can be tricky in a written medium, but try to envision a network that has about ten routers and switches. Like any sizable network, they don't each connect to one another, and they're not daisy-chained together — some are hubs, others need a frame relay network to get inside access, and others are endpoints.

Let's call our destination device "R1" and our source router we'll call "R7". And just because we can, let's also say that R1's loopback is 1.1.1.1 and R7's is 7.7.7.7.

• R7 starts its journey by transiting the frame relay network that separates it from the rest of the network and winds up at R4.

• R4's default behavior is to send traffic coming in through its serial 1/1.478 sub-interface toward R5. (That decision is based on routing protocol and metrics that are in place.)

• R5 shoots the traffic to R3.

• R3 forwards traffic to its final destination of R1.

Now, it's important to note that in our set-up, a serial connection does exist between R4 and R3. Despite that connection, the protocol in place sends traffic to R5 regardless of the fact that its destination is R3.

Policy-based routing gives us the control we need to override the default behavior of our routing table. In our example, we could instruct R4 that if traffic is sourced from the IP address 7.7.7.7 and it's coming in on the serial 1.478 interface, to use R3 as the next hop for that specific packet, instead of the traditional next hop of R5 based on the routing table.

How to Implement Policy-Based Routing

Implementing policy-based routing takes three things: an access control list, a route map, and applying those two to the relevant interface(s). Let's take a look at each of those three things:

1. We'll need an ACL that identifies what traffic should receive the policy-based routing.

2. A route map is also necessary. A route map is essentially a big if/then statement. It's written in a way that says, "if traffic matches this access control list which is identifying our traffic-of-interest for PBR, then change your behavior in processing it." In our case, that special treatment is to make R3 the next hop for the traffic.

3. Applying our route map and policy is done with an IP policy command. We apply the route map to the interface on which we want the router to inspect the incoming traffic. Applying the route map and policy to the interface means the override happens right where the decision gets made about how traffic should be dealt with.

Next, we'll actually walk through the necessary steps for implementing policy-based routing. We're going to write out the actual commands to use in the consoles of each router. Although your router designations and addresses would be different from ours, it can help understand the process if you can follow along on your own virtualized network. We'll write out each command you'll need.

We'll be targeting any traffic sourced from 7.7.7.7 (R7's loopback), if it's coming in on serial 1/1.478 sub-interface. If we see that traffic, we want to set R3 as the next hop.

Like we said above, the first step is to identify that interesting traffic by creating an Access Control List (ACL). We'll head into configuration mode. Start by accessing R7's console, then type:

conf t

We want to find out if we have any access lists currently in place. It wouldn't do to accidentally add on to an existing one:

do show access-list

This should reveal that there are no access lists in place. So we'll create a single entry that will match any IP traffic sourced from 7.7.7.7 going anywhere:

access-list 100 permit ip host 7.7.7.7 any

For our purposes, that defines what we're considering "interesting" traffic that we're going to use as a part of PBR. Next, we'll create a route map called PBR:

route-map PBR

Notice that your command line changes to reflect where you're now writing. Next, we have an "if/then" statement to construct. For the "if" portion of this route-map, we say we're looking to match IP address 100:

match IP address 100

Translated, this means we're looking for traffic that matches "access-list 100". And if we find that traffic, the "then" portion, we want to set the IP next hop to 10.34.0.3:

set ip next-hop 10.34.0.3

For our network, 10.34.0.3 is R3, the next hop. Instituting this rule will cause the traffic to be forwarded over the serial link to R3 from R4, instead of the normal path to R5. Leave this configuration:

exit

We've written the rules we need, and now the final step would be to apply this to the interface. For our purposes, we'll need to apply it to R4's serial 1/1.478. However, before we do, let's verify the default path that would normally be used.

To trace the route that our data takes through our pre-PBR'd topology, we'll head over to R7, where we'll do a quick traceroute to 1.1.1.1:

traceroute 1.1.1.1

In our network setup, each routers' last octet matches the router number. So the results of this traceroute should show R4 > R5 > R3 > R1. What your network shows you at this stage is obviously dependent on your particular arrangement. For us, the 1.1.1.1 address is the loopback that's hanging off of R1.

Next, we'll take that same traceroute and source it from our own loopback on R7 of 7.7.7.7:

traceroute 1.1.1.1 source 7.7.7.7

For now, this shouldn't show any difference than the previous one. That's because the route to the 1.1.1.1 network hasn't been changed. We just want to make sure we confirm that we're still going through R5 on the way from R4 to R3.

Now that we know what our default traffic state is, let's implement the PBR back on R4. Head back to R4 and type:

do show access-list

Note: we include "do" because we're in config mode.

This should display our current access list, 100. If we wanted to look at our current route maps, including the one we just configured, we could type:

show route-map

The final, third piece is to go directly into the sub-interface we'll be applying that ACL onto. To access serial 1/1.478, type:

int ser 1/1.478

Next, we'll use the command "IP Policy", along with the keyword "route-map", plus the name of the route-map that we just created:

ip policy route-map PBR

With that, PBR is now effective for any traffic that's coming in on that serial 1/1.478 sub-interface. Say we wanted to verify our policy? We could type:

show ip policy

This Show IP Policy command shows us, in our hypothetical example at least, that we've got one interface ("Serial 1/1.478") with one Route map ("PBR") applied. We wrote that just now, so we know that it means that any inbound packets are going to be considered and compared against that route map.

Another useful command when you're working with PBR is the Debug of IP Policy, so let's turn that on over on R4:

debug ip policy

With that activated, we'll see the details regarding packets. Are they going to be routed normally or do they match the ACL in the route-map, and are they going to be policy-based route-ed? It'll give us all that detail.

To test it though, we'll need to head back over to R7. On R7, we'll again do a traceroute to 1.1.1.1

traceroute 1.1.1.1

For those of you keeping score at home, you'll recognize that this traffic is not being sourced from 7.7.7.7. and so it should not be matching our policy map. As a result, this traceroute should be no different than one what we got above: R4 > R5 > R3 > R1.

A cool thing we could do is go back to R4's console, where debug is running, to see the traffic that was sourced from 10.4.78.7 (that's the serial interface of R7). If we go there, we'll see that the destination address was 1.1.1.1, and the policy was rejected. That sounds bad, but it simply means it didn't match the policy-based routing, and as a result of not matching the policy, it was forwarded normally.

However, we'll go back to R7, and this time do a traceroute and source it from 7.7.7.7, the loopback serial address on R7:

traceroute 1.1.1.1 source 7.7.7.7

What that does is trigger policy-based routing and sets the next hop to R3 from R4. In this demonstration, that's a minor change to our path through the network, but you can imagine how a deviation like that on a larger network, or one that sees diversified traffic, could improve efficiency and speed significantly.

If we look at the path the traffic did take, we see that it went from R7 to R4, where R4 made the decision based on PBR to send it to R3. Once at R3, the traffic continued its normal path: over to R1.

If you're feeling the need to verify what happened, we can go back to the console of R4. With the debug still running, we should see that the policy was matched. That means policy-based routing moved the packets through the router and caused that next hop to be R3. In our case, that meant the traffic took a serial path instead of its normal path.

Wrapping Up

Policy-based routing is one of the many tools in any network administrator's toolkit. With it, you can divert traffic of a certain size, from a specified IP address, from certain types of devices, or any other set of specifications. That diversion can be for speed, efficiency, or just because you felt like it.

Configuring policy-based routing on larger networks can be much more complicated, which is why CBT Nuggets' CCNP Routing training is your best bet for understanding all the ins and outs of changing the default behavior of network devices with PBR.