Influencing Forwarding Behavior with Policy Based Routing

It had been a hot minute since I last put together a blog, and I was thinking about what might be an interesting topic. Well, as is typical, I thought about what I’d recently run across, or worked on, in my “day job” as part of the engineering team that builds and supports the lab environments for all the Learning at Cisco training materials.

On this particular day, I was reviewing the current configurations of the core network routers (layer 3 switches really) in our data centers. I’m fairly new to this part of the team, and I was interested to discover that we were leveraging Policy Based Routing to manipulate the forwarding behavior for different types of traffic. I’m sure many of you reading this blog are familiar with the fact that there are always several ways to accomplish a task in networking (life really, but definitely in networking). As such, policy-based routing is a tool in the network engineer’s toolkit that can often be leveraged to handle “odd business requirements.”

And with that, I had a topic to use for this blog and an accompanying video to kick off a short video series called “Technically Speaking… with Hank Preston” on the Cisco U. by Learning and Certifications YouTube channel. Specifically, we are going to look at how to configure policy-based routing to influence forwarding behavior. The why I’ll leave for another post. 🙂

Also, for anyone studying for the CCNP Enterprise certification, policy-based routing is on the ENARSI – Implementing Cisco Enterprise Advanced Routing and Services blueprint – “1.6 Configure and verify policy-based routing.” 300-410 ENARSI is a concentration exam that earns you the Cisco Certified Specialist – Enterprise Advanced Infrastructure Implementation certification.  So, it’s definitely a great topic for the Cisco Learning blog. Let’s dive right in!

Setting the Stage

Before we look at changing the typical routing and forwarding behavior, let’s start with the basic forwarding behavior. For this exploration, I put the below network together in a Cisco Modeling Labs simulation. (You can find the topology file here.)

This network has two small LANs separated by a basic, single area OSPF network in the middle. The costs in the OSPF network have been configured to make the best path from R1 to R5 through R3. We can see that in a couple ways.

First, let’s look at the interface costs on R1.

R1#show ip ospf interface brief 

Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Gi0/1.200    1     0               192.168.200.1/24   1     DR    0/0
Gi0/1.100    1     0               192.168.100.1/24   1     DR    0/0
Gi0/4        1     0               10.14.14.1/24      110   DR    1/1
Gi0/3        1     0               10.13.13.1/24      1     DR    1/1
Gi0/2        1     0               10.12.12.1/24      100   DR    1/1

Notice the costs for interface G0/2 and G0/4 (towards R2 and R4) have a cost of 100 and 110 respectively, while the cost of G0/3 (towards R3) is only 1.

And now, we’ll verify the routing table entry for host H3 on R1.

R1#show ip route 172.16.10.11   

Routing entry for 172.16.10.0/24
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 10.13.13.3 on GigabitEthernet0/3, 00:23:02 ago
  Routing Descriptor Blocks:
  * 10.13.13.3, from 5.5.5.5, 00:23:02 ago, via GigabitEthernet0/3
      Route metric is 3, traffic share count is 1

The routing table lists the route as towards R3 out interface G0/3 — exactly as we’d expect.

The final check will be a trace route from host H1.

H1:~$ traceroute -n 172.16.10.11

traceroute to 172.16.10.11 (172.16.10.11), 30 hops max, 46 byte packets
 1  192.168.100.1   5.534 ms  5.004 ms  3.038 ms
 2  10.13.13.3      5.528 ms  5.531 ms  4.137 ms       <- R3's G0/1 interface
 3  10.35.35.5      5.533 ms  5.656 ms  6.339 ms
 4  172.16.10.11   14.180 ms  9.787 ms  7.908 ms

And no big shocker here, the second hop in the trace is indeed R3.

Let’s shake things up a little bit.

Suppose there was some reason that you wanted to direct traffic received at router R1 from host H1 destined for H3 to pass through R2 . Maybe there was some traffic analysis that happened on that router. Or perhaps that link is more reliable, even if slower. There are any number of reasons this might come up in a network design. The key part is that you don’t want to change ALL forwarding behavior, just some of it. You have a “policy,” so to speak, that identifies some traffic you want to adjust. This is where policy based routing, often referred to as PBR, comes in.

Policy based routing can seem complicated. To be fair, if overused, it can make networks very complicated and hard to maintain. However, the technical basics of PBR are pretty straightforward.

First, you need a way to identify the traffic that you want to apply the policy to. Like many “matching” use cases in networking, this is often done with an access-list. So, here’s the access list that I’ll use to match the traffic I’m interested in.

ip access-list extended H1-to-H3
  10 permit ip host 192.168.100.11 host 172.16.10.11

This single line extended ACL is all that is needed. I’m matching all IP traffic from H1 to H3, but I could be more specific, to a specific port as well. Maybe just web traffic (tcp/80 & tcp/443) as an example.

Next, a route-map is used to describe the policy that we want to configure. The “policy” is made up of “match” conditions to identify the traffic and “set” conditions to make the “policy based changes” to the traffic that was matched.

Here is the route-map for my policy example.

route-map POLICY-BASED-ROUTING permit 10
  description Traffic from H1 -> H3 route through R2
  match ip address H1-to-H3
  set ip next-hop 10.12.12.2

I’ve used the access-list I created in my “match ip address” command. And, I’ve indicated that when traffic “matches” this policy, I want to “set” the next-hop to be 10.12.12.2.

And notice the first line in the configuration example. It ends with the number “10.” This number identifies the position in the route map that this particular policy entry holds.  A route-map can be made up of many policy sets – each with a “match” and “set” statement.  In this way, network engineers can have very granular control over how traffic is forwarded in the network.  Pretty handy right!

Before I go much farther it is definitely important to note that route-maps are used for more than just policy based routing.  The route-map construct is also used as part of quality of service (QoS) configurations, routing protocol filtering, and BGP path manipulations.  So if you explore the configuration options available for match and set you will find several other options.  Most of these are used for use cases other than policy based routing.

The last step to complete the configuration of my policy is to apply it to the router interface. Since this policy is about controlling traffic from the LAN connected to interface Gig0/1 on R1, that is where I will apply it.

interface Gig0/1.100
  ip policy route-map POLICY-BASED-ROUTING

That’s it, we’ve configured policy based routing. Let’s test to see if it’s working.

We’ll start by rerunning the same trace route command as before and comparing the results.

1:~$ traceroute -n 172.16.10.11

traceroute to 172.16.10.11 (172.16.10.11), 30 hops max, 46 byte packets
 1  192.168.100.1  7.306 ms  3.017 ms  3.337 ms
 2  10.12.12.2     3.844 ms  4.335 ms  3.688 ms      <- R2's G0/1 interface
 3  10.25.25.5     7.906 ms  5.125 ms  5.962 ms
 4  172.16.10.11   8.951 ms  8.912 ms  7.348 ms

Look at that, traffic is indeed going through R2 now. But let’s verify that it is just for traffic to H3 by trace routing the traffic to H4.

H1:~$ traceroute -n 172.16.10.21

traceroute to 172.16.10.21 (172.16.10.21), 30 hops max, 46 byte packets
 1  192.168.100.1  3.681 ms  3.153 ms  2.563 ms
 2  10.13.13.3     3.613 ms  3.185 ms  3.747 ms     <- R3's G0/1 interface
 3  10.35.35.5     5.957 ms  7.555 ms  5.040 ms
 4  172.16.10.21  14.915 ms  7.157 ms  7.853 ms

Yep, traffic from H1 to H4 is indeed still following the “standard path” through R3. But what about traffic from H2 -> H3?  Will it be redirected through R2?

H2:~$ traceroute -n 172.16.10.11

traceroute to 172.16.10.11 (172.16.10.11), 30 hops max, 46 byte packets
 1  192.168.200.1  7.284 ms  2.840 ms  3.173 ms
 2  10.13.13.3     3.526 ms  4.514 ms  3.498 ms    <- R3's G0/1 interface
 3  10.35.35.5     6.375 ms  7.212 ms  4.900 ms
 4  172.16.10.11   6.642 ms  6.270 ms  5.884 ms

Nope, only traffic from H1 -> H3 is being redirected.

If we look at the routing table on R1, we’ll see nothing has changed.

R1#show ip route 172.16.10.11   

Routing entry for 172.16.10.0/24
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 10.13.13.3 on GigabitEthernet0/3, 00:23:02 ago
  Routing Descriptor Blocks:
  * 10.13.13.3, from 5.5.5.5, 00:23:02 ago, via GigabitEthernet0/3
      Route metric is 3, traffic share count is 1

There are a few useful commands on the router to check the status of policy based routing.

First up, a basic “show” command worth noting.

R1#show route-map 

route-map POLICY-BASED-ROUTING, permit, sequence 10
  Match clauses:
    ip address (access-lists): H1-to-H3 
  Set clauses:
    ip next-hop 10.12.12.2
  Policy routing matches: 12 packets, 756 bytes

This command provides “policy match” statistics. We can see that when I ran this command there were 12 matches so far.

Another command that is useful is the “debug ip policy” command. It provides useful details about the processing of the policy as traffic flows through the router. But as with any “debug” command, be careful using it on a production device as it can put a heavy load on network devices if there is a lot of traffic flowing through.

I will turn on the debugging and then send a single ICMP (ping) packet from H1 -> H3.

R1#debug ip policy
Policy routing debugging is on

R1#
*Apr 26 00:29:58.282: IP: s=192.168.100.11 (GigabitEthernet0/1.100), d=172.16.10.11, len 84, FIB policy match
*Apr 26 00:29:58.282: IP: s=192.168.100.11 (GigabitEthernet0/1.100), d=172.16.10.11, len 84, PBR Counted
*Apr 26 00:29:58.282: IP: s=192.168.100.11 (GigabitEthernet0/1.100), d=172.16.10.11, g=10.12.12.2, len 84, FIB policy routed

Compare the above output to the debug output when I ping H1 -> H4.

*Apr 26 00:31:00.294: IP: s=192.168.100.11 (GigabitEthernet0/1.100), d=172.16.10.21, len 84, FIB policy rejected(no match) - normal forwarding

In the first example, “FIB policy match” indicates that the PRB policy was triggered. And a following debug line shows that the traffic was “FIB policy routed.” That’s the PBR in action. Compare that to the output from the second ping that is “FIB policy rejected (no match) – normal forwarding.” That output is pretty descriptive.

And with that, we’ve come to the end of this post. I hope this short look at policy based routing helped break it down and introduce you to a new technology tool that you can put into your toolkit. Maybe it’ll help you solve a business challenge someday. Or maybe it’ll help you in your preparation for the ENARSI exam or other studies. Either way, thanks for hanging out with me today.

 Got a topic you’d like me to breakdown? Let me know in the comments.

Resources

Join the Cisco Learning Network today for free.

Follow Cisco Learning & Certifications

Twitter | Facebook | LinkedIn | Instagram | YouTube

Use #CiscoCert to join the conversation.

Share: