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

PDF

Policy-based routing

Updated: June 30, 2026

Want to summarize with AI?

Log in

Explains the benefits of policy-based routing by allowing administrators to define routing policies using parameters such as IP address, port number, or protocol. It supports granular traffic control and optimization through features like flow-tag and forward-class.

Policy-based routing is a routing technique that

  • lets administrators define routing policies by using parameters such as IP address, port number, or protocol

  • makes routing decisions based on criteria other than the destination IP address, and

  • supports granular traffic control and optimization by using features such as flow-tag, forward-class, and access-group.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

Policy-Based Routing byte count

 Release 26.1.1

Introduced in this release on: Fixed Systems (8200 [ASIC: P100, P200], 8700 [ASIC: P100, K100], 8010 [ASIC: A100])(select variants only); Modular Systems (8800 [LC ASIC: P100]) (select variants only*)

The bytes count enables the router to accurately track and display the total number of bytes matched by each policy-based routing (PBR) rule. This provides enhanced visibility into traffic volume, allowing you to better monitor and analyze network usage.

The byte count in the show pbr stats counters policy <policy_name> command now supports additional PIDs.

*This feature is supported on:

  • 8212-48FH-M

  • 8711-32FH-M

  • 8712-MOD-M

  • 8011-4G24Y4H-I

  • 88-LC1-36EH

  • 88-LC1-12TH24FH-E

  • 88-LC1-52Y8H-EM

  • 8223-64EF-M(O)

Policy-Based Routing

 Release 25.4.1

Introduced in this release on: Fixed Systems (8010 [ASIC: A100]) (select variants only*)

*This feature is supported on:

  • 8011-32Y8L2H2FH

  • 8011-12G12X4Y-A

  • 8011-12G12X4Y-D

Policy-Based Routing

 Release 25.1.1

Introduced in this release on: Fixed Systems (8010 [ASIC: A100]) (select variants only*)

*This feature is supported on Cisco 8011-4G24Y4H-I routers.

Policy-Based Routing

 Release 24.4.1

Introduced in this release on: Fixed Systems (8700 [ASIC: K100]) (select variants only*)

*This feature is supported on Cisco 8712-MOD-M routers.

Policy-Based Routing

 Release 24.2.11

Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100]) (select variants only*); Modular Systems (8800 [LC ASIC: P100]) (select variants only*)

You can now create customized routing policies based on different parameters such as IP address, port numbers, or protocols. With policy-based routing (PBR), you can enhance your network security by steering sensitive data away from potentially vulnerable network segments. Also, by allowing you to distribute traffic across multiple paths, PBR can help prevent traffic congestion in your network.

*This feature is supported on:

  • 8212-48FH-M

  • 8711-32FH-M

  • 88-LC1-36EH

  • 88-LC1-12TH24FH-E

  • 88-LC1-52Y8H-EM

Policy-based routing (PBR) lets you route packets by configuring a policy for traffic flows. This reduces reliance on routing protocols. PBR allows you to prioritize and provide a specific routing path for certain types of traffic, such as VoIP and video conferencing, based on the service-level agreement (SLA).

Unlike traditional routing, which relies solely on the destination IP address, PBR enables you to route packets based on various parameters, such as IP address, port numbers, or protocols. For instance, you can implement routing policies to permit or deny traffic paths based on the identity of a specific end system, an application protocol, or packet size.

Flow-tag support

A provider edge (PE) router directs traffic toward the core through learned routes and installs policies on your interfaces based on your profiles. You must manually scan route tables and install Access Control Lists (ACLs) on your interfaces for proper traffic forwarding. As the scale of route prefix lists increases, the hardware resources required to program policies also increase. Whenever route updates occur, you must manually update these policies. You can apply route policies per prefix list but cannot select them for each interface to associate policies for each customer. This limitation may require additional planning.

To simplify policy management and improve scalability, you can classify the traffic early in the routing domain as routes are learned, and mark them with metadata or a tag in the Forwarding Information Base (FIB). Forwarding-path rules can be defined against this flow-tag value, reducing manual updates and improving scalability.

The system sets and distributes the flow tag via the Routing Information Base (RIB) as a policy attribute of the Forwarding Information Base (FIB) entry in the FIB lookup table. Use the Route Policy Language (RPL) set operation to create flow tags. The PBR policy then refers to the flow tag and associates it with specific actions or policy rules for its value.

Figure 1. Flow-tag process
flow-tag-process

Forward-class support

Use the PBR class-map to define matching criteria for a particular type of traffic. Use the forward-class to specify the forwarding path for packets. After you associate a class-map with a forwarding-class in the policy map, all matching packets are forwarded as specified in the policy map.

Use Traffic Engineering (TE) tunnels to direct traffic along specific network paths. Associate TE tunnels with a forward-class to determine the forwarding path for packets.

The use of the auto-route command allows the TE interface to be exported to the routing protocol module, associating the route in the Forwarding Information Base (FIB) database with these tunnels.

The system can support up to eight forward-classes with eight TE tunnels each, allowing a maximum of 32 TE tunnels to be associated with the destination route.

Guideline for forward-class implementation

When you configure match tcp-flag, also configure match protocol tcp to ensure correct traffic classification.

Access-group support

PBR supports matching on an ACL group ID. You can specify large prefix lists and long lists of specific permit or deny lists. The prefix lists filter routing updates, while the permit or deny lists determine the action taken when a match occurs.

  • Permit - Stop processing ACL, and if

    • the type of class is “match-any”, proceed to take policy-map action

    • the type of class is “match-all”, proceed to the next ACL or “match” statement in the class-map considering that you already have a match (true) for an existing ACL.

  • Deny - Stop processing ACL and if

    • the type of class is “match-any”, proceed to the next ACL (or “match”) statement in the class-map if there is no match for the existing ACL.

    • the type of class is “match-all”, exit the class. No policy action is taken, and the next class is processed as per the specified order.

When the ACE is a MISS, that is, it did not match any permit or deny statement, these actions are performed:

  • Proceed to the next "match" statement.

  • If the “match” statement does not provide a match, then skip that class. No policy action is taken for that class, and proceed to check the packet against the next class in order, or proceed to L3 forwarding lookup.

Note

An explicit deny entry is not supported in ACL groups that are embedded in class-maps.

Policy-based routing example

For example, you can implement a policy to route VoIP traffic through a dedicated path to ensure quality of service, while video conferencing traffic can be prioritized using a specific SLA. PBR can also be used to steer sensitive data away from vulnerable network segments, and distribute traffic across multiple paths to prevent congestion.

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 2. 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

1.

Configure flow-tag.
2.

Provision forward class using RPL.
3.

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.

Procedure

1.

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.
2.

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.
3.

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.
4.

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.
5.

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.
6.

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

1.

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
2.

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
3.

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.

Procedure

1.

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
2.

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
3.

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
4.

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
5.

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
!