Policy-Based Routing (PBR) is an essential feature for network administrators aiming to create intelligent, flexible routing decisions beyond traditional routing protocol behavior. In dynamic environments where cloud services, video conferencing, real-time communications, and multi-department data streams compete for bandwidth and require different priorities, policy-based routing gives engineers the power to customize how traffic is forwarded within the network infrastructure. This first part in the four-part article series explores the foundation of policy-based routing, what makes it essential in modern networks, and how it functions within Cisco environments using practical configuration examples.
Traditional Routing vs. Policy-Based Routing
Traditional IP routing relies on routing protocols and static routes to determine the best path to a destination network. These routes are selected based solely on destination IP addresses and metrics such as hop count, bandwidth, or administrative distance. While effective, this method lacks the flexibility to consider traffic characteristics like source IP, traffic type, or time of day, all of which might be relevant in today’s complex, application-driven networks.
Policy-based routing solves this limitation. It allows administrators to define policies that determine how specific traffic flows should be handled. Rather than being constrained to the destination-based forwarding logic of traditional routing, policy-based routing evaluates the packet’s source address, access list, or other attributes and applies a user-defined routing policy accordingly.
For instance, you might want all VoIP traffic to take a high-speed, low-latency link while backup traffic can be sent through a slower, cost-efficient WAN connection. Or perhaps you want all employees in the finance department to access cloud applications over a dedicated ISP connection while other users share a general-purpose link. These types of routing decisions are achievable with policy-based routing.
Key Use Cases for Policy-Based Routing
Policy-based routing becomes critical in scenarios such as
- Traffic prioritization for business applications: Different departments or services (like video conferencing or VoIP) may need preferential treatment to maintain performance.
- Multi-WAN setups: Organizations with multiple internet connections can use policy-based routing to control which traffic flows through which connection, improving redundancy and cost-effectiveness.
- Segregating departmental traffic: Engineering teams might be routed through a higher bandwidth path while guest Wi-Fi traffic gets directed through a limited, throttled connection.
- Time-based traffic control: PBR rules can be applied based on schedules, such as routing backup traffic during off-hours.
By configuring routing behavior based on such custom rules, network administrators gain far greater control and efficiency than what standard routing can offer.
Cisco Implementation of Policy-Based Routing
In Cisco networks, policy-based routing is configured using a combination of Access Control Lists (ACLs), Route Maps, and Interface Configuration. ACLs identify the traffic to which the policy will apply, Route Maps define how that traffic should be handled, and Interface Configuration ties the route map to an ingress interface.
Let’s examine a basic real-world example to illustrate the implementation process. Suppose an organization has two WAN links: a high-speed connection (Serial0/0) and a slower, cost-effective link (Serial0/1). The IT department’s traffic, which needs faster access to cloud services, should be routed through the faster link, while all other traffic can use the slower link.
The IT department operates in the 10.1.0.0/16 subnet. All other traffic originates from other subnets, such as 10.2.0.0/16.
Step-by-Step Configuration: Setting Up Policy-Based Routing
Step 1: Create the Access List
The first task is to define which traffic should be subject to the routing policy. In this example, we will target the IT department:
Router(config)# access-list 50 permit 10.1.0.0 0.0.255.255
This ACL matches traffic coming from the 10.1.0.0/16 subnet. The number 50 designates this as a standard access list.
Step 2: Define the Route Map
A route map consists of multiple sequence statements, each representing a policy rule. Sequence 10 can match the IT department traffic and specify the fast link as the desired route.
Router(config)# route-map IT-Fast permit 10
Router(config-route-map)# match ip address 50
Router(config-route-map)# set interface serial0/0
This configuration tells the router to match traffic defined by ACL 50 and forward it via the Serial0/0 interface, which is mapped to the faster WAN connection.
Next, we create another sequence to catch all remaining traffic:
Router(config)# route-map IT-Fast permit 20
Router(config-route-map)# set interface serial0/1
This rule has no match condition, so it acts as a catch-all. Any traffic not matched by sequence 10 will be routed to Serial0/1, the slower WAN link.
Step 3: Apply the Route Map to an Interface
Assuming traffic enters the router through the FastEthernet0/0 interface, we apply the route map there:
Router(config)# interface fastEthernet0/0
Router(config-if)# ip policy route-map IT-Fast
At this point, all inbound traffic on FastEthernet0/0 will be evaluated against the IT-Fast route map, and forwarded based on the logic defined.
Verification and Monitoring
To ensure your route map is working as intended, use the command:
Router# show route-map
Sample output might look like:
route-map IT-Fast, permit, sequence 10
Match clauses:
ip address (access-lists): 50
Set clauses:
interface Serial0/0
Policy routing matches: 45 packets, 7654 bytes
route-map IT-Fast, permit, sequence 20
Match clauses:
none
Set clauses:
interface Serial0/1
Policy routing matches: 203 packets, 19453 bytes
This output shows how many packets matched each sequence, helping administrators confirm traffic is being routed as expected.
Important Considerations for Using Policy-Based Routing
Processing Overhead: The Cost of Flexibility
One of the main trade-offs when deploying policy-based routing is processing overhead. Unlike standard routing, which often leverages hardware acceleration to make decisions based solely on destination addresses, PBR typically operates within the software forwarding path. On many Cisco platforms, especially older ones, this means that packet forwarding decisions must be processed by the router’s CPU rather than by specialized ASICs or NPUs.
This has significant implications for network performance. Under light traffic conditions, the impact may be negligible. However, in high-throughput environments or networks with many policy-based rules in place, the CPU can become a bottleneck. As a result, the router may experience increased latency, reduced throughput, or even dropped packets if CPU resources are exhausted.
In mission-critical environments, it’s essential to perform capacity planning and stress testing before enabling complex PBR policies. Cisco Practice test labs and simulation tools available on platforms like Exam-Labs can help learners experiment with PBR configurations under varying traffic loads, allowing for a better understanding of how processing overhead impacts performance.
Additionally, modern Cisco hardware has made strides in offloading PBR functions to the data plane, especially in platforms like the Catalyst 9000 series or the ASR routers. Still, administrators must validate whether their hardware supports hardware-based PBR. If not, high CPU utilization could quickly degrade network performance, especially when policies are applied across multiple interfaces or with sophisticated match conditions.
Routing Table Ignored: A Double-Edged Sword
Another vital consideration is how policy-based routing interacts with the standard routing table. By default, packets subject to a policy route do not consult the routing table unless explicitly instructed to do so by the route map. This behavior provides flexibility but can lead to unintended consequences if not carefully planned.
For instance, consider a scenario where traffic from a specific subnet is redirected through a dedicated firewall for inspection. The route map specifies a next-hop IP address that lies across a specific interface. If that next-hop IP becomes unavailable and the PBR policy does not have a fallback mechanism, traffic will be blackholed—even if a valid route exists in the routing table via a different path.
This limitation underscores the importance of redundancy and conditional logic in route maps. Cisco’s advanced route map features allow the use of the set ip next-hop verify-availability option, enabling more intelligent behavior in the event that the primary next-hop becomes unreachable.
Candidates studying for the Cisco Exam, particularly those focusing on advanced routing or troubleshooting modules, must be prepared to analyze scenarios where policy-based routing overrides the normal routing logic. Being able to diagnose misrouted or dropped traffic due to overly rigid PBR policies is a common skill measured in exams and required in production environments.
In short, while bypassing the routing table grants greater control, it demands greater responsibility. Policies must be thoroughly tested and validated using lab environments or virtual routers to ensure that no edge cases result in network disruption.
Limited to Inbound Interfaces: Strategic Placement Required
One of the architectural constraints of policy-based routing is that it can only be applied on inbound interfaces. That is, PBR policies can influence traffic as it enters a router interface, not as it exits one. This requirement forces network architects to think carefully about where policies should be applied.
Consider a network topology with multiple WAN exits. If the goal is to steer traffic from internal VLANs toward different service providers based on traffic type or user group, the PBR policy must be placed on the interface that receives this traffic from the LAN segment, not the WAN interface that ultimately forwards it. This restriction can sometimes complicate policy design, especially in highly meshed topologies or in multi-VRF environments.
In practice, this means that careful interface planning and logical segmentation are required. Engineers must also take into account the direction of traffic flows, NAT boundaries, and potential changes in routing behavior due to asymmetric traffic patterns.
Cisco Certification materials often address this limitation in both theoretical and lab-based questions. By engaging with simulated environments on platforms like Exam-Labs, learners can experiment with different placements of PBR to see firsthand how traffic is influenced and what errors may arise when policies are applied incorrectly.
A common pitfall is attempting to apply PBR to outbound traffic on WAN interfaces, only to find that the configuration has no effect. Understanding the directional limitations of PBR can save significant time during both exam preparation and real-world troubleshooting.
No Load Balancing by Default: Manual Configuration Required
Traditional IP routing allows for load balancing using Equal-Cost Multi-Path (ECMP) when multiple routes exist to a destination with the same metric. Policy-based routing, on the other hand, does not perform load balancing by default. If a route map points traffic to a specific interface or next hop, all matching traffic will follow that single path, regardless of available alternatives.
This behavior poses a limitation for network environments where bandwidth optimization and traffic distribution are critical. To achieve load balancing with PBR, administrators must manually configure additional route map sequences, perhaps with different match criteria or even using route-map randomization techniques where supported.
For example, you might configure one sequence in a route map to match traffic from even-numbered source IPs and send them to one path, while odd-numbered sources go through another. Another method involves using Cisco’s set ip next-hop recursive feature with multiple next-hops listed, though its support varies by platform and IOS version.
Without explicit configuration, PBR can easily create traffic bottlenecks by funneling all matched traffic into a single interface, even when other equal-cost paths are available. This contradicts one of the primary design goals of modern networks, resiliency through path diversity.
For learners aiming to master advanced routing concepts on the Cisco Exam track, understanding how to manipulate traffic across multiple links using PBR is a valuable skill. The complexity involved also makes it a prime candidate for lab-based learning, where scenarios can be created and tested without impacting production.
Successful implementation of PBR depends on strategic thinking, proper testing, and a deep understanding of how Cisco routers handle policy rules. Whether you’re managing a small branch office or a global enterprise network, these considerations will help ensure that your policy-based routing configurations are not only functional but also robust, scalable, and resilient.
Policy-Based Routing in Modern Networks
With growing adoption of software-defined networking, hybrid cloud services, and bandwidth-hungry applications, policy-based routing remains an indispensable tool for network engineers. Although newer technologies like SD-WAN offer more dynamic policy enforcement and automation, classic PBR is still widely used in enterprise networks, particularly in Cisco environments.
For learners preparing for Cisco Certification exams such as the Cisco CCNA 200-301 or more advanced paths, understanding PBR is crucial. It appears in configuration scenarios, troubleshooting questions, and performance optimization topics. Practice labs and hands-on exercises using simulators or real hardware are highly recommended to build confidence with the feature.
Resources like the Cisco Practice test, Cisco Exam preparation tools, and Exam-Labs training modules help reinforce these concepts. While Exam-Labs does not offer a standalone course strictly for policy-based routing, its general CCNA and CCNP training modules often incorporate it into broader routing topics.
In summary, policy-based routing enables fine-grained traffic control by allowing routing decisions based on policies rather than destination IPs alone. This makes it invaluable in networks requiring advanced traffic segregation, department-based routing policies, and multi-WAN optimization.
In the next part of this series, we’ll explore advanced policy-based routing techniques, including route map conditional matching, integration with NAT, and the role of next-hop IP address versus interface routing in more complex scenarios.
Advanced Policy-Based Routing in Cisco Networks
Building upon the foundational concepts explored in Part 1, this second article delves into advanced policy-based routing (PBR) features and their real-world applications in Cisco networks. While basic PBR focuses on matching traffic using source IP addresses and applying a fixed interface or next-hop IP, more sophisticated network designs require conditional logic, policy integration with NAT, tracking reachability, and load balancing strategies. This part explains how to implement these advanced techniques in Cisco IOS, equipping network engineers with the tools needed to build smarter, more resilient routing policies.
Conditional Matching with Route Maps
Route maps in Cisco IOS act like dynamic if-else statements for routing logic. Instead of simply matching a single access list, you can apply multiple match conditions to enforce more granular policies. Cisco route maps support matching on criteria such as
- Source IP (via ACLs)
- Destination IP (with extended ACLs)
- IP precedence or DSCP values
- Input interface
- Length of packets
- Protocol type (e.g., TCP, UDP, ICMP)
Consider a scenario where an organization wants to route all HTTP traffic from the marketing department (IP range: 10.3.0.0/16) over a dedicated ISP link for analytics but send all other traffic over a general-purpose WAN.
Step 1: Define an Extended Access List
Router(config)# access-list 101 permit tcp 10.3.0.0 0.0.255.255 any eq 80
This ACL matches only HTTP traffic from the 10.3.0.0/16 subnet.
Step 2: Create a Route Map with Extended Matching
Router(config)# route-map Marketing-HTTP permit 10
Router(config-route-map)# match ip address 101
Router(config-route-map)# set interface Serial0/2
This route map only affects packets that match ACL 101, providing selective routing based on both source and destination port.
You can combine multiple match statements within the same route map sequence using:
Router(config-route-map)# match length 100 1500
Router(config-route-map)# match interface FastEthernet0/1
These options allow the administrator to apply routing decisions based on packet size (e.g., favoring large data transfers) or ingress interface (e.g., segregating VLAN-based traffic).
Using Next-Hop IP vs. Set Interface
When setting routing behavior in a route map, two common directives are:
- set ip next-hop [ip-address]
- set interface [interface-name]
- set ip next-hop instructs the router to forward matched traffic to a specific next-hop IP address. The router performs a recursive lookup in the routing table to resolve the final egress interface.
- set interface, by contrast, forces traffic to exit a particular interface regardless of the routing table, which may bypass standard behavior and lead to packet drops if layer 2 resolution (ARP) fails.
Example:
Router(config-route-map)# set ip next-hop 192.168.100.1
This is generally preferred over set interface, as it adheres more closely to normal routing operations and allows fallback mechanisms.
However, there are situations where set interface is beneficial—for example, in point-to-point WAN environments with no intermediate IP next-hop available.
Tracking Next-Hop Reachability with IP SLA
A common issue with basic PBR is the lack of dynamic failover. If a specified next-hop becomes unreachable, the router may still try to forward packets to it, causing blackhole routing. To overcome this, Cisco allows integration of PBR with IP SLA and Object Tracking, which dynamically verifies the next-hop’s availability.
Step 1: Configure an IP SLA Probe
Router(config)# ip sla 1
Router(config-ip-sla)# icmp-echo 192.168.100.1
Router(config-ip-sla)# frequency 10
Router(config-ip-sla)# exit
Router(config)# ip sla schedule 1 start-time now life forever
This configuration sends ICMP pings every 10 seconds to check the reachability of 192.168.100.1.
Step 2: Track the SLA Status
Router(config)# track 1 ip sla 1 reachability
Now, create a route map that uses this tracking object:
Router(config)# route-map SLA-Policy permit 10
Router(config-route-map)# match ip address 110
Router(config-route-map)# set ip next-hop verify-availability 192.168.100.1 track 1
This tells the router to only use 192.168.100.1 as a next-hop if the SLA object confirms it is reachable. Otherwise, the router will fall back to normal routing.
Policy-Based Routing with NAT
In networks using Network Address Translation (NAT), policy-based routing and NAT may intersect. A typical use case is to route users through different WAN links and assign them different public IPs via NAT pools, depending on the route taken.
Use Case: Split NAT Based on Source Subnet
· Finance users (10.10.10.0/24) go out WAN1 and get NATed to 209.165.200.1
· All others use WAN2 and get NATed to 209.165.201.1
Step 1: Define NAT Pools
ip nat pool FINANCE-PUBLIC 209.165.200.1 209.165.200.1 netmask 255.255.255.0
ip nat pool GENERAL-PUBLIC 209.165.201.1 209.165.201.1 netmask 255.255.255.0
Step 2: Define ACLs to Identify Traffic
access-list 10 permit 10.10.10.0 0.0.0.255
access-list 20 permit any
Step 3: Apply NAT Based on Source ACLs
ip nat inside source list 10 pool FINANCE-PUBLIC
ip nat inside source list 20 pool GENERAL-PUBLIC
In parallel, apply a PBR route map directing 10.10.10.0/24 through Serial0/0 and other users through Serial0/1. The NAT and PBR policies complement each other for traffic segregation.
Load Balancing with Policy-Based Routing
Policy-based routing isn’t inherently designed for automatic load balancing like equal-cost multipath routing, but it can be configured to perform manual traffic distribution across multiple paths.
Example: Load Balance by Source Subnet
· Subnet A (10.10.0.0/24) uses ISP1 (Serial0/0)
· Subnet B (10.20.0.0/24) uses ISP2 (Serial0/1)
access-list 101 permit ip 10.10.0.0 0.0.0.255 any
access-list 102 permit ip 10.20.0.0 0.0.0.255 any
route-map LB-A permit 10
match ip address 101
set ip next-hop 192.0.2.1
route-map LB-B permit 10
match ip address 102
set ip next-hop 192.0.2.2
These route maps are applied on the inbound LAN interface, splitting outbound traffic between two links. While not adaptive, this method can relieve bandwidth pressure by assigning segments of the network to separate ISPs.
Verifying and Troubleshooting PBR
Several show and debug commands help confirm whether policy-based routing is operating as intended:
1. Check Route Map Statistics:
show route-map
This displays match counts and applied policies.
2. Verify Interface Policy Binding:
show ip policy
3. Inspect PBR Effects on Packets:
debug ip policy
This shows which route map is being applied to specific traffic in real-time. Be cautious, this command is CPU-intensive and should be used sparingly.
4. Check IP SLA Status:
show ip sla statistics
show track
These confirm if tracking objects are up and working as expected.
Common Pitfalls and How to Avoid Them
1. Ignoring ARP for Set Interface: Using set interface requires layer 2 resolution. If the router cannot resolve the MAC address, the traffic gets dropped.
2. No Catch-All Route Map Entry: Forgetting to add a final permit statement in the route map can result in traffic being dropped.
3. Static Next-Hop with No Reachability Check: Without IP SLA integration, unreachable next-hop addresses result in blackholed traffic.
4. Applying PBR on the Wrong Interface: PBR only applies on ingress, not egress. Ensure the route map is applied to the correct incoming interface.
Relevance for Cisco Certification
Policy-based routing is a core topic in both the Cisco CCNA and CCNP Enterprise tracks. Candidates preparing for exams like the Cisco 200-301 or the ENARSI (300-410) should understand both basic and advanced PBR configuration techniques. Scenario-based questions often test understanding of routing behavior overrides, conditional logic, next-hop availability, and troubleshooting route maps.
Using resources like Cisco Practice test, Cisco Exam training material, and Exam-Labs labs is essential to reinforce these skills. Many practice labs focus on combining PBR with NAT, IP SLA, and dual-WAN failover techniques, making it a practical, exam-relevant topic.
Real-World Applications and Design Considerations for Policy-Based Routing in Cisco Networks
With a strong foundation in both basic and advanced Policy-Based Routing (PBR) techniques, Part 3 of this series explores real-world implementation scenarios, design best practices, and enterprise-grade strategies for using PBR in Cisco environments. We’ll break down how organizations use PBR to control traffic for compliance, security, bandwidth optimization, and multi-WAN routing. This article also covers integration with other technologies like QoS, VRF, and MPLS, and explains PBR-related design pitfalls to avoid.
Policy-Based Routing in Enterprise Network Design
Policy-Based Routing gives network administrators control that static and dynamic routing protocols don’t offer. In enterprise settings, it is often used for:
- Routing around link failures with IP SLA
- Enforcing application-specific paths
- Sending traffic to security appliances
- Directing different departments to different ISPs
- Implementing compliance-based routing policies
- Providing granular control over cloud access paths
Instead of allowing OSPF or EIGRP to decide the path, PBR enables traffic steering based on logic defined in route maps. This logic can override the routing table without changing core routing behavior globally.
Common Real-World Use Cases for PBR
1. Split ISP Routing for Departments
Scenario:
A company has two departments: Engineering and Finance. Engineering traffic should go through ISP1 for faster access to development servers, while Finance must use ISP2 for audited transactions and secure banking gateways.
Design:
· Engineering subnet: 10.10.10.0/24
· Finance subnet: 10.20.20.0/24
· ISP1 next-hop: 192.0.2.1
· ISP2 next-hop: 198.51.100.1
Access Lists:
access-list 101 permit ip 10.10.10.0 0.0.0.255 any
access-list 102 permit ip 10.20.20.0 0.0.0.255 any
Route Maps:
route-map ENG-TO-ISP1 permit 10
match ip address 101
set ip next-hop 192.0.2.1
route-map FIN-TO-ISP2 permit 10
match ip address 102
set ip next-hop 198.51.100.1
Interface Application:
interface GigabitEthernet0/1
ip policy route-map ENG-TO-ISP1
interface GigabitEthernet0/2
ip policy route-map FIN-TO-ISP2
This is a classic example of PBR enabling departmental segregation without needing VRFs or separate routing protocols.
2. Sending Traffic to Security Appliances Scenario:
An enterprise wants to send all HTTP and HTTPS traffic to a next-generation firewall (NGFW) appliance for inspection before allowing it out to the internet.
Access List:
access-list 110 permit tcp any any eq 80
access-list 110 permit tcp any any eq 443
Route Map:
route-map TO-FIREWALL permit 10
match ip address 110
set ip next-hop 10.1.1.10 ! IP of the firewall
Application:
interface LAN
ip policy route-map TO-FIREWALL
This use case is popular in segmented data centers where not all traffic should be routed out directly, especially for regulatory compliance or logging.
3. Using PBR for Cloud Optimization
Organizations often use PBR to direct cloud-related traffic (e.g., Microsoft 365, Salesforce) over a faster MPLS or SD-WAN tunnel, while regular internet browsing goes through a basic broadband link.
Use of FQDN ACLs:
In more advanced configurations, Cisco SD-WAN (vManage) or Cisco Umbrella-integrated routers can define policies using destination domain names, but traditional IOS requires IP-based matching.
You would create IP prefix lists based on known cloud IP ranges, then route-map them accordingly:
ip prefix-list OFFICE365 seq 5 permit 13.107.0.0/16
ip prefix-list OFFICE365 seq 10 permit 40.96.0.0/12
route-map CLOUD-PBR permit 10
match ip address prefix-list OFFICE365
set ip next-hop 192.168.100.1 ! Optimized path
Integrating PBR with VRFs
In a multi-tenant environment, VRFs (Virtual Routing and Forwarding) isolate routing tables per tenant or service. However, sometimes you may want traffic from one VRF to be routed to another for centralized logging, firewall inspection, or shared services like DNS.
To do this:
Step 1: Enable PBR inside the VRF.
Step 2: Use route maps to direct traffic to a next hop in a different VRF using inter-VRF static routes or export/import policies.
Example Use Case:
· VRF A: Finance
· VRF B: Shared-Services
· Traffic from VRF A needs to use the DNS server in VRF B.
Define a route map in VRF A:
route-map PBR-VRF-DNS permit 10
match ip address 150
set ip next-hop 10.200.1.1
Where 10.200.1.1 is the DNS IP reachable via VRF B. Use static inter-VRF routes if needed.
PBR and Quality of Service (QoS)
PBR and QoS often work together to shape traffic behavior. PBR can classify and route certain traffic, while QoS can prioritize or throttle it based on class maps and policy maps.
Example Integration:
· PBR sends video traffic to a low-latency path
· QoS ensures video packets have high priority
You can match DSCP values in route maps:
route-map VIDEO-PBR permit 10
match ip dscp af41
set ip next-hop 192.0.2.1
This ensures that only high-priority video traffic takes the optimized path, while other traffic follows the default route.
Policy-Based Routing in MPLS Environments
In MPLS networks, the Label Distribution Protocol (LDP) or Segment Routing is typically responsible for path selection. However, PBR can still override this to handle specific flows.
Use case:
· Send specific customer traffic to a remote data center using a backup LSP (Label Switched Path) manually
In these cases, PBR is used to bypass IGP-calculated labels and force traffic to the alternate Label Edge Router (LER).
PBR configurations in MPLS are similar, but care must be taken to preserve the labels and avoid breaking the MPLS forwarding chain.
Design Considerations for Policy-Based Routing
PBR adds complexity, and improper use can cause routing loops, traffic blackholes, or degraded performance. Consider the following design principles:
1. Minimal Use Principle
Use PBR only where necessary. Prefer dynamic routing and redundancy mechanisms (like HSRP, EIGRP, and OSPF) unless policy-based decisions are unavoidable.
2. Catch-All Permit Entry
Always end your route maps with a permit entry if you want unmatched traffic to follow normal routing. Omitting this causes implicit deny, and unmatched packets are dropped.
route-map MY-PBR permit 20
This entry does nothing but allow unmatched traffic to proceed via the routing table.
3. Failover and IP SLA Integration
Never statically assign a next hop without availability tracking. Always use IP SLA or object tracking to ensure reachability.
4. Consistent Policy Application
Apply route maps at the correct ingress interface. Remember, PBR is inbound, not outbound.
5. Performance Overhead
High traffic volumes with complex route maps can increase CPU utilization. Avoid deep route map logic on routers with limited processing power.
Troubleshooting and Validation Tips
Use these commands to validate and troubleshoot:
- show route-map: Check hit counters and sequence details.
- show ip policy: Validate interface bindings.
- debug ip policy: See real-time packet matches (use cautiously).
- show ip sla statistics: Validate reachability of tracked next-hops.
- show track: Check object status used in route maps.
Test by generating controlled traffic (e.g., using extended ping or IPerf) and watching how packets are handled.
Certification Insight
Cisco certification exams such as Cisco CCNP ENARSI (300-410) and CCNP ENCOR (350-401) include scenario-based questions on PBR in enterprise and service provider settings. Candidates must understand:
- How PBR interacts with routing protocols
- PBR vs. routing redistribution
- PBR and NAT integration
- Route map logic and sequence processing
Hands-on labs and Cisco Practice test resources are highly recommended. Tools like Exam-Labs help simulate real-world problems, including dual-WAN policies, fallback mechanisms, and firewall redirection scenarios.
Automating Cisco Policy-Based Routing with Python, RESTCONF, and NETCONF
In the evolving world of network engineering, the manual configuration of features like Policy-Based Routing (PBR) no longer scales well in large or dynamic environments. As Cisco shifts toward intent-based networking and software-defined infrastructure, automation becomes essential. Part 4 of this series dives into automating PBR configuration and management using Python and network APIs like RESTCONF and NETCONF. This approach reduces human error, speeds up deployments, and integrates routing policy changes with orchestration platforms and CI/CD pipelines.
Why Automate Policy-Based Routing?
Manual configuration of PBR can be time-consuming and error-prone, especially in environments where
- Routing policies must change dynamically based on application or user behavior
- Frequent failover decisions are required
- Devices are managed at scale (dozens to hundreds of routers)
- Integration with external services like monitoring, authentication, or cloud intelligence is necessary
Using tools like Python, RESTCONF, and NETCONF allows network engineers to treat infrastructure as code and make programmatic changes to PBR policies based on templates, events, or telemetry.
Automation Toolchain Overview
To automate PBR in Cisco networks, you can use
- Python: A general-purpose scripting language, widely supported in networking
- RESTCONF: A RESTful API supported on Cisco IOS XE, useful for web-based interactions with the device’s YANG data models
- NETCONF: An XML-based protocol used for interacting with Cisco devices using structured YANG data models, typically for configuration
- Cisco DevNet Sandbox: A cloud-based lab for testing automation scripts against virtual routers
- Ansible/Nornir (optional): Higher-level tools that can run Python logic in bulk
This part will focus on direct Python + RESTCONF/NETCONF methods for clarity.
Automating PBR with Python + RESTCONF
RESTCONF lets you interact with Cisco IOS XE devices using HTTP or HTTPS. You can use it to push configuration changes related to access lists, route maps, and interface policy applications.
1. Prerequisites
· IOS XE device with RESTCONF enabled
· Python 3.x installed
· Requests library (pip install requests)
· Device credentials (username/password or token)
2. Enabling RESTCONF on a Cisco Device conf t restconf ip http secure-server username netadmin privilege 15 secret cisco123 Ensure you have proper crypto keys:
crypto key generate rsa modulus 2048
Verify RESTCONF access:
show restconf
3. Building the Python Script
Here’s a basic Python snippet that creates an access list entry via RESTCONF.
import requests
import json
from requests.auth import HTTPBasicAuth
device = {
“host”: “10.0.0.1”,
“port”: “443”,
“user”: “netadmin”,
“password”: “cisco123”
}
headers = {
“Content-Type”: “application/yang-data+json”,
“Accept”: “application/yang-data+json”
}
url = f”https://{device[‘host’]}:{device[‘port’]}/restconf/data/Cisco-IOS-XE-native:native/ip/access-list/extended=TRAFFIC-FILTER”
payload = {
“Cisco-IOS-XE-acl:extended”: [
{
“name”: “TRAFFIC-FILTER”,
“access-list-seq-rule”: [
{
“sequence”: 10,
“ace-rule”: {
“action”: “permit”,
“protocol”: “ip”,
“source”: {
“any”: [None]
},
“destination”: {
“any”: [None]
}
}
}
]
}
]
}
response = requests. put(url, auth=HTTPBasicAuth(device[“user”], device[“password”]), headers=headers, data=json.dumps(payload), verify=False)
print(response.status_code)
print(response.text)
This script creates an access list called TRAFFIC-FILTER, allowing all IP traffic. You can then proceed to automate route-map creation and binding to interfaces using similar RESTCONF endpoints.
Automating Route Maps and Interfaces via RESTCONF
Once ACLs are in place, use additional RESTCONF paths to:
· Create a route-map with sequence match and set actions
· Bind that route-map to a router interface using ip policy route-map
Example payloads include:
· /restconf/data/Cisco-IOS-XE-native:native/route-map
· /restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=1/ip/policy
Due to JSON/YANG nesting, it’s advisable to use Cisco’s YANG Explorer (or the DevNet API documentation) to build correct payload structures.
Automating PBR with NETCONF
NETCONF offers more structure and transactional control than RESTCONF. It’s used extensively in Cisco automation and supported natively on IOS XE routers.
1. Python + NETCONF with ncclient
Install the ncclient library: pip install ncclient Connect and push configuration: from ncclient import manager
router = {
“host”: “10.0.0.1”,
“port”: 830,
“username”: “netadmin”,
“password”: “cisco123”
}
netconf_filter = “””
<filter>
<native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native”>
<ip>
<access-list>
<extended>
<name>WEB-ACL</name>
<access-list-seq-rule>
<sequence>10</sequence>
<ace-rule>
<action>permit</action>
<protocol>tcp</protocol>
<source><any/></source>
<destination>
<any/>
<destination-port>
<eq>80</eq>
</destination-port>
</destination>
</ace-rule>
</access-list-seq-rule>
</extended>
</access-list>
</ip>
</native>
</filter>
“””
with manager.connect(host=router[“host”], port=router[“port”],
username=router[“username”], password=router[“password”],
hostkey_verify=False, device_params={‘name’: ‘csr’}) as m:
reply = m.edit_config(target=”running”, config=netconf_filter)
print(reply)
Building a Full PBR Deployment Pipeline
Once individual pieces (ACLs, route maps, interfaces) are defined in Python, you can:
1. Create YAML/JSON templates for ACLs and route-maps
2. Trigger deployment from CI/CD tools like Jenkins or GitLab
3. Use event-based logic (e.g., failover via NetBox, NMS alert)
4. Pull device state before applying changes to validate conditions
5. Push config to multiple routers in a loop
This approach enables dynamic routing policy decisions—such as changing the path for SaaS applications based on performance metrics or traffic surges.
Using PBR Automation in Cisco SD-WAN and DNA Center
For modern Cisco environments:
· Cisco SD-WAN (Viptela) uses policy templates via vManage APIs
· Cisco DNA Center supports PBR creation and management through intent APIs
You can write Python scripts to create Application-Aware Routing (AAR) policies that replicate PBR logic based on user-defined thresholds, SaaS performance, or telemetry.
Use Cases for Automated PBR
- Time-based Routing: Schedule route-map updates to steer traffic differently during business hours
- Threat Response: Send traffic to security appliances automatically if an anomaly is detected
- Cloud Service Tuning: Adjust next-hop routing based on SLA metrics for services like Microsoft 365 or Zoom
- Failover Routing: Use reachability scripts with IP SLA to dynamically change next-hops in route-maps
Testing PBR Automation in a Lab
Use tools like:
- Cisco DevNet Sandbox: Access virtual IOS XE routers
- GNS3/EVE-NG: Build virtual labs with CSR1000v routers
- Postman: Test RESTCONF endpoints before Python scripting
- Wireshark: Verify NETCONF/RESTCONF request behavior
PBR Automation: Best Practices
- Template Everything: Use Jinja2 or YAML templates for consistency
- Track Changes: Integrate with Git for configuration version control
- Validate Before Apply: Use dry-run mechanisms to preview config changes
- Error Handling: Ensure your scripts can catch API failures and log outcomes
- Secure Your Endpoints: Use HTTPS, token-based auth, and RBAC
Cisco Certification Insight
PBR automation is relevant for Cisco DevNet Associate, DevNet Professional, and CCNP Enterprise ENAUTO (300-435) exams. Topics include:
- YANG models (IOS XE native)
- RESTCONF vs NETCONF
- Python scripting and JSON/YAML parsing
- Network programmability architecture
Practical labs and Cisco Practice test platforms like Exam-Labs help candidates gain confidence by simulating automation tasks, API interactions, and dynamic policy updates.
Final Thoughts
Policy-Based Routing has long been a powerful but underutilized tool in traditional network environments. With the shift toward automation, cloud-native architectures, and intent-based networking, PBR now plays a critical role in enabling application-aware traffic steering, dynamic path control, and intelligent failover mechanisms. When combined with Python scripting and programmable interfaces like RESTCONF and NETCONF, PBR becomes a flexible, scalable, and repeatable part of modern network operations.
This four-part series has explored the theory, manual configuration, real-world use cases, and advanced automation of PBR in Cisco environments. From simple ACLs and route-maps to complex multi-path decisions tied to performance metrics, PBR offers granular control over how traffic flows through your infrastructure.
For network engineers pursuing certifications such as Cisco DevNet Associate, CCNP Enterprise, or the 300-435 ENAUTO exam, mastering PBR both manually and programmatically is a valuable skill set. Using platforms like Exam-Labs for Cisco Practice test resources can reinforce your understanding and provide hands-on experience with simulated lab environments.
As networks become more dynamic and demand real-time adaptability, the ability to automate routing behavior based on business logic will separate traditional network admins from modern network engineers. Policy-Based Routing, when automated, is a clear example of how legacy techniques can evolve to meet today’s operational challenges with precision and intelligence.
