CCNP Route - Path control, part 3: PBR - Policy-Based Routing and IP Service Level Agreement

The term path control has many fine shades of meaning, depending on the context.
The broadest typical use of the term refers to any and every function that influences where a router forwards a packet.
In other cases, the term path control refers to tools that influence the contents of the routing table, most typically referring to routing protocols.

Policy-Based Routing
When a packet arrives at the incoming interface of a router, the router’s data plane processing logic takes several steps to process the packet
 1) the router must check the incoming frame’s Frame Check Sequence (FCS) and discard the frame if errors occurred in transmission,
 2) If the FCS check passes, the router discards the incoming frame’s data link header and trailer, leaving the Layer 3 packet.
 3) the router does the equivalent of comparing the destination IP address of the packet with the IP routing table, matching the longest prefix route.

Note: Most routers today default to use Cisco Express Forwarding (CEF), which causes the router to match the destination of IP packets with the CEF table, instead of the IP routing table. IOS derives the CEF table from the information in the IP routing table, with much faster table lookup as compared with using the routing table directly.

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.
By default PBR is processed-switch( not CEF-switched) but you can fast-switch the PBR'd traffic which will give you better performance than process-switching.
PBR and IP-CEF doesnt work together in older IOS  (even applied correct PBR, packets matched with PBR are routed via RIB/CEF)
CEF PBR is enabled automatically
Older command can be used to manually allow fast-switched PBR (less efficient, not recommended)

PBR chooses how to forward the packet by using matching logic defined through a route map, which in turn typically refers an IP ACL and to the specific next-hop IP address or outgoing interface–for packets matched by the route map.

Route maps are complex access lists that allow some conditions to be tested against:
 - the packet  in PBR (to routed or through router) or 
 - the prefix in route-filtering (route to destination) in question using match commands.
Route-map configuration for packet and route will be different.

If the conditions match, some actions can be taken to modify attributes of the packet or route.
These actions are specified by set commands.

Basic config :
1. Define an ACL (whatever is permitted by ACL is what will be matched)
1. Create a route map with the logic to match packets, and choose the route.
2. Enable the route map for use with PBR, on an interface, for packets entering the interface (where the traffic is coming in.).

PBR work only on INCOMING DIRECTION, not outgoing.
All route maps have an implicit deny clause at the end that matches all packets not already matched by the route map. 
For packets matched by a deny clause, PBR lets the packet go through to the normal IP routing process.
Matching the Packet and Setting the Route

Route maps have the following common characteristics:
 - The default for the route-map command is permit, with a sequence-number of 10.
 - Route maps are executed in the order of the lowest sequence number to the highest. You can edit or modify maps by using the sequence number.
 - If a match is found within a route map instance, execution of further route map instances stops.
 - You can use route maps to permit or deny the information found true by the match statements.
 - If multiple match statements are called within a single route map instance, all match statements must match for the route map instance to yield a true result.
 - If route maps are applied in a policy-routing environment, packets that do not meet the match criteria are then forwarded according to the route table.
 - A route-map statement without any match statements will be considered matched.
   If there is no match statement in the route map instance, all routes and packets are matched. The set statement will apply to all routes or packets.
 - If there is not a corresponding ACL to the match statement in the route map instance, all routes are matched. The set statement, in turn, applies to all routes.
 - As with ACLs, an implicit deny is included at the end of the route map policy.

To match packets with a route map enabled for PBR:
! reference standard and extended ACLs
match ip address

!
! allows you to specify a range of lengths, in bytes
match length min max
Route-map logic example
route-map demo permit 10
    match x y z
    match a
    set b
    set c
route-map demo permit 20
    match q
    set r
route-map demo permit 30  

If {(x or y or z) and (a) match} then {set b and c}
    Else
If q matches then set r
    Else
Set nothing


When a route map clause (with a permit action) matches a packet, the set command defines the action to take regarding how to forward the packet.
!   PBR   BEFORE  ROUTING TABLE
! 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 next-hop ip-address [. . . ip-address]
!
! Forwards packets using the first interface in the list that is up.
set interface interface-type interface-number[. . . interface-type interface-number]
!
!    ROUTING TABLE   BEFORE   PBR   
! policy routing first attempts to route based on the routing table.
set ip default next-hop ip-address [. . . ip-address]
set default interface interface-type interface-number[. . . interface-type interface-number]
If the PBR route (as defined in the set command) is not working–because the outgoing interface is down or the next hop is unreachable using a connected route–then IOS next tries to route the packet using the normal destination-based IP routing process.

With default parameter: IOS matches the associated PBR route map permit clause, IOS applies the normal destination-based routing logic first, with one small exception: it ignores any default routes.

The set ip default next-hop command verifies the existence of the destination IP address in the routing table, and…
 - if the destination IP address exists, the command does not policy route the packet, but forwards the packet based on the routing table.
 - if the destination IP address does not exist, (instead of use default route or drop packet) the command policy routes the packet by sending it to the specified next hop.

The set ip next-hop command verifies the existence of the next hop specified, and…
 - if the next hop exists in the routing table, then the command policy routes the packet to the next hop.
 - if the next hop does not exist in the routing table, the command uses the normal routing table to forward the packet.

Policy-Based Routing Using the set ip default next-hop and set ip next-hop
http://www.cisco.com/c/en/us/support/docs/ip/ip-routed-protocols/47121-pbr-cmds-ce.html

Example:
PBR example: packets from PC2 (10.1.1.2) are going to dest 10.1.3.0/24 through S0/0/1, and not as routing table best through S0/0/0

R1
interface Fastethernet 0/0
ip address 10.1.1.9 255.255.255.0
ip policy route-map PC2-over-low-route
!
route-map PC2-over-low-route permit
match ip address 101
set ip next-hop 10.1.14.4
!
access-list 101 permit ip host 10.1.1.2 10.1.3.0 0.0.0.255
Verify
show route map
show ip policy
debug ip policy
traceroute
R1# show ip policy
Interface Route map
Fa0/0 PC2-over-low-route
R1# show route-map
route-map PC2-over-low-route, permit, sequence 10
Match clauses:
ip address (access-lists): 101
Set clauses:
ip next-hop 10.1.14.4
Policy routing matches: 12 packets, 720 bytes
R1# debug ip policy
*Sep 14 16:57:51.675: IP: s=10.1.1.2 (FastEthernet0/0), d=10.1.3.99, len 28, policy match
*Sep 14 16:57:51.675: IP: route map PC2-over-low-route, item 10, permit
*Sep 14 16:57:51.675: IP: s=10.1.1.2 (FastEthernet0/0), d=10.1.3.99 (Serial0/0/1), len 28, policy routed
*Sep 14 16:57:51.675: IP: FastEthernet0/0 to Serial0/0/1 10.1.14.4


PBR Recursive Next Hop
The PBR Recursive Next Hop feature enhances route maps to enable configuration of a recursive next-hop IP address that is used by policy-based routing (PBR). The recursive next-hop IP address is installed in the routing table and can be a subnet that is not directly connected. If the recursive next-hop IP address is not available, packets are routed using a default route.
Because Cisco Express Forwarding (CEF) or process switching provides the infrastructure, the benefit of this feature is the CEF load sharing.
This feature was integrated into Cisco IOS Release 12.3(14)T.

Router# show running-config | beg abccomp
route-map abccomp permit 10
 match ip address 101 ! Defines the match criteria for an access list.
  ! If the match criteria is met, the recursive IP address is set.
 set ip next-hop recursive 10.3.3.3
 set ip next-hop 10.1.1.1 10.2.2.2 10.4.4.4

Setting the Recursive Next-Hop IP Address
The infrastructure provided by CEF or process switching performs the recursion to the next-hop IP address. The configuration sequence, which affects routing, is as follows:
1. Next-hop
2. Next-hop recursive
3. Interface
4. Default next-hop
5. Default interface
If both a next-hop and a recursive next-hop IP address are present in the same route-map entry, the next-hop is used. If the next-hop is not available, the recursive next-hop is used. If the recursive next-hop is not available and no other IP address is present, the packet is routed using the default routing table; it is not dropped. If the packet is supposed to be dropped, use the set next-hop recursive command followed by a set interface null0 configuration.
Perform this task to set the IP address for the recursive next-hop router.

PBR Function for Routes manipulations
router bgp 64516
 neighbour x.x.x.x route-map Prepend out
route-map Prepend permit 10
  match ip address ACL (10.0.0.0/24)
  set as-path prepend 64516
route-map Prepend permit 20
 - route-maps used for PBR do not need a last empty clause because the implicit action in this case is normal destination based routing,
 - route-map used on a BGP session both inbound or outbound is a route filter that decides what routes can be advertised/received to/from the neighbor and allows also to perform some BGP attributes manipulation.
   In this case a last empty clause matching anything else is needed if all other routes have to be advertised/received,  because otherwise the filtering action blocks all routes not matching the previous route-map clauses.
   Also route-maps used for redistribution are route filters and have to be terminated accordingly.
  
When route-map is used for PBR: We don’t need the last command route-map pbr permit 20 to permit other traffic according to Cisco:

“If the packets do not meet any of the defined match criteria (that is, if the packets fall off the end of a route map), then those packets are routed through the normal destination-based routing process.
If it is desired not to revert to normal forwarding and to drop the packets that do not match the specified criteria, then interface Null 0 should be specified as the last interface in the list by using the set clause.”

Reference: http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800a4409.shtml
 
Additional PBR Functions
Applying PBR to Locally Created Packets
In some cases, it may be useful to use PBR to process packets generated by the router itself.

ip local policy route-map name

Setting IP Precedence
Quality of service (QoS) refers to the entire process of how the network infrastructure can choose to apply different levels of service to different packets.
For example, a router may need to keep delay and jitter (delay variation) low for VoIP and Video over IP packets, because these interactive voice and video calls only work well when the delay and jitter are held very low. So, the router might let VoIP packets bypass a long queue of data packets that might be waiting to exit an interface, giving the voice packet better (lower) delay and jitter.

Most QoS designs mark each packet with a different value inside the IP header ( all VoIP packets could be marked with a particular value so that
the router can then find those marked bits, know that the packet is a VoIP packet due to that marking, and apply QoS accordingly).

Although the most commonly used QoS marking tool today is Class-Based Marking, in the past, PBR was one of the few tools that could be used for this important QoS function of marking packets. PBR still supports marking; however, most modern QoS designs ignore PBR’s marking capabilities.
The IP header originally defined a ToS.
Back in the 1990s, the ToS byte was redefined as the Differentiated Services (DS) byte, with the first six bits defined as the Differentiated Service Code Point (DSCP). Most QoS implementations today revolve around setting the DSCP field.
set ip precedence value
set ip tos value
PBR with IP SLA

PBR can also react to some dynamic measurements of the health of the IP network. To do so, PBR relies on the IP Service-Level Agreement (IP SLA) tool

IP Service-Level Agreement

IP SLA primarily acts as a tool to test and gather data about the network.
Many network management tools support the ability to configure IP SLA from the management tools’ graphical interfaces (using IOS RTTMON MIB).
Cisco Works Internetwork Performance Monitor (IPM) - can be used to configure and monitor the data collected using IP SLA operations.

The measurement can be as simple as using the equivalent of a ping to determine if an IP address responds, or as sophisticated as measuring the jitter (delay variation) of VoIP packets that flow over a particular path.

Understanding IP SLA Concepts
IP SLA uses the concept of an operation - defines a type of packet that the router will generate, the destination and source address, and other characteristics of
the packet.
A single IP SLA operation could define the following:
■ Use ICMP echo packets.
■ Measure the end-to-end round trip response time (ICMP echo).
■ Send the packets every 5 minutes, all day long.

IP SLA has origins in earlier IOS features, including the Response Time Reporter (RTR)feature. The RTR feature uses the rtr command and uses the term probe to refer to what IP SLA refers to as an operation.

1) SLA operation sends packets to a host, the router can only use operation types that send packets that the host understands (ICMP echo requests, TCP connection requests, or even HTTP GET requests to a web server)
2) The operation can also send packets to another router, which gives IP SLA a wider range of possible operation types (configuring remote router as an IP SLA responder).
The following list summarizes the majority of the available operation types, just for perspective:
■ ICMP (echo, jitter)
■ RTP (VoIP)
■ TCP connection (establishes TCP connections)
■ UDP (echo, jitter)
■ DNS
■ DHCP
■ HTTP
■ FTP

Configuring and Verifying IP SLA
! Create IP SLA Operation
ip sla sla-ops-number
!
! Define the operation type and the parameters for that operation type
icmp-echo {destination-ipaddress | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name]
!
! (Optional) Define a (nondefault) frequency that the operation should send the packets, in seconds
frequency seconds
!
! Schedule when the SLA will run (global command)
 ip sla schedule sla-ops-number [life{forever| seconds}] [start-time{hh:mm[:ss] [month day | day month] | pending| now| afterhh:mm:ss}] [ageoutseconds] [recurring]
!
! disable and delete IP SLA Operation
no ip sla sla-ops-number
show ip sla configuration
show ip sla statistics

Example
R1 PBR tells - process packets generated by R1, including the IP SLA operation packets
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ip sla 11
R1(config-ip-sla)# icmp-echo 10.1.3.99 source-ip 10.1.1.9
R1(config-ip-sla)# frequency 60
R1(config-ip-sla)# exit
R1(config)# ip sla schedule 11 start-time now life forever
! Changes to the PBR configuration below
R1(config)# access-list 101 permit ip host 10.1.1.9 host 10.1.3.99
R1(config)# ip local policy PC2-over-low-route
R1(config)# end
Tracking SLA Operations to Influence Routing

You can configure both static routes and PBR to be used only when an SLA operation remains successful.
The configuration to achieve this logic requires the configuration of a tracking object and cross references between the static route, PBR, and IP SLA.
STATIC ROUTE   --->   Tracking OBJECT    <------  PBR
                      (SLA Operation)
The tracking object looks at the IP SLA operation’s most recent return code to then determine the tracking state as either “up” or “down.”
Depending on the type of SLA operation, the return code may be a simple toggle, with “OK” meaning that the last operation worked.
One of the main reasons that IOS requires the use of this tracking object is so that the routes do not flap.
Route flapping - when a router adds a route to the routing table, then quickly removes it; conditions change, so the router soon adds the route to the table
again; and so on

Configuring a Static Route to Track an IP SLA Operation
track <object-number> ip sla <sla-ops-number> [state | reachability]
! (Optional)  Configure the delay to regulate flapping of the tracking state
delay {down seconds| up seconds}
ip route destination mask{interface | next-hop} track <object-number>
show track
!
track 2 ip sla 11 state
delay up 90 down 90
ip route 10.1.234.0 255.255.255.0 s0/0/1 track 2

Configuring PBR to Track an IP SLA
When the tracking object is up, PBR works as configured. When the tracking object is down, PBR acts as if the set command does not exist.
That means that the router will still attempt to route the packet per the normal destination-based routing process.
set ip next-hop 10.1.14.4
set ip next-hop verify-availability 10.1.14.4 1 track 2