Policy-Based Routing
Feature Name |
Release Information |
Feature Description |
Policy-Based Routing on P100-based line cards |
Release 24.2.11 |
You can now create customised 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 only on routers with P100-based line cards. |
Policy-Based Routing (PBR) gives you a flexible means of routing packets by allowing you to configure a defined policy for traffic flows, reducing reliability on routes derived from routing protocols. Moreover, PBR allows you to prioritize and provide a specific routing path for certain types of traffic (for example, VoIP, video conferencing) based on the service-level agreement (SLA).
Unlike traditional routing which is based on destination IP address alone, PBR allows you to route packets based on different parameters such as IP address, port numbers, or protocols. For example, you can implement routing policies to allow or deny paths based on the identity of a particular end system, an application protocol, or the size of packets.
Flow-tag Support
A provider edge (PE) router directs traffic toward the core through the routes learnt. It also installs policies on your interfaces to offer value-added services based on your profiles. The administrators must manually scan route-tables and install traffic-path selection as Access Control Lists (ACLs) on your interfaces for proper traffic forwarding. However, with the scale of route prefix-lists learned from the core, the hardware resource requirements to program policies grows high. When route updates change, it requires administrators to manually update these policies. Moreover, these route policies are applied per prefix list and do not allow per interface selection to associate these policies on a per customer basis, which can be a challenge.
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). Then, forwarding-path rules can be defined against this flow-tag value. This could reduce the need for manual updates and make the system more scalable and efficient.
The following figure illustrates the process:
![](/c/dam/en/us/td/i/500001-600000/520001-530000/523001-524000/523795.jpg)
Flow-tag is set and distributed via the Routing Information Base (RIB) as a policy attribute of the Forwarding Information Base (FIB) entry in the FIB lookup table. Route Policy Language (RPL) is used to create these flow tags through the "set" operation. The flow tag is then referred to in the PBR policy, where it is associated with specific actions or policy rules against the flow tag's value.
Forward-Class Support
The PBR class-map defines the matching criteria for classifying a particular type of traffic, while the forward-class defines the forwarding path these packets must take. Once a class-map is associated with a forwarding-class in the policy map, all the packets that match the class-map are forwarded as defined in the policy-map.
Traffic Engineering (TE) tunnels are then used to direct traffic along specific paths through the network. These TE tunnels can be associated with a forward-class which determines the forwarding path for the 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.
Access-Group Support
PBR supports matching on an ACL group ID. You can specify large prefix lists and long lists of specific permit/deny lists. The prefix lists serve as a filter for routing updates, and the permit or deny lists determine what action to take when a match is found.
Permit/Deny Actions in ACL Groups
An access control entry (ACE) can be either a HIT or a MISS. When the ACE is a HIT, the following actions are performed:
-
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 (didn’t match any permit or deny statement), the following 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. |
Supported Match and Set Operations
The following table illustrates the match/set criteria that is supported by PBR:
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 |