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

Nice stuff Andrew..I'll be looking forward to more of this type of post

On Wed, Nov 3, 2010 at 8:25 PM, Andrew Bruce Caslow <
abcaslow_at_netmasterclass.net> wrote:

> 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 today s 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 <http://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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Olugbenga Lasisi
CCIE(R&S)# 27036
Blogs and organic groups at http://www.ccie.net