What is Policy-Based Routing (PBR)?
Learn what policy-based routing is, how route maps override destination-based routing, and common PBR use cases and risks.
Expected Interview Answer
Policy-based routing (PBR) forwards traffic based on administrator-defined rules that match on criteria beyond the destination IP address — such as source address, protocol, or packet marking — overriding the router’s normal destination-based routing table lookup for matched traffic.
Traditional routing only asks 'what is the destination IP, and what does the routing table say the best path is?' PBR inserts a policy layer before that lookup: a route map matches traffic (for example, all traffic from a specific source subnet, or all traffic on a particular port) and then explicitly sets the next hop, output interface, or a different routing table for that traffic, regardless of what the default route would have chosen. Common uses include sending traffic from a guest VLAN out a cheaper, lower-priority internet link while production traffic uses the primary link, steering VoIP traffic across a low-latency path different from bulk data traffic, or asymmetrically routing traffic to satisfy a security or compliance requirement. Because PBR is evaluated per packet against explicit match criteria before the normal routing table, it is powerful but must be used carefully — overlapping or conflicting policies, and interaction with features like NAT or stateful firewalls, can create asymmetric routing that breaks connections if not planned for.
- Routes traffic based on more than just destination IP (source, protocol, marking)
- Enables traffic engineering like cost-based or latency-based path selection
- Supports compliance/security requirements for specific traffic classes
- Requires careful design to avoid asymmetric routing and broken connections
AI Mentor Explanation
Policy-based routing is like a ground manager who overrides the normal “walk to your section based on your seat number” rule for a specific group — VIP ticket holders, regardless of their printed seat number, are always directed through a separate private entrance instead of the standard queue. Everyone else still follows the normal seat-number-based path. This override based on who the person is, not just where they are ultimately sitting, is exactly what policy-based routing does by matching on source rather than only destination.
Step-by-Step Explanation
Step 1
Define match criteria
A route map or access list specifies which traffic to match — by source address, protocol, port, or marking.
Step 2
Set the policy action
For matched traffic, the policy explicitly sets the next hop, output interface, or an alternate routing table.
Step 3
Apply to an interface
The route map is applied inbound on the interface where the matched traffic arrives.
Step 4
Fall back for unmatched traffic
Any traffic not matching a policy clause falls through to the router's normal destination-based routing table lookup.
What Interviewer Expects
- Correct definition: routing based on criteria beyond destination IP
- Names concrete use cases (cost-based path selection, VoIP steering, compliance)
- Understands PBR is evaluated before the normal routing table lookup
- Aware of the asymmetric routing risk with NAT/stateful firewalls
Common Mistakes
- Thinking PBR only matches on destination IP like normal routing
- Not considering how PBR can create asymmetric paths that break stateful firewalls
- Confusing policy-based routing with simple access-control filtering (PBR forwards, ACLs permit/deny)
- Forgetting unmatched traffic still falls back to normal destination-based routing
Best Answer (HR Friendly)
“Policy-based routing lets a network administrator say, 'normally traffic goes by destination, but for this specific type of traffic, send it a different way' — for example, routing guest Wi-Fi out a cheaper internet line while office traffic uses the main line. It gives fine-grained control beyond the usual 'where is this packet going' rule, but it needs to be planned carefully so traffic does not end up taking mismatched paths in and out.”
Code Example
# Send all traffic from a specific source subnet through a
# secondary routing table (table 100) instead of the main table
# 1. Define the alternate route in table 100
ip route add default via 203.0.113.1 dev eth1 table 100
# 2. Add a policy rule matching source traffic to use table 100
ip rule add from 192.168.50.0/24 table 100
# 3. Verify the rule and resulting lookup order
ip rule show
# 0: from all lookup local
# 32764: from 192.168.50.0/24 lookup 100
# 32766: from all lookup mainFollow-up Questions
- How does policy-based routing differ from destination-based routing?
- What risks does PBR introduce with asymmetric routing and stateful firewalls?
- How would you use PBR to steer VoIP traffic across a lower-latency link?
- What is the difference between a route map used for PBR and one used for redistribution?
MCQ Practice
1. What can policy-based routing match on, beyond destination IP?
PBR matches on criteria like source address, protocol, port, or marking to override normal destination-based routing.
2. When is a PBR policy evaluated relative to the routing table lookup?
PBR is applied on ingress before the standard destination-based routing table lookup for traffic that matches its criteria.
3. What is a key risk of poorly designed policy-based routing?
Sending traffic out via a different path than the return traffic takes can break stateful inspection and NAT translation.
Flash Cards
What is policy-based routing? — Routing traffic based on rules beyond destination IP (source, protocol, marking), overriding normal routing.
When is PBR applied? — Before the normal destination-based routing table lookup, for matched traffic.
Common PBR use case? — Sending guest/low-priority traffic out a cheaper link while production traffic uses the primary link.
Key PBR risk? — Asymmetric routing that can break stateful firewalls and NAT.