PBR is not supported together with ingress ACLs on the same port.
Global PBR is not supported with per-port-per-VLAN ACLs.
Global PBR is supported only on the default VRF.
A PBR policy on an interface takes precedence over a global PBR policy.
You cannot apply PBR on a port if that port already has ingress ACLs, ACL-based rate limiting, DSCP-based QoS, or MAC address filtering.
The number of route maps that you can define is limited by the available system memory, which is determined by the system configuration and how much memory other features use. When a route map is used in a PBR policy, the PBR policy uses up to 21 instances of a route map, up to five ACLs in a matching policy of each route map instance, and up to six next hops in a set policy of each route map instance. Note that the CLI allows you to configure more than six next hops in a route map; however, the extra next hops will not be placed in the PBR database. The route map could be used by other features such as BGP or OSPF, which may use more than six next hops.
Denial of Service (DoS) protection is supported in PBR.
IPv4 ACL accounting is supported in PBR.
ACLs with the
log option configured in the
access-list command should not be used for PBR purposes.
PBR ignores explicit or implicit
deny ip any any ACL entries to ensure that the traffic is compared to all ACLS for route maps that use multiple ACLs. PBR also ignores any deny clauses in an ACL. Traffic that matches a deny clause is routed normally using Layer 3 paths.
PBR always selects the first next hop from the next-hop list that is up. If a PBR policy next hop goes down, the policy uses another next hop if available. If no next hops are available, the device routes the traffic in the normal way.
PBR is not supported for fragmented packets. If the PBR ACL filters on Layer 4 information such as TCP/UDP ports, fragmented packed are routed normally.
You can change route maps or ACL definitions dynamically and do not need to rebind the PBR policy to an interface.