Performance Routing (PfR) and OER: legacy intelligent path control

The problem it solved, and its status today

Routing protocols choose paths using fixed metrics such as hop count, bandwidth or AS path. They do not notice that one internet provider is suffering 5% packet loss while the other is clean. OER (Optimized Edge Routing) added that awareness to Cisco routers at sites with two or more WAN exits. It was renamed PfR (Performance Routing), and a redesigned PfRv3 became part of Cisco's IWAN (Intelligent WAN) solution.

OER and PfR are legacy. Cisco moved its WAN strategy to Cisco SD-WAN, where application-aware routing measures every tunnel with BFD probes and steers each application against an SLA. If you are designing today, read SD-WAN path selection and Cisco SD-WAN policies. OER and PfR remain useful for understanding older networks and exam history.

The parts

• Master controller (MC): the brain. It collects measurements, compares them with policy and tells border routers what to change. It can run on a border router or a separate box.
• Border routers (BRs): the routers with the external WAN interfaces. They measure traffic and apply the MC's decisions, for example by injecting static or BGP routes, or using policy-based routing.
• Internal and external interfaces: the MC must know which interfaces face the LAN and which face each WAN provider.

The MC and BRs talk over an authenticated session that uses a key chain.

The five phases

1. Profile: learn which traffic classes (destination prefixes or applications) matter, often the busiest ones seen in NetFlow.
2. Measure: gather performance. Passive monitoring watches real traffic (delay from TCP handshakes, loss, throughput). Active monitoring sends IP SLA probes.
3. Apply policy: compare results with targets such as maximum delay, loss, jitter, reachability, link load or cost.
4. Control (enforce): move a traffic class that is out of policy to a better exit.
5. Verify: confirm the change worked and the traffic is now in policy.

Policies, variance and timers

A policy can rank several goals, for example "first delay, then loss, then load". That creates a conflict when two exits are almost equal on the first goal: should a 2 ms delay difference outweigh a big difference in loss? Variance answers this. It sets a percentage within which two exits count as equal on one goal, so the MC moves on to the next goal to decide. Without variance, tiny differences on the top goal would always win.

Timers control how quickly the system reacts: how often it re-evaluates exits (periodic), how long it waits before acting again (backoff), and how long a decision is held before reconsidering it (holddown). Default timers are deliberately slow to avoid route flapping. In labs, people shortened them to see results within minutes, which you should not copy into production.

key chain PFR-KEY
 key 1
  key-string Lab-Pfr-Key-01
oer master
 border 10.0.0.2 key-chain PFR-KEY
  interface GigabitEthernet0/0 internal
  interface GigabitEthernet0/1 external
  interface GigabitEthernet0/2 external
oer border
 local Loopback0
 master 10.0.0.1 key-chain PFR-KEY

This classic OER syntax is shown for recognition only; later releases used pfr master and PfRv3 used a very different domain-based configuration.

Real-world example: two ISPs and a slow payroll

Around 2012, a logistics firm's head office had two internet providers and BGP to both. Users complained that a hosted payroll service was slow in the afternoons, even though BGP still preferred the first provider. The network engineer enabled OER with passive monitoring on the payroll prefix and a delay-first policy. The master controller moved that prefix to the second provider during the congested hours and back again later. When the firm moved to SD-WAN years later, the same goal was met with an application-aware routing policy, without separate master controllers.