- Finding Feature Information
- Prerequisites for Configuring and Applying OER Policies
- Information About Configuring and Applying OER Policies
- How to Configure and Apply OER Policies
- Configuring and Applying an OER Policy to Learned Traffic Classes
- Configuring and Applying an OER Policy to Configured Traffic Classes
- Preventing OER Optimization of Learned Prefixes
- Configuring and Applying an OER Policy to Learned Inside Prefixes
- Configuring and Applying an OER Policy to Configured Inside Prefixes
- Configuring Policy Rules for OER Maps
- Configuring Multiple OER Policy Conflict Resolution
- Configuring an Exit Link Load Balancing OER Policy
- Implementing Performance Routing Link Groups
- Configuring OER Cost-Based Policies
- Configuring OER Network Security Policies
- Configuring OER Voice Traffic Optimization Using Active Probes
- Configuring and Applying an OER Policy to Learned Traffic Classes Example
- Configuring and Applying an OER Policy to Configured Traffic Classes Example
- Preventing OER Optimization of Learned Prefixes Example
- Configuring and Applying an OER Policy to Learned Inside Prefixes Example
- Configuring and Applying an OER Policy to Configured Inside Prefixes Example
- Configuring Policy Rules for OER Maps Example
- Configuring Multiple OER Policy Conflict Resolution Example
- Configuring an Exit Link Load Balancing OER Policy Example
- Implementing Performance Routing Link Groups Example
- Configuring OER Cost-Based Policies Example
- Configuring OER Network Security Policies Examples
- Configuring OER Voice Traffic Optimization Using Active Probes Examples
Configuring and Applying OER Policies
This module describes the Cisco IOS Optimized Edge Routing (OER) apply policy phase. In the apply policy phase, OER uses policies to map the measured performance metrics of traffic class entries in the Monitored Traffic Class (MTC) list, or exit links, against well-known or configured thresholds to determine if the traffic class entry performance or the link utilization is meeting specified levels of service, or if some action is required.
- Finding Feature Information
- Prerequisites for Configuring and Applying OER Policies
- Information About Configuring and Applying OER Policies
- How to Configure and Apply OER Policies
- Configuration Examples for Configuring and Applying OER Policies
- Where to Go Next
- Additional References
- Feature Information for Configuring and Applying OER Policies
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 Table at the end of this document.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Configuring and Applying OER Policies
Before implementing OER policies, you need to understand an overview of how OER works and how to set up OER network components. See the Cisco IOS Optimized Edge Routing OverviewCisco IOS Optimized Edge Routing Overview and Setting Up OER Network Components modules for more details. If you are following the OER performance loop, the OER profile and measure phases precede this phase. See the Where to Go Next section for more details.
Information About Configuring and Applying OER Policies
- OER Apply Policy Phase Overview
- OER Policy Decision Point
- OER Traffic Class Performance Policies
- OER Link Policies
- Performance Routing Link Grouping
- OER Network Security Policies
- OER Policy Operational Options and Parameters
- OER Policy Application
- Priority Resolution for Multiple OER Policies
OER Apply Policy Phase Overview
The OER apply policy phase is the third step in the OER performance loop following after the profile phase that identifies the traffic classes, and the measure phase where each traffic class entry in the MTC list is monitored to determine performance metric measurements. The apply policy phase compares the measured performance metrics against well-known or configured thresholds to determine if the traffic is meeting specified levels of service, or if some action is required. If the performance metric does not conform to the threshold, a decision is made by OER to move the traffic class or exit into another state. For more details about the state transition decision, see OER Policy Decision Point.
An OER policy is a rule that defines an objective and contains the following attributes:
For example, a policy can be configured to maintain a delay of less than or equal to 100 milliseconds for packets sent to a specific traffic class entry. The scope is the network traffic sent to the specific traffic class entry, the action is a routing table change, and the triggering event is a measured delay of greater than 100 milliseconds for this traffic. The action may be not be executed until OER is configured to control the traffic in the OER control phase. By default, OER runs in an observe mode during the profile, measure, and apply policy phases.
In the OER apply policy phase you can configure and apply policies. Different types of OER policies can be configured--see the figure below--and specific OER parameters and options can be included within a policy. In this document, a parameter is a configurable element that can be fine-tuned, and an option is a configurable element that is either enabled or disabled. After an OER policy is configured, the policy can be applied to learned traffic classes or configured traffic classes. OER policies can be applied globally--to all the traffic classes--or to just a specific set of traffic classes.
| Figure 1 | OER Apply Policy Phase Structure |
In the figure above you can see that there are three types of OER policies plus some operational options and parameters that can be configured. Use the following links to review more information about each policy type, parameter, or option:
After an OER policy is configured, you can see from the figure above that a policy can be applied to learned traffic classes or configured traffic classes on a global basis for all traffic classes or for a specific set of traffic classes. For more details about applying OER policies, see OER Policy Application.
When configuring multiple policy parameters for traffic classes, it is possible to have multiple overlapping policies. To resolve the potential conflict of which policy to run, OER uses its resolve function: a flexible mechanism that allows you to set the priority for most of the policy types. For more details about how OER resolves multiple policy conflicts, see Priority Resolution for Multiple OER Policies.
OER Policy Decision Point
When running an OER policy that compares the traffic class performance metrics with default or configured thresholds, a traffic class may change state. OER uses a policy decision point (PDP) that operates according to the traffic class state transition diagram shown in the figure below. The state transition diagram in the figure below contains the following states:
- Default--A traffic class is placed in the default state when it is not under OER control. Traffic classes are placed in the default state when they are initially added to the central policy database, the MTC. A traffic class will transition into and out of the default state depending on performance measurements, timers, and policy configuration.
- Choose Exit--This is a temporary state in which the PDP compares the current state of the traffic class against its policy settings and chooses the optimal exit for the traffic class. OER will try to keep a traffic class flowing through its current exit but, as in the default state, performance measurements, timers, and policy configurations can cause the master controller to place a traffic class in this state for the duration of the exit link selection process. The traffic class remains in the choose exit state until it is moved to the new exit.
- Holddown--A traffic class is placed in the holddown state when the master controller requests a border router to forward the traffic class to be monitored using probes. Measurements are collected for the selected traffic class until the holddown timer expires unless the exit used by this traffic class is declared unreachable. If the exit is unreachable, the traffic class transitions back to the choose exit state.
| Figure 2 | OER Traffic Class State Transition Diagram |
- In-Policy--After performance measurements are compared against default or user-defined policy settings and an exit selection is made, the traffic class enters an in-policy state. When a traffic class is in the in-policy state, the traffic class is forwarded through an exit that satisfies the default or user-defined settings. The master controller continues to monitor the traffic class, but no action is taken until the periodic timer expires, or an out-of-policy message is received from a measurement collector, when the traffic class transitions back to the choose exit state.
 Note |
In Cisco IOS Release 12.4(24)T, 12.2(33)SRE, and later releases, when observe mode is running, a prefix goes into an in-policy state only if the exit selected for that prefix is the current exit. In previous releases, a prefix goes into an in-policy state even if the newly selected exit is not the current exit. |
- Out-of-Policy (OOP)--A traffic class is placed in this state when there are no exits through which to forward the traffic class that conform to default or user-defined policies. While the traffic class is in this state, the backoff timer controls exiting from this state. Each time the traffic class enters this state, the amount of time the traffic class spends in this state increases. The timer is reset for a traffic class when the traffic class enters an in-policy state. If all exit links are out-of-policy, the master controller may select the best available exit.
OER Traffic Class Performance Policies
OER traffic class performance policies are a set of rules that govern performance characteristics for traffic classes that can be network addresses (prefixes) or application criteria such as protocol, port number, or DSCP value. Network addresses can refer to individual endpoints within a network (e.g. 10.1.1.1/32) or to entire subnets (e.g. 10.0.0.0/8). The major performance characteristics that can be managed within an OER policy are:
With the exception of reachability, none of these performance characteristics can be managed within the constructs of conventional routing protocol metrics. Cisco OER extends the concept of reachability (beyond ensuring that a particular route exists in the routing table) by automatically verifying that the destination can be reached through the indicated path. Using Cisco OER provides the network administrator with a new and powerful toolset for managing the flow of traffic.
Reachability
Reachability is specified as the relative percentage or the absolute maximum number of unreachable hosts, based on flows per million (fpm), that OER will permit from a traffic class entry. If the absolute number or relative percentage of unreachable hosts is greater than the user-defined or the default value, OER determines that the traffic class entry is out-of-policy and searches for an alternate exit link.
To configure parameters for reachability, use the unreachable command. This command has two keywords, relative and threshold. The relative keyword is used to configure the relative percentage of unreachable hosts. The relative unreachable host percentage is based on a comparison of short-term and long-term measurements. The short-term measurement reflects the percentage of hosts that are unreachable within a 5-minute period. The long-term measurement reflects the percentage of unreachable hosts within a 60-minute period. The following formula is used to calculate this value:
Relative percentage of unreachable hosts = ((short-term percentage - long-term percentage) / long-term percentage) * 100
The master controller measures the difference between these two values as a percentage. If the percentage exceeds the user-defined or default value, the traffic class entry is determined to be out-of-policy. For example, if 10 hosts are unreachable during the long-term measurement and 12 hosts are unreachable during short-term measurement, the relative percentage of unreachable hosts is 20 percent.
The threshold keyword is used to configure the absolute maximum number of unreachable hosts. The maximum value is based on the actual number of hosts that are unreachable based on fpm.
Delay
Delay (also referred as latency) 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.
In Cisco IOS Release 12.4(6)T, 12.2(33)SRB, and later releases, support was introduced for defining delay performance characteristics with respect to voice traffic. 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.
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.
Jitter
Support for jitter was introduced in Cisco IOS Release 12.4(6)T, 12.2(33)SRB, and later releases. 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, both positive and negative jitter values are undesirable; a jitter value of 0 is ideal.
Mean Opinion Score (MOS)
Support for MOS was introduced in Cisco IOS Release 12.4(6)T, 12.2(33)SRB, and later releases. 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.
In Cisco IOS Release 12.4(4)T and prior releases, only reachability, delay, and loss performance characteristics could be used. In Cisco IOS Release 12.4(6)T, 12.2(33)SRB, and later releases, jitter and MOS performance characteristic can be configured in an OER policy as well as delay and packet loss to determine the quality of a phone call over an IP network.
OER Link Policies
OER link policies are a set of rules that are applied against OER-managed external link (an external link is an interface on a border router on the network edge). Link policies define the desired performance characteristics of the links. Instead of defining the performance of an individual traffic class entry that uses the link (as in traffic class performance policies), link policies are concerned with the performance of the link as a whole. In Cisco IOS Release 12.4(6)T and prior releases, link policies are applied only to exit (egress) links, but in Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, support for selected entrance (ingress) link policies was introduced. The following performance characteristics are managed by link policies:
Traffic Load
A traffic load (also referred to as utilization) policy consists of an upper threshold on the amount of traffic that a specific link can carry. Cisco IOS OER supports per traffic class load distribution. Every 20 seconds, by default, the border router reports the link utilization to the master controller, after an external interface is configured for a border router. In Cisco IOS Release 12.4(6)T and prior releases, only exit link traffic load thresholds can be configured as an OER policy, but in Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, entrance link traffic load thresholds can be configured. If the exit or entrance link utilization is above the configured threshold, or 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. A load utilization policy for an individual interface is configured on the master controller under the border router configuration.
 Tip |
When configuring load distribution, we recommend that you set the interface load calculation on external interfaces to 30-second intervals with the load-interval interface configuration command. The default calculation interval is 300 seconds. The load calculation is configured under interface configuration mode on the border router. This configuration is not required, but it is recommended to allow Cisco IOS OER to respond as quickly as possible to load distribution issues. |
Range
A range policy is defined to maintain all links within a certain utilization range, relative to each other in order to ensure that the traffic load is distributed. For example, if a network has multiple exit links, and there is no financial reason to choose one link over another, the optimal choice is to provide an even load distribution across all links. The load-sharing provided by traditional routing protocols is not always evenly distributed, because the load-sharing is flow-based rather than performance- or policy-based. Cisco OER range functionality allows you to configure OER to maintain the traffic utilization on a set of links within a certain percentage range of each other. If the difference between the links becomes too great, OER will attempt to bring the link back to an in-policy state by distributing traffic classes among the available links. The master controller sets the maximum range utilization to 20 percent for all OER-managed links by default, but the utilization range can be configured using a maximum percentage value. In Cisco IOS Release 12.4(6)T and prior releases, only an exit link utilization range can be configured as an OER policy, but in Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, an entrance link utilization range can be configured.
Cost
OER support for cost-based optimization was introduced in Cisco IOS Release 12.3(14)T and 12.2(33)SRB. Cost-based optimization allow you to configure policies based on the monetary cost (ISP service level agreements [SLAs]) of each exit link in your network. To implement OER cost-based optimization the OER master controller is configured to send traffic over exit links that provide the most cost-effective bandwidth utilization, while still maintaining the desired performance characteristics.
Cost Based Optimization can be applied to links that are billed using a fixed or tiered billing method and load balancing based on cost can also be achieved. For more configuration details, see the Configuring Performance Routing Cost Policies module.
Performance Routing Link Grouping
In Cisco IOS Release 12.4(15)T the ability to define a group of exit links as a preferred set of links, or a fallback set of links for OER to use when optimizing traffic classes specified in an OER policy, was introduced. OER currently selects the best link for a traffic class based on the preferences specified in a policy and the traffic class performance--using parameters such as reachability, delay, loss, jitter or MOS--on a path out of the specified link. Bandwidth utilization, cost, and the range of links can also be considered in selecting the best link. Link grouping introduces a method of specifying preferred links for one or more traffic classes in an OER policy so that the traffic classes are routed through the best link from a list of preferred links, referred to as the primary link group. A fallback link group can also be specified in case there are no links in the primary group that satisfy the specified policy and performance requirements. If no primary group links are available, the traffic classes are routed through the best link from the fallback group. To identify the best exit, OER probes links from both the primary and fallback groups.
Primary and fallback link groups can be configured at the master controller and are identified using a unique name. Link groups provide a method of grouping links such as high bandwidth links to be used, for example, by video traffic, by configuring an OER policy to specify that the best link is to be selected from the link group that consists of only high bandwidth links. The traffic classes specified in a policy can be configured with only one primary link group and one fallback link group. The priority of a link group can vary between policies, a link group might be a primary link group for one policy, and a fallback link group for another policy.
See the figure below for an example of how to implement link grouping. Three link groups, ISP1, ISP2, and ISP3 represent different Internet Service Providers (ISPs) and all three ISPs have links to interfaces on the three border routers shown in the figure below. ISP1 links are the most expensive links, but they have the best Service Level Agreement (SLA) guarantees. ISP3 links are best effort links, and these links are the cheapest links. ISP2 links are not as good as the ISP1 links, but the ISP2 links are more reliable than the ISP3 links. The cost of the ISP2 links is higher than the ISP3 links, but lower than ISP1 links. In this situation, each ISP is created as a link group and associated with an interface on each border router shown in the figure below.
| Figure 3 | Link Group Diagram |
Assuming four types of traffic class, video, voice, FTP, and data, each traffic class can be routed through a border router interface belonging to an appropriate link group. Video and voice traffic classes need the best links so the ISP1 link group is configured as the primary link group, with ISP2 as the fallback group. FTP traffic needs reliable links but the cost might be a factor so ISP2 is assigned as the primary group, and ISP3 is the fallback link group. Note that although ISP1 provides the most reliable links, it may be too expensive for file transfer traffic. For data traffic, ISP3 is a good choice as a primary link group, with ISP2 as the fallback group.
Spillover
Performance routing link groups can be used to support spillover. Spillover is when there are two paths through the network--traffic engineering (TE) tunnels, for example--to the same provider edge (PE) router, but the tunnels take different paths across the network and the traffic is sent through one tunnel until it reaches a traffic load threshold when it spills over to the second tunnel. Using OER link groups one tunnel is created as a primary link group and the second tunnel is the fallback link group. When the first tunnel goes out of policy, OER switches to the fallback tunnel link group, which provides the spillover capacity until the traffic load on the first tunnel drops below the threshold. The tunnels must be established before the OER link groups are configured.
OER Network Security Policies
The ability to configure network security policies either to prevent unauthorized use of the network or to mitigate attacks inside and outside the network was introduced in Cisco IOS Release 12.4(6)T and 12.2(33)SRB. You can configure OER to use black hole or sinkhole routing techniques to limit the impact of attacks against your network. Black hole routing refers to the process of forwarding packets to a null interface, meaning that the packets are dropped into a "black hole." Sinkhole routing directs packets to a next hop where the packets can be stored, analyzed, or dropped. Another term for sinkhole routing is honey-pot routing.
OER Policy Operational Options and Parameters
In addition to the specific types of OER policies, there are some OER policy operational parameters or options that can be configured. The operational parameters are timers and the operational options consist of different operational modes. For more details, see the following sections:
OER Timers Parameters
Three types of timers can be configured as OER policy operational parameters:
Backoff Timer
The backoff timer is used to adjust the transition period that the master controller holds an out-of-policy traffic class entry. The master controller waits for the transition period before making an attempt to find an in-policy exit. A minimum, a maximum, and an optional step timer value can be configured.
Holddown Timer
The holddown timer is used to configure the traffic class entry route dampening timer to set the minimum period of time that a new exit must be used before an alternate exit can be selected. To prevent the traffic class entry from flapping because of rapid state changes, the master controller does not move the traffic class entry to a different exit even if it goes out-of-policy during the holddown timer period. OER does not implement policy changes while a traffic class entry is in the holddown state. A traffic class entry will remain in a holddown state for the default or configured time period. When the holddown timer expires, OER will select the best exit based on performance and policy configuration. However, an immediate route change will be triggered if the current exit for a traffic class entry becomes unreachable.
Periodic Timer
The periodic timer is used to find a better path for a traffic class entry, even if the traffic class entry is in-policy on the current exit. When the periodic timer expires, the master controller evaluates current exit links for the traffic class entry and, if a better exit exists based on the current measurements and priorities, the traffic class entry is moved to a new in-policy exit link.
When adjusting OER timers note that a newly configured timer setting will immediately replace the existing setting if the value of the new setting is less than the time remaining. If the value is greater than the time remaining, the new setting will be applied when the existing timer expires or is reset.
Note |
Overly aggressive timer settings can keep an exit link or traffic class entry in an out-of-policy state. |
OER Mode Options
Three types of mode options can be configured as OER policy operational options:
Mode Monitor
The mode monitor option enables the configuration of OER monitoring settings. 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 exit links. For more details about mode monitoring options, see the Measuring the Traffic Class Performance and Link Utilization Using OER module.
Mode Route
The mode route option specifies one of three OER route control policy settings. Mode route control enables OER to control routes automatically, mode route metric specifies OER route protocol-related settings, and mode route observe offers route control advice, but does not take any action. Observe mode monitoring is enabled by default when OER is enabled. In observe mode, the master controller monitors traffic classes and exit links based on default and user-defined policies and then reports the status of the network and the decisions that should be made but does not implement any changes. Observe mode is used to verify the effect of OER features before OER is actively deployed on your network. For more details about the mode route control and mode route metric options, see the Using OER to Control the Traffic Classes and Verify the Network Performance module.
Mode Select-Exit
The mode select-exit option enables the exit selection settings. The definition of an in-policy traffic class entry is that the measured performance metrics are do not exceed a default or configured threshold while the traffic class traffic is on the current path. In this situation, OER does not search for an alternate exit link because the current network path keeps the traffic class entry in-policy. This type of configuration would be activated by using the mode select-link good command which is the default if the mode command is not specified. There are other deployment scenarios, where OER selects the best performance path. This type of configuration can be activated by using the mode select-link best command. In this type of situation, OER measures alternate path performance metrics while the traffic class entry is in-policy on the current path. OER moves the current path if a better performance path is found. After the first selection of the best path, however, OER does not initiate another search unless the periodic timer is configured. When the periodic timer expires, the master controller evaluates current exit links for the traffic class entry and, if a better exit exists based on the current measurements and priorities, the traffic class entry is moved to a new in-policy exit link. Use the periodic timer with the mode select-link best command if you have a deployment scenario where you need OER to select the best performance path at any given time.
There is one further use of the mode select-exit option. If OER does not find an in-policy exit for a traffic class entry when the mode select-link good command is operational, OER transitions the traffic class entry to an uncontrolled state. If OER does not find an in-policy exit for a traffic class entry when the mode select-link best command is operational, OER selects the best of the OOP exit links for the traffic class entry.
OER Policy Application
OER policies can be applied to learned or configured traffic classes. OER policies can be applied on a global basis when the policy is configured directly under OER master controller configuration mode. All traffic classes inherit global policies. If, however, you want to apply a policy to a subset of the traffic classes, then a specific policy can be configured. A specific OER policy applies only to the specific traffic classes that match a prefix list or access list. Specific policies inherit global policies unless the same policy is overwritten by the specific policy. In Cisco IOS Release 12.4(6)T and earlier releases, OER policies applied only to prefixes, but in Cisco IOS Release 12.4(9)T, 12.2(33)SRB, and later releases, OER policies can apply to traffic classes that define an application traffic class and may include prefixes, protocols, port numbers, and DSCP values. To apply specific policies to learned or configured traffic classes, OER map configuration is used.
OER Map Configuration for OER Policies
An OER map may appear to be similar to a route map but there are significant differences. An OER map is designed to select learned or configured traffic classes using a match clause and then to apply OER policy configurations using a set clause. The OER map can be optionally configured with a sequence number like a route map, but only the OER map with the lowest sequence number is evaluated. The operation of an OER map differs from a route map at this point. There are two important distinctions:
- Only a single match clause may be configured for each sequence. An error message will be displayed on the console if you attempt to configure multiple match clauses for a single OER map sequence.
-
An OER map is not configured with permit or deny statements. However, a permit or deny sequence can be configured for an IP traffic flow by configuring a permit or deny statement in an IP prefix list and then applying the prefix list to the OER map.
Note
Match precedence priority is not supported in OER maps.
The OER map applies the configuration of the set clause after a successful match occurs. An OER set clause can be used to set policy parameters such as the backoff timer, packet delay, holddown timer, packet loss, mode settings, periodic timer, resolve settings, unreachable hosts, and traceroute reporting.
Policies applied by an OER map take effect immediately. The OER map configuration can be viewed in the output of the show running-config command. OER policy configuration can be viewed in the output of the show oer master policy command. These policies are applied only to traffic classes that match or pass through the OER map.
Policy Rules Configuration to Apply an OER Policy
The policy-rules OER master controller configuration command was introduced in Cisco IOS Release 12.3(11)T, 12.2(33)SRB, and later releases. This command allows you to select an OER map using a sequence number and apply the configuration under OER master controller configuration mode, providing an improved method to switch between predefined OER maps. Only one OER map is used at a time for policy configuration, but many OER maps can be defined. In Cisco IOS Release 12.3(8)T, only one OER map could be defined to apply a policy to traffic classes.
Priority Resolution for Multiple OER Policies
When configuring multiple policy criteria for a single traffic class entry, or a set of traffic classes, it is possible to have multiple overlapping policies. To resolve the potential conflict of which policy to run, OER uses its resolve function: a flexible mechanism that allows you to set the priority for an OER policy. Each policy is assigned a unique value, and the policy with the lowest value is selected as the highest priority policy. By default, OER assigns the highest priority to delay policies, followed by utilization policies. Assigning a priority value to any policy will override the default settings. To configure the policy conflict resolution, use the resolve command in OER master controller configuration mode, or the set resolve command in OER map configuration mode.
Variance Setting for OER Policy Conflict Resolution
When configuring OER resolve settings, you can also set an allowable variance for the defined policy. Variance configures the average delay, as a percentage, that all traffic classes for one exit, or the specific policy traffic classes for an exit, can vary from the defined policy value and still be considered equivalent. For example, if the delay on the best exit link (best exit in terms of delay) for a traffic class entry is 80 milliseconds (ms) and a 10 percent variance is configured, then any other exit links with a delay between 80 and 88 ms for the same traffic class entry are considered equivalent to the best exit link.
To illustrate how variance is used by OER consider three exit links with the following performance values for delay and jitter for a traffic class entry:
- Exit A--Delay is 80 ms, jitter is 3ms
- Exit B--Delay is 85 ms, jitter is 1ms
- Exit C--Delay is 100 ms, jitter is 5ms
The following OER policy conflict resolution is configured and applied to the traffic class entry:
delay priority 1 variance 10 jitter priority 2 variance 10
OER determines the best exit by looking at the policy with the lowest priority value, which in this example is the delay policy. Exit A has the lowest delay value, but Exit B has a delay value of 85 which is within a 10 percent variance of the delay value at Exit A. Exit A and Exit B can therefore be considered equal in terms of delay values. Exit C is now eliminated because the delay values are too high. The next priority policy is jitter, and Exit B has the lowest jitter value. OER will select Exit B as the only best exit for the traffic class entry because Exit A has a jitter value that is not within 10 percent variance of the Exit B jitter value.
Note |
Variance cannot be configured for cost or range policies. |
How to Configure and Apply OER Policies
- Configuring and Applying an OER Policy to Learned Traffic Classes
- Configuring and Applying an OER Policy to Configured Traffic Classes
- Preventing OER Optimization of Learned Prefixes
- Configuring and Applying an OER Policy to Learned Inside Prefixes
- Configuring and Applying an OER Policy to Configured Inside Prefixes
- Configuring Policy Rules for OER Maps
- Configuring Multiple OER Policy Conflict Resolution
- Configuring an Exit Link Load Balancing OER Policy
- Implementing Performance Routing Link Groups
- Configuring OER Cost-Based Policies
- Configuring OER Network Security Policies
- Configuring OER Voice Traffic Optimization Using Active Probes
Configuring and Applying an OER Policy to Learned Traffic Classes
Perform this task at the master controller to configure and apply an OER policy to learned traffic classes. After configuring the router as an OER master controller using the oer master command, most of the commands in this task are all optional. Each step configures a performance policy that applies to learned traffic classes on a global basis. In this example, OER is configured to select the first in-policy exit.
Cisco IOS OER Timers Adjustments
When adjusting OER timers note that a newly configured timer setting will immediately replace the existing setting if the value of the new setting is less than the time remaining. If the value is greater than the time remaining, the new setting will be applied when the existing timer expires or is reset.
Note |
Overly aggressive timer settings can keep an exit link or traffic class entry in an out-of-policy state. |
DETAILED STEPS
Examples
This example shows output from the show oer master policy command. Default policy settings are displayed except where the configuration in this task has overwritten specific policy settings.
Router# show oer master policy
Default Policy Settings:
backoff 400 4000 400
delay relative 80
holddown 600
periodic 300
probe frequency 56
mode route observe
mode monitor both
mode select-exit good
loss relative 20
unreachable relative 10
resolve delay priority 11 variance 20
resolve utilization priority 12 variance 20
*tag 0
Configuring and Applying an OER Policy to Configured Traffic Classes
Perform this task at the master controller to configure and apply an OER policy to specified configured traffic classes. This task contains two targeted policies that work differently for different traffic class entries from the MTC list. The policies are configured using an OER map. This task contains both prefix list and access list configuration with different criteria in the set clauses. OER timers are also modified in this OER map configuration.
Note |
Policies applied in an OER map can override global policy configurations. |
Cisco IOS OER Timers Adjustments
When adjusting OER timers note that a newly configured timer setting will immediately replace the existing setting if the value of the new setting is less than the time remaining. If the value is greater than the time remaining, the new setting will be applied when the existing timer expires or is reset.
Note |
Overly aggressive timer settings can keep an exit link or prefix in an out-of-policy state. |
Prefix List Use with OER
IP prefix lists are used to manually select prefixes for OER monitoring and the prefix list syntax operates in a slightly different way with OER than in regular routing. The ge keyword is not used and the le keyword is used by OER to specify two types of prefixes: exact prefixes, and inclusive prefixes.
A master controller can monitor and control an exact prefix of any length including the default route. If an exact prefix is specified, OER monitors only the exact prefix.
A master controller can monitor and control an inclusive prefix using the le keyword and the le-value argument set to 32. OER monitors the configured prefix and any more specific prefixes (for example, configuring the 10.0.0.0/8 le 32 prefix would include the 10.1.0.0/16 and the 10.1.1.0/24 prefixes) over the same exit and records the information in the routing information base (RIB).
Note |
Use the inclusive prefix option with caution in a typical OER deployment because of the potential increase in the amount of prefixes being monitored and recorded. |
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.
DETAILED STEPS
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||
|
|
Example: Router(config)# ip prefix-list OER seq 10 permit 10.4.9.0/24 |
Creates an IP prefix list.
|
||
|
|
Example: Router(config)# ip access-list extended VOICE_ACCESS_LIST |
Defines an IP access list by name. |
||
|
|
Example: Router(config-ext-nacl)# permit udp any range 16384 32767 10.20.20.0 0.0.0.15 range 16384 32767 |
Sets conditions to allow a packet to pass a named IP access list.
|
||
|
|
Example: Router(config-ext-nacl)# exit |
Exits extended access list configuration mode and returns to global configuration mode. |
||
|
|
Example: Router(config)# oer-map FINANCE 10 |
Enters OER map configuration mode to configure an OER map to apply policies to selected IP prefixes. |
||
|
|
Example: Router(config-oer-map)# match ip address prefix-list OER |
References an extended IP access list or IP prefix list as match criteria in an OER map. |
||
|
|
Example: Router(config-oer-map)# set backoff 400 4000 400 |
Creates a set clause entry to configure the backoff timer to adjust the time period for traffic class entry policy decisions.
|
||
|
|
Example: Router(config-oer-map)# set delay threshold 2000 |
Creates a set clause entry to configure the delay threshold.
|
||
|
|
Example: Router(config-oer-map)# set loss relative 20 |
Creates a set clause entry to configure the relative or maximum packet loss limit that the master controller will permit for an exit link.
|
||
|
|
Example: Router(config-oer-map)# set periodic 300 |
Creates a set clause entry to configure the time period for the periodic timer.
|
||
|
|
Example: Router(config-oer-map)# set unreachable relative 10 |
Creates a set clause entry to configure the maximum number of unreachable hosts.
|
||
|
|
Example: Router(config-oer-map)# exit |
(Optional) Exits OER map configuration mode and returns to global configuration mode. |
||
|
|
Example: Router(config)# oer-map VOICE_MAP 10 |
Enters OER map configuration mode to configure an OER map to apply policies to selected IP traffic classes. |
||
|
|
Example: Router(config-oer-map)# match ip address access-list VOICE_ACCESS_LIST |
References an extended IP access list or IP prefix list as match criteria in an OER map. |
||
|
|
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.
|
||
|
|
Example: Router(config-oer-map)# set probe frequency 10 |
Creates a set clause entry to set the frequency of the OER active probe. |
||
|
|
Example: Router(config-oer-map)# set jitter threshold 20 |
Creates a set clause entry to configure the jitter threshold value. |
||
|
|
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.
|
||
|
|
Example: Router(config-oer-map)# set mode select-exit best |
Creates a set clause entry to configure monitoring, control, or exit selection settings for matched traffic. |
||
|
|
Example: Router(config-oer-map)# end |
Exits OER map configuration mode and enters privileged EXEC mode. |
Preventing OER Optimization of Learned Prefixes
Perform this task at the master controller to configure and apply an OER policy to prevent OER from attempting to optimize specified learned prefixes. This task is useful when you know a few prefixes that you want to exclude from the OER optimization, but these prefixes will be learned automatically by OER. In this task, an IP prefix list is configured with two entries for different prefixes that are not to be optimized. An OER map is configured with two entries in a sequence that will prevent OER from optimizing the prefixes specified in the prefix list, although the prefixes may be learned. If the sequence numbers of the OER map entries are reversed, OER will learn and attempt to optimize the prefixes.
DETAILED STEPS
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||
|
|
Example: Router(config)# ip prefix-list DENY_LIST deny 10.1.1.0/24 |
Creates an IP prefix list.
|
||
|
|
Example: Router(config)# ip prefix-list DENY_LIST deny 172.20.1.0/24 |
Creates an IP prefix list.
|
||
|
|
Example: Router(config)# oer-map DENY_MAP 10 |
Enters OER map configuration mode to configure an OER map to apply policies to selected IP prefixes. |
||
|
|
Example: Router(config-oer-map)# match ip address prefix-list DENY_LIST |
References an extended IP access list or IP prefix list as match criteria in an OER map. |
||
|
|
Example: Router(config-oer-map)# exit |
Exits OER map configuration mode and returns to global configuration mode. |
||
|
|
Example: Router(config)# oer-map DENY_MAP 20 |
Enters an OER map entry. |
||
|
|
Example: Router(config-oer-map)# match oer learn throughput |
Creates a match clause entry in an OER map to match OER learned prefixes.
|
||
|
|
Example: Router(config-oer-map)# end |
(Optional) Exits OER map configuration mode and returns to privileged EXEC mode. |
Configuring and Applying an OER Policy to Learned Inside Prefixes
Perform this task to apply a policy to learned inside prefix traffic class entries from the MTC list. Support for optimizing inside prefixes was introduced in Cisco IOS Release 12.4(9)T and 12.2(33)SRB. The policy is configured using an OER map and contains some set clauses.
Note |
Policies applied in an OER map do not override global policy configurations. |
OER Inside Prefixes
An OER inside prefix is defined as a public IP prefix assigned to a company. An OER outside prefix is defined as a public IP prefix assigned outside the company. Companies advertise the inside prefixes over the Internet using an Internet service provider (ISP) and receive advertisements for outside prefixes from an ISP.
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 releases.
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
|
Example: Router(config)# oer-map INSIDE_LEARN 10 |
Enters OER map configuration mode to configure an OER map to apply policies to selected IP prefixes.
|
|
|
Example: Router(config-oer-map)# match oer learn inside |
Creates a match clause entry in an OER map to match OER learned prefixes.
|
|
|
Example: Router(config-oer-map)# set delay threshold 2000 |
Creates a set clause entry to configure the delay threshold.
|
|
|
Example: Router(config-oer-map)# set loss relative 20 |
Creates a set clause entry to configure the relative or maximum packet loss limit that the master controller will permit for an exit link.
|
|
|
Example: Router(config-oer-map)# set unreachable relative 10 |
Creates a set clause entry to configure the maximum number of unreachable hosts.
|
|
|
Example: Router(config-oer-map)# end |
(Optional) Exits OER map configuration mode and returns to privileged EXEC mode. |
Configuring and Applying an OER Policy to Configured Inside Prefixes
Perform this task to apply a policy to configured inside prefix traffic class entries from the MTC list. Support for optimizing inside prefixes was introduced in Cisco IOS Release 12.4(9)T and 12.2(33)SRB. The policies are configured using an OER map. This task contains prefix list configuration with different criteria in the set clauses.
Note |
Policies applied in an OER map do not override global policy configurations. |
OER Inside Prefixes
An OER inside prefix is defined as a public IP prefix assigned to a company. An OER outside prefix is defined as a public IP prefix assigned outside the company. Companies advertise the inside prefixes over the Internet using an Internet service provider (ISP) and receive advertisements for outside prefixes from an ISP.
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 releases.
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
|
Example: Router(config)# oer-map INSIDE_CONFIGURE 10 |
Enters OER map configuration mode to create or configure an OER map. |
|
|
Example: Router(config-oer-map)# match ip address prefix-list INSIDE_PREFIXES inside |
References an extended IP access list or IP prefix list as match criteria in an OER map.
|
|
|
Example: Router(config-oer-map)# set delay threshold 2000 |
Creates a set clause entry to configure the delay threshold.
|
|
|
Example: Router(config-oer-map)# set loss relative 20 |
Creates a set clause entry to configure the relative or maximum packet loss limit that the master controller will permit for an exit link.
|
|
|
Example: Router(config-oer-map)# set unreachable relative 10 |
Creates a set clause entry to configure the maximum number of unreachable hosts.
|
|
|
Example: Router(config-oer-map)# end |
Exits OER map configuration mode and returns to privileged EXEC mode. |
Configuring Policy Rules for OER Maps
Perform this task to select an OER map and apply the configuration under OER master controller configuration mode. The policy-rules OER master controller configuration command was introduced in Cisco IOS Release 12.3(11)T, and this command provides an improved method to switch between predefined OER maps.
- At least one OER map must be configured before you can enable policy-rule support.
- This task requires the master controller and border routers to be running Cisco IOS Release 12.3(11)T, 12.2(33)SRB, or later release.
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
|
Example: Router(config)# oer master |
Enters OER master controller configuration mode to configure global prefix and exit link policies. |
|
|
Example: Router(config-oer-mc)# policy-rules RED |
Applies a configuration from an OER map to a master controller configuration in OER master controller configuration mode.
|
|
|
Example: Router(config-oer-mc)# end |
Exits OER master controller configuration mode and enters privileged EXEC mode. |
Configuring Multiple OER Policy Conflict Resolution
Perform this task to use the OER resolve function to assign a priority to an OER policy to avoid any conflict over which policy to run first. Each policy is assigned a unique value, and the policy with the highest value is selected as the highest priority. By default, a delay policy has the highest priority and a traffic load (utilization) policy has the second highest priority. Assigning a priority value to any policy will override default settings.
DETAILED STEPS
| Command or Action | Purpose | |||||
|---|---|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||||
|
|
Example: Router(config)# oer master |
Enters OER master controller configuration mode. |
||||
|
|
Example: Router(config-oer-mc)# resolve loss priority 2 variance 10 |
Sets policy priority or resolves policy conflicts.
|
||||
|
|
|
-- |
||||
|
|
Example: Router(config-oer-mc)# end |
Exits OER master controller configuration mode, and enters privileged EXEC mode. |
Configuring an Exit Link Load Balancing OER Policy
Perform this task at the master controller to configure a load balancing policy for traffic class flows over the border router exit links. In this example, range and exit utilization policies are given priority when OER chooses the best exit selection for traffic class flows. Best route selection for performance policies is disabled. The external Ethernet interfaces on border router 1 and border router 2--BR1 and BR2 in the figure below--are both configured with a maximum utilization threshold of 70 percent and a range of utilization between the two exit links is set to 30 percent. After an external interface is configured for the border routers, OER automatically monitors the utilization of external links on a border router every 5 minutes. The utilization is reported back to the master controller and, if the utilization exceeds 70 percent, OER selects another exit link for traffic class flows on that link. To complete the load balancing, the utilization range between the two exit links must not be greater than 30 percent, otherwise OER will move some of the traffic classes from one exit link to another to balance the traffic load between the two exit links.
| 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.
DETAILED STEPS
| Command or Action | Purpose | |||||
|---|---|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||||
|
|
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. |
||||
|
|
Example: Router(config-oer-mc)# max-range-utilization percent 30 |
Sets the maximum utilization range for all OER-managed exit link.s. |
||||
|
|
Example: Router(config-oer-mc)# mode select-exit best |
Creates a set clause entry to configure exit selection settings.
|
||||
|
|
Example: Router(config-oer-mc)# resolve range priority 1 |
Sets policy priority or resolves policy conflicts.
|
||||
|
|
Example: Router(config-oer-mc)# resolve utilization priority 2 variance 25 |
Sets policy priority or resolves policy conflicts.
|
||||
|
|
Example: Router(config-oer-mc)# no resolve delay |
Disables any priority for delay performance policies.
|
||||
|
|
Example: Router(config-oer-mc)# no resolve loss |
Disables any priority for loss performance policies.
|
||||
|
|
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.
|
||||
|
|
Example: Router(config-oer-mc-br)# interface Ethernet 1/0 external |
Configures a border router interface as an OER-managed external interface.
|
||||
|
|
Example: Router(config-oer-mc-br-if)# max-xmit-utilization percentage 70 |
Configures the maximum utilization on a single OER managed exit link. |
||||
|
|
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. |
||||
|
|
Example: Router(config-oer-mc-br)# exit |
Exits OER-managed border router configuration mode and returns to OER master controller configuration mode. |
||||
|
|
|
-- |
||||
|
|
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. |
||||
|
|
Example: Router(config-oer-mc-learn)# end |
Exits OER Top Talker and Top Delay learning configuration mode and returns to privileged EXEC mode. |
Implementing Performance Routing Link Groups
Perform this task on a master controller to set up some performance routing link groups by identifying an exit link on a border router as a member of a link group, and to create an OER map to specify link groups for traffic classes defined in an OER policy. In this task, a link group is set up for video traffic and a set of high bandwidth exit links are identified as members of the video link group which is identified as a primary link group. A fallback link group is also specified.
An OER policy is created using an OER map where the primary and fall link groups are specified for traffic classes matching the OER map criteria. OER probes both the primary and fallback group links and selects the best link in the primary link group for the traffic class specified in this task. If none of the primary links are within policy, OER selects the bast link from the fallback group. For more details about link groups, see Performance Routing Link Grouping.
This task requires the master controller and border routers to be running Cisco IOS Release 12.4(15)T, or later release.
DETAILED STEPS
| Command or Action | Purpose | |||||
|---|---|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||||
|
|
Example: Router(config)# oer master |
Enters OER master controller configuration mode to configure a router as a master controller.
|
||||
|
|
Example: Router(config-oer-mc)# border 192.168.1.2 key-chain border1_OER |
Enters OER-managed border router configuration mode to establish communication with a border router.
|
||||
|
|
Example: Router(config-oer-mc-br)# interface Serial 2/0 external |
Configures a border router interface as an OER-managed external interface.
|
||||
|
|
Example: Router(config-oer-mc-br-if)# link-group VIDEO |
Configures an OER border router exit interface as a member of a link group.
|
||||
|
|
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. |
||||
|
|
|
-- |
||||
|
|
Example: Router(config-oer-mc-br)# interface FastEthernet 0/1 internal |
Configures a border router interface as an OER controlled internal interface.
|
||||
|
|
Example: Router(config-oer-mc-br)# exit |
Exits OER-managed border configuration mode and returns to global configuration mode. |
||||
|
|
Example: Router(config)# ip access-list extended ACCESS_VIDEO |
Defines an IP access list by name and enters extended named access list configuration mode. |
||||
|
|
Example: Router(config-ext-nacl)# permit tcp any any 500 |
Sets conditions to allow a packet to pass a named IP access list.
|
||||
|
|
|
-- |
||||
|
|
Example: Router(config-ext-nacl)# exit |
(Optional) Exits extended named access list configuration mode and returns to global configuration mode. |
||||
|
|
Example: Router(config)# oer-map VIDEO_MAP 10 |
Enters OER map configuration mode to configure an OER map. |
||||
|
|
Example: Router(config-oer-map)# traffic-class access-list ACCESS_VIDEO |
Manually configures an access list as match criteria used to create traffic classes using an OER map. |
||||
|
|
Example: Router(config-oer-map)# set link-group video fallback voice |
Specifies a link group for traffic classes defined in an OER map to create an OER policy.
|
||||
|
|
Example: Router(config-oer-map)# end |
(Optional) Exits OER map configuration mode and returns to privileged EXEC mode. |
||||
|
|
Example: Router# show oer master link-group |
Displays information about configured OER link groups. |
Examples
The example output from the show oer master link-group command displays information about performance routing link groups configured using OER. In this example, the VIDEO link group is shown with other configured link groups.
Router# show oer master link-group
link group video
Border Interface Exit id
192.168.1.2 Serial2/0 1
link group voice
Border Interface Exit id
192.168.1.2 Serial2/0 1
192.168.1.2 Serial3/0 2
192.168.3.2 Serial4/0 4
link group data
Border Interface Exit id
192.168.3.2 Serial3/0 3
Configuring OER Cost-Based Policies
Perform this task to configure cost-based optimization. Cost-based optimization is configured on a master controller using the cost-minimization command in OER border exit interface configuration mode (under the external interface configuration). Cost-based optimization supports tiered and fixed billing methods.
Cost Based Optimization can be applied to links that are billed using a fixed or tiered billing method and load balancing based on cost can also be achieved. For more configuration tasks and configuration examples, see the Configuring Performance Routing Cost Policies module.
This task requires the master controller and border routers to be running Cisco IOS Release 12.3(14)T, 12.2(33)SRB, or later releases.
DETAILED STEPS
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||
|
|
Example: Router(config)# oer master |
Enters OER master controller configuration mode to configure global prefix and exit link policies. |
||
|
|
Example: Router(config-oer-mc)# border 10.100.1.1 key-chain OER |
Enters OER-managed border router configuration mode to establish communication with a border router.
|
||
|
|
Example: Router(config-oer-mc-br)# interface ethernet 0/0 external |
Enters OER border exit interface configuration mode to configure a border router interface as an external interface. |
||
|
|
Example: Router(config-oer-mc-br-if)# cost-minimization end day-of-month 30 offset 3:00 |
Configures cost-based optimization policies on a master controller.
|
||
|
|
|
-- |
||
|
|
Example: Router(config-oer-mc-br-if)# end |
Exits OER border exit interface configuration mode and enters privileged EXEC mode. |
Configuring OER Network Security Policies
Perform one of the following two optional tasks to help prevent and mitigate attacks on your network. The first task uses the black hole routing technique, and the second task uses the sinkhole routing technique.
Configuring Black Hole Routing Using an OER Map
Perform this task to configure an OER map to filter packets to be forwarded to a null interface, meaning that the packets are discarded in a "black hole." The prefix list is configured after an IP prefix is identified as the source of the attack on the network. Some protocols such as BGP allow the redistribution of back hole routes, but other protocols do not.
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 releases.
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
|
Example: Router(config)# ip prefix-list BLACK_HOLE_LIST seq 10 permit 10.20.21.0/24 |
Creates an IP prefix list.
|
|
|
Example: Router(config)# oer-map BLACK_HOLE_MAP 10 |
Enters OER map configuration mode to configure an OER map to apply policies to selected IP prefixes.
|
|
|
Example: Router(config-oer-map)# match ip address prefix-list BLACK_HOLE_LIST |
References an extended IP access list or IP prefix as match criteria in an OER map.
|
|
|
Example: Router(config-oer-map)# set interface null0 |
Creates a set clause entry to forward packets to the null interface, meaning that they are discarded.
|
|
|
Example: Router(config-oer-map)# end |
(Optional) Exits OER map configuration mode and returns to privileged EXEC mode. |
Configuring Sinkhole Routing Using an OER Map
Perform this task to configure an OER map to filter packets to be forwarded to a next hop. The next hop is a router where the packets can be stored, analyzed, or discarded (the sinkhole analogy). The prefix list is configured after an IP prefix is identified as the source of an attack on the network.
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 releases.
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
|
Example: Router(config)# ip prefix-list SINKHOLE_LIST seq 10 permit 10.20.21.0/24 |
Creates an IP prefix list.
|
|
|
Example: Router(config-oer-mc)# oer-map SINKHOLE_MAP 10 |
Enters OER map configuration mode to configure an OER map to apply policies to selected IP prefixes.
|
|
|
Example: Router(config-oer-map)# match ip address prefix-list SINKHOLE_LIST |
References an extended IP access list or IP prefix as match criteria in an OER map.
|
|
|
Example: Router(config-oer-map)# set next-hop 10.20.21.6 |
Creates a set clause entry specifying that packets are forwarded to the next hop.
|
|
|
Example: Router(config)# end |
(Optional) Exits OER map configuration mode and returns to privileged EXEC mode. |
Configuring OER Voice Traffic Optimization Using Active Probes
Support for optimizing voice traffic using OER was introduced in 12.4(6)T. Configuring OER to optimize voice traffic using active probes involves several decisions and subsequent branching tasks. The first step is to identify the traffic to be optimized and decide whether to use a prefix list or an access list. Use a prefix list to identify all traffic, including voice traffic, with a specific set of destination prefixes. Use an access list to identify only voice traffic with a specific destination prefix and carried over a specific protocol.
The second step in optimizing voice traffic is to configure active probing using the active-probe or set active-probe command to specify the type of active probe to be used. In Cisco IOS Release 12.4(6)T, 12.2(33)SRB, the ability to set a forced target assignment for the active probe was introduced.
The final step in optimizing voice traffic is to configure an OER policy to set the performance metrics that you want OER to apply to the identified traffic.
Perform one of the first two optional tasks, depending on whether you want to use a prefix list or an access list to identify the traffic to be optimized. The third task can be used with traffic identified using an access list, and it also demonstrates how to use a forced target assignment. For an example configuration that can be used with traffic identified using a prefix list, see Optimizing Only Voice Traffic Using Active Probes.
- Identifying Traffic for OER Using a Prefix List
- Identifying Voice Traffic to Optimize Using an Access List
- Configuring OER Voice Probes with a Target Assignment
Identifying Traffic for OER Using a Prefix List
Before traffic can be measured using OER, it must be identified. Perform this task to use a prefix list to identify the traffic that OER will probe.
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode.
|
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
|
Example: Router(config)# ip prefix-list TRAFFIC_PFX_LIST seq 10 permit 10.20.21.0/24 |
Creates an IP prefix list.
|
|
|
Example: Router(config)# exit |
(Optional) Exits global configuration mode and returns to privileged EXEC mode. |
Identifying Voice Traffic to Optimize Using an Access List
Perform this task to use an access list to identify the voice traffic. Before voice traffic can be optimized, it must be identified. Voice traffic that has to be optimized must be configured because OER does not "learn" about voice traffic on IP networks during an OER learn phase.
IP Protocol Stack for Voice
Voice traffic uses a variety of protocols and streams on the underlying IP network. The figure below is a representation of the protocol options available for carrying voice traffic over IP. Most signaling traffic for voice is carried over TCP. Most voice calls are carried over User Datagram Protocol (UDP) and Real-Time Protocol (RTP). You can configure your voice devices to use a specific range of destination port numbers over UDP to carry voice call traffic.
| Figure 5 | Protocol Stack Options Available for Voice Traffic |
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 release.
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
|
|
Example: Router(config)# ip access-list extended VOICE_ACCESS_LIST |
Defines an IP access list by name. |
|
|
Example: Router(config-ext-nacl)# permit udp any range 16384 32767 10.20.20.0 0.0.0.15 range 16384 32767 |
Sets conditions to allow a packet to pass a named IP access list.
|
|
|
Example: Router(config-ext-nacl)# end |
(Optional) Exits extended access list configuration mode and returns to privileged EXEC mode. |
Configuring OER Voice Probes with a Target Assignment
After identifying the traffic (in this example, voice traffic identified using an access list) to be optimized, perform this task to configure the OER jitter probes and assign the results of the jitter probes to optimize the identified traffic. In this task, the OER active voice probes are assigned a forced target for OER instead of the usual longest match assigned target. 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 |
The device that runs the IP SLAs Responder does not have to be configured for OER. |
Note |
Policies applied in an OER map do not override global policy configurations. |
- Before configuring this task, perform the Identifying Voice Traffic to Optimize Using an Access List task.
- 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.
DETAILED STEPS
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||
|
|
Example: Router(config)# ip sla monitor responder |
Enables the IP SLAs Responder. |
||
|
|
Example: Router(config)# exit |
Exits global configuration mode and returns to privileged EXEC mode. |
||
|
|
|
-- |
||
|
|
Example: Router> enable |
Enables privileged EXEC mode. |
||
|
|
Example: Router# configure terminal |
Enters global configuration mode. |
||
|
|
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. |
||
|
|
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. |
||
|
|
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.
|
||
|
|
Example: Router(config-oer-map)# set probe frequency 10 |
Creates a set clause entry to set the frequency of the OER active probe. |
||
|
|
Example: Router(config-oer-map)# set jitter threshold 20 |
Creates a set clause entry to configure the jitter threshold value. |
||
|
|
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.
|
||
|
|
Example: Router(config-oer-map)# set resolve jitter priority 1 variance 10 |
Creates a set clause entry to configure policy priority or resolve policy conflicts.
|
||
|
|
Example: Router(config-oer-map)# set resolve mos priority 2 variance 15 |
Creates a set clause entry to configure policy priority or resolve policy conflicts.
|
||
|
|
Example: Router(config-oer-map)# set delay threshold 100 |
Creates a set clause entry to configure the delay threshold.
|
||
|
|
Example: Router(config-oer-map)# exit |
Exits OER map configuration mode and returns to global configuration mode. |
||
|
|
Example: Router(config)# oer master |
Enters OER master controller configuration mode to configure a router as a master controller.
|
||
|
|
Example: Router(config-oer-mc)# policy-rules TARGET_MAP |
Applies a configuration from an OER map to a master controller configuration in OER master controller configuration mode. |
||
|
|
Example: Router(config-oer-mc)# end |
Exits OER master controller configuration mode and enters privileged EXEC mode. |
||
|
|
Example: Router# show oer master active-probes forced |
Displays connection and status information about active probes on an OER master controller.
|
||
|
|
Example: Router# show oer master policy TARGET_MAP |
Displays policy settings 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 forced
OER Master Controller active-probes
Border = Border Router running this Probe
Policy = Forced target is configure under this policy
Type = Probe Type
Target = Target Address
TPort = Target Port
N - Not applicable
The following Forced Probes are running:
Border State Policy Type Target TPort
10.20.20.2 ACTIVE 40 jitter 10.20.22.1 3050
10.20.21.3 ACTIVE 40 jitter 10.20.22.4 3050
What to do Next
For further configuration examples of OER voice traffic optimization, see the Configuring OER Voice Traffic Optimization Using Active Probes Examples.
Configuration Examples for Configuring and Applying OER Policies
- Configuring and Applying an OER Policy to Learned Traffic Classes Example
- Configuring and Applying an OER Policy to Configured Traffic Classes Example
- Preventing OER Optimization of Learned Prefixes Example
- Configuring and Applying an OER Policy to Learned Inside Prefixes Example
- Configuring and Applying an OER Policy to Configured Inside Prefixes Example
- Configuring Policy Rules for OER Maps Example
- Configuring Multiple OER Policy Conflict Resolution Example
- Configuring an Exit Link Load Balancing OER Policy Example
- Implementing Performance Routing Link Groups Example
- Configuring OER Cost-Based Policies Example
- Configuring OER Network Security Policies Examples
- Configuring OER Voice Traffic Optimization Using Active Probes Examples
Configuring and Applying an OER Policy to Learned Traffic Classes Example
The following example uses learned traffic classes and overwrites many of the default policy settings and configures the master controller to move traffic classes to the best available exit link when any of the configured or default policy settings exceed their thresholds:
enable configure terminal oer master backoff 200 2000 200 delay threshold 2000 holddown 400 loss threshold 1500 periodic 180 unreachable threshold 1000 mode select-exit best end
Configuring and Applying an OER Policy to Configured Traffic Classes Example
The following example uses traffic classes filtered by a prefix list and an access list and overwrites some of the default policy settings. The policies are configured using two OER maps that apply to different traffic classes that represent voice traffic. The master controller is configured to move traffic classes to the first in-policy exit link when any of the configured or default policy settings exceed their thresholds. To run this task, both the master controller and border routers must be running Cisco IOS Release 12.4(9)T, 12.2(33)SRB, or later releases.
enable configure terminal ip prefix-list CONFIG_TRAFFIC_CLASS seq 10 permit 10.1.5.0/24 ip access-list extended VOICE_TRAFFIC_CLASS permit udp any range 16384 32767 10.1.5.0 0.0.0.15 range 16384 32767 dscp ef exit oer-map CONFIG_MAP 10 match ip address prefix-list CONFIG_TRAFFIC_CLASS set backoff 100 1000 100 set delay threshold 1000 set loss relative 25 set periodic 360 set unreachable relative 20 exit oer-map VOICE_MAP 10 match ip address access-list VOICE_TRAFFIC_CLASS set active-probe jitter 10.1.5.1 target-port 2000 codec g729a set probe-frequency 20 set jitter threshold 30 set mos threshold 4.0 percent 25 set mode select-exit good end
Preventing OER Optimization of Learned Prefixes Example
The following example shows how to configure OER to prevent specified prefixes being optimized. In this example, an IP prefix list is created with two entries for different prefixes that are not to be optimized. An OER map is configured with two entries in a sequence that will prevent OER from optimizing the prefixes specified in the prefix list, although the prefixes may be learned. If the sequence numbers of the OER map entries are reversed, OER will learn and attempt to optimize the prefixes.
enable configure terminal ip prefix-list DENY_PREFIX deny 172.17.10.0/24 ip prefix-list DENY_PREFIX deny 172.19.10.0/24 oer-map DENY_PREFIX_MAP 10 match ip address prefix-list DENY_PREFIX exit oer-map DENY_PREFIX_MAP 20 match oer learn throughput end
Configuring and Applying an OER Policy to Learned Inside Prefixes Example
The following example shows how to apply an OER policy to learned inside prefixes:
enable configure terminal oer-map INSIDE_LEARN 10 match oer learn inside set delay threshold 2000 set loss relative 20 set unreachable relative 90 end
Configuring and Applying an OER Policy to Configured Inside Prefixes Example
The following example shows how to create an OER map named INSIDE_CONFIGURE and apply an OER policy to manually configured inside prefixes:
enable configure terminal oer-map INSIDE_CONFIGURE 10 match ip address prefix-list INSIDE_PREFIXES inside set delay threshold 2000 set loss relative 20 set unreachable relative 80 end
Configuring Policy Rules for OER Maps Example
The following example shows how to configure the policy-rules command to apply the OER map configuration named BLUE under OER master controller mode:
enable configure terminal oer-map BLUE 10 match oer learn delay set loss relative 90 exit oer master policy-rules BLUE exit
Configuring Multiple OER Policy Conflict Resolution Example
The following example configures an OER resolve policy that sets delay to the highest priority, followed by loss, and then utilization. The delay policy is configured to allow a 20 percent variance, the loss policy is configured to allow a 30 percent variance, and the utilization policy is configured to allow a 10 percent variance.
enable configure terminal oer master resolve delay priority 1 variance 20 resolve loss priority 2 variance 30 resolve utilization priority 3 variance 10 end
Configuring an Exit Link Load Balancing OER Policy Example
The following example configures an OER load balancing policy for traffic class flows over the border router exit links. This example task is performed at the master controller and configures an exit link utilization range and an exit link utilization threshold with policy priorities set for utilization and range policies. Performance policies, delay and loss, are disabled. OER uses both the utilization and range thresholds to load balance the traffic flow over the exit links.
enable configure terminal oer master max-range-utilization percentage 25 mode select-exit best resolve range priority 1 resolve utilization priority 2 variance 15 no resolve delay no resolve loss border 10.1.4.1 interface Ethernet 1/0 external max-xmit-utilization absolute 10000 exit exit border 10.1.2.1 interface Ethernet 1/0 external max-xmit-utilization absolute 10000 end
Implementing Performance Routing Link Groups Example
The following example shows how to implement link groups. In this example, an OER map named VIDEO_MAP is created to configure OER to define a traffic class that matches an access list named ACCESS_VIDEO. The traffic class is configured to use a link group named VIDEO as the primary link group, and a fallback group named VOICE. The VIDEO link group may be a set of high bandwidth links that are preferred for video traffic.
enable configure terminal border 10.1.4.1 interface serial 2/0 external link-group VIDEO exit interface serial 3/0 external link-group VOICE exit interface Ethernet 1/0 internal exit ip access-list extended ACCESS_VIDEO permit tcp any 10.1.1.0 0.0.0.255 eq 500 permit tcp any 172.17.1.0 0.0.255.255 eq 500 permit tcp any 172.17.1.0 0.0.255.255 range 700 750 permit tcp 192.168.1.1 0.0.0.0 10.1.2.0 0.0.0.255 eq 800 any any dscp ef exit oer-map VIDEO_MAP 10 match traffic-class access-list ACCESS_VIDEO set link-group VIDEO fallback VOICE end
Configuring OER Cost-Based Policies Example
The following example shows how to configure cost-based optimization on a master controller. Cost optimization configuration is applied under the external interface configuration. In this example, a policy for a tiered billing cycle is configured that sets a tiered fee of 1000 at 100 percent utilization, a tiered fee of 900 at 90 percent utilization, and a tiered fee of 800 at 80 percent utilization. Calculation is configured separately for egress and ingress samples. The time interval between sampling is set to 10 minutes and these samples are configured to be rolled up every 60 minutes.
enable configure terminal oer master border 10.5.5.55 key-chain key interface Ethernet 0/0 external cost-minimization nickname ISP1 cost-minimization end day-of-month 30 180 cost-minimization calc separate cost-minimization sampling 10 rollup 60 cost-minimization tier 100 fee 1000 cost-minimization tier 90 fee 900 cost-minimization tier 80 fee 800 exit
Cost Based Optimization can be applied to links that are billed using a fixed or tiered billing method and load balancing based on cost can also be achieved. For more configuration tasks and examples, see the Configuring Performance Routing Cost Policies module.
Configuring OER Network Security Policies Examples
Black Hole Routing Example
The following example creates an OER map named BLACK_HOLE_MAP that matches traffic defined in the IP prefix list named PREFIX_BLACK_HOLE. The OER map filters packets to be forwarded to a null interface, meaning that the packets are discarded in a "black hole." The prefix list is configured after an IP prefix is identified as the source of the attack on the network.
enable configure terminal ip prefix-list PREFIX_BLACK_HOLE seq 10 permit 10.1.5.0/24 oer-map BLACK_HOLE_MAP 10 match ip address prefix-list PREFIX_BLACK_HOLE set interface null0 end
Sink Hole Routing Example
The following example creates an OER map named SINK_HOLE_MAP that matches traffic defined in the IP prefix list named PREFIX_SINK_HOLE. The OER map filters packets to be forwarded to a next hop. The next hop is a router where the packets can be stored, analyzed, or discarded (the sinkhole analogy). The prefix list is configured after an IP prefix is identified as the source of an attack on the network.
enable configure terminal ip prefix-list PREFIX_SINK_HOLE seq 10 permit 10.1.5.0/24 oer-map SINK_HOLE_MAP 10 match ip address prefix-list PREFIX_SINK_HOLE set next-hop 10.1.1.3 end
Configuring OER Voice Traffic Optimization Using Active Probes Examples
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.
The following examples show both how to use an access list to identify only voice traffic to be optimized by OER and to use a prefix list to identify traffic that includes voice traffic to be optimized by OER.
- Optimizing Only Voice Traffic Using Active Probes
- Optimizing Traffic (Including Voice Traffic) Using Active Probes
Optimizing Only Voice Traffic Using Active Probes
The figure below shows that voice traffic originating at the remote office and terminating at the headquarters has to be optimized to select the best path out of the remote office network. Degradation in voice (traffic) quality is less likely to be introduced within the network, so probing the edge of the network gives a measurement that is close to probing the final destination.
| Figure 6 | OER Network Topology Optimizing Voice Traffic Using Active Probes |
This configuration optimizes voice traffic to use the best performance path, whereas all other traffic destined to the same network--10.1.0.0/16--will follow the best path as indicated by a traditional routing protocol, for example BGP, that is configured on the device. As part of this optimization, OER will use policy based routing (PBR) to set the best exit link for voice traffic within a device.
The following configuration is performed on the edge router R1 in the figure above in the headquarters network to enable the IP SLAs Responder.
enable configure terminal ip sla responder exit
The following configuration is performed on the edge router MC/BR (which is both an OER master controller and border router) in the figure above in the remote office network to optimize voice traffic using active probes.
enable configure terminal ip access-list extended Voice_Traffic 10 permit udp any 10.1.0.0 0.0.255.255 range 16384 32767 exit oer-map Voice_MAP 10 match ip address access-list Voice_Traffic set active-probe jitter 10.1.1.1 target-port 1025 codec g711alaw set delay threshold 300 set mos threshold 3.76 percent 30 set jitter threshold 15 set loss relative 5 resolve mos priority 1 resolve jitter priority 2 resolve delay priority 3 resolve loss priority 4
Optimizing Traffic (Including Voice Traffic) Using Active Probes
The figure below shows that traffic originating in the headquarters network and destined for the remote office network has to be optimized based on voice traffic metrics. Voice traffic is one of the most important traffic classes that travel from the headquarters to the remote office network, so the voice traffic must be prioritized to be optimized. Degradation in voice packet quality is less likely to be introduced within the network, so probing the edge of the network gives a measurement that is close to probing the final destination.
| Figure 7 | OER Network Topology for Optimizing All Traffic Using Active Probes |
This configuration optimizes all traffic, including voice traffic, destined for the10.12.0.0/16 network. The OER optimization is based on the measurement of voice performance metrics with threshold values using active probes. As part of the optimization, OER will introduce a BGP or a static route into the headquarters network. For more details about BGP and static route optimization, see the Using OER to Control Traffic Classes and Verify the Route Control Changes module.
The following configuration is performed on router R1 in the figure above in the remote office network to enable the IP SLAs Responder.
enable configure terminal ip sla responder exit
The following configuration is performed on one of the BR routers in the figure above in the headquarters network to optimize all traffic (including voice traffic) using active probes.
enable configure terminal ip prefix-list All_Traffic_Prefix permit 10.12.0.0/16 oer-map Traffic_MAP 10 match ip address prefix-list All_Traffic_Prefix set active-probe jitter 10.12.1.1 target-port 1025 codec g711alaw ! port 1025 for the target probe is an example. set delay threshold 300 set mos threshold 3.76 percent 30 set jitter threshold 15 set loss relative 5 resolve mos priority 1 resolve jitter priority 2 resolve delay priority 3 resolve loss priority 4
Where to Go Next
This module covered the OER apply policy phase and it has assumed that you started with the Cisco IOS Optimized Edge Routing Overview and the Setting Up OER Network Components module. The apply policy phase is the third phase in the OER performance loop. To learn more about the other OER phases, read through the other modules in the following list:
- Using OER to Profile the Traffic Classes
- Measuring the Traffic Class Performance and Link Utilization Using OER
- Configuring and Applying OER Policies
- Configuring Performance Routing Cost Policies
- Using OER to Control Traffic Classes and Verify the Route Control Changes
- Using Performance Routing to Control EIGRP Routes with mGRE DMVPN Hub-and-Spoke Support
Additional References
Related Documents
| Related Topic |
Document Title |
|---|---|
| Cisco IOS Master Command List |
http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html |
| Command Lookup Tool |
|
| Cisco OER technology overview |
|
| Concepts and configuration tasks required to set up OER network components. |
|
| Cisco OER commands: complete command syntax, command mode, command history, defaults, usage guidelines and examples |
Technical Assistance
| Description |
Link |
|---|---|
| The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. |
Feature Information for Configuring and Applying OER Policies
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
| Table 1 | Feature Information for Configuring and Applying OER Policies |
| Feature Name |
Releases |
Feature Configuration Information |
|---|---|---|
| Optimized Edge Routing |
12.3(8)T 12.2(33)SRB |
OER was introduced. |
| OER Support for Policy-Rules Configuration |
12.3(11)T 12.2(33)SRB |
The OER Support for Policy-Rules Configuration feature introduced the capability to select an OER map and apply the configuration under OER master controller configuration mode, providing an improved method to switch between predefined OER maps. The following commands were introduced or modified by this feature: policy-rules. |
| OER Support for Cost-Based Optimization |
12.3(14)T 12.2(33)SRB |
The OER Support for Cost-Based Optimization feature introduced the capability to configure exit link policies based monetary cost and the capability to configure traceroute probes to determine prefix characteristics on a hop-by-hop basis. The following commands were introduced or modified by this feature: cost-minimization, debug oer master cost-minimization, show oer master cost-minimization. |
| OER Voice Traffic Optimization |
12.4(6)T 12.2(33)SRB |
The 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 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 master policy, show oer master prefix. |
| OER BGP Inbound Optimization |
12.4(9)T 12.2(33)SRB |
OER 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 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)SRB |
OER 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 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. |
| Performance Routing - Link Groups |
12.4(15)T |
The Performance Routing - Link Groups feature introduces the ability to define a group of exit links as a preferred set of links, or a fallback set of links for OER to use when optimizing traffic classes specified in an OER policy. The following commands were introduced or modified by this feature: link-group, set link-group, and show oer master link-group. |
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned 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. (1005R)
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.
Feedback