Overview
Policy-Based Routing (PBR) lets the network steer selected traffic according to policy rather than destination routing alone. It is useful for campus security, WAN edge selection, service insertion, migration, and special application paths.
PBR should be narrow and intentional. The default routing table should still carry normal traffic, while policy rules handle traffic that truly needs a different path.
When To Use PBR
| Scenario | PBR Use |
|---|---|
| Firewall or inspection insertion | Send selected VLANs or applications through security services. |
| WAN edge selection | Steer traffic from a branch, building, or application toward a chosen uplink. |
| Migration | Redirect legacy services while new routing is introduced. |
| Guest or IoT segmentation | Send edge segments through controlled service paths. |
| Troubleshooting | Temporarily steer a narrow class of traffic for validation. |
Policy Components
| Component | Purpose | Design Note |
|---|---|---|
| Match criteria | Defines which traffic is selected. | Keep selectors specific and documented. |
| Next hop | Defines where selected traffic goes. | Use reachable and monitored next hops. |
| Fallback | Defines behavior when policy path fails. | Avoid silent blackholing. |
| Application point | Interface or routing boundary where policy is applied. | Apply close to the source when practical. |
Traffic Flow
Packet enters xSONiC switch
|
v
Does it match PBR policy?
| yes
v
Forward to configured next hop
|
v
If no match or fallback applies, use normal routing tableDesign Warnings
| Risk | Mitigation |
|---|---|
| Policy sprawl | Keep PBR limited to documented use cases. |
| Hidden asymmetric routing | Validate return path and firewall state. |
| Next-hop failure | Define fallback and monitoring behavior. |
| Operational confusion | Label policies by business purpose, not only ACL number. |
| Overlapping match rules | Order and test policy behavior carefully. |
Deployment Checklist
- Document the business reason for each policy.
- Define exact source, destination, protocol, or segment matches.
- Confirm the intended next hop and return path.
- Decide fallback behavior for next-hop failure.
- Apply policy at a controlled boundary and test with representative traffic.
- Monitor counters to confirm policy hit rate and path behavior.
xSONiC Platform Fit
XS-AA access and aggregation switches fit PBR use cases at campus routing boundaries. They can steer guest, IoT, branch, or selected application traffic toward firewall, WAN, inspection, or migration paths while preserving normal routing for the rest of the network.
Engineering Position
PBR is a precision tool, not a substitute for a clean routing design. It should be used when a narrow traffic class needs a different path for a stated business reason: inspection, migration, WAN selection, or service insertion. If every new requirement becomes another broad policy rule, the network becomes harder to reason about and harder to recover during incidents.
Every PBR rule should have an owner, a match definition, a next-hop decision, a fallback behavior, and an expiry or review date. The operator should also be able to prove that return traffic follows a valid path, especially when firewalls, NAT, or stateful inspection are involved.
Failure Modes To Test
| Failure Mode | Why It Matters | Test Evidence |
|---|---|---|
| Next-hop loss | Selected traffic may blackhole if fallback is not defined. | Failed next-hop replay and route-table output. |
| Overlapping match | A broad rule may catch traffic intended for another path. | Ordered rule list and per-rule hit counters. |
| Asymmetric return | Stateful services can drop return traffic. | Forward and return packet capture. |
| Policy drift | Rules may survive after the migration or exception is gone. | Owner, ticket, review date, and config diff. |
Engineering Validation Checkpoint
Policy-based routing must prove both intended forwarding and safe fallback. Validate 5 flows, 3 rules, 2 groups, and 1 failed next hop. Record route lookup, policy hit counters, ACL interaction, and rollback behavior.
| Check | Evidence to collect | Reject condition |
|---|---|---|
| Policy match | Flow tuple, rule hit counters, next hop, and route table output. | Traffic matches the wrong policy or bypasses a required security path. |
| Failure handling | Next-hop failure, fallback route, packet loss, and recovery timing. | Traffic blackholes or loops when a policy path fails. |
| Change control | Config diff, staged rollout, rollback, and telemetry export. | Operators cannot prove the policy change caused or did not cause an incident. |
Engineering FAQ
When should PBR be avoided?
Avoid PBR when ordinary routing, VRF separation, or firewall policy can solve the problem with clearer behavior. PBR is appropriate for narrow exceptions, but it becomes a risk when it hides broad design debt or sends operators to multiple places to understand one packet path.
What should be documented for every rule?
Document the source, destination, protocol or application, intended next hop, fallback behavior, rule owner, business reason, and review date. Also capture rule hit counters during the pilot so the team can see whether the policy is actually matching the expected traffic.
