-
Cisco IOS Optimized Edge Routing Configuration Guide, Release 12.4
-
Cisco IOS Optimized Edge Routing Roadmap
-
Cisco IOS Optimized Edge Routing Overview
-
Setting Up OER Network Components
-
Using OER to Profile the Traffic Classes
-
Measuring the Traffic Class Performance and Link Utilization Using OER
-
Configuring and Applying OER Policies
-
Using OER to Control Traffic Classes and Verify the Route Control Changes
-
OER Voice Traffic Optimization Using Active Probes
-
Configuring VPN IPsec/GRE Tunnel Interfaces As OER-Managed Exit Links
-
Table Of Contents
Measuring the Traffic Class Performance and Link Utilization Using OER
Prerequisites for Measuring the Traffic Class Performance and Link Utilization Using OER
Information About Measuring the Traffic Class Performance and Link Utilization Using OER
OER Traffic Class Performance Measurement
OER Link Utilization Measurement
How to Measure the Traffic Class Performance and Link Utilization Using OER
Modifying the OER Link Utilization for Outbound Traffic
Modifying the OER Link Utilization for Inbound Traffic
Modifying the OER Exit Link Utilization Range
Modifying the OER Entrance Link Utilization Range
Configuring and Verifying OER Passive Monitoring
Configuring OER Active Probing Using the Longest Match Target Assignment
OER Active Probing Target Reachability
Configuring OER Voice Probes with a Forced Target Assignment
Configuring OER Voice Probes for Fast Failover
Configuring Exit Link Load Balancing Using OER
Configuring the Source Address of an Active Probe
Configuration Examples for Measuring the Traffic Class Performance and Link Utilization Using OER
Modifying the OER Link Utilization for Outbound Traffic: Example
Modifying the OER Link Utilization for Inbound Traffic: Example
Modifying the OER Exit Link Utilization Range: Example
Modifying the OER Entrance Link Utilization Range: Example
Configuring OER Active Probing Using the Longest Match Target Assignment: Examples
ICMP Probe for Longest Match Target Assignment
TCP Probe for Longest Match Target Assignment
UDP Probe for Longest Match Target Assignment
Configuring Active Probing with a Forced Target Assignment: Examples
UDP Probe for Forced Target Assignment
Jitter Probe for Forced Target Assignment
Configuring OER Voice Probes for Fast Failover: Example
Configuring the Source Address of an Active Probe: Example
Feature Information for Measuring the Traffic Class Performance and Link Utilization Using OER
Measuring the Traffic Class Performance and Link Utilization Using OER
First Published: January 29, 2007Last Updated: October 8, 2009This module describes the Cisco IOS Optimized Edge Routing (OER) measure phase, which is the second step in the OER performance loop. In the measure phase, OER monitors the performance metrics of the traffic class entries that were identified during the OER profile phase. OER also monitors the link utilization in the measure phase. Monitoring is the act of measurement and comparison against a threshold to determine the occurrence of an out-of-policy (OOP) event. OER uses two types of measurement; active and passive monitoring.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Measuring the Traffic Class Performance and Link Utilization Using OER" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Measuring the Traffic Class Performance and Link Utilization Using OER
•
•
•
•
Prerequisites for Measuring the Traffic Class Performance and Link Utilization Using OER
•
•
Information About Measuring the Traffic Class Performance and Link Utilization Using OER
To configure traffic class performance monitoring on a master controller, you should understand the following concepts:
•
•
OER Measure Phase
The OER measure phase is the second step in the OER performance loop and it follows the OER profile phase where the traffic class entries fill the Monitored Traffic Class (MTC) list. The MTC list is now full of traffic class entries and OER must measure the performance metrics of these traffic class entries. Monitoring is defined here as the act of measurement performed periodically over a set interval of time where the measurements are compared against a threshold. OER measures the performance of traffic classes using active and passive monitoring techniques but it also measures, by default, the utilization of links. The master controller can be configured to monitor learned and configured traffic classes. The border routers collect passive monitoring and active monitoring statistics and then transmit this information to the master controller. The OER measure phase is complete when each traffic class entry in the MTC list has associated performance metric measurements.
The overall structure of the OER measure phase and its component parts can be seen in Figure 1.
Figure 1 OER Performance Measuring Process
OER measures the performance of both traffic classes and links, but before monitoring a traffic class or link OER checks the state of the traffic class or link. OER uses a policy decision point (PDP) that operates according to the traffic class state transition diagram shown in Figure 2. In some states, OER does not initiate monitoring. The state transition diagram in Figure 2 contains the following states:
•
•
•
Figure 2 OER Traffic Class State Transition Diagram
•
•
After determining the state of the traffic class or link, OER may initiate one of the following performance measuring processes:
•
•
OER Traffic Class Performance Measurement
OER uses three methods of traffic class performance measurement:
•
•
•
In Cisco IOS Release 12.4(15)T, another variation of the combined active and passive monitoring modes was introduced—fast failover monitoring mode. In fast failover monitoring mode, all exits are continuously probed using active monitoring and passive monitoring. When fast failover monitoring mode is enabled, the probe frequency can be set to a lower frequency than for other monitoring modes, to allow a faster failover capability.
No explicit NetFlow or IP SLAs configuration is required and support for NetFlow and IP SLAs is enabled automatically. You can use both active and passive monitoring methods for a traffic class.
After the master controller is defined and OER functionality is enabled, the master controller uses both passive and active monitoring by default. All traffic classes are passively monitored using integrated NetFlow functionality. Out-of-policy traffic classes are actively monitored using IP SLA functionality. You can configure the master controller to use only passive monitoring, active monitoring, both passive and active monitoring, or fast failover monitoring. The main differences between the different modes can be seen in Table 1.
In Cisco IOS Release 12.2(33)SXH support for using a Cisco Catalyst 6500 series switch as an OER border router was introduced. In Cisco IOS Release 12.2(33)SRB support for using a Cisco 7600 series router as an OER border router was introduced. The master controller that communicates with the Cisco Catalyst 6500 switch or a Cisco 7600 series router being used as a border router must be a router running Cisco IOS Release 12.4(6)T or a later release because a special monitoring mode was introduced to support the limited capabilities for collecting passive statistics on the Catalyst 6500. The special mode is set globally and cannot be configured using the command-line interface (CLI). For more details, see the "OER Special Monitoring" section.
For more details about each of the monitoring methods, see the following concepts:
OER Passive Monitoring
Cisco IOS OER uses NetFlow, an integrated technology in Cisco IOS software, to collect and aggregate passive monitoring statistics on a per traffic class basis. Passive monitoring is enabled along with active monitoring by default when an OER managed network is created. Passive monitoring can also be enabled explicitly using the mode monitor passive command. Netflow is a flow-based monitoring and accounting system, and NetFlow support is enabled by default on the border routers when passive monitoring is enabled.
Passive monitoring uses only existing traffic; additional traffic is not generated. Border routers collect and report passive monitoring statistics to the master controller approximately once per minute. If traffic does not go over an external interface of a border router, no data is reported to the master controller. Threshold comparison is done at the master controller. In Cisco IOS Release 12.4(6)T, passive monitoring is supported only for prefixes. In Cisco IOS Release 12.4(9)T, and later releases, passive monitoring supports traffic classes defined by prefix, port, protocol, and DSCP value.
OER uses passive monitoring to measure the following metrics for all the traffic classes:
•
•
•
•
Note
Passive monitoring of application traffic was introduced in Cisco IOS Release 12.4(9)T, and later releases, with application traffic class configuration support of the profiling of DSCP values as well as protocol and port numbers. DSCP values, port numbers, and protocols in addition to prefixes, are all now sent to the master controller. Passive monitoring statistics are gathered and stored in a prefix history buffer that can hold a minimum of 60 minutes of information depending on whether the traffic flow is continuous. OER uses this information to determine if the prefix is in-policy based on the default or user-defined policies. No alternative path analysis is performed as the traffic for a traffic class is flowing through one transit device in the network. If the traffic class goes OOP and only passive monitoring mode is enabled, the traffic class is moved to another point and the measurement repeated until a good or best exit is found. If the traffic class goes OOP and both passive and active monitoring modes are enabled, active probing is executed on all the exits and a best or good exit is selected. For more details on good and best exit selections, see the "Configuring and Applying OER Policies" module.
OER Active Monitoring
If OER passive monitoring techniques create too much overhead on a network device, or the performance metrics of a traffic class cannot be measured using the OER passive monitoring mode, then OER active monitoring techniques are performed. Active monitoring involves creating a stream of synthetic traffic that replicates a traffic class as closely as possible. The performance metrics of the synthetic traffic are measured and the results are applied to the traffic class entry in the MTC list. In Cisco IOS Release 12.4(6)T, and earlier releases, active monitoring supports traffic classes defined by prefix, port, and protocol. In Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, active monitoring supports traffic classes defined by prefix, port, protocol, and DSCP value.
OER uses active monitoring to measure the following metrics for all the traffic classes:
•
•
•
•
The creation of synthetic traffic in Cisco network devices is activated through the use of Cisco IOS IP SLA probes. OER is integrated with IP SLAs functionality such that OER will use IP SLA probes to actively monitor a traffic class. When active monitoring is enabled, the master controller commands the border routers to send active probes to set of target IP addresses. The border sends probe packets to no more than five target host addresses per traffic class, and transmits the probe results to the master controller for analysis.
IP SLA Active Probe Types Used by OER
IP SLAs are an embedded feature set in Cisco IOS software and they allow you to analyze IP service levels for IP applications and services, to increase productivity, to lower operational costs, and to reduce occurrences of network congestion or outages. IP SLAs use active traffic monitoring—the generation of traffic in a continuous, reliable, and predictable manner—for measuring network performance. The accuracy of measured data is enhanced by enabling the IP SLAs Responder, available in Cisco routers, on the destination device. For more details about IP SLAs, see the Cisco IOS IP SLAs Configuration Guide.
The following types of active probes can be configured:
•
•
•
•
In Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, OER marks the probe packets with the DSCP value by default if the monitored traffic classes have the DCSP field set to a nonzero value.
Creation of Active Probe for a Traffic Class
To create an active probe for a traffic class, a probe type has to be discovered, and a probe target assigned to the traffic class. To discover a probe type, OER uses one of the following methods:
•
•
To assign a probe target for a traffic class, OER uses one of the following methods:
•
•
The active probe is sourced from the border router and transmitted through an external interface (the external interface may, or may not, be the preferred route for an optimized prefix). When creating an active probe through an external interface for a specified target, the target should be reachable through the external interface. To test the reachability of the specified target, OER performs a route lookup in the BGP and static routing tables for the specified target and external interface. In Cisco IOS Release 12.4(24)T, Protocol Independent Route Optimization (PIRO) introduced the ability of OER to search for a parent route—an exact matching route, or a less specific route—in any IP Routing Information Base (RIB). The BGP routing table is searched first, followed by the static routing table, and finally the RIB.
In active monitoring mode, the probes are activated from all the border routers to find the best performance path for the specific traffic class. The active probes for that traffic class are not activated again unless the traffic class goes OOP.
In Cisco IOS Release 12.4(4)T and earlier releases, the frequency of an active probe used by OER was set to 60 seconds. In Cisco IOS Release 12.4(6)T and 12.2(33)SRB the frequency can be increased for each policy by configuring a lower time-interval between two probes. Increased probe frequency can reduce the response time and, for voice traffic, provide a better approximation of the MOS-low count percentage.
OER Active Probe Source Address
Support for the ability to configure an OER active probe source address was introduced in Cisco IOS Release 12.4(2)T and 12.2(33)SRB. By default, active probes use the source IP address of the OER external interface that transmits the probe. The active probe source address feature is configured on the border router. When this command is configured, the primary IP address of the specified interface is used as the active probe source. The active probe source interface IP address must be unique to ensure that the probe reply is routed back to the specified source interface. If the interface is not configured with an IP address, the active probe will not be generated. If the IP address is changed after the interface has been configured as an active probe source, active probing is stopped, and then restarted with the new IP address. If the IP address is removed after the interface has been configured as an active probe source, active probing is stopped and not restarted until a valid primary IP address is configured.
OER Voice Traffic Optimization Using Active Probes
In Cisco IOS Release 12.4(6)T support was introduced for outbound optimization of voice traffic using active probes on the basis of voice metrics such as delay, reachability, jitter, and Mean Opinion Score (MOS).
OER voice traffic optimization provides support for outbound optimization of voice traffic on the basis of the voice performance metrics such as delay, reachability, jitter, and MOS. Delay, reachability, jitter and MOS are important quantitative quality metrics for voice traffic, and these voice metrics are measured using OER active probes. In Cisco IOS Release 12.4(4)T and earlier releases, OER probes could measure delay and reachability, but not jitter and MOS. The IP SLA jitter probe is integrated with OER to measure jitter (source to destination) and the MOS score in addition to measuring delay and reachability. 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 OER enhances the ability of OER to optimize voice traffic. OER policies can be configured to set the threshold and priority values for the voice performance metrics: delay, reachability, jitter, and MOS.
Configuring an OER policy to measure jitter involves configuring only the threshold value and not relative changes (used by other OER 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 minutes) jitter is higher than the jitter threshold, the prefix is considered out-of-policy due to jitter. OER 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. When OER 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 (during the last 5 minutes) MOS-low-count percentage is greater than the configured value for a given MOS threshold. OER then probes all exits, and the exit with the highest MOS value is selected as the best exit.
OER Combined Monitoring
Cisco IOS OER can also be configured to combine both active and passive monitoring in order to generate a more complete picture of traffic flows within the network. There are some scenarios in which you may want to combine both OER monitoring modes.
One example scenario is when you want to learn traffic classes and then monitor them passively, but you also want to determine the alternate path performance metrics in order to control the traffic classes. The alternate path performance metrics, in the absence of the actual traffic flowing through the alternate path in the network, can be measured using the active probes. OER automates this process by learning traffic classes at five targets and probing through all the alternate paths using active probes.
OER Fast Failover Monitoring
In Cisco IOS Release 12.4(15)T, a new monitoring mode, fast monitoring, was introduced. Fast monitoring sets the active probes to continuously monitor all the exits (probe-all), and passive monitoring is enabled too. Fast failover monitoring can be used with all types of active probes: ICMP echo, Jitter, TCP connection, and UDP echo. When the mode monitor fast command is enabled, the probe frequency can be set to a lower frequency than for other monitoring modes, to allow a faster failover ability. Under fast monitoring with a lower probe frequency, route changes can be performed within 3 seconds of an out-of-policy situation. When an exit becomes OOP under fast monitoring, the select best exit is operational and the routes from the OOP exit are moved to the best in-policy exit. 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. For example, a voice call is very sensitive to any performance problems or congested links, but the ability to detect and reroute the call within a few seconds can demonstrate the value of using fast monitoring mode.
OER Special Monitoring
In Cisco IOS Release 12.2(33)SXH support for using a Cisco Catalyst 6500 series switch as an OER border router was introduced. In Cisco IOS Release 12.2(33)SRB support for using a Cisco 7600 series router as an OER border router was introduced. Only border router functionality is included in the Cisco IOS Release 12.2(33)SXH and 12.2(33)SRB images; no master controller configuration is available. The master controller that communicates with the Cisco Catalyst 6500 series switch or a Cisco 7600 series router being used as a border router must be a router running Cisco IOS Release 12.4(6)T or a later release.
In Cisco IOS Release 12.4(6)T the OER master controller software was modified to support the limited capabilities for collecting passive statistics on a Cisco Catalyst 6500 switch or a Cisco 7600 series router used as a border router. If mode monitor active is configured on the master controller, no changes are made. If mode monitor passive or mode monitor both is configured, the master controller sends commands to each border router to determine if the border router can activate passive monitoring. If the master controller has mode monitor passive configured, and a Cisco Catalyst 6500 series switch or a Cisco 7600 series router is being used as a border router, the master controller changes the mode to a special mode because it cannot activate passive monitoring. If mode monitor both is configured on the master controller and at least one border router cannot activate passive monitoring then the master controller changes the mode to a special mode. The special mode is set globally and cannot be configured using the command-line interface (CLI). In the special mode only a subset of passive performance metrics—the ingress and egress bandwidth—are evaluated for a traffic class. Active monitoring at regular intervals using a periodic timer supplies the delay and reachability statistics.
When the special monitoring mode is set, the PDP—OER uses a policy decision point (PDP) that operates according to the traffic class state transition diagram shown in Figure 2—examines probing results for delay and unreachability statistics when measuring the performance of a traffic class. Bandwidth calculations are considered, but loss is not supported.
OER Link Utilization Measurement
Link Utilization Threshold
After an external interface is configured for a border router, OER automatically monitors the utilization of the external link (an external link is an interface on a border router that typically links to a WAN). Every 20 seconds, by default, the border router reports the link utilization to the master controller. In Cisco IOS Release 12.4(6)T and prior releases, only egress (transmitted) traffic utilization values were reported, but in Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, the ingress (received) traffic utilization values are also reported to the master controller. If the exit or entrance link utilization is above the default threshold of 75 percent, the exit or entrance link is in an OOP state and OER starts the monitoring process to find an alternative link for the traffic class. The link utilization threshold can be manually configured either as an absolute value in kilobytes per second (kbps) or as a percentage.
Link Utilization Range
OER can also be configured to calculate the range of utilization over all the links. In Cisco IOS Release 12.4(6)T and prior releases, only egress (transmitted) traffic utilization range values were reported, but in Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, the ingress (received) traffic utilization range values are also reported to the master controller. In Figure 3 there are two border routers with exits links to the Internet through two ISPs. The master controller determines which link on one of the border routers—either BR1 or BR2 in Figure 3—is used by a traffic class.
Figure 3 OER network diagram
OER range functionality attempts to keep the exit or entrance links within a utilization range, relative to each other to ensure that the traffic load is distributed. The range is specified as a percentage and is configured on the master controller to apply to all the exit or entrance links on border routers managed by the master controller. For example, if the range is specified as 25 percent, and the utilization of the exit link at BR1 (in Figure 3) is 70 percent, then if the utilization of the exit link at BR2 (in Figure 3) falls to 40 percent, the percentage range between the two exit links will be more than 25 percent and OER will attempt to move some traffic classes to use the exit link at BR1 to even the traffic load. If BR1 (in Figure 3) is being configured as an entrance link, the link utilization range calculations work in the same way as for an exit link, except that the utilization values are for received traffic, not transmitted traffic.
How to Measure the Traffic Class Performance and Link Utilization Using OER
This section contains the following tasks:
•
•
•
•
•
•
•
•
•
•
Modifying the OER Link Utilization for Outbound Traffic
Perform this task at the master controller to modify the OER exit (outbound) link utilization threshold. After an external interface has been configured for a border router, OER automatically monitors the utilization of external links on a border router every 20 seconds. The utilization is reported back to the master controller and, if the utilization exceeds 75 percent, OER selects another exit link for traffic classes on that link. An absolute value in kilobytes per second (kbps), or a percentage, can be specified.
To modify the link utilization threshold for inbound traffic, see the "Modifying the OER Link Utilization for Inbound Traffic" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
oer master
Example:Router(config)# oer master
Enters OER master controller configuration mode to configure a router as a master controller and to configure global operations and policies.
Step 4
border ip-address [key-chain key-chain-name]
Example:Router(config-oer-mc)# border 10.1.1.2
Enters OER-managed border router configuration mode to establish communication with a border router.
•
•
Note
Step 5
interface type number external
Example:Router(config-oer-mc-br)# interface Ethernet 1/0 external
Configures a border router interface as an OER-managed external interface and enters OER border exit interface configuration mode.
•
•
Note
Only the syntax relevant to this task is displayed. For more details, see the Cisco IOS Optimized Edge Routing Command Reference.
Step 6
max-xmit-utilization {absolute kbps | percentage value
Example:Router(config-oer-mc-br-if)# max-xmit-utilization absolute 500000
Configures the maximum utilization on a single OER managed exit link.
•
•
Step 7
end
Example:Router(config-oer-mc-br-if)# end
Exits OER border exit interface configuration mode and returns to privileged EXEC mode.
Modifying the OER Link Utilization for Inbound Traffic
In Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, the ability to report inbound traffic utilization to the master controller was introduced. Perform this task at the master controller to modify the OER entrance (inbound) link utilization threshold. After an external interface has been configured for a border router, OER automatically monitors the utilization of entrance links on a border router every 20 seconds. The utilization is reported back to the master controller and, if the utilization exceeds 75 percent, OER selects another entrance link for traffic classes on that link. An absolute value in kilobytes per second (kbps), or a percentage, can be specified. This task is configured in the same way as the "Modifying the OER Link Utilization for Outbound Traffic" section as an external interface can be used as either an exit link or an entrance link. The difference in the configuration for this task is the command that specifies the utilization threshold for inbound traffic.
Prerequisites
This task requires the master controller and border routers to be running Cisco IOS Release 12.4(9)T, 12.2(33)SRB, or later release.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
oer master
Example:Router(config)# oer master
Enters OER master controller configuration mode to configure a router as a master controller and to configure global operations and policies.
Step 4
border ip-address [key-chain key-chain-name]
Example:Router(config-oer-mc)# border 10.1.1.2
Enters OER-managed border router configuration mode to establish communication with a border router.
•
•
Note
Step 5
interface type number external
Example:Router(config-oer-mc-br)# interface Ethernet 1/0 external
Configures a border router interface as an OER-managed external interface and enters OER border exit interface configuration mode.
•
•
Note
Only the syntax relevant to this task is displayed. For more details, see the Cisco IOS Optimized Edge Routing Command Reference.
Step 6
maximum utilization receive {absolute kbps | percent percentage}
Example:Router(config-oer-mc-br-if)# maximum utilization receive percent 90
Sets the maximum receive utilization threshold for the configured OER-managed link interface.
•
•
•
Step 7
end
Example:Router(config-oer-mc-br-if)# end
Exits OER border exit interface configuration mode and returns to privileged EXEC mode.
Modifying the OER Exit Link Utilization Range
Perform this task at the master controller to modify the maximum exit link utilization range threshold over all the border routers. By default, OER automatically monitors the utilization of external links on a border router every 20 seconds, and the border router reports the utilization to the master controller. If the utilization range between all the exit links exceeds 20 percent, the master controller tries to equalize the traffic load by moving some traffic classes to another exit link. The maximum utilization range is configured as a percentage.
OER uses the maximum utilization range to determine if exit links are in-policy. OER will equalize outbound traffic across all exit links by moving traffic classes from overutilized or out-of-policy exits to in-policy exits.
To modify the link utilization range for entrance links, see the "Modifying the OER Entrance Link Utilization Range" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Modifying the OER Entrance Link Utilization Range
Perform this task at the master controller to modify the maximum entrance link utilization range over all the border routers. By default, OER automatically monitors the utilization of external links on a border router every 20 seconds, and the border router reports the utilization to the master controller. In Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, the ability to report inbound traffic utilization to the master controller, and to specify a link utilization range for entrance links, was introduced. In this task, if the utilization range between all the entrance links exceeds 20 percent, the master controller tries to equalize the traffic load by moving some traffic classes to another entrance link. The maximum utilization range is configured as a percentage.
OER uses the maximum utilization range to determine if links are in-policy. In this task, OER will equalize inbound traffic across all entrance links by moving traffic classes from overutilized or out-of-policy exits to in-policy exits.
Prerequisites
This task requires the master controller and border routers to be running Cisco IOS Release 12.4(9)T, 12.2(33)SRB, or later release.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring and Verifying OER Passive Monitoring
OER enables passive monitoring by default when an OER managed network is created, but there are times when passive monitoring is disabled. Use this task to configure passive monitoring and then verify that the passive monitoring is being performed. Perform this task on a border router to display passive measurement information collected by NetFlow for monitored prefixes or application traffic flows. These commands are entered on a border router through which the application traffic is flowing. The show commands can be entered in any order.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Step 1
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 2
Enters global configuration mode.
Router# configure terminalStep 3
Enters OER master controller configuration mode to configure a router as a master controller and to configure global operations and policies.
Router(config)# oer masterStep 4
Configures route monitoring or route control on an OER master controller. The monitor keyword is used to configure active monitoring, passive monitoring, or both active and passive monitoring. Passive monitoring is enabled when either the both or passive keywords are specified. In this example, passive monitoring is enabled.
Note
Router(config-oer-mc)# mode monitor passiveStep 5
Exits OER master controller configuration mode and returns to privileged EXEC mode.
Router(config-oer-mc)# endStep 6
This command is used to display real-time passive measurement information collected by NetFlow from the border router for OER monitored prefixes and traffic flows. The applications keyword displays information about the monitored application traffic classes, and the prefix keyword displays information about monitored prefixes. Using the learned and application keywords you can display information about learned applications. The following output shows the passive measurement information collected by NetFlow for monitored prefixes and traffic flows for the border router on which the show oer border passive cache prefix command was run:
Router# show oer border passive cache prefixOER Passive Prefix Cache, State: enabled, 278544 bytes1 active, 4095 inactive, 2 added82 ager polls, 0 flow alloc failuresActive flows timeout in 1 minutesInactive flows timeout in 15 secondsIP Sub Flow Cache, 17416 bytes2 active, 1022 inactive, 4 added, 2 added to flow0 alloc failures, 0 force free1 chunk, 2 chunks addedPrefix NextHop Src If Dst IfFlows Pkts B/Pk Active sDly #Dly PktLos #UnRch------------------------------------------------------------------------------10.1.5.0/24 10.1.2.2 Et0/0 Et1/0381 527 40 65.5 300 2 10 1The following output shows the passive measurement information collected by NetFlow for monitored application traffic flows for the border router on which the show oer border passive cache applications command was run:
Router# show oer border passive cache applicationsOER Passive Prefix Cache, State: enabled, 278544 bytes6 active, 4090 inactive, 384 added6438 ager polls, 0 flow alloc failuresActive flows timeout in 1 minutesInactive flows timeout in 15 secondsIP Sub Flow Cache, 25800 bytes18 active, 1006 inactive, 1152 added, 384 added to flow0 alloc failures, 0 force free1 chunk, 1 chunk addedPrefix NextHop Src If Dst If FlowsProt DSCP SrcPort DstPort Appl_IDPkts B/Pk Active sDly #Dly PktLos #UnRch------------------------------------------------------------------------10.1.1.0/24 10.1.1.2 Et8/0 Et0/0 117 ef [1, 65535] [3000, 4000] 22 28 16.5 0 0 0 010.1.3.0/24 10.1.1.2 Et8/0 Et0/0 117 ef [1, 65535] [3000, 4000] 116 28 19.9 0 0 0 0Step 7
This command is used to display passive measurement information collected by NetFlow for OER monitored prefixes and traffic flows. The following output shows the prefix that is being passively monitored by NetFlow for the border router on which the show oer border passive prefixes command was run:
Router# show oer border passive prefixesOER Passive monitored prefixes:Prefix Mask Match Type10.1.5.0 /24 exact
Configuring OER Active Probing Using the Longest Match Target Assignment
Perform this task at the master controller to configure active probing using the longest match target assignment. Active monitoring is enabled with the mode monitor active or mode monitor both commands, and the type of active probe is specified using the active-probe command. Active probes are configured with a specific host or target address and the active probes are sourced on the border router. The active probe source external interface may, or may not, be the preferred route for an optimized prefix. In this example, both active and passive monitoring are enabled and the target IP address of 10.1.5.1 is to be actively monitored using Internet Control Message Protocol (ICMP) echo (ping) messages. This task does not require an IP SLA responder to be enabled.
OER Active Probing Target Reachability
The active probe is sourced from the border router and transmitted through an external interface (the external interface may or may not be the preferred route for an optimized prefix). When creating an active probe through an external interface for a specified target, the target should be reachable through the external interface. To test the reachability of the specified target, OER performs a route lookup in the BGP and static routing tables for the specified target and external interface.
ICMP Echo Probes
Configuring an ICMP echo probe does not require knowledgeable cooperation from the target device. However, repeated probing could trigger an IDS alarm in the target network. If an IDS is configured in a target network that is not under your administrative control, we recommend that you notify the target network administration entity.
The following defaults are applied when active monitoring is enabled:
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
oer master
Example:Router(config)# oer master
Enters OER master controller configuration mode to configure a router as a master controller and to configure global operations and policies.
Step 4
mode monitor {active | both | passive}
Example:Router(config-oer-mc)# mode monitor both
Configures route monitoring on an OER master controller.
•
•
Note
Step 5
active-probe {echo ip-address | tcp-conn ip-address target-port number | udp-echo ip-address target-port number}
Example:Router(config-oer-mc)# active-probe echo 10.1.5.1
Configures an active probe for a target prefix.
•
•
•
•
Note
Step 6
end
Example:Router(config-oer-mc)# end
Exits OER master controller configuration mode and returns to privileged EXEC mode.
Configuring OER Voice Probes with a Forced Target Assignment
Perform this task to enable active monitoring using OER jitter probes. Support for the jitter probe was introduced in Cisco IOS Release 12.4(6)T and 12.2(33)SRB. In this example, the traffic to be monitored is voice traffic, which is identified using an access list. The active voice probes are assigned a forced target for OER instead of the usual longest match assigned target. This task also demonstrates how to modify the OER probe frequency, another feature added in Cisco IOS Release 12.4(6)T and 12.2(33)SRB.
Before configuring the OER jitter probe on the source device, the IP SLAs Responder must be enabled on the target device (the operational target). The IP SLAs Responder is available only on Cisco IOS software-based devices. Start this task at the network device that runs the IP SLAs Responder.
Note
Prerequisites
This task requires the master controller and border routers to be running Cisco IOS Release 12.4(6)T, 12.2(33)SRB, or later releases.
Jitter
Jitter means interpacket 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.
MOS
Mean Opinion Score (MOS) is a quantitative quality metric for voice traffic that can be measured using OER active probes. 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.
Prerequisites
Before configuring this task, an access list must be defined. For an example access list and more details about configuring voice traffic using active probes, see the "OER Voice Traffic Optimization Using Active Probes" solution module.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
ip sla monitor responder
Example:Router(config)# ip sla monitor responder
Enables the IP SLAs Responder.
Step 4
exit
Example:Router(config)# exit
Exits global configuration mode and returns to privileged EXEC mode.
Step 5
Move to the network device that is the OER master controller.
—
Step 6
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 7
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 8
oer master
Example:Router(config)# oer master
Enters OER master controller configuration mode to configure a router as a master controller and to configure global operations and policies.
Step 9
mode monitor {active | both | passive}
Example:Router(config-oer-mc)# mode monitor active
Configures route monitoring on an OER master controller.
•
•
Note
Step 10
exit
Example:Router(config-oer-mc)# exit
Exits OER master controller configuration mode and returns to global configuration .
Step 11
oer-map map-name sequence-number
Example:Router(config)# oer-map TARGET_MAP 10
Enters OER map configuration mode to configure an OER map to apply policies to selected IP prefixes.
•
•
•
Step 12
match ip address {access-list access-list-name | prefix-list prefix-list-name}
Example:Router(config-oer-map)# match ip address access-list VOICE_ACCESS_LIST
References an extended IP access list or IP prefix as match criteria in an OER map.
•
•
Step 13
set active-probe probe-type ip-address [target-port number] [codec codec-name]
Example:Router(config-oer-map)# set active-probe jitter 10.20.22.1 target-port 2000 codec g729a
Creates a set clause entry to assign a target prefix for an active probe.
•
•
•
•
•
Step 14
set probe frequency seconds
Example:Router(config-oer-map)# set probe frequency 10
Creates a set clause entry to set the frequency of the OER active probe.
•
•
Step 15
set jitter threshold maximum
Example:Router(config-oer-map)# set jitter threshold 20
Creates a set clause entry to configure the jitter threshold value.
•
•
Step 16
set mos {threshold minimum percent percent}
Example:Router(config-oer-map)# set mos threshold 4.0 percent 30
Creates a set clause entry to configure the MOS threshold and percentage values used to decide whether an alternate exit is be selected.
•
•
•
•
Step 17
set delay {relative percentage | threshold maximum}
Example:Router(config-oer-map)# set delay threshold 100
Creates a set clause entry to configure the delay threshold.
•
•
•
•
Step 18
end
Example:Router(config-oer-map)# end
Exits OER map configuration mode and enters privileged EXEC mode.
Step 19
show oer master active-probes [appl | forced]
Example:Router# show oer master active-probes forced
Displays connection and status information about active probes on an OER master controller.
•
•
•
•
Examples
This example shows output from the show oer master active-probes forced command. The output is filtered to display only connection and status information about the active probes generated for voice traffic configured with a forced target assignment.
Router# show oer master active-probes forcedOER Master Controller active-probesBorder = Border Router running this ProbePolicy = Forced target is configure under this policyType = Probe TypeTarget = Target AddressTPort = Target PortN - Not applicableThe following Forced Probes are running:Border State Policy Type Target TPort10.20.20.2 ACTIVE 40 jitter 10.20.22.1 305010.20.21.3 ACTIVE 40 jitter 10.20.22.4 3050Configuring OER Voice Probes for Fast Failover
In Cisco IOS Release 12.4(15)T the ability to configure a fast monitoring mode was introduced. In fast failover monitoring mode, all exits are continuously probed using active monitoring and passive monitoring. The probe frequency can be set to a lower frequency in fast failover monitoring mode than for other monitoring modes, to allow a faster failover capability. Fast failover monitoring can be used with all types of active probes: ICMP echo, jitter, TCP connection, and UDP echo.
Perform this task to enable fast monitoring using OER jitter probes. Fast failover monitoring is designed for traffic classes that are very sensitive to performance issues or congested links, and voice traffic is very sensitive to any dropped links. In this example, the fast failover monitoring mode is enabled and the voice traffic to be monitored is identified using an IP prefix list. To reduce some of the overhead that fast failover monitoring produces, the active voice probes are assigned a forced target for OER. The OER probe frequency is set to 2 seconds. In the examples section after the task table, the show oer master prefix command is used to show the policy configuration for the prefix specified in the task steps and some logging output is displayed to show that fast failover is configured.
Note
Before configuring the OER jitter probe on the source device, the IP SLAs Responder must be enabled on the target device (the operational target). The IP SLAs Responder is available only on Cisco IOS software-based devices. Start this task at the network device that runs the IP SLAs Responder.
Note
Prerequisites
This task requires the master controller and border routers to be running Cisco IOS Release 12.4(15)T, or later releases.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
ip sla monitor responder
Example:Router(config)# ip sla monitor responder
Enables the IP SLAs Responder.
Step 4
exit
Example:Router(config)# exit
Exits global configuration mode and returns to privileged EXEC mode.
Step 5
Move to the network device that is the OER master controller.
—
Step 6
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 7
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 8
ip prefix-list list-name [seq seq-value] {deny network/length | permit network/length} [le le-value]
Example:Router(config)# ip prefix-list VOICE_FAIL_LIST permit 10.1.0.0/24
Creates an IP prefix list.
•
•
Step 9
Repeat Step 4 for more prefix list entries, as required.
—
Step 10
oer-map map-name sequence-number
Example:Router(config)# oer-map FAST_FAIL_MAP 10
Enters OER map configuration mode to configure an OER map to apply policies to selected IP prefixes.
•
•
Step 11
match traffic-class prefix-list prefix-list-name
Example:Router(config-oer-map)# match traffic-class prefix-list VOICE_FAIL_LIST
References an IP prefix list as traffic class match criteria in an OER map.
•
•
Step 12
set mode monitor {active | both | fast | passive}
Example:Router(config-oer-map)# set mode monitor fast
Creates a set clause entry to configure route monitoring on an OER master controller.
•
•
•
Note
Step 13
set jitter threshold maximum
Example:Router(config-oer-map)# set jitter threshold 12
Creates a set clause entry to configure the jitter threshold value.
•
•
Step 14
set mos {threshold minimum percent percent}
Example:Router(config-oer-map)# set mos threshold 3.6 percent 30
Creates a set clause entry to configure the MOS threshold and percentage values used to decide whether an alternate exit is be selected.
•
•
•
•
Step 15
set delay {relative percentage | threshold maximum}
Example:Router(config-oer-map)# set delay relative 50
Creates a set clause entry to configure the delay threshold.
•
•
•
•
Step 16
set active-probe probe-type ip-address [target-port number] [codec codec-name]
Example:Router(config-oer-map)# set active-probe jitter 10.120.120.1 target-port 20 codec g729a
Creates a set clause entry to assign a target prefix for an active probe.
•
•
•
•
•
Step 17
set probe frequency seconds
Example:Router(config-oer-map)# set probe frequency 2
Creates a set clause entry to set the frequency of the OER active probe.
•
•
Note
Step 18
end
Example:Router(config-oer-map)# end
Exits OER map configuration mode and enters privileged EXEC mode.
Step 19
show oer master prefix [prefix [detail | policy | traceroute [exit-id | border-address | current]]]
Example:Router# show oer master prefix 10.1.1.0/24 policy
(Optional) Displays the status of monitored prefixes.
•
•
•
Note
Examples
This example shows output from the show oer master prefix command when a prefix is specified with the policy keyword to display 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 oer master prefix 10.1.1.0/24 policy* Overrides Default Policy Settingoer-map MAP 10sequence no. 8444249301975040, provider id 1, provider priority 30host priority 0, policy priority 10, Session id 0match ip prefix-lists: VOICE_FAIL_LISTbackoff 90 90 90delay relative 50holddown 90periodic 0*probe frequency 2mode route control*mode monitor fast*mode select-exit bestloss relative 10*jitter threshold 12mos threshold 3.60 percent 30unreachable relative 50next-hop not setforwarding interface not setresolve jitter priority 1 variance 10resolve utilization priority 12 variance 20Forced Assigned Target List:active-probe jitter 10.120.120.1 target-port 20 codec g729aAfter 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 is routed by OER 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/0May 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 JitterConfiguring Exit Link Load Balancing Using OER
Perform this task at the master controller to configure load balancing for traffic classes over the border router exit links. In this example, both active and passive monitoring is enabled, and range and exit utilization policies are given priority when OER chooses the best exit selection for traffic classes. Best route selection for performance policies is disabled. The external Ethernet interfaces on border router 1 and border router 2—BR1 and BR2 in Figure 4—are both configured with a maximum utilization threshold of 70 percent. After an external interface is configured for the border routers, OER automatically monitors the utilization of external links on a border router every 20 seconds. The utilization is reported back to the master controller and, if the utilization exceeds 70 percent, OER selects another exit link for traffic classes on that link.
Figure 4 Network diagram for OER Exit Link Load Balancing
Traffic can also be load balanced over entrance links, for more details see the "Using OER to Control Traffic Classes and Verify the Network Performance" module.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
oer master
Example:Router(config)# oer master
Enters OER master controller configuration mode to configure a router as a master controller and to configure global operations and policies.
Step 4
mode monitor {active | both | passive}
Example:Router(config-oer-mc)# mode monitor both
Configures route monitoring on an OER master controller.
•
•
Note
Step 5
resolve range priority value
Example:Router(config-oer-mc)# resolve range priority 1
Sets policy priority or resolves policy conflicts.
•
•
•
•
Note
Step 6
resolve utilization priority value variance percentage
Example:Router(config-oer-mc)# resolve utilization priority 2 variance 25
Sets policy priority or resolves policy conflicts.
•
•
•
•
•
Note
Step 7
no resolve delay
Example:Router(config-oer-mc)# no resolve delay
Sets policy priority or resolves policy conflicts.
•
•
Note
Step 8
no resolve loss
Example:Router(config-oer-mc)# no resolve loss
Sets policy priority or resolves policy conflicts.
•
•
Note
Step 9
border ip-address [key-chain key-chain-name]
Example:Router(config-oer-mc)# border 10.1.1.2 key-chain border1_OER
Enters OER-managed border router configuration mode to establish communication with a border router.
•
•
•
Note
Step 10
interface type number external
Example:Router(config-oer-mc-br)# interface Ethernet 1/0 external
Configures a border router interface as an OER-managed external interface.
•
•
TipNote
Step 11
max-xmit-utilization {absolute kbps | percentage value}
Example:Router(config-oer-mc-br-if)# max-xmit-utilization absolute 500000
Configures the maximum utilization on a single OER managed exit link.
•
•
Step 12
exit
Example:Router(config-oer-mc-br-if)# exit
Exits OER-managed border exit interface configuration mode and returns to OER-managed border router configuration mode.
Step 13
Repeat Step 9 through Step 12 with appropriate changes to establish communication with each border router.
—
Step 14
keepalive timer
Example:Router(config-oer-mc)# keepalive 10
(Optional) Configures the length of time that an OER master controller will maintain connectivity with an OER border router after no keepalive packets have been received.
•
Step 15
end
Example:Router(config-oer-mc)# end
Exits OER master controller configuration mode and returns to privileged EXEC mode.
Step 16
show running-config
Example:Router# show running-config
(Optional) Displays the running configuration to verify the configuration entered in this task.
Configuring the Source Address of an Active Probe
Perform this task on a border router to specify the source interface for active probing. Support for configuring a source interface for active probing was introduced in Cisco IOS Release 12.4(2)T and 12.2(33)SRB. The active probe source interface is configured on the border router with the active-probe address source in OER border router configuration mode. The active probe source interface IP address must be unique to ensure that the probe reply is routed back to the specified source interface.
The following is default behavior:
•
•
•
•
Prerequisites
This task requires the master controller and border routers to be running Cisco IOS Release 12.4(2)T, 12.2(33)SRB, or later releases.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Examples
This example shows output from the show oer border active-probes command. The output is filtered to display only connection and status information about the active probes generated for voice traffic configured with a forced target assignment.
Router# show oer border active-probesOER Border active-probesType = Probe TypeTarget = Target IP AddressTPort = Target PortSource = Send From Source IP AddressInterface = Exit interfaceAtt = Number of AttemptsComps = Number of completionsN - Not applicableType Target TPort Source Interface Att Compsudp-echo 10.4.5.1 80 10.0.0.1 FE2/0 1 0tcp-conn 10.4.7.1 33 10.0.0.1 FE0/0 1 0echo 10.4.9.1 N 10.0.0.1 FE1/0 2 2Configuration Examples for Measuring the Traffic Class Performance and Link Utilization Using OER
The examples in this section show how to configure OER to measure traffic class performance and link utilization.
•
•
•
•
•
•
•
•
Modifying the OER Link Utilization for Outbound Traffic: Example
The following example shows how to modify the OER exit link utilization threshold. In this example, the exit utilization is set to 80 percent. If the utilization for this exit link exceeds 80 percent, OER selects another exit link for traffic classes that were using this exit link.
Router(config)# oer masterRouter(config-oer-mc)# border 10.1.4.1Router(config-oer-mc-br)# interface Ethernet 1/0 externalRouter(config-oer-mc-br-if)# max-xmit-utilization percentage 80Router(config-oer-mc-br-if)# endModifying the OER Link Utilization for Inbound Traffic: Example
The following example shows how to modify the OER entrance link utilization threshold. In this example, the entrance utilization is set to 65 percent. If the utilization for this exit link exceeds 65 percent, OER selects another entrance link for traffic classes that were using this entrance link.
Router(config)# oer masterRouter(config-oer-mc)# border 10.1.2.1Router(config-oer-mc-br)# interface Ethernet 1/0 externalRouter(config-oer-mc-br-if)# maximum receive utilization percentage 65Router(config-oer-mc-br-if)# endModifying the OER Exit Link Utilization Range: Example
The following example shows how to modify the OER exit utilization range. In this example, the exit utilization range for all exit links is set to 10 percent. OER uses the maximum utilization range to determine if exit links are in-policy. OER will equalize outbound traffic across all exit links by moving prefixes from overutilized or out-of-policy exits to in-policy exits.
Router(config)# oer masterRouter(config-oer-mc)# max-range-utilization percentage 10Router(config-oer-mc)# endModifying the OER Entrance Link Utilization Range: Example
The following example shows how to modify the OER entrance utilization range. In this example, the entrance utilization range for all entrance links is set to 15 percent. OER uses the maximum utilization range to determine if entrance links are in-policy. OER will equalize inbound traffic across all entrance links by moving prefixes from overutilized or out-of-policy exits to in-policy exits.
Router(config)# oer masterRouter(config-oer-mc)# max range receive percent 15Router(config-oer-mc)# endActive Probing: Examples
ICMP Echo Example
The following example, starting in global configuration mode, configures an active probe using an ICMP echo (ping) message. The 10.5.5.55 address is the target. No explicit configuration is required on the target device.
Router(config)# oer masterRouter(config-oer-mc)# active-probe echo 10.5.5.55TCP Connection Example
The following example, starting in global configuration mode, configures an active probe using a TCP connection message. The 10.5.55.56 address is the target. The target port number must be specified when configuring this type of probe.
Router(config)# oer masterRouter(config-oer-mc)# active-probe tcp-conn 10.5.5.56 target-port 23
Note
UDP Echo Example
The following example, starting in global configuration mode, configures an active probe using UDP echo messages. The 10.5.5.57 address is the target. The target port number must be specified when configuring this type of probe, and a remote responder must also be enabled on the target device.
Router(config)# oer masterRouter(config-oer-mc)# active-probe udp-echo 10.5.5.57 target-port 1001UDP Remote Responder Example
The following example, starting in global configuration mode, configures a remote responder on a border router to send IP SLAs control packets in response to UDP active probes. The port number must match the number that is configured for the active probe.
Border-Router(config)# ip sla monitor responder type udpEcho port 1001TCP Remote Responder Example
The following example, starting in global configuration mode, configures a remote responder on a border router to send IP SLAs control packets in response to TCP active probes. The remote responder must be configured for TCP active probes that do not use the TCP well-known port number 23.
Border-Router(config)# ip sla monitor responder type tcpConnect port 49152Configuring OER Active Probing Using the Longest Match Target Assignment: Examples
The example configurations in this section demonstrate active probing using the longest match target assignment using the following probe types:
•
•
•
ICMP Probe for Longest Match Target Assignment
The following example shows how to configure active probing using the ICMP probe with the longest match target assignment:
Router(config)# oer masterRouter(config-oer-mc)# mode monitor activeRouter(config-oer-mc)# active-probe echo 10.5.5.55TCP Probe for Longest Match Target Assignment
The following example shows how to configure active probing using the TCP probe with the longest match target assignment. The IP SLAs Responder must first be enabled on the target device, and this device does not have to be configured for OER. A border router can be used as the target device. The second configuration is performed at the master controller.
Target Device
Router> enableRouter# configure terminalRouter(config)# ip sla monitor responder type tcpConnect port 49152Router(config)# exitMaster Controller
Router(config)# oer masterRouter(config-oer-mc)# mode monitor activeRouter(config-oer-mc)# active-probe tcp-conn 10.4.4.44 target-port 49152UDP Probe for Longest Match Target Assignment
The following example shows how to configure active probing using the UDP probe with the longest match target assignment. The IP SLAs Responder must first be enabled on the target device, and this device does not have to be configured for OER. A border router can be used as the target device. The second configuration is performed at the master controller.
Target Device
Router> enableRouter# configure terminalRouter(config)# ip sla monitor responder type udpEcho port 1001Router(config)# exitMaster Controller
Router(config)# oer masterRouter(config-oer-mc)# mode monitor activeRouter(config-oer-mc)# active-probe udp-echo 10.3.3.33 target-port 1001Configuring Active Probing with a Forced Target Assignment: Examples
The example configurations in this section demonstrate active probing using a forced target assignment using the following probe types:
•
•
UDP Probe for Forced Target Assignment
The following example shows how to configure active probing with a forced target assignment and a configured probe frequency of 20 seconds. This example requires an IP SLAs Responder to be enabled on the target device.
Target Device
Router> enableRouter# configure terminalRouter(config)# ip sla monitor responder type udpEcho port 1001Router(config)# exitMaster Controller
Router(config)# oer masterRouter(config-oer-mc)# mode monitor activeRouter(config-oer-mc)# exitRouter(config)# oer-map FORCED_MAP 10Router(config-oer-map)# match ip address access-list FORCED_LISTRouter(config-oer-map)# set active-probe udp-echo 10.5.5.57 target-port 1001Router(config-oer-map)# set probe frequency 20Router(config-oer-map)# endJitter Probe for Forced Target Assignment
The following example shows how to configure active probing for Voice traffic with a forced target assignment using the jitter probe and a configured probe frequency of 15 seconds. The voice traffic is identified using an access list and thresholds are set for jitter, mos, and delay. In this task, the codec keyword and codec-name argument used in the jitter probe configuration specify the codec value used for mos calculation. This example requires an IP SLAs Responder to be enabled on the target device.
Target Device
Router> enableRouter# configure terminalRouter(config)# ip sla monitor responderRouter(config)# exitMaster Controller
Router(config)# oer masterRouter(config-oer-mc)# mode monitor activeRouter(config-oer-mc)# exitRouter(config)# oer-map FORCED_VOICE_MAP 10Router(config-oer-map)# match ip address access-list FORCED_VOICE_LISTRouter(config-oer-map)# set active-probe jitter 172.17.5.57 target-port 2000 codec g729aRouter(config-oer-map)# set probe frequency 15Router(config-oer-map)# set jitter threshold 20Router(config-oer-map)# set mos threshold 4.0 percent 30Router(config-oer-map)# set delay threshold 100Router(config-oer-map)# endConfiguring OER Voice Probes for Fast Failover: Example
The following example, starting in global configuration mode, shows how quickly a new exit can be selected when fast failover is configured.
Note
The first output shows the configuration at the master controller of three border routers. Route control mode is enabled.
Router# show run | sec oer masteroer masterpolicy-rules MAPport 7777logging!border 10.3.3.3 key-chain key1interface Ethernet9/0 externalinterface Ethernet8/0 internal!border 10.3.3.4 key-chain key2interface Ethernet5/0 externalinterface Ethernet8/0 internal!border 10.4.4.2 key-chain key3interface Ethernet2/0 externalinterface Ethernet8/0 internalbackoff 90 90mode route controlresolve jitter priority 1 variance 10no resolve delay!To verify the basic configuration and show the status of the border routers, the show oer master command is run:
Router# show oer masterOER state: ENABLED and ACTIVEConn Status: SUCCESS, PORT: 7777Version: 2.1Number of Border routers: 3Number of Exits: 3Number of monitored prefixes: 1 (max 5000)Max prefixes: total 5000 learn 2500Prefix count: total 1, learn 0, cfg 1Border Status UP/DOWN AuthFail Version10.4.4.2 ACTIVE UP 17:00:32 0 2.110.3.3.4 ACTIVE UP 17:00:35 0 2.110.3.3.3 ACTIVE UP 17:00:38 0 2.1Global Settings:max-range-utilization percent 20 recv 20mode route metric bgp local-pref 5000mode route metric static tag 5000trace probe delay 1000loggingDefault Policy Settings:backoff 90 90 90delay relative 50holddown 90periodic 0probe frequency 56mode route controlmode monitor bothmode select-exit goodloss relative 10jitter threshold 20mos threshold 3.60 percent 30unreachable relative 50resolve jitter priority 1 variance 10resolve utilization priority 12 variance 20Learn Settings:current state : DISABLEDtime remaining in current state : 0 secondsno throughputno delayno inside bgpno protocolmonitor-period 5periodic-interval 120aggregation-type prefix-length 24prefixes 100expire after time 720Fast failover is now configured for active voice probes and the probe frequency is set to 2 seconds using an OER 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 OER.
Router# show run | sec oer-mapoer-map MAP 10match traffic-class prefix-list VOICE_FAIL_LISTset mode select-exit bestset mode monitor fastset jitter threshold 12set active-probe jitter 120.120.120.1 target-port 20 codec g729aset probe frequency 2The following output from the show oer master prefix command 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 oer master prefix 10.1.1.0/24 policy* Overrides Default Policy Settingoer-map MAP 10sequence no. 8444249301975040, provider id 1, provider priority 30host priority 0, policy priority 10, Session id 0match ip prefix-lists: VOICE_FAIL_LISTbackoff 90 90 90delay relative 50holddown 90periodic 0*probe frequency 2mode route control*mode monitor fast*mode select-exit bestloss relative 10*jitter threshold 12mos threshold 3.60 percent 30unreachable relative 50next-hop not setforwarding interface not setresolve jitter priority 1 variance 10resolve utilization priority 12 variance 20Forced Assigned Target List:active-probe jitter 10.120.120.1 target-port 20 codec g729aAfter 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 OER 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/0May 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 JitterConfiguring the Source Address of an Active Probe: Example
The following example, starting in global configuration mode, configures FastEthernet 0/0 as the active-probe source interface.
Router(config)# oer borderRouter(config-oer-br)# active-probe address source interface FastEthernet 0/0Where to Go Next
This module described the OER measure phase and it has assumed that you started with the Cisco IOS Optimized Edge Routing Overview module, followed by the Setting Up OER Network Components module. The measure phase is the second phase in the OER performance loop. To learn more about the other OER phases, read through the other modules in the following list:
•
•
•
•
After you understand the various OER phases, you may want to review the OER Solutions modules that are listed under "Related Documents" section.
Additional References
The following sections provide references related to measuring the traffic class performance and link utilization using OER.
Related Documents
Cisco OER technology overview
Concepts and configuration tasks required to set up OER network components.
OER solution module: voice traffic optimization using OER active probes.
OER solution module: configuring VPN IPsec/GRE tunnel interfaces as OER-managed exit links.
"Configuring VPN IPsec/GRE Tunnel Interfaces As OER-Managed Exit Links" module
Cisco OER commands: complete command syntax, command mode, command history, defaults, usage guidelines and examples
Technical Assistance
Feature Information for Measuring the Traffic Class Performance and Link Utilization Using OER
Table 2 lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Release 12.3(8)T, 12.2(33)SRB, or a later release appear in the table.
For information on a feature in this technology that is not documented here, see the "Cisco IOS Optimized Edge Routing Feature Roadmap."
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 2 Feature Information for Measuring the Traffic Class Performance and Link Utilization Using OER
Optimized Edge Routing
12.3(8)T
12.2(33)SRBOER was introduced.
OER Active Probe Source Address
12.4(2)T
12.2(33)SRBThe OER Active Probe Source Address feature allows you to configure a specific exit interface on the border router as the source for active probes.
The following sections provide information about this feature:
•
•
•
•
The active-probe address source command was introduced by this feature.
OER Voice Traffic Optimization
12.4(6)T
12.2(33)SRBThe OER Voice Traffic Optimization feature introduced support for outbound optimization of voice traffic based on the voice metrics, jitter and Mean Opinion Score (MOS). Jitter and MOS are important quantitative quality metrics for voice traffic and these voice metrics are measured using OER active probes.
The following sections provide information about this feature:
•
•
The following commands were introduced or modified by this feature: active-probe, jitter, mos, resolve, set jitter, set mos, set probe, set resolve, show oer master active-probes, show oer policy, show oer master prefix.
OER BGP Inbound Optimization
12.4(9)T
12.2(33)SRBOER BGP inbound optimization supports best entrance selection for traffic that originates from prefixes outside an autonomous system destined for prefixes inside the autonomous system. External BGP (eBGP) advertisements from an autonomous system to an Internet service provider (ISP) can influence the entrance path for traffic entering the network. OER uses eBGP advertisements to manipulate the best entrance selection.
The following sections provide information about this feature:
•
•
•
•
•
The following commands were introduced or modified by this feature: clear oer master prefix, downgrade bgp, inside bgp, match ip address (OER), match oer learn, max range receive, maximum utilization receive, show oer master prefix.
OER DSCP Monitoring
12.4(9)T
12.2(33)SRBOER DSCP Monitoring introduced automatic learning of traffic classes based on protocol, port numbers, and DSCP value. Traffic classes can be defined by a combination of keys comprising of protocol, port numbers, and DSCP values, with the ability to filter out traffic that is not required, and the ability to aggregate the traffic in which you are interested. Information such as protocol, port number, and DSCP information is now sent to the master controller database in addition to the prefix information. The new functionality allows OER to both actively and passively monitor application traffic.
The following sections provide information about this feature:
The following commands were introduced or modified by this feature: show oer border passive applications, show oer border passive cache, show oer border passive learn, show oer master appl, traffic-class aggregation, traffic-class filter, and traffic-class keys.
Support for Fast Failover Monitoring1
12.4(15)T
Fast Failover Monitoring introduced the ability to configure a fast monitoring mode. In fast failover monitoring mode, all exits are continuously probed using active monitoring and passive monitoring. The probe frequency can be set to a lower frequency in fast failover monitoring mode than for other monitoring modes, to allow a faster failover capability. Fast failover monitoring can be used with all types of active probes: ICMP echo, jitter, TCP connection, and UDP echo.
The following section provides information about this feature:
•
•
The following commands were modified by this feature: mode (OER), set mode.
OER Border Router Only Functionality
12.2(33)SXH
In Cisco IOS Release 12.2(33)SXH support for using a Cisco Catalyst 6500 series switch as an OER border router was introduced. Only border router functionality is included in the Cisco IOS Release 12.2(33)SXH images; no master controller configuration is available. The master controller that communicates with the Cisco Catalyst 6500 series switch being used as a border router must be a router running Cisco IOS Release 12.4(6)T or a later release. The OER master controller software has been modified to handle the limited functionality supported by the Cisco Catalyst 6500 border routers. Using the Route Processor (RP), the Catalyst 6500 border routers can capture throughput statistics only for a traffic class compared to the delay, loss, unreachability, and throughput statistics collected by non-Catalyst 6500 border routers. A master controller automatically detects the limited capabilities of the Catalyst 6500 border routers and downgrades other border routers to capture only the throughput statistics for traffic classes. By ignoring other types of statistics, the master controller is presented with a uniform view of the border router functionality.
The following sections provide information about this feature:
•
The following command was introduced or modified by this feature: show oer border passive cache.
1 This is a minor enhancement. Minor enhancements are not typically listed in Feature Navigator.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0910R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2007-2009 Cisco Systems, Inc. All rights reserved.
