Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now Get Now

Advanced Policy-Based Routing: The Override That Fails Silently

Network Infrastructure ｜ Configuration ｜ Intermediate ｜ 19 min read

Policy-based routing forwards packets on something other than the destination address. That is the whole idea, and it is also why PBR is the feature most likely to be blamed for a problem it is not causing and least likely to be found by someone troubleshooting a path that looks wrong. A routing table can be read; a PBR policy has to be known about first, and a route-map attached to one interface on one router is easy to miss for an hour.

The mechanics are simpler than the reputation suggests. A route-map is attached to an interface with ip policy route-map, it sees packets arriving on that interface before the routing lookup, and clauses that match get a next hop imposed on them. Clauses that do not match — and packets denied by a clause — fall through to normal routing. That last sentence is the source of most PBR confusion, because a deny in a PBR route-map does not drop anything; it means "this traffic is exempt from the policy".

This article covers what PBR overrides and where it applies, the full match vocabulary and its limits, the four set actions and the precedence between them, making PBR fail over safely with IP SLA and tracking, and the failure catalogue — the cases where PBR is configured correctly, matches nothing, and silently does nothing at all.

Blog ClaimA deny clause in a PBR route-map does not drop traffic, it exempts traffic from the policy — and the number of production incidents caused by that one misunderstanding is larger than the number caused by every other PBR feature combined.
 
PBR runs on the ingress interface before the routing lookup. The two “default” set forms only apply when the routing table has nothing; the other two always win.

What Does PBR Actually Override, and Where Is It Applied?

What is PBR in one paragraph?

PBR is a route-map attached to an interface that inspects packets as they arrive, before the destination lookup, and imposes a forwarding decision on the ones that match. It overrides the routing table for those packets only. It is applied on the interface traffic enters, not the one it leaves, and there is no egress form. Traffic the router originates itself bypasses interface PBR entirely and needs the separate ip local policy route-map command. Everything else about PBR follows from those three facts.

A Deeper Dive into Scope and Attachment

Ingress, not egress

This is the single most common configuration error and it produces a policy that is syntactically perfect and never fires. PBR examines packets on arrival, so the route-map belongs on the interface facing the source. Attaching it to the interface you want traffic to leave by achieves nothing, because by the time a packet reaches that interface the forwarding decision that PBR was supposed to influence has already been made.

! Topology: clients on Gi0/1, two exits on Gi0/0 and Gi0/2
! Goal: send client HTTP out Gi0/2, everything else out Gi0/0
!
! CORRECT - on the interface traffic ARRIVES on
interface GigabitEthernet0/1
 ip address 10.1.1.1 255.255.255.0
 ip policy route-map CLIENT-PBR
!
! WRONG - this does nothing at all
interface GigabitEthernet0/2
 ip policy route-map CLIENT-PBR
! ^ Traffic leaving here was already routed. Too late.
!
! The counter tells you immediately which mistake you made
R1# show route-map CLIENT-PBR
route-map CLIENT-PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): CLIENT-HTTP
  Set clauses:
    ip next-hop 203.0.113.9
  Policy routing matches: 0 packets, 0 bytes
! ^ Zero after real traffic = wrong interface, or the ACL missed.

Router-generated traffic and ip local policy

Packets the router originates — pings from the CLI, syslog, SNMP traps, routing protocol messages, an SSH session outbound — never traverse an ingress interface, so interface PBR cannot see them. Testing a PBR policy with a ping from the router itself therefore tests nothing, and the test failing is not evidence that the policy is broken. Where the router's own traffic genuinely needs steering, ip local policy route-map is the global command that applies a route-map to it.

! Steer traffic the router itself originates
ip local policy route-map LOCAL-PBR
!
route-map LOCAL-PBR permit 10
 match ip address MGMT-TRAFFIC
 set ip next-hop 192.168.99.1
!
! Verify separately from interface PBR
R1# show ip local policy
Local policy routing is enabled, using route-map LOCAL-PBR
route-map LOCAL-PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): MGMT-TRAFFIC
  Set clauses:
    ip next-hop 192.168.99.1
  Policy routing matches: 412 packets, 38904 bytes

What PBR does not override

PBR overrides the forwarding decision and nothing else. It does not bypass an inbound ACL, which is evaluated first and drops matching traffic before PBR ever sees it. It does not bypass unicast RPF, does not change what NAT does, and does not alter the routing table itself — the routes are all still there, unchanged, for every packet that PBR did not match. And it does not affect return traffic, which follows normal routing unless a matching policy exists on the return path's ingress interface.

Order on the ingress path Feature Relationship to PBR
1 Inbound ACL Runs before PBR. Denied traffic never reaches the policy.
2 Unicast RPF Runs before PBR. A failed RPF check drops the packet regardless of policy.
3 Inbound NAT (outside-to-inside) Translation happens first; PBR matches the translated address.
4 PBR Imposes the forwarding decision on matching traffic.
5 Destination routing lookup Used for everything PBR did not match, and for denied clauses.
PBR is one-directional by natureSteering client traffic out a particular exit does not steer the replies back in through the same one. Where symmetry matters — a stateful firewall in the path, for example — the return direction needs its own policy on its own ingress interface, or a design where the routing table produces symmetry on its own.

Where PBR is the wrong tool

PBR is a per-interface, per-router, manually maintained override. That is fine for a handful of steering rules and unmanageable as a network-wide policy layer, because nothing propagates it and nothing warns when one device in a path is missing it. Where the requirement is "traffic of this type should take this path across the network", the answers that scale are separate VRFs, a tunnel or SD-WAN overlay, or influencing the routing table itself with metrics and route-maps. PBR is the right tool when the exception is local, small, and documented.

Document PBR where the routing table is readThe person troubleshooting a path a year from now will read show ip route and get an answer that is true and irrelevant. A comment in the interface description — description CLIENTS - PBR CLIENT-PBR applied — costs nothing and turns an hour of confusion into a ten-second discovery.
Sub claimPBR is applied on the interface traffic arrives on and never on the one it leaves, which makes a policy match counter of zero the fastest diagnosis in the feature.

How Do I Match Traffic in a PBR Route-Map?

What can a PBR clause match on?

Four things in practice: an extended ACL, which carries source, destination, protocol and ports and is what nearly every real policy uses; packet length, for the rare size-based split; the arrival interface, useful when one route-map serves several interfaces; and IP precedence or DSCP through an ACL match. PBR does not match on routing attributes — no AS path, no community, no metric — because it operates on packets rather than on routes, and that distinction is what separates a PBR route-map from a BGP one despite the identical syntax.

A Deeper Dive into Matching

The extended ACL, which does the real work

An extended ACL in a PBR match clause is read as a classifier, not as a filter. A permit line means "this traffic is selected by the clause"; a deny line means "this traffic is not selected by this clause, keep looking". Nothing in the ACL drops anything. That reading is worth internalising, because an ACL written as a security filter and reused in a PBR match clause frequently selects the exact opposite of what was intended.

! Select client HTTP and HTTPS, exclude the internal server farm
ip access-list extended CLIENT-WEB
 deny   ip 10.1.1.0 0.0.0.255 10.50.0.0 0.0.255.255
 ! ^ NOT a drop. Means "this clause does not select internal traffic".
 permit tcp 10.1.1.0 0.0.0.255 any eq 80
 permit tcp 10.1.1.0 0.0.0.255 any eq 443
!
route-map CLIENT-PBR permit 10
 match ip address CLIENT-WEB
 set ip next-hop 203.0.113.9
!
! Confirm what the ACL is actually selecting
R1# show ip access-lists CLIENT-WEB
Extended IP access list CLIENT-WEB
    10 deny ip 10.1.1.0 0.0.0.255 10.50.0.0 0.0.255.255 (2841 matches)
    20 permit tcp 10.1.1.0 0.0.0.255 any eq www (19422 matches)
    30 permit tcp 10.1.1.0 0.0.0.255 any eq 443 (88103 matches)

Matching on length

The match length clause takes a minimum and maximum in bytes and selects packets whose total IP length falls in the range. The classic use is separating interactive traffic from bulk transfer without inspecting ports — small packets to a low-latency path, large packets to a high-bandwidth one. It is a blunt instrument and it is genuinely useful when the alternative is enumerating every application port.

! Small packets to the low-latency link, bulk to the fat one
route-map SIZE-SPLIT permit 10
 match length 0 400
 set ip next-hop 10.0.1.2
!
route-map SIZE-SPLIT permit 20
 match length 401 1500
 set ip next-hop 10.0.2.2
!
interface GigabitEthernet0/1
 ip policy route-map SIZE-SPLIT
!
! Both clauses have their own counter
R1# show route-map SIZE-SPLIT | include sequence|matches
route-map SIZE-SPLIT, permit, sequence 10
  Policy routing matches: 74211 packets, 18409884 bytes
route-map SIZE-SPLIT, permit, sequence 20
  Policy routing matches: 210934 packets, 297418562 bytes

Matching on the arrival interface

Where one route-map is attached to several interfaces, match interface lets a single clause distinguish between them. It saves maintaining near-identical route-maps and it makes the policy read as a table of source interfaces rather than as a set of parallel configurations.

! One route-map, different treatment per arrival interface
route-map MULTI-SRC permit 10
 match interface GigabitEthernet0/1
 set ip next-hop 203.0.113.9
!
route-map MULTI-SRC permit 20
 match interface GigabitEthernet0/3
 set ip next-hop 198.51.100.9
!
interface GigabitEthernet0/1
 ip policy route-map MULTI-SRC
interface GigabitEthernet0/3
 ip policy route-map MULTI-SRC

Combining match clauses

PBR route-maps follow the same composition rules as every other route-map. Two match clauses of different types in one sequence are ANDed — both must be satisfied. Multiple values inside one match clause are ORed. A sequence with no match clause at all matches everything, which makes it useful as a catch-all and dangerous when it was left in place by accident.

Construct Logic Effect in a PBR policy
Two different match types in one sequence AND Both must be true before the set actions apply
Several values in one match clause OR Any one of them selects the packet
Sequence with no match clause Matches everything Catch-all — deliberate or a leftover
route-map X deny 20 Exemption Matching traffic uses normal routing, is not dropped
End of route-map, nothing matched Implicit exemption Normal routing — not a drop
Pitfall: an ACL written as a filter reused as a classifier Symptom: the policy steers traffic that should have been left alone, or leaves alone the traffic it was meant to steer — exactly inverted from the intent. Cause: in a PBR match clause, ACL permit means "select this" and ACL deny means "do not select this". An ACL copied from a security context, where the same words mean allow and drop, therefore classifies backwards. Confirm: show ip access-lists shows heavy hit counts on the lines you expected to be quiet. Fix: write a dedicated ACL for the policy with a name that says what it selects, and never share one ACL between a security filter and a PBR classifier.
Sub claimPBR matches packets and never routes, which is why an extended ACL is the only match clause that matters in most policies and why reusing a security ACL classifies the traffic backwards.

What Are the Set Actions and In What Order Do They Apply?

Which set action should I use?

set ip next-hop in nearly every case, because it overrides the routing table and names a specific adjacent device. set interface where the exit is a point-to-point link with no meaningful next hop address. The two "default" forms — set ip default next-hop and set default interface — apply only when the routing table has no explicit route to the destination, which makes them a fallback rather than an override and makes choosing the wrong one the reason a policy appears to be ignored.

A Deeper Dive into Set Actions

The default forms and why they lose

The difference is one word in the command and total in the behaviour. set ip next-hop 203.0.113.9 sends matching traffic to that address whether or not a route exists to the destination. set ip default next-hop 203.0.113.9 sends it there only if the routing table has nothing for the destination — which, on a router with a default route, is never. A policy built on the default form on a router carrying a default route will match packets, increment its counters, and change nothing.

! Overrides the routing table - the normal choice
route-map OVERRIDE permit 10
 match ip address CLIENT-WEB
 set ip next-hop 203.0.113.9
!
! Only used if NO route exists to the destination
route-map FALLBACK permit 10
 match ip address CLIENT-WEB
 set ip default next-hop 203.0.113.9
! ^ With 0.0.0.0/0 in the table, a route always exists. Never fires.
!
! Interface forms, same distinction
route-map OVERRIDE-INT permit 10
 set interface Serial0/0/0
route-map FALLBACK-INT permit 10
 set default interface Serial0/0/0

Multiple next hops and the order they are tried

A set clause can carry several next hops. The router uses the first one whose address is reachable through a connected interface, and moves to the next only when that reachability disappears. This is a crude failover — it reacts to the interface going down, not to the far end failing — and it is the reason tracking exists.

! First reachable one wins, left to right
route-map CLIENT-PBR permit 10
 match ip address CLIENT-WEB
 set ip next-hop 203.0.113.9 198.51.100.9
! ^ Uses 198.51.100.9 only when 203.0.113.9 stops being reachable
!   via a connected interface. A dead peer on a live link is missed.
!
! Which one is in use right now
R1# show route-map CLIENT-PBR
route-map CLIENT-PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): CLIENT-WEB
  Set clauses:
    ip next-hop 203.0.113.9 198.51.100.9
  Policy routing matches: 44182 packets, 5102944 bytes

Marking as well as steering

PBR can rewrite IP precedence or DSCP on the packets it matches, which makes it a marking point as well as a forwarding one. Marking at the ingress edge with PBR is a legitimate pattern where an MQC policy would be heavier than the requirement warrants, and it composes with the forwarding actions in the same clause.

! Steer and mark in the same clause
route-map VOICE-PBR permit 10
 match ip address VOICE-TRAFFIC
 set ip precedence critical
 set ip next-hop 10.0.1.2
!
! Or DSCP, which is the modern form
route-map VOICE-PBR permit 20
 match ip address VIDEO-TRAFFIC
 set ip dscp af41
 set ip next-hop 10.0.1.2

Moving the lookup to another table

set vrf does not impose a next hop at all — it moves the routing lookup for matching packets into a different VRF, where normal destination routing then happens. This is VRF selection, and it is the clean way to send a subset of traffic from the global table into a VRF, or between VRFs, without any of the leaking machinery.

! Send matched traffic to be routed in VRF RED instead
route-map TO-RED permit 10
 match ip address GUEST-TRAFFIC
 set vrf RED
!
interface GigabitEthernet0/1
 ip policy route-map TO-RED
!
! The lookup now happens in RED - verify there
R1# show ip route vrf RED 0.0.0.0
R1# show route-map TO-RED | include matches
  Policy routing matches: 9284 packets, 1104882 bytes

The four forms compared

Set action Beats the routing table Names Typical use
set ip next-hop Yes An adjacent IP address The default choice for almost every policy
set interface Yes An egress interface Point-to-point links with no useful next hop
set ip default next-hop No An adjacent IP address Fallback when the table has nothing
set default interface No An egress interface Fallback on a point-to-point link
Pitfall: set interface on a multi-access segment Symptom: traffic leaves the correct interface and never arrives, with the ARP table on the router filling with entries for destinations that are not on the segment. Cause: naming an interface rather than a next hop makes the router treat the destination as directly connected on that interface, so it ARPs for the destination address itself. On Ethernet, nothing answers. Confirm: show ip arp | include Incomplete shows entries for remote destinations. Fix: use set ip next-hop with the address of the adjacent router on any multi-access segment, and reserve set interface for genuine point-to-point links.
Sub claimThe word default inverts the relationship between the policy and the routing table, which is why a policy that matches packets and changes nothing is almost always a default form on a router that has a default route.

How Do I Make PBR Fail Over Instead of Blackholing?

What is the problem with plain PBR?

A plain set ip next-hop forwards to that address as long as the address is reachable through a connected interface. It does not check that anything is alive at the other end. When the far device fails while the link stays up — a very common failure on any path through a switch, a service provider handoff, or a firewall — PBR keeps forwarding into the hole while the routing table, which does have liveness detection through its protocols, has long since converged around it. Two mechanisms fix this: verify-availability, which requires CDP visibility, and IP SLA with object tracking, which does not.

A Deeper Dive into Resilient PBR

IP SLA plus tracking, which is the answer

An IP SLA probe tests reachability to a target on a schedule; a tracked object turns the probe's state into a boolean; the set clause consults the object and skips the next hop when it is down. The whole chain is four short blocks and it converts PBR from a static override into one that reacts to real failures at whatever interval the probe runs.

! 1. The probe - test the next hop itself
ip sla 10
 icmp-echo 203.0.113.9 source-interface GigabitEthernet0/0
 frequency 5
 threshold 1000
 timeout 2000
ip sla schedule 10 life forever start-time now
!
! 2. The tracked object
track 10 ip sla 10 reachability
 delay down 10 up 30
! ^ delay damps a flapping probe. Down fast, up slowly.
!
! 3. The set clause consults the object
route-map CLIENT-PBR permit 10
 match ip address CLIENT-WEB
 set ip next-hop verify-availability 203.0.113.9 10 track 10
 set ip next-hop verify-availability 198.51.100.9 20 track 20
! ^ 10 and 20 are sequence numbers. Lowest usable wins.
!
! 4. Apply as usual
interface GigabitEthernet0/1
 ip policy route-map CLIENT-PBR

Verifying the tracking chain

Three commands confirm the chain end to end, and checking all three separates a failed probe from a probe that succeeds while the object stays down — usually a delay up that has not expired yet.

! Is the probe running and succeeding?
R1# show ip sla statistics 10
IPSLA operation id: 10
        Latest RTT: 3 milliseconds
Latest operation start time: 14:02:11 UTC Tue Aug 25 2026
Latest operation return code: OK
Number of successes: 1841
Number of failures: 2
!
! Is the object up, and for how long?
R1# show track 10
Track 10
  IP SLA 10 reachability
  Reachability is Up
    3 changes, last change 02:14:08
  Delay up 30 secs, down 10 secs
    Latest operation return code: OK
!
! Which next hop is the policy actually using?
R1# show route-map CLIENT-PBR
route-map CLIENT-PBR, permit, sequence 10
  Set clauses:
    ip next-hop verify-availability 203.0.113.9 10 track 10  [up]
    ip next-hop verify-availability 198.51.100.9 20 track 20 [up]
  Policy routing matches: 182044 packets, 21845280 bytes

Probe the right target

Probing the next hop address proves the next hop is alive and proves nothing about anything beyond it. Where the failure mode you care about is the provider losing upstream connectivity rather than the handoff router failing, probe something further away — a well-known address beyond the provider, or a service you actually depend on. The trade-off is that a distant target introduces false positives from unrelated failures, so a common pattern is two probes with the tracked object depending on both.

! Near target: proves the handoff is alive
ip sla 10
 icmp-echo 203.0.113.9 source-interface GigabitEthernet0/0
 frequency 5
!
! Far target: proves the path beyond it works
ip sla 11
 icmp-echo 208.67.222.222 source-interface GigabitEthernet0/0
 frequency 10
!
ip sla schedule 10 life forever start-time now
ip sla schedule 11 life forever start-time now
!
track 10 ip sla 10 reachability
track 11 ip sla 11 reachability
!
! Require both before declaring the path usable
track 100 list boolean and
 object 10
 object 11
 delay down 15 up 60

verify-availability without tracking

The bare form of set ip next-hop verify-availability checks that the next hop appears in the CDP neighbour table. That is cheap and it works only where CDP runs and the next hop is a directly connected Cisco device — which excludes most provider handoffs, most firewalls, and every path through a device with CDP disabled. It is worth knowing because it appears in older configurations, and worth replacing with the tracked form wherever it is found.

! CDP-based verification - narrow applicability
route-map CDP-PBR permit 10
 match ip address CLIENT-WEB
 set ip next-hop verify-availability
!
! Does CDP actually see the next hop?
R1# show cdp neighbors GigabitEthernet0/0 detail | include IP address
  IP address: 203.0.113.9
! ^ If this is empty, the clause never selects the next hop.

What each mechanism detects

Mechanism Detects Does not detect Requires
Plain set ip next-hop Local interface down A dead peer on a live link Nothing
verify-availability (CDP) Peer missing from CDP Anything beyond the peer CDP on a directly connected Cisco device
IP SLA + track, near target Dead peer on a live link Failures beyond the peer The peer answering probes
IP SLA + track, far target Path failure beyond the peer — A stable, reachable distant target
Asymmetric delay timers are the pointdelay down 10 up 30 means the object drops quickly when the probe fails and returns slowly when it recovers. That asymmetry is deliberate: failing away fast limits the outage, and returning slowly stops a flapping link from moving production traffic back and forth every few seconds.
Sub claimPlain PBR only notices that the local interface went down, which is why the failure it handles worst — a dead peer on a live link — is also the one that happens most often on provider handoffs.

Which PBR Mistakes Silently Do Nothing?

What are the failures worth memorising?

Five, and four of them produce no error message and no obvious symptom beyond traffic taking the path it would have taken anyway. The route-map on the egress interface. The deny clause read as a drop. The default form on a router with a default route. Testing with a ping from the router itself. And a next hop that is not reachable through a connected interface, which causes the entire set clause to be skipped in favour of normal routing.

A Deeper Dive into the Failure Catalogue

The unreachable next hop

Pitfall: a next hop that is not directly reachable Symptom: the policy match counter increments, so the traffic clearly matched, and yet the packets follow the normal routing table. Cause: PBR requires the next hop to be reachable through a connected interface. An address that is reachable only recursively — via a route to a route — is treated as unusable and the set clause is skipped, silently, in favour of destination routing. Confirm: show ip route 203.0.113.9 shows a route that is not directly connected, and show ip cef 203.0.113.9 shows a recursive resolution. Fix: point the set clause at an address on a connected subnet, or use set interface on a point-to-point link, or add a static host route so the next hop becomes connected-adjacent.

Testing from the router

Pitfall: verifying interface PBR with a local ping Symptom: a ping from the router follows the normal routing table and the engineer concludes the policy is broken, then spends the next hour rewriting a route-map that was correct all along. Cause: interface PBR only sees packets arriving on the interface it is attached to. Traffic the router originates never arrives on any interface, so no interface policy can apply to it. Confirm: show route-map counters stay at zero during the local ping and increment as soon as a real client sends traffic. Fix: test from a host behind the ingress interface, or use an extended ping with a source interface that is behind the policy, and use ip local policy where router-originated traffic genuinely needs steering.

The deny clause

Pitfall: a deny clause used as a drop Symptom: traffic that was supposed to be blocked flows normally, and an ACL-based "block" built into a PBR route-map has no effect whatsoever. Cause: a deny clause in a PBR route-map means "exempt from the policy", and exempt traffic uses the routing table, which forwards it. The same is true of the implicit deny at the end. Nothing in PBR drops packets except an explicit set interface Null0. Confirm: the destination remains reachable from the source the deny clause named. Fix: use an ACL for filtering, and if a policy genuinely must discard traffic, say so explicitly with set interface Null0.

Discarding traffic on purpose

Since nothing in a PBR route-map drops by default, discarding requires naming the null interface. This is worth knowing as a technique — source-based blackholing at an ingress edge is a legitimate use — and worth flagging in review, because set interface Null0 in a policy nobody remembers is a very effective way to lose traffic invisibly.

! The only way a PBR clause discards traffic
route-map BLACKHOLE permit 10
 match ip address BAD-SOURCES
 set interface Null0
!
interface GigabitEthernet0/1
 ip policy route-map BLACKHOLE
!
! Confirm it is discarding, not just matching
R1# show route-map BLACKHOLE | include matches
  Policy routing matches: 4471 packets, 536520 bytes
R1# show interfaces Null0 | include packets input

A diagnostic order that works

The counter first, always. Zero means the traffic never reached the policy — wrong interface, wrong ACL, or the traffic is not what you think it is. Non-zero with unchanged forwarding means the set clause was skipped — an unreachable next hop, or a default form on a router with a route. That single branch resolves most PBR cases before any packet capture is needed.

! In this order, every time
show route-map CLIENT-PBR
! ^ counter 0? Wrong interface or wrong ACL. Stop here.
show ip interface GigabitEthernet0/1 | include policy
! ^ confirms the policy is attached where you think it is
show ip access-lists CLIENT-WEB
! ^ confirms the classifier is selecting what you meant
show ip route 203.0.113.9
! ^ next hop must be directly connected, not recursive
show track brief
! ^ if tracking is used, is the object up?
debug ip policy
! ^ last resort, and only with an ACL limiting it

Performance and platform notes

On modern IOS-XE platforms PBR is handled in CEF and carries no meaningful forwarding penalty for the common set actions. Some combinations — notably match length on certain platforms, and older set ip default next-hop implementations — have historically punted to the process path, which turns a line-rate policy into a CPU load. The check that matters before deploying a policy at scale is show ip cef switching statistics before and after, looking for a rise in punted packets rather than trusting a general claim about the platform.

Reviewing an inherited policy

Finding a PBR policy you did not write raises one question before any other: is it still doing anything? Run show route-map and note the counter, wait a working day, and read it again. A counter that has not moved describes a policy whose traffic no longer exists, and removing it is safe. A counter that moved tells you the policy is load-bearing and that whatever depends on it has to be understood before the route-map is touched.

The second question is what the policy would do if it were removed. Because PBR only overrides forwarding, the answer is always "the routing table decides", and the routing table can be read directly. Checking show ip route for the destinations the ACL selects tells you exactly where the traffic would go instead, which turns a risky removal into a change with a known outcome.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint lists policy-based routing under routing concepts, and lab tasks typically present it as a constraint rather than as a topic: a requirement that one class of traffic take a path the routing table does not choose. Recognising that phrasing as a PBR task, applying the route-map on the correct ingress interface, and reading the match counter before changing anything is most of what the topic asks for.

Every PBR policy is a permanent exceptionPBR does not expire, does not propagate, and does not appear in any routing output. A policy added for a two-week migration and never removed will still be steering traffic years later, and the person who finds it will have no way to know whether it is still needed. Give every policy a description that says why it exists and when it can go.
Sub claimFour of the five common PBR failures produce no error and no visible symptom, which is why the policy match counter — zero or non-zero — is the diagnostic that has to come first.

Conclusion

PBR is a small feature with an outsized capacity to confuse, and almost all of that confusion comes from three facts that read as counter-intuitive until they are internalised. It applies on ingress, so the interface that feels right is the wrong one. A deny clause exempts rather than drops, so an ACL borrowed from a security context classifies backwards. And the word default in a set action inverts the relationship with the routing table, turning an override into a fallback that a default route makes unreachable.

The resilience story is worth the extra configuration. Plain PBR notices only that the local interface went down, which means it keeps forwarding into a hole for exactly the failure mode that dominates provider handoffs and firewall paths. IP SLA with a tracked object turns that static override into one that reacts, and the asymmetric delay timers — down fast, up slow — are what stop a flapping link from moving production traffic back and forth. Probing a near target and a far target with a boolean object between them costs four more lines and distinguishes a dead peer from a dead path.

Above all, PBR is a local, manual, permanent exception with no propagation and no expiry. That makes it excellent for a small number of documented cases and a poor foundation for anything resembling a network-wide policy layer, where VRFs, overlays, or the routing table itself are the tools that scale. Write the description that says why the policy exists, read the match counter before changing anything, and PBR stops being the feature that ate an afternoon.

Reference Notes

  1. Cisco IOS documentation describes policy-based routing as applying to packets received on an interface, configured with ip policy route-map on that inbound interface.
  2. Cisco documentation describes ip local policy route-map as the mechanism for applying a policy to packets generated by the router itself, which are not subject to interface policies.
  3. Cisco documentation distinguishes set ip next-hop, which takes precedence over the routing table, from set ip default next-hop, which is used only when no explicit route to the destination exists.
  4. The same distinction applies between set interface and set default interface, with the default form consulted only after the routing table has produced no explicit route.
  5. Cisco documentation notes that a next hop specified in a PBR set clause must be reachable through a connected interface for the clause to be applied.
  6. Cisco documentation describes set ip next-hop verify-availability with a sequence number and a tracked object, so that unreachable next hops are skipped in favour of the next configured entry.
  7. Cisco IP SLAs documentation describes ICMP echo operations, their scheduling with ip sla schedule, and the statistics available through show ip sla statistics.
  8. Cisco object tracking documentation describes track ... ip sla ... reachability and the delay up and delay down timers used to damp state changes.
  9. Cisco object tracking documentation describes tracked lists, including track ... list boolean and, which combines multiple tracked objects into a single state.
  10. RFC 2474 defines the Differentiated Services field, the basis for the DSCP values settable in a PBR route-map with set ip dscp.
  11. RFC 1812 establishes the baseline requirement that IPv4 routers forward on destination address, which is precisely what policy-based routing overrides for selected traffic.
  12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include policy-based routing within the routing concepts area of the infrastructure domain.