PfR:Solutions:EnterpriseWAN
From DocWiki
- 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
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).
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
- Voice:
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.
