July 2004 · 6 min read
As traffic types diversified across campus and branch networks, it became crucial to prioritize and route traffic based on application needs rather than destination alone. In this context, Policy-Based Routing (PBR) emerged as a flexible tool in the Cisco arsenal.
PBR allows us to route packets based on criteria like source address, protocol, or even application-specific tags. This means you could route VoIP traffic via a high-speed link and bulk data via a less expensive path — all without needing to modify the underlying routing protocol decisions.
To implement PBR on a Catalyst or router, we define route-maps and apply them to the incoming interface:
interface FastEthernet0/1
ip policy route-map QoSPolicy
route-map QoSPolicy permit 10
match ip address 110
set ip next-hop 10.1.1.1
Access-list 110 could define a class of traffic, such as video conferencing endpoints or Citrix client subnets. The ability to selectively influence routing opens up use cases like bandwidth conservation, WAN cost management, and traffic engineering in the absence of MPLS or SD-WAN.
However, with power comes responsibility. PBR overrides the routing table, so improper design or forgetting route fallback can lead to blackholing. PBR also consumes more CPU, especially at scale, so interface-level testing is essential before deploying in production environments.
At this point in the network evolution, QoS and PBR together began forming the foundation of what we now refer to as intent-based routing strategies — even before SD-WAN brought it to the mainstream.