Glossary

Policy-Based Routing

What is Policy-Based Routing

Policy-Based Routing is a routing mechanism that forwards packets according to custom-defined policies rather than purely by destination address. Ordinary routing makes one decision for every packet headed to the same destination — whatever the routing table says is the best path. Policy-Based Routing lets network operators override that, deciding where traffic goes based on characteristics of the traffic itself.

That distinction is what makes Policy-Based Routing useful for flexible traffic scheduling and refined traffic management. Two flows leaving the same source, headed toward the same general direction, can be sent down entirely different paths — one toward a firewall or inspection appliance, another straight out to the Internet; one across a premium low-latency link, another across a cheaper high-capacity one. The routing table alone can't express that kind of intent, because it only knows about destinations.

How Policy-Based Routing Works

Policy-Based Routing works by defining match conditions and pairing them with forwarding actions, then binding the resulting policy to an interface so it applies to traffic entering there.

Matching happens against a set of packet characteristics. A Policy-Based Routing policy can match on source IP address, destination IP address, IP protocol (TCP or UDP), source TCP/UDP port, and destination TCP/UDP port — individually or in combination. Because these fields span Layer 3 and Layer 4, a policy can be as broad as "everything from this subnet" or as specific as "TCP traffic from this host to this port on that server."

Actions determine where matched packets go. The essential action is setting the next hop — an explicit IPv4 or IPv6 address that the packet should be forwarded to, bypassing whatever the routing table would have chosen. Alternatively, a policy can point at a next-hop group: a named collection of next-hop addresses defined separately, so a single group can be referenced by multiple policies and updated in one place rather than edited across every rule that uses it.

A complete policy is built from numbered sequence entries. Each entry pairs its own match conditions with its own action, and entries are evaluated in sequence order — so a policy can express several distinct rules at once, for example sending traffic from one source subnet toward one next hop and traffic from a different subnet toward another. Because the sequence number controls evaluation order, more specific rules can be placed ahead of broader catch-all rules.

Finally, a policy has to be bound to an interface to take effect. Binding is what determines which traffic the policy actually inspects: it applies to packets arriving on that interface, which is why Policy-Based Routing is typically configured on the ingress-facing port closest to the traffic source whose behavior the operator wants to control.

Why Policy-Based Routing is Beneficial

  • Routes on intent, not just destination: Matching on source, protocol, and port lets operators express forwarding decisions that the destination-based routing table fundamentally can't represent.

  • Enables flexible traffic scheduling: Different flows from the same source can be deliberately steered onto different paths, improving how effectively a network's available links actually get used.

  • Supports service insertion: Specific traffic can be directed through firewalls, inspection appliances, or proxies while other traffic bypasses them entirely — without physically re-cabling anything or redesigning the topology.

  • Granular control without global disruption: Because a Policy-Based Routing policy is bound per-interface, its effect is scoped precisely to the traffic entering where it's applied, rather than changing routing behavior network-wide.

  • Maintainable at scale with next-hop groups: Referencing a named next-hop group instead of hard-coding addresses in every rule means a next-hop change is a single edit, not a sweep through every policy that happens to use it.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements PBR as a straightforward, CLI-configurable policy framework, with full Layer 3/Layer 4 matching and both direct and grouped next-hop actions.

  • Full five-field matching: match {dst-ip | dst-port | ip-protocol {tcp|udp} | src-ip | src-port} covers source and destination IP, source and destination port, and IP protocol — the complete set of fields needed to distinguish flows by more than just where they're headed.

  • Multi-rule policies with explicit ordering: pbr-map <name> seq <seq-num> supports sequence numbers from 1 to 700, so a single named policy can carry many independently matched rules, evaluated in a deliberate, operator-controlled order.

  • Direct next-hop or next-hop group actions: set nexthop <A.B.C.D | X:X::X:X> sets an explicit IPv4 or IPv6 next hop, while set nexthop-group <name> — paired with a nexthop-group definition — lets operators maintain shared next-hop sets independently of the policies that reference them.

  • Simple per-interface binding: pbr-policy <pbr-map-name> applied inside an interface configuration view binds a policy to Ethernet or link-aggregation interfaces, keeping the scope of each policy explicit and easy to audit.

  • Verification across all three layers of the configuration: show pbr interface confirms which policy is bound where, show pbr map (with an optional detail flag) shows each sequence entry's match conditions, action, and installation status — including a specific reason when a rule isn't installed — and show pbr nexthop-groups displays next-hop group state, with JSON output available on all three for automation and monitoring integration.

  • Documented, real-world deployment pattern: AsterNOS's PBR documentation walks through a complete traffic-steering example — a single source sending two flows, matched by source subnet, and forwarded to two different downstream hosts through separate next hops — exactly the flexible-scheduling use case PBR is designed for.