Cisco Performance Routing – Measure and Learning methods

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.

Performance Routing Setup graph

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 :)

Daniel Rodriguez

Daniel is the co-founder of Network Faculty. He holds the following certifications: CCNA, CCNP, CCIP, LPIC Level 2 and Security+. He loves Perl Programming, Linux, IPv6 and Multicast deployments. When not doing network related study/work, he is training for triathlons and other endurance sports.

More Posts - Website - Twitter - Facebook

Creative Commons License
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.

Tags: , ,

19 Responses to "Cisco Performance Routing – Measure and Learning methods"

  • LiMeng says:
  • Andrei says:
  • Fazil says:
  • Roberto says:
  • Terry says:
  • mohamed says:
  • Kaage says:
  • Alex says:
  • Alex says:
  • Alex says:
  • Lewy says:
  • Lewy says:
Leave a Comment

*

Notify me of followup comments via e-mail. You can also subscribe without commenting.