Today, we revisit a foundational Cisco feature: Optimized Edge Routing (OER), more commonly known now as Performance Routing (PfR). In 2011, we explored how this “brain” could monitor network paths and intelligently route traffic based on real-time metrics like jitter, delay, and bandwidth consumption. Fast forward to 2025, and while the core principles of PfR remain incredibly relevant, its implementation and integration have evolved dramatically, becoming a cornerstone of modern SD-WAN (Software-Defined Wide Area Network) and Intent-Based Networking (IBN) architectures.
The days of purely manual OER CLI configurations on physical routers are largely behind us. Today, PfR’s capabilities are baked into powerful, centralized platforms like Cisco SD-WAN vManage and Cisco DNA Center, enabling application-aware routing (AAR), policy-driven automation, and deeper network observability. Let’s dive into how this feature has grown, moving from “watching like hell” to proactively optimizing with intelligence and automation.
Evolution of PfR: From Classic OER to SD-WAN Intelligence
The original concept of OER/PfR was revolutionary: a Master Controller (MC) making dynamic routing decisions based on real-time performance data gathered from Border Routers (BRs) at the network edge. This allowed enterprises with multiple WAN connections to intelligently steer traffic over the “best” path for specific applications, greatly improving user experience and resource utilization.
Today, this capability is not just about avoiding congested links. It’s about ensuring business-critical applications receive optimal performance, regardless of network conditions. This shift is powered by Cisco SD-WAN, where PfR’s logic is elevated into sophisticated application-aware routing policies managed from a centralized controller.
Topology Overview: The Modern Perspective
Our original topology used GNS3 with R1 as the **Master Controller (MC)** and R2/R4 as **Border Routers (BRs)**, connecting to different ISPs. This traditional setup highlighted the MC/BR roles clearly.
TOPOLOGY Overview (Classic):
In the original GNS3 lab, R1, R2, and R4 were in AS 64511, using **EIGRP** as the IGP. R2 and R4 peered with ISP-1 and ISP-2 via **BGP**. This demonstrates a classic multi-homed enterprise setup.
R1#sh ip bgp summ | b Neigh
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 64511 10 11 7 0 0 00:06:05 3
4.4.4.4 4 64511 10 11 7 0 0 00:06:00 3
R2#sh ip bgp summ | b Neigh
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 64511 11 10 7 0 0 00:06:34 1
21.21.21.1 4 1 10 10 7 0 0 00:06:29 3
R4#sh ip bgp summ | b Nei
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 64511 12 11 7 0 0 00:07:00 3
42.42.42.2 4 2 11 11 7 0 0 00:07:02 3
HOST-1 and HOST-2 were configured with default gateways pointing to R1, demonstrating how internal traffic would egress the enterprise.
HOST-1#sh ip route
Default gateway is 1.1.124.1
The Modern SD-WAN Equivalent:
In an **SD-WAN architecture**, the **Master Controller (MC)** role is assumed by the **vSmart Controller**, which acts as the centralized brain for the overlay network. The **Border Routers (BRs)** are now **vEdge** or **cEdge (IOS-XE)** devices, forming the data plane and peering with external ISPs. These devices are managed by **vManage**, the centralized Network Management System (NMS).
The core concept remains: traffic from internal networks needs to reach external destinations over multiple paths, with performance optimization.
PfR/OER Configuration: Then vs. Now
Let’s look at the original OER configuration and then compare it with how **PfRv3** and **SD-WAN Application-Aware Routing** achieve the same goals today.
Classic OER/PfR Configuration (Pre-v3 CLI – Legacy):
The original configuration involved setting up a key chain for secure communication between the MC and BRs.
R1(config)#key chain OER
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string cisco
The MC (R1) configuration involved enabling OER master mode, logging, specifying the communication port, and defining the Border Routers along with their internal and external interfaces.
R1(config)#oer master
R1(config-oer-mc)#logging
R1(config-oer-mc)#port 1790
R1(config-oer-mc)#border 2.2.2.2 key-chain OER
R1(config-oer-mc-br)#interface fa0/0 internal
R1(config-oer-mc-br)#interface s0/0 external
R1(config-oer-mc-br-if)#exi
R1(config-oer-mc-br)#exi
R1(config-oer-mc)#border 4.4.4.4 key-chain OER
R1(config-oer-mc-br)#interface fa0/0 internal
R1(config-oer-mc-br)#interface s0/0 external
R1(config-oer-mc-br-if)#exit
**NOTE:** In this legacy mode, the interfaces specified under `border` configuration were the actual interfaces on the BRs, not the MC.
On the BRs (R2 and R4), the configuration involved a matching key chain and pointing to the Master Controller, along with specifying the source interface for active probes.
key chain OER
key 1
key-string cisco
oer border
local Loopback0
port 1790
master 1.1.1.1 key-chain OER
active-probe address source interface Loopback0
Upon successful configuration, the OER process would start on the MC:
R1#
*Mar 1 00:30:43.303: %OER_MC-5-NOTICE: BR 2.2.2.2 UP
*Mar 1 00:30:43.315: %OER_MC-5-NOTICE: BR 2.2.2.2 IF Se0/0 UP
*Mar 1 00:30:43.339: %OER_MC-5-NOTICE: BR 2.2.2.2 IF Fa0/0 UP
*Mar 1 00:30:43.339: %OER_MC-5-NOTICE: BR 2.2.2.2 Active
R1#
*Mar 1 00:30:50.263: %OER_MC-5-NOTICE: BR 4.4.4.4 UP
*Mar 1 00:30:50.287: %OER_MC-5-NOTICE: BR 4.4.4.4 IF Se0/0 UP
*Mar 1 00:30:50.295: %OER_MC-5-NOTICE: BR 4.4.4.4 IF Fa0/0 UP
*Mar 1 00:30:50.295: %OER_MC-5-NOTICE: BR 4.4.4.4 Active
*Mar 1 00:30:50.295: %OER_MC-5-NOTICE: MC Active
Verification commands like `sh oer master` and `show oer border` were crucial.
R1#sh oer master
OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 1790
Version: 2.1
Number of Border routers: 2
Number of Exits: 2
Number of monitored prefixes: 0 (max 5000)
Max prefixes: total 5000 learn 2500
Prefix count: total 0, learn 0, cfg 0
Border Status UP/DOWN AuthFail Version
4.4.4.4 ACTIVE UP 00:00:23 0 2.1
2.2.2.2 ACTIVE UP 00:00:30 0 2.1
R2#sh oer border
OER BR 2.2.2.2 ACTIVE, MC 1.1.1.1 UP/DOWN: UP 00:05:14,
Auth Failures: 0
Conn Status: SUCCESS, PORT: 1790
Version: 2.1 MC Version: 2.1
Exits
Fa0/0 INTERNAL
Se0/0 EXTERNAL
The MC was then configured to learn prefixes based on **throughput** and **delay**, specifying learning intervals and aggregation types (e.g., /32 routes).
R1(config)#oer master
R1(config-oer-mc)#learn
R1(config-oer-mc-learn)#throughput
R1(config-oer-mc-learn)#delay
R1(config-oer-mc-learn)#periodic-interval 1
R1(config-oer-mc-learn)#monitor-period 2
R1(config-oer-mc-learn)#expire after time 30
*Mar 1 00:42:01.443: %OER_MC-5-NOTICE: Prefix Learning STARTED
R1(config-oer-mc-learn)#aggregation-type prefix-length 32
R1(config-oer-mc-learn)#exit
Finally, policy decisions were configured, including backoff periods, route control mode, and the selection of the best exit interface. Priority was given to **loss**, then **delay**, **utilization**, and **range**.
R1(config-oer-mc)#backoff 180 360
R1(config-oer-mc)#mode route control
*Mar 1 00:44:41.683: %OER_MC-5-NOTICE: Prefix Learning WRITING DATA
R1(config-oer-mc)#mode select-exit best
R1(config-oer-mc)#periodic 180
R1(config-oer-mc)#resolve loss priority 1 variance 1
R1(config-oer-mc)#resolve delay priority 2 variance 1
R1(config-oer-mc)#resolve utilization priority 3 variance 1
R1(config-oer-mc)#resolve range priority 4
Verification confirmed these settings:
R1#sh oer master
OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 1790
Version: 2.1
Number of Border routers: 2
Number of Exits: 2
Number of monitored prefixes: 0 (max 5000)
Max prefixes: total 5000 learn 2500
Prefix count: total 0, learn 0, cfg 0
Border Status UP/DOWN AuthFail Version
4.4.4.4 ACTIVE UP 00:18:03 0 2.1
2.2.2.2 ACTIVE UP 00:18:10 0 2.1
Global Settings:
max-range-utilization percent 20 recv 0
mode route metric bgp local-pref 5000
mode route metric static tag 5000
trace probe delay 1000
logging
Default Policy Settings:
backoff 180 360 180
delay relative 50
holddown 300
periodic 180
probe frequency 56
mode route control
mode monitor both
mode select-exit best
loss relative 10
jitter threshold 20
mos threshold 3.60 percent 30
unreachable relative 50
resolve loss priority 1 variance 1
resolve delay priority 2 variance 1
resolve utilization priority 3 variance 1
resolve range priority 4 variance 0
Learn Settings:
current state : STARTED
time remaining in current state : 168 seconds
throughput
delay
no inside bgp
no protocol
monitor-period 2
periodic-interval 1
aggregation-type prefix-length 32
prefixes 100
expire after time 30
Traffic generation was done via **IP SLAs** from R1 to ISP loopbacks, with **IP SLA responders** on BRs.
R1(config)#ip sla 1
R1(config-ip-sla)#tcp-connect 6.6.6.6 4000
R1(config-ip-sla-tcp)#time
R1(config-ip-sla-tcp)#timeout 100
R1(config-ip-sla-tcp)#frequency 1
R1(config-ip-sla-tcp)#exit
R1(config)#ip sla schedule 1 start-time now life forever
R1(config)#ip sla 2
R1(config-ip-sla)#tcp-connect 7.7.7.7 5000
R1(config-ip-sla-tcp)#timeout 100
R1(config-ip-sla-tcp)#frequency 1
R1(config-ip-sla-tcp)#exit
R1(config)#ip sla 2
*Mar 1 00:59:46.751: %OER_MC-5-NOTICE: Prefix Learning WRITING DATA
R1(config)#ip sla schedule 2 start-time now life forever
R2(config)#ip sla responder
R2(config)#exit
Finally, the `sh oer border passive cache prefix` command showed learned routes and their associated performance metrics.
R2#sh oer border passive cache prefix
OER Passive Prefix Cache, State: enabled, 278544 bytes
2 active, 4094 inactive, 26 added
1361 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 25800 bytes
6 active, 1018 inactive, 78 added, 26 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
Prefix NextHop Src If Dst If Flows
Pkts B/Pk Active sDly #Dly PktLos #UnRch
----------------------------------------------------------------------
7.7.7.7/32 21.21.21.1 Fa0/0 Se0/0 7
10 80 64.7 0 0 0 0
6.6.6.6/32 21.21.21.1 Fa0/0 Se0/0 7
10 80 64.1 0 0 0 0
Traces confirmed the path through R2 (ISP-1). By artificially degrading R2’s interface using `traffic-shape`, the MC would detect worse performance and shift traffic to R4 (ISP-2), demonstrating the dynamic optimization.
R2(config)#int s0/0
R2(config-if)#traffic-shape rate 10000 1000 0
R1#
*Mar 1 01:27:17.499: %OER_MC-5-NOTICE: Route changed Prefix 7.7.7.7/32, BR 4.4.4.4, i/f Se0/0, Reason Range, OOP Reason Timer Expired
*Mar 1 01:27:17.499: %OER_MC-5-NOTICE: Route changed Prefix 6.6.6.6/32, BR 4.4.4.4, i/f Se0/0, Reason Range, OOP Reason Timer Expired
Traces from HOSTs then confirmed the path shifted to R4.
HOST-1#trace 6.6.6.6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
1 1.1.124.4 4 msec 4 msec 4 msec
2 42.42.42.2 4 msec * 36 msec
Modern PfR Configuration (PfRv3 and SD-WAN Application-Aware Routing):
The configuration paradigm has shifted from isolated CLI commands to **policy-driven automation**.
1. **PfRv3 (Performance Routing v3):**
For IOS-XE devices not (yet) integrated into SD-WAN, PfRv3 uses the `performance-routing` command mode. It still involves a Master Controller and Border Routers, but with a refined CLI and enhanced capabilities. The concepts of defining control policies, border elements, and specific metrics (delay, jitter, loss) remain.
! Example of conceptual PfRv3 CLI (simplified, modern IOS-XE)
! On Master Controller (MC)
performance-routing
master
border 2.2.2.2
interface GigabitEthernet0/0 internal
interface GigabitEthernet0/1 external
border 4.4.4.4
interface GigabitEthernet0/0 internal
interface GigabitEthernet0/1 external
control-policy PFR_POLICY
class VOICE
resolve loss priority 1 variance 1
resolve delay priority 2 variance 1
set path preferred exit Gig0/1
class DATA
resolve utilization priority 1 variance 1
set path preferred exit Gig0/1 load-balance
exit
exit
! On Border Routers (BR)
performance-routing
border
master 1.1.1.1
active-probe address source interface Loopback0
control-interface Loopback0
exit
2. **Cisco SD-WAN Application-Aware Routing (AAR) – The Primary Approach:**
This is where PfR truly shines today. In **Cisco SD-WAN**, you don’t configure `oer master` or `border` CLI on individual routers. Instead, you define **application-aware routing policies** within the **vManage GUI**.
* **Application Definition:** You identify applications (e.g., VoIP, Microsoft 365, internal ERP) using deep packet inspection or port/protocol.
* **SLA Classes:** You define **SLA (Service Level Agreement) classes** for each application, specifying acceptable thresholds for **delay**, **jitter**, and **packet loss**.
* **Policy Creation:** In vManage, you create a **Centralized Control Policy** that maps applications to SLA classes. This policy dictates:
* Which paths (MPLS, Internet, LTE) are preferred under normal conditions.
* Which paths to **failover** to when an SLA threshold is violated.
* How to **load-balance** traffic across multiple healthy paths.
* **Deployment:** vManage pushes these policies to the **vSmart Controller**, which then instructs the **cEdge/vEdge devices** on how to dynamically steer traffic based on real-time path monitoring.
The **active probing** and **passive monitoring** are handled automatically by the SD-WAN fabric. The MC/BR roles are abstracted; the **vSmart** is the intelligent control plane, and **cEdge/vEdge** routers execute the data plane forwarding based on policies.
Modern Path Optimization: Intent-Based Automation and SD-WAN Integration
The evolution of PfR is tightly coupled with **Intent-Based Networking (IBN)** and **SD-WAN**. This isn’t just about dynamic routing; it’s about simplifying network operations, enhancing security, and guaranteeing application performance through automation.
* Cisco SD-WAN: This is the flagship platform for advanced PfR capabilities. It uses **Application-Aware Routing (AAR)** policies to monitor path health in real-time (loss, latency, jitter) across various WAN transports. When a path degrades for a specific application, SD-WAN automatically steers traffic to a better-performing link, ensuring **Application Quality of Experience (AppQoE)**.
* Cisco DNA Center: For campus and branch networks, DNA Center extends IBN principles, allowing network administrators to define high-level business intents. While not directly configuring PfR, it integrates with SD-WAN solutions and offers advanced **network assurance** using telemetry and AI/ML to predict and prevent performance issues.
* Zero-Touch Provisioning (ZTP): Modern SD-WAN deployments leverage ZTP, allowing new branch routers to automatically onboard and receive their configurations and PfR policies from vManage, drastically reducing deployment time and human error.
Beyond CLI: Modern Network Automation for PfR/SD-WAN
While vManage provides a powerful GUI for SD-WAN policy creation, **network automation tools** are essential for integrating network operations into broader IT workflows, implementing **Infrastructure as Code (IaC)**, and managing large-scale deployments.
* Ansible Collections: For Cisco IOS-XE devices (including cEdge routers), **Ansible** with the `cisco.ios` or `cisco.dcnm` collections can automate the deployment of PfRv3 configurations or even interact with vManage’s APIs to create and manage SD-WAN policies.
* Python Libraries (Nornir, Scrapli, Netmiko): These libraries are invaluable for **programmatic interaction** with network devices.
* **Nornir:** A Python automation framework for managing inventory and executing tasks across multiple devices, perfect for deploying or verifying PfRv3 configurations.
* **Scrapli/Netmiko:** Python libraries for SSH and Telnet connections, enabling parsing of `show` commands (`show performance-routing`) or pushing configurations.
* CI/CD Pipelines: Network changes, including updates to SD-WAN policies or PfRv3 parameters, can be integrated into **Continuous Integration/Continuous Deployment (CI/CD)** pipelines. This ensures that policy changes are tested, version-controlled, and deployed automatically, minimizing risks.
Telemetry and AI-Driven Path Selection
Modern networks are **data-rich**. The ability to collect, analyze, and act on this data in real-time is crucial for advanced path optimization.
* Model-Driven Telemetry (NETCONF/RESTCONF/gNMI): Instead of relying on periodic `show` commands or SNMP, devices stream performance metrics (latency, loss, jitter, utilization) in real-time using standardized data models (YANG). This provides a granular, high-fidelity view of network health.
* AI/ML in SD-WAN Analytics: **Cisco SD-WAN Analytics** and **DNA Center Assurance** leverage **Artificial Intelligence (AI)** and **Machine Learning (ML)** to process this vast amount of telemetry data.
* **Predictive Analytics:** AI can identify trends and predict potential path degradations *before* they impact applications.
* **Anomaly Detection:** ML algorithms can quickly detect unusual network behavior, pinpointing root causes faster.
* Closed-Loop Automation: With AI/ML insights, SD-WAN can automatically adjust routing policies or trigger remedial actions without human intervention, creating a truly **self-healing network**.
Modern Security: Zero Trust and Secure Routing Practices
While PfR focuses on performance, security is paramount. Modern **SD-WAN** integrates robust security mechanisms, aligning with **Zero Trust Architecture (ZTA)** principles.
* Encrypted Control Plane: Communication between **vManage**, **vBond**, **vSmart**, and **cEdge/vEdge** routers is secured with **DTLS/TLS**, ensuring policy integrity.
* Secure Data Plane: User traffic across the WAN fabric is protected by **IPsec tunnels**, providing **encryption** and **authentication**.
* Segmentation: SD-WAN allows for granular **network segmentation** (e.g., separating guest, IoT, and corporate traffic), reducing the attack surface.
* Integrated Security: Many SD-WAN solutions integrate advanced security services like **firewall**, **IPS/IDS**, and **URL filtering** directly at the branch or through cloud-based security platforms.
Conclusion: PfR – Smarter, Faster, More Automated
From its humble beginnings in 2011, **Cisco PfR** has transformed into a critical component of modern networking. It’s no longer just a standalone feature; it’s deeply integrated into **Cisco SD-WAN** and **Intent-Based Networking** strategies. The goal remains the same: ensuring the best path for your applications. However, the *how* has evolved from manual CLI “watching like hell” to **intelligent, policy-driven automation**, leveraging **telemetry**, **AI/ML**, and robust **security** frameworks.
Embracing these modern approaches allows network engineers to build more resilient, agile, and performant networks, delivering superior user experience and driving business innovation. If you’re still on classic PfR, now is the perfect time to explore the power of **Cisco SD-WAN** and **DNA Center** to bring your network into the future.
- How to Configure a Secure Site-to-Site VPN on Cisco Firepower Complete Guide - December 3, 2025
- Jobs for Network Engineers: Roles, Skills & Pay - December 3, 2025
- How to Change WiFi Password on Any Router : The Last Guide You Need - December 1, 2025
Great post!!