Policy-Based Routing (PBR)

Policy-Based Routing (PBR) is a feature on Cisco IOS routers that allows you to make routing decisions based on policies defined by the network administrator, rather than solely on the destination IP address in the routing table. While traditional routing uses the longest prefix match, PBR uses a route map to match packets based on criteria such as source address, destination address, protocol type, packet length, or even application-level information. When a packet matches a policy, the router can forward it to a specific next hop, out a specific interface, or even discard it. PBR is configured on the interface where the packet is received (ingress interface) and affects all packets arriving on that interface, unless otherwise filtered.

PBR is used for several reasons: - Traffic engineering: Direct traffic from certain users or applications over specific links for load balancing or quality of service. - Cost savings: Send bulk data transfers over a cheaper link while keeping interactive traffic on a faster, more expensive link. - Security: Route traffic from untrusted sources to a firewall or inspection device. - Multihoming: Control outbound traffic from different sources to different ISPs without relying on default routes.

- Source IP address (via access-list or prefix-list) - Destination IP address (via access-list or prefix-list) - Protocol (IP, TCP, UDP, etc.) - Packet length - Interface type 4. Set actions: If a match is found, the router applies the set actions, which can include:

- Setting the next-hop IP address - Setting the output interface - Setting the default next-hop (used only if no route exists in the routing table) - Setting the IP precedence or DSCP value - Setting the next-hop recursive (for load balancing) 5. Forwarding decision: The router forwards the packet according to the set action. If no match is found in the route map, the router falls back to normal destination-based routing.

To configure PBR, you first create a route map. Here is an example that forwards all traffic from source 10.1.1.0/24 to next-hop 192.168.1.1:

route-map PBR-MAP permit 10
 match ip address 100
 set ip next-hop 192.168.1.1
!
access-list 100 permit ip 10.1.1.0 0.0.0.255 any
!
interface GigabitEthernet0/0
 ip policy route-map PBR-MAP

Verification commands:

show route-map
show ip policy
show ip local policy

Example output of show route-map:

route-map PBR-MAP, permit, sequence 10
  Match clauses:
    ip address (access-lists): 100
  Set clauses:
    ip next-hop 192.168.1.1
  Policy routing matches: 0 packets, 0 bytes

By default, PBR is processed in software (process switching) on older platforms, but modern Cisco routers support CEF-based PBR (also called PBR with CEF switching). CEF-based PBR uses the Forwarding Information Base (FIB) to apply policies at hardware speed. However, not all match criteria are supported in CEF; for example, matching on packet length may require process switching. The command ip route-cache policy enables CEF-based PBR on an interface.

PBR does not affect routing tables or routing protocol updates. It only influences the forwarding decision for packets that match the policy. Routes learned via OSPF, EIGRP, etc., remain in the routing table. PBR can override the routing table for specific traffic, but it does not change the routing protocol's behavior. This is important: if you set a next-hop that is not reachable (e.g., the interface is down), the packet will be dropped unless you configure a fallback option like set ip default next-hop or use the ip policy route-map with a default route.

It's important to distinguish PBR from route maps used for redistribution or BGP. PBR uses route maps, but route maps are also used for other purposes. The key is the ip policy route-map command on an interface, which invokes PBR.

In enterprise networks, PBR is commonly used for traffic engineering across multiple WAN links. For example, consider a company with two internet connections: a high-speed MPLS link for critical applications and a lower-cost DSL link for non-critical traffic. By using PBR on the internal router, the network engineer can match traffic from the finance department (source subnet) and force it out the MPLS link, while all other traffic uses the default route to the DSL link. This ensures that important financial transactions get priority bandwidth without needing complex QoS configurations.

Another common scenario is routing traffic through a security appliance. Suppose a company wants to inspect all traffic from the guest wireless network before it reaches the internet. On the router connected to the guest VLAN, PBR is applied to match all traffic from the guest subnet and forward it to the firewall's inside interface. The firewall then forwards it to the internet after inspection. This avoids changing the default gateway on the guest devices and allows transparent security enforcement.

A third scenario is load balancing outbound traffic from multiple servers. For instance, a data center may have two upstream routers. By using PBR on the server-facing switch, traffic from certain server VLANs can be sent to one router, and traffic from others to the second router, achieving a simple form of load sharing without dynamic routing protocols.

Performance considerations: PBR can be CPU-intensive if processed in software. On high-traffic links, it is essential to use CEF-based PBR (ip route-cache policy) to offload the processing to hardware. Misconfiguration can lead to black-holing traffic if the set next-hop is not reachable. Always verify reachability and consider using set ip default next-hop as a safety net. Also, PBR does not affect return traffic; return packets follow normal routing unless PBR is also applied on the return path.