Daily Archives: November 3, 2014

6.4.e Identify performance routing [PfR]

PfR has three monitoring modes of operations, namely

● Active mode: uses IP SLA probes

● Passive mode: uses NetFlow

● Fast mode: uses IP SLA probes (based on FRR feature)

No explicit NetFlow or IP SLAs configuration is required; support for NetFlow and IP SLAs is enabled and configured automatically by the master controller. You can use both active and passive monitoring methods for each traffic class. The master controller uses both passive and active monitoring by default. All traffic classes are passively monitored using integrated NetFlow functions, whereas the OOP traffic classes are actively monitored using IP SLA functions.

Passive monitoring metrics include the following:

● Delay: Cisco PfR measures the average delay of TCP flows for a given prefix or traffic class. Delay is the measurement of the round-trip response time (RTT) between the transmission of a TCP synchronization message and receipt of the TCP acknowledgement.

● Packet loss: Cisco PfR measures packet loss by tracking TCP sequence numbers for each TCP flow; it tracks the highest TCP sequence number. If it receives a subsequent packet with a lower sequence number, PfR increments the packet-loss counter. Packet loss is measured in packets per million.

● Reachability: Cisco PfR measures reachability by tracking TCP synchronization messages that have been sent repeatedly without receiving a TCP acknowledgement.

● Throughput: Cisco PfR measures throughput by measuring the total number of bytes and packets for each interesting traffic class or prefix for a given interval of time.

Active monitoring metrics include the following:

● Delay: Cisco PfR measures the average delay of TCP, User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP) flows for a given traffic class or prefix.

● Reachability: Cisco PfR measures reachability by tracking TCP synchronization messages that have been sent repeatedly without a received TCP acknowledgement.

● Jitter: Cisco PfR measures jitter, or interpacket delay variance, by sending multiple packets to a target address and a specified target port number and measuring the delay interval between packets arriving at the destination.

● MOS: MOS is a standards-based method of measuring voice quality.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 6238-6243).  . Kindle Edition.




6.4.e Identify performance routing [PfR]

6.4.e [i] Basic load balancing

Cisco PfR is essentially application routing based on network performance. It automatically detects path degradation and responds to avoid continued degradation. In many cases for a multi-homed enterprise , the traffic on an initial path is routed through another egress path that can meet the application performance requirements. This routing is different from classic routing, because classic routing looks only at reachability and does not look into the required traffic service needs, such as low loss or low delay. In addition, Cisco PfR allows a multi-homed enterprise to use all available WAN or Internet links. It can track throughput, link usage, and link cost, and automatically determine the best load balancing to optimize throughput, load, and cost -and network operators define the

Cisco PfR policies that implement these adaptive routing techniques. Cisco PfR policies can be based on the following parameters:

● WAN out-bound performance (traffic exiting from an enterprise): Delay, loss, reachability, throughput, jitter, and MOS

● WAN in-bound performance (traffic arriving into an enterprise): Delay, loss, reachability, and throughput

● WAN and Internet path parameters: Reachability, throughput, load, and link usage cost

Cisco Performance Routing consists of two distinct elements: border routers and a master controller. The border routers connect enterprises to the WAN; the master controller is a software entity supported by Cisco IOS Software on a router platform . Border routers gather traffic and path information and send this information to a master controller, which places all received information into a database. The master controller is configured with the requested service policies, so it is aware of everything that happens at the network edge and can automatically detect and take action when certain parameters are out-of-policy (OOP). Delay, jitter, and packet loss are used to determine the best exit path by the PfR engine.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 6265-6266).  . Kindle Edition.



6.4.e Identify performance routing [PfR]

6.4.e [ii] Voice optimization

Voice packets traveling through an IP network are no different from data packets. In the plain old telephone system (POTS), voice traffic travels over circuit-switched networks with predetermined paths and each phone call is given a dedicated connection for the duration of the call. Voice traffic using POTS has no resource contention issues, but voice traffic over an IP network has to contend with factors such as delay, jitter, and packet loss, which can affect the quality of the phone call.


Delay (also referred as latency ) for voice packets is defined as the delay between when the packet was sent from the source device and when it arrived at a destination device. Delay can be measured as one -way delay or round-trip delay. The largest contributor to latency is caused by network transmission delay. Round-trip delay affects the dynamics of conversation and is used in Mean Opinion Score (MOS) calculations. One-way delay is used for diagnosing network problems . A caller may notice a delay of 200 milliseconds and try to speak just as the other person is replying because of packet delay. The telephone industry standard specified in ITU-T G. 114 recommends the maximum desired one-way delay be no more than 150 milliseconds. Beyond a one-way delay of 150 milliseconds , voice quality is affected. With a round-trip delay of 300 milliseconds or more, users may experience annoying talk-over effects.


Jitter means inter-packet delay variance. When multiple packets are sent consecutively from source to destination, for example , 10 ms apart, and if the network is behaving ideally , the destination should be receiving them 10 ms apart. But if there are delays in the network (like queuing, arriving through alternate routes , and so on) the arrival delay between packets might be greater than or less than 10 ms. Using this example, a positive jitter value indicates that the packets arrived more than 10 ms apart. If the packets arrive 12 ms apart, then positive jitter is 2 ms; if the packets arrive 8 ms apart, then negative jitter is 2 ms. For delay-sensitive networks like VoIP, positive jitter values are undesirable, and a jitter value of 0 is ideal.

Packet Loss

Packet loss can occur due an interface failing, a packet being routed to the wrong destination, or congestion in the network. Packet loss for voice traffic leads to the degradation of service in which a caller hears the voice sound with breaks. Although average packet loss is low, voice quality may be affected by a short series of lost packets.

Mean Opinion Score (MOS)

With all the factors affecting voice quality, many people ask how voice quality can be measured. Standards bodies like the ITU have derived two important recommendations: P. 800 (MOS) and P. 861 (Perceptual Speech Quality Measurement [PSQM]). P. 800 is concerned with defining a method to derive a Mean Opinion Score of voice quality. MOS scores range between 1 representing the worst voice quality, and 5 representing the best voice quality. A MOS of 4 is considered “toll-quality” voice.

PfR voice traffic optimization provides support for outbound optimization of voice traffic on the basis of the voice performance metrics, delay, packet loss, jitter, and MOS. Delay, packet loss, jitter and MOS are important quantitative quality metrics for voice traffic, and these voice metrics are measured using PfR active probes. The IP SLA jitter probe is integrated with PfR to measure jitter (source to destination) and the MOS score in addition to measuring delay and packet loss. The jitter probe requires a responder on the remote side just like the UDP Echo probe. Integration of the IP SLA jitter probe type in PfR enhances the ability of PfR to optimize voice traffic. PfR policies can be configured to set the threshold and priority values for the voice performance metrics: delay, packet loss, jitter, and MOS.

Configuring a PfR policy to measure jitter involves configuring only the threshold value and not relative changes (used by other PfR features) because for voice traffic, relative jitter changes have no meaning. For example, jitter changes from 5 milliseconds to 25 milliseconds are just as bad in terms of voice quality as jitter changes from 15 milliseconds to 25 milliseconds. If the short-term average (measuring the last 5 probes) jitter is higher than the jitter threshold, the prefix is considered out-of-policy due to jitter. PfR then probes all exits, and the exit with the least jitter is selected as the best exit. MOS policy works in a different way. There is no meaning to average MOS values, but there is meaning to the number of times that the MOS value is below the MOS threshold. For example, if the MOS threshold is set to 3.85 and if 3 out of 10 MOS measurements are below the 3.85 MOS threshold, the MOS-low-count is 30 percent. In the output of the show commands the field, ActPMOS, shows the number of actively monitored MOS packets with a percentage below threshold. If some of the MOS measurements are only slightly below the threshold, with percentage rounding, an ActPMOS value of zero may be displayed. When PfR runs a policy configured to measure MOS, both the MOS threshold value and the MOS-low-count percentage are considered. A prefix is considered out-of-policy if the short term (average over the last 5 probes ) MOS-low-count percentage is greater than the configured MOS-low-count percentage . PfR then probes all exits, and the exit with the highest MOS value is selected as the best exit.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 6310-6315).  . Kindle Edition.


6.4.d Implement and troubleshoot embedded event manager

6.4.d [i] EEM policy using applet

An EEM applet is a concise method for defining event screening criteria and the actions to be taken when that event occurs. In applet configuration mode, three types of configuration statements are supported. The event commands are used to specify the event criteria to trigger the applet to run, the action commands are used to specify an action to perform when the EEM applet is triggered, and the set command is used to set the value of an EEM applet variable. Currently only the _exit_status variable is supported for the set command when you use the sync option. Only one event configuration command is allowed within an applet configuration. When applet configuration mode is exited and no event command is present, a warning is displayed stating that no event is associated with this applet. If no event is specified, this applet is not considered registered. When no action is associated with this applet , events are still triggered but no actions are performed. Multiple action configuration commands are allowed within an applet configuration . Use the show event manager policy registered command to display a list of registered applets.

Before modifying an EEM applet, be aware that the existing applet is not replaced until you exit applet configuration mode. While you are in applet configuration mode modifying the applet, the existing applet may be executing. It is safe to modify the applet without unregistering it. When you exit applet configuration mode, the old applet is unregistered and the new version is registered.

The action configuration commands are uniquely identified using the label argument, which can be any string value. Actions are sorted in ascending alphanumeric key sequence using the label argument as the sort key, and they are run using this sequence. The Embedded Event Manager schedules and runs policies on the basis of an event specification that is contained within the policy itself. When applet configuration mode is exited, EEM examines the event and action commands that are entered and registers the applet to be run when a specified event occurs.

event manager applet applet-name

Above command registers the applet with the EEM and takes you to applet configuration mode for configuration of event criteria when there is a matching syslog message. The applet-name can be any case-sensitive alphanumeric string up to 29 characters.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 6197-6205).  . Kindle Edition.