In medium to large networks there are hundreds of thousands of routes in the RIB to which a device is trying to route traffic. Because performance routing is a means of preferring some traffic over another, a subset of the total routes in the RIB has to be selected to optimize for performance routing. In the OER profile phase this selection of the subset of total traffic flowing through a device or a network is accomplished in a combination of ways:

• The device profiles the traffic that has to be performance routed (optimized) by learning the flows that pass through the device and by selecting those flows that have the lowest delay or the highest throughput.
• In addition to, or instead of learning, you can configure a class of traffic to performance route.

After you have profiled a group of traffic classes that are to be performance routed, the network has to measure the performance metrics of these individual traffic classes. There are two mechanisms--passive monitoring and active monitoring--to measure performance metrics, and one or both could be deployed in the network to accomplish this task. Monitoring is the act of measuring at periodic intervals.

Passive monitoring is the act of measuring the performance metrics of the traffic flow as the flow is traversing the device in the data path. Passive monitoring cannot be employed for measuring performance metrics for some traffic classes, and there are some hardware or software limitations.

Active monitoring consists of generating synthetic traffic to emulate the traffic class that is being monitored. The synthetic traffic is measured instead of the actual traffic class. Then the results of the synthetic traffic monitoring are applied to performance route the traffic class represented by the synthetic traffic.

You can also deploy both passive and active monitoring modes in an automated flow. The passive monitoring phase may detect traffic class performance that does not conform to an OER policy, and then active monitoring can be applied to that traffic class to find the best alternate performance path, if available. For more details about OER policies, see the OER Apply Policy Phase section.

After collecting the performance metrics of the class of traffic that you want to optimize, OER compares the results with a set of configured low and high thresholds for each metric. When a metric, and consequently a policy, goes out of bounds, it is an Out-of-Policy (OOP) event. The results are compared on a relative basis--a deviation from the observed mean--or on a threshold basis--the lower or upper bounds of a value--or a combination of both.

There are two types of policies that can be defined in OER: traffic class policies and link policies. Traffic class policies are defined for prefixes or for applications. Link policies are defined for exit or entrance links at the network edge. Both types of OER policies define the criteria for determining an OOP event. The policies are applied on a global basis in which a set of policies is applied to all traffic classes, or on a more targeted basis in which a set of policies is applied to a selected (filtered) list of traffic classes.

With multiple policies, many performance metric parameters, and different ways of assigning these policies to traffic classes, a method of resolving policy conflicts was created. The default arbitration method uses a default priority level given to each performance metric variable and each policy. You can configure different priority levels that overrides the default arbitration for all policies, or a selected set of policies.

In the OER control phase (also called the enforce phase) of the performance loop, the traffic is controlled to enhance the network performance time. The technique used to control the traffic depends on the class of traffic. For traffic classes that are defined using a prefix only, the prefix reachability information used in traditional routing can be manipulated. Protocols such as Border Gateway Protocol (BGP) or RIP are used to announce or remove the prefix reachability information by introducing or deleting a route and its appropriate cost metrics.

For traffic classes that are defined by an application in which a prefix and additional packet matching criteria are specified, OER cannot employ traditional routing protocols because routing protocols communicate the reachability of the prefix only and the control becomes device specific and not network specific. This device specific control is implemented by OER using policy-based routing (PBR) functionality. If the traffic in this scenario has to be routed out to a different device, the remote border router should be a single hop away or a tunnel interface that makes the remote border router look like a single hop.

During the OER control phase if a traffic class is OOP, then OER introduces controls to influence (optimize) the flow of the traffic for the traffic class that is OOP. A static route and a BGP route are examples of controls introduced by OER into the network. After the controls are introduced, OER will verify that the optimized traffic is flowing through the preferred exit or entrance links at the network edge. If the traffic class remains OOP, OER will drop the controls that were introduced to optimize the traffic for the OOP traffic class and cycle through the network performance loop.

The diagram below shows a typical OER-managed enterprise network of a content provider. The enterprise network has three exit interfaces that are used to deliver content to customer access networks. The content provider has a separate service level agreement (SLA) with a different ISP for each exit link. The customer access network has two edge routers that connect to the Internet. Traffic is carried between the enterprise network and the customer access network over six service provider (SP) networks.

OER monitors and controls outbound traffic on the three border routers (BRs). In Cisco IOS Release 12.4(9)T, 12.2(33)SRB and later releases, the ability to monitor and control inbound traffic was introduced. OER measures the packet response time and path availability from the egress interfaces on BR1, BR2 and BR3. Changes to exit link performance on the border routers are detected on a per-prefix basis. If the performance of a prefix falls below default or user-defined policy parameters, routing is altered locally in the enterprise network to optimize performance and to route around failure conditions that occur outside of the enterprise network. For example, an interface failure or network misconfiguration in the SP D network can cause outbound traffic that is carried over the BR2 exit interface to become congested or fail to reach the customer access network. Traditional routing mechanisms cannot anticipate or resolve these types of problems without intervention by the network operator. OER can detect failure conditions and automatically alter routing inside of the network to compensate.

OER is configured on Cisco routers using Cisco IOS command-line interface (CLI) configurations. An OER deployment has two primary components, a master controller and one or more border routers. The master controller is the intelligent decision maker, while the border routers are enterprise edge routers with exit interfaces that are either used to access the Internet or used as WAN exit links.