Table Of Contents
Using Performance Routing to Control EIGRP Routes with mGRE DMVPN Hub-and-Spoke Support
Prerequisites for Using PfR to Control EIGRP Routes
Restrictions for Using PfR to Control EIGRP Routes
Information About Using PfR to Control EIGRP Routes
PfR and mGRE Dynamic Multipoint VPN
How to Configure PfR to Control EIGRP Routes
Enabling PfR EIGRP Route Control and Setting a Community Value
Disabling PfR EIGRP Route Control
Manually Verifying the PfR EIGRP-Controlled Routes
Configuration Examples for Using PfR to Control EIGRP Routes
Enabling PfR EIGRP Route Control and Setting a Community Value: Example
Feature Information for Using PfR to Control EIGRP Routes
Using Performance Routing to Control EIGRP Routes with mGRE DMVPN Hub-and-Spoke Support
First Published: October 2, 2009Last Updated: November 20, 2009The PfR EIGRP mGRE DMVPN Hub-and-Spoke Support feature introduces the ability to inject routes into the EIGRP routing table, which allows Performance Routing (PfR) to control prefixes and applications over EIGRP routes. This feature also adds support for multicast Generic Routing Encapsulation (mGRE) Dynamic Multipoint Virtual Private Network (DMVPN) deployments that follow a hub- and-spoke network design.
Performance Routing is an extension of the Optimized Edge Routing (OER) technology and many of the commands and command modes still use the OER naming conventions. All of the original OER features are incorporated into the Performance Routing technology. Some of the early OER features have been superseded by newer techniques, and the more recent configuration module titles now use Performance Routing naming.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Using PfR to Control EIGRP Routes" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Using PfR to Control EIGRP Routes
•
•
•
•
•
Prerequisites for Using PfR to Control EIGRP Routes
This feature assumes that EIGRP is already configured in your network and that basic OER functionality is also configured. See the "Cisco IOS Optimized Edge Routing Overview" and "Setting Up OER Network Components" modules for more details. For other OER and PfR features, see the "Where to Go Next" section or the "Additional References" section for more details.
Restrictions for Using PfR to Control EIGRP Routes
If you are deploying EIGRP in an mGRE DMVPN topology in your network, it must conform to a hub- and-spoke network design.
Information About Using PfR to Control EIGRP Routes
To use PfR to control EIGRP routes, you should understand the following concepts:
•
PfR EIGRP Route Control
The PfR EIGRP mGRE DMVPN Hub-and-Spoke Support feature introduces PfR route control for EIGRP. When enabled, a parent route check is performed in the EIGRP database for controlling PfR prefixes and routes in addition to the existing BGP and static route databases.
PfR can only optimize paths for prefixes, which have an exact matching route or a less specific route (also called as parent route) in the routing protocols. The route being controlled by PfR can be an exact match of the parent route or can be a more specific one. For example, if PfR wants to control 10.1.1.0/24 but the EIGRP routing table has only 10.1.0.0/16 then the parent route is 10.1.0.0/16 and PfR will inject 10.1.1.0/24 in the EIGRP routing table.
If an exact matching parent route in the EIGRP routing table is found, PfR will attempt to install a route on an exit selected by the master controller by influencing the metric. If an exact match parent is not found, then PfR introduces a new route in the EIGRP table that matches the attributes of the parent. If the route installation in the EIGRP table is successful, PfR saves the EIGRP parent and registers for any updates to the parent route. If the parent route is removed, PfR will uncontrol any routes it has installed in the EIGRP table based on this parent route.
PfR monitors traffic performance for prefixes it is controlling either passively using NetFlow or actively using IP SLA probes. Performance statistics such as delay, loss, and reachability are gathered and compared against a set of policies configured for the prefixes. If the traffic performance does not conform to the policies, the prefix is said to be out-of-policy (OOP). PfR tries to find an alternate path when the prefix goes into the OOP state.
While both BGP and static route control are enabled by default, EIGRP route control must be configured. PfR always attempts to control a prefix using BGP first. If BGP route control fails, static route control is tried. When EIGRP route control is enabled, PfR will attempt to control a prefix using BGP first. If no parent route is found, PfR will try to use EIGRP route control. If EIGRP route controls fails, static route control is tried.
To find an alternate path for a prefix, PfR tries to send active probes from all the external interfaces on the border routers to a set of hosts in the destination prefix network. Before an active probe can be sent on an external interface, a parent route lookup is performed in routing protocol tables. When the PfR EIGRP mGRE DMVPN Hub-and-Spoke Support feature is enabled, PfR checks EIGRP routing tables, in addition to BGP and static routing tables, for a parent route, before sending active probes on external interfaces. Active probes are initiated on all the external interfaces that have a parent route in the EIGRP routing table. When the probe activity completes and the timer expires, statistics are sent from the border router to the master controller for policy decision and selection of an optimal exit.
When an exit is selected, a control prefix command is sent to the border router with the selected exit, specifying EIGRP as the protocol to install or modify the route. When the border router receives the command, it checks the EIGRP table to find a parent route. If a parent route is found, OER will install or modify the route in the EIGRP table and will notify the master controller about the route control status.
If an EIGRP route is successfully installed and advertised into the domain, OER continues to monitor traffic performance for this prefix and takes further action as mentioned above if the prefix goes OOP.
For more details about the PfR control mode and details about other PfR exit link selection control techniques including BGP, static routes, policy-based routing, and Protocol Independent Route Optimization (PIRO), see the "Using OER to Control Traffic Classes and Verify the Route Control Changes" module.
PfR and mGRE Dynamic Multipoint VPN
Dynamic Multipoint VPN (DMVPN) enables zero-touch deployment of IPsec encrypted VPN networks. The DMVPN topology leverages protocols like multipoint GRE (mGRE) for hub-to-spoke functionality, and for spoke-to-spoke functionality it utilizes the Next Hop Resolution Protocol (NHRP). Many DMVPN deployments use EIGRP networks, and support was added to PfR to allow DMVPN network deployments to use EIGRP route control within the DMVPN network. In the PfR EIGRP route control implementation, only hub-to-spoke network designs are supported.
For more details about configuring mGRE DMVPN networks, see the Dynamic Multipoint VPN module. For general information about DMVPN, go to http://www.cisco.com/go/dmvpn.
How to Configure PfR to Control EIGRP Routes
•
•
•
Enabling PfR EIGRP Route Control and Setting a Community Value
Perform this task on the master controller to enable EIGRP route control. While both BGP and static route control are enabled by default, EIGRP route control must be enabled using a command-line interface (CLI) command, mode route metric eigrp. PfR always attempts to control a prefix using BGP first. If BGP route control fails, static route control is tried. When EIGRP route control is enabled, PfR will attempt to control a prefix using BGP first. If no parent route is found, PfR will try to use EIGRP route control. If EIGRP route controls fails, static route control is tried.
This task can also set an extended community value for an injected EIGRP route to allow the routes to be uniquely identified. An EIGRP route may be injected by PfR to control the traffic defined by a traffic class when it goes out-of-policy (OOP). In this task, the PfR route control mode is configured globally with the mode route control command in OER master controller configuration mode, and any injected EIGRP routes will be tagged with a value of 700.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
oer master
Example:Router(config)# oer master
Enters OER master controller configuration mode to configure a router as a master controller and to configure global operations and policies.
Step 4
mode route control
Example:Router(config-oer-mc)# mode route control
Configures the OER route control mode on a master controller.
•
Note
Step 5
mode route metric eigrp tag community
Example:Router(config-oer-mc)# mode route metric eigrp tag 7000
Enables EIGRP route control and sets an EIGRP tag and community number value for injected EIGRP routes.
•
Note
Step 6
end
Example:Router(config-oer-mc)# end
Exits OER master controller configuration mode and returns to privileged EXEC mode.
Disabling PfR EIGRP Route Control
Perform this task on the master controller to disable EIGRP route control.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Manually Verifying the PfR EIGRP-Controlled Routes
PfR automatically verifies route control changes in the network using NetFlow output. PfR monitors the NetFlow messages and uncontrols a traffic class if a message does not appear to verify the route control change. Perform the steps in this optional task if you want to manually verify that the traffic control implemented in the PfR control phase actually changes the traffic flow, and brings the OOP event to be in-policy.
All the steps in this task are optional and are not in any order. The information from these steps can verify that a specific prefix associated with a traffic class has been moved to another exit or entrance link interface, or that it is being controlled by PfR. The first two commands are entered at the master controller, the last two commands are entered at a border router.
Only partial command syntax for some of the show commands used in this task is displayed. For more details about OER show commands, see the Cisco IOS Optimized Edge Routing Command Reference.
Prerequisites
•
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Step 1
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 2
This command is used to display the status of monitored prefixes. The output from this command includes information about the source border router, current exit interface, protocol, prefix delay, and egress and ingress interface bandwidth. In this example, the protocol displayed for the prefix 10.1.0.0/16 is EIGRP, which means that the parent route for the traffic class exists in the EIGRP routing table and EIGRP community values are used to control the prefix. Only syntax relevant to this task is shown in this step.
Router# show oer master prefix 10.1.0.0OER Prefix Statistics:Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),P - Percentage below threshold, Jit - Jitter (ms),MOS - Mean Opinion ScoreLos - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),E - Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicableU - unknown, * - uncontrolled, + - control more specific, @ - active probe all# - Prefix monitor mode is Special, & - Blackholed Prefix% - Force Next-Hop, ^ - Prefix is deniedPrefix State Time Curr BR CurrI/F ProtocolPasSDly PasLDly PasSUn PasLUn PasSLos PasLLosActSDly ActLDly ActSUn ActLUn EBw IBwActSJit ActPMOS--------------------------------------------------------------------------------10.1.0.0/16 DEFAULT* @69 10.1.1.1 Gi1/22 EIGRPU U 0 0 0 0U U 0 0 22 8N NStep 3
The next command is entered on a border router, not the master controller.
Step 4
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 5
This command is entered on a border router. Use this command to display information about EIGRP routes controlled by PfR on a border router. In this example, the output shows that prefix 10.1.2.0/24 is being controlled by OER. This command is used to show parent route lookup and route changes to existing parent routes when the parent route is identified from the EIGRP routing table.
Router# show oer border routes eigrpFlags: C - Controlled by oer, X - Path is excluded from control,E - The control is exact, N - The control is non-exactFlags Network Parent TagCE 10.1.2.0/24 10.0.0.0/8 5000In this example, the parent keyword is used and more details are shown about the parent route lookup.
Router# show oer border routes eigrp parentNetwork Gateway Intf Flags10.0.0.0/8 10.40.40.2 Ethernet4 1Child NetworksNetwork Flag10.1.2.0/24 6
Troubleshooting Tips
If the show commands are not displaying output that verifies the EIGRP route control, use the debug oer border routes eigrp command with the optional detail keyword for more information. Debugging must be enabled before entering the required commands, and the debug output depends on which commands are subsequently entered.
Configuration Examples for Using PfR to Control EIGRP Routes
This section provides the following configuration example:
•
Enabling PfR EIGRP Route Control and Setting a Community Value: Example
In the following configuration example, PfR route control is enabled first, and then the EIGRP route control is enabled and configured to set an extended community value of 700 to any injected EIGRP routes:
oer mastermode route controlmode route metric eigrp tag 700endWhere to Go Next
This module covers PfR EIGRP route control. To learn more about PfR, start with the "Cisco IOS Optimized Edge Routing Overview" and the "Setting Up OER Network Components" modules. To learn more about the OER phases (same as Performance Routing phases) identified in the "Cisco IOS Optimized Edge Routing Overview" module, read through the other modules in the following list:
•
•
•
•
•
Additional References
The following sections provide references related to the PfR EIGRP mGRE DMVPN Hub-and-Spoke Support feature.
Related Documents
Cisco PfR technology overview
Concepts and configuration tasks required to set up PfR network components
Cisco OER commands: complete command syntax, command mode, command history, defaults, usage guidelines and examples
EIGRP Routing Protocol commands
Configuring mGRE DMVPN networks
General information about the DMVPN technology
Command Lookup Tool
Cisco IOS Master Command List
http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Feature Information for Using PfR to Control EIGRP Routes
Table 1 lists the release history for this feature.
Table 1 lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Release 15.0(1)M, or a later release appear in the table.
For information on a feature in this technology that is not documented here, see the "Optimized Edge Routing Roadmap."
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0910R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2009 Cisco Systems, Inc. All rights reserved.
Guest
