Optimized Edge Routing and Performance Routing (OER/PfR): legacy performance-based WAN routing

The problem OER solved

Routing protocols pick paths using bandwidth, cost or hop count. They do not notice that an internet link is congested or that one provider has high delay at lunchtime. Around the mid-2000s Cisco introduced Optimized Edge Routing (OER) for sites with two or more WAN or internet exits. It was later expanded and renamed Performance Routing (PfR). Both are legacy technologies today, but you may meet them in older networks and exam material, and their ideas live on in SD-WAN.

Components

• Master controller (MC): the brain. It gathered measurements, compared them with policies and decided which exit each traffic class should use. It could run on its own router or on a border router.
• Border routers (BR): the routers with the WAN exits. They measured traffic and applied the controller's decisions, for example by injecting more specific routes or using policy-based routing.
• Internal and external interfaces: each border router told the controller which interfaces faced the LAN and which faced the WAN exits.

The controller and border routers talked over an authenticated session using a key chain. A simplified legacy configuration looked like this:

! legacy OER syntax, removed from current releases
key chain OER-KEY
 key 1
  key-string Example-Key
oer master
 border 10.0.0.2 key-chain OER-KEY
  interface GigabitEthernet0/0 internal
  interface GigabitEthernet0/1 external
  interface GigabitEthernet0/2 external
oer border
 local Loopback0
 master 10.0.0.1 key-chain OER-KEY

The five phases

1. Profile: learn which traffic classes (destination prefixes or applications) are worth optimising, automatically from traffic or from a configured list.
2. Measure: collect performance data per exit, passively from NetFlow-style traffic statistics or actively with IP SLA probes.
3. Apply policy: compare results with targets such as maximum delay, loss, jitter, link use or cost.
4. Control (enforce): move traffic classes that break the policy to a better exit.
5. Verify: check that the traffic really moved and performance improved, and undo it if not.

Policies, variance and timers

A policy could consider several measures at once, each with a priority, for example delay first, then loss, then link use. That raises a conflict: one exit may have slightly lower delay while another has much less loss. Variance solved this by treating exits within a set percentage of the best value as equally good for a higher-priority measure, so the next priority could decide between them.

Timers controlled how quickly it reacted: how often it re-evaluated everything (periodic), how long a traffic class had to stay on a new exit before moving again (holddown, to prevent flapping), and how long to back off when no exit met the policy. Lab guides often shortened these so changes could be observed in minutes rather than hours.

What replaced it

PfR version 3 became part of Cisco IWAN (Intelligent WAN), which combined DMVPN, PfR and centralised policy. IWAN was discontinued, and Cisco now directs customers to Cisco SD-WAN (Catalyst SD-WAN), where a central controller defines application SLAs and every edge router measures paths continuously with BFD probes. The phases are the same in spirit, but configuration, visibility and scaling are far simpler. See SD-WAN path selection and what SD-WAN is.

Real-world example: a travel agency chain once used PfR at its head office to choose between an MPLS link and an internet VPN for its booking system. Reconfiguring policies needed an engineer at the command line, and troubleshooting moved routes was difficult. When the routers reached end of support, the company moved to an SD-WAN service. The same rule, "booking traffic must have less than 150 ms delay and 1 percent loss", now lives in one central policy and the dashboard shows which link each branch uses and why.