5.3 Policy-Based Routing (PBR) Architecture, Configuration, and Route-Maps

Policy-Based Routing (PBR) Architecture, Configuration, and Route-Maps

Traditional IP forwarding operates strictly on a destination-driven paradigm: a router evaluates incoming packets against its local routing table (RIB) and selects the best exit interface solely based on the destination IP address and Longest Prefix Match (LPM). However, enterprise networks frequently require customized traffic forwarding that overrides standard routing tables. Policy-Based Routing (PBR) provides network engineers with granular control, allowing packets to be steered based on source IP address, transport layer protocol, application port numbers, packet length, or Quality of Service (QoS) markings.

---

Enterprise PBR Architecture and Use Cases

PBR functions as a programmable bypass mechanism inserted directly into the router's packet forwarding path:

Incoming Packet on Interface
             |
             v
   [Is PBR Enabled on Interface?]
        /              \
      YES               NO
      /                  \
[Evaluate Route-Map]      v
   |         |      [Standard Destination Routing Table]
 MATCH     NO MATCH               |
   |         |                    v
   v         +-----> [Normal Forwarding / Next-Hop]
[Apply 'Set' Action]
(e.g., Force ISP 2)

Primary Enterprise Use Cases

• Multi-Homed ISP Selection: Steering latency-sensitive voice and critical SaaS traffic through a premium primary ISP link while shunting bulk data or backup replication over an inexpensive secondary circuit.
• Security Inspection Steering: Forcing specific user subnets or suspicious traffic through dedicated out-of-path security appliances (such as web proxies, firewalls, or IDS sensors) without re-architecting physical cabling.
• QoS Policy Routing: Classifying traffic at the edge and assigning specific next-hop paths or IP Precedence/DSCP values to protect business-critical flows.
• Equal-Cost Multi-Path Override: Bypassing standard hashing algorithms to pin specific traffic streams to deterministic transit interfaces.

---

Route-Map Anatomy and Processing Semantics

PBR relies on route-maps to define match criteria and forwarding actions. A route-map consists of named statement blocks ordered by sequence numbers:

route-map PBR_POLICY permit 10
 match ip address 101
 set ip next-hop 198.51.100.1
!
route-map PBR_POLICY permit 20
 match ip address 102
 set ip next-hop 203.0.113.1

Route-Map Processing Rules

1. Sequential Evaluation: Route-maps evaluate statements in ascending sequence number order (e.g., 10, then 20, then 30). As soon as a packet matches a statement, evaluation terminates and the corresponding set action executes.
2. Permit vs. Deny in Route-Maps:
   • permit: If the packet matches the match clause, the router applies the set action.
   • deny: If the packet matches the match clause, the router ceases policy routing for this packet. The packet falls through to standard destination-based routing.
3. Implicit Deny: Every route-map terminates with an unwritten implicit deny. Packets that fail to match any sequence number exit the route-map and undergo standard destination-based routing table lookups. Packets are never dropped by an implicit deny in PBR.

The Matrix of Route-Map and ACL Logic

When an Access Control List (ACL) is called within a match ip address statement, the combination of ACL action and route-map action dictates the forwarding outcome:

---

Next-Hop Forwarding Directives: set ip next-hop vs. set ip default next-hop

The most critical architectural distinction in PBR lies between set ip next-hop and set ip default next-hop:

                                  Incoming Packet
                                         |
                   +---------------------+---------------------+
                   |                                           |
         [set ip next-hop]                           [set ip default next-hop]
                   |                                           |
        Is next-hop reachable?                       Does an explicit route exist
             /           \                           in RIB (excluding 0.0.0.0/0)?
           YES            NO                                 /              \
           /                \                              YES               NO
          v                  v                             /                  \
  Forward via PBR    Fallback to standard           Forward via           Forward via PBR
     next-hop           routing table             standard explicit         default next-hop
                                                      RIB route

Interface Directives: PBR also supports set interface <type/number> and set default interface <type/number>. These directives should only be used on point-to-point connections (such as serial links or GRE tunnels). Using set interface on a multiaccess Ethernet segment causes excessive ARP lookups for every destination IP, exhausting router memory and CPU resources.

---

Interface PBR vs. Local PBR

Routers process transit packets passing through interfaces differently from packets generated locally by the router's own control plane:

1. Interface PBR (ip policy route-map)

Applied to an ingress physical interface, subinterface, or VLAN interface (SVI). It evaluates transit traffic entering the router from downstream devices:

interface GigabitEthernet0/0/1
 description Ingress LAN from Campus
 ip policy route-map LAN_STEERING

Packets originated by the router itself (e.g., ping commands executed on the CLI, SNMP traps, Syslog messages, or BGP update packets) completely bypass interface PBR.

2. Local PBR (ip local policy route-map)

Applied globally to inspect and redirect traffic originated locally by the router:

ip local policy route-map ROUTER_MANAGEMENT_POLICY

This command enables network administrators to direct management or monitoring traffic out a dedicated out-of-band management interface or secondary WAN link.

---

Step-by-Step Cisco IOS PBR Configuration

Consider an enterprise edge router dual-homed to two ISPs:

• ISP_1 Next-Hop: 198.51.100.1 (connected via GigabitEthernet0/0/1)
• ISP_2 Next-Hop: 203.0.113.1 (connected via GigabitEthernet0/0/2)
• Ingress LAN Interface: GigabitEthernet0/0/0

Business Objective: Route Voice over IP (VoIP) and video traffic (marked DSCP EF or CS4) out ISP_1. Route Guest Wi-Fi subnet (172.16.50.0/24) out ISP_2. Allow all other enterprise data to follow standard routing.

! Step 1: Define classification ACLs
ip access-list extended ACL_REALTIME_TRAFFIC
 permit ip any any dscp ef
 permit ip any any dscp cs4
!
ip access-list extended ACL_GUEST_WIFI
 permit ip 172.16.50.0 0.0.0.255 any
!
! Step 2: Build the route-map with sequence numbers and set clauses
route-map PBR_EDGE_POLICY permit 10
 description Direct Voice and Video out ISP 1
 match ip address ACL_REALTIME_TRAFFIC
 set ip next-hop 198.51.100.1
!
route-map PBR_EDGE_POLICY permit 20
 description Direct Guest Wi-Fi out ISP 2
 match ip address ACL_GUEST_WIFI
 set ip next-hop 203.0.113.1
!
! Step 3: Attach the route-map to the ingress interface
interface GigabitEthernet0/0/0
 description Ingress User LAN
 ip address 10.1.1.1 255.255.255.0
 ip policy route-map PBR_EDGE_POLICY

---

PBR Verification and Troubleshooting

Network engineers verify and troubleshoot PBR deployments using dedicated operational commands:

• show route-map [map-name]: Displays route-map configuration, sequence numbers, and vital match counters indicating how many packets and bytes have matched each sequence clause.
• show ip policy: Lists all interfaces where ip policy route-map is actively applied along with the bound route-map name.
• show ip local policy: Displays the globally configured local policy route-map applied to self-generated router packets.
• debug ip policy: Generates real-time console messages for each packet evaluated by PBR, displaying the source/destination IP, matching sequence number, and designated next-hop, or indicating if the packet fell through to the normal routing table (routed normal).