Dell OS10 Policy-Based Routing (PBR) Configuration

Dell PowerSwitch OS10 normally forwards packets by looking up the destination address in the routing table. Policy-based routing (PBR) overrides that decision: traffic is matched against an ACL, and matching packets are forwarded to a next hop you choose, regardless of what the routing protocol would have selected. Typical uses are steering a specific subnet through a dedicated firewall, forcing guest traffic onto a cheap transit link, or tagging VOIP traffic toward a QoS-capable path. This article covers the full OS10 sequence — ACL, route-map, interface application — and the verification commands that confirm packets are really being policy-routed instead of falling back to normal forwarding.

How PBR Works on OS10

Three objects are involved. An ACL selects the traffic by source, destination, protocol, or port. A route-map binds a permit or deny sequence to that ACL and defines what to do with matching packets, usually set ip next-hop. Finally, the route-map is attached to a Layer 3 interface (or a VLAN interface) with ip policy route-map.

OS10 evaluates the route-map sequences in ascending order. A permit sequence with a matching ACL applies the set action; a deny sequence stops policy evaluation and hands the packet back to normal routing. Only ACLs referenced from a route-map are used for policy routing, so an ACL that is not attached to any route-map has no effect here.

Step 1 - Build the ACL

Create an extended ACL that matches the source subnet you want to steer. Be explicit about the destination so that only traffic to that service takes the alternate path:

OS10(config)# ip access-list extended STEER-TO-FW
OS10(config-ext-nacl)# permit ip 192.168.50.0 0.0.0.255 any
OS10(config-ext-nacl)# exit

For a narrower policy, match only the destination that must leave through the firewall:

OS10(config-ext-nacl)# permit tcp 192.168.50.0 0.0.0.255 10.20.30.0 0.0.0.255 eq 443

Step 2 - Create the Route-Map

The route-map name is case sensitive and is referenced later by the interface. The first sequence matches the ACL and sets the next hop; a second, higher sequence with a catch-all ACL keeps a clean default path:

OS10(config)# route-map PBR-TO-FW permit 10
OS10(config-route-map-PBR-TO-FW)# match ip address STEER-TO-FW
OS10(config-route-map-PBR-TO-FW)# set ip next-hop 10.10.10.254
OS10(config-route-map-PBR-TO-FW)# exit

Sequence order and the deny action

Deny sequences are useful when a large ACL has a few exceptions that must keep using the routing table:

OS10(config)# route-map PBR-TO-FW deny 5
OS10(config-route-map-PBR-TO-FW)# match ip address EXEMPT-HOSTS

You can also set a next-hop that is verified or a global default next hop so that traffic falls back to normal routing when the policy next hop becomes unreachable:

OS10(config-route-map-PBR-TO-FW)# set ip next-hop verify-availability 10.10.10.254 1 track 5
OS10(config-route-map-PBR-TO-FW)# set ip default next-hop 10.10.10.253

Step 3 - Apply the Policy to an Interface

PBR is applied on the interface where the traffic enters the switch. That interface must be a routed (Layer 3) interface or a VLAN interface:

OS10(config)# interface vlan 50
OS10(conf-if-vl-50)# no shutdown
OS10(conf-if-vl-50)# ip address 192.168.50.1/24
OS10(conf-if-vl-50)# ip policy route-map PBR-TO-FW
OS10(conf-if-vl-50)# exit

The same statement works on a physical interface after no switchport. Remember that OS10 processes the policy on ingress only — attaching it to the egress interface does nothing.

Step 4 - Verify the Policy

Policy-routed packets are counted on the route-map, which is the fastest way to prove the feature is working:

OS10# show route-map PBR-TO-FW
OS10# show ip access-lists STEER-TO-FW
OS10# show running-configuration | grep -A5 "route-map PBR-TO-FW"
OS10# show ip interface vlan 50

The route-map output lists each sequence, the matched ACL, the configured set clause, and a Policy routed packet and byte counter. A counter that stays at zero means either the ACL is not matching (check the address and wildcard mask) or the policy is not attached to the ingress interface.

PBR and VLT: A Known Misrouting Case

Known PBR behaviour inside a VLT domain

Dell documents a PBR problem in VLT environments: when traffic is routed to the VLT secondary switch over VLTi interfaces, policy-routed packets can be misrouted, producing intermittent communication failures. The documented workaround is to restructure the route-map with two ACLs — one permitting the subnets that should use traditional routing, and a second permitting everything else with an explicit next hop:

OS10(config)# route-map ToDefaultRoute deny 10
OS10(config-route-map-ToDefaultRoute)# match ip address ACL1
OS10(config-route-map-ToDefaultRoute)# exit
OS10(config)# route-map ToFwPbr permit 20
OS10(config-route-map-ToFwPbr)# match ip address ACL2
OS10(config-route-map-ToFwPbr)# set ip next-hop 10.10.10.254

If the problem is not needed at all, PBR can be disabled inside the VLT domain with ip pbr disable and ipv6 pbr disable.

Operational Notes

• Only ACLs referenced by a route-map participate in PBR — unused ACLs are ignored.
• Attach the policy on the ingress interface; egress attachment has no effect.
• Use set ip default next-hop for a fallback path and verify-availability with tracking to withdraw the policy when the next hop dies.
• In VLT fabrics, validate PBR behaviour after any VLTi change — this is where the documented misrouting risk lives.

Related reading: our Dell OS10 ACL configuration and verification guide, the OS10 VLT peer routing configuration article, and the OS10 OSPF interface and area guide.

原文链接：https://www.dell.com/support/manuals/en-us/force10-s4048-on/os10-enterprise-user-guide-pub/policy-based-routing