Table Of Contents
Cisco IOS Optimized Edge Routing Configuration
Prerequisites for Cisco IOS Optimized Edge Routing
Restrictions for Cisco IOS Optimized Edge Routing
Information About Cisco IOS Optimized Edge Routing
Cisco IOS Optimized Edge Routing Overview
Cisco IOS OER: A Typical Deployment
Cisco IOS OER: Optimizes for Performance
Cisco IOS OER Network Components
Cisco IOS OER Network Components: Master Controller
Cisco IOS OER Network Components: Border Router
Cisco IOS OER Network Components: Interfaces
Cisco IOS OER Managed Network: Central Policy Database
Cisco IOS OER Managed Network: Policy Enforcement Point
Cisco IOS OER Prefix Learning: Automatic Prefix Learning
Cisco IOS OER Prefix Learning: Manually Selecting Prefixes
Cisco IOS OER Prefix Learning: Port and Protocol Based Prefix Learning
Cisco IOS OER Prefix Learning: Prefix Transition States
Cisco IOS OER Monitoring: Passive Monitoring
Cisco IOS OER Monitoring: Active Monitoring
Cisco IOS OER Monitoring: Active Probe Source Address
Cisco IOS OER Monitoring: Combined Monitoring
Cisco IOS OER Monitoring: Traceroute Reporting
Cisco IOS OER Modes of Operation
Cisco IOS OER Modes of Operation: Observe Mode
Cisco IOS OER Modes of Operation: Control Mode
Cisco IOS OER Routing: Border Router Peering with the Internal Network
Cisco IOS OER Routing: BGP Peering
Cisco IOS OER Routing: BGP Redistribution into an IGP
Cisco IOS OER Routing: BGP Redistribution Based on the BGP Local-Preference Attribute
Cisco IOS OER Routing: Static Routing and Static Route Redistribution
Cisco IOS OER Routing: Injecting Split Prefixes
Cisco IOS OER Policy Configuration
Cisco IOS OER Policy Configuration: Prefix Policies
Cisco IOS OER Policy Configuration: Exit Link Policies
Cisco IOS OER Policy Configuration: Cost-Based Optimization
Cisco IOS OER Policy Configuration: Optimal Exit Link Selection
Cisco IOS OER Policy Configuration: Load Distribution
Cisco IOS OER Policy Configuration: Global Policies
Cisco IOS OER Policy Configuration: Applying Policies with an OER Map
Cisco IOS OER Policy Configuration: Resolving Policies
VPN IPSec/GRE Tunnel Interface Optimization
Cisco IOS OER Logging and Reporting
Cisco IOS OER Deployment Configurations
How to Configure Cisco IOS Optimized Edge Routing
Minimum Master Controller Configuration
Disabling a Master Controller Process
Minimum Border Router Configuration
Disabling a Border Router Process
Manually Selecting Prefixes for Monitoring
Active Probing over eBGP Peerings
Configuring the Source Address of an Active Probe
Configuring Traceroute Reporting
Configuring Prefix and Exit Link Policies
Adjusting Cisco IOS OER Timers
Configuring Cost-Based Optimization
Setting Variance for Resolve Policies
Configuring Cisco IOS OER Modes of Operation
Configuring OER Policies with an OER Map
Configuring Policy Rules for OER Maps
Configuring iBGP Peering on the Border Routers
Configuring BGP Redistribution into an IGP on the Border Routers
Configuring Static Route Redistribution on the Border Routers
Configuring Static Route Redistribution into EIGRP
Configuring OER to Monitor and Control IPSec VPN Prefixes Over GRE Tunnels
Routing Prefixes that are Protected with IPSec over GRE Tunnels
GRE Tunnel Interfaces are Configured as OER Managed Exit Links
Master Controller Configuration
Verifying Cisco IOS OER Configuration
Using Cisco IOS OER Clear Commands
Using Cisco IOS OER Debug Commands
Configuration Examples for Cisco IOS Optimized Edge Routing
Master Controller and Two Border Routers Deployment: Example
Master Controller and Border Router Deployed on a Single Router: Example
BR 1 Configuration: Master/Border with Load Distribution
Configuring OER to Monitor and Control GRE/IPSec VPN Prefixes: Example
Central VPN Configuration: OER Master
Central VPN Configuration: BR1
Central VPN Configuration: BR 2
Central VPN Configuration: Internal Peers
VPN B Configuration: OER Master
VPN B Configuration: Internal Peers
debug oer border traceroute reporting
debug oer master cost-minimization
debug oer master traceroute reporting
show oer border passive prefixes
show oer master cost-minimization
Cisco IOS Optimized Edge Routing Configuration
Cisco IOS Optimized Edge Routing (OER) provides automatic route optimization and load distribution for multiple ISP and WAN connections. Cisco IOS OER is an integrated Cisco IOS solution that allows you to monitor IP traffic flows and then define policies and rules based on prefix performance, link load distribution, link cost, and traffic type. Cisco IOS OER provides active and passive monitoring systems, dynamic failure detection, and automatic path correction. Deploying Cisco IOS OER enables intelligent load distribution and optimal route selection in an enterprise network.
Feature History for Optimized Edge Routing
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for Cisco IOS Optimized Edge Routing
•
•
•
•
Prerequisites for Cisco IOS Optimized Edge Routing
•
•
•
•
If you have configured internal BGP (iBGP) on the border routers, iBGP peering must be established and consistently applied throughout your network.
If an IGP is deployed in your network, static route redistribution must be configured with the redistribute static command. Interior Gateway Protocol (IGP) or static routing should also be applied consistently throughout an OER managed network; the border router should have a consistent view of the network.
Restrictions for Cisco IOS Optimized Edge Routing
•
•
•
•
•
•
•
•
Information About Cisco IOS Optimized Edge Routing
To configure Cisco IOS Optimized Edge Routing (OER), you should understand the following concepts:
•
•
•
•
•
•
•
•
•
•
Cisco IOS Optimized Edge Routing Overview
Enterprise networks use multiple ISP or WAN connections for reliability and load distribution. Existing reliability mechanisms depend on link state or route removal on the border router to select a better exit link for a prefix or set of prefixes. Multiple connections protect enterprise networks from catastrophic failures but do not protect the network from "brown outs" or soft failures that occur due to network congestion. Existing mechanisms can respond to catastrophic failures at the first indication of a problem. However, black outs and brown outs can go undetected and often require the network operator to take action to resolve the problem. When a packet is transmitted between external networks (nationally or globally), the packet spends the vast majority its life cycle on the WAN segments of the network. Optimizing WAN route selection in the enterprise network provides the end-user with the greatest performance improvement, even better than LAN speed improvements in the local network.
Cisco IOS OER is implemented in Cisco IOS software as an integrated part of Cisco core routing functionality. Deploying Cisco IOS OER enables intelligent network traffic load distribution and dynamic failure detection for data paths at the wide-area network (WAN) edge. While other routing mechanisms can provide both load distribution and failure mitigation, Cisco IOS OER is unique in that it can make routing adjustments based on criteria other than static routing metrics, such as response time, packet loss, path availability, and traffic load distribution. Deploying Cisco IOS OER allows you to optimize network performance and link load utilization while minimizing bandwidth costs and reducing operational expenses.
Cisco IOS OER: A Typical Deployment
Figure 1 shows a Cisco IOS 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.
Figure 1 A Typical Cisco IOS Optimized Edge Routing Deployment
Cisco IOS OER monitors and controls outbound traffic on the three border routers (BRs). It 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 problem without intervention by the network operator. Cisco IOS OER can detect failure conditions and alter routing inside of the network to compensate.
Cisco IOS OER: Optimizes for Performance
Traditional routing mechanisms rely upon reachability information to make routing decisions but cannot enforce performance policies. Cisco IOS OER optimizes routing to improve performance in the enterprise network. Prefix policies are defined to control the performance of a single prefix or a prefix range. You can configure Cisco IOS OER to monitor and control the performance of a single host route or routes from an entire network. Exit link policies are defined to control the performance of exit interfaces in an OER managed network. Performance policies can be defined for a single exit link or all exit links in the OER managed network.
Figure 2 shows a Cisco IOS OER managed enterprise network of a content provider. This figure shows that delay measurements are collected for monitored prefixes on the border routers. These statistics are collected by the border routers an then transmitted to the master controller.
Figure 2 Cisco IOS OER Optimizes for Performance
For example, if a performance policy is defined that sets the delay threshold for a group of prefixes to less than or equal to 200 milliseconds (ms), as shown in Figure 2. Prefixes with a slower round-trip response time (or longer delay) will be considered to be out-of-policy. Routing is locally altered to bring the prefix to an in-policy state. In Figure 2, out-of-policy prefixes that use exit links on BR3 will be moved to BR1.
The master controller monitors prefixes and exit links on the border routers. This allows the master controller to measure performance and detect failure conditions that occur outside of the network. When the master controller detects a performance change that brings a prefix out of policy, the master controller sends commands to the border routers to dynamically alter routing inside of the enterprise network to bring prefix performance back within default or user-defined policy. If all prefixes and exit links are in policy, the master controller continues to monitor the network and does not take any action.
Cisco IOS OER Network Components
Cisco IOS OER is configured on Cisco routers though standard Cisco IOS CLI configuration. 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 used to access the Internet or used as WAN exit links.
Cisco IOS OER Network Components: Master Controller
The master controller is a single router that coordinates all OER functions within an OER managed network. A Cisco router can be configured to run a stand-alone master controller process or can also be configured to perform other functions, such as routing or running a border router process. The master controller maintains communication and authenticates the sessions with the border routers. The master controller monitors outbound traffic flows using active or passive monitoring and then applies default or user-defined policies to alter routing to optimize prefixes and exit links. OER administration and control is centralized on the master controller, which makes all policy decisions and controls the border routers. The master controller does not need to be in the traffic forwarding path, but it must be reachable by the border routers. The master controller can support up to 10 border routers and up to 20 OER managed external interfaces.
Note
Cisco IOS OER Network Components: Border Router
The border router is an enterprise edge router with one or more exit links to an ISP or other participating network. The border router is where all policy decisions and changes to routing in the network are enforced. The border router participates in prefix monitoring and route optimization by reporting prefix and exit link measurements to the master controller and then by enforcing policy changes received from the master controller. The border router enforces policy changes by injecting a preferred route to alter routing in the network. The border router is deployed on the edge of the network, so the border router must be in the forwarding path. A border router process can be enabled on the same router as a master controller process.
Cisco IOS OER Network Components: Interfaces
An OER managed network must have at least two external interfaces that are used to forward traffic to the external network (WAN or ISP) and at least one internal interface that is used for passive monitoring. There are three interface configurations required to deploy OER:
•
•
•
Tip
The following interface types can be configured as external and internal interfaces:
•
•
•
•
•
•
•
•
•
•
•
•
Note
The following interface types can be configured as local interfaces:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
Cisco IOS OER Managed Network
Figure 3 shows an OER managed network. This network contains a master controller and two border routers. OER communication between the master controller and the border routers is carried separately from routing protocol traffic. This communication is protected by MD5 authentication. Each border router has an external interface that is connected to a different ISP or WAN link to a remote site and a local and an internal interface that are reachable by the master controller.
Figure 3 Cisco IOS OER Managed Network
External interfaces are used to forward outbound traffic from the network and are used as the source for active monitoring. Internal interfaces are used for OER communication and used for passive monitoring. At least one external and one internal interface must be configured on each border router. At least two external interfaces are required in an OER managed network. A local interface is configured on the border router for communication with the master controller.
Cisco IOS OER Managed Network: Central Policy Database
The master controller continuously monitors the network. The master controller maintains a central policy database where it stores collected statistical information. The master controller compares long-term and short-term measurements. The long-term measurements are collected every 60 minutes. Short term measurements are collected every five minutes. The master controller analyzes these statistics to determine which routes have the lowest delay, highest outbound throughput, relative or absolute packet loss, relative or absolute link cost, and prefix reachability to analyze and optimize the performance of monitored prefixes and to distribute the load from over-utilized exit links to under-utilized exit links.
Cisco IOS OER Managed Network: Policy Enforcement Point
The border router is the policy enforcement point. Default or user-defined policies are configured on the master controller to set the performance level for prefixes and exit links. The master controller automatically alters routing in the OER managed network, as necessary, by sending control commands to the border routers to inject a preferred route. The preferred route is advertised or redistributed through the internal network. The preferred route alters default routing behavior so that out of policy prefixes are moved from over utilized exit links to under utilized exit links to bring prefixes and exit links in-policy, and thus optimizing the overall performance of the enterprise network.
Cisco IOS OER Prefix Learning
To enable Cisco IOS OER in your network prefixes must be identified to monitor and optimize. A Cisco router configured as a master controller will learn and monitor up to 2500 prefixes by default and can configured to learn and monitor up to 5000 prefixes with the max prefix total command in OER master controller configuration mode. Prefixes can be learned automatically or can manually selected.
Cisco IOS OER Prefix Learning: Automatic Prefix Learning
The master controller can be configured, using Top Talker functionality, to learn prefixes automatically based on highest outbound throughput or lowest delay time. Throughput learning measures prefixes that generate the highest outbound traffic volume. Throughput prefixes are sorted from highest to lowest. Delay learning measures prefixes with the lowest round-trip response time (RTT). Delay prefixes are sorted from the lowest to the highest delay time.
Automatic prefix learning is configured in OER Top Talker and Delay learning configuration mode. The learn command is used to enter this mode from OER master controller configuration mode. When automatic prefix learning is enabled, prefixes and their delay and/or throughput characteristics are learned, and this is information is stored in the central policy database. Prefixes are learned for 5 minutes by default. The master controller analyzes these statistics and implements policy decisions as necessary.
Prefixes are learned on the border routers through passive monitoring. Prefix learning is configured on the master controller. The border routers monitor all incoming and outgoing traffic flows. The top 100 flows are learned by default, and up to 5000 flows can be learned.
Learned prefixes can be aggregated based the prefix type, BGP or non-BGP (static routes), or the prefix length. Traffic flows are aggregated using a /24 prefix length by default. Prefix aggregation can be configured to include any subset or superset of a major network, including a single host route (/32). For each aggregated prefix, up to five host addresses are selected to use as active probe targets. Prefix aggregation is configured with the aggregation-type command in OER Top Talker and Delay learning configuration mode.
Cisco IOS OER Prefix Learning: Manually Selecting Prefixes
A prefix or range of prefixes can be selected for monitoring by configuring an IP prefix list. The IP prefix list is then imported into the master controller database by configuring a match clause in an OER map. IP prefix-lists are configured with the ip prefix-list command and OER maps are configured with the oer-map command in global configuration mode.
The following IP prefix list configuration options are supported:
•
•
•
•
Traffic is excluded or included by configuring permit or deny statements in the IP prefix list.
For best performance, you should apply the most commonly referenced prefix lists and deny prefix lists to the lowest (or first) OER map sequences.
Cisco IOS OER Prefix Learning: Port and Protocol Based Prefix Learning
Port and Protocol Based Prefix Learning was introduced in Cisco IOS Release 12.3(11)T. This feature allows you to configure the master controller to learn traffic based on the protocol number or the source or destination port number, carried by TCP or UDP traffic. This feature provides a very granular filter that can be used to further optimize prefixes learned based on throughput and delay.
Port and protocol based prefix learning allows you to optimize or exclude traffic streams for a specific protocol or the TCP port, UDP port, or range of port numbers. Traffic can be optimized for a specific application or protocol. Uninteresting traffic can be excluded, allowing you to focus router system resources, and reduce unnecessary CPU and memory utilization. In cases where traffic streams need to be excluded or included over ports that fall above or below a certain port number, the range of port numbers can be specified. Port and protocol prefix based learning is configured with the protocol command in OER Top Talker and Delay learning configuration mode.
For a list of IANA assigned port numbers, refer to the following document:
•
For a list of IANA assigned protocol numbers, refer to the following document:
•
Cisco IOS OER Prefix Learning: Prefix Transition States
Monitored prefixes pass through the following states when imported into the central policy database or when a default or user-defined policy is applied:
Default—A prefix is placed in this state when it is not under OER control. All routing decisions for the prefix are controlled by existing metrics determined by the default routing protocol. Prefixes are placed in the default state when they are initially added to the central policy database. A prefix will transition into and out of the default state depending on policy configuration and performance measurements.
In-Policy—A prefix is placed in this state when the status of the prefix exit conforms to default or user-defined policies. No changes are made when a prefix is in the in-policy state. The master controller continues to monitor the prefix and will take no action until the policy configuration or performance measurements change.
Out-of-Policy—A prefix is placed in this state when the prefix exit does not conform to default or user-defined policies. The master controller will use active probing and/or passive monitoring to find a better exit for the prefix, while the prefix is in this state. If all exit links are out-of-policy, the master controller will select the best available exit.
Choose—A prefix is placed in this state by the master controller during exit link selection. The prefix remains in the choose state until it is moved to the new exit.
Holddown—A prefix is placed in this state when the master controller moves a prefix to a new exit. No policy changes are applied to a prefix in the holddown state. The holddown state is designed to isolate the prefix during the transition period to prevent the prefix from causing instability due to rapid state changes (flapping).
Note
Cisco IOS OER Monitoring
Cisco IOS OER monitors prefix performance over OER managed exit links to ensure that OER controlled prefixes and exit links conform to policy parameters. Prefixes are passively monitored with integrated NetFlow functionality and are actively monitored with integrated IP Service Level Agreements (IP SLAs) functionality. No explicit NetFlow or IP SLAs configuration is required. Support for these features are enabled automatically as necessary.
The master controller can be configured to monitor learned and manually selected prefixes. The border routers collect passive monitoring and active monitoring statistics and then transmit this information to the master controller. The master controller analyzes the collected information. If all monitored prefixes and exit links are in policy, no changes are made and the master controller continues to monitor the network. If a monitored prefix or exit link is out of policy, the master controller makes a policy decision and sends a control command to the border router to alter routing in the OER managed network to move the prefix to a better exit to bring the prefix or exit in policy.
Cisco IOS OER Monitoring: Passive Monitoring
Cisco IOS OER uses NetFlow, an integrated technology in Cisco IOS software, to collect and aggregate passive monitoring statistics on a per prefix basis. Passive monitoring is enabled by default when an OER managed network is created. Netflow is a flow-based monitoring and accounting system. NetFlow support is enabled by default on the border routers when passive monitoring is enabled.
Passive monitoring uses only existing traffic; additional traffic is not generated. Border routers collect and report passive monitoring statistics to the master controller approximately once per minute. If traffic does not go over an external interface of a border router, no data is reported to the master controller.
The master controller uses passive monitoring to measure the following information:
Delay—The master controller measures the average delay of TCP flows for a given prefix. Delay is the measurement of the round-trip response time (RTT) between the transmission of a TCP synchronization message and receipt of the TCP acknowledgement.
Packet loss—The master controller measures packet loss by tracking TCP sequence numbers for each TCP flow. OER estimates packet loss by tracking the highest TCP sequence number. If a subsequent packet is received with a lower sequence number, OER increments the packet loss counter. Packet loss is measured in flows per million (fpm).
Reachability—The master controller measures reachability by tracking TCP synchronization messages that have been sent repeatedly without receiving a TCP acknowledgement.
Throughput—The master controller measures prefixes that generate the highest outbound traffic volume or throughput. Throughput is measured on external interfaces in bits per second (bps).
Note
Passive monitoring statistics are gathered and stored in a prefix history buffer that can hold a minimum of 60 minutes of information depending on whether the traffic flow is continuos. Cisco IOS OER uses this information to determine if the prefix is in policy based on the default or user-defined policies.
Cisco IOS OER Monitoring: Active Monitoring
Active monitoring uses IP Service Level Agreements (IP SLAs), an integrated technology in Cisco IOS software, to analyze and measure the performance of TCP and UDP traffic. Active monitoring generates traffic in a continuous, reliable, and predictable manner. This allows the master controller to measure delay and jitter to determine prefix performance characteristics more accurately than is possible with only passive monitoring.
Active monitoring is enabled with the mode command in OER master controller configuration mode. When active monitoring is enabled, the master controller commands the border routers to send active probes to a target IP address. The border router collects and transmits the probe results to master controller to analyze.
Active probes are automatically generated when a prefix is learned or aggregated. The border router collects up to five host addresses from the prefix for active probing. Active probes can be configured for specific host or target address. Active probes are configured with the active-probe command in OER master controller configuration mode. The active probe is sourced from the border router and transmitted through an external interface (the external interface may or may not be the preferred route for an optimized prefix). Active probes are sent once per minute. ICMP probes are used by default.
Note
Active Probe Types
Cisco IOS OER uses ICMP Echo probes, by default, when an active probe is automatically generated. The following types of active probes can be configured:
ICMP Echo—A ping is sent to the target address. Configuring an ICMP echo probe does not require knowledgeable cooperation from the target device. However, repeated probing could trigger an Intrusion Detection System (IDS) alarm in the target network. If an IDS is configured in a target network that is not under your administrative control, we recommend that you notify the target network administration entity.
TCP Connection—A TCP connection probe is sent to the target address. A target port number must be specified. A remote responder must be enabled if TCP messages are configured to use a port number other than TCP well-known port number 23.
UDP Echo—A UDP echo probe is sent to the target address. A target port number must be specified. A remote responder must be enabled on the target device, regardless of the configured port number.
Cisco IOS OER Monitoring: Active Probe Source Address
The Active Probe Source Address feature was introduced in Cisco IOS Release 12.4(2)T. By default, active probes use the source IP address of the OER external interface that transmits the probe. The active probe source address feature is configured on the border router. This feature allows you to specify the source address of the active probe with the active-probe address source OER border router configuration command. When this command is configured, the primary IP address of the specified interface is used as the active probe source. The active probe source interface IP address must be unique to ensure that the probe reply is routed back to the specified source interface. If the interface is not configured with an IP address, the active probe will not be generated. If the IP address is changed after the interface has been configured as an active probe source, active probing is stopped, and then restarted with the new IP address. If the IP address is removed after the interface has been configured as an active probe source, active probing is stopped and not restarted until a valid primary IP address is configured.
Cisco IOS OER Monitoring: Combined Monitoring
Cisco IOS OER can also be configured to combine both active and passive monitoring in order to generate a more complete picture of traffic flows within the network. Combined monitoring is enabled by default. Combined monitoring is configured with the mode monitor both command in OER master controller configuration mode.
Cisco IOS OER Monitoring: Traceroute Reporting
The OER Support for Traceroute Reporting feature was introduced in Cisco IOS Release 12.3(14)T. Traceroute reporting is configured on a master controller. Traceroute probes are sourced from the current border router exit. This feature allows you to monitor prefix performance on a hop-by-hop basis. Delay, loss, and reachability measurements are gathered for each hop from the probe source to the target prefix.
Traceroute reporting is enabled with the set traceroute reporting oer-map configuration mode command. Learned or specific prefixes are selected for traceroute reporting by configuring a match clause in an OER map. When traceroute reporting is enabled, traceroute probes gather delay, loss, and reachability statistic for a given prefix. Specific traceroute probes can also be configured to gather these statistics individually only for prefixes that are in the out-of-policy state. The time interval between traceroute probes is configured with the traceroute probe-delay command in OER master controller configuration mode.
Traceroute probes are configured using the following methods:
Continuous—A traceroute probe is triggered for each new probe cycle. Entering the set traceroute reporting command without any keywords enables continuous reporting. The probe is sourced from the current exit of the prefix.
Policy based—A traceroute probe is triggered automatically when a prefix goes into an out-of-policy state. Policy based traceroute probes are configured individually for delay, loss, and reachability policies. The monitored prefix is sourced from a match clause in an oer-map. Policy based traceroute reporting stops when the prefix returns to an in-policy state.
On demand—A trace route probe is triggered only when the show oer master prefix command is entered for a specific IP address with the current and now keywords. Continuous or policy-based traceroute reporting does not need to be enabled to use this method. Entering this command without any keywords displays the most recent probe results for all exits. Entering this command with the current keyword displays the results for the current exit from the most recent probe.
Cisco IOS OER Modes of Operation
The master controller can be configured to operate in observe mode or control mode.
Cisco IOS OER Modes of Operation: Observe Mode
The master controller can be configured to operate in route observe mode or route control mode. Observe mode monitoring is enabled by default. In observe mode, the master controller monitors prefixes 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. This mode allows you to verify the effectiveness of this feature before actively deploying it.
Cisco IOS OER Modes of Operation: Control Mode
In control mode, the master controller coordinates information from the border routers and makes policy decisions just as it does in observe mode. The master controller monitors prefixes and exits based on default and user-defined policies but then implements changes to optimize prefixes and to select the best exit. In this mode, the master controller gathers performance statistics from the border routers and then transmits commands to the border routers to alter routing as necessary in the OER managed network. Control mode or observe mode monitoring is configured with the mode route command in OER master controller configuration mode.
Cisco IOS OER Routing Control
Figure 4 shows an OER managed network. The master controller alters default routing behavior inside of the OER managed network to optimize prefix and exit link performance. Cisco IOS OER uses a command/response protocol to manage all communication between the border router and the master controller.
Figure 4 Cisco IOS OER Controls Default Routing Behavior
The border routers are enterprise edge routers. Routing protocol peering or static routing is established between the border routers and internal peers. The border routers advertise a default route to internal peers through BGP peering, static routing, or route redistribution into an Interior Gateway Protocol (IGP). The master controller alters default routing behavior in the OER managed network by sending control commands to the border routers to inject a preferred route into the internal network.
When the master controller determines the best exit for a prefix, it sends a route control command to the border router with the best exit. The border router searches for a parent route for the monitored prefix. The BGP routing table is searched first and then the static routing table. This can be a default route for the monitored prefix. If a parent route is found that includes the prefix (the prefix may be equivalent or less specific) and points to the desired exit link by either the route to its nexthop or by a direct reference to the interface, a preferred route is injected into the internal network from the border router. OER injects the preferred route where the first parent is found. The preferred route can be an injected BGP route or an injected static route. The preferred route is learned by internal peers, which in turn recalculate their routing tables causing the monitored prefix to be moved to the preferred exit link. The preferred route is only advertised to the internal network and is not advertised to external peers.
Cisco IOS OER Routing: Border Router Peering with the Internal Network
The master controller alters default routing behavior in the OER managed network by injecting preferred routes into the routing tables of the border routers. The border routers peer with other routers in the internal network through BGP peering, BGP or static route redistribution into an IGP, or static routing. The border routers advertise the preferred route to internal peers.
The border routers should be close to each other in terms of hops and throughput and should have a consistent view of the network; routing should be configured consistently across all border routers. The master controller verifies that a monitored prefix has a parent route with a valid next hop before it commands the border routers to alter routing. The border router will not inject a route where one does not already exist. This behavior is designed to prevent traffic from being blackholed because of an invalid next hop.
Note
Cisco IOS OER Routing: BGP Peering
Standard internal BGP (iBGP) peering can be established between the border routers and other internal peers. External BGP (eBGP) peering or a default route is configured to the ISP. In the iBGP network, OER uses the local preference attribute to set the preference for injected routes. The BGP local preference attribute is a discretionary attribute that is used to apply the degree of preference to a route during the BGP best path selection process. This attribute is exchanged only between iBGP peers and is not advertised outside of the OER managed network or to the eBGP network. The prefix with the highest local preference value is locally advertised as the preferred path to the destination. OER applies a local preference value of 5000 to injected routes by default. A local preference value from 1 to 65535 can be configured.
Note
Note
Cisco IOS OER Routing: BGP Redistribution into an IGP
BGP redistribution can be used if the border routers are configured to run BGP (for ISP peering for example) and the internal peers are configured to run another routing protocol (such as Enhanced Interior Gateway Routing Protocol [EIGRP], Open Shortest Path First [OSPF] or Routing Information Protocol [RIP]). The border routers can advertise a single default route or full routing tables to the internal network. If you use BGP to redistribute more than a default route into an IGP, we recommend that you use IP prefix-list and route-map statements to limit the number of prefixes, as BGP routing tables can be very large.
Cisco IOS OER Routing: BGP Redistribution Based on the BGP Local-Preference Attribute
OER uses the local-preference attribute to influence routing inside of a BGP network. OER injected BGP routes can redistributed within the network by configuring the match local-preference route-map configuration command. A value of 5000 (or a custom value if configured on the master controller) must be configured when entering this command.
Cisco IOS OER Routing: Static Routing and Static Route Redistribution
Static routing or static route redistribution can be configured in the internal network. OER alters routing these types of network by injecting temporary static routes. The temporary static route replaces the parent static route. OER will in not inject a temporary static route where a parent static route does not exist. OER applies a default tag value of 5000 to identify the injected static route. In the case of the network where only static routing is configured, no redistribution configuration is required. In the case of a network where an IGP is deployed and BGP is not run on the border routers, static routes to border router exit interfaces must be configured, and these static routes must be redistributed into the IGP.
Cisco IOS OER Routing: Injecting Split Prefixes
When configured to control a subset of a larger network, the master controller will add an appropriate route or split prefix to the existing routing table, as necessary. A split prefix is a more specific route that is derived from a less specific parent prefix. For example, if a /24 prefix is configured to be optimized, but only a /16 route is installed to the routing table, the master controller will inject a /24 prefix using the attributes from the /16 prefix. Any subset of the less-specific prefix can be derived, including a single host route. Split prefixes are processed only inside the OER managed network and are not advertised to external networks. If BGP is deployed in the OER managed network, the master controller will inject a more specific BGP route. If BGP is not deployed, the master controller will inject a more specific temporary static route.
Cisco IOS OER Policy Configuration
The master controller optimizes prefixes and exit links to conform to default and user-defined policies. When the performance of a monitored prefix or exit link falls below a policy configuration setting, the master controller optimizes traffic in the internal network to bring either the prefix or exit link into an in-policy state. Global policies are configured in OER master controller configuration mode and OER Top Talker and Top delay learning configuration mode. Policies can also be applied to specific prefixes that pass through a match statement in an OER map in oer-map configuration mode. Global policies override OER map policies.
Cisco IOS OER Policy Configuration: Prefix Policies
A prefix policy is a set of rules that governs performance characteristics for a network address. The network address can be a single host route or an entire network. A prefix is defined as any network number with a prefix mask applied to it. The following performance characteristics are managed by prefix policies:
•
•
•
Note
Cisco IOS OER Policy Configuration: Exit Link Policies
An exit link policy is a set of rules that are applied to OER managed exit links. The performance characteristics that are managed by a link policy are traffic load and exit link utilization. A link policy can define total outbound throughput or total link utilization. Link utilization policies can be defined for a single exit link or all OER managed exit links. The following performance characteristics are managed by link policies:
•
•
•
Cisco IOS OER Policy Configuration: Cost-Based Optimization
The OER Support for Cost-Based Optimization feature was introduced in Cisco IOS Release 12.3(14)T. Cost-based optimization allows you to configure policies based on the monetary cost (ISP Service Level Agreement [SLA]) of each exit link in your network. This feature allows you to configure the master controller send traffic over exit links that provide the most cost-effective bandwidth utilization, while still maintaining the desired performance characteristics. Cost-based optimization is configured with the cost-minimization command in OER border exit configuration mode (under the external interface configuration). Cost-based optimization supports two billing models: fixed rate or tier-based with bursting.
Fixed Rate Billing
Fixed rate—This method is used when the ISP bills one flat rate for network access regardless of bandwidth usage. If only fixed rate billing is configured on the exit links, all exits are considered to be equal in regards to cost-optimization and other policy parameters (such as delay, loss, utilization, etc) are used to determine if the prefix or exit link is in-policy. If multiple exit links are configured with tiered and fixed policies, then exit links with fixed policies have the highest priority in regards to cost optimization. If the fixed exit links are at maximum utilization, then the tiered exit links will be used. Fixed rate billing is configured for an exit link when the fixed keyword is entered with the cost-minimization command. The monetary cost of the exit link is entered with the fee keyword.
Tier-Based Billing
Tier-based with bursting—This method is used when the ISP bills at a tiered rate based on the percentage of exit link utilization. Tiered-based billing is configured for an exit link when the tier keyword is entered with the cost-minimization command. A command statement is configured for each cost tier. The monetary cost of the tier is entered with the fee keyword. The percentage of bandwidth utilization that activates the tier is entered after the tier keyword.
The specific details of tier-based with bursting billing models vary by ISP. However, most ISPs use some variation of the following algorithm to calculate what an enterprise should pay in a tiered billing plan:
1.
2.
3.
4.
5.
6.
Note
Cost Optimization Algorithm
At the end of each billing cycle the top n% of samples, or rollup values, are discarded. The remaining highest value is the sustained utilization. Based on the number of samples discarded, the billing cycle is divided into three periods:
•
•
•
Initial Period
The period when the samples measured is less than the number of discards +1. For example, if discard is 7%, billing month is 30 days long, and sample period is 24 hours, then there are 30 samples at the end of the month. The number of discard samples is two (2% of 30). In this case, days one, two, and three are in the Initial Period. During this period, target the lowest tier for each ISP at the start of their respective billing periods and walk up the tiers until the current total traffic amount is allocated across the links.
Middle Period
The period after the Initial Period until the number of samples yet to be measured or collected is less than the number of discards.
Using the same example as above, the Middle Period would be from day four through day 28. During this period, set the target tier to the sustained utilization tier, which is the tier where (discard +1) the highest sample so far measured falls in.
Last Period
The period after the Middle Period until the end of billing period is the Last Period. During this period, if links were used at the maximum link capacity for the remainder of the billing period and sustained utilization does not change by doing so, then set the target to maximum allowable link utilization. Maximum link utilization is configurable where most likely values would be 75-90%. Otherwise, set the target to sustained utilization tier. During any sample period, if the cumulative usage is more than targeted cumulative usage, then bump up to the next tier for the remainder of sample period. If rollup is enabled, then replace sample values to rollup values and number of sample to number of rollups in above algorithm.
Cisco IOS OER Policy Configuration: Optimal Exit Link Selection
Cisco IOS OER can be configured to periodically select the Optimal Exit Link (OEL) from the available ISP connections based on exit link performance. The master controller will move traffic from over-utilized exit links to under-utilized exit links. Optimal Exit Link Selection (OELS) uses policy configuration to manage prefix and exit link performance. Policy configuration can be customized to your requirements. For example, a policy can be created to ensure that priority traffic is always routed to the target network through the exit link with the highest outbound throughput or the lowest delay (round-trip response time).
Cisco IOS OER Policy Configuration: Load Distribution
Cisco IOS OER supports per-prefix load distribution. The master controller measures transmission throughput on OER managed exit interfaces. When exit link utilization causes an exit link to go into an out-of-policy state, monitored prefixes are moved to bring the exit link in-policy and to equalize transmission utilization across all exit links. Load distribution settings are configured with the max-range-utilization command. The master controller sets the maximum range utilization to 20 percent for all OER managed exit links by default. Utilization can be customized for a single link or all exit links. A range policy can be applied to all monitored prefixes or any subset through oer-map or global policy configuration.
Tip
Cisco IOS OER Policy Configuration: Global Policies
Global policies are applied in Top Talker and Delay learning configuration mode. These policies are used to configure a master controller to learn and optimize prefixes based on the highest throughput or the highest delay. Under the Top Talker and Delay learning configuration mode, you can configure prefix learning based on delay and throughput statistics. You can configure the length of the prefix learning period, the interval between prefix learning periods, the number of prefixes to learn, and prefix learning based on port and protocol.
Cisco IOS OER Policy Configuration: Applying Policies with an OER Map
The operation of an OER map is similar to the operation of a route map. An OER map is designed to select IP prefixes defined in an IP prefix list or to select learned prefixes policies that pass a match clause and then to apply OER policy configurations using a set clause. The OER map is configured with a sequence number like a route map, and the OER map with the lowest sequence number is evaluated first. The operation of an oer-map differs from a route map at this point. There are two important distinctions:
•
•
An OER map can match a prefix or prefix range with the match ip address (OER) command. A prefix can be any IP network number combined with a prefix mask that specifies the prefix length. The prefix or prefix range is defined with the ip prefix-list command in Global configuration mode. Any prefix length can be specified. An oer-map can also match OER learned prefixes with the match oer learn command. Matching can be configured for learned prefixes based on delay or based on throughput.
The OER map applies the configuration of the set clause after a successful match occurs. Anther set clause can be used to set policy parameters for the backoff timer, packet delay, holddown timer, packet loss, mode settings, periodic timer, resolve settings, and unreachable hosts.
Policies applied by an OER map take effect after the current policy or operational timer expires. 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. Policies that are applied by an OER map do not override global policies and user-defined policies configured under OER master controller configuration mode and OER Top Talker and Delay configuration mode. These policies are only applied to prefixes that pass OER map match criteria.
Policy-Rules Configuration
The policy-rules OER master controller configuration command was introduced in Cisco IOS Release 12.3(11)T. This command allows you 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.
Cisco IOS OER Policy Configuration: Resolving Policies
When configuring multiple policy parameters for a monitored prefix or set of prefixes, it is possible to have multiple overlapping policies. The resolve function is a flexible mechanism that allows you to set the priority for cost, delay, loss, utilization, and range policies. Each policy is assigned a unique value. The policy with the highest priority is selected to determine the policy decision. By default, delay has the highest priority and utilization has the second highest priority.
Configuring Resolve with Variance
When configuring resolve settings, you can also set an allowable variance for the defined policy. Variance configures the allowable percentage that an exit link or prefix can vary from the defined policy value and still be considered equivalent. For example, if exit link delay is set to 80 percent and a 10 percent variance is configured, exit links that have delay values from 80 to 89 percent will be considered equal.
Note
VPN IPSec/GRE Tunnel Interface Optimization
Cisco IOS OER support for VPN IPSec/GRE Tunnel Optimization was introduced in Cisco IOS Release 12.3(11)T. Cisco IOS OER supports the optimization of prefixes that are routed over IPSec/GRE tunnel interfaces. The VPN tunnel interface is configured as OER external interfaces on the master controller. Figure 5 shows a an OER managed network that is configured to optimize VPN traffic. Cisco IOS OER is deployed at the Central Office and Remote Offices.
Figure 5 Cisco IOS OER Network Optimized for VPN Routing
This enhancement allows you to configure two-way VPN optimization. A master controller and border router process are enabled on each side of the VPN. Each site maintains a separate master controller database. VPN routes can be dynamically learned through the tunnel interfaces or can be configured. Prefix and exit link policies are configured for VPN prefixes through standard Cisco IOS OER configuration.
Cisco IOS OER Logging and Reporting
Cisco IOS OER supports standard syslog functions. The notice level of syslog is enabled by default. System logging is enabled and configured in Cisco IOS software under Global configuration mode. The logging command in OER master controller or OER border router configuration mode is used only to enable or disable system logging under OER. OER system logging supports the following message types:
Error Messages—These messages indicate OER operational failures and communication problems that can impact normal OER operation.
Debug Messages—These messages are used to monitor detailed OER operations to diagnose operational or software problems.
Notification Messages—These messages indicate that OER is performing a normal operation.
Warning Messages—These messages indicate that OER is functioning properly but an event outside of OER may be impacting normal OER operation.
To modify system, terminal, destination, and other system global logging parameters, use the logging commands in Global configuration mode. For more information about global system logging configuration, refer to the "Troubleshooting and Fault Management" section of the Cisco IOS Configuration Fundamentals and Network Management Configuration Guide, Release 12.3.
Cisco IOS OER Deployment Configurations
Cisco IOS OER can be deployed in an enterprise network, remote office network, or small office home office (SOHO) network using one of the following three configurations shown in Figure 6:
•
•
•
Figure 6 Cisco IOS OER Deployment Scenarios
In each deployment scenario, a single master controller is deployed. The master controller does not need to be in the traffic forwarding path but must be reachable by the border routers. A master controller process can be enabled on router that is also configured to run a border router process.The master controller can support up to 10 border routers and up to 20 OER managed external interfaces. At least one border router process and two exit interfaces are required in an OER managed network.
Note
How to Configure Cisco IOS Optimized Edge Routing
This section contains the following procedures:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Specific example configurations for each procedure follow each configuration table. Proceed to the Configuration Examples for Cisco IOS Optimized Edge Routing section to see more complex example deployment configurations.
Minimum Master Controller Configuration
This section describes the minimum required steps to configure a master controller process to manage an OER managed network. In this section, the following tasks are completed:
•
•
•
•
•
•
•
Master Controller
•
•
•
Disabling a Master Controller Process
To disable a master controller and completely remove the process configuration from the running-config file, use the no oer master command in Global configuration mode.
To temporarily disable a master controller, use the shutdown command in OER master controller configuration mode. Entering the shutdown command stops an active master controller process but does not remove any configuration parameters. The shutdown command is displayed in the running-config file when enabled.
Manual Port Configuration
Communication between the master controller and border router is automatically carried over port 3949 when connectivity is established. Port 3949 is registered with IANA for OER communication. Support for port 3949 was introduced in Cisco IOS Release 12.3(11)T. Manual port number configuration is only required if you are running Cisco IOS Release 12.3(8)T or if you need to configure OER communication to use a dynamic port number.
Prerequisites
Interfaces Must be Defined
Interfaces must be defined and reachable by the master controller and the border router before an OER managed network can be configured.
Key Chain Authentication
Communication between the master controller and the border router is protected by key-chain authentication. The authentication key must be configured on both the master controller and the border router before communication can be established. The key-chain configuration is defined in Global configuration mode on both the master controller and the border router before key-chain authentication is enabled for master controller to border router communication. For more information about key management in Cisco IOS software, refer to the "Managing Authentication Keys" section of the Cisco IOS IP Configuration Guide, Release 12.3.
Restrictions
Token Ring Interfaces are not Supported
Token Ring interfaces are not supported by OER and cannot be configured as OER managed interfaces. It may be possible to load a Token Ring interface configuration under certain conditions. However, the Token Ring interface will not become active and the border router will not function if the Token Ring interface is the only external interface on the border router.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
DETAILED STEPS
Examples
The following configuration example, starting in Global configuration mode, shows the minimum configuration required to configure a master controller process to control an OER managed network:
A key-chain configuration named OER is defined in Global configuration mode.
Router(config)# key chain OERRouter(config-keychain)# key 1Router(config-keychain-key)# key-string CISCORouter(config-keychain-key)# exitRouter(config-keychain)# exitThe master controller is configured to communicate with the 10.100.1.1 and 10.200.2.2 border routers. The keep alive interval is set to 10 seconds. Route control mode is enabled. Internal and external OER controlled border router interfaces are defined.
Router(config)# oer masterRouter(config-oer-mc)# keepalive 10Router(config-oer-mc)# mode route controlRouter(config-oer-mc)# loggingRouter(config-oer-mc)# border 10.100.1.1 key-chain OERRouter(config-oer-mc-br)# interface Ethernet 0/0 externalRouter(config-oer-mc-br)# interface Ethernet 0/1 internalRouter(config-oer-mc-br)# exitRouter(config-oer-mc)# border 10.200.2.2 key-chain OERRouter(config-oer-mc-br)# interface Ethernet 0/0 externalRouter(config-oer-mc-br)# interface Ethernet 0/1 internalRouter(config-oer-mc)# exitAutomatic prefix learning based on highest outbound throughput is enabled.
Router(config-oer-mc)# learnRouter(config-oer-mc-learn)# throughputRouter(config-oer-mc-learn)# endWhat to Do Next
Border routers must be configured to complete the minimum configuration of the OER managed network. Proceed to the next section to see instructions for configuring the border routers.
Minimum Border Router Configuration
This section describes the minimum required steps to configure a border router process. In this section, the following tasks are completed:
•
•
•
•
Border Router
•
•
•
Interface Configuration
•
•
•
Tip
Disabling a Border Router Process
To disable a border router and completely remove the process configuration from the running-config file, use the no oer border command in Global configuration mode.
To temporarily disable a border router process, use the shutdown command in OER border router configuration mode. Entering the shutdown command stops an active border router process but does not remove any configuration parameters. The shutdown command is displayed in the running-config file when enabled.
Prerequisites
Interfaces Must be Defined
Interfaces must be defined and reachable by the master controller and the border router before an OER managed network can be configured.
Restrictions
Internet Exchange Point over Broadcast Media
Internet exchange points where a border router can communicate with several service providers over the same broadcast media are not supported.
Border Exits Cannot use the Same Next Hop
When two or more border routers are deployed in an OER managed network, the next hop to an external network on each border router, as installed in the RIB, cannot be an IP address from the same subnet as the next hop on the other border router.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
Examples
The following configuration example, starting in Global configuration mode, shows the minimum required configuration to enable a border router:
The key-chain configuration is defined in Global configuration mode.
Router(config)# key chain OERRouter(config-keychain)# key 1Router(config-keychain-key)# key-string CISCORouter(config-keychain-key)# exitRouter(config-keychain)# exitThe key-chain OER is applied to protect communication. An interface is identified to the master controller as the local source interface for OER communication.
Router(config)# oer borderRouter(config-oer-br)# local Ethernet 0/1Router(config-oer-br)# master 192.168.1.1 key-chain OERRouter(config-oer-br)# endWhat to Do Next
Prefix learning based on the highest outbound throughput was enabled in the "Minimum Master Controller Configuration" section. Proceed to the next section to see more information about configuring and customizing prefix learning on the master controller.
Configuring Prefix Learning
This section describes the commands that are used to configure prefix learning on a master controller in OER Top Talker and Top Delay configuration mode. The learn command is entered in OER master controller configuration mode and is required to enter OER Top Talker and Top Delay configuration mode. All commands described in this section are optional.
The tasks described in this section allow you to configure the following:
•
•
•
•
Defaults
The following defaults are applied when a prefix learning is enabled:
•
•
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
What to Do Next
This section shows how to configure a master controller to automatically learn prefixes to monitor. Prefixes can also be manually selected for monitoring. Proceed to the next section to see information about manually importing prefixes.
Manually Selecting Prefixes for Monitoring
This section describes how to manually select prefixes for monitoring. An IP prefix list is created to define the prefix or prefix range. The prefix list is then imported into the central policy database by configuring a match clause in an OER map. The following IP prefix list configuration options are supported:
•
•
•
•
Manually Excluding Prefixes
An IP prefix list with a deny statement is used to configure the master controller to exclude a prefix or prefix length. Deny prefix list sequences should be applied in the lowest oer-map sequences for best performance.
OER Map Operation
The operation of an OER map is similar to the operation of a route-map. An OER map is configured to select an IP prefix list or OER learn policy using a match clause and then to apply OER policy configurations using a set clause. The OER map is configured with a sequence number like a route-map, and the OER map with the lowest sequence number is evaluated first.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Examples
The following example creates an oer-map named PREFIXES that matches traffic defined in the IP prefix lists named EXCLUDE and IMPORT. The prefix-list named EXCLUDE defines a deny sequence for all prefixes or host routes in the 192.168.0.0/16 subnet. The master controller will exclude these prefixes from the master controller database. The prefix-list named IMPORT defines a permit sequence to manually import the exact prefix 10.4.9.0/24.
Router(config)# ip prefix-list seq 10 EXCLUDE deny 192.168.0.0/16 le 32Router(config)# ip prefix-list seq 10 IMPORT permit 10.4.9.0/24Router(config)# !Router(config)# oer-map PREFIXES 10Router(config-oer-map)# match ip address prefix-list EXCLUDERouter(config-oer-map)# exitRouter(config)# oer-map PREFIXES 20Router(config-oer-map)# match ip address prefix-list IMPORTRouter(config-oer-map)# end
Tip
What to Do Next
Proceed to the next section to see information about configuring active probing.
Configuring Active Probing
This section describes how to enable active monitoring and how to configure active probing. Active monitoring is enabled with the mode command, and active probing is configured with the active-probe command in OER master controller mode. Active probes are configured with a specific host or target address. Active probes are sourced on the border router. The active probe source external interface may or may not be the preferred route for an optimized prefix.
Active Probing over eBGP Peerings
For eBGP peering sessions, the IP address of the eBGP peer must be reachable from the border router via a connected route in order for active probes to be generated.
ICMP Echo Probes
Configuring an ICMP echo probe does not require knowledgeable cooperation from the target device. However, repeated probing could trigger an Intrusion Detection System (IDS) alarm in the target network. If an IDS is configured in a target network that is not under your administrative control, we recommend that you notify the target network administration entity.
Defaults
The following defaults are applied when a active monitoring is enabled:
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Note
Examples
ICMP Echo Example
The following example configures an active probe using an ICMP echo (ping) message. The 10.4.9.1 address is the target. No explicit configuration is required on the target device.
Router(config-oer-mc)# active-probe echo 10.4.9.1TCP Connection Example
The following example configures an active probe using a TCP connection message. The 10.4.9.2 address is the target. The target port number must be specified when configuring this type of probe.
Router(config-oer-mc)# active-probe tcp-conn 10.4.9.2 target-port 23UDP Echo Example
The following example configures an active probe using UDP echo messages. The 10.4.9.3 address is the target. The target port number must be specified when configuring this type of probe, and a remote responder must also be enabled on the target device.
Router(config-oer-mc)# active-probe udp-echo 10.4.9.3 target-port 1001UDP Remote Responder Example
The following example configures an remote responder on a border router to send IP SLAs control packets in response to UDP active probes. The port number must match the number that is configured for the active probe.
Border-Router(config)# ip sla monitor responder type udpEcho port 1001TCP Remote Responder Example
The following example configures an remote responder on a border router to send IP SLAs control packets in response to TCP active probes. The remote responder must be configured for TCP active probes that do not use the TCP well-known port number 23.
Border-Router(config)# ip sla monitor responder type tcpConnect port 49152
Note
What to Do Next
If you need to configure a specific interface as the source for active monitoring, proceed to the next section for more information.
Configuring the Source Address of an Active Probe
The section describes how to specify the source interface for active probing. The active probe source interface is configured on the border router with the active-probe address source in OER border router configuration mode. The active probe source interface IP address must be unique to ensure that the probe reply is routed back to the specified source interface.
Defaults
•
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Example
The following example, starting in Global configuration mode, configures FastEthernet 0/0 as the active-probe source interface.
Router(config)# oer borderRouter(config-oer-br)# active-probe address source interface FastEthernet 0/0Router(config-oer-br)# end
What to Do Next
Traceroute reporting can be enable to gather hop-by-hop delay, loss, reachability statistics. Proceed to the next section for more information.
Configuring Traceroute Reporting
This section describes how to configure trace route reporting. Traceroute reporting is configured on a master controller. Traceroute probes are sourced from the current border router exit.
Continuous and policy based traceroute reporting is configured with the set traceroute reporting oer-map configuration mode command. The time interval between traceroute probes is configured with the traceroute probe-delay command in OER master controller configuration mode. On-demand traceroute probes are triggered by entering the show oer master prefix command with the traceroute and now keywords.
Defaults
When traceroute reporting is enabled, the default time interval between traceroute probes is 1000 milliseconds.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Example
The following example, starting in Global configuration mode, configures continuous traceroute reporting for prefix learned based on delay:
Router(config)# oer masterRouter(config-oer-mc)# traceroute probe-delay 10000Router(config-oer-mc)# exitRouter(config)# oer-map TRACE 10Router(config-oer-map)# match oer learn delayRouter(config-oer-map)# set traceroute reportingRouter(config-oer-map)# endThe following example, starting in Privileged EXEC mode, initiates an on-demand traceroute probe for the 10.5.5.5 prefix:
Router# show oer master prefix 10.5.5.55 traceroute current nowPath for Prefix: 10.5.5.0/24 Target: 10.5.5.5Exit ID: 2, Border: 10.1.1.3 External Interface: Et1/0Status: DONE, How Recent: 00:00:08 minutes oldHop Host Time(ms) BGP1 10.1.4.2 8 02 10.1.3.2 8 3003 10.5.5.5 20 50
What to Do Next
In the "Minimum Master Controller Configuration" section prefix learning based on highest outbound throughput is configured and only default prefix and exit link policies are enabled, using global settings. Proceed to the next section to configure and customize global prefix and exit link policies.
Configuring Prefix and Exit Link Policies
This section describes commands that are used to configure global prefix and exit link policies in OER master controller configuration mode. The oer master command is required to enter OER master controller configuration mode. All other command listed in this section are optional.
Prefix Policies
A prefix policy is a set of rules that govern the performance characteristics for a network address. The network address can be a single end point within a network or an entire subnet. A prefix is defined as any network number with a prefix mask applied to it. The performance characteristics that are managed by a prefix policy are reachability, delay, and packet loss.
Note
Exit Link Policies
An exit link policy is a set of rules that govern the performance of an OER managed exit link. Prefixes are moved to another exit link to bring an exit link in-policy. The performance characteristics that are managed by a link policy are traffic load distribution, link utilization (range), and link bandwidth monetary cost. An exit link policy can define total outbound throughput or total link utilization.Exit link utilization policies can be defined for a single exit link or all OER managed exit links.
Tip
Adjusting Cisco IOS OER Timers
Configuring a new timer value will immediately replaces the existing value if the new value is less than the time remaining. If the new value is greater than the time remaining, the new timer value will be used when the existing timer is reset.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Examples
Loss Policy Example
The following example configures the master controller to move prefixes to an in-policy exit link when the relative percentage of packet loss is equal to or greater than 20 percent:
Router(config-oer-mc)# loss relative 200Delay Policy Example
The following example sets the absolute delay threshold to 100 milliseconds:
Router(config-oer-mc)# delay threshold 100Prefix Timer Policy Example
The following example adjusts the period of time that the master controller holds prefixes during transition states and the period time that the prefix must use an exit before a new exit can be selected. The backoff command sets the minimum timer to 400 seconds, the maximum timer to 4000 seconds, and the step timer to 400 seconds. The holddown command sets the prefix route dampening timer to 10 minutes.
Router(config-oer-mc)# backoff 400 4000 400Router(config-oer-mc)# holddown 600Exit Link Selection Example
The following example configures the master controller to evaluate OER managed exit links every 5 minutes and then move out-of-policy prefixes to the first in-policy exit.
Router(config-oer-mc)# periodic 300Router(config-oer-mc)# mode select-exit goodLoad Distribution Example
The following examples configures the master controller to set the maximum utilization range for OER managed exit links to 40 percent:
Router(config-oer-mc)# max-range-utilization 40What to Do Next
To configure exit link policies based on the monetary cost of the exit links in your network, proceed to the next section for more information.
Configuring Cost-Based Optimization
This section describes how to configure cost-based optimization. Cost-based optimization is configured on a master controller with 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.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Examples
The following example, starting in Global configuration mode, configures cost-based optimization on a master controller. Cost optimization configuration is applied under the external interface configuration. A policy for a tiered billing cycle is configured. Calculation is configured separately for egress and ingress samples. The time interval between sampling is set to 10 minutes. These samples are configured to be rolled up every 60 minutes.
Router(config)# oer masterRouter(config-oer-mc)# border 10.5.5.55 key-chain keyRouter(config-oer-mc-br)# interface Ethernet 0/0 externalRouter(config-oer-mc-br-if)# cost-minimization nickname ISP1Router(config-oer-mc-br-if)# cost-minimization end day-of-month 30 180Router(config-oer-mc-br-if)# cost-minimization calc separateRouter(config-oer-mc-br-if)# cost-minimization sampling 10 rollup 60Router(config-oer-mc-br-if)# cost-minimization tier 100 fee 1000Router(config-oer-mc-br-if)# cost-minimization tier 90 fee 900Router(config-oer-mc-br-if)# cost-minimization tier 80 fee 800Router(config-oer-mc-br-if)# exitWhat to Do Next
To set the priority for multiple overlapping policies, proceed to the next section.
Configuring Resolve Policies
When configuring multiple policy parameters for a monitored prefix or set of prefixes, it is possible to have multiple overlapping policies. The resolve function is a flexible mechanism that allows you to set the priority for cost, delay, loss, utilization, and range policies. Each policy is assigned a unique value. The policy with the highest priority is selected to determine the policy decision. By default, delay has the highest priority and utilization has the second highest priority. Assigning a priority value to any policy will override the default settings.
Setting Variance for Resolve Policies
When setting resolve settings, you can also set an allowable variance for a user-defined policy. Variance configures the allowable percentage that an exit link or prefix can vary from the user-defined policy value and still be considered equivalent. For example, if exit link delay is set to 80 percent and a 10 percent variance is configured, exit links that have delay values from 80 to 89 percent will be considered equal. Variance cannot be configured for cost or range policies.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Examples
Resolve with Variance Policy Example.
The following example configures a 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.
Router(config-oer-mc)# resolve delay priority 1 variance 20Router(config-oer-mc)# resolve loss priority 2 variance 30Router(config-oer-mc)# resolve utilization priority 3 variance 10What to Do Next
Observe mode monitoring was enabled in the "Minimum Master Controller Configuration" section. Proceed to the next section to see information about configuring and customizing the Cisco IOS OER mode of operation.
Configuring Cisco IOS OER Modes of Operation
This section describes commands that are used to configure the mode of operation in OER master controller configuration mode. The master controller can be configured to operate in observe mode or control mode. A Cisco IOS OER managed network can be configured to use active and passive monitoring or both active and passive monitoring. The oer master command is required to enter OER master controller configuration mode.
Observe Mode
Observe mode monitoring is enabled by default. In observe mode, the master controller monitors prefixes 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. This mode allows you to verify the effectiveness of this feature before it is actively deployed.
Control Mode
In control mode, the master controller coordinates information from the border routers and makes policy decisions just as it does in observe mode. The master controller monitors prefixes and exits based on default and user-defined policies but then implements changes to optimize prefixes and to select the best exit. In this mode, the master controller gathers performance statistics from the border routers and then transmits commands to the border routers to alter routing as necessary in the OER managed network.
Note
Optimal Exit Link Selection
Cisco IOS OER can be configured to periodically select the Optimal Exit Link (OEL) from the available ISP connections based on exit link performance. The master controller will move traffic from over-utilized exit links to under-utilized exit links. Optimal Exit Link Selection (OELS) uses policy configuration to manage prefix and exit link performance. Policy configuration can be customized to your requirements. For example, a policy can be created to ensure that priority traffic is always routed to the target network through the exit link with the highest outbound throughput or the lowest delay (round-trip response time).
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Examples
The following example enables both active and passive monitoring, control mode, and sets the master controller to evaluate and select the first in-policy exit every 5 minutes. (The monitored prefix is moved only if the prefix is out-of-policy.) Active and passive monitoring is enabled with the mode monitor both command. Route control is enabled with the mode route control command. The time period between the exit selection process is configured with the periodic command. The selection of the first in-policy exit is configured with the mode select-exit good command.
Router(config)# oer masterRouter(config-oer-mc)# mode monitor bothRouter(config-oer-mc)# mode route controlRouter(config-oer-mc)# periodic 300Router(config-oer-mc)# mode select-exit goodWhat to Do Next
Proceed to the next section to see information about configuring OER policies with an oer-map.
Configuring OER Policies with an OER Map
This section describes commands that are used to configure policies to be applied to prefixes through an OER Map. The oer-map command is required to enter oer-map 1configuration mode. All other command listed in this section are optional.
Note
OER Map Operation
The operation of an OER map is similar to the operation of a route map. An OER map is designed to select IP prefixes or to select OER learn policies using a match clause and then to apply OER policy configurations using a set clause. The oer-map is configured with a sequence number like a route-map, and the oer-map with the lowest sequence number is evaluated first. The operation of an OER map differs from a route map at this point. There are two important distinctions:
•
•
IP Prefix Lists
Cisco IOS OER supports three IP prefix configuration options for importing prefixes. The master controller can monitor and control an exact prefix (/32), a specific prefix length, and a specific prefix length and any prefix that falls under the prefix length (for example, a /24 under a /16).
IP prefix list permit and deny statements are supported by Cisco IOS OER. An IP prefix list with a deny statement can be used to exclude a prefix or prefix length. Any prefix length can be specified for a deny IP prefix list.
Adjusting OER Timers
An oer-map can be used to configure OER timers for traffic that is defined as match criteria. Configuring a new timer value will immediately replace the existing value if the new value is less than the time remaining. If the new value is greater than the time remaining, the new timer value will be used when the existing timer is reset.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
DETAILED STEPS
Examples
Imported Prefix Policy Example
The following example creates an oer-map named SELECT_EXIT that matches traffic defined in the IP prefix list named CUSTOMER and sets exit selection to the first in-policy exit when the periodic timer expires. This OER map also sets a resolve policy that sets the priority of link utilization policies to 1 (highest priority) and allows for a 10 percent variance in exit link utilization statistics.
Router(config)# ip prefix-list CUSTOMER permit 10.4.9.0/24Router(config)# !Router(config)# oer-map SELECT_EXIT 10Router(config-oer-map)# match ip address prefix-list CUSTOMERRouter(config-oer-map)# set mode select-exit goodRouter(config-oer-map)# set resolve utilization priority 1 variance 10Learned Prefix Policy Example
The following example creates an oer-map named THROUGHPUT that matches traffic learned based on the highest outbound throughput. The set clause applies a relative loss policy that will permit 1 percent packet loss:
Router(config)# oer-map THROUGHPUT 20Router(config-oer-map)# match oer learn throughputRouter(config-oer-map)# set loss relative 10
What to do Next
An OER map configuration can also be applied in OER master controller configuration mode. Proceed to the next section to see more information.
Configuring Policy Rules for OER Maps
The policy-rules OER master controller configuration command was introduced in Cisco IOS Release 12.3(11)T. This command allows you 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.
Prerequisites
At least one oer-map must be configured before you can enable policy-rule support.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Examples
The following examples, starting in global configuration mode, show how to configure the policy-rules command to apply the OER map configuration named BLUE under OER master controller mode:
Router(config-oer-map)# oer-map BLUE 10Router(config-oer-map)# match oer learn delayRouter(config-oer-map)# set loss relative 900Router(config-oer-map)# exitRouter(config)# oer masterRouter(config-oer-mc)# policy-rules BLUERouter(config-oer-mc)# exitWhat to Do Next
If iBGP peering is enabled in the internal network, proceed to the next section to see information about configuring iBGP redistribution from the border routers.
Configuring iBGP Peering on the Border Routers
The master control implements policy changes by altering default routing behavior in the OER managed network. If iBGP peering is enabled on the border routers, the master controller will inject iBGP routes into routing tables on the border routers. The border routers advertise the preferred route through standard iBGP peering.
BGP Local Preference Attribute
OER uses the BGP local preference attribute to set the preference for injected BGP prefixes. If a local preference value of 5000 or higher has been configured for default BGP routing, you should configure a higher value in OER. OER default BGP local preference and default static tag values are configurable with the mode command in OER master controller configuration mode.
Injected Routes are not Advertised to External Networks
All OER injected routes remain local to an Autonomous System. The "no-export" community is automatically applied to inject routes to ensure that are not advertised to external networks.
Parent Route Must Exist
Before injecting a route, the master controller verifies that a parent route with a valid next hop exists. This behavior is designed to prevent traffic from being blackholed.
eBGP Peerings
The IP address for each eBGP peering session must be reachable from the border router via a connected route. Peering sessions established through loopback interfaces or with the neighbor ebgp-multihop command are not supported.
Prerequisites
Peering must be Consistently Applied
Routing protocol peering must be established in your network and consistently applied to the border routers; the border routers should have a consistent view of the network.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Examples
The following example, starting in Global configuration mode, establishes peering between two routers in autonomous system 65534. This example also configures the two routers to exchange the standard BGP communities attribute:
Border Router Configuration
Router(config)# router bgp 65534Router(config-router)# neighbor 10.100.1.3 remote-as 65534Router(config-router)# address-family ipv4Router(config-router-af)# neighbor 10.100.1.3 activateRouter(config-router-af)# neighbor 10.100.1.3 send-community standardInternal Border Peer Configuration
Router(config)# router bgp 65534Router(config-router)# neighbor 10.100.1.2 remote-as 65534Router(config-router)# address-family ipv4Router(config-router-af)# neighbor 10.100.1.2 activateRouter(config-router-af)# neighbor 10.100.1.2 send-community standardWhat to Do Next
If BGP is configured on the border routers and another IGP is deployed in the internal network, proceed to the next section to see information about configuring redistribution from BGP into the IGP.
If BGP is not configured in the internal network, then static routes to the border exits must be configured and the static routes must be redistributed into the IGP. For more information, proceed to the Configuring Static Route Redistribution on the Border Routers section.
Configuring BGP Redistribution into an IGP on the Border Routers
This section describes BGP redistribution into an IGP in the OER managed network. The configuration task table and examples in this section redistribution into OSPF, but EIGRP, IS-IS, or RIP could also be used in this configuration.
Filtering Routes that are Redistributed by BGP into the IGP
When redistributing BGP into any IGP, be sure to use IP prefix-list and route-map statements to limit the number of prefixes that are redistributed. Redistributing full BGP routing tables into an IGP can have a serious detrimental effect on IGP network operation.
Redistributing OER Injected Routes by Matching on the Local-Preference Attribute
OER uses a local-preference value of 5000 (default) to move traffic to the preferred exit point in a BGP network. (This value is configured on the OER master controller.) The match local-preference can be used in place of the ip prefix-list command to redistribute OER injected routes into the IGP. The local-preference value must match the default or configured value on the master controller. Only OER injected routes will be redistributed into the IGP. A branching task for this configuration is included in the task table below. The prefix-list is not required in this configuration.
Prerequisites
Peering must be Consistently Applied
IGP peering, static routing, and static route redistribution must be applied consistently throughout the OER managed network; the border routers should have a consistent view of the network.
Restrictions
Border Exits Cannot use the Same Next Hop
When two or more border routers are deployed in an OER managed network, the next hop to an external network on each border router, as installed in the RIB, cannot be an IP address from the same subnet as the next hop on the other border router.
SUMMARY STEPS
1.
2.
3.
4.
5.
or
6.
7.
8.
9.
10.
11.
12.
13.
DETAILED STEPS
Examples
The following example, starting in Global configuration mode, configures the border router to redistribute BGP routes into the internal network and configures the IGP (OSPF) to accept redistributed BGP routes. The first example configures redistribution using prefix lists. The second example configures redistribution using the BGP local-preference attribute. The IGP peer configuration is the same for either configuration.
Border Router Redistribution Configuration Using Prefix Lists
Router(config)# ip prefix-list PREFIXES seq 5 permit 10.200.2.0/24Router(config)# ip prefix-list PREFIXES seq 10 deny 0.0.0.0/0Router(config)# !Router(config)# route-map BGP permit 10Router(config-route-map)# match ip address prefix-list PREFIXESRouter(config-route-map)# exitRouter(config)# router bgp 65534Router(config-router)# bgp redistribute-internalBorder Router Redistribution Configuration Matching on the Local-Preference Attribute
Router(config)# route-map BGP permit 10Router(config-route-map)# match local-preference 5000Router(config-route-map)# exitRouter(config)# router bgp 65534Router(config-router)# bgp redistribute-internalIGP Peer Configuration
Router(config)# router ospf 1Router(config-router)# redistribute bgp 65534 route-map BGP subnetsWhat to Do Next
If BGP is not configured in the internal network, then static routes to the border exits must be configured and the static routes must be redistributed into the IGP. For more information, proceed to the next section.
Configuring Static Route Redistribution on the Border Routers
This section describes static redistribution into an IGP in an OER managed network.
OER Tags Static Routes
OER applies a default tag value of 5000 to injected temporary static routes. The static route is filtered through a route map and then redistributed into the IGP. If you use the tag value of 5000 for another routing function, you should use a different tag value for that function, or you can change the default static tag values by configuring the mode command in OER master controller configuration mode.
Parent Route Must Exist
Before injecting a route, the master controller verifies that a parent route with a valid next hop exists. This behavior is designed to prevent traffic from being blackholed.
Static Routing without IGP Redistribution
If static routing is configured in your network and no IGP is deployed, OER will inject temporary static routes as necessary. No redistribution or other specific network configuration is required.
Supported Interior Gateway Protocols
•
•
•
•
EIGRP Static Route Redistribution
Cisco IOS OER supports static route redistribution into EIGRP. However, it is configured differently. Proceed to the Configuring Static Route Redistribution into EIGRP section for more information.
Prerequisites
Peering must be Consistently Applied
IGP peering, static routing, and static route redistribution must be applied consistently throughout the OER managed network; the border routers should have a consistent view of the network.
Restrictions
Border Exits Cannot use the Same Next Hop
When two or more border routers are deployed in an OER managed network, the next hop to an external network on each border router, as installed in the RIB, cannot be an IP address from the same subnet as the next hop on the other border router.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Examples
The following example, starting in global configuration mode, configures static redistribution to allow the master controller to influence routing in an internal network that is running RIP. The match tag command is match OER injected temporary static routes. The set metric command is used to set the preference of the injected static.
Border Router Configuration
Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 0Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 1Router(config)# route-map STATIC permit 10Router(config-route-map)# match tag 5000Router(config-route-map)# set metric -10Router(config-route-map)# exitRouter(config)# router ripRouter(config-router)# network 192.168.0.0Router(config-router)# network 172.16.0.0Router(config-router)# redistribute static route-map STATICInternal Border Peer Configuration
Router(config)# route ripRouter(config-router)# network 192.168.0.0Router(config-router)# network 172.16.0.0What to Do Next
If EIGRP is deployed in the internal network and BGP is not configured on the border routers, proceed to the next section for more information.
Configuring Static Route Redistribution into EIGRP
This section describes static route redistribution into EIGRP. Under the EIGRP configuration, a tag is applied to the static route and an a distribute list is configured on all egress interfaces.
OER Tags Static Routes
OER applies a default tag value of 5000 to injected temporary static routes. The static route is filtered through a route map and then redistributed into the IGP.
Parent Route Must Exist
Before injecting the temporary static route, the master controller verifies that a parent static route with a valid next hop exists. This behavior is designed to prevent traffic from being blackholed.
Prerequisites
Peering must be Consistently Applied
IGP peering, static routing, and static route redistribution must be applied consistently throughout the OER managed network; the border routers should have a consistent view of the network.
Restrictions
Border Exits Cannot use the Same Next Hop
When two or more border routers are deployed in an OER managed network, the next hop, as installed in the RIB, to an external network on each border router cannot be an IP address from the same subnet as the next hop on the other border router.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
Examples
The following example, starting in Global configuration mode, configures static redistribution to allow the master controller to influence routing in an internal network that is running EIGRP:
Border Router Configuration
Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 0 tag 10Router(config)# ip route 0.0.0.0 0.0.0.0 Ethernet 1 tag 10Router(config)# !Router(config)# route-map RED deny 20Router(config-route-map)# match tag 10Router(config-route-map)# exitRouter(config)# route-map RED permit 30Router(config-route-map)# exitRouter(config)# route-map BLUE permit 10Router(config-route-map)# match tag 5000Router(config-route-map)# exitRouter(config)# route-map BLUE permit 20Router(config-route-map)# exitRouter(config)# route eigrp 1Router(config-router)# no auto-summaryRouter(config-router)# redistribute static route-map REDRouter(config-router)# network 10.0.0.0Router(config-router)# network 172.16.0.0Router(config-router)# network 192.168.0.0Router(config-router)# distribute-list route-map BLUE out Ethernet 0Router(config-router)# distribute-list route-map BLUE out Ethernet 1Internal Border Peer Configuration
Router(config)# route eigrp 1Router(config-router)# no auto-summaryRouter(config-router)# network 10.0.0.0Router(config-router)# network 172.16.0.0Router(config-router)# network 192.168.0.0Router(config-router)# endConfiguring OER to Monitor and Control IPSec VPN Prefixes Over GRE Tunnels
VPN IPSec/GRE Tunnel Optimization was introduced in Cisco IOS Release 12.3(11)T. Cisco IOS OER supports the optimization of prefixes that are routed over GRE tunnel interfaces and protected with IPSec. Both GRE and multipoint GRE tunnels are supported.
This task shows a sample IPSec VPN configuration example. In this example, the IPSec VPN is configured on the border router, and the tunnel interface is configured as an OER managed interface on the master controller. The following tasks are completed:
•
•
•
•
•
•
Routing Prefixes that are Protected with IPSec over GRE Tunnels
The IPSec to GRE model allows a service provider to provide VPN services over the IP backbone. Both the central and remote VPN clients terminate per the IPSec-to-IPSec model. Prefixes are encapsulated using generic route encapsulation (GRE) tunnels. The GRE packet is protected by IPSec. The encapsulated prefixes are forwarded from the central VPN site to a customer headend router that is the other endpoint for GRE. The IPSec protected GRE packets provide secure connectivity across the IP backbone of the service provider network.
For more information about configuring IPSec over GRE tunnels, refer to the Dynamic Multipoint IPsec VPNs (Using Multipoint GRE/NHRP to Scale IPsec VPNs) published at the following URL:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_white_paper09186a008018983e.shtml
GRE Tunnel Interfaces are Configured as OER Managed Exit Links
GRE tunnel interfaces on the border routers are configured as OER external interfaces on the master controller. At least two external tunnel interfaces must be configured on separate physical interfaces in an OER managed network. These interfaces can be configured on a single border router or multiple border routers. Internal interfaces are configured normally using a physical interface on the border router that is reachable by the master controller.
Prerequisites
•
•
•
Restrictions
•
Border Router Configuration
The GRE tunnel and IPSec protection is configured on the border router. The following configuration steps show the configuration of single tunnel. At least two tunnels must be configured on the border router(s) in an OER managed network. The IPSec configuration must be applied at each tunnel end point (the central and remote site).
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
DETAILED STEPS
Guest
