CCNP ROUTE: 6. Policy-Based Routing (PBR)

Policy-Based Routing (PBR) overrides the router’s natural destination-based forwarding logic.
PBR intercepts the packet after de-encapsulation on the incoming interface, before the router performs the CEF table lookup. PBR then chooses how to forward the packet using criteria other than the usual matching of the packet’s destination address with the CEF table.

To enable PBR, the engineer configures two general steps:
Step 1. Create a route map with the logic to match packets, and choose the route.
Step 2. Enable the route map for use with PBR, on an interface, for packets entering the interface.

We have two match command options to use:
- match ip address
- match length min max

The match ip address command uses the same familiar logic as for route maps.
The match length command allows you to specify a range of lengths, in bytes.

Then we have the the set command, which defines the action to take regarding how to forward the packet:

set ip next-hop ip-address[. . . ip-address] - Next-hop addresses must be in a connected subnet; forwards to the first address in the list for which the associated interface is up.
set ip default next-hop ip-address[. . . ip-address] - Same logic as previous command, except policy routing first attempts to route based on the routing table.
set interface interface-type interface-number [. . . interface-type interface-number] - Forwards packets using the first interface in the list that is up.
set default interface interface-type interface-number [. . . interface-type interface-number] - Same logic as previous command, except policy routing first attempts to route based on the routing table.

Let's consider router R7 trying to reach R4's Serial0/2 IP address 172.16.0.13 (subnet between R4 and R5):

R7#traceroute 172.16.0.13

Type escape sequence to abort.
Tracing the route to 172.16.0.13

  1 172.16.0.9 40 msec 0 msec 12 msec
  2 172.16.0.6 52 msec 28 msec 8 msec
  3 172.16.0.13 88 msec *  20 msec

From the traceroute above, we conclude that the chosen path is R7-R6-R5-R4, due to the higher bandwidth of the R6-R5 link.

If for any reason we don't want R7's packets to go through the FastEthernet link, we can configure PBR on R6's Serial0/1 interface and redirect the traffic coming from R7 to R4.

R6(config)#ip access-list extended 100
R6(config-ext-nacl)#permit ip host 172.16.0.10 172.16.0.12 0.0.0.3

R6(config)#route-map filterR7-to-R4 permit 
R6(config-route-map)#match ip address 100
R6(config-route-map)#set ip next-hop 172.16.0.2

R6(config)#interface serial 0/1
R6(config-if)#ip policy route-map filterR7-to-R4 

R6#show ip policy
Interface      Route map
Serial0/1      filterR7-to-R4

R6#show route-map
route-map filterR7-to-R4, permit, sequence 10
  Match clauses:
    ip address (access-lists): 100
  Set clauses:
    ip next-hop 172.16.0.2
  Policy routing matches: 3 packets, 96 bytes

Now, trying the same traceroute from before, we can see that now the path through R4 is chosen, as expected:

R7#traceroute 172.16.0.13

Type escape sequence to abort.
Tracing the route to 172.16.0.13

  1 172.16.0.9 64 msec 32 msec 8 msec
  2 172.16.0.2 12 msec *  32 msec

The route-map clause uses a permit action, which tells IOS to indeed apply PBR logic to these matched packets.
Had the route-map command listed a deny action, IOS would simply route the packet as normal (through the normal IP routing process) – it would NOT FILTER the packet.

Note: The "default" keyword - This parameter in effect tells IOS whether to apply PBR logic before trying to use normal destination-based routing (without the keyword), or whether to first try to use the normal destination-based routing (with the keyword), relying on PBR’s logic only if the destination-based routing logic fails to match a nondefault route.