OER/PfR Part One.... We're going to call it PfR!

Hi Everyone,

We had a discussion on OER/PfR today during a free Live On-Line Group
Mentoring session that about 45 people attended. This series of e-mails
will highlight some of the main topics we covered in todays Live On-line
Group Mentoring session on OER/PfR. This e-mail will be the first in a
series of e-mails I will post on the subject of OER/PfR.

For the rest of this e-mail, I will simply refer to OER/PfR by its new name
performance based routing or PfR. The name performance based routing
accurately describes what PfR does: PfR makes path selection decisions
based upon measuring real-time performance characteristics of multiple
paths to a specific destination address. Performance characteristics
include delay and throughput. To get started with PfR, here are three
basic configuration steps or phases you can perform (NOTE: While the new
name of this IOS mechanism is PfR, all of the IOS commands associated
with PfR are still called oer!!!  Very confusing!!):

We divided a basic PfR configuration steps into the following three phases:

***Phase One

1). Establish communications between the PfR Master Controller (MC) and the
PfR Border Router(s) (BR). All PfR implementations must have one MC and at
least one BR.

1.2) Configure an MD5 key between the MC and BR. THIS IS MANDATORY!!!

1.3). During this first phase, determine what interfaces will be internal
interfaces on the Border Router(s) and what interfaces will be external
interfaces on the Border Router(s). For any PfR configuration, there must be
at least on internal interface and two external interfaces.

1.4). Specify a BR local interface. THIS STEP IS MANDATORY! This step is
similar to specifying a BGP update-source on the BR.

Here is a snippet of this part of the PfR configuration:

oer master

!

 border 1.1.1.6 key-chain OER

  interface FastEthernet0/0 internal

  interface Serial0/0/0.62 external

  interface FastEthernet0/1 external

 !

oer border

local FastEthernet0/0

 master 1.1.1.6 key-chain OER

This portion of the configuration can be verified with the following IOS
show command:

R6#sh oer master

OER state: ENABLED and ACTIVE g NOTICE THAT THE MC AND BR relationship is
ENABLED & ACTIVE

  Conn Status: SUCCESS, PORT: 3949

  Version: 2.2

  Number of Border routers: 1

  Number of Exits: 2

  Number of monitored prefixes: 3 (max 5000)

  Max prefixes: total 5000 learn 2500

  Prefix count: total 3, learn 0, cfg 3

  PBR Requirements met

  Nbar Status: Inactive

Border Status UP/DOWN AuthFail Version

1.1.1.6 ACTIVE UP 07:00:43 0 2.2

***Phase Two

Specify the destination prefixes that PfR traffic must match so that it can
be performance routed. Here are the three basic steps we used:

1). Configure a prefix-list to specify the prefixes to be performance
routed by PfR.

2). Reference this prefix-list in an oer-map configuration. An oer-map has
the same general match and set semantics as a route-map.

3). Reference the oer-map configuration in the oer master-controller
configuration mode using the policy-rules command.

Here is a sample configuration of these Phase Two steps:

oer master

 policy-rules prfx

 MORE OER MC commands omitted..

!

oer-map prfx 10

 match traffic-class prefix-list prfx

!

ip prefix-list prfx seq 5 permit 3.3.3.3/32

Once this configuration has been entered, you can verify and check how OER
is tracking the prefixes specified (in this case in the prefix-list), with
the following very useful and insightful PfR IOS show command:

R6#show oer master prefix

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

Prefix State Time Curr BR CurrI/F
Protocol

                      PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos

                      ActSDly ActLDly ActSUn ActLUn EBw IBw

                      ActSJit ActPMOS ActSLos ActLLos

----------------------------------------------------------------------------

----
3.3.3.3/32              INPOLICY        0 1.1.1.6         Fa0/1
STATIC
                               N        N        N        N        N
N
                              31       31        0        0        N
N
                               N        N
***Phase Three
Specify how the performance routing characteristics of all possible paths
for a specified destination prefix will be learned. Will the performance
routing characteristics be actively learned via an active-probe using
an embedded IP SLA Monitor mechanism within PfR or will the performance
routing characteristics be passively learned via an embedded NetFlow
mechanism within PfR.
Here are some of the IOS configuration commands related to what we are
calling Phase Three of a basic PfR implementation. NOTE: All of the
following commands are found within the oer master controller
configuration mode. Furthermore, there is one more sub-configuration mode
within the oer master configuration mode itself. This sub configuration
mode is called learn.
oer master
!
 learn
  delay
  periodic-interval 3
  monitor-period 1
 mode route control
 mode monitor active
 !
 active-probe echo 3.3.3.3
in this sample, snippet the mode monitor active learning and performance
measurement mode is being used. This active mode will activate an embedded
IP SLA MONITOR mechanism within PfR.  This active mode configuration  is
using a simple echo probe.   Other probes include:
R6(config-oer-mc)#active-probe ?
  echo      Perform ICMP echo probe operations
  jitter    Perform jitter probe operations (requires a responder)
  tcp-conn  Perform TCP Connection / Disconnect probe operations
  udp-echo  Perform UDP Echo probe operations (requires a responder)
As you can see, PfR is a vast and complex subject! I am going to stop here
for now and follow up on this discussion with more postings. I hope you
found this first post on PfR somewhat useful. We discussed these very
subjects for about two hours today during our interactive Live On-line Group
Mentoring session.
In follow up e-mails on this interesting subject of PfR, I will supply
configuration snippets and supporting IOS show and debug traces related to
the subject of PfR. Remember, in NMC Live On-line Group Mentoring, we live
by Proof by IOS and Proof by Debug! :  )
HTH,
-Bruce
Andrew Bruce Caslow, CCIE #3139
+1 703 606 7353
NetMasterClass, LLC
Cisco Learning Partner
www.NetMasterClass.com
NMC Live On-Line Group Mentoring Sessions held on Mondays at 12 noon and 7
PM and Fridays 12 noon and 6 PM (GMT -5). All Live On-line Group Mentoring
sessions are 90 minutes each. Come join us for more Proof by Debug!
Blogs and organic groups at http://www.ccie.net