What Is Policy-Based Routing?

Policy-based routing routes network traffic based on policy rules that might consider the source, application, user class, ports, or traffic class. This differs from traditional network routing, where the selected route is largely based on the shortest or most preferred route to the destination.

Policy-based routing can be used to achieve various goals, such as enhancing performance and reliability or implementing segmentation. These decisions may be based on application identification, allowing highly granular routing on a per-application basis.

Key Highlights

• Policy-based routing steers traffic using rule criteria beyond destination-only routing.
• Criteria often include source, destination, ports, protocol, DSCP, and application identity (when available).
• Some platforms combine policy intent with path telemetry to support SLA-based steering (for example: latency, loss, jitter). This is related to PBR but not required for classic PBR.
• PBR commonly steers application classes (for example: real-time collaboration vs bulk transfer) to preferred egress points or transports.
• Poorly designed policies can create asymmetric routing, unstable failover behavior, and hard-to-troubleshoot outcomes across sites.
• Successful programs treat routing policy as change-controlled logic with clear rule order, testing, observability, and rollback.

What Is Policy-Based Routing?

Policy-based routing allows an organization to control how certain types of traffic move over the network. This is accomplished by defining policies and network rules that specify where traffic should go on its next hop toward its destination.

These rules use various fields within a packet to match packets to policies. Commonly used match fields include:

• Source/destination
• Ports
• Protocol
• DSCP
• Application category

Based on these fields, the traffic is mapped to a policy, which can specify the next action that the traffic should take. Common actions include:

• Choosing the next hop
• Choosing the interface or egress used to leave the network
• Choosing the tunnel or transport protocol
• Selecting a routing table or VRF
• Preferring one path with an explicit fallback (when supported)

Policy-based routing focuses on where to route traffic, allowing firewalls or access control lists (ACLs) to implement allow/deny rules. Policies are often implemented as ordered rule lists – where the first match wins – to resolve conflicts when traffic matches multiple rules.

Policy-based routing is not a routing protocol like Border Gateway Protocol (BGP) or Open Shortest Path First (OSPF). It also can’t magically fix last-mile issues since it only defines how traffic should use available routes and bandwidth.

Why Do Organizations Use Policy-Based Routing?

Policy-based routing offers greater granularity and control than traditional destination-based routing. Organizations can use it to achieve various outcomes, including:

• Enhanced performance for latency- sensitive apps
• Improved resiliency
• Deterministic segmentation
• Cost control

Traditional network routing takes a “one size fits all” approach to routing, treating voice/video, SaaS, bulk backup, and admin traffic the same. By defining specific policies for these, organizations can ensure that more important and sensitive traffic is treated appropriately.

However, defining and implementing additional policies introduces additional complexity and overhead. Governance and testing are essential to ensure that policies work as designed and that the number of policies doesn’t spiral out of control.

How Does Policy-Based Routing Work?

Policy-based routing works via a multistage process. Key steps include:

• Traffic identification and classification
• Extraction of match fields
• Finding matching policies and applying the first
• Applying the specified policy action (next hop, egress, tunnel, etc.)
• Applying fallback action if needed
• Verifying success with logs or telemetry

Implementing policy-based routing requires selecting the conditions used to match traffic to policies, defining the actions taken in response to a match, and enforcing policies across the network.

Define match conditions

Policy-based routing uses a variety of match fields to select appropriate policies rather than simply the traffic’s destination. When implementing it, the first step is to define the match conditions that will be used to select an appropriate policy.

Policies can be matched using a variety of different fields, such as source/destination, ports, protocol, and DSCP. Modern systems increasingly rely upon application classification to apply specific policies to application traffic, even if the majority of the traffic flows over the same ports and protocol (443/HTTPS). When defining criteria, consistent identity sources (apps, devices, and users) are essential to ensure consistent enforcement across the corporate WAN.

When defining match criteria for policies, it’s wise to keep them as mutually exclusive as possible to limit the number of matches for a particular packet. When multiple policies match, conflicts are resolved via rule ordering, making careful consideration of these priorities essential to ensure that the appropriate policy is applied to traffic.

Choose an action (next hop, egress, tunnel, transport)

Policies can be defined to take various actions for matching traffic. In general, these fall into two main categories:

• Deterministic Actions: Traffic may be routed to a fixed next hop, egress, or tunnel.
• Policy and Measured Path Selection: Combines policy-based routing with measured path selection to support SLA-based or application-aware steering.

Often, policies are defined with a preferred path as well as a fallback in the event that something goes wrong. Policies may also include SLA thresholds regarding latency, loss, and jitter in the decision-making process as well.

When defining policies, it’s important to avoid policy loops that can break workflows. Additionally, the use of IP pinning in policies for cloud apps can introduce fragility and break policies if IP addresses change.

Enforce globally and validate outcomes

Policy-based routing should be enforced consistently across the enterprise, ensuring the same intent, predictable behavior, and measurable results in all environments. When implementing policy-based routing at scale, best practices include:

• Using testing tools and simulation, where possible, to test policies before deployment
• Implementing change control policies to manage the creation of new policies
• Considering the effects of asymmetric routing on stateful traffic inspection and troubleshooting
• Monitoring path selection rates, SLA violations, and failover events when evaluating policy success
• Implementing policy-based routing as a staged process, starting small and expanding carefully

What Criteria Should Policies Use for Traffic Steering?

Policies should use a few different types of criteria when steering traffic. These include:

• Identity (user and device)
• Application or workload
• Network data (source, destination, and ports)
• Quality (latency, loss, and jitter)
• DSCP (QoS markings identifying various types of traffic)

When defining criteria, it’s important to strike a balance between broad and narrow matches. Broader matches are easier to implement but may accidentally steer unintended traffic as well. Narrower matches have lower risk but increase the number of required rules.

Policies must also be prioritized to resolve conflicts when multiple policies match a packet. When defining priorities, a recommended order is:

• Business-critical real-time
• Interactive business apps
• Bulk and backup traffic
• Best effort

What Are Common Policy-Based Routing Use Cases?

Policy-based routing is intent-based steering designed to route traffic over a particular path or egress based on its needs, not its intended destination. Common use cases include:

• Real-Time Apps: Sensitive to latency, loss, and jitter
• Business-Critical SaaS: Requires reliable connectivity
• Bulk or Background Traffic: Throughput-hungry but tolerant
• Segmented and Controlled Egress Traffic: Egress point and route are important considerations

Policy-based routing steers traffic to a particular path but doesn’t necessarily force traffic through specific intermediate hops. Additionally, policies commonly consider link health as well, routing traffic to an alternative path if the preferred link fails an SLA threshold. However, the same use cases that make PBR valuable also create risk. Overlapping criteria, inconsistent rule order, and asymmetric routing can cause brittle outcomes if policies are not designed and tested carefully.

Real-time communications and collaboration

One common use case for policy-based routing is to enhance the performance and reliability of latency-sensitive traffic. For example, voice and video traffic should be steered to the best quality path to reduce the risk that jitter and loss will impact call quality. However, traffic shouldn’t be oversteered mid-call without guardrails due to the risk that traffic could be lost as a result.

Policy-based routing can also complement prioritization. In this case, this type of traffic would also be prioritized within the selected path.

Segmentation and controlled egress

Policy-based routing can also be used to implement segmentation and controlled access, requiring admin, regulated, or sensitive workflows to pass through specific inspection points or egress locations. For example, traffic from a particular subnet may be required to pass through an enforcement point en route to any other subnet.

When implementing segmentation and controlled egress, it’s important to note that return traffic may not necessarily follow the same path. Additionally, this use case can run the risk of introducing policy sprawl unless managed via tools like naming, tags, and templates.

Cost control and capacity management

A third application of policy-based routing is for cost and capacity management, reserving premium and more expensive paths for critical apps and cheaper links for bulk traffic. For example, backups, patching, and large file transfers should be routed over cost-effective paths since minor increases in network latency have a negligible impact on them.

These use cases are often driven by issues related to network congestion and rising latency on network paths that impact the performance of business-critical apps. The effectiveness of rerouting less critical traffic to cheaper links may become evident after comparing the performance of business-critical traffic during congestion events before and after implementing these policies.

What Can Go Wrong With Policy-Based Routing?

When implementing policy-based routing, common failure modes and pitfalls include:

• Asymmetric Routing: An organization can choose which egress point or path to send outbound traffic on, but inbound traffic within the session may take a different path. This can introduce issues if security tools and enforcement points only see half of the conversation.
• Policy Conflicts: When matching packets to policies, it’s possible that multiple policies will be a match. Rule ordering is used to solve these conflicts, which may mean that the correct policy isn’t the one selected.
• Rule Shadowing: Rule shadowing is a type of policy conflict where a general policy is higher in the ordering than a more specific one. This means that the specific one will never be applied.
• Brittle Matching: Brittle matching can be an issue if policy matches are too tightly defined. In this case, small deviations in match fields may cause the policy to no longer match and be applied.

These challenges may be solved only by analyzing a packet capture of the network traffic. This can help to determine whether the correct policies were applied in various situations. In general, a good mitigation strategy is to simplify rules, implement logging, test policies, stage changes, and validate per site.

Beyond the technical failure modes, organizations may struggle with governance. Common pitfalls include unmanaged exceptions, lack of documentation, no test plan, and no rollback.

FAQ

What is the difference between policy-based routing and dynamic routing?

Policy-based routing uses predefined policies and criteria to define how traffic should be routed. In contrast, dynamic routing is primarily based on the destination IP address and the health of various network links.

Is policy-based routing the same as application-aware routing?

Policy-based routing and application-aware routing both consider various factors when making routing decisions. However, policies are generally defined using static match fields (port, protocol, etc.), while application-aware routing considers SLA factors like latency, jitter, and packet loss when making routing decisions.

What match criteria are most reliable for cloud applications?

Application identification is the most reliable match criterion for cloud applications since cloud infrastructure is ephemeral. IP pinning is unreliable in these contexts since key IP addresses may change.

How do teams test routing policies safely?

When possible, testing should be performed in a test environment or via simulation. When rolling out to production, changes should be implemented in stages with extensive validation and testing.

What are the biggest signs that a PBR design is too complex?

Indications that a PBR design is too complex include a large number of policy exceptions, inconsistent outcomes, and frequent emergency changes. If this is the case, simplify, validate changes, and implement change management rules for policy creation.

Implementing Policy-Based Routing with Cato Networks

The Cato SASE Cloud Platform is implemented as a global network of SASE PoPs backed by a dedicated private backbone. Administrators can define network rules that specify how particular type sof traffic should be routed over the network to enhance performance or control costs. Additionally, Cato’s private backbone inherently offers greater reliability, performance, and control than the public Internet.

The Cato SASE Cloud Platform offers both security integration and granular control over network routing and performance. To learn more about the potential benefits for your business, schedule a demo.