Routing Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

PDF

Routing Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

Policy-based routing

Updated: September 8, 2026

Want to summarize with AI?

Describes how policy-based routing enables routing decisions based on parameters beyond destination IP address, allowing granular traffic control and optimization.

Supported match and set operations

Supported match and set operations in PBR refer to the criteria that can be used to identify and manipulate network traffic for routing purposes.

Match operations include source IP, destination IP, source protocol/port, destination protocol/port, access-group, flow-tag, IP protocol, TCP flag, and port-range.
Set operations include nexthop IP, nexthop VRF, nexthop IP+VRF, and forward-class.

Table 1. Supported match and set operations
Criteria	match/set
source ip	match
destination ip	match
source protocol/port	match
destination protocol/port	match
nexthop ip	set
nexthop vrf	set
nexthop ip+vrf	set
forward-class	set
access-group	match
flow-tag	match
ip protocol	match
tcp-flag	match
port-range	match

Restrictions for implementing policy-based routing

These restrictions apply when implementing Policy-based routing.

QoS Group and Flow-tag are not supported together at the same time.
Bridge Group Virtual Interface (BVI) and Pseudowire Headend (PWHE) subinterfaces support PBR from Release 26.1.1.
BGP Flowspec feature and PBR are not supported together on the same interface.
A route-policy can have either 'set qos-group' or 'set flow-tag,' but not both for a prefix-set.
Route policy for qos-group and route policy flow-tag cannot have overlapping routes. The Quality-of-service Policy Propagation Using Border Gateway Protocol (QPPB) and flow tag features can coexist (on same as well as on different interfaces) as long as the route policy used by them do not have any overlapping route.
Mixing usage of qos-group and flow-tag in route-policy and policy-map is not recommended.

Configure policy-based routing

Procedure

Configure flow-tag.
Provision forward class using RPL.
Configure ACLs with policy-based routing.

Configure the flow-tag

Configure the Flow-tag to classify and manage traffic flows using route policies, class maps, and policy maps.

The Flow-tag feature allows you to mark and control traffic flows for advanced routing and policy-based forwarding. This procedure demonstrates how to define AS path sets, set Flow-tags, and apply related configurations.

Before you begin

Procedure

Define a named AS path set in the route policy.
Example:
```
Router(config)#as-path-set as-set-1
   ios-regex '_12$',
   ios-regex '_13$' 
end-set
```
This AS path set is referenced in route-policy configuration to match specific AS paths.

Set the Flow-tag under route-policy configuration.

Example:

Router(config)# route-policy flowtag_match
Router(config-rpl)# if community matches-every (100:1) then
set flow-tag 31
else
Router(config-rpl-else)# if as-path in as-set-1 then
set flow-tag 62
Router(config-rpl-else)# endif
Router(config-rpl)# end-policy

The route-policy uses community and AS path matches to set different Flow-tags.

Apply the policy when updating the routing table.

Example:

Router(config)# router bgp 100
Router(config-bgp)# bgp router-id 209.165.201.19
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# table-policy flowtag_match

Ensure the policy is applied to the correct BGP address-family for traffic classification.

Configure a class map and policy map for traffic matching and forwarding.

Example:

Router(config)# class-map type traffic match-all green-tag1
Router(config-cmap)# match flow-tag 31
Router(config-cmap)# end-class-map
Router(config-cmap)# exit
Router(config)# policy-map type pbr nh_select
Router(config-pmap)# class type traffic green-tag1
Router(config-pmap-c)# set forward-class 1

The class map matches traffic with Flow-tag 31, and the policy map sets the forwarding class for matched traffic.

Configure an interface and apply the PBR policy map to the interface.
Example:
```
Router(config)# interface HundredGigE0/7/0/27
Router(config-if)# ipv4 address 10.10.20.10
Router(config-if)# service-policy type pbr input nh_select
```
Applying the policy map to the interface enables policy-based routing for incoming traffic.

Verify the running configuration for class map, policy map, and interface.

Example:

Router# show running-config class-map
class-map type traffic match-all green-tag1
match flow-tag 101 
 end-class-map
! 
Router# show running-config policy-map
policy-map type pbr nh_select
class type traffic green-tag1 
  redirect ipv4 nexthop 10.1.2.2 
 ! 
 class type traffic green-tag1 
 ! 
 end-policy-map
! 
Router# show running-config interface HundredGigE0/7/0/27
interface HundredGigE0/7/0/27
service-policy type pbr input nh_select
!

Use these commands to confirm that Flow-tag, class map, policy map, and interface configurations are active.

Flow-tag configuration is applied, and traffic is classified and forwarded according to the defined policies.

Provision forward class using RPL

Provisioning forward class using RPL involves configuring route policies that set the forward-class ID based on matching criteria such as community strings, VRFs, or next-hop addresses. This enables differentiated forwarding for traffic engineering tunnels.

Route policies can match on community strings, VRFs, or next-hop sets.
Forward-class IDs are set within the route policy and applied to BGP routes.
Traffic is forwarded through TE tunnels associated with the configured forward-class.

Before you begin

Use this sample configuration to provision forward class using RPL.

Procedure

Set the forward class ID for community string.

Example:

Router(config)# route-policy c1
Router(config-rpl)# if community matches-every (6500:1) then
set forward-class 1
Router(config-rpl-else)# endif
Router(config-rpl)# end-policy
Router(config)# router bgp 50
Router(config-bgp)# bgp router-id 209.165.201.29
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# table-policy c1
Router(config-bgp-af)# exit
Router(config-bgp)# exit
Router(config)# interface tunnel-te1
Router(config-if)# forward-class 1

Set the forward class ID for VRF.

Example:

Router(config)# route-policy c1
Router(config-rpl)# set forward-class 1
Router(config-rpl)# end-policy
Router(config)# route-policy c2
Router(config-rpl)# set forward-class 2
Router(config-rpl)# end-policy
Router(config)# router bgp 50
Router(config-bgp)# bgp router-id 209.165.201.29
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# exit
Router(config-bgp)# exit
Router(config-bgp)# vrf one
Router(config-bgp-vrf)# rd 1:1
Router(config-bgp-vrf)# address-family ipv4 unicast
Router(config-bgp-af)# table-policy c1
Router(config-bgp-af)# exit
Router(config-bgp)# exit
Router(config-bgp)# vrf two
Router(config-bgp-vrf)# rd 2:2
Router(config-bgp-vrf)# address-family ipv4 unicast
Router(config-bgp-af)# table-policy c2
Router(config-bgp-af)# exit
Router(config-bgp)# exit
Router(config)# interface tunnel-te1
Router(config-if)# forward-class 1
Router(config)# interface tunnel-te2
Router(config-if)# forward-class 2

Configure a route policy with next hop and set a forward class.

Example:

Router(config)# prefix-set nh-set-1
Router(config-pfx)# 10.10.0.1
Router(config-pfx)# end-set

Router(config)# route-policy c1
Router(config-rpl)# if next-hop in nh-set-1 then
set forward-class 1
Router(config-rpl)# endif
Router(config-rpl)# end-policy
Router(config)# router bgp 50
Router(config-bgp)# bgp router-id 209.165.201.29
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# table-policy c1
Router(config-bgp-af)# exit
Router(config-bgp)# exit
Router(config)# interface tunnel-te1
Router(config-if)# forward-class 1

In these examples, BGP on the receiving PE is configured with table policies that set the forward-class based on the matching criteria. The appropriate TE tunnel is selected for forwarding based on the forward-class ID.

For example, if a route matches community 6500:1, the route-policy sets forward-class 1, and traffic is forwarded through tunnel-te1. For VRF one and two, table-policies C1 and C2 set forward-class 1 and 2, selecting tunnel-te1 and tunnel-te2, respectively. When matching on next-hop 10.10.0.1, the policy sets forward-class 1 and selects the corresponding tunnel.

Configure ACLs with policy-based routing

Use this procedure to configure ACLs with PBR. The following steps provide a sample configuration and verification commands.

Before you begin

Procedure

Configure an access list.

Example:

Router(config)# ipv4 access-list INBOUND-ACL
Router(config-ipv4-acl)# 10 permit ipv4 any host 10.1.1.10
Router(config-ipv4-acl)# 20 permit ipv4 any host 10.2.3.4
Router(config-ipv4-acl)# commit
Router(config-ipv4-acl)# exit

Configure a class map for the access list.

Example:

Router(config)# class-map type traffic match-any INBOUND-CLASS
Router(config-cmap)# match access-group ipv4 INBOUND-ACL
Router(config-cmap)# end-class-map
Router(config)# commit

Configure a PBR policy map with the class map.

Example:

Router(config)# policy-map type pbr INBOUND-POLICY
Router(config-pmap)# class type traffic INBOUND-CLASS
Router(config-pmap-c)# redirect ipv4 nexthop 192.168.10.1
Router(config-pmap-c)# exit
Router(config-pmap)# class type traffic class-default
Router(config-pmap-c)# transmit
Router(config-pmap-c)# commit
Router(config-pmap)# end-policy-map

Configure a Gigabit Ethernet interface and apply the PBR policy map to the interface.

Example:

Router(config)# interface GigabitEthernet 0/0/0/0
Router(config-if)# ipv4 address 10.10.10.1 255.255.255.0
Router(config-if)# service-policy type pbr input INBOUND-POLICY
Router(config-if)# commit
Router(config-if)# exit

Verify the running configuration for the access list.

Example:

Router# show running-config ip access-list
ipv4 access-list INBOUND-ACL
10 permit ipv4 host 10.10.10.1 any
!

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.