Policy-Based Routing Guide

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 table

Design 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

1. Document the business reason for each policy.
2. Define exact source, destination, protocol, or segment matches.
3. Confirm the intended next hop and return path.
4. Decide fallback behavior for next-hop failure.
5. Apply policy at a controlled boundary and test with representative traffic.
6. 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.