ArubaOS-CX Policy-Based Routing (PBR) Configuration

Policy-based routing on ArubaOS-CX lets you override the routing table for selected traffic - sending a subnet to a specific next hop, or steering traffic to a firewall that the destination-based table would skip. It is the Swiss army knife of migrations and security enforcement, because it needs no change to the routing protocol configuration. This guide walks the three-object model ArubaOS-CX uses, the CLI for each, and the verification that proves the policy is actually matching.

The Three-Object Model

ArubaOS-CX separates policy-based routing into three pieces:

• Class - what to match (source or destination address and port, protocol, DSCP, VLAN, interface).
• Action list - what to do with matching traffic, primarily a next hop, with optional fallback behaviour.
• Policy - binds a class to an action list as an ordered rule, and is applied to an interface direction.

Keeping the classes reusable is the point: one class can be referenced by several policies with different action lists, and one action list can serve several classes.

Create the Class

switch(config)# class ip PBR_CLASS_WEB
switch(config-class-ip)# 10 match any any any
switch(config-class-ip)# exit

switch(config)# class ip PBR_CLASS_APP
switch(config-class-ip)# 10 match tcp 10.20.0.0/16 0.0.0.0 any eq 443
switch(config-class-ip)# exit

The any any any form is a catch-all class, useful as the last rule in a policy to define default behaviour for everything the policy touches.

Create the Action List

switch(config)# policy PBR_APP
switch(config-policy)# 10 class ip PBR_CLASS_APP action PBR_ACT_FW
switch(config-policy)# exit

switch(config)# action-list type modify ip PBR_ACT_FW
switch(config-action-list)# 10 nexthop 10.0.0.254
switch(config-action-list)# 20 default-nexthop
switch(config-action-list)# exit

Two options here decide failure behaviour. nexthop sends matching traffic to the specified address; if that next hop is unreachable, matching traffic is dropped unless a further rule or default-nexthop provides a fallback. The default-nexthop keyword restores normal routing for that traffic, which is almost always what you want as the second entry so that a failed next hop degrades to the routing table instead of black-holing the flow.

An interface-based next hop is also supported, which is useful for tunnels and P2P links where the address may move:

switch(config-action-list)# 10 nexthop interface 1/1/10

Apply the Policy to an Interface

switch(config)# interface 1/1/1
switch(config-if)# apply policy PBR_APP in
switch(config-if)# exit
switch(config)# show running-config interface 1/1/1

PBR policies apply to a direction - typically in on the interface where traffic arrives. Applying in the wrong direction is the single most common reason "the policy does nothing".

Verification

switch# show policy PBR_APP
switch# show class ip PBR_CLASS_APP
switch# show policy PBR_APP hitcounts
switch# show policy PBR_APP hitcounts interface 1/1/1 in
switch# show ip route 10.20.10.5
switch# show ip route 10.20.10.5 vrf default

Hit counts are the fastest way to distinguish three different problems. Counters incrementing on the expected class means the match logic is right and the fault is downstream. Counters stuck at zero means traffic never arrives in that direction, or an earlier class swallowed it. Counters incrementing on the class but the traffic still taking the route table path means the action list is not being reached or the next hop is considered unreachable.

Remember that PBR takes precedence over the routing table but not over more specific local handling such as locally sourced traffic or traffic that the policy does not ingress from. When you are testing, generate traffic from a host behind the applied interface rather than pinging from the switch itself - a locally originated ping does not traverse the ingress PBR pipeline.

Typical Use Cases

Steer a subnet through an inspection appliance during a migration, force specific SaaS traffic over a preferred WAN link, or route management traffic to a distinct next hop to keep it out of the data path. If your requirement is simply to permit or deny rather than to redirect, an ACL is the lighter tool - see ArubaOS-CX ACL configuration and interface application. In VSX pairs, apply the PBR policy on both peers so that traffic redirected after a failover is handled identically; ArubaOS-CX VSX configuration covers that topology.

One operational warning: PBR next hops are not tracked by the routing protocol. If the appliance or link behind the next hop fails, traffic continues to be sent to an address that no longer answers, so the fallback rule is not optional in production designs.

原文链接：https://support.hpe.com/hpesc/public/docDisplay?docId=sf000097975en_us