Two different problems, the same tool — sending traffic to a specific next hop based on where it came from or what application it is, instead of whatever the routing table would otherwise pick — interface-level matching by source and by application, a network-wide redirect, verification commands, and where policy-based routing stops and route-policy begins.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The routing table answers "how do I reach this destination." Policy-based routing answers a different question: given who's asking and what they're asking for, which way should this particular traffic actually go.
A normal routing table makes one decision per destination, and every host sending to that destination gets the same answer. That's fine until it isn't — until one internal source needs a specific path regardless of what the routing table says about the destination, or one application needs its own path for latency or cost reasons while everything else takes the default route. Policy-based routing (PBR) exists for exactly this gap: it matches traffic first — by source address, protocol, port, whatever a traffic classifier can express — and only then decides the next hop, ahead of and independent from the routing table's own decision.
Below are two worked configurations: matching traffic on a single inbound interface by source address and by application (HTTP), each redirected to a different next hop; and a network-wide policy that redirects one source-destination pair's traffic to a specific router regardless of what the normal routing table — built here by OSPF — would otherwise choose. If your scenario is closer to sending each internet uplink's traffic out its own link with automatic failover, that's a related but different problem — see our dual-WAN failover and load-sharing configuration note for that.
One router, several interfaces, and two independent matching rules deciding which packets get redirected before the routing table ever sees them.
Diagram labels are kept in English for engineering clarity.
Traffic Classifiers and Redirect Targets
| Match | Redirect Next Hop | Precedence |
|---|---|---|
| ACL 3005 — source 10.2.1.1/32 | 10.5.1.2 | 5 — evaluated first |
| ACL 3006 — destination-port www (HTTP) | 10.3.1.2 | 10 |
| Unmatched traffic | 10.4.1.2 | Normal routing table — static route preference 40 |
Five moves: define the match, pair it with a redirect, bind everything into one policy with precedence, apply it to the right interface and direction, and make sure unmatched traffic still has somewhere to go.
#
sysname Router
#
acl number 3005
rule 0 permit ip source 10.2.1.1 0
#
acl number 3006
rule 0 permit tcp destination-port eq www
#
traffic classifier 10.2.1.1 operator or
if-match acl 3005
traffic classifier www operator or
if-match acl 3006
#
traffic behavior 10.2.1.1
redirect ip-nexthop 10.5.1.2
traffic behavior www
redirect ip-nexthop 10.3.1.2
#
traffic policy pbr
classifier 10.2.1.1 behavior 10.2.1.1 precedence 5
classifier www behavior www precedence 10
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
traffic-policy pbr inbound
#
interface GigabitEthernet2/0/1
ip address 10.3.1.1 255.255.255.0
#
interface GigabitEthernet2/0/2
ip address 10.4.1.1 255.255.255.0
#
interface GigabitEthernet2/0/3
ip address 10.5.1.1 255.255.255.0
#
ip route-static 192.168.1.0 24 10.3.1.2
ip route-static 192.168.1.0 24 10.4.1.2 preference 40
ip route-static 192.168.1.0 24 10.5.1.2
#
returnThree static routes reach the same 192.168.1.0/24 prefix on purpose — 10.4.1.2 carries the lower preference (40) so it wins the routing table's own selection for unmatched traffic, while 10.3.1.2 and 10.5.1.2 stay reachable purely so PBR's redirected next hops are valid.
A different, larger network illustrates this at scale: RouterA, RouterB and RouterC share routes through OSPF, and the routing table alone would send 10.0.2.0/24-to-10.0.0.0/24 traffic via RouterC. A traffic policy on RouterA redirects that one flow to RouterB instead.
#
acl number 3001
rule 5 permit ip source 10.0.2.0 0.0.0.255 destination 10.0.0.0 0.0.0.255
#
traffic classifier rdt operator or
if-match acl 3001
#
traffic behavior rdt
redirect ip-nexthop 10.181.10.2
#
traffic policy rdt
classifier rdt behavior rdt
#
interface GigabitEthernet1/0/0
ip address 10.181.20.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.181.10.1 255.255.255.0
#
interface GigabitEthernet3/0/0
ip address 10.0.2.1 255.255.255.0
traffic-policy rdt inbound
#
ospf 1
area 0.0.0.0
network 10.0.2.0 0.0.0.255
network 10.181.20.0 0.0.0.255
network 10.181.10.0 0.0.0.255
#
return#
interface GigabitEthernet1/0/0
ip address 10.181.10.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.184.10.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.181.10.0 0.0.0.255
network 10.184.10.0 0.0.0.255
#
return#
interface GigabitEthernet1/0/0
ip address 10.181.20.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.184.10.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.184.10.0 0.0.0.255
network 10.181.20.0 0.0.0.255
network 10.0.0.0 0.0.0.255
#
returnDespite the similar name, route-policy is a completely different mechanism operating on a different plane. Route-policy (configured with route-policy ... permit/deny node ...) filters and modifies routes themselves as they're learned or advertised between routing protocols — for example applying a local-preference or community attribute to BGP routes, or controlling which routes get redistributed from one protocol into another. Policy-based routing, by contrast, never touches the routing table or the routes in it — it intercepts already-arrived packets on an interface and forwards them to a specific next hop based on a traffic classifier, regardless of what the routing table says. A route-policy changes what routes exist and how they're tagged; a traffic policy with PBR changes where already-decided packets actually go. One detail worth borrowing from route-policy configuration: a route-policy needs an explicit, empty permit node at the end, or routes that matched none of the earlier nodes get silently filtered out — a different failure mode from PBR's own unmatched-traffic behavior, but a similar instinct to check for.
Check the classifier, the behavior and the policy independently, then confirm with a trace that traffic actually leaves through the redirected next hop.
<Host> tracert -a 10.0.2.1 10.0.0.1
1 10.181.20.1 3 ms 2 ms 1 ms
2 10.181.10.2 4 ms 3 ms 3 ms
3 10.184.10.1 5 ms 4 ms 4 ms
4 10.0.0.1 6 ms 5 ms 5 msThe second hop (10.181.10.2) is RouterB's address — confirming the traffic policy redirected this flow there instead of the OSPF-preferred path through RouterC. Your own hop addresses and timings will differ; what matters is which router the trace passes through.
The ones that turn a working redirect into traffic that silently goes the wrong way, or nowhere at all.
SYMPTOMTraffic that clearly doesn't match any classifier in the policy still ends up dropped or misrouted, instead of just following the normal routing table.
CAUSEApplying traffic-policy inbound on an interface doesn't create a default-deny the way some ACL logic does — but if the interface's normal route to that destination is itself missing or wrong, there's nothing sane for unmatched traffic to fall back to. PBR only decides for what it explicitly matches; everything else needs a working routing table entry to begin with.
FIXConfirm normal reachability (a route in display ip routing-table) for the destination before layering PBR on top — PBR replaces the next hop for matched traffic, it doesn't create reachability out of nothing.
SYMPTOMA static route to the redirect next-hop address exists, but display ip routing-table shows a completely different route winning for that same prefix.
CAUSEredirect ip-nexthop forwards matched packets to that address directly — it doesn't require that address's route to be the routing table's own best path. In the worked configuration here, three static routes to the same prefix coexist deliberately: one wins the routing table's own selection (lowest preference value) for unmatched traffic, while the other two exist purely so PBR's redirected next hops are reachable at all.
FIXDon't assume the redirect next hop needs to "win" any route comparison — verify reachability to it directly (ping it, or check the specific static route), not by checking which route the table currently prefers.
SYMPTOMA packet that should clearly hit the more specific rule — say, one matching a specific source address — instead gets redirected by the broader application-based rule, or vice versa.
CAUSEA traffic policy evaluates its classifier-behavior pairs in precedence order — lower precedence number first — and stops at the first match, the same way an ACL stops at its first matching rule. If the more general rule has a lower precedence number than the more specific one, the general rule wins even when both could match.
FIXGive the more specific match the lower precedence number, exactly as in the worked configuration — the source-address match sits at precedence 5, ahead of the application match at precedence 10.
SYMPTOMTraffic that clearly matches the ACL used in a classifier still isn't redirected.
CAUSEThe policy is bound with a direction — inbound on one specific interface. It only evaluates traffic as it arrives on that exact interface in that direction; traffic originating elsewhere on the router, or arriving on a different interface, never passes through that policy at all.
FIXConfirm which physical interface the traffic in question actually enters through, and make sure that's the interface — and direction — the traffic-policy is applied to, not just any interface in the path.
SYMPTOMSomeone tries to steer one specific source's traffic to a specific next hop by editing a route-policy applied to a routing protocol, and it does nothing for that traffic.
CAUSERoute-policy shapes which routes exist and their attributes in the control plane — it has no concept of "this specific source's packets," only of routes and their attributes as protocols exchange them. Steering one source's traffic to a specific next hop, regardless of the destination's normal best route, is a data-plane, per-packet decision — that's what PBR is for.
FIXUse PBR when the deciding factor is something about the packet itself (source, protocol, port); use route-policy when the deciding factor is something about the route (which protocol learned it, its attributes, whether it should be redistributed at all).
This note is based on two worked configurations: interface-level PBR matching by source address and by HTTP destination port with two independent redirect targets, and a network-wide PBR redirect layered on top of an OSPF-routed network. It doesn't cover PBR based on packet length or DSCP/precedence marking, load-balancing traffic across more than one redirect next hop, or applying policy-based routing outbound rather than inbound. It also doesn't cover route-policy itself in depth — route-policy shapes routes, not packets, and deserves its own treatment; what's here is only the distinction needed to pick the right tool.
Pulled from the same configuration cases this note is built on.
No — it sits ahead of it for matched traffic only. Anything a traffic classifier doesn't explicitly match still falls through to the normal routing table exactly as if PBR weren't configured at all.
Yes — anything an ACL (or a more complex traffic classifier) can express is fair game: source, destination, protocol, port ranges, and more. The two examples here — source address and HTTP destination port — are simply the ones the underlying worked configuration illustrates.
Route-policy operates on routes themselves — filtering or tagging what a routing protocol learns or advertises. PBR operates on packets that have already arrived — redirecting them to a specific next hop based on a traffic classifier, without changing any route or route attribute at all. See the comparison in the configuration section above for the full distinction.
It's related but distinct. That's usually built with equal- or unequal-preference static routes (for load sharing or primary/backup) rather than a traffic-policy redirect — see our dual-WAN failover and load-sharing configuration note for that specific design.
Yes — redirect ip-nexthop still needs that next-hop address to be genuinely reachable; PBR decides that a matched packet goes there, but it doesn't manufacture reachability. As shown in gotcha 2 above, that route doesn't need to be the routing table's own preferred path for the prefix, it just needs to exist.
The configuration keyword supports both directions, but inbound on the interface where the traffic actually originates from the source you're matching is the far more common and predictable placement — it catches the traffic at the earliest point, before any other forwarding decision has a chance to apply.
Tell us which traffic — by source, application or link — needs to go where, and we'll help you write the classifier and precedence order correctly.