Hi Ignacio,
If you lab this up, I highly recommend to use PfR. OER is pretty buggy and I had lots of issues with it.
One command I can think of is show pfr master traffic-class detail:
MC#show pfr master traffic-class detail
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 (percent/10000), 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
--------------------------------------------------------------------------------
Prefix: 10.40.40.0/24
State: INPOLICY Time Remaining: 0
Policy: Default
Most recent data per exit
Border Interface PasSDly PasLDly ActSDly ActLDly
*2.2.2.2 Gi3 0 0 11 11
3.3.3.3 Gi3 0 0 2 2
Latest Active Stats on Current Exit:
Type Target TPort Attem Comps DSum Min Max Dly
echo 10.40.40.4 N 1 1 17 6 17 17
echo 10.40.40.3 N 1 1 18 6 18 18
echo 10.40.40.4 N 1 1 6 6 6 6
echo 10.40.40.3 N 1 1 6 6 6 6
Prefix performance history records
Current index 7, S_avg interval(min) 5, L_avg interval(min) 60
Age Border Interface OOP/RteChg Reasons
Pas: DSum Samples DAvg PktLoss Unreach Ebytes Ibytes Pkts Flows
Act: Dsum Attempts DAvg Comps Unreach Jitter LoMOSCnt MOSCnt
00:00:57 2.2.2.2 Gi3
Pas: 0 0 0 0 0 1909362 1906002 5074 480
Act: 0 0 0 0 0 N N N
00:01:57 2.2.2.2 Gi3
Pas: 0 0 0 0 0 1912666 1910036 5087 488
Act: 0 0 0 0 0 N N N
00:02:58 2.2.2.2 Gi3
Pas: 0 0 0 0 0 1923670 1921040 5115 488
Act: 0 0 0 0 0 N N N
00:03:59 2.2.2.2 Gi3
Pas: 0 0 0 0 0 1907004 1906788 5072 480
Act: 0 0 0 0 0 N N N
00:04:59 2.2.2.2 Gi3
Pas: 0 0 0 0 0 1911880 1905320 5080 488
Act: 0 0 0 0 0 N N N
00:05:59 2.2.2.2 Gi3
Pas: 0 0 0 0 0 1429860 1427340 3800 360
Act: 35 2 17 2 0 N N N
00:07:00 2.2.2.2 Gi3
Pas: 0 0 0 0 0 1906218 1901286 5064 480
Act: 12 2 6 2 0 N N N
--------------------------------------------------------------------------------The ActSDly and ActLDly are short-term and long-term active delay. This is measured with active probes.
I’d have to test when PfR uses PBR exactly. I found this document from Cisco:
Where they describe:
When a PfR master controller (MC) decides to control a prefix using a protocol BGP, for example, it sends the control request to a selected PfR border router (BR). If the MC receives the successful control notification from the BR, it will notify all the other BRs to exclude the prefix. Some BRs may not have a parent route to this prefix via the same protocol. When no parent route exists for the prefix, this is detected as a RIB mismatch, the prefix is moved into a default state, and the control procedure begins again.
To simplify PfR, CSCtr26978 introduced new behavior when no parent route is detected. In this situation, PfR automatically switches to using dynamic policy-based routing (PBR) instead of trying all the other routing protocols in the following order; BGP, EIGRP, static, and PBR. With CSCtr26978, the existing mode route protocol pbr command behavior was enabled by default. Configuration of the no mode route protocol pbr command initially sets the traffic classes to be uncontrolled and PfR then uses a single protocol to control the traffic class in the following order: BGP, EIGRP, static, and PBR.
So, it seems to prefer regular routing before using PBR but with the mode route protocol pbr you can force it to use PBR right away.
In an oer-map (or pfr-map) you can match with prefix-lists, access-lists, PfR learned prefixes, and NBAR.
Rene