Hi Jack,
I have found that OER and PfR are huge subjects, with the scope to
dynamically control routing decisions on a prefix basis.
The configuration below is part of Phase 1 - Profiling the traffic. I
just wanted to see how to configure the latest IOS.
The roadmap can be found here:
http://www.cisco.com/en/US/docs/ios/oer/configuration/guide/oer-roadmap.html
A Q&A on OER can be found here:
http://www.cisco.com/en/US/partner/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps8787/prod_qas0900aecd806c4f03.html
The phases in order are as follows:
Phase 0 - OER setup
Phase 1 - Profile and identify traffic classes
Phase 2 - Measure (and monitor) performance metrics of identified
traffic classes
Phase 3 - Apply Policies to Traffic Classes
Phase 4 - Control
Phase 5 - Verify
Profiling traffic is basically learning prefixes based on your
configuration - in this example I have not limited the scope of
prefixes, though you can do it in a number of places (oer-map, MC -
learn - prefix configuration, within a list, etc).
A note on PfR - Performance Routing (PfR) is an extension of the
Optimized Edge Routing (OER) technology, and you may notice here
http://www.cisco.com/en/US/docs/ios/oer/configuration/guide/12_4t/oer_12_4t_book.html
that the OER configuration guide provides you with two ways to profile
the traffic class: 1) using OER, 2) using PfR - it all comes down to the
IOS you are running and the features you require. For example, if you
running the latest 12.4(20)T IOS required for PfR traffic profiling you
may still choose to use the OER method of learning traffic classes
through protocol and ports.
Measuring comes in at phase 2. This is where you have a number of
monitoring options available to use. Note, however, you are not
controlling traffic at this point. Monitoring is defined as the act of
measurement performed periodically over a set interval of time where the
measurements are compared against a threshold, and here they are:
OER Performance Measuring
- Traffic Class Performance
- Active Monitoring
- Passive Monitoring
- Both Active and Passive Monitoring
- Fast Failover Monitoring
- Link Utilization
- Link Update Performance
Passive monitoring uses NetFlow functionality and is enabled by default.
Active probes are implemented using IP SLA functionality in IOS routers.
Note that these are created for you as part of the process (when you
enter the active-probe command under oer master), unless you require
specific active jitter probes which need to be manually created.
Depending on what port you are probing you may require additional
configuration on the remote host for the probe to function.
Once you are happy with the measurements you can apply the policy:
Configure & Apply Policy
- Policy Configuration
- Traffic Class Performance
- Link Utilization
- Timers & Operational Modes
- Policy Application
- Apply To Learned Class
- Apply to Configured Class
- Global Policy
- Specific Policy
After an OER policy is configured, the policy can be applied to learned
traffic classes or configured traffic classes. OER profiles can be
applied globally - to all the traffic classes - or to just a specific
set of traffic classes.
Again, OER takes no action upon policy violation in this phase.
The control phase gives control over to the MC and the information it is
measuring will be used to change traffic flow as required depending on
your underlying IGP and if NAT is in-use.
The OER static routing NAT solution is a single box solution and
configurations with interfaces on multiple routers using NAT and managed
by OER are not supported. Effectively you get the "oer" keyword option
at the end of the ip nat inside source:
ip nat inside source interface FastEthernet1/0 overload oer
ip nat inside source route-map isp-2 pool ISP2 oer
If you have a network using an IGP such as OSPF then a route-map is
required to redistribute the OER managed prefixes into OSPF. By default,
OER will tag the static routes with 5000. This can be changed to a
different tag if required. If you are running EIGRP within the network
you also have to exclude the OER injected static routes from being
advertised out of the router through the use of a distribute-list.
This is a short summary of OER/PfR please have a look at the links
provided for much more detail as this only touches the surface.
During my research I also found a real world story of someone who
implemented OER into their production network. The link is here:
http://www.carltonhouston.com/wordpress/?p=93
regards Andy
jack daniels wrote:
> Hi Andy,
>
>
> how does PFR check link quality and integrity - does it send peroidic
> packets for check on link end to end ( in MPLS enviornment CE-to- CE )?
>
> what will happen if there is flap in one link , will it fall over to other
> link ?
>
> On Sun, Apr 4, 2010 at 11:44 PM, Andy Reid <ccie_at_reid.it> wrote:
>
>
>> I have created a configuration that appears to work - by creating an
>> oer-map referencing the MGMT application "refname". I then fed the oer-map
>> back into the MC configuration using the policy-rules statement. The Telnet
>> traffic is now being captured correctly:
>>
>> Rack1R6# show run | se oer
>> oer master
>> policy-rules MANAGEMENT
>> logging
>> !
>> border 150.1.4.4 key-chain OER
>> interface FastEthernet0/0 external
>> interface FastEthernet0/1 internal
>> interface Serial0/2/0 external
>> !
>> border 150.1.6.6 key-chain OER
>> interface FastEthernet0/0.67 external
>> interface FastEthernet0/0.146 internal
>> interface Serial0/1/0 external
>> !
>> learn
>> throughput
>> delay
>> periodic-interval 0
>> monitor-period 1
>> list seq 1 refname MGMT
>> traffic-class application nbar telnet
>> aggregation-type prefix-length 32
>> delay
>> periodic 90
>> !
>> oer border
>> local Loopback0
>> master 150.1.6.6 key-chain OER
>> oer-map MANAGEMENT 10
>> match oer learn list MGMT
>>
>>
>> *Apr 4 17:39:24.010: %OER_MC-5-NOTICE: Discovered Exit for Appl Prefix
>> 150.1.8.8/32 telnet, BR 150.1.4.4, i/f Se0/2/0
>> Rack1R6#show oer master traffic-class learned list MGMT
>>
>> 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
>>
>> --------------------------------------------------------------------------------
>> 150.1.2.2/32 telnet defa N N N 0.0.0.0/0
>> INPOLICY* @70 150.1.4.4 Se0/2/0
>> U
>> 48 48 0 0 19073 19073 1
>> 6
>> 59 59 0 0 N N N
>> N
>>
>> 150.1.8.8/32 telnet defa N N N 0.0.0.0/0
>> DEFAULT* @44 150.1.4.4 Se0/2/0
>> U
>> U U 0 0 0 0 1
>> 0
>> U U 0 0 N N N
>> N
>>
>>
>>
>> Rack1R6#show oer master
>> OER state: ENABLED and ACTIVE
>> Conn Status: SUCCESS, PORT: 3949
>> Version: 2.2
>> Number of Border routers: 2
>> Number of Exits: 4
>> Number of monitored prefixes: 3 (max 5000)
>> Max prefixes: total 5000 learn 2500
>> Prefix count: total 3, learn 2, cfg 0
>> PBR Requirements met
>> Nbar Status: Active
>>
>> Border Status UP/DOWN AuthFail Version
>> 150.1.6.6 ACTIVE UP 00:03:22 0 2.2
>> 150.1.4.4 ACTIVE UP 00:03:22 0 2.2
>>
>>
>> Global Settings:
>> max-range-utilization percent 20 recv 0
>> 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 300
>> 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
>> resolve range priority 12 variance 0
>> resolve utilization priority 13 variance 20
>>
>> Learn Settings:
>> current state : STARTED
>> time remaining in current state : 67 seconds
>>
>> throughput
>> delay
>> no inside bgp
>> no protocol
>> monitor-period 1
>> periodic-interval 0
>> aggregation-type prefix-length 24
>> prefixes 100
>> expire after time 720
>>
>> Learn-List seq 1 refname MGMT
>>
>> Configuration:
>> Traffic-Class Application: telnet
>> Aggregation-type: prefix-length 32
>>
>> Learn type: delay
>> Session count: 50 Max count: 100
>> Policies assigned: 10
>> Stats:
>> Traffic-Class Count: 1
>>
>>
>>
>> regards Andy
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Mon Apr 05 2010 - 03:01:02 ART
This archive was generated by hypermail 2.2.0 : Sat May 01 2010 - 09:49:56 ART