The following example, starting in global configuration mode, shows how quickly a new exit can be selected when fast failover is configured.
 Note |
Fast monitoring is a very aggressive mode that incurs a lot of overhead with the continuous probing. We recommend that you use fast monitoring only for performance sensitive traffic.
|
The first output shows the configuration at the master controller of three border routers. Route control mode is enabled.
Router# show run | sec pfr master
pfr master
policy-rules MAP
port 7777
logging
!
border 10.3.3.3 key-chain key1
interface Ethernet9/0 external
interface Ethernet8/0 internal
!
border 10.3.3.4 key-chain key2
interface Ethernet5/0 external
interface Ethernet8/0 internal
!
border 10.4.4.2 key-chain key3
interface Ethernet2/0 external
interface Ethernet8/0 internal
backoff 90 90
mode route control
resolve jitter priority 1 variance 10
no resolve delay
!
To verify the basic configuration and show the status of the border routers, the show pfr master command is run:
Router# show pfr master
OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 7777
Version: 2.1
Number of Border routers: 3
Number of Exits: 3
Number of monitored prefixes: 1 (max 5000)
Max prefixes: total 5000 learn 2500
Prefix count: total 1, learn 0, cfg 1
Border Status UP/DOWN AuthFail Version
10.4.4.2 ACTIVE UP 17:00:32 0 2.1
10.3.3.4 ACTIVE UP 17:00:35 0 2.1
10.3.3.3 ACTIVE UP 17:00:38 0 2.1
Global Settings:
max-range-utilization percent 20 recv 20
mode route metric bgp local-pref 5000
mode route metric static tag 5000
trace probe delay 1000
logging
Default Policy Settings:
backoff 90 90 90
delay relative 50
holddown 90
periodic 0
probe frequency 56
mode route control
mode monitor both
mode select-exit good
loss relative 10
jitter threshold 20
mos threshold 3.60 percent 30
unreachable relative 50
resolve jitter priority 1 variance 10
resolve utilization priority 12 variance 20
Learn Settings:
current state : DISABLED
time remaining in current state : 0 seconds
no throughput
no delay
no inside bgp
no protocol
monitor-period 5
periodic-interval 120
aggregation-type prefix-length 24
prefixes 100
expire after time 720
Fast failover is now configured for active voice probes and the probe frequency is set to 2 seconds using a PfR map. The fast failover monitoring mode is enabled and the voice traffic to be monitored is identified using an IP prefix list to specify the 10.1.1.0/24 prefix. To reduce some of the overhead that fast failover monitoring produces, the active voice probes are assigned a forced target for PfR.
Router# show run | sec pfr-map
pfr-map MAP 10
match traffic-class prefix-list VOICE_FAIL_LIST
set mode select-exit best
set mode monitor fast
set jitter threshold 12
set active-probe jitter 120.120.120.1 target-port 20 codec g729a
set probe frequency 2
The following output from the show pfr master prefixcommand when a prefix is specified with the policy keyword shows the policy configured for the prefix 10.1.1.0/24. Note that the mode monitor is set to fast, which automatically sets the select-exit to best, and allows the probe frequency to be set at 2.
Router# show pfr master prefix 10.1.1.0/24 policy
* Overrides Default Policy Setting
pfr-map MAP 10
sequence no. 8444249301975040, provider id 1, provider priority 30
host priority 0, policy priority 10, Session id 0
match ip prefix-lists: VOICE_FAIL_LIST
backoff 90 90 90
delay relative 50
holddown 90
periodic 0
*probe frequency 2
mode route control
*mode monitor fast
*mode select-exit best
loss relative 10
*jitter threshold 12
mos threshold 3.60 percent 30
unreachable relative 50
next-hop not set
forwarding interface not set
resolve jitter priority 1 variance 10
resolve utilization priority 12 variance 20
Forced Assigned Target List:
active-probe jitter 10.120.120.1 target-port 20 codec g729a
After the master controller is configured for fast failover as shown in this task, and a traffic class goes out of policy, the logging output below shows that the traffic class represented by prefix 10.1.1.0/24 is routed by PfR through a new border router exit at interface 10.3.3.4 within 3 seconds. From the logging output, it appears that the traffic class moved to an out-of-policy state due to the jitter threshold being exceeded.
May 2 10:55:27.355: %OER_MC-5-NOTICE: Active ABS Jitter OOP Prefix 10.1.1.0/24,
jitter 15, BR 10.4.4.2, i/f Et2/0
May 2 10:55:27.367: %OER_MC-5-NOTICE: Route changed Prefix 10.1.1.0/24, BR 10.3.3.4,
i/f Et5/0, Reason Jitter, OOP Reason Jitter