11.1 Policy-Based Routing (PBR) & Route Maps

11.1 Policy-Based Routing (PBR) & Route Maps

Standard IP packet forwarding relies strictly on destination-based routing. When a router receives an IP packet, the forwarding engine queries the Forwarding Information Base (FIB) to identify the longest prefix match for the packet's destination IP address. While this destination-driven model is scalable and deterministic, modern enterprise architectures require granular traffic steering based on source identity, application protocol, packet length, or quality of service (QoS) classification.

Policy-Based Routing (PBR) empowers network engineers to bypass or modify the standard destination routing table lookup. By leveraging the flexible route-map construct, PBR enables deterministic path selection, multi-homed ISP link steering, security service chaining, and selective QoS marking at the network edge.

+-----------------------------------------------------------------------------------+
|              DESTINATION-BASED ROUTING VS. POLICY-BASED ROUTING (PBR)             |
+-----------------------------------------------------------------------------------+
|  DESTINATION-BASED ROUTING (FIB / RIB):                                           |
|  - Inspects ONLY the Destination IP address.                                      |
|  - All traffic destined for Subnet X follows the exact same path.                 |
|  - Source IP, port number, application, and packet size are ignored.              |
|                                                                                   |
|  POLICY-BASED ROUTING (PBR / Route-Map):                                          |
|  - Inspects Source IP, Destination IP, Protocol, Layer 4 Port, Packet Length, etc.|
|  - Traffic from Host A to Subnet X can take Link 1; Host B to Subnet X takes Link 2.|
|  - Overrides or complements standard FIB lookups before forwarding.               |
|  - Hardware accelerated via Cisco Express Forwarding (CEF) TCAM entries.          |
+-----------------------------------------------------------------------------------+

1. Control Plane vs. Data Plane Routing Override Mechanics

To understand PBR, one must examine how PBR interacts with the router's control plane (Routing Information Base / RIB) and data plane (Forwarding Information Base / FIB).

+-----------------------------------------------------------------------------------+
|                       PBR PACKET FORWARDING PIPELINE                              |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|   Incoming Packet Arrives on Ingress Interface (e.g., Gi0/0/1)                    |
|                               |                                                   |
|                               v                                                   |
|              +----------------------------------+                                 |
|              | Is Interface PBR Configured?     |                                 |
|              | ('ip policy route-map <NAME>')   |                                 |
|              +----------------------------------+                                 |
|                             /    \                                                |
|                       YES  /      \  NO                                           |
|                           v        v                                              |
|       +-----------------------+   +------------------------------------+          |
|       | Evaluate Route-Map    |   | Standard CEF FIB Lookup            |          |
|       | Sequences (Match ACL) |   | (Longest Prefix Match on Dest IP)  |          |
|       +-----------------------+   +------------------------------------+          |
|                 /    \                                |                           |
|         MATCH  /      \ NO MATCH (Implicit Deny)      |                           |
|               v        +----------------------------->|                           |
|   +-----------------------+                           |                           |
|   | Execute SET Action    |                           v                           |
|   | - set ip next-hop     |                 +--------------------+                |
|   | - set ip dscp         |                 | Forward Packet via |                |
|   | - set interface       |                 | Normal FIB Next-Hop|                |
|   +-----------------------+                 +--------------------+                |
|               |                                                                   |
|               v                                                                   |
|   +-----------------------+                                                       |
|   | Forward Packet to     |                                                       |
|   | Policy-Specified Hop  |                                                       |
|   +-----------------------+                                                       |
|                                                                                   |
+-----------------------------------------------------------------------------------+

CEF-Based PBR Acceleration

In legacy architectures, policy routing forced the router to divert matching packets to the central CPU for process switching, resulting in high processor utilization and reduced throughput. In modern Cisco IOS and IOS-XE platforms, Cisco Express Forwarding (CEF) natively accelerates PBR in hardware ASICs:

• Route-map rules, Access Control Lists (ACLs), and next-hop rewrites are compiled directly into the hardware Ternary Content-Addressable Memory (TCAM) tables.
• Packets matching PBR policies are switched at wire speed (line rate) without CPU intervention.
• If a policy specifies an unresolvable next-hop or an unsupported feature, the packet gracefully falls back to standard CEF destination switching or CPU punt.

2. Route-Map Architecture & Evaluation Logic

A route-map is a programmable control structure composed of numbered sequence clauses. Route-maps evaluate incoming data or control packets top-down, executing matching criteria and applying transformation or steering actions.

route-map MAP_NAME {permit | deny} [sequence-number]
 match <condition_1>
 match <condition_2>
 set <action_1>
 set <action_2>

+-----------------------------------------------------------------------------------+
|                         ROUTE-MAP LOGICAL ANATOMY                                 |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  route-map PBR_POLICY permit 10                                                   |
|   match ip address ACL_CRITICAL_TRAFFIC       <--- Match Criteria (AND / OR)     |
|   match length 64 1500                        <--- Additional Match Criteria      |
|   set ip next-hop 192.0.2.1                   <--- Policy Action (Set Next-Hop)   |
|   set ip dscp ef                              <--- Policy Action (QoS Marking)    |
|  !                                                                                |
|  route-map PBR_POLICY deny 20                                                     |
|   match ip address ACL_MANAGEMENT             <--- Bypass Policy / Normal FIB     |
|  !                                                                                |
|  route-map PBR_POLICY permit 30                                                   |
|   match ip address ACL_GENERAL_USERS                                              |
|   set ip default next-hop 198.51.100.1                                            |
|  !                                                                                |
|  < IMPLICIT DENY AT END >                     <--- Unmatched falls to Normal FIB  |
|                                                                                   |
+-----------------------------------------------------------------------------------+

Sequence Numbers & Processing Order

• Route-map clauses are processed in ascending numerical order based on their sequence number (e.g., sequence 10, then 20, then 30).
• As soon as a packet matches a sequence clause, processing stops (first match wins), and the associated set actions are applied.
• If no match occurs in a clause, evaluation immediately proceeds to the next sequence number.
• Best practice dictates numbering sequences in steps of 10 (10, 20, 30...) to allow future insertion of rules without renumbering existing configurations.

Match Statements: Boolean AND vs. Boolean OR Logic

Understanding how Cisco IOS evaluates multiple match commands within a single route-map sequence clause is critical:

1. Horizontal Match (Same Line = Boolean OR):

   • When multiple parameters or ACLs are listed on the same match line, IOS evaluates them using logical OR.
   • Example: match ip address 101 102 $\to$ Matches if the packet is permitted by ACL 101 OR ACL 102.

2. Vertical Match (Multiple Lines = Boolean AND):

   • When multiple match commands appear on separate lines within the same sequence clause, IOS evaluates them using logical AND.
   • Example:

     route-map STEERING permit 10
      match ip address ACL_FINANCE
      match length 128 1024
     

     $\to$ The packet must match ACL_FINANCE AND its IP packet length must be between 128 and 1024 bytes. If either condition fails, sequence 10 is skipped.

Permit vs. Deny Semantics in Policy-Based Routing

In standard route filtering (e.g., route redistribution or BGP policy), permit allows a route and deny drops/filters the route. In Policy-Based Routing (PBR), permit and deny have distinct forwarding behaviors:

• permit clause: If a packet matches a permit clause, the router executes the configured set actions (e.g., policy routing the packet to an alternate next-hop or marking DSCP).
• deny clause: If a packet matches a deny clause, the packet is NOT dropped. Instead, the router immediately exempts the packet from PBR and forwards it using the standard destination-based routing table (FIB).
• Implicit Deny: At the end of every route-map resides an invisible, implicit deny statement. Any packet that fails to match all configured sequence clauses falls through to the implicit deny and is forwarded via the normal destination routing table.

Dropping Packets with PBR: To intentionally drop/discard packets using PBR, you must match the traffic in a permit sequence clause and configure the action: set interface Null0.

3. PBR Set Statements & Forwarding Actions

The set commands define the policy transformations or next-hop overrides executed when a packet matches a permit sequence clause.

+-----------------------------------------------------------------------------------+
|                         PBR SET STATEMENT COMPARISON                              |
+-----------------------------------------------------------------------------------+
|  Command                        | Evaluation Timing   | Fallback Condition        |
| :------------------------------ | :------------------ | :-------------------------|
|  set ip next-hop <ip>           | BEFORE Routing Table| If next-hop unreachable,   |
|                                 | (Overrides FIB)     | falls back to normal FIB.  |
|  set default ip next-hop <ip>   | AFTER Routing Table | Used ONLY if no explicit   |
|                                 | (FIB First)         | non-default route in RIB.  |
|  set interface <intf>           | BEFORE Routing Table| Best for P2P links; needs  |
|                                 | (Direct Egress)     | ARP on multi-access links. |
|  set default interface <intf>   | AFTER Routing Table | Used ONLY if no explicit   |
|                                 | (FIB First)         | route found in RIB.        |
|  set ip precedence / dscp <val> | Ingress QoS Marking | Applied to packet header   |
|                                 | (Header Rewrite)    | alongside forwarding path. |
+-----------------------------------------------------------------------------------+

1. set ip next-hop vs. set default ip next-hop

The operational distinction between set ip next-hop and set default ip next-hop is one of the most frequently tested concepts on the ENCOR exam:

• set ip next-hop <ip-address-1> [ip-address-2 ...]:

  • Unconditional Policy Override: Evaluated before the router consults the regular destination routing table.
  • If the specified next-hop IP is reachable (has an active path in the RIB / ARP adjacency), the router unconditionally forwards the packet to that next-hop, ignoring whatever the FIB might say.
  • Multiple next-hops can be specified for redundancy. If <ip-address-1> is unreachable, the router tries <ip-address-2>.

• set default ip next-hop <ip-address-1> [ip-address-2 ...]:

  • Conditional Default Override: Evaluated after the router performs a normal destination routing table lookup.
  • If the routing table contains an explicit, non-default route (e.g., /32, /24, /16) matching the destination IP, the router forwards the packet according to that specific routing table entry, ignoring the PBR policy.
  • The policy next-hop is utilized only if NO explicit match exists in the routing table (i.e., the packet only matches the default route 0.0.0.0/0 or would otherwise be dropped).

2. Next-Hop Tracking with IP SLA (verify-availability)

Standard set ip next-hop relies on routing table presence and ARP resolution to determine reachability. However, if an upstream service provider router is powered on but has lost end-to-end WAN transit connectivity, standard next-hop checks will fail to detect the outage. Cisco IOS allows integrating PBR with Object Tracking and IP SLA:

! Track WAN Link Reachability using IP SLA ICMP Echo
ip sla 1
 icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0/2
 frequency 5
ip sla schedule 1 life forever start-time now
!
track 10 ip sla 1 reachability
!
! Integrate Object Tracking directly into PBR Route-Map
route-map PBR_DUAL_WAN permit 10
 match ip address ACL_CRITICAL_APP
 set ip next-hop verify-availability 203.0.113.1 1 track 10
 set ip next-hop verify-availability 198.51.100.1 2 track 20

• If Track 10 is UP, traffic matching sequence 10 is forwarded to 203.0.113.1 (Sequence 1 priority).
• If Track 10 transitions to DOWN, PBR instantly falls back to 198.51.100.1 (Sequence 2 priority).

3. QoS Marking with set ip precedence and set ip dscp

PBR allows network administrators to classify and mark packets at the ingress boundary without configuring a separate Modular QoS CLI (MQC) policy:

• set ip precedence <0-7 | routine | priority | immediate | flash | flash-override | critical | internet | network>
• set ip dscp <0-63 | default | af11-af43 | cs1-cs7 | ef>

route-map PBR_QOS permit 10
 match ip address ACL_VOIP_PAYLOAD
 set ip dscp ef
 set ip next-hop 10.10.10.1

4. Interface PBR vs. Local PBR

Cisco IOS-XE supports two distinct administrative scopes for Policy-Based Routing: Interface PBR and Local PBR.

+-----------------------------------------------------------------------------------+
|                         INTERFACE PBR VS. LOCAL PBR                               |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  INTERFACE PBR (Transit Traffic):                                                 |
|  - Applied under interface configuration mode: 'ip policy route-map <NAME>'       |
|  - Evaluates incoming packets arriving from attached hosts or adjacent routers.    |
|  - Does NOT inspect or steer packets originated by the router itself!             |
|                                                                                   |
|  LOCAL PBR (Router-Originated Traffic):                                           |
|  - Applied in global configuration mode: 'ip local policy route-map <NAME>'       |
|  - Evaluates packets generated directly by the Route Processor (Control Plane).   |
|  - Steers local Ping, Traceroute, BGP/OSPF Hellos, SNMP, Syslog, TACACS+, etc.    |
+-----------------------------------------------------------------------------------+

Detailed Comparison Matrix

5. Cisco IOS-XE Configuration & Verification

1. Dual-ISP Policy-Based Routing Implementation

Consider an enterprise edge router (Edge-R1) connected to two internet service providers: ISP-A (High-speed, primary for web/video) and ISP-B (Low-latency, dedicated for corporate VoIP/SSH). Internal subnets enter via interface GigabitEthernet0/0/0.

! Step 1: Define Access Control Lists to identify traffic classes
ip access-list extended ACL_VOIP_SSH
 permit tcp 10.10.0.0 0.0.255.255 any eq 22
 permit udp 10.10.0.0 0.0.255.255 any range 16384 32767
 permit tcp 10.10.0.0 0.0.255.255 any eq 5060
exit

ip access-list extended ACL_GENERAL_WEB
 permit tcp 10.10.0.0 0.0.255.255 any eq 80
 permit tcp 10.10.0.0 0.0.255.255 any eq 443
exit

! Step 2: Construct the Route-Map with match and set clauses
route-map PBR_TRAFFIC_SHAPING permit 10
 match ip address ACL_VOIP_SSH
 set ip dscp ef
 set ip next-hop 203.0.113.2
!
route-map PBR_TRAFFIC_SHAPING permit 20
 match ip address ACL_GENERAL_WEB
 set ip dscp af21
 set ip next-hop 198.51.100.2
!
route-map PBR_TRAFFIC_SHAPING deny 30
 match ip address ACL_INTERNAL_CORP
! (Sequence 30 bypasses PBR; implicitly permitted via normal routing table)

! Step 3: Apply the Route-Map to the Ingress Interface (Interface PBR)
interface GigabitEthernet0/0/0
 description LAN_Internal_Users
 ip address 10.10.1.1 255.255.255.0
 ip policy route-map PBR_TRAFFIC_SHAPING
exit

! Step 4: Configure Local PBR to steer router's own Syslog and SNMP to ISP-B
route-map PBR_ROUTER_MGMT permit 10
 match ip address ACL_MGMT_TRAFFIC
 set ip next-hop 203.0.113.2
!
ip local policy route-map PBR_ROUTER_MGMT

2. Comprehensive Verification Commands & Debugging

Edge-R1# show ip policy
Interface                 Route map
GigabitEthernet0/0/0      PBR_TRAFFIC_SHAPING
local                     PBR_ROUTER_MGMT

Edge-R1# show route-map PBR_TRAFFIC_SHAPING
route-map PBR_TRAFFIC_SHAPING, permit, sequence 10
  Match clauses:
    ip address (access-lists): ACL_VOIP_SSH
  Set clauses:
    ip dscp ef
    ip next-hop 203.0.113.2
  Policy routing matches: 14820 packets, 1896960 bytes

route-map PBR_TRAFFIC_SHAPING, permit, sequence 20
  Match clauses:
    ip address (access-lists): ACL_GENERAL_WEB
  Set clauses:
    ip dscp af21
    ip next-hop 198.51.100.2
  Policy routing matches: 98450 packets, 126016000 bytes

route-map PBR_TRAFFIC_SHAPING, deny, sequence 30
  Match clauses:
    ip address (access-lists): ACL_INTERNAL_CORP
  Policy routing matches: 4210 packets, 353640 bytes

Edge-R1# debug ip policy
Policy routing debugging is on

*Aug 30 14:22:01.104: IP: s=10.10.1.50 (GigabitEthernet0/0/0), d=203.0.113.50, len 84, policy match
*Aug 30 14:22:01.105: IP: route map PBR_TRAFFIC_SHAPING, sequence 10, permit
*Aug 30 14:22:01.105: IP: s=10.10.1.50 (GigabitEthernet0/0/0), d=203.0.113.50, len 84, policy routed to 203.0.113.2 via GigabitEthernet0/0/1

*Aug 30 14:22:05.210: IP: s=10.10.1.99 (GigabitEthernet0/0/0), d=172.16.5.1, len 60, policy match
*Aug 30 14:22:05.210: IP: route map PBR_TRAFFIC_SHAPING, sequence 30, deny
*Aug 30 14:22:05.211: IP: s=10.10.1.99 (GigabitEthernet0/0/0), d=172.16.5.1, len 60, policy rejected -- normal forwarding