PfR:Solutions:EnterpriseWAN

From DocWiki

Revision as of 18:33, 1 October 2012 by Jbarozet (Talk | contribs)
Jump to: navigation, search

Pfr-banner-solutions.png



PfR Enterprise WAN Application Control


Navigation


Contents




Version Used

IOS 15.2(3)T and IOS-XE 3.6 releases are key milestones for PfR. Defaults have changed to better align with the customer deployments and the PfR Best practices. Among the most important changes are:

  • Mode route control is on by default
  • Resolvers range and utilization have been removed. Load-balancing is used as the last resolver and cannot be disabled.
  • Automatic learning is enabled by default
  • Learning monitor-period is 1, and periodic-interval is 0 by default

See PfR News for more information.


Enterprise Needs

Presentation

This solution is for an Enterprise which is dual-attached to two Service Providers. Multiple scenarios are covered like:

  • Dual MPLS-VPN service
  • or a primary MPLS-VPN and a secondary DMVPN over the Public Internet.
  • or dual DMVPN over the Public Internet
  • and more

In this guide we will cover several concepts including:

  • Active probing
  • Target Discovery to simplify the active mode configuration
  • Advanced learning: defining groups of traffic classes, e.g. VOICE_VIDEO, CRITICAL and Best Effort (BE) using a PfR feature called 'learn-list'
  • Measurement modes: passive for BE and active for VOICE_VIDEO and CRITICAL
  • Defining specific policies for each group.
  • Link-groups


Traffic Classification and Overall Policies

The enterprise traffic is divided into 3 main application groups that have their own policies:


Voice and Video traffic

  • Voice and video traffic is running between the central site and the branches. This traffic is already marked with DSCP EF and the transport is RTP.
  • We would like to track delay, jitter and loss.
  • We want to have deterministic path selection and therefore use the primary SP called SP1.
  • If the primary WAN experiences brownouts or blackout, we want PfR to failover this traffic to the secondary path.


Critical Application

  • There is a highly important application running between branches and the central site network and running over TCP.
  • This traffic is marked with DSCP AF31.
  • This application is interactive, so it is sensitive to delay. In addition, it does not respond well to packet loss. The servers being used for this important application are also responsible for other applications that are not only less important, but that have different requirements of the network.
  • We want to have deterministic path selection and therefore use the primary SP SP1.
  • If the primary WAN experiences brownouts or blackout, we want PfR to failover this traffic to the secondary path.


Best Effort Applications

  • The rest of the traffic is just HTTP or email and should be load balanced over all exit interfaces, SP1 and SP2.


In most (all) cases, Qos is already in place and classification/marking procedures were studied a while back. Therefore packets entering on the Border Router are already classified and marked directly on the access switch connecting the station, IP Phone or multimedia terminal. That means PfR can probably use the dscp field as an efficient way for the traffic profiling phase. This guide will use the DSCP values as the classification criteria. But you could also use a combination of destination prefixes and DSCP or even NBAR (see [[PfR:Solutions:NBAR | PfR NBAR Based Application Control] for more information).



PfR Network Topology Used

Central site:

  • A dedicated Master Controller (MC) R3 and two Border Routers (BRs) R4 and R5
  • Server R1: 10.10.0.0/16

Remote Sites:

  • Branch R9 with a combo of Master Controller and Border Router on R9 and clients on R12 (20.20.0.0/16)
  • Branch R10 with a combo of Master Controller and Border Router on R10 and clients on R11 (30.30.0.0/16)

Two SP Clouds (SP1 and SP2) with a delay generator (R7)

Traffic generation between R1 and R11/R12:

  • Voice traffic on RTP – DSCP EF
  • Business applications running on port TCP 7000 – DSCP AF31
  • Best effort application – DSCP 0



Pfr-topology3.jpg


R2 is an iBGP peer for both border routers and as such has the BGP route table. PfR being not active, the parent routes are BGP based on R2, R4 and R5 and R5 is the preferred exit point (higher local preference applied on ingress on R5) as seen below:

Route to destination prefixes BRANCH1 (20.20.0.0/16):


R2#sh ip bgp 20.20.0.0/16
BGP routing table entry for 20.20.0.0/16, version 7
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200 20
    100.5.82.1 (metric 11) from 10.5.5.5 (10.5.5.5)
      Origin IGP, metric 0, localpref 200, valid, internal, best
R2#

Route to destination prefixes BRANCH2 (30.30.0.0/16):


R2#sh ip bgp 30.30.0.0/16
BGP routing table entry for 30.30.0.0/16, version 12
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200 30
    100.5.82.1 (metric 11) from 10.5.5.5 (10.5.5.5)
      Origin IGP, metric 0, localpref 200, valid, internal, best
R2#



Checking flows

In this section we are using Flexible NetFlow on R2 to look at the traffic and check what is the current path used.

Create the flow record:

!*******************************
! FLOW RECORD
! What data do I want to meter?
! First define the flow record that you want.
! ‘match’ is used to identify key fields, ie, those fields used to define what a flow is
! ‘collect’ is used to define what fields we want to monitor
!
!         
flow record RECORD-FNF-EGRESS
 match ipv4 protocol
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 match interface output
 collect ipv4 dscp
 collect interface input
 collect counter bytes
 collect counter packets
!
flow record RECORD-FNF-INGRESS
 match ipv4 protocol
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 match interface input
 collect ipv4 dscp
 collect interface output
 collect counter bytes
 collect counter packets
!     

Create the flow monitor

!*******************************
! FLOW MONITOR
! Creates a new NetFlow cache
! Attach the flow record
! Exporter is attached to the cache
! Potential sampling configuration
!
flow monitor MONITOR-FNF-EGRESS
 record RECORD-FNF-EGRESS
!
flow monitor MONITOR-FNF-INGRESS
 record RECORD-FNF-INGRESS
!

Then apply the flow monitor on the interface to the BRs:


You can now check the NetFlow cache on R2. We can check that we have critical applications with DSCP 0x1A (AF31) and voice flows with DSCP 0x2E (EF):

<pre>

R2#sh flow monitor MONITOR-FNF-EGRESS cache format table
  Cache type:                               Normal
  Cache size:                                 4096
  Current entries:                              92
  High Watermark:                               95

  Flows added:                               17354
  Flows aged:                                17262
    - Active timeout      (  1800 secs)         14
    - Inactive timeout    (    15 secs)      17248
    - Event aged                                 0
    - Watermark aged                             0
    - Emergency aged                             0

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  INTF OUTPUT           IP PROT  intf input                 bytes        pkts  ip dscp
===============  ===============  =============  =============  ====================  =======  ====================  ==========  ==========  =======
10.3.3.3         10.5.5.5                  3949          50629  Et0/2                       6  Et0/0                      88243        1277  0x00   
10.3.3.3         10.4.4.4                  3949          12269  Et0/2                       6  Et0/0                      88203        1276  0x00   
10.10.1.1        20.20.0.12               10000          20000  Et0/2                      17  Et0/1                      26752         608  0x2E   
10.10.1.1        30.30.0.11               20000          10000  Et0/2                      17  Et0/1                      26752         608  0x2E   
10.10.2.1        30.30.5.11                  25           1013  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.3.1        30.30.7.11                7000           7010  Et0/2                       6  Et0/1                      10738          12  0x1A   
10.10.1.1        30.30.16.11                 80           2010  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.2.1        30.30.6.11                  25           1014  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.3.1        30.30.8.11                7000           7000  Et0/2                       6  Et0/1                      10738          12  0x1A   
10.10.1.1        30.30.17.11                 80           2011  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.2.1        30.30.7.11                  25           1015  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.3.1        30.30.9.11                7000           7001  Et0/2                       6  Et0/1                      10738          12  0x1A   
10.10.1.1        30.30.18.11                 80           2012  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.3.1        30.30.10.11               7000           7002  Et0/2                       6  Et0/1                      10738          12  0x1A   
10.10.1.1        30.30.19.11                 80           2013  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.2.1        30.30.8.11                  25           1016  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.1.1        20.20.0.12                  80           2019  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.2.1        20.20.1.12                  25           1001  Et0/2                       6  Et0/1                      10738          12  0x00   
10.10.3.1        20.20.2.12                7000           7008  Et0/2                       6  Et0/1                      10738          12  0x1A   

[SNIP]

Check that active RTP flows exist with dscp EF (0x2E):

R2#show flow monitor MONITOR-FNF-EGRESS cache filter ipv4 protocol 17 format t$
  Cache type:                               Normal
  Cache size:                                 4096
  Current entries:                             111
  High Watermark:                              121

  Flows added:                               19408
  Flows aged:                                19297
    - Active timeout      (  1800 secs)         16
    - Inactive timeout    (    15 secs)      19281
    - Event aged                                 0
    - Watermark aged                             0
    - Emergency aged                             0

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  INTF OUTPUT           IP PROT  intf input                 bytes        pkts  ip dscp
===============  ===============  =============  =============  ====================  =======  ====================  ==========  ==========  =======
10.10.1.1        20.20.0.12               10000          20000  Et0/2                      17  Et0/1                      41756         949  0x2E   
10.10.1.1        30.30.0.11               20000          10000  Et0/2                      17  Et0/1                      41712         948  0x2E   
Matched 2 flows

R2#

Check routing tables for destination prefixes 20.20.0.0/16 (branch1) and 30.30.0.0/16 (branch2):


R2#show ip route | inc 30.30
B        30.30.0.0/16 [200/0] via 100.5.82.1, 01:47:09
R2#

R2#show ip route | inc 20.20
B        20.20.0.0/16 [200/0] via 100.5.82.1, 01:47:15
R2#

From that, we can check that Border Router R5 is used from the central site to the branches.


PfR Configuration

Presentation

In this guide we want to protect voice/video and critical applications against soft errors, brownouts and blackouts. We want to be able to track jitter, delay and loss but we also want to have a fast failover. Therefore performance measurement will be in active mode and will use jitter probes. Jitter probe configuration for all the remote sites is a painful process and Cisco Performance Routing is now using a new feature called Target Discovery to help simplifying the configuration and deployment in such cases.

A peering session is configured between the Master Controller on the central site and the Master Controllers on the remote sites. The MCs which participate in this peering will exchange the list of inside prefixes and IP SLA probe responder addresses that belong to the sites, along with the site name (configurable).


Pfr-td1.png


Basic Configuration

Basic configuration to establish session between MC and BR on the central site:

! This is the basic configuration required to establish session between MC and BR.
! With this basic configuration, learning is enabled, route control is in place and
! load-balancing happens on all configured external interfaces.
!
! It includes
! – Key-chain configuration for authentication.
!
! – Specification of BR’s IP Address and internal/external interface on the BR.
!   If there is a tunnel between the BRs, it should be configured as internal
!
! - Specification of the Carrier name (link-group). Link-group is used to color the exit interfaces. 
!   We will define an administrative policy for voice/video and critical application to choose SP1 
!   has the primary path and SP2 as the fallback path.
!
! - Load balancing range set to 30%. This is conservative and helps to cut down on the churn resulting 
!   from movement of traffic-classes across exits.
!
! - Disabling auto-tunnels as BRs are L2 adjacent.
! - Forcing the use of PBR
! - Specification of the probe packet number. Used to decrease the CPU utilization.
!
! Notes on the new defaults:
! - Automatic learning is enabled
! - mode route control is enabled
! - Maximum transmit utilization is 90%
! - Load-balancing is now used as the last resolver and cannot be disabled.
!
!
pfr master
 max-range-utilization percent 30
 !
 border 10.4.4.4 key-chain pfr
  interface Ethernet0/0 internal
  interface Ethernet0/1 external
   link-group SP1 
!
 border 10.5.5.5 key-chain pfr
  interface Ethernet0/0 internal
  interface Ethernet0/1 external
   link-group SP2 
!
 mode route protocol pbr
 no mode auto-tunnels
 periodic 90
 probe packets 20
 !
!


Enable NetFlow version9 Export (optional)


! Flow Exporter Definition
! Where do I want my data sent?
!
flow exporter MYEXPORTER
 destination 10.151.1.131
 source Loopback0
 transport udp 9991
 option interface-table timeout 300
 option sampler-table timeout 300
 option application-table timeout 300
!
!
! Add NetFlow export to PfR
!
pfr master
 exporter MYEXPORTER
!


Enable logging


! Following configuration is to enable logging. 
! This will print PfR related syslog messages on the console.
!
pfr master
 logging
!


Basic configuration to establish session between MC and BR on the branch sites:

!
! BRANCH1 - R9
!
key chain pfr
 key 0
  key-string cisco
!
pfr master
 logging
 !
 border 20.9.9.9 key-chain pfr
  interface Ethernet0/0 internal
  interface Ethernet0/1 external
  interface Ethernet0/2 external
 !
!
pfr border
 logging  
 local Loopback0
 master 20.9.9.9 key-chain pfr
!


!
! BRANCH2 - R10
!
key chain pfr
 key 0
  key-string cisco
!
pfr master
 logging
 !
 border 30.10.10.10 key-chain pfr
  interface Ethernet0/2 external
  interface Ethernet0/1 external
  interface Ethernet0/0 internal
 !
!
pfr border
 logging
 local Loopback0
 master 30.10.10.10 key-chain pfr
!


Enabling PfR Domain and Target Discovery

Enabling Target Discovery on R3:

!
! Target Discovery is used in a hub and spoke model where R3 is the hub and R9/R10 are the spokes.
! R3 is listening to incoming connections from the spokes.
!
pfr master
 mc-peer domain 65000 head-end Loopback0
 target-discovery responder-list RESPONDER_PREFIX inside-prefixes HQ_PREFIX
!
ip prefix-list HQ_PREFIX seq 5 permit 10.10.1.0/24
ip prefix-list HQ_PREFIX seq 10 permit 10.10.2.0/24
ip prefix-list HQ_PREFIX seq 15 permit 10.10.3.0/24
ip prefix-list HQ_PREFIX seq 20 permit 10.10.4.0/24
ip prefix-list RESPONDER_PREFIX seq 5 permit 10.2.2.2/32
!


Enabling Target Discovery on R9:

!
! Target Discovery is used in a hub and spoke model where R3 is the hub and R9/R10 are the spokes.
! R9 is configured with the IP address of the hub (R3)
!
pfr master
 mc-peer domain 65000 10.3.3.3 Loopback0
 target-discovery responder-list RESPONDER1_PREFIX inside-prefixes BRANCH1_PREFIX
!
ip prefix-list BRANCH1_PREFIX seq 5 permit 20.20.0.0/16
ip prefix-list RESPONDER1_PREFIX seq 5 permit 20.20.0.9/32
!

Enabling Target Discovery on R10:

!
!
! Target Discovery is used in a hub and spoke model where R3 is the hub and R9/R10 are the spokes.
! R10 is configured with the IP address of the hub (R3)
!
pfr master
 mc-peer domain 65000 10.3.3.3 Loopback0
 target-discovery responder-list RESPONDER2_PREFIX inside-prefixes BRANCH2_PREFIX
!
ip prefix-list BRANCH2_PREFIX seq 5 permit 30.30.0.0/16
ip prefix-list RESPONDER2_PREFIX seq 5 permit 30.10.10.10/32


Learning Configuration

We would like PfR to learn and optimize traffic going to the branch offices. More specifically, of the streams that are headed to that branch, we would like PfR to optimize certain mission critical traffic based on certain policy parameters and the rest of the traffic based on a different set of parameters.

We also want to apply policies not on a global basis but for specific application groups. The choice here is to define application groups by filtering on DSCP values. The routers R2 and R10 are marking critical application traffic with DSCP af31 and voice traffic with DSCP ef.

We can therefore define learning based on DSCP values while filtering based on the branch prefix. The filtering (based on the prefix) will make sure that PfR only learns traffic destined to the specific branch, while the different access-lists (based on DSCP values) help categorize the interesting traffic into different buckets like critical, best effort, etc., which can then be associated with different optimization policies.

Define learning parameters:


! By default now:
!
! - Automatic learning is enabled
!
! - Continuous learn cycle, each 1 minute duration 
!   periodic-interval = 0 (forever)
!   monitor-period = 1 (minutes)
!
! - traffic-class sorting based on ‘throughput’ at the end of
!   each learning cycle.
!
! - Anything traffic that doesn’t match the learn list will be
!   learned under global learn and will be optimized using default policy. 
!
pfr master
 !
 !--------------------------------------------------------------------------------
 ! Automatic Learning
 ! Define 2 groups of applications
 ! The rest of the traffic falls under global policies
 !--------------------------------------------------------------------------------
 !
 learn
  throughput
  !
  list seq 10 refname LEARN_VOICE_VIDEO
   traffic-class access-list VOICE_VIDEO filter BRANCH_PREFIX
   aggregation-type prefix-length 32
   throughput
  !
  list seq 20 refname LEARN_CRITICAL
   traffic-class access-list CRITICAL filter BRANCH_PREFIX
   throughput
 !
 !
 !--------------------------------------------------------------
 ! Best Effort Traffic
 ! Define the Global policy to load balance rest of the traffic
 ! By default load-balancing is enabled
 !--------------------------------------------------------------
 !
!
!---------------------------------------------------------------
! Classification
!---------------------------------------------------------------
!
!
ip access-list extended VOICE_VIDEO
 permit ip any any dscp ef
!
ip access-list extended CRITICAL
 permit ip any any dscp af31
!
!
ip prefix-list BRANCH_PREFIX seq 5 permit 20.20.0.0/16     
ip prefix-list BRANCH_PREFIX seq 10 permit 30.30.0.0/16
!
ip prefix-list BRANCH1_PREFIX seq 5 permit 20.20.0.0/16   
ip prefix-list BRANCH2_PREFIX seq 5 permit 30.30.0.0/16
!
ip prefix-list HQ_PREFIX seq 5 permit 10.10.1.0/24
ip prefix-list HQ_PREFIX seq 10 permit 10.10.2.0/24
ip prefix-list HQ_PREFIX seq 15 permit 10.10.3.0/24
ip prefix-list HQ_PREFIX seq 20 permit 10.10.4.0/24
!
!


Policy Configuration

Monitoring Modes

We have 3 groups of applications that require different monitoring modes. See Monitoring Modes for more information.

For best effort applications, running passive mode is enough because traffic is mainly based on TCP. For voice, traffic is based on UDP (RTP) and we may want to get additional metrics like delay, jitter or even MOS. So we have to go with an active mode. For critical application we may also want to run in active mode.

To acquire jitter metrics, the router will need to inject instrumented synthetic traffic and derive the required information from there. With TCP traffic, we cannot make passive jitter measurements---only latency, loss and throughput. PfR makes use of the IOS IPSLA feature to generate probes and collect information about the state of the network.

In the case of jitter measurements, IPSLA requires that the probe destination needs to be an IPSLA responder. The IPSLA responder function is available on IOS devices as well as Cisco Telepresence units. The IPSLA responder is able to make accurate latency time stamping and has the vital ability of factoring out the processing time taken within the responder between reception of the probe and the generation of the probe reply.

Realistically, having access to a IPSLA responder along the path of a data traffic is usually only within the scope of private IP networks.

Note that if a traffic-class is monitored under active mode (which is completely active measurement based), passive measurements are disabled for that traffic-class. Notably, the throughput information is unavailable. PfR offers an hybrid monitoring mode called ‘active throughput’ that will trigger OOP based on the active measurements, but throughput information is also collected. The CLI for this command is ‘mode monitor active throughput’ and is used for the critical applications in this lab.


Defining Advanced Policies per Group

PfR-maps are somewhat similar to route-maps in functionality in that a pfr-map will ‘match’ traffic and then apply (or in other words ‘set’) a form of policy to that traffic. Now that the network is able to identify that traffic (via the ACLs and the learn-lists) we can configure the pfr-map entries. So far, PfR was optimizing all traffic based on the inherited global policies, which emphasized load sharing. Also, measurements were done using the default monitor mode of ‘both’ (meaning a combination of ‘passive’ and ‘active’) for all traffic.

VIDEO group:

  • Our voice/video traffic is matching DSCP EF marked flows
  • Latency, jitter and loss would be more important. Another possibility (rather than specifying delay, jitter and loss individually) is that we could have represented our performance target in terms of Mean Opinion Score (MOS), which is a composite metric based on loss, jitter, latency and the specific codec being used. Specifying the target in terms of MOS is much simpler and the reference being used is voice quality (for example, MOS 4 is toll quality voice service).
  • Measurement mode should be ‘fast’ to be able to track delay and loss quickly and more accurately. So, jitter probe is needed and an explicit jitter configuration per branch would be required. Because we use Target Discovery, there is no need for jitter probe configuration anymore.

CRITICAL group:

  • Our critical traffic class is matching DSCP AF31 marked flows.
  • Latency and loss would be more important.
  • Measurement mode should be ‘active throughput’ to be able to track delay and loss as well as getting the bandwidth per traffic class. So, jitter probe is needed and an explicit jitter configuration per branch would be required. Because we use Target Discovery, there is no need for jitter probe configuration anymore.

BE group:

  • Best effort traffic on the other hand can still be optimized for load-balancing.
  • Measurement mode can be passive.


Configuration

Policy configuration for controlling applications:

!-------------------------------------------------------------------------------
! Policies for Voice and Video
!
! – match command is to specify that this policy should be applied
!   to all the traffic-classes learned under list LEARN_VOICE_VIDEO
!
! - monitor mode is set to fast. This means probe all external interfaces
!   all the time. When Out-of-Policy condition is detected on the current 
!   exit results on alternate exit is available for quick decision. In other 
!   modes alternate exits are probed only when current link is determined to 
!   be OOP. The fast mode helps in switching the path quickly when the 
!   problem is detected.
!
! - Re-evaluate exit every 90 sec (periodic 90)
!
! – delay threshold is configured as 60 msec. The delay measured by PfR is
!   Round-Trip-Time.
! - loss threshold is configured as 5%
! - jitter threshold is configured as 30 ms
!
! – Probe frequency is set to 8 seconds and can be changed to a lesser value
!   if the application being controlled is critical.
!
! - Probes are automatically configured and generated by Target Discovery
!
!-------------------------------------------------------------------------------
!
pfr-map MYMAP 10
 match PfR learn list LEARN_VOICE_VIDEO
 set periodic 90
 set delay threshold 200
 set loss threshold 50000
 set jitter threshold 30
 set mode monitor fast
 set resolve loss priority 2 variance 5
 set resolve jitter priority 3 variance 5
 set resolve delay priority 4 variance 5
 set probe frequency 8
 set link-group SP1 fallback SP2
!
!
!-------------------------------------------------------------------------------
! Policies for Critical Data
!
! – match command is to specify that this policy should be applied
!   to all the traffic-classes learned under list LEARN_CRITICAL
!
! - monitor mode is set to active throughput. This shows the use of active mode
!   as well as BW collection. Realistically For critical data, fast mode is also 
!   used for quick decision and fast failover.
!
! - Re-evaluate exit every 90 sec (periodic 90)
!
! – delay threshold is configured as 60 msec. The delay measured by PfR is
!   Round-Trip-Time.
! - loss threshold is configured as 5%
!
! – Probe frequency is set to 8 seconds and can be changed to a lesser value
!   if the application being controlled is critical.
!
! - Probes are automatically configured and generated by Target Discovery
!
!-------------------------------------------------------------------------------
!
pfr-map MYMAP 20
 match pfr learn list LEARN_CRITICAL
 set periodic 90
 set delay threshold 120
 set mode monitor active throughput
 set resolve delay priority 1 variance 20
 set resolve loss priority 5 variance 10
 set probe frequency 8
 set link-group SP1 fallback SP2
!


Now that the policies are defined using pfr-map, we need to apply them on the PfR MC for them to take effect. This is done through the ‘policy-rules’ command under ‘pfr master’ global mode:

!
pfr master
 policy-rules MYMAP
!


PfR Configuration Verification

Master Controller (MC)

Verify the Border Routers, verify the parameters used (default and configured) and check the learn-list.


R3#sh pfr master
OER state: ENABLED and ACTIVE
  Conn Status: SUCCESS, PORT: 3949
  Version: 3.3
  Number of Border routers: 2
  Number of Exits: 2
  Number of monitored prefixes: 90 (max 5000)
  Max prefixes: total 5000 learn 2500
  Prefix count: total 90, learn 88, cfg 0
  PBR Requirements met
  Nbar Status: Inactive
  Auto Tunnel Mode: Off

Border           Status                UP/DOWN             AuthFail  Version  DOWN Reason
10.5.5.5         ACTIVE                UP       00:35:40          0  3.3
10.4.4.4         ACTIVE                UP       00:35:39          0  3.3

Global Settings:
  max-range-utilization percent 30 recv 0
  rsvp post-dial-delay 0 signaling-retries 1
  mode route metric bgp local-pref 5000
  mode route metric static tag 5000
  mode route protocol pbr
  trace probe delay 1000
  logging
  exit holddown time 60 secs, time remaining 0

Default Policy Settings:
  backoff 90 900 90
  delay relative 50
  holddown 90
  periodic 90
  probe frequency 56
  number of jitter probe packets 20
  mode route control 
  mode monitor both
  loss relative 10
  jitter threshold 20
  mos threshold 3.60 percent 30
  unreachable relative 50
  trigger-log percentage 30

Learn Settings:
  current state : STARTED
  time remaining in current state : 90 seconds
  throughput
  no delay
  no inside bgp
  monitor-period 1
  periodic-interval 0
  aggregation-type prefix-length 24
  prefixes 100 appls 100
  expire after time 720

  Learn-List seq 10 refname LEARN_VOICE_VIDEO
    Configuration:
     Traffic-Class Access-list: VOICE_VIDEO
     Filter: BRANCH_PREFIX
     Aggregation-type: prefix-length 32
     Learn type: throughput
     Session count: 1000 Max count: 1000
     Policies assigned: 10
     Status: ACTIVE
    Stats:
     Traffic-Class Count: 2
  Learn-List seq 20 refname LEARN_CRITICAL
    Configuration:
     Traffic-Class Access-list: CRITICAL
     Filter: BRANCH_PREFIX
     Aggregation-type: prefix-length 24
     Learn type: throughput
     Session count: 1000 Max count: 1000
     Policies assigned: 20
     Status: ACTIVE
    Stats:
     Traffic-Class Count: 38
R3# 

What to check:

  • Both Border Routers are up and running
  • Check to make sure that PBR Requirements are met
  • Number of automatically learned applications – 2 in this case for Voice and 38 for Critical
  • All default policy settings are displayed
  • Learn is started (current state : STARTED)
  • Learn-list status is ACTIVE and learn-type is throughput
  • Make sure that all the configured learn lists show up
  • For each learn-list, check the Traffic Class access-list (if configured), prefix-list (if configured) and the policy number associated (which is the pfr-map it refers to).
  • The Traffic Class count is also displayed which allows you to check whether the learning process worked well.


Check if the application is automatically learnt under each learn-list


R3#
R3#show pfr master learn list

 Learn-List seq 10 refname LEARN_VOICE_VIDEO
   Configuration:
    Traffic-Class Access-list: VOICE_VIDEO
    Filter: BRANCH_PREFIX
    Aggregation-type: prefix-length 32
    Learn type: throughput
    Session count: 1000 Max count: 1000
    Policies assigned: 10
    Status: ACTIVE
   Stats:
    Traffic-Class Count: 2
    Traffic-Class Learned:
     Appl Prefix 30.30.0.11/32 ef   256
     Appl Prefix 20.20.0.12/32 ef   256
 Learn-List seq 20 refname LEARN_CRITICAL
   Configuration:
    Traffic-Class Access-list: CRITICAL
    Filter: BRANCH_PREFIX
    Aggregation-type: prefix-length 24
    Learn type: throughput
    Session count: 1000 Max count: 1000
    Policies assigned: 20
    Status: ACTIVE
   Stats:
    Traffic-Class Count: 38
    Traffic-Class Learned:
     Appl Prefix 30.30.18.0/24 af31 256
     Appl Prefix 30.30.16.0/24 af31 256
     Appl Prefix 30.30.20.0/24 af31 256
     Appl Prefix 30.30.14.0/24 af31 256
     Appl Prefix 20.20.20.0/24 af31 256
     Appl Prefix 30.30.11.0/24 af31 256
     Appl Prefix 20.20.18.0/24 af31 256
     Appl Prefix 20.20.16.0/24 af31 256
     Appl Prefix 30.30.8.0/24 af31 256
     Appl Prefix 30.30.7.0/24 af31 256
     Appl Prefix 20.20.14.0/24 af31 256
     Appl Prefix 20.20.12.0/24 af31 256
     Appl Prefix 30.30.5.0/24 af31 256
     Appl Prefix 20.20.11.0/24 af31 256
     Appl Prefix 20.20.10.0/24 af31 256
     Appl Prefix 20.20.9.0/24 af31 256
     Appl Prefix 30.30.19.0/24 af31 256
     Appl Prefix 20.20.8.0/24 af31 256
     Appl Prefix 30.30.17.0/24 af31 256
     Appl Prefix 20.20.7.0/24 af31 256
     Appl Prefix 20.20.6.0/24 af31 256
     Appl Prefix 20.20.5.0/24 af31 256
     Appl Prefix 20.20.4.0/24 af31 256
     Appl Prefix 20.20.3.0/24 af31 256
     Appl Prefix 20.20.15.0/24 af31 256
     Appl Prefix 30.30.2.0/24 af31 256
     Appl Prefix 20.20.2.0/24 af31 256
     Appl Prefix 20.20.17.0/24 af31 256
     Appl Prefix 30.30.12.0/24 af31 256
     Appl Prefix 30.30.13.0/24 af31 256
     Appl Prefix 30.30.10.0/24 af31 256
     Appl Prefix 30.30.9.0/24 af31 256
     Appl Prefix 30.30.6.0/24 af31 256
     Appl Prefix 30.30.4.0/24 af31 256
     Appl Prefix 20.20.19.0/24 af31 256
     Appl Prefix 30.30.3.0/24 af31 256
     Appl Prefix 20.20.13.0/24 af31 256
     Appl Prefix 30.30.15.0/24 af31 256
R3#  


Check the default policies:


R3#sh pfr master policy 
Default Policy Settings:
  backoff 90 900 90
  delay relative 50
  holddown 90
  periodic 90
  probe frequency 56
  number of jitter probe packets 20
  mode route control 
  mode monitor both
  loss relative 10
  jitter threshold 20
  mos threshold 3.60 percent 30
  unreachable relative 50
  trigger-log percentage 30

[SNIP]

R3#


Check the policy associated for LEARN_VOICE_VIDEO:


R3#sh pfr master policy 10
* Overrides Default Policy Setting
oer-map MYMAP 10
  sequence no. 8444249301975040, provider id 1, provider priority 30
    host priority 0, policy priority 10, Session id 0
  match oer learn list LEARN_VOICE_VIDEO
  backoff 90 900 90
 *delay threshold 200
  holddown 90
 *periodic 90
 *probe frequency 8
  number of jitter probe packets 20
  mode route control 
 *mode monitor fast
 *loss threshold 50000
 *jitter threshold 30
  mos threshold 3.60 percent 30
  unreachable relative 50
  next-hop not set
  forwarding interface not set
  trigger-log percentage 30
 *resolve loss priority 2 variance 5
 *resolve jitter priority 3 variance 5
 *resolve delay priority 4 variance 5
 *link-group SP1 fallback SP2
R3# 


Check the policy associated for LEARN_CRITICAL:


R3#sh pfr master policy 20
* Overrides Default Policy Setting
oer-map MYMAP 20
  sequence no. 8444249302630400, provider id 1, provider priority 30
    host priority 0, policy priority 20, Session id 0
  match oer learn list LEARN_CRITICAL
  backoff 90 900 90
 *delay threshold 120
  holddown 90
 *periodic 90
 *probe frequency 8
  number of jitter probe packets 20
  mode route control 
 *mode monitor active throughput
  loss relative 10
  jitter threshold 20
  mos threshold 3.60 percent 30
  unreachable relative 50
  next-hop not set
  forwarding interface not set
  trigger-log percentage 30
 *resolve delay priority 1 variance 20
 *resolve loss priority 5 variance 10
 *link-group SP1 fallback SP2
R3# 

Notes:

  • Default policies that will be applied are somewhat similar to the concept of default-class in QoS. All Traffic that does not match LEARN_VOICE_VIDEO or LEARN_CRITICAL falls under global policies. Load balancing is enabled by default for this kind of traffic.
  • Then note the additional section under ‘pfr-map MYMAP 10’ and ‘pfr-map MYMAP 20’ (just like route-maps, we can have multiple stanzas of match critera and policies).
  • Note how the pfr-map inherits the policy settings from default for parameters that were not explicitly configured under the pfr-map entry.




Check Target Discovery and Peering:


R3#sh pfr master target-discovery 
PfR Target-Discovery Services
 Mode: Static  Domain: 65000
 Responder list: RESPONDER_PREFIX  Inside-prefixes list: HQ_PREFIX
 SvcRtg: client-handle: 3  sub-handle: 2  pub-seq: 1

PfR Target-Discovery Database (local)

 Local-ID: 10.3.3.3          Desc: R3
   Target-list: 10.2.2.2
   Prefix-list: 10.10.4.0/24, 10.10.3.0/24, 10.10.2.0/24, 10.10.1.0/24

PfR Target-Discovery Database (remote)

 MC-peer: 30.10.10.10        Desc: R10
   Target-list: 30.10.10.10
   Prefix-list: 30.30.0.0/16

 MC-peer: 20.9.9.9           Desc: R9
   Target-list: 20.9.9.9
   Prefix-list: 2.0.0.0/8, 20.20.0.0/16

R3#

What to Check:

  • You get the list of all remote sites
  • You get the list of destination prefixes per remote site
  • You also get the probe target addresses per remote site (there could be multiple responders within a given site)


You can display the state of active probes on the MC. Remember that IP SLA probes are generated by the BRs, which report back the results to the MC.


R3#sh pfr master active-probes target-discovery 
PfR Master Controller active-probes (TD)
Border  = Border Roter running this probe
MC-Peer = Remote MC associated with this target
Type    = Probe Type
Target  = Target Address
TPort   = Target Port
N - Not applicable

Destination Site Peer Addresses:

MC-Peer           Targets
30.10.10.10       30.10.10.10
20.9.9.9          20.9.9.9

The following Probes are running:

Border          Idx  State     MC-Peer            Type     Target           TPort
10.5.5.5         2   TD-Actv   30.10.10.10        jitter   30.10.10.10      5000
10.4.4.4         2   TD-Actv   30.10.10.10        jitter   30.10.10.10      5000
10.5.5.5         2   TD-Actv   30.10.10.10        jitter   30.10.10.10      5000
10.4.4.4         2   TD-Actv   30.10.10.10        jitter   30.10.10.10      5000
10.5.5.5         2   TD-Actv   20.9.9.9           jitter   20.9.9.9         5000
10.4.4.4         2   TD-Actv   20.9.9.9           jitter   20.9.9.9         5000


R3#

Note:

  • Multiple probe types generated: echo for critical applications (no need for jitter information) and jitter probes (voice/video traffic).
  • The probe packets will automatically take on the DSCP properties of the traffic class. In the case that the traffic class type has multiple DSCP settings (which is very likely when the traffic class is learned rather than explicitly specified), a unique probe for each DSCP value will be generated.
    • Voice:
      • DSCP EF (46, 0x2E)
      • TOS = 0xB8, 184
    • Business:
      • DSCP AF31 (26, 0x1A)
      • TOS = 0x68, 104

Notes specific to Target Discovery probes

  • Traffic classes going to the same remote site share probe statistics
  • Only one set of probes will be run on each BR even thought multiple applications to the same site are being monitored by PfR
  • Probes to TD targets are always of type jitter
  • If there are multiple targets advertised by a remote site, one probes to all targets will be run simultaneously


Verify Traffic Class Statistics


As soon as you see:

R3#
*Sep 20 20:24:43.515: %OER_MC-5-NOTICE: Prefix Learning WRITING DATA
*Sep 20 20:24:43.589: %OER_MC-5-NOTICE: Prefix Learning STARTED
R3#


You should be able to see the traffic classes on the Master Controller. You will need a few cycles before having all applications in INPOLICY state.


Verify learnt Traffic Classes

On the Master Controller, you have all the Traffic Classes (learnt as well as statistics): Use show pfr master traffic-class to see the state of the application:


R3#sh 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
--------------------------------------------------------------------------------

20.20.8.0/24              N    N    N           N           N N                 
                          INPOLICY      @15          10.4.4.4 Et0/1           RIB-PBR 
              52       56        0        0        0        0        8        1
               U       52        0        0        0        U        0        0

20.20.8.0/24              N af31  256           N           N 0.0.0.0/0         
               #          INPOLICY       61          10.4.4.4 Et0/1           PBR     
              52       52        0        0        0        0        4        1
              52       52        0        0        N        N        N        N

20.20.16.0/24             N    N    N           N           N N                 
                          INPOLICY        4          10.4.4.4 Et0/1           RIB-PBR 
              52       52        0        0        0        0        9        1
               U       52        0        0        0        U        0        0

20.20.16.0/24             N af31  256           N           N 0.0.0.0/0         
               #          INPOLICY       66          10.4.4.4 Et0/1           PBR     
              52       52        0        0        0        0        3        1
              49       51        0        0        N        N        N        N

30.30.0.0/24              N    N    N           N           N N                 
                          HOLDDOWN        8          10.5.5.5 Et0/1           RIB-PBR 
               U        U        0        0        0        0        0        0
               U        U        0        0        0        U        0        0

30.30.8.0/24              N af31  256           N           N 0.0.0.0/0         
               #          INPOLICY       56          10.4.4.4 Et0/1           PBR     
              68       68        0        0        0        0        3        1
              51       50        0        0        N        N        N        N

20.20.0.12/32             N   ef  256           N           N 0.0.0.0/0         
                          INPOLICY      @18          10.4.4.4 Et0/1           PBR     
               U        U        0        0        0        0        1        1
              52       52        0        0        2        0        0        0

30.30.0.11/32             N   ef  256           N           N 0.0.0.0/0         
                          INPOLICY      @17          10.4.4.4 Et0/1           PBR     
               U        U        0        0        0        0        1        1
              51       51        0        0        2        0        0        0

[SNIP]

R3#  

Notes:

  • Note the DSCP values under the DSCP field column.
  • The TCs belonging to CRITICAL and VOICE_VIDEO learn-list are being forced out R4 as it has a delay within the defined threshold to the remote branch and because the preferred path is SP1 (note that R5 would be a valid choice too without the link-group policy).
  • The TCs belonging to BE are supposed to be load-balanced across both Border Routers and exit links.
  • Note the path enforcement used.


A closer look at the results You can also have all information related to a specific traffic class with the following command:


R3#sh pfr master traffic-class performance ip any 20.20.0.0/24 dscp ef
==============================================================================================

Traffic-class:
 Destination Prefix : 20.20.0.12/32           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.4.4 interface Et0/1, Tie breaker was None
   Time on current exit            : 0d 0:12:26
   Time remaining in current state : @3 seconds
   Last uncontrol reason           : Probe frequency changed
   Time since last uncontrol       : 0d 0:12:59
   Traffic-class type              : Learned
   Target-Discovery origin         : 20.9.9.9
   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%
   Loss                   : 0 -- Threshold: 50000
   Delay                  : 0 msecs -- Threshold: 200 msecs
   Egress BW              : 1 kbps
   Ingress BW             : 1 kbps
   Time since last update : 0d 0:0:17

 Average Active Performance Current Exit: (Average for last 5 minutes)
   Unreachable            : 0% -- Threshold: 50%
   Loss                   : 0 -- Threshold: 50000 
   Jitter                 : 231 msec -- Threshold: 3000 msec
   Delay                  : 51 msec -- Threshold: 200 msec

 Last Resolver Decision:
   BR              Interface    Status       Reason       Performance Threshold
   --------------- ------------ ------------ ------------ ----------- ---------
   10.5.5.5        Et0/1        Eliminated   Link Group   N/A          N/A         
   10.4.4.4        Et0/1        Best Exit    Unreachable  N/A          N/A         
          
==============================================================================================
R3#


Monitoring Load Balancing. Traffic other than voice/video and critical application is load balanced across all external interfaces. To visualize the accuracy of the load balancing, the following command can be used:


R3#sh pfr master exits 
==============================================================================================
PfR Master Controller Exits:

General Info:
=============
  E - External
  I - Internal
  N/A - Not Applicable
                                                                                           Up/
   ID Name         Border          Interface   ifIdx IP Address      Mask Policy      Type Down
  --- ------------ --------------- ----------- ----- --------------- ---- ----------- ---- ----
    2              10.4.4.4        Et0/1           2 100.4.81.4        24 Util          E  UP  
    1              10.5.5.5        Et0/1           2 100.5.82.5        24 Util          E  UP  

Global Exit Policy:
===================
            Cost:      In Policy
          
Exits Performance:
==================
                   Egress                                            Ingress
    ---------------------------------------------------- ------------------------------------
 ID Capacity  MaxUtil    Usage   %      RSVP POOL    OOP Capacity  MaxUtil    Usage   %  OOP
 --- -------- -------- -------- --- -------------- ----- -------- -------- -------- --- -----
  2     1000      900      313  31            N/A    N/A     1000     1000       78   7  N/A
  1     1000      900      256  25            N/A    N/A     1000     1000       13   1  N/A

TC and BW Distribution:
=======================
                       # of TCs                  BW (kbps)            Probe   Active
     Name/ID   Current Controlled InPolicy    Controlled       Total  Failed  Unreach
                                                                     (count) (fpm)
        ----   ----------------------------   ----------------------  ------  --------
           2       55         55       55          272          313 4294966270          0
           1       29         29       29          218          256 4294965244          0

Exit Related TC Stats:
======================
                                  Priority
                             highest       nth
                            ------------------
  Number of TCs with range:        0         0
   Number of TCs with util:        0         0
   Number of TCs with cost:        0         0

       Total number of TCs:       90
R3#

Notes:

  • You can check the bandwidth usage on all external interfaces
  • You can also check the number of TCs on each link.





Border Routers (BRs)

Check Active probing status on Border Router:


R4#sh pfr border active-probes 
        OER Border active-probes
Type      = Probe Type
Target    = Target IP Address
TPort     = Target Port
Source    = Send From Source IP Address
Interface = Exit interface
Att       = Number of Attempts
Comps   = Number of completions
N - Not applicable

Type     Target          TPort Source          Interface           Att   Comps
DSCP 

[SNIP] 

jitter   20.9.9.9         5000 100.4.81.4      Et0/1               149    2980
0     
jitter   30.10.10.10      5000 100.4.81.4      Et0/1               256    5120
0     
jitter   20.9.9.9         5000 100.4.81.4      Et0/1               275    5500
184   
jitter   30.10.10.10      5000 100.4.81.4      Et0/1               275    5500
184   


R4#


Or

R4#sh pfr border active-probes | inc jitter
jitter   20.9.9.9         5000 100.4.81.4      Et0/1                 6     120
jitter   30.10.10.10      5000 100.4.81.4      Et0/1                 6     120
jitter   20.9.9.9         5000 100.4.81.4      Et0/1                40     800
jitter   30.10.10.10      5000 100.4.81.4      Et0/1               147    2940
jitter   20.9.9.9         5000 100.4.81.4      Et0/1               167    3340
jitter   30.10.10.10      5000 100.4.81.4      Et0/1               167    3340
R4#


You can check the IP SLA configuration:


R4#sh ip sla configuration 
IP SLAs Infrastructure Engine-III
Entry number: 11
Owner: Optimized Edge Routing (OER)
Tag: 
Operation timeout (milliseconds): 4000
Type of operation to perform: udp-jitter
Target address/Source address: 30.10.10.10/100.4.81.4
Target port/Source port: 5000/0
Type Of Service parameter: 0xB8
Codec Type: g729a
Codec Number Of Packets: 20
Codec Packet Size: 32
Codec Interval (milliseconds): 20
Advantage Factor: 0
Verify data: No
Vrf Name: 
Control Packets: enabled
Schedule:
   Operation frequency (seconds): 8  (not considered if randomly scheduled)
   Next Scheduled Start Time: Start Time already passed
   Group Scheduled : FALSE
   Randomly Scheduled : FALSE
   Life (seconds): Forever
   Entry Ageout (seconds): never
   Recurring (Starting Everyday): FALSE
   Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 4000
Distribution Statistics:
   Number of statistic hours kept: 2
   Number of statistic distribution buckets kept: 1
   Statistic distribution interval (milliseconds): 20
Enhanced History:

[SNIP]

R4#


Notes:

  • Each probe has its own entry number.
  • These probes are managed by PfR (means there is no configuration done directly on the router)
  • You can check the probe type (echo or jitter)
  • For jitter you can also check the codec used, as well as packet size, interval, etc


Detailed statistics can be displayed using the following command:


R4#sh ip sla statistics 11   
IPSLAs Latest Operation Statistics

IPSLA operation id: 11
Type of operation: udp-jitter
        Latest RTT: 51 milliseconds
Latest operation start time: 14:46:10 MET Fri Sep 21 2012
Latest operation return code: OK
RTT Values:
        Number Of RTT: 20               RTT Min/Avg/Max: 46/51/55 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 20
        Source to Destination Latency one way Min/Avg/Max: 46/51/55 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 0/0/1 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 19
        Number of DS Jitter Samples: 19
        Source to Destination Jitter Min/Avg/Max: 0/3/7 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/1/1 milliseconds
Packet Loss Values:
        Loss Source to Destination: 0
        Source to Destination Loss Periods Number: 0
        Source to Destination Loss Period Length Min/Max: 0/0
        Source to Destination Inter Loss Period Length Min/Max: 0/0
        Loss Destination to Source: 0
        Destination to Source Loss Periods Number: 0
        Destination to Source Loss Period Length Min/Max: 0/0
        Destination to Source Inter Loss Period Length Min/Max: 0/0
        Out Of Sequence: 0      Tail Drop: 0
        Packet Late Arrival: 0  Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 11
        MOS score: 4.06
Number of successes: 209
Number of failures: 0
Operation time to live: Forever


R4#


How does PfR modify Paths on the Border Routers:

PfR will create dynamic route-maps (dynamic PBR) on both Borders Routers (R4 and R5) to forward any flows matching the application:

  • over the PFR configured internal interfaces to the forwarding BR if it's the non-forwarding BR.
  • or over the external interfaces to the WAN if it is the forwarding BR.

In-order for the PBR based route control to be successful, the BRs have to be adjacent either through a direct connection or one hop away.


R4#sh route-map dynamic detail 
route-map OER_INTERNAL_RMAP, permit, sequence 0, identifier 1694498817
  Match clauses:
    ip address (access-lists): oer#1 
      Extended IP access list oer#1
          2047 permit ip any 30.30.16.0 0.0.0.255 dscp af31 (948 matches)
          4095 permit ip any 30.30.14.0 0.0.0.255 dscp af31 (828 matches)
          6143 permit ip any 20.20.14.0 0.0.0.255 dscp af31 (876 matches)
          8191 permit ip any 20.20.3.0 0.0.0.255 dscp af31 (984 matches)
          10239 permit ip any 20.20.5.0 0.0.0.255 dscp af31 (912 matches)
          12287 permit ip any 30.30.9.0 0.0.0.255 dscp af31 (876 matches)
          14335 permit ip any 30.30.20.0 0.0.0.255 dscp af31 (756 matches)
          16383 permit ip any 20.20.7.0 0.0.0.255 dscp af31 (1104 matches)
          18431 permit ip any 30.30.13.0 0.0.0.255 dscp af31 (900 matches)
          20479 permit ip any 30.30.6.0 0.0.0.255 dscp af31 (924 matches)
          22527 permit ip any 20.20.13.0 0.0.0.255 dscp af31 (936 matches)
          24575 permit ip any 20.20.10.0 0.0.0.255 dscp af31 (960 matches)
          26623 permit ip any 20.20.20.0 0.0.0.255 dscp af31 (814 matches)
          28671 permit ip any 30.30.11.0 0.0.0.255 dscp af31 (924 matches)
          30719 permit ip any 20.20.9.0 0.0.0.255 dscp af31 (900 matches)
          32767 permit ip any 30.30.19.0 0.0.0.255 dscp af31 (948 matches)
          34815 permit ip any 30.30.12.0 0.0.0.255 dscp af31 (1008 matches)
          36863 permit ip any 20.20.17.0 0.0.0.255 dscp af31 (840 matches)
          38911 permit ip any 20.20.18.0 0.0.0.255 dscp af31 (936 matches)
          40959 permit ip any 20.20.4.0 0.0.0.255 dscp af31 (840 matches)
          43007 permit ip any 30.30.18.0 0.0.0.255 dscp af31 (1044 matches)
          45055 permit ip any 30.30.5.0 0.0.0.255 dscp af31 (876 matches)
          47103 permit ip any 30.30.4.0 0.0.0.255 dscp af31 (863 matches)
          49151 permit ip any 20.20.15.0 0.0.0.255 dscp af31 (1056 matches)
          57343 permit ip any 30.30.15.0 0.0.0.255 dscp af31 (792 matches)
          65535 permit ip any 20.20.11.0 0.0.0.255 dscp af31 (894 matches)
          131071 permit ip any 30.30.8.0 0.0.0.255 dscp af31 (876 matches)
          262143 permit ip any 30.30.10.0 0.0.0.255 dscp af31 (948 matches)
          524287 permit ip any 20.20.16.0 0.0.0.255 dscp af31 (852 matches)
          1048575 permit ip any 20.20.6.0 0.0.0.255 dscp af31 (792 matches)
          2097151 permit ip any 30.30.7.0 0.0.0.255 dscp af31 (953 matches)
          4194303 permit ip any 20.20.19.0 0.0.0.255 dscp af31 (1008 matches)
          8388607 permit ip any 20.20.8.0 0.0.0.255 dscp af31 (864 matches)
          16777215 permit ip any 30.30.17.0 0.0.0.255 dscp af31 (1020 matches)
          33554431 permit ip any 30.30.3.0 0.0.0.255 dscp af31 (1008 matches)
          67108863 permit ip any 20.20.12.0 0.0.0.255 dscp af31 (948 matches)
          134217727 permit ip any host 20.20.0.12 dscp ef (1768 matches)
          268435455 permit ip any host 30.30.0.11 dscp ef (1769 matches)
          536870911 permit ip any 30.30.2.0 0.0.0.255 dscp af31 (3048 matches)
          1073741823 permit ip any 20.20.2.0 0.0.0.255 dscp af31 (3041 matches)
          2147483647 deny ip any any (72238 matches)
  Set clauses:
    ip next-hop 100.4.81.1
    interface Ethernet0/1
  Policy routing matches: 42634 packets, 35738442 bytes
route-map OER_INTERNAL_RMAP, permit, sequence 1, identifier 150994946
  Match clauses:
    ip address (access-lists): oer#2 
      Extended IP access list oer#2
          2047 permit ip any 30.30.5.0 0.0.0.255 (2171 matches)
          12287 permit ip any 30.30.3.0 0.0.0.255 (2039 matches)
          18431 permit ip any 20.20.8.0 0.0.0.255 (2172 matches)
          20479 permit ip any 30.30.13.0 0.0.0.255 (2136 matches)
          22527 permit ip any 20.20.9.0 0.0.0.255 (2141 matches)
          24575 permit ip any 20.20.14.0 0.0.0.255 (2172 matches)
          26623 permit ip any 30.30.15.0 0.0.0.255 (2244 matches)
          28671 permit ip any 30.30.7.0 0.0.0.255 (2088 matches)
          30719 permit ip any 30.30.20.0 0.0.0.255 (2289 matches)
          32767 permit ip any 20.20.5.0 0.0.0.255 (2124 matches)
          36863 permit ip any 30.30.11.0 0.0.0.255 (2112 matches)
          38911 permit ip any 20.20.19.0 0.0.0.255 (2038 matches)
          262143 permit ip any 20.20.18.0 0.0.0.255 (2110 matches)
          16777215 permit ip any 20.20.16.0 0.0.0.255 (2196 matches)
          536870911 permit ip any 20.20.11.0 0.0.0.255 (2154 matches)
          2147483647 deny ip any any (37495 matches)
  Set clauses:
    ip next-hop 100.4.81.1
    interface Ethernet0/1
  Policy routing matches: 34743 packets, 31583282 bytes
route-map OER_INTERNAL_RMAP, permit, sequence 2, identifier 1828716547
  Match clauses:
    ip address (access-lists): oer#3 
      Extended IP access list oer#3
          2047 permit ip any 20.20.6.0 0.0.0.255
          4095 permit ip any 30.30.8.0 0.0.0.255
          6143 permit ip any 30.30.14.0 0.0.0.255
          8191 permit ip any 30.30.16.0 0.0.0.255
          10239 permit ip any 20.20.3.0 0.0.0.255
          12287 permit ip any 30.30.4.0 0.0.0.255
          14335 permit ip any 20.20.4.0 0.0.0.255
          16383 permit ip any 20.20.15.0 0.0.0.255
          18431 permit ip any 30.30.9.0 0.0.0.255
          20479 permit ip any 20.20.20.0 0.0.0.255
          22527 permit ip any 30.30.6.0 0.0.0.255
          24575 permit ip any 30.30.19.0 0.0.0.255
          26623 permit ip any 30.30.10.0 0.0.0.255
          28671 permit ip any 30.30.12.0 0.0.0.255
          30719 permit ip any 20.20.13.0 0.0.0.255
          32767 permit ip any 30.30.18.0 0.0.0.255
          65535 permit ip any 20.20.12.0 0.0.0.255
          131071 permit ip any 20.20.17.0 0.0.0.255
          262143 permit ip any 30.30.17.0 0.0.0.255
          524287 permit ip any 20.20.7.0 0.0.0.255
          1048575 permit ip any 20.20.10.0 0.0.0.255
          2097151 permit ip any 30.10.82.0 0.0.0.255
          4194303 permit ip any 20.9.81.0 0.0.0.255 (26005 matches)
          8388607 permit ip any 20.9.82.0 0.0.0.255
          16777215 permit ip any host 30.10.10.10 (366 matches)
          67108863 permit ip any 20.20.1.0 0.0.0.255
          134217727 permit ip any 30.10.81.0 0.0.0.255 (8982 matches)
          268435455 permit ip any 30.30.1.0 0.0.0.255
          536870911 permit ip any host 20.9.9.9 (366 matches)
          2147483647 deny ip any any
  Set clauses:
    ip next-hop 10.4.5.5
    interface Ethernet0/0
  Policy routing matches: 35294 packets, 2605004 bytes
Current active dynamic routemaps = 1
R4#


Conclusion

The configuration examples provided above explain how applications can be learnt and optimized using learn lists and pfr-maps.

Performance Routing is an advanced and flexible technology that allows multiple deployments. Based on this solution guides, customers can define their own policies to match their needs.


Rating: 4.9/5 (11 votes cast)

Personal tools