Cisco Performance Routing (PfR) / Optimized Edge Routing (OER)

After my CCIE R&S bootcamp with Brian Dennis (reviewed a few posts agolast words), I got stuck with the idea of understanding how PFR(Performance Routing)/OER(Optimized Edge Routing) really works, prior to this, I had avoided this topic for a myriad of reasons. I have done some labbing, reading and testing and I wanted to share my view and simplified understanding of this feature, so you can use it in your study to pass the CCIE lab. I’m going to explain it on two different post, this one covering much of the theory and basic configuration and another a little bit more advanced.

In current networks, we are basically working with a very “static” decision process that is done mostly based on the amount of bandwith declared on a link. Current standard setups can’t take into account usage, delay, efficient load distribution (underutilized links), and more important, actual reachability to the destination network. This could lead to traffic blackout and also to not efficient forwarding through a link with over utilization/loss/delay.

PFR/OER is a technology designed to address these issues and basically achieve:

  • Routing based on the actual behavior of the network, and not a statically defined metric.
  • Minimize the risk of black-holing traffic by testing actual reachability.
  • Effective load sharing and efficient utilization of network resources.
  • Possibility to define specific profile’s for certain traffic type and/or applications.

General overview of the infrastructure (How it works)

PFR/OER is implemented around two entities, a Border Router (BR) and the Master Controler (MC). Both of these can co-exist on the same physical device, but as a requirement you need to have at least two external links configured in the topology (if you have one device only, this needs to have two external links minimum).

  • The Border router (BR) duty is to do the actual switching of the traffic and collect netflow and IP SLA probes information for the Master Controler.
  • The Master Controler (MC) duty is basically to analyze all the data that the BR(s) is/are collecting (Netflow/IP SLA), and make decisions about how the flow has to go, pushing these changes to the BR.

In short, the BR gathers statistics of the behavior of the network and sends it to the MC so it can analyze the data and make a decision. If a routing change is needed, MC will push that info to the BR so it can actually modify the routing behavior. The MC router does not directly affect the forwarding path of the traffic, BRs are the ones that do so. They become the executing hand of the changes that the MC informs to do. Let’s say for example that one BR is experiencing high delay on a specific prefix (more than 250 ms) by an IP SLA probe. So it sends that information to the MC, which will compare the info with a configured “rule”, and it will decide whether a routing change must be done. If so, MC will  “tell” the BR to change the forwarding path of this specific prefix by injecting a static route (just an example) that points to another link with less delay.

Performance Routing engine:

PFR/OER works in 5 phases:

  • Learning: The MC tells the BR to learn/discover the traffic classes based on destination prefix, ports, NBAR applications, DSCP, etc.
  • Measuring: For the traffic classes learned, PFR/OER is going to measure their performance with netflow information and IP SLA probes (depending on the configuration). The measured values can be delay, mos, availability, jitter, etc.
  • Applying Policy: With the measurements done, the MC will decide whether the traffic classes are IN POLICY based on the configured parameters, or OUT OF POLICY. If an alternate path exists, it will be also checked to confirm that meets the configured requirements.
  • Enforcing: Modify the routing behavior by injecting statics routes, working with the BGP local preference, forcing policy-based routing, etc.
  • Verifying: Check that the new enforced change is compatible with the defined policy.

Important things easily forgotten when configuring PFR/OER

You need to keep in mind the following details (they are not that clear in the documentation):

  • Parent route: In order for the MC to be able to tell the BR to inject a static route for a specific prefix, the BR needs to be able to route using that new exit point in the first place, then, a route needs to exist in the database. It’s important to understand that this route does not need to be active in the routing table, so for example a floating static route would do the trick. Imagine that we have R1 with two external interfaces like f0/0 (10.0.124.1) as a main interface and s0/0 (10.10.10.2) as a secondary link. A valid configuration using static routes would be:

ip route 0.0.0.0 0.0.0.0 10.0.124.1
ip route 0.0.0.0 0.0.0.0 10.10.10.2 20
If you manage to forget the floating route in this kind of setup, simply it won’t work. Your setup may include BGP, OSFP, etc. not only static routes. Just be sure that the requierement is covered.

  • Access-list: ACL’s are not used to match ip address, but for protocols/port information. It’s very easy to make a mistake on this. Just try to remember, why to use an ACL if you have a prefix-list to match addresses? If you need to match based on a prefix and on a protocol, use both, or better, use NBAR and a prefix-list.
  • Same IP segment: If you are going to base the routing decision process on protocol information and not just on ip prefix, the BR needs to be on the same ip segment. This is because for this kind of manipulation, PBR (policy based routing) is going to be used. PBR will change the next-hop of the traffic as it’s received on the “incoming interface” and if the BR doesn’t share the segment, the packets may end looping. A possible solution, if the routers are in different subnets, is to use tunnels.
  • You need at least two exit points: PFR would not make any sense if you can’t change the behavior of the network. To be able to do that, you need minimum two exit points in the setup. It does not matter if both of them are in the same device, but they must exist and be defined in the configuration. Makes sense, right?
  • Version: The PFR/OER version configured on the master controller needs to be superior or equal to the one configured on the BRs. Otherwise, you may have some weird behavior.

Configuration

I’m going to show a basic configuration, and on future posts, we will work in a more “advanced” one.

In this setup we are going to have 2 border routers (BR) and 1 master controller (MC) on the topology. The network has a lot of traffic flowing but we are just going to focus on the prefix 30.1.1.0/24. Let’s imagine this prefix involves very critical traffic for our network, so we want to give it the best possible treatment. All traffic going that way belongs to an interactive application, so it must go with the lowest delay possible.

We are then going to configure a policy so that this critical traffic gets moved into another link if the delay measurements is superior to 80 ms.

Performance Routing Setup graph

Define the infrastructure:

Border router:

The configuration on the BR is very simple: you just have to specify the “local” interface, that basically defines which interface is going to be used as source for the connections, and a key chain to define the password that is going to be used to authenticate the messages:

key chain CHAIN
 key 1
  key-string CISCO
pfr border
 logging
 local Loopback0
 master 10.3.3.3 key-chain CHAIN

Master Controller:

It’s in the master controller where all the magic happens. For the infrastructure you need to define the key chain, and the BR of the topology. On this part you need to define which of the interfaces of the BR are going to be inside the PFR/OER domain, and its functions: internal for the inside of the network and external for outside.

key chain CHAIN
 key 1
  key-string CISCO

pfr master
 policy-rules CRITICAL-TRAFFIC
 logging
 !
 border 10.5.5.5 key-chain CHAIN
  interface Ethernet0/0 internal
  interface Ethernet0/1 external
 !
 border 10.4.4.4 key-chain CHAIN
  interface Ethernet0/1 external
  interface Ethernet0/0 internal

After this configuration you should be able to see the BR come up, and at “ACTIVE” status:

MC#show pfr master
OER state: ENABLED and ACTIVE
  Conn Status: SUCCESS, PORT: 3949
  Version: 3.1
  Number of Border routers: 2
  Number of Exits: 2
  Number of monitored prefixes: 1 (max 5000)
  Max prefixes: total 5000 learn 2500
  Prefix count: total 1, learn 0, cfg 1
  PBR Requirements met
  Nbar Status: Inactive

Border           Status   UP/DOWN             AuthFail  Version  DOWN Reason
10.5.5.5         ACTIVE   UP       00:14:41          0  3.1
10.4.4.4         ACTIVE   UP       00:14:42          0  3.1

Policies:

Inside the “pfr master” configuration you can define general policies to apply to all traffic. If you define more specific ones later, this would overwrite the general ones (like we are going to see next). Example:

pfr master
 holddown 90
 periodic 90
 no resolve range
 no resolve utilization

You can check the current configuration with the command “show pfr master”. One interesting thing about this output is that you configure the different parameters (syntax) the same way it’s displayed in this command. Example: How do you configure PFR/OER to be in observe mode?: mode route observe

MC#show pfr master
OER state: ENABLED and ACTIVE
  Conn Status: SUCCESS, PORT: 3949
  Version: 3.1
  Number of Border routers: 2
  Number of Exits: 2
  Number of monitored prefixes: 1 (max 5000)
  Max prefixes: total 5000 learn 2500
  Prefix count: total 1, learn 0, cfg 1
  PBR Requirements met
  Nbar Status: Inactive

Border           Status   UP/DOWN             AuthFail  Version  DOWN Reason
10.5.5.5         ACTIVE   UP       00:00:10          0  3.1
10.4.4.4         ACTIVE   UP       00:00:10          0  3.1

Global Settings:
  max-range-utilization percent 20 recv 0
  rsvp post-dial-delay 0 signaling-retries 1
  mode route metric bgp local-pref 5000
  mode route metric static tag 5000
  trace probe delay 1000
  logging
  exit holddown time 60 secs, time remaining 0

Default Policy Settings:
  backoff 300 3000 300
  delay relative 50
  holddown 90
  periodic 90
  probe frequency 56
  number of jitter probe packets 100
  mode route observe
  mode monitor both
  mode select-exit good
  loss relative 10
  jitter threshold 20
  mos threshold 3.60 percent 30
  unreachable relative 50
  resolve delay priority 11 variance 20

Learn Settings:
  current state : DISABLED
  time remaining in current state : 0 seconds
  no throughput
  no delay
  no inside bgp
  monitor-period 5
  periodic-interval 120
  aggregation-type prefix-length 24
  prefixes 100 appls 100
  expire after time 720

Static definition of traffic and policy:

As I mentioned on the general setup overview, we have a traffic that is very critical and we need to do some manipulation for it. I’m going to explain this policy definition, as you’ll type it to configure it:

pfr-map CRITICAL-TRAFFIC 50
Name of the PFR-MAP, basically it works the same way as route-map does: you have a sequence number that defines the order in witch PFR/OER is going to look at the policy defined. The way that IOS goes through is the same as with a route-map

match traffic-class prefix-list CRITICAL
This commands define the traffic that is going to be matched in this policy definition. Here, we are only working on a specific prefix, but you can also match on ports, dscp, nbar, etc.

set periodic 90
How often PFR/OER is going to try to find a better path for this specific traffic (seconds).

set mode select-exit good
Defines how PFR/OER is going to choose the best exit. There are two possible options in here: “good”, which means that PFR/OER is going to pick an exit point that just falls under the IN POLICY needs, or “best” which means that will always try to find the best link available, even if the “current” one is offering an “IN POLICY” state.

set backoff 90 90
This timer controls how much time the master controller waits for an out of policy traffic before trying to find a better link (seconds).

set delay threshold 80
Here we define how much delay we are going to tolerate for this traffic class. I have defined a maximum of 80 ms. If PFR/OER finds that the traffic class is having a delay higher than this quantity, it declares the traffic as out of policy and will look for a better one.

set mode route control
Here we tell PFR/OER to control the actual traffic. By default, it’s just going to “observe”. Setting it to “control” means that PFR/OER is going to actually change the behaviour of the network

set mode monitor both
We are going to speak more about the monitor modes in the next post. For now, keep in mind that we are going to use Netflow information (passive) and IP SLA probes (active) to measure the performance of this traffic class.

set resolve delay priority 1 variance 10
The resolve parameter defines what PFR/OER is going to take into account to make decisions about the IN POLICY or OUT OF POLICY state of a specific class. Here we are telling that delay is our priority.

no set resolve range
no set resolve utilization

We are not going to take into account these two parameters. Basically, PFR/OER is configured to only look for delay (and unreachable state, that is the most important)

set active-probe echo 30.1.1.11
It’s going to send IP SLA probes to this destination network to measure the performance. This info plus the netflow information, will feed the master controller database so it can make decisions.

pfr master
policy-rules CRITICAL-TRAFFIC

Here we apply the policy to the PFR/OER process.

The final configuration for the Master Controller will be:

key chain CHAIN
 key 1
  key-string CISCO

pfr master
 policy-rules CRITICAL-TRAFFIC
 logging
 !
 border 10.5.5.5 key-chain CHAIN
  interface Ethernet0/0 internal
  interface Ethernet0/1 external
 !
 border 10.4.4.4 key-chain CHAIN
  interface Ethernet0/1 external
  interface Ethernet0/0 internal
 holddown 90
 periodic 90
 no resolve range
 no resolve utilization
pfr-map CRITICAL-TRAFFIC 50
 match traffic-class prefix-list CRITICAL
 set periodic 90
 set mode select-exit good
 set backoff 90 90
 set delay threshold 80
 set mode route control
 set mode monitor both
 set resolve delay priority 1 variance 10
 no set resolve range
 no set resolve utilization
 set active-probe echo 30.1.1.11

You can see the results of your policy configuration

MC#show pfr master policy
Default Policy Settings:
  backoff 300 3000 300
  delay relative 50
  holddown 90
  periodic 90
  probe frequency 56
  number of jitter probe packets 100
  mode route observe
  mode monitor both
  mode select-exit good
  loss relative 10
  jitter threshold 20
  mos threshold 3.60 percent 30
  unreachable relative 50
  resolve delay priority 11 variance 20
oer-map CRITICAL-TRAFFIC 50
  sequence no. 8444249304596480, provider id 1, provider priority 30
    host priority 0, policy priority 50, Session id 0
  match ip prefix-lists: CRITICAL
 *backoff 90 90 90
 *delay threshold 80
  holddown 90
 *periodic 90
  probe frequency 56
  number of jitter probe packets 100
 *mode route control
 *mode monitor both
 *mode select-exit good
  loss relative 10
  jitter threshold 20
  mos threshold 3.60 percent 30
  unreachable relative 50
  next-hop not set
  forwarding interface not set
 *resolve delay priority 1 variance 10

  Forced Assigned Target List:
   active-probe echo 30.1.1.11 target-port 0

* Overrides Default Policy Setting

These commands help us also to see what we have actually changed for the policy compared to the default values (all values with a * prepended)

To see the current traffic classes:

MC#show pfr master traffic-class
OER Prefix Statistics:
 Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),
 P - Percentage below threshold, Jit - Jitter (ms),
 MOS - Mean Opinion Score
 Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),
 E - Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable
 U - unknown, * - uncontrolled, + - control more specific, @ - active probe all
 # - Prefix monitor mode is Special, & - Blackholed Prefix
 % - Force Next-Hop, ^ - Prefix is denied

DstPrefix           Appl_ID Dscp Prot     SrcPort     DstPort SrcPrefix
           Flags             State     Time            CurrBR  CurrI/F Protocol
         PasSDly  PasLDly   PasSUn   PasLUn  PasSLos  PasLLos      EBw      IBw
         ActSDly  ActLDly   ActSUn   ActLUn  ActSJit  ActPMOS  ActSLos  ActLLos
--------------------------------------------------------------------------------
30.1.1.0/24               N    N    N           N           N N
                          HOLDDOWN       76          10.5.5.5 Et0/1           BGP
               U        U        0        0        0        0        1        0
               2        2        0        0        N        N        N        N

In this output, you’ll see the traffic that you have statically defined (like we did) and also, if enabled, all the traffic that PFR/OER is learning (not in our case, as we are not auto learning anything).

And you can see the specific performance information of the traffic class, with the following command:

MC#show pfr master traffic-class performance ip any 30.1.1.0/24
==============================================================================================

Traffic-class:
 Destination Prefix : 30.1.1.0/24             Source Prefix    : N/A
 Destination Port   : N/A                     Source Port      : N/A
 DSCP               : N                       Protocol         : N/A
 Application Name:  : N/A

 General:
   Control State                   : Controlled using BGP
   Traffic-class status            : INPOLICY
   Current Exit                    : BR 10.5.5.5 interface Et0/1, Tie breaker was Random due to Tie
   Time on current exit            : 0d 0:2:28
   Time remaining in current state : @66 seconds
   Traffic-class type              : Configured
   Improper config                 : None

 Last Out of Policy event:
   Exit                            : BR 10.5.5.5 interface Et0/1
   Reason                          : Range
   Time since Out of Policy event  : 0d 0:0:25
   Link OOP; no prefix performance :

 Average Passive Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 2 msecs -- Threshold: 80 msecs
   Loss                   : 0% -- Threshold: 10%
   Egress BW              : 49 kbps
   Ingress BW             : 12 kbps
   Time since last update : 0d 0:0:55

 Average Active Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 2 msec -- Threshold: 80 msec

==============================================================================================

Right now, focus only on the values I have highlighted. Basically, look that we are right now inside the IN POLICY state, we are using 10.5.5.5 as our exit BR, which is offering a delay of 2 msec both on our passive (netflow stats) and our IP SLA probe.

If we increase the delay of the link connected to R5, PFR/OER will react to the change and will modify the actual path:

*Feb 29 22:49:57.111: %OER_MC-5-NOTICE: Route changed Prefix 30.1.1.0/24, BR 10.4.4.4, i/f Et0/1, Reason Delay, OOP Reason Range

MC#show pfr master traffic-class performance ip any 30.1.1.0/24
==============================================================================================

Traffic-class:
 Destination Prefix : 30.1.1.0/24             Source Prefix    : N/A
 Destination Port   : N/A                     Source Port      : N/A
 DSCP               : N                       Protocol         : N/A
 Application Name:  : N/A

 General:
   Control State                   : Controlled using BGP
   Traffic-class status            : HOLDDOWN
   Current Exit                    : BR 10.4.4.4 interface Et0/1, Tie breaker was Delay
   Time on current exit            : 0d 0:0:7
   Time remaining in current state : 77 seconds
   Traffic-class type              : Configured
   Improper config                 : None

 Last Out of Policy event:
   Exit                            : BR 10.4.4.4 interface Et0/1
   Reason                          : Range
   Time since Out of Policy event  : 0d 0:0:41
   Link OOP; no prefix performance :

 Average Passive Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 0 msecs -- Threshold: 80 msecs
   Loss                   : 0% -- Threshold: 10%
   Egress BW              : 74 kbps
   Ingress BW             : 17 kbps
   Time since last update : 0d 2:36:32

 Average Active Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 0 msec -- Threshold: 80 msec

 Last Resolver Decision:
   BR              Interface    Status       Reason       Performance Threshold
   --------------- ------------ ------------ ------------ ----------- ---------
   10.5.5.5        Et0/1        Eliminated   Delay        106 msecs    80 msecs
   10.4.4.4        Et0/1        Best Exit    Delay        1 msecs      80 msecs    

==============================================================================================

As the output shows, we have switched over to 10.4.4.4 because there was too much delay for this specific class. Again, focus on the highlighted sections. Right now we are on a “HOLDDOWN” state, witch means that PFR/OER have made a recent change and it’s waiting for the network to stabilize before actually making another change (if needed). Basically we dont want changes too often (that could lead to flapping). Look also that we can see how much delay the prefix  10.5.5.5 is having (106ms).

How was the change enforced? By changing the local preference of this prefix in BGP:

R2#show ip bgp
BGP table version is 68, local router ID is 10.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
r>i10.4.5.0/24      10.4.4.4                 0    100      0 i
r i                 10.5.5.5                 0    100      0 i
*>i20.10.10.10/32   100.4.8.8                0    100      0 100 20 i
* i                 100.5.9.9                0    100      0 200 20 i
*>i20.10.11.0/24    100.4.8.8                0    100      0 100 20 i
* i                 100.5.9.9                0    100      0 200 20 i
*>i20.11.11.11/32   100.4.8.8                0    100      0 100 20 i
* i                 100.5.9.9                0    100      0 200 20 i
*>i30.1.0.0/24      100.5.9.9                0    200      0 200 20 i
*>i30.1.1.0/24      100.4.8.8                0   5000      0 100 20 i

Keep in mind that I did not do any special configuration on the BGP side, everything is handle automatically by PFR/OER

After a while, the traffic class would be back into a IN POLICY state:

MC#show pfr master traffic-class
OER Prefix Statistics:
 Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),
 P - Percentage below threshold, Jit - Jitter (ms),
 MOS - Mean Opinion Score
 Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),
 E - Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable
 U - unknown, * - uncontrolled, + - control more specific, @ - active probe all
 # - Prefix monitor mode is Special, & - Blackholed Prefix
 % - Force Next-Hop, ^ - Prefix is denied

DstPrefix           Appl_ID Dscp Prot     SrcPort     DstPort SrcPrefix
           Flags             State     Time            CurrBR  CurrI/F Protocol
         PasSDly  PasLDly   PasSUn   PasLUn  PasSLos  PasLLos      EBw      IBw
         ActSDly  ActLDly   ActSUn   ActLUn  ActSJit  ActPMOS  ActSLos  ActLLos
--------------------------------------------------------------------------------
30.1.1.0/24               N    N    N           N           N N
                          INPOLICY      @87          10.4.4.4 Et0/1           BGP
              21       21        0        0        0        0       61       17
               U        U        0        0        N        N        N        N

MC#show pfr master traffic-class performance ip any 30.1.1.0/24
==============================================================================================

Traffic-class:
 Destination Prefix : 30.1.1.0/24             Source Prefix    : N/A
 Destination Port   : N/A                     Source Port      : N/A
 DSCP               : N                       Protocol         : N/A
 Application Name:  : N/A

 General:
   Control State                   : Controlled using BGP
   Traffic-class status            : INPOLICY
   Current Exit                    : BR 10.4.4.4 interface Et0/1, Tie breaker was Delay
   Time on current exit            : 0d 0:2:13
   Time remaining in current state : @73 seconds
   Traffic-class type              : Configured
   Improper config                 : None

 Last Out of Policy event:
   Exit                            : BR 10.4.4.4 interface Et0/1
   Reason                          : Range
   Time since Out of Policy event  : 0d 0:2:47
   Link OOP; no prefix performance :

 Average Passive Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 21 msecs -- Threshold: 80 msecs
   Loss                   : 0% -- Threshold: 10%
   Egress BW              : 61 kbps
   Ingress BW             : 17 kbps
   Time since last update : 0d 0:0:32

 Average Active Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 0 msec -- Threshold: 80 msec

 Last Resolver Decision:
   BR              Interface    Status       Reason       Performance Threshold
   --------------- ------------ ------------ ------------ ----------- ---------
   10.5.5.5        Et0/1        Eliminated   Delay        106 msecs    80 msecs
   10.4.4.4        Et0/1        Best Exit    Delay        1 msecs      80 msecs    

==============================================================================================

Now, what happens if 10.4.4.4 fails? would the MC switch over to 10.5.5.5 even if that exit is not providing a good enough link?

I’m going to shut down one of the links that 10.4.4.4 uses to forward the traffic (not the one directly connected), so you can see how it reacts.

MC#show pfr master traffic-class performance ip any 30.1.1.0/24
==============================================================================================

Traffic-class:
 Destination Prefix : 30.1.1.0/24             Source Prefix    : N/A
 Destination Port   : N/A                     Source Port      : N/A
 DSCP               : N                       Protocol         : N/A
 Application Name:  : N/A

 General:
   Control State                   : Controlled using BGP
   Traffic-class status            : INPOLICY
   Current Exit                    : BR 10.4.4.4 interface Et0/1, Tie breaker was None
   Time on current exit            : 0d 0:15:53
   Time remaining in current state : @9 seconds
   Traffic-class type              : Configured
   Improper config                 : None

 Last Out-of-Policy event:
   No Out-of-Policy Event

 Average Passive Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 21 msecs -- Threshold: 80 msecs
   Loss                   : 624% -- Threshold: 10%
   Egress BW              : 34 kbps
   Ingress BW             : 4 kbps
   Time since last update : 0d 0:0:8

 Average Active Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 333333% -- Threshold: 50%
   Delay                  : 1 msec -- Threshold: 80 msec

 Last Resolver Decision:
   BR              Interface    Status       Reason       Performance Threshold
   --------------- ------------ ------------ ------------ ----------- ---------
   10.5.5.5        Et0/1        Eliminated   Delay        108 msecs    80 msecs
   10.4.4.4        Et0/1        Best Exit    Delay        1 msecs      80 msecs    

==============================================================================================

Our active probe is failing. Look at the Unreachable (passive is showing loss), if you wait a few seconds:

*Feb 29 23:06:03.031: %OER_MC-5-NOTICE: Route changed Prefix 30.1.1.0/24, BR 10.5.5.5, i/f Et0/1, Reason Unreachable, OOP Reason Timer Expired

And now the traffic flows using 10.5.5.5, even if that link does not comply to the delay configured:

MC#show pfr master traffic-class performance ip any 30.1.1.0/24
==============================================================================================

Traffic-class:
 Destination Prefix : 30.1.1.0/24             Source Prefix    : N/A
 Destination Port   : N/A                     Source Port      : N/A
 DSCP               : N                       Protocol         : N/A
 Application Name:  : N/A

 General:
   Control State                   : Controlled using BGP
   Traffic-class status            : HOLDDOWN
   Current Exit                    : BR 10.5.5.5 interface Et0/1, Tie breaker was Unreachable
   Time on current exit            : 0d 0:1:7
   Time remaining in current state : 39 seconds
   Traffic-class type              : Configured
   Improper config                 : None

 Last Out-of-Policy event:
   No Out-of-Policy Event

 Average Passive Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 109 msecs -- Threshold: 80 msecs
   Loss                   : 0% -- Threshold: 10%
   Egress BW              : 21 kbps
   Ingress BW             : 3 kbps
   Time since last update : 0d 0:0:11

 Average Active Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Delay                  : 0 msec -- Threshold: 80 msec

 Last Resolver Decision:
   BR              Interface    Status       Reason       Performance Threshold
   --------------- ------------ ------------ ------------ ----------- ---------
   10.4.4.4        Et0/1        Eliminated   Unreachable  1000000%     157894%
   10.5.5.5        Et0/1        Best Exit    Unreachable  N/A          N/A         

==============================================================================================

This is just the basics, wait for the next post :)

Please, if you like our post don’t forget to hit the google +1 button at begining of the article.

Daniel Rodriguez

Daniel is the co-founder of Network Faculty. He holds the following certifications: CCNA, CCNP, CCIP, LPIC Level 2 and Security+. He loves Perl Programming, Linux, IPv6 and Multicast deployments. When not doing network related study/work, he is training for triathlons and other endurance sports.

More Posts - Website - Twitter - Facebook

Creative Commons License
The Cisco Performance Routing (PfR) / Optimized Edge Routing (OER) by CCIE Blog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

Tags: , ,

43 Responses to "Cisco Performance Routing (PfR) / Optimized Edge Routing (OER)"

  • Daniel says:
  • Sirwan says:
  • sirwan says:
  • LiMeng says:
  • LiMeng says:
  • Karthic says:
  • LiMeng says:
  • Andrei says:
  • Adey says:
  • yasir says:
      • Yasir says:
  • Julius says:
  • event84 says:
  • Event84 says:
  • Event84 says:
  • AsoG says:
  • AsoG says:
  • AsoG says:
  • c1sc0m says:
  • c1sc0m says:
  • Artoshi says:
  • Artoshi says:
  • Artoshi says:
  • Artoshi says:
  • Shahin says:
Leave a Comment

*

Notify me of followup comments via e-mail. You can also subscribe without commenting.