Verification of Policy-Based Routing: Ensuring Correct Implementation

Policy-Based Routing verification is where theory meets reality. You've configured your route-maps, applied them to interfaces, and created complex matching criteria , but how do you prove your PBR implementation actually works as designed? Proper verification methodology separates competent network engineers from those who deploy configurations and hope for the best.

Understanding PBR Verification Layers

Effective PBR verification operates on multiple layers. First, you need to confirm your route-map logic is sound and applied correctly. Second, you must verify that traffic matching occurs as expected. Finally, you need to validate that packets actually follow the policy-defined paths rather than standard routing table entries.

The verification process becomes critical in enterprise environments where PBR handles traffic engineering, load balancing across multiple ISP connections, or implements security policies that direct specific traffic through security appliances.

Route-Map Structure Verification

Begin verification by examining your route-map configuration and application status. The show route-map command reveals both the configured logic and runtime statistics:

Router# show route-map POLICY_MAP
route-map POLICY_MAP, permit, sequence 10
  Match clauses:
    access-list 100
  Set clauses:
    ip next-hop 192.168.1.10
  Policy routing matches: 1247 packets, 89384 bytes

route-map POLICY_MAP, permit, sequence 20
  Match clauses:
    access-list 101
  Set clauses:
    interface Serial0/0/1
  Policy routing matches: 0 packets, 0 bytes

The match statistics provide immediate insight into which route-map statements are processing traffic. Zero matches on a statement you expect to be active indicates either incorrect ACL logic or traffic that doesn't match your assumptions.

Verify route-map application to interfaces using show ip policy:

Router# show ip policy
Interface      Route map
Gi0/0/0        POLICY_MAP
Gi0/0/1        POLICY_MAP

Access List Validation

Since PBR relies heavily on access lists for traffic classification, verify ACL match behavior using show access-lists:

Router# show access-lists 100
Extended IP access list 100
    10 permit tcp 192.168.10.0 0.0.0.255 any eq 80 (1247 matches)
    20 permit tcp 192.168.10.0 0.0.0.255 any eq 443 (892 matches)

The match counters confirm which traffic types are being classified. Use clear access-list counters before testing to get clean baseline statistics.

Real-Time Traffic Flow Analysis

Static configuration verification only tells part of the story. Use debug ip policy to observe PBR decisions in real-time:

Router# debug ip policy
Policy routing debugging is on

*Oct 15 14:23:15.123: IP: s=192.168.10.5 (GigabitEthernet0/0/0), d=8.8.8.8, len 64
*Oct 15 14:23:15.123: IP: route map POLICY_MAP, item 10, permit
*Oct 15 14:23:15.123: IP: s=192.168.10.5 (GigabitEthernet0/0/0), d=8.8.8.8 (Serial0/0/1), len 64, policy routed

Debug output shows the source/destination, which route-map statement matched, and the ultimate forwarding decision. This real-time view validates that traffic follows your intended policy paths.

For production environments, consider using debug ip policy detail for more comprehensive information, but remember that debugging can impact performance on busy routers.

Next-Hop Reachability Testing

PBR can specify next-hop addresses that might become unreachable, potentially creating black holes. Verify next-hop reachability using standard ping and traceroute tests, but also examine the routing table:

Router# show ip route 192.168.1.10
Routing entry for 192.168.1.10/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via ospf 1
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0/0/1
      Route metric is 0, traffic share count is 1

For PBR policies using set ip next-hop verify-availability, check the tracking object status:

Router# show track 1
Track 1
  IP route 192.168.1.10 255.255.255.255 reachability
  Reachability is Up
    1 change, last change 00:15:23
  Latest operation return code: OK

End-to-End Path Validation

The ultimate PBR verification requires confirming that packets traverse the intended path from source to destination. Generate test traffic from specific sources that should trigger PBR policies:

Router# ping 8.8.8.8 source 192.168.10.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/32/36 ms

Combine this with interface statistics monitoring to confirm traffic exits through the policy-defined interface:

Router# show interface serial0/0/1 | include packets
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 2000 bits/sec, 3 packets/sec
     1247 packets input, 89384 bytes, 0 no buffer
     1892 packets output, 145672 bytes, 0 underruns

Traceroute Analysis

Extended traceroute provides definitive path verification by showing exactly which next-hops handle the traffic:

Router# traceroute 8.8.8.8 source 192.168.10.5
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.1.10 16 msec 16 msec 16 msec
  2 203.0.113.1 32 msec 32 msec 28 msec

Compare this path against traceroute results without PBR to confirm the policy is actively changing forwarding behavior.

Performance Impact Assessment

PBR verification should include performance impact analysis. Monitor CPU utilization during peak traffic periods:

Router# show processes cpu | include IP Input
   3         0    131240     0.15%   0.12%   0.11%   0 IP Input

High CPU utilization in the IP Input process may indicate PBR is consuming excessive resources, particularly with complex route-maps or extensive ACLs.

Common Verification Pitfalls

Watch for these common verification mistakes that can mask PBR problems. First, ensure you're testing with traffic that actually matches your ACL criteria — many engineers test with administrative traffic that bypasses PBR entirely. Second, verify that your test traffic originates from the correct interfaces where PBR policies are applied. Finally, remember that locally generated router traffic typically isn't subject to PBR policies unless explicitly configured with ip local policy route-map.

Automated Verification Scripts

For ongoing monitoring, consider implementing automated verification scripts that periodically test PBR functionality. These scripts can generate specific traffic patterns, capture route-map statistics, and alert on unexpected changes in forwarding behavior.

What's Next

Now that you understand PBR verification methodology, the next logical step is exploring advanced PBR scenarios including load balancing across multiple paths, integrating PBR with IP SLA for next-hop availability tracking, and implementing PBR in complex enterprise networks with multiple routing protocols. These advanced implementations require sophisticated verification approaches that build on these fundamental techniques.

Tools and resources for this topic

• CCNP ENARSI 300-410 Official Cert Guide — The definitive ENARSI study resource by Raymond Lacoste. Covers advanced routing, services, and troubleshooting.