Policy Based Routing / Local Policy Routing, and Route-Map configuration and explanation, review for exam day!

I will be using this Topology not as an OSPF course, but to perform Policy Based Routing (PBR) to influence how traffic travels from R5 to destination network 172.12.23.0, but first we need to review the basics of PBR:

• PBR effects packets on the Ingress interface it is configured on, not traffic generated by the router it is configured on, that is called “Local Policy Routing”
• Packets can be routed by interface, or by “next-hop” via Route-Maps
• Route-Maps must be used for PBR, so ACL’s must also be configured

Now if using an interface to “set” as an exit, it should be a non-multi access link (Point-to-Point), so the traffic isn’t being put on a Broadcast segment and reaching multiple hosts. If configuring an interface, you can define multiple interfaces in the Route-Map clause, in case the first one goes down it has a backup interface to take if specified.

If using the “set” for a next-hop ip add, you simply define the IP address to set as the next hop, and you can also have multiple next-hop’s in case one route goes down.

When it comes to doing a “match” for incoming data traffic, there are two options with PBR:

• Match on “match ip add #” where # is an ACL # defining what traffic is going to be impacted by the Route-Map
• By “match length …” where it actually matches not on Prefix Length, but on Packet length, which is a very special case use like QoS

Before going any further, to touch on this Length value being matched on, it will match on the packets length itself. This is generally used as said for QoS, as VOIP or Video packets are generally relatively small and pre-determined sizes, and the “Length” match is measured in Bytes specifically.

I just “wr er” all my routers thinking I was done with OSPF, blah, let me spin them up again quick to show these values, I’ll be leaving Area 34 completely out of this example:

R1(config-router)#do sh ip route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback1
      172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
C        172.12.15.0/24 is directly connected, FastEthernet0/1
L        172.12.15.1/32 is directly connected, FastEthernet0/1
O IA     172.12.23.0/24 [110/65] via 172.12.123.3, 00:00:48, Serial0/0/0
                        [110/65] via 172.12.123.2, 00:00:48, Serial0/0/0
C        172.12.123.0/24 is directly connected, Serial0/0/0
L        172.12.123.1/32 is directly connected, Serial0/0/0
R1(config-router)#

As can be seen, there is an equal Cost calculated by OSPF via R2 and R3 to the 172.12.23.0 /24 network, so lets run a few traceroutes from R5 to see which path is taken, if either is preferred:

R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 37 msec 32 msec 32 msec
  3 172.12.23.100 32 msec *  36 msec
R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 36 msec 33 msec 32 msec
  3 172.12.23.100 36 msec *  32 msec
R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 4 msec 0 msec 4 msec
  2 172.12.123.2 32 msec 32 msec 32 msec
  3 172.12.23.100 33 msec *  32 msec
R5#

As can be seen, R2 is the preferred route to the Switch at 172.12.23.100, so first we will configure it to prefer R3 as its next-hop to the Switch but we must first ask ourselves what the source address we want to matched on to incur this Policy.

For this I will use R5’s loopback 5.5.5.5, to confirm the inbound interface will differentiate the traffic coming from R5 as to where it sends it across the network.

So first we test 5.5.5.5 as a source for the traceroute, and get to work on R1’s config:

R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.3 36 msec 32 msec 32 msec
  3  *
    172.12.23.100 32 msec *
R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.3 36 msec 33 msec 32 msec
  3 172.12.23.100 32 msec *  32 msec

Now this is odd, I ran traceroute with source 5.5.5.5 a lot more times than on screen, but it seems to prefer the path to R3 rather than R2, however we are going to tell R1 to change its mind about that.

Before the configuration, though, I’d like to explain the steps I am about to take in order to accomplish the task of performing Policy Based Routing:

• Configuring the ACL with the source traffic address (5.5.5.5) or if your doing it by length configuring your Packet Length… however that is done
• Creating a Route-Map that matches on the ACL for source traffic defined
• Apply the route map to the Ingress interface with the “ip policy route-map …” command

So lets get some dirt under R1’s fingernails:

R1#
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 5 permit 5.5.5.5
R1(config)#route-map PBR permit 10
R1(config-route-map)#match ip add 5
R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#route-map PBR permit 20
R1(config-route-map)#int fa0/1
R1(config-if)#ip policy route-map PBR
R1(config-if)#

I didn’t think I’d get that all in one smooth config with no errors, but there is each step in order, notice I didn’t bother messing with the “permit any” on the ACL, because the Route-Map Sequence 20 is what takes precedence in this configuration, and I ended it with the catch-all clause of “Let all other traffic not matched on flow normally” at the end.

So lets see if our traffic is now hitting that Route-Map at its most basic configuration, and taking R2 as the next hop instead of R3:

R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 0 msec 4 msec
  2 172.12.123.2 32 msec 32 msec 32 msec
  3 172.12.23.100 33 msec *  33 msec
R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 36 msec 32 msec 32 msec
  3 172.12.23.100 32 msec *  32 msec

There it is, that simple!

Now I want to look at our options for matching certain criteria, if it has limits, and what those limits are (and I found the verbiage a bit odd as well) so lets check it out:

Packet Length Matches

R1(config)#route-map PBR permit 15
R1(config-route-map)#match length ?
<0-2147483647>  Minimum packet length

R1(config-route-map)#match length 100000 ?
<0-2147483647>  Maximum packet length

R1(config-route-map)#match length 100000 100000 ?
<cr>

So for Packet Length, you get one Primary and one Fallback option, and that’s it. It is not often Cisco puts its foot down on limiting backup criteria in commands, but it is obviously not a fan of matching a ton of Packet Length.

Also a very important note – It does not indicate it matches by the “byte” in the Route-Map ? output, so remember that for exam day, even though I’d really doubt it will come up on the ROUTE exam.

Interface Matches

R1(config-route-map)#match interface ?
(All interface types)

R1(config-route-map)#match interface serial 0/0/0 ?
(All interface types)

R1(config-route-map)#match interface serial 0/0/0 interface s0/0/1 ?
% Unrecognized command
R1(config-route-map)#match interface serial 0/0/0 interface ?
% Unrecognized command
R1(config-route-map)#match interface serial 0/0/0 serial 0/0/1 ?
(All interface types)

I left out the gigantic list of all interface types possible after the ?, but also left in the syntax errors I made, to demonstrate the syntax of this command. I kept going for a third interface but stopped there, so you can have up to 3+ redundant interfaces to “set” that traffic “match”ed by your PBR whereas Packet Length was limited to 2.

Next-Hop Matches

R1(config-route-map)#match ip next-hop 10.10.10.1 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#match ip next-hop 10.10.10.1 10.10.10.2 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#match ip next-hop 10.10.10.1 10.10.10.2 10.10.10.3 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#$xt-hop 10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#$xt-hop 10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4

And it continues on presumable forever, so you can set backup next-hops until you pass out from exhaustion typing right on the keyboard.

So these are the ways we “set” where our traffic goes, with one interesting command that can prepend each of them, called “default” which immediately makes me think “default route” – Lets take a look:

R1(config-route-map)#set ip ?
address     Specify IP address
default     Set default information
df          Set DF bit
global      global routing table
next-hop    Next hop address
precedence  Set precedence field
qos-group   Set QOS Group ID
tos         Set type of service field
vrf         VRF name

 

R1(config-route-map)#set default ?
interface  Default output interface

Not only are they set in slightly different ways, but they also have nothing to do with a default route, it actually refers to the default behavior of the packets transmission.

If you see “default” in the PBR route-map sequence “set” commands, that means that it is telling the Route-Map to first use the default method of routing the packet (Ask the IP Route Table where to send it) before falling back to the PBR set on the interface to tell the packet how to be routed.

Its a very special use modifier in PBR, because it defeats the purpose of Path Manipulation, but it does exist (and is configured in slightly different syntax forms) that we need to know about.

Now a couple of verification commands to verify Policy Based Routing:

• show ip policy
• show route (shows route-maps configured)
• traceroute (to verify path taken)
• debug ip policy

So I’ve demonstrated how to use the traceroute command to verify the PBR is working, however lets look at the other examples quick:

R1#sh ip policy
Interface      Route map
Fa0/1          PBR
R1#

This is saying the Fa0/1 has a PBR configuration using Route-Map PBR, so lets look at that:

R1#sh route PBR
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): 5
  Set clauses:
    ip next-hop 172.12.123.2
  Policy routing matches: 18 packets, 1080 bytes
route-map PBR, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
R1#

The red is my actual PBR configuration, while the blue is my catch-all clause on the Route-Map to allow all other traffic to route as normal.

As mentioned above, PBR only applies to Ingress traffic, however you can configure locally generated traffic on the router to do “Local Policy Routing”

Local policy routing is used for all practical purposes (at this point in my studies), for if you want to test your PBR assigned to an interface by creating a loopback on the local router, and using the “traceroute x.x.x.x source x.x.x.x” command to simulate traffic coming from that source.

It is configured with the following command in global configuration:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip local policy route-map PBR
R1(config)#int lo5
R1(config-if)#ip add 5.5.5
*May 19 23:26:26.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback5, changed state to up
R1(config-if)#ip add 5.5.5.5 255.255.255.255
R1(config-if)#^Z
R1#t
*May 19 23:26:49.287: %SYS-5-CONFIG_I: Configured from console by console
R1#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.123.2 32 msec 36 msec 32 msec
  2 172.12.23.100 32 msec *  28 msec
R1#

So that is PBR in all its glory, that is as far as I’ll go into it as I have a LOT more ground to cover, however it is simply a route-map configured to manipulate traffic, then applied to an Ingress interface receiving that traffic.

Next up, NTP, only this time with only 2 routers that are both running 15.x IOS code to get a true idea of the full list of features, as 12.x does not support NTPv4 – See you there!