Blog

Policy-Based Routing for Enterprise Campus Networks: When Destination-Only Routing Is Not Enough

Learn how policy-based routing (PBR) solves traffic engineering, security segmentation, and application-aware forwarding challenges in enterprise access and aggregation networks -- without proprietary lock-in.

By xSONiC Team · · SONiCopen networkingAI fabricEthernetautomationpacket broker

Most enterprise campus networks still forward traffic based on a single criterion: the destination IP address. That model works fine when every application behaves the same way, every user needs the same path, and every compliance boundary maps cleanly to a subnet. In practice, none of those assumptions hold in a modern Australian enterprise campus.

Policy-based routing (PBR) lets network teams override the destination-based forwarding decision and route packets based on source address, protocol, port number, DSCP marking, packet length, or a combination of match criteria. When deployed at the access or aggregation layer, PBR gives enterprises fine-grained traffic steering without bolting on an expensive overlay.

This article explains what PBR does, where it fits in campus network design, and why open networking platforms like those running SONiC give Australian enterprises a practical path to policy-driven forwarding without proprietary lock-in.

Why Destination-Based Routing Breaks Down in Campus Networks

Traditional campus architectures assume a simple model: access switches connect endpoints, aggregation switches aggregate uplinks, and the core or distribution layer makes routing decisions based on destination prefixes. That model was adequate when most traffic flowed north-south to a central data centre or internet breakout.

Several trends have changed the picture:

  • Hybrid work and cloud-first applications. Staff connect from campus, home, and branch locations. Traffic to Microsoft 365, Salesforce, and SaaS platforms now rivals or exceeds traffic to on-premises servers. Routing all SaaS traffic through a centralised internet gateway adds latency and cost.
  • Security segmentation requirements. Compliance frameworks such as the Australian Government Information Security Manual (ISM) and industry-specific standards demand traffic isolation between user groups, IoT devices, and sensitive workloads. VLANs alone cannot enforce inter-VLAN routing policy at scale.
  • Multi-path aggregation fabrics. Modern aggregation layers often use MC-LAG, MLAG, or virtual chassis designs that provide multiple equal-cost or unequal-cost paths. Without policy control, the network cannot prefer one path for latency-sensitive traffic and another for bulk transfers.
  • Application-aware SLAs. Voice, video, real-time collaboration, and industrial control traffic need deterministic forwarding. Destination-based ECMP hashing cannot distinguish a Teams voice flow from a software update download headed to the same CDN edge.

PBR addresses each of these gaps by letting the network team define match-and-forward rules at the point where traffic enters the campus fabric: the access or aggregation switch.

What Policy-Based Routing Actually Does

At its core, PBR replaces or supplements the standard routing table lookup for packets that match a defined policy. The forwarding decision can:

  • Redirect traffic to a specific next-hop. For example, send all traffic from the finance VLAN destined to the internet through a next-generation firewall cluster rather than the default gateway.
  • Set a DSCP or traffic class. Mark packets so downstream switches and routers apply the correct QoS treatment without re-classifying.
  • Drop or deny traffic. Act as a lightweight access control mechanism at the routing layer, complementing ACLs.
  • Load-balance across paths based on policy. Steer high-priority traffic over a low-latency link and bulk traffic over a secondary path, rather than relying on ECMP hashing alone.

A typical PBR configuration involves three elements:

  1. Match criteria. Source IP subnet, destination port, protocol, DSCP value, VLAN ID, or a combination.
  2. Action. Set next-hop IP, set DSCP, redirect to a tunnel interface, or drop.
  3. Application point. The ingress interface or VLAN where the policy is applied.

On a switch running SONiC, PBR policies are configured through the standard SONiC configuration model, leveraging access control lists (ACLs) with redirect actions. This means the same declarative, JSON-based configuration workflow that manages VLANs, L3 interfaces, and BGP peers also manages PBR rules. Network automation tools that interact with SONiC via NETCONF, RESTCONF, or gNMI can push PBR policies as part of a broader campus configuration pipeline.

PBR Design Patterns for Access and Aggregation Layers

Pattern 1: Internet Breakout Steering

In a multi-site campus with distributed internet breakout, PBR at the aggregation layer can steer SaaS traffic directly to the local internet gateway while sending corporate application traffic to a centralised security stack. Match criteria might include destination prefixes for known SaaS providers (pulled from a regularly updated object group) combined with source VLANs for corporate versus guest users.

This pattern reduces backhaul cost and improves SaaS performance without requiring a full SD-WAN overlay.

Pattern 2: Security Zone Enforcement

When the campus network includes IoT devices, guest Wi-Fi, and corporate endpoints on separate VLANs, PBR can enforce that IoT traffic always traverses a firewall or network access control (NAC) appliance before reaching any other zone. The aggregation switch applies a PBR rule matching the IoT subnet and redirecting all traffic to the security appliance next-hop.

This approach is simpler to audit than relying solely on inter-VLAN ACLs spread across dozens of access switches.

Pattern 3: Application-Aware Path Selection

In aggregation fabrics with redundant paths — for example, an MC-LAG pair providing two active uplinks — PBR can direct latency-sensitive traffic (voice, video, real-time telemetry) over the path with lower measured latency or jitter, while bulk data takes the alternate path. Match criteria use DSCP markings applied at the access layer by endpoint QoS policies or by the access switch itself.

Pattern 4: Compliance-Driven Traffic Mirroring or Redirection

Australian organisations subject to data sovereignty requirements may need to ensure that certain traffic flows through inspection or logging infrastructure before leaving the campus. PBR at the aggregation layer can redirect flows matching specific source-destination pairs to a packet broker or inline inspection tool.

PatternMatch CriteriaActionTypical Deployment Point
Internet breakout steeringSource VLAN + destination prefixSet next-hop to local internet gatewayAggregation layer
Security zone enforcementSource subnet (IoT, guest)Redirect to firewall next-hopAggregation layer
Application-aware path selectionDSCP marking or protocol/portSet next-hop to preferred uplinkAccess or aggregation layer
Compliance traffic redirectionSource-destination pairRedirect to inline inspection toolAggregation layer

Why Open Networking Changes the PBR Equation

Traditional campus switch vendors support PBR, but the implementation is often tied to proprietary CLI syntax, proprietary management platforms, and licensed feature tiers. In some cases, PBR is only available on premium switch models or requires a separate license key. This creates a situation where a foundational routing capability becomes a vendor tax.

SONiC-based open networking platforms break that pattern in several ways:

  • Consistent configuration model. PBR rules are expressed through the same SONiC configuration schema used for VLANs, interfaces, and routing. No proprietary CLI to learn.
  • Automation-native. Because SONiC configuration is JSON-based and supports standard management interfaces (NETCONF, RESTCONF, gNMI, REST API), PBR policies can be version-controlled, peer-reviewed, and deployed through CI/CD pipelines — the same way infrastructure teams manage compute and storage.
  • Hardware decoupling. SONiC runs on switches from multiple hardware vendors built on merchant silicon from vendors such as Broadcom and Marvell. This means PBR capabilities travel with the NOS, not the hardware SKU.
  • Community-driven feature velocity. The SONiC open-source project, hosted under the Linux Foundation, benefits from contributions by hyperscale operators, silicon vendors, and enterprise users. PBR and ACL redirect features have been production-hardened in large-scale data centre environments and are now available for campus use cases.

For Australian enterprises evaluating a campus refresh, this means PBR should not require a forklift upgrade to a premium switch tier. It should be a baseline capability of the access and aggregation platform.

Practical Considerations for Australian Campus Deployments

Scale and Rule Complexity

PBR rules are processed in hardware (ASIC-based ACL/redirect lookups) on modern switches, so performance at line rate is achievable. However, the number of PBR rules that can be applied per interface depends on the switch ASIC and its TCAM or ACL table capacity. Before deploying hundreds of PBR rules at the access layer, validate rule capacity against the target hardware platform.

Interaction with STP, MC-LAG, and Virtual Chassis

PBR does not replace spanning tree or MC-LAG. It operates at Layer 3 and supplements the forwarding decision after the Layer 2 topology has determined which physical path is available. In an MC-LAG or virtual chassis design, PBR next-hops must point to addresses that remain reachable during failover events. Validate that PBR policies degrade gracefully during link or node failures.

Operational Tooling

PBR rules that are manually configured on individual switches create operational risk. Treat PBR policies as code: store them in a Git repository, validate them in a lab or virtual SONiC instance, and deploy through tested automation. This approach aligns with the operational model that SONiC encourages and reduces the risk of configuration drift across dozens of aggregation switches.

Observability and Troubleshooting

When a packet takes an unexpected path, the network team needs to confirm which PBR rule matched (or did not match). SONiC provides standard Linux diagnostic tools and show commands to inspect ACL counters and forwarding decisions. Packet broker integration — mirroring traffic to a visibility platform — adds another layer of diagnostic capability for PBR-steered flows.

Where PBR Fits in the Campus Refresh Conversation

If your organisation is planning a campus refresh in the next 12 to 24 months, PBR should be on the evaluation checklist alongside VLAN design, Layer 3 routing protocol selection, MC-LAG or virtual chassis topology, PoE capacity, and wireless integration. It is not an advanced feature reserved for data centre fabrics. It is a practical tool for solving real campus traffic engineering problems.

The key question is not whether your vendor supports PBR, but whether your platform makes PBR operationally sustainable: version-controlled, automatable, hardware-decoupled, and free from per-feature licensing.

Open networking answers that question differently than proprietary alternatives.

Next Steps

Sources Reviewed