How to Implement Policy-Based Routing (PBR) on Cisco Routers: Complete Configuration Guide

Normal IP routing makes one decision for every packet: look at the destination address, check the routing table, and forward accordingly. Most of the time that’s exactly what you want. But sometimes it isn’t enough — maybe you need traffic from a specific application to go out a different WAN link than everything else, or you need to steer traffic from a particular subnet through a security appliance for inspection before it leaves the network. That’s where Policy-Based Routing comes in, and I want to walk you through exactly how it works and how to configure it properly on Cisco routers.

What Is Policy-Based Routing?

Policy-Based Routing (PBR) lets you override the normal destination-based routing decision using criteria you define — source address, destination address, packet size, protocol, application port, or a combination of these. Instead of asking “where does this destination live in my routing table,” PBR asks “does this packet match a policy I’ve defined, and if so, what should I do with it instead of the default behavior?”

I think of normal routing like a mail sorting facility that only looks at the destination zip code. PBR is like adding a rule that says “any package with ‘fragile’ stamped on it, regardless of destination, goes on the truck with better shock absorbers.” It’s routing based on characteristics of the packet itself, not just where it’s headed.

Common Use Cases

• Load distribution across multiple ISPs based on source subnet or application type
• Forcing traffic through a firewall, IDS/IPS, or WAN optimizer for inspection before normal routing takes over
• Cost-based routing — sending bulk/non-critical traffic over a cheaper link while keeping latency-sensitive traffic on a premium circuit
• Asymmetric routing control in multi-homed environments
• Selectively routing guest or IoT traffic differently than corporate traffic, even when they share a routing table

How PBR Works: The Processing Order

This is the part that trips a lot of people up, so I want to be very clear about it. PBR is applied to packets as they arrive on an inbound interface, and it’s evaluated before the normal routing table lookup. The router checks: does this packet match a route-map applied via PBR? If yes, PBR’s instructions take priority. If no match (or the route-map explicitly denies it), the packet falls through to normal destination-based routing.

The building blocks are:

1. An Access Control List (ACL) — defines which traffic you’re interested in (matching criteria).
2. A route-map — references the ACL and defines what to do with matching traffic (set next-hop, set interface, set DSCP, etc.).
3. Applying the route-map to an interface using ip policy route-map — this activates PBR on that inbound interface.

Step-by-Step Configuration

Let’s build a real example. Say we have a router with two internet connections — a primary MPLS/fiber link and a secondary broadband link — and we want traffic from our finance subnet (10.10.10.0/24) to specifically route out through the secondary link, while everything else uses normal routing.

Step 1: Define the Matching Criteria with an ACL

Router(config)# ip access-list extended FINANCE-TRAFFIC
Router(config-ext-nacl)# permit ip 10.10.10.0 0.0.0.255 any
Router(config-ext-nacl)# exit

Step 2: Create the Route-Map

Router(config)# route-map PBR-FINANCE permit 10
Router(config-route-map)# match ip address FINANCE-TRAFFIC
Router(config-route-map)# set ip next-hop 203.0.113.254
Router(config-route-map)# exit

You have several options for the set action, not just next-hop:

set ip next-hop 203.0.113.254        ! Route to a specific next-hop
set interface GigabitEthernet0/2      ! Route out a specific interface
set ip default next-hop 203.0.113.254 ! Only used if normal routing table lookup fails
set ip precedence flash                ! Mark packet precedence
set ip qos-group 10                    ! Assign to a QoS group

Step 3: Add a Catch-All Permit for Everything Else

If you don’t want PBR to affect any other traffic, don’t add another match clause — simply don’t apply a deny for unmatched traffic, and let it fall through to normal routing naturally. But if you have multiple policies, chain route-map sequences:

Router(config)# route-map PBR-FINANCE permit 20
Router(config-route-map)# exit

An empty permit 20 with no match statement matches everything remaining and lets it continue with default routing behavior (no set commands means normal routing applies).

Step 4: Apply the Route-Map to the Inbound Interface

Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip policy route-map PBR-FINANCE
Router(config-if)# exit

Remember: this is applied to the interface where traffic enters the router from the finance subnet — not the outbound interface.

Verifying PBR

Router# show route-map PBR-FINANCE
route-map PBR-FINANCE, permit, sequence 10
  Match clauses:
    ip address (access-lists): FINANCE-TRAFFIC
  Set clauses:
    ip next-hop 203.0.113.254
  Policy routing matches: 1542 packets, 128940 bytes

That “Policy routing matches” counter is invaluable — it tells you the policy is actually being hit, not just configured.

Router# show ip policy
Interface      Route map
Gi0/0          PBR-FINANCE

Test with a traceroute from a finance-subnet host and confirm the path takes the expected next hop.

Local Policy Routing (Traffic Originated by the Router Itself)

Everything above applies to transit traffic passing through the router. If you need to policy-route traffic that the router itself generates (like pings sourced from the router, or SNMP traps), you need a separate command:

Router(config)# ip local policy route-map PBR-FINANCE

This is a common gap — people configure PBR and then wonder why router-originated traffic doesn’t follow the same policy; it needs to be explicitly enabled.

PBR with IP SLA for Intelligent Failover

A more advanced, production-grade pattern combines PBR with IP SLA tracking, so that if the preferred next-hop becomes unreachable, PBR automatically stops routing traffic there.

Router(config)# ip sla 1
Router(config-ip-sla)# icmp-echo 203.0.113.254 source-interface GigabitEthernet0/2
Router(config-ip-sla-echo)# frequency 5
Router(config-ip-sla-echo)# exit
Router(config)# ip sla schedule 1 life forever start-time now

Router(config)# track 1 ip sla 1 reachability

Router(config)# route-map PBR-FINANCE permit 10
Router(config-route-map)# match ip address FINANCE-TRAFFIC
Router(config-route-map)# set ip next-hop verify-availability 203.0.113.254 1 track 1

This way, if the secondary link’s next-hop stops responding to ICMP, PBR gracefully falls back to normal routing (or you can chain a second sequence pointing to a tertiary path).

Real-World Enterprise Scenario

I’ve used PBR most heavily in dual-ISP branch designs, where the business wants bulk backup/replication traffic to go out the cheaper broadband circuit while VoIP and business-critical SaaS traffic stays on the premium MPLS or dedicated fiber link. Rather than relying purely on routing metrics (which apply per-destination, not per-application), PBR lets you match specific traffic types — by source subnet, by destination port, or by DSCP marking — and steer them independently of what the routing table would otherwise choose.

Another common scenario: security-driven designs where all guest and IoT traffic must be policy-routed through a dedicated firewall or content-filtering appliance before reaching the internet, regardless of what the “normal” shortest path would be.

Security Considerations

• PBR can be used defensively — forcing certain traffic through inspection points — but it can also become a security gap if misconfigured, silently routing traffic around firewalls or logging points that the rest of the network assumes it passes through. Document PBR policies clearly.
• Combine PBR route-maps with strict ACL matching; overly broad permit ip any any matches in the underlying ACL can cause unintended traffic to be policy-routed.
• Regularly audit show route-map hit counters — a policy with zero hits over time may indicate a matching problem or that it’s now obsolete.

Common Configuration Mistakes

• Applying ip policy route-map on the wrong interface (it must be the ingress interface for the traffic you want to affect).
• Forgetting ip local policy route-map for router-originated traffic.
• Not accounting for return traffic — PBR only affects the direction it’s applied to; asymmetric routing can result if you’re not careful, and some stateful security devices don’t tolerate that well.
• Route-map sequence numbering gaps causing unexpected fallthrough behavior.
• Forgetting that a set ip next-hop pointing to an unreachable address will black-hole traffic unless combined with verify-availability tracking.

Troubleshooting Checklist

1. show ip policy — confirm the route-map is applied to the correct interface.
2. show route-map <name> — check match/set clauses and hit counters.
3. debug ip policy (careful in production, it’s verbose) — shows real-time PBR decisions per packet.
4. Confirm the ACL used in the route-map actually matches the intended traffic with show access-list <name>.
5. Check for asymmetric routing issues if a stateful firewall along the path is dropping return traffic.
6. Verify IP SLA/tracking state with show track 1 if you’re using availability-based fallback.

Performance Tuning Tips

• PBR is processed via Cisco Express Forwarding (CEF) on most modern platforms — check show ip cef to confirm CEF is enabled, as PBR performance without CEF (process-switched) can be significantly slower.
• Keep ACLs used in PBR route-maps as specific and minimal as possible — every packet on the ingress interface has to be evaluated against them.
• Consolidate multiple PBR policies into a single well-ordered route-map with sequence numbers rather than stacking multiple separate policies, for easier troubleshooting and slightly better performance.

FAQs

Does PBR affect return traffic automatically? No. PBR only applies to traffic matching the policy on the interface where it’s configured. Return traffic follows its own routing decision (or its own PBR policy if configured on that path), which is why asymmetric routing is a common side effect to watch for.

Can I use PBR with NAT? Yes, and it’s a common combination, but order of operations matters — PBR typically evaluates the packet before NAT translation on the way in, so make sure your ACLs match pre-NAT or post-NAT addresses depending on the traffic direction and platform behavior. Always verify with a lab test.

What happens if a packet doesn’t match any route-map clause? It falls through to normal destination-based routing, exactly as if PBR weren’t configured for that packet.

Is PBR supported on switches too? Yes, many Cisco Layer 3 switches (like the Catalyst 9000 series) support PBR, though the exact command set and hardware limitations can differ slightly from router platforms — always check the specific platform’s PBR support and TCAM resource limits.

Summary

Policy-Based Routing gives you granular control over how traffic flows through your network, based on more than just destination address — source, protocol, port, and packet characteristics can all drive the decision. The essentials to remember: PBR is applied on ingress interfaces and evaluated before the routing table, router-originated traffic needs its own ip local policy command, and pairing PBR with IP SLA tracking makes it resilient to link failures instead of black-holing traffic. Once you’ve built a couple of PBR policies for real business requirements — like dual-ISP load distribution or security-driven traffic steering — it becomes one of the most useful tools in your routing toolkit.

References

• Cisco: Policy-Based Routing Configuration Guide
• Cisco: IP SLA Configuration Guide
• Cisco IOS Route-Map Command Reference