May
3
On my first article about Cisco Performance Routing, I described how it works, things to keep in mind when deploying PFR/OER and a basic configuration with static definition of traffic classes. In this article we are going to work on Learning methods to dynamically detect and classify the traffic, the modes Cisco Performance Routing can use to measure and react if needed and lastly a feature called link-groups. I highly recommend to give a good read to my first Cisco Performance Routing article as all the foundation are in there.
Learning Method
With Cisco Performance Routing you can define the traffic that is going to be managed by the feature in a static way or dynamically (using Netflow). Both of them can be configured at the same time, for example you can statically define a class like voice traffic, in which you know exactly the networks, protocols, etc that needs to be handled and leave the rest of the traffic to be discovered automatically and treated in a different way.
Static or Manual configuration
This is the mode that we used on the first part of the article, so to not repeat myself too much, I’m just going to briefly review it in this post.
This mode allows you to define the traffic classes that are going to be in the Cisco Performance Routing database and there is not automatic discovery or “magic” happening, as soon as the configuration is placed, the traffic class pops into the database. You can use prefix-list, access-list or even NBAR to create the traffic class.
For example a class for HTTP traffic for the network 10.0.12.0/24
ip prefix-list HTTP-SERVERS seq 10 permit 10.0.12.0/24 pfr-map CRITICAL-TRAFFIC 50 match traffic-class application http prefix-list HTTP-SERVERS set periodic 90 set mode select-exit good set backoff 90 90 set delay threshold 80 set mode route control set mode monitor both
For this class definition I used NBAR to match the http (web) traffic and a prefix list to define the network involved. For the rest of the parameters please, look at the previous post on Cisco Performance Routing.
Automatic Configuration
When using this kind of mode PFR/OER will learn all traffic going through the router with netflow, saving you from the hassle of defining the traffic classes manually. For example, imagine that you want to optimize HTTP traffic because it’s very important for your organization but you don’t know exactly which host is generating (or receiving) the flows. With automatic learning you have the option of leaving everything to be handled automatically by Cisco Performance Routing / Optimized Edge Routing or define a parameters to group them and manage them interdependently.
When we want to take advantage of this automatic configuration but specifying some parameters for the traffic definitions its done inside a “learn-list”.
A learn-list works similar to a policy-map in that in each entry or sequence you can define prefix, application, filter, etc. This kind of configuration provides a lot o power and flexibility.
Configuration Example:
ip prefix-list CENTRAL-OFFICE seq 10 permit 10.0.66.0/24 oer master learn throughput delay list seq 10 refname HTTP-TRAFFIC traffic-class application http throughput list seq 20 refname CENTRAL-OFFICE traffic-class prefix-list CENTRAL-OFFICE throughput
In the previous configuration you can see how we have defined the automatic learning on a specific learn lists for all HTTP traffic and then all the traffic destinated to our central office using a prefix list. Every time the device “detects” a flow in any of this list it will go to the PFR database. The learn list can later be called by a pfr-map to handle that specific kind of traffic in a different way if needed, for example, by moving the CENTRAL-OFFICE traffic to the lowest delay link and HTTP to the one with the highest throughput.
I like to think of a “learn-list” as an special kind of class-map, where traffic is learned automatically depending on some parameters and that it can be called later in the pfr-map to define a behavior for that specific traffic.
Measurement modes
In my previous Cisco Performance Routing / Optimized Edge Routing configuration example I used the default monitoring mode, which is “monitor both”, but we did not detail much about what it actually means. So let’s give it a look:
During the measurement phase the border router collects information from the traffic that is flowing through it and sends it over the Master Controller. This information can be obtained in two ways, using netflow information or by active probing the links/destinations from the BR (Border Routers), you can use these two ways of gathering information in four different modes that we are going to describe here:
Monitor Mode Passive
This is probably the simplest mode you can use, the router will silently gather information from the traffic flowing through it by using Netflow (automatically configured for you) and it’s the recommended mode when working with Border routers directly connected to the internet, as you don’t want to send probing traffic (used in other modes) for all the destination prefixes that your network is using.
How the measurements are done?:
- Reachability: If connection attempts are done, but they are not getting the proper full TCP handshake then there is some kind of reachability problems in the path.
- Throughput: Calculated based on the Netflow database.
- Delay: The time between the SYN and SYN/ACK packets on TCP Handshake
- Loss: By tracking the sequence numbers it can provide an estimate if packets are getting lost
Traffic that is not TCP, for example UDP, will only have throughput measurements done for it, there is no way to determine without active probes if the flow is having delay, loss, etc of a UDP transmission.
Monitor Mode Active
In this mode netflow is used to “detect” the flows and configure active probing automatically using IP SLA, in other words, as soon as a flow is detected test traffic will be generated for the destination networks, this measures provides a better understanding of the actual performance of the destination and not estimates like the ones done on passive measurements. You need to keep in mind two things:
- The automatic probes are generated using ICMP, so if this kind of traffic is blocked by a middle host, your test would fail.
- It generates extra traffic, so in high traffic situations it could affect the performance of your network, also, keep in mind that the destination may not like to be probed often and simply block that traffic.
- Probes are only generated using the active link and the backup link are only tested when some traffic goes out of policy.
- You can generate your own probes by providing explicitly the IP SLA configuration (we did this in Part 1)
Its a good method to be used for your inside network and probably not for public internet traffic.
Monitor Mode both
This is the mix of the two previous modes, you get all the information that net flows manage to get passively and the more complete test done by automatic probing, combining both of them you can probably get the most precise view of the network.
The probes are generate by the BR only on the active link, the backup paths are only tested when a prefix goes out of policy and needs to be moved, this probes are sent to a maximum of five active destination ip address by prefix learned using ICMP (the limitations that I mentioned before of active mode apply here).
As this mode uses active probing it may not be well suited for BR with direct internet traffic (Read Mode Active), but it offers a better view of the network, so IMHO is better than using plain active mode.
Monitor Mode Fast
This is the most intense mode currently available, all available paths are tested automatically by IP SLA, which differs greatly from mode active in that “active” only tests the active path unless there is out of policy situation that triggers the probing of backup paths. With this mode PFR/OER is able to achieve the fastest convergence possible, the router does not have to wait for the testing of alternatives to be able to move the traffic. It knows the characteristics of every possible path.
The problem with this mode as you can imagine is that is very CPU and Network intensive, the BR will send probes to all destination all the time, its better to keep it only for specific controlled destinations.
This mode is able to achieve a fast reroute of traffic with for example a 3 second reaction time if configured with the lowest timers.
Most of the decisions are based on the active probes generated (including the Out Of Policy state), but passive information from netflow is still used, for things like throughput measurements for load balancing
Links Groups
This is the last “feature” of Cisco Performance routing that I wanted to touch in this post, and it’s the ability you have to control the links used by each traffic class. With this configuration you can specify what links you prefer “primarily” for each traffic class, and in case of an Out of policy situation, the fallback link to be used.
Lets say that you have a link you know is low delay but it does not have too much bandwidth making it perfect for the voice traffic of your branch. With this feature you can tell the engine that you want this voice traffic to use that link and only use another one in case that it goes out of policy for some reason.
The configuration is very straight forward, as you only have to put “names” to the external links on you Master Controler and then associate the traffic to the link on your PFR/OER map:
pfr master border 10.4.5.5 key-chain pfr interface Ethernet0/1 external link-group HIGH_BW interface Ethernet0/0 internal ! border 10.4.5.4 key-chain pfr interface Ethernet0/1 external link-group LOW_DELAY interface Ethernet0/0 internal pfr-map VOICE 10 set link-group LOW_DELAY fallback HIGH_BW
Configuration
In this setup we are going to work with the same topology as before, but interacting with the features we have presented here. The requirements are the following:
- HTTP traffic should use R5 external link unless there is excessive delay or connectivity problems with that link.
- Traffic marked with EF should use the low delay link of R4, and only when experiencing high delay or loss should be moved to another link.
- EF traffic should move to the alternate link as soon as possible.
The configuration of Performance Routing is this one:
On the BR’s
key chain CHAIN key 1 key-string CISCO pfr border logging local Loopback0 master 10.3.3.3 key-chain CHAIN
On the Master Controller
pfr master policy-rules BRANCH_TRAFFIC no max-range-utilization logging ! border 10.4.5.5 key-chain pfr interface Ethernet0/1 external link-group R5_HIGH_BW interface Ethernet0/0 internal ! border 10.4.5.4 key-chain pfr interface Ethernet0/1 external link-group R4_LOW_DELAY interface Ethernet0/0 internal ! learn throughput delay periodic-interval 0 monitor-period 1 traffic-class filter access-list DONT_LEARN list seq 10 refname HTTP traffic-class application http throughput list seq 20 refname BRANCH_VOICE traffic-class access-list VOICE_CRITICAL throughput holddown 90 mode route control periodic 90 no resolve range no resolve utilization ! pfr-map BRANCH_TRAFFIC 10 match pfr learn list HTTP set periodic 90 set mode select-exit good set backoff 90 90 set delay threshold 500 set mode route control set mode monitor passive set resolve loss priority 1 variance 20 set resolve delay priority 2 variance 80 no set resolve range no set resolve utilization set link-group R5_HIGH_BW fallback R4_LOW_DELAY pfr-map BRANCH_TRAFFIC 20 match pfr learn list BRANCH_VOICE set periodic 90 set mode select-exit good set backoff 90 90 set delay threshold 150 set mode route control set mode monitor fast set resolve delay priority 1 variance 20 set resolve loss priority 2 variance 20 set resolve jitter priority 3 variance 20 set link-group R4_LOW_DELAY fallback R5_HIGH_BW
Lets focus on the “new” configuration (the ones not mentioned on my previous post):
With the link-group command you “name” the links, to latter reference them on the pfr map:
interface Ethernet0/1 external link-group R5_HIGH_BW
With the following configuration, I specify that I don’t want to learn anything automatically on the global configuration. I don’t have to worry about “analyzing” extra traffic classes going through the border routers that I’m not actually handling:
traffic-class filter access-list DONT_LEARN ip access-list extended DONT_LEARN deny ip any any
In the following configuration we created two learn lists, to auto discover http traffic and “voice” traffic (in reality traffic marked with EF). Basically you specify what kind of traffic is going to fall in each list so you can later reference them, on the performance pfr map.
list seq 10 refname HTTP traffic-class application http throughput list seq 20 refname BRANCH_VOICE traffic-class access-list VOICE_CRITICAL throughput
In the pfr-map we are calling each learn list independently, configuring the monitor mode and the link groups. For HTTP we are choosing to only use passive mode, so only netflow is going to be used to measure those traffic-classes, also we are specifying that initially all traffic should go though R5 external links, as it is “cheaper” and with more bandwidth available. For the “voice” traffic (traffic marked with EF), we will be using fast monitor mode, that way PFR would test all available links at all time and would be able to move the traffic to another link faster than any other mode. Also, on normal conditions this traffic is supposed to use R4 low delay link, and only if its goes out of policy would be moved to R5 link.
pfr-map BRANCH_TRAFFIC 10 match pfr learn list HTTP set mode monitor passive set link-group R5_HIGH_BW fallback R4_LOW_DELAY pfr-map BRANCH_TRAFFIC 20 match pfr learn list BRANCH_VOICE set mode monitor fast set link-group R4_LOW_DELAY fallback R5_HIGH_BW
Everything else in the configuration was discussed on my previous post: Cisco Performance Routing
Verification:
First, you can check how your learn list are performing:
#show pfr master learn list
Learn-List seq 10 refname HTTP
Configuration:
Traffic-Class Application: http
Aggregation-type: prefix-length 24
Learn type: throughput
Session count: 50 Max count: 100
Policies assigned: 10
Status: ACTIVE
Stats:
Traffic-Class Count: 4
Traffic-Class Learned:
Appl Prefix 30.1.2.0/24 http
Appl Prefix 30.1.3.0/24 http
Appl Prefix 30.1.5.0/24 http
Appl Prefix 30.1.4.0/24 http
Learn-List seq 20 refname BRANCH_VOICE
Configuration:
Traffic-Class Access-list: VOICE_CRITICAL
Aggregation-type: prefix-length 24
Learn type: throughput
Session count: 50 Max count: 100
Policies assigned: 20
Status: ACTIVE
Stats:
Traffic-Class Count: 1
Traffic-Class Learned:
Appl Prefix 30.1.1.0/24 ef 256
And see how each traffic class is behaving:
#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 ef 256 N N 0.0.0.0/0
INPOLICY @1 10.4.5.4 Et0/1 PBR
U U 0 0 0 0 9 10
55 54 0 0 N N N N
30.1.2.0/24 http N N N N 0.0.0.0/0
INPOLICY 41 10.4.5.5 Et0/1 PBR
107 107 0 0 0 0 10 1
N N N N N N
30.1.3.0/24 http N N N N 0.0.0.0/0
INPOLICY 72 10.4.5.5 Et0/1 PBR
110 110 0 0 0 0 11 1
N N N N N N
30.1.4.0/24 http N N N N 0.0.0.0/0
INPOLICY 59 10.4.5.5 Et0/1 PBR
97 97 0 0 0 0 41 5
N N N N N N
30.1.5.0/24 http N N N N 0.0.0.0/0
INPOLICY 55 10.4.5.5 Et0/1 PBR
97 97 0 0 0 0 38 4
N N N N N N
Something interesting to see in this output, the PBR (Policy Base Routing) is handling our traffic classes. Think about it, we are looking at specific fields on the IP packets and Layer 4 information, and to control that on a packet the only way would be with the capabilities that PBR provides, no change on BGP or static route would be able achieve this.
Now, how are the routers handling that configuration?, well, you can actually see the configuration that the Master Controller have pushed to their Border Routers:
R4#show route-map dynamic route-map OER_INTERNAL_RMAP, permit, sequence 0, identifier 1979711497 Match clauses: ip address (access-lists): oer#1 Set clauses: ip next-hop 100.4.8.8 interface Ethernet0/1 Policy routing matches: 8315 packets, 3761567 bytes route-map OER_INTERNAL_RMAP, permit, sequence 1, identifier 3439329290 Match clauses: ip address (access-lists): oer#2 Set clauses: ip next-hop 10.4.5.5 interface Ethernet0/0 Policy routing matches: 0 packets, 0 bytes Current active dynamic routemaps = 1 R4#show ip access-list dynamic Extended IP access list oer#1 16383 permit ip any 30.1.1.0 0.0.0.255 dscp ef (3732 matches) Extended IP access list oer#2 32767 permit tcp any range www www 30.1.5.0 0.0.0.255 65535 permit tcp any 30.1.5.0 0.0.0.255 range www www 131071 permit udp any range 80 80 30.1.5.0 0.0.0.255 262143 permit udp any 30.1.5.0 0.0.0.255 range 80 80 524287 permit tcp any range www www 30.1.4.0 0.0.0.255 1048575 permit tcp any 30.1.4.0 0.0.0.255 range www www 2097151 permit udp any range 80 80 30.1.4.0 0.0.0.255 4194303 permit udp any 30.1.4.0 0.0.0.255 range 80 80 8388607 permit tcp any range www www 30.1.2.0 0.0.0.255 16777215 permit tcp any 30.1.2.0 0.0.0.255 range www www 33554431 permit udp any range 80 80 30.1.2.0 0.0.0.255 67108863 permit udp any 30.1.2.0 0.0.0.255 range 80 80 134217727 permit tcp any range www www 30.1.3.0 0.0.0.255 268435455 permit tcp any 30.1.3.0 0.0.0.255 range www www 536870911 permit udp any range 80 80 30.1.3.0 0.0.0.255 1073741823 permit udp any 30.1.3.0 0.0.0.255 range 80 80 R5#show route-map dynamic route-map OER_INTERNAL_RMAP, permit, sequence 0, identifier 3774873609 Match clauses: ip address (access-lists): oer#1 Set clauses: ip next-hop 10.4.5.4 interface Ethernet0/0 Policy routing matches: 8953 packets, 3852163 bytes route-map OER_INTERNAL_RMAP, permit, sequence 1, identifier 989855754 Match clauses: ip address (access-lists): oer#2 Set clauses: ip next-hop 100.5.9.9 interface Ethernet0/1 Policy routing matches: 3955 packets, 2662099 bytes Current active dynamic routemaps = 1 R5#show ip access-list dynamic Extended IP access list oer#1 16383 permit ip any 30.1.1.0 0.0.0.255 dscp ef (4422 matches) Extended IP access list oer#2 32767 permit tcp any range www www 30.1.5.0 0.0.0.255 (1540 matches) 65535 permit tcp any 30.1.5.0 0.0.0.255 range www www 131071 permit udp any range 80 80 30.1.5.0 0.0.0.255 262143 permit udp any 30.1.5.0 0.0.0.255 range 80 80 524287 permit tcp any range www www 30.1.4.0 0.0.0.255 (1685 matches) 1048575 permit tcp any 30.1.4.0 0.0.0.255 range www www 2097151 permit udp any range 80 80 30.1.4.0 0.0.0.255 4194303 permit udp any 30.1.4.0 0.0.0.255 range 80 80 8388607 permit tcp any range www www 30.1.2.0 0.0.0.255 (450 matches) 16777215 permit tcp any 30.1.2.0 0.0.0.255 range www www 33554431 permit udp any range 80 80 30.1.2.0 0.0.0.255 67108863 permit udp any 30.1.2.0 0.0.0.255 range 80 80 134217727 permit tcp any range www www 30.1.3.0 0.0.0.255 (581 matches) 268435455 permit tcp any 30.1.3.0 0.0.0.255 range www www 536870911 permit udp any range 80 80 30.1.3.0 0.0.0.255 1073741823 permit udp any 30.1.3.0 0.0.0.255 range 80 80
Now, lets see some details about two specific traffic classes, one marked with EF (mode fast) and the other one in the HTTP list (mode passive). Pay special attention to the highlighted parts:
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 (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
--------------------------------------------------------------------------------
Prefix: 30.1.1.0/24 Protocol: 256 Port: [1, 65535] [1, 65535] DSCP: ef
State: INPOLICY Time Remaining: @1
Policy: BRANCH_TRAFFIC 20
Most recent data per exit
Border Interface PasSDly PasLDly ActSDly ActLDly
*10.4.5.4 Et0/1 0 0 55 54
10.4.5.5 Et0/1 0 0 110 110
Latest Active Stats on Current Exit:
Type Target TPort Attem Comps DSum Min Max Dly
echo 30.1.1.11 N 1 1 64 44 64 64
echo 30.1.1.11 N 1 1 52 44 64 52
Prefix performance history records
Current index 11, 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:37 10.4.5.4 Et0/1
Pas: 0 0 0 0 0 78080 38272 909 4
Act: 0 0 0 0 0 N N N
00:01:39 10.4.5.4 Et0/1
Pas: 0 0 0 0 0 78080 78208 1221 6
Act: 64 1 64 1 0 N N N
00:02:39 10.4.5.4 Et0/1
Pas: 0 0 0 0 0 78080 77952 1219 6
Act: 52 1 52 1 0 N N N
00:03:41 10.4.5.4 Et0/1
Pas: 0 0 0 0 0 78080 78208 1221 6
Act: 104 2 52 2 0 N N N
00:04:42 10.4.5.4 Et0/1
Pas: 0 0 0 0 0 78208 77952 1220 6
Act: 56 1 56 1 0 N N N
00:05:47 10.4.5.4 Et0/1
Pas: 0 0 0 0 0 77952 78208 1220 7
Act: 56 1 56 1 0 N N N
00:06:45 10.4.5.4 Et0/1
Pas: 0 0 0 0 0 77952 77952 1218 6
Act: 52 1 52 1 0 N N N
00:07:44 10.4.5.4 Et0/1
Pas: 0 0 0 0 0 39552 78080 919 5
Act: 104 2 52 2 0 N N N
00:09:06 10.4.5.5 Et0/1
Pas: 0 0 0 0 0 78080 78208 1221 6
Act: 108 1 108 1 0 N N N
00:10:07 10.4.5.5 Et0/1
Pas: 0 0 0 0 0 78208 78080 1221 6
Act: 112 1 112 1 0 N N N
00:11:30 10.4.5.5 Et0/1
Pas: 0 0 0 0 0 117632 67840 1449 7
Act: 112 1 112 1 0 N N N
--------------------------------------------------------------------------------
Prefix: 30.1.2.0/24 Appl Id: http
State: INPOLICY Time Remaining: 18
Policy: BRANCH_TRAFFIC 10
Most recent data per exit
Border Interface PasSDly PasLDly ActSDly ActLDly
*10.4.5.5 Et0/1 107 107 0 0
10.4.5.4 Et0/1 61 61 0 0
Latest Active Stats on Current Exit:
Type Target TPort Attem Comps DSum Min Max Dly
Prefix performance history records
Current index 9, 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:45 10.4.5.5 Et0/1
Pas: 896 8 112 0 0 37258 5346 136 26
Act: 0 0 0 0 0 N N N
00:01:45 10.4.5.5 Et0/1
Pas: 2312 21 110 0 0 95549 12078 325 57
Act: 0 0 0 0 0 N N N
00:03:03 10.4.5.5 Et0/1
Pas: 1660 15 110 0 0 51540 9648 207 28
Act: 0 0 0 0 0 N N N
00:04:03 10.4.5.5 Et0/1
Pas: 1480 15 98 0 0 109911 9339 297 50
Act: 0 0 0 0 0 N N N
00:05:09 10.4.5.4 Et0/1
Pas: 932 17 54 0 0 0 10964 161 17
Act: 0 0 0 0 0 N N N
00:06:34 10.4.5.4 Et0/1
Pas: 1220 22 55 0 0 83064 13421 322 51
Act: 0 0 0 0 0 N N N
00:07:50 10.4.5.4 Et0/1
Pas: 1616 22 73 0 0 161451 14459 442 67
Act: 0 0 0 0 0 N N N
00:09:22 10.4.5.5 Et0/1
Pas: 0 0 0 0 0 69388 0 109 22
Act: 0 0 0 0 0 N N N
00:10:27 10.4.5.5 Et0/1
Pas: 0 0 0 0 0 114158 0 185 42
Act: 0 0 0 0 0 N N N
--------------------------------------------------------------------------------
As you can see on the “Most recent data per exit” points us the current exit, but also provides delay information depending if the data comes from an active or passive measurement. In the case of the HTTP traffic, the “61″ value on the delay is based on legacy information, PFR managed to measure that link just before it was moved out to our configured link-group. You can “check” the last performance measurements on the “Prefix Performance History”.
Now, lets focus on the “voice” traffic:
#show pfr master traffic-class performance ip any 30.1.1.0/24 ============================================================================================== Traffic-class: Destination Prefix : 30.1.1.0/24 Source Prefix : 0.0.0.0/0 Destination Port : N Source Port : N DSCP : ef Protocol : 256 Application Name: : N/A General: Control State : Controlled using PBR Traffic-class status : INPOLICY Current Exit : BR 10.4.5.4 interface Et0/1, Tie breaker was None Time on current exit : 0d 0:9:35 Time remaining in current state : @1 seconds Traffic-class type : Learned 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 : 57 msecs -- Threshold: 150 msecs Loss : 0% -- Threshold: 10% Egress BW : 10 kbps Ingress BW : 10 kbps Time since last update : 0d 0:0:22 Average Active Performance Current Exit: (Average for last 5 minutes) Unreachable : 0% -- Threshold: 50% Delay : 59 msec -- Threshold: 150 msec Loss : 0% -- Threshold: 10% Jitter : 0 msec -- Threshold: 2000 msec Last Resolver Decision: BR Interface Status Reason Performance Threshold --------------- ------------ ------------ ------------ ----------- --------- 10.4.5.5 Et0/1 Eliminated Link Group N/A N/A 10.4.5.4 Et0/1 Best Exit Unreachable N/A N/A ==============================================================================================
As you can see, EF marked traffic is currently in policy and have been moved from using R5 to R4 because of the link group configuration.
Now if we increase the delay on R4 link (to 300 ms), it would go to the other link faster than using “passive or both” measurements modes.
*Apr 29 16:19:24.947: %OER_MC-5-NOTICE: Active ABS Delay OOP Appl Prefix 30.1.1.0/24 ef 256,
delay 157, BR 10.4.5.4, i/f Et0/1
*Apr 29 16:19:24.959: %OER_MC-5-NOTICE: Route changed Appl Prefix 30.1.1.0/24 ef 256,
BR 10.4.5.5, i/f Et0/1, Reason Delay, OOP Reason Delay
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 : 0.0.0.0/0 Destination Port : N Source Port : N DSCP : ef Protocol : 256 Application Name: : N/A General: Control State : Controlled using PBR Traffic-class status : HOLDDOWN Current Exit : BR 10.4.5.5 interface Et0/1, Tie breaker was Delay Time on current exit : 0d 0:0:8 Time remaining in current state : @83 seconds Traffic-class type : Learned Improper config : None Last Out of Policy event: Exit : BR 10.4.5.5 interface Et0/1 Reason : Delay Time since Out of Policy event : 0d 0:0:8 Active Delay Performance : 0 msecs Active Delay Threshold : 150 msecs Average Passive Performance Current Exit: (Average for last 5 minutes) Unreachable : 0% -- Threshold: 50% Delay : 0 msecs -- Threshold: 150 msecs Loss : 0% -- Threshold: 10% Egress BW : 10 kbps Ingress BW : 10 kbps Time since last update : 0d 0:14:45 Average Active Performance Current Exit: (Average for last 5 minutes) Unreachable : 0% -- Threshold: 50% Delay : 0 msec -- Threshold: 150 msec Loss : 0% -- Threshold: 10% Jitter : 0 msec -- Threshold: 2000 msec Last Resolver Decision: BR Interface Status Reason Performance Threshold --------------- ------------ ------------ ------------ ----------- --------- 10.4.5.4 Et0/1 Eliminated Delay 222 msecs 150 msecs 10.4.5.5 Et0/1 Best Exit Delay 108 msecs 150 msecs ==============================================================================================
As you can see traffic is moved now to R5. With this mode it reacts decently fast, but if you want faster convergence then you can change the probing frequency, that way problems can be detected faster.
MC(config)#pfr-map BRANCH_TRAFFIC 20 MC(config-pfr-map)#set probe frequency 2
Thank you for reading our CCIE Blog, and please, don’t forget to hit the +1 button 
The Cisco Performance Routing – Measure and Learning methods by CCIE Blog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
