Hands-On Lab: Configuring Policy-Based Routing (PBR)

This hands-on lab configures Policy-Based Routing on a router to send traffic from a specific source subnet out a different path than the normal routing table would select, overriding the destination-based forwarding decision that every previous routing lab in this series relied on.

Policy-Based Routing ConfigurationRoute-Map Set Next-HopSource-Based Path Selection

~4 min read · Updated Sep 24, 2026

Lab Objective

Configure a route-map matching traffic from a specific source subnet, set an alternate next hop for that traffic using PBR, apply it inbound on the source-facing interface, and verify traffic from that subnet takes the alternate path while all other traffic continues following the normal routing table.

Lab Purpose

Every routing protocol and static route covered throughout this series makes forwarding decisions based purely on destination address. PBR breaks this assumption entirely, allowing forwarding decisions based on source address, packet size, or other criteria — useful when specific traffic needs to take a different path than the destination-based routing table would otherwise select, regardless of what that table says.

Lab Topology

R1
  Gi0/0: 192.168.190.1/24 (LAN, source subnet
                            for PBR)
  Gi0/1: 10.1.1.1/30 (normal path via routing
                       table, toward R2)
  Gi0/2: 10.2.2.1/30 (alternate path PBR
                       should force, toward R3)

Normal routing table would send all traffic
toward 8.8.8.8 via Gi0/1 (R2) by default

Task 1: Verify the Default Path Without PBR

Confirm traffic from the LAN toward an external address currently follows the normal routing table via Gi0/1.

Task 2: Create an ACL Matching the Source Subnet

Create an ACL matching traffic from 192.168.190.0/24.

Task 3: Create a Route-Map Setting the Alternate Next Hop

Create a route-map matching the ACL and setting the next hop to R3's address via Gi0/2.

Task 4: Apply the Policy to the Inbound Interface

Apply the route-map as a policy on the LAN-facing interface, inbound.

Task 5: Verify Traffic Now Follows the PBR Path

Confirm traffic from the LAN subnet now exits via Gi0/2 toward R3, despite the routing table still preferring Gi0/1.

Solution and Verification

R1# show ip route 8.8.8.8

S*   0.0.0.0/0 [1/0] via 10.1.1.2
-- Default route points toward R2 via Gi0/1,
-- the normal path before PBR is applied

R1# traceroute 8.8.8.8 source 192.168.190.1

  1  10.1.1.2  (via Gi0/1, R2)
-- Confirms traffic currently exits via the
-- normal routing table's chosen path

R1(config)# access-list 150 permit ip 192.168.190.0 0.0.0.255 any

R1(config)# route-map REDIRECT-PBR permit 10
R1(config-route-map)# match ip address 150
R1(config-route-map)# set ip next-hop 10.2.2.2

-- The set clause overrides the routing
-- table's normal decision for any traffic
-- matched by this route-map sequence

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip policy route-map REDIRECT-PBR

R1# traceroute 8.8.8.8 source 192.168.190.1

  1  10.2.2.2  (via Gi0/2, R3)
-- Traffic from the LAN subnet now exits via
-- Gi0/2 toward R3 instead, exactly as the
-- policy dictates, despite the routing
-- table's default route still pointing
-- toward R2 via Gi0/1

R1# show ip policy

Interface      Route map
Gi0/0          REDIRECT-PBR

R1# show route-map REDIRECT-PBR

route-map REDIRECT-PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): 150
  Set clauses:
    ip next-hop 10.2.2.2
  Policy routing matches: 47 packets, 4230 bytes
-- The match counter confirms packets are
-- actually being redirected by this policy

Key Takeaway

PBR is evaluated before the normal routing table lookup for any packet arriving on an interface with a policy applied — a matched packet's forwarding decision comes entirely from the route-map's set clause, completely bypassing whatever the destination-based routing table would otherwise choose, which is precisely why PBR must be used deliberately and documented carefully, since it can make troubleshooting confusing for anyone unaware a policy is silently overriding normal routing behavior on that interface.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring iBGP and the Full-Mesh Requirement

This hands-on lab configures iBGP among three routers within a single autonomous system, demonstrating the full-mesh peering requirement by deliberately omitting one peering relationship and observing the resulting route propagation failure.

Continue

Hands-On Lab: Configuring eBGP Between Two Autonomous Systems (CCNP Depth)

This hands-on lab configures eBGP between two routers in different autonomous systems with a full verification workflow, examining the BGP table, AS-path attribute, and confirming routes are correctly installed with eBGP's default administrative distance.

Continue

Hands-On Lab: Configuring Route Leaking Between VRFs

This hands-on lab configures selective route leaking between two VRFs using route targets and a shared services VRF, allowing specific routes to cross the otherwise strict isolation boundary established in the previous VRF-Lite lab.

Continue

Hands-On Lab: Configuring VRF-Lite

This hands-on lab configures VRF-Lite on a router to maintain two completely separate routing tables for two different customer networks sharing the same physical router, verifying each VRF's traffic remains isolated despite using overlapping IP address space.

Continue

Hands-On Lab: Configuring Layer 3 EtherChannel

This hands-on lab configures a routed EtherChannel between two Layer 3 switches, bundling two physical links into a single logical routed interface rather than a switched trunk, and verifies OSPF forms a single neighbor relationship across the bundle rather than one per physical link.

Continue

Hands-On Lab: Configuring LACP Fast Rate

This hands-on lab configures LACPDU fast rate on an EtherChannel bundle, reducing the interval between LACP control packets to accelerate detection of a failed member link compared to the default slow rate.

Continue