It’s already no secret that organizations differ in terms of governance policies and regulations. An organization may need to route 3rd party vendor traffic for instance via a T1 to reach specific destinations as opposed to a default path. PBR provides us with the ability to implement packet forwarding and routing via a specific next hop address based on a matched criteria. We will be using the following topology to demonstrate how to implement PBR.

All IP addresses are pre-configured as well as EIGRP for dynamic routing. Notice here that we have 2 Serial interfaces and a Fastethernet interface connected to RouteLeak-Core. By just looking at the diagram and factoring EIGRP path selection criteria, we can right off the bat conclude that loopback 99.99.99.99 is going to be primarily reachable from RouteLeak-HQ via the Fastethernet link. But let’s not just assume even if we are sure. Let’s check the routing table of RouteLeak-Core for the prefix 99.99.99.99/32…

Here, we can clearly see that our assumption is correct. Traffic to the loopback prefix at the remote office prefers the path towards Fa1/0 first. If for whatever reason Fa1/0 goes down, traffic is then load balanced between the serial interfaces from the core perspective. Let’s see that in action so at least we have a baseline of the current traffic flow before we make any changes. Let’s shut Fa1/0 on Transit 1…

Let’s run a traceroute from the core to the loopback prefix…

Good ! You can see here the traffic load balancing. Now that we have a baseline of how the network works, let’s unshut the interface and make some changes !

Notice on the diagram that we have a couple of loopback prefixes on RouteLeak-HQ. Our goal here is to:

1) Traffic sourcing from loopack11 at the HeadQuarter will be sent towards Ser2/0 to 99.99.99.99/32
2) Traffic sourcing from loopack12 at the HeadQuarter will be sent towards Ser2/1 to 99.99.99.99/32
3) Traffic sourcing from loopack13 will take the best path based on the IP routing table

All right ! We will be using a route-map instance to accomplish this. Understanding route-maps and how they works is fundamental in Network Engineering. This is one of the most powerful configuration option Cisco IOS has to offer.

Some of the most common ways you can use route-maps are:

Policy Based Routing
Route Filtering
Prefix Tagging and Route Metric assignment
Route Control

If you are familiar with the “If then else” analogy, then you’d quickly find that it is fairly similar. IF a certain condition is true, THEN perform a specific action.

Let’s see it in action. First we will need ACLs to match the prefixes…

Here we have used extended ACLs to match the prefixes. Note that we’ve specifically enumerated the destination address in the ACLs. Let’s configure our route-map and match on the ACLs…

The term “RouteLeak-PBR” is arbitrary and it reference the route-map. It is called a map name and it used to call the route-map. Notice that we have several options here such as matching on a BGP AS path or a community list or even an interface. But in our case, we will match on the ACL defined and for that purpose, we used the command “match ip address AclNameOrNumber“. Let’s now set an action for traffic sourcing from Loopback 11…

Note also here how we have several options with the “set” command. But in our case, we will just set the next hop to be the ip address interfacing with Serial2/0. Remember, we wanted traffic sourcing from 11.11.11.11/32 to be sent via Ser2/0 to 99.99.99.99/32.

We’ve successfully matched loopback 11 prefix under the route-map instance with the “match” command and we’ve instructed the router to forward incoming traffic from Lo11 to the next hop address peering with ser2/0. Let’s finish configuring our route-map in relation to loopback 12 and loopback 13 based on our requirement…

Here we have used the same route-map but with different sequence number. Noticed how we did not specify the sequence number in our initial route-map ? By default, the IOS added the sequence number for us (10). So, on sequence 20 we are matching ACL112 and set the next-hop address to be the prefix peering with Ser2/1. On sequence 30, we are matching on ACL 113 and since we did not set an action here, the IP routing table will be leveraged to forward the packets.

It is important to know that if for instance no matching statement is configured, then everything is matched by default. In that sense, we could have also NOT configure a matching statement on sequence 30 and it would have still worked because the policy would match on everything else and ACL 113 is part of everything else.

Also note that route-maps are similar to ACLs in a sense where there is an implicit deny at the end.

Our next-step now is to apply the policy command on the egress interface of the core router. Let’ do that…

The command is “ip policy route-map MapTag“. The policy command instructs the router to call on the route-map and see if there is a match or not. Based on the match clause, actions are taken as configured.

Let’s now test…

Great ! We can clearly see here that our requirements are fulfilled.

Traffic from loopback 11 are routed through Ser2/0
Traffic from loopback 12 are routed through Ser2/1
Traffic from loopback 13 are routed through the best path

The output of the command “show route-map” provides useful information in terms of policy matches and the configuration details of the Policy itself. Let’s do that…

Quick Tips: If the policy is configured on the same router where the traffic is originating from, the command “ip local policy route-map MapTag” is needed to enable local policy routing.

That’s all I have today. Thank you for checking in !