Performance Routing FAQs
Cisco Performance Routing (PfR) FAQs
About Performance Routing
Q. What is Cisco® Performance Routing?
A. Cisco Performance Routing complements classic IP routing technologies by adding intelligence to select best paths to meet application performance requirements. The first phase of Performance Routing technology intelligently optimizes application performance over enterprise WANs and to and from the Internet. This technology will evolve to help enable application performance optimization throughout the enterprise network through an end-to-end, performance-aware network.
Cisco Performance Routing selects an egress or ingress WAN path based on parameters that affect application performance, including reachability, delay, cost, jitter, and Mean Opinion Score (MOS). This technology can reduce network costs by facilitating more efficient load balancing and by increasing application performance without WAN upgrades. Traditional IP routing protocols such as Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), Routing Information Protocol (RIP), and Border Gateway Protocol (BGP) generally focus on providing reachability by creating a loop-free topology based on shortest or least-cost path. Cisco Performance Routing adds intelligence to routing decisions based on measured application and network performance.
Q. Are There Any Case Studies or Success Stories with PfR?
A. Yes. Just recently in June of 2010 Cisco Inc. and SAS Inc. concluded a joint Case Study on their use of PfR. Global Business Analytics Leader Reduces WAN Network Costs, where SAS Inc. uses Performance Routing (PfR) to help ensure top performance for business-critical communications, while controlling costs.
Q. Where is the Performance Routing documentation?
For Cisco IOS Release 15.1, Performance Routing Configuration Guide:
All releases, Performance Routing Command Reference:
http://www.cisco.com/en/US/docs/ios/pfr/command/reference/pfr_book.html Available late July 2010
Q. What is the difference between Performance Routing and Cisco IOS Optimized Edge Routing (OER)?
A. Cisco Performance Routing takes advantage of the vast intelligence embedded in Cisco IOS Software to determine the optimal path based upon network and application policies. Cisco Performance Routing is an evolution of the Cisco IOS OER technology with a much broader scope. OER was originally designed to provide route control on a per destination prefix basis, but Performance Routing has expanded capabilities that facilitate intelligent route control on a per application basis. The expanded capabilities provide additional flexibility and more granular application optimization than OER.
Q. What are the two components of Performance Routing? What do they do?
A. Performance Routing has two logical components: the Master Controller (MC) and the Border Router (BR).
The BR component resides within the data plane of the edge router. The BR uses NetFlow to passively gather throughput and TCP performance information. The BR also sources all IP service-level agreement (SLA) probes used for explicit application performance monitoring. As the policy enforcement point, the BR receives commands from the MC to actively control routes through route injection or dynamic policy-based routing (PBR) injection.
The MC acts as the central processor and database for the Performance Routing system. The MC component does not reside in the forwarding plane and, when deployed in a standalone fashion, has no view of routing information contained within the BR. The role of the MC is to gather information from the BR or BRs to determine whether or not traffic classes are in or out of policy, and to instruct the BRs how to make sure that traffic classes remain in policy using route injection or dynamic PBR injection. The MC also provides an API for reporting capabilities.
Depending on your Performance Routing deployment scenario and scaling requirements, the MC may be deployed on a dedicated router or may be deployed along with the BR on the same physical router.
Q. What problem does Cisco Performance Routing solve?
A. As enterprise organizations grow their businesses, there is a demand for real-time application performance, and better application experiences for users. For example, voice and Cisco TelePresence® applications have become integral parts of business success. Performance of these applications is crucial to their successful implementation. In order to improve application performance, companies have typically deployed two common solutions: providing additional bandwidth by deploying more network connections (for example, through multihoming), and using application optimization technologies (for example, Cisco Wide Area Application Services [WAAS]). Additional WAN bandwidth may improve aggregate throughput, but may not improve delay or loss for critical applications. Application optimization technologies such as Cisco WAAS can improve performance with data-reduction techniques, but fluctuating network performance can still affect applications. Performance Routing addresses network performance problems by helping enable the network to intelligently choose a path that currently meets the performance requirements of a specific application. In addition, using cost-based link policies, Performance Routing allows the network to intelligently choose link resources as needed to reduce operational costs.
Q. What are the benefits to customers of Cisco Performance Routing?
- Bandwidth cost minimization allows enterprises to minimize traffic sent over expensive links or consolidate multiple flat-rate connections to fewer and lower-cost services.
- Automatic performance optimization reduces engineering operating expenses associated with manual network performance analysis and tuning of the routing infrastructure.
- Automatic performance optimization also helps ensure that mission-critical applications perform with the speed, availability, and reliability required for business success.
- Users can experience improved response time because Performance Routing can automatically detect and route around poorly performing paths using an alternate path.
- Due to the ability to actively detect and route around "black hole" conditions in the network, Performance Routing can minimize the effects of network outages.
Q. What are the newest features in Performance Routing (PfR)?
A. There are two new features recently released:
1. Performance Routing - Protocol Independent Route Optimization (PIRO), you can find this in the Cisco Feature Navigator named as "PfR - Protocol Independent Route Optimization (PIRO)".
First Published: March 19, 2010; Last Updated: March 19, 2010
Protocol Independent Route Optimization (PIRO) introduced the ability of Performance Routing (PfR) to search for a parent route—an exact matching route, or a less specific route—in the IP Routing Information Base (RIB), allowing PfR to be deployed in any IP-routed environment including Interior Gateway Protocols (IGPs) such as OSPF and IS-IS.
2. Using Performance Routing to Control EIGRP Routes with mGRE DMVPN Hub-and-Spoke Support, you can find this in the Cisco Feature Navigator named as "PfR EIGRP mGRE DMVPN Hub-and-Spoke support".
First Published: March 19, 2010; Last Updated: March 19, 2010
The 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.
A. There are three keywords you should look for and those are "OER", "PFR", and "Performance Routing". Here is the list of PfR feature names as of June, 2010:
|FN Keyword||Full Feature Name Syntax|
|OER||OER - API|
|OER||OER - Application Aware Routing with Static Application|
|OER||OER - Inbound Optimization thru BGP|
|OER||OER - MC Support for Cat6k Phase1|
|OER||OER - Voice Traffic Optimization|
|OER||OER Border Router Only Functionality|
|OER||OER Port and Protocol Based Prefix Learning|
|OER||OER Support for Cost Based Optimization and Traceroute Reporting|
|OER||OER Support for Policy-Rules Configuration and Port-Based Prefix Learning|
|OER||OER VPN IPsec/GRE Tunnel Optimization|
|Performance Routing||Performance Routing - Application Interface|
|Performance Routing||Performance Routing - Link Groups|
|Performance Routing||Performance Routing with NBAR/CCE Application Recognition|
|PfR||PfR - Protocol Independent Route Optimization (PIRO)|
|PfR||PfR EIGRP mGRE DMVPN Hub-and-Spoke support|
Q. What are the software and hardware requirements for Cisco Performance Routing?
A. Refer to Figures 1 and 2.
Figure 1. Cisco Performance Routing Platform Support
Figure 2. Classic Cisco IOS Software Feature Sets
Figure 3. New ISR G2 Simplified Feature Sets (PfR in DATA Package)
Q. Is there a feature matrix that lists the features with platform support and correlates them with the Cisco IOS Software releases?
A. Use the Cisco IOS Performance Routing Roadmap document. The roadmap is organized so that you can select your release train and see the features available in that release. Certain release trains correspond to specific platforms; for example, the SR train is for the 7600 platform, the SX train is for the 6500 platform, the Cisco XE train is for the ASR1000, and the mainline and T-trains are cross-platform releases. Find the feature name you are searching for and click the URL in the "Where Documented" column to access the document containing that feature.
Available starting with Cisco IOS Software Release 12.3(8)T, the Cisco OER/PfR solution supports both the border router and the master controller functions. The following functions have been added to OER since its inception:
• Cisco IOS Software Release 12.3(8)T: Initial OER support
• Cisco IOS Software Release 12.3(11)T: Added VPN IP Security (IPsec) and generic routing encapsulation (GRE) tunnel optimization
• Cisco IOS Software Release 12.3(11)T: Added port- and protocol-based prefix learning
• Cisco IOS Software Release 12.3(11)T:: Added support for policy-rules configuration
• Cisco IOS Software Release 12.3(14)T: Added support for cost-based optimization and traceroute reporting
• Cisco IOS Software Release 12.4(2)T: Added application-aware routing: Policy-Based Routing (PBR)
• Cisco IOS Software Release 12.4(2)T: Added active probe source address
• Cisco IOS Software Release 12.4(6)T: Added voice traffic optimization
• Cisco IOS Software Release 12.4(9)T: Added differentiated services code point (DSCP) monitoring
• Cisco IOS Software Release 12.4(9)T: Added BGP inbound optimization
• Cisco IOS Software Release 12.2(33)SRB: Added support on Cisco7600
• Cisco IOS Software Release 12.2(33)SXH: Added border router support on Cisco Catalyst® 6500
• Cisco IOS Software Release 15.0(1)M: Added PfR EIGRP mGRE DMVPN Hub-and-Spoke Support
• Cisco IOS Software Release 12.4(24)T: Added PfR - Protocol Independent Route Optimization (PIRO)
You can also use Feature Navigator to precisely determine which features are included in specific releases on specific platforms; see http://www.cisco.com/go/cfn.
Q. Is there a Performance Routing GUI?
A. Yes. Cisco has partnered with Fluke Networks to build a configuration and reporting GUI named the Fluke Performance Routing Manager. Please visit Fluke Networks' web site: http://www.flukenetworks.com/fnet/en-ca/products/PFR+Manager. Also, Cisco Configuration Professional 1.3, available as a free download at Cisco.com, facilitates Performance Routing configuration on Cisco Integrated Services Routers. For more details and a download link for Cisco Configuration Professional, go to http://www.cisco.com/en/US/prod/collateral/routers/ps9422/data_sheet_c78_462210.html.
Q. Is Cisco Performance Routing supported globally?
A. Yes, the Cisco Technical Assistance Center (TAC) provides global support.
Active Probing (IP SLAs)
Q. Does Performance Routing require explicit IP SLA configuration?
A. No; by default, Performance Routing automatically configures IP SLA Internet Control Message Protocol (ICMP) probes for you. Depending on the type of traffic being controlled, you may want to use a different type of IP SLA probe. For example, if you want to control voice traffic through Performance Routing using a jitter-based policy, you will need to explicitly configure an IP SLA jitter probe and specify the target IP address of an appropriate IP SLA responder.
Q. Do I have to understand IP SLA comprehensively?
A. No, by default the activation of IP SLA and active monitoring using probes occurs without any interaction or awareness of the person configuring Performance Routing. The Border Router sends the IP SLA results to the Master Controller where routing decisions are made based on the policy configuration.
Q. How does Performance Routing use active probing?
A. Performance Routing can use passive monitoring, active monitoring, or both types of monitoring to determine the performance of prefixes on all possible paths. You can configure IP SLA probes to use system defaults or configure them in the following ways:
- If active probing is enabled, but no other specific probe configuration is created (using system defaults), Performance Routing dynamically sends out ICMP probes to a subset of Top Talker destinations if you previously configured Performance Routing to build a Top Talker list.
- Active probing can calculate the voice over IP (VoIP) MOS by measuring delay, loss, and jitter of codec realistic probes.
Q. Is Performance Routing configuration complex?
A. Basic Performance Routing configuration using the command-line interface (CLI) is very simple, with most of the configuration performed on the Master Controller. For an example of a simple link-utilization-based Performance Routing policy, see Figure 3.
Figure 3. Cisco Performance Routing Configuration
Q. Can inbound traffic be optimized?
A. Yes, Performance Routing can optimize inbound traffic. Performance Routing downgrades a nonpreferred entrance by prepending BGP autonomous system numbers or by adding a community to external route advertisements associated with this entrance.
Q. When using the learn delay function, Performance Routing learns only prefixes that generate a three-way handshake during the learning period. Does the learn delay function learn only TCP traffic?
A. Yes, bidirectional TCP traffic is required to use the learn delay function of Performance Routing. The learn delay function is limited to TCP traffic, but throughput-based learning can be used for non-TCP traffic. Using the learn delay function, Performance Routing learns the top N prefixes with the highest delay values.
Q. Does learn delay learn the top N prefixes with the highest or worst delay?
Q. When using learn throughput, Performance Routing identifies, through NetFlow, the top N prefixes that have the most throughput during the learn period. Does a learn throughput configuration allow Performance Routing to learn prefixes for which there is any sort of IP traffic?
A. Yes, unless learn filter is configured.
Q. Can a Performance Routing Master Controller and a Border Router be configured on the same physical router?
A. Yes, although scaling issues in your network may require that the MC and BR be deployed on separate physical routers.
Q. When do I need a dedicated Master Controller?
A. If you need to control more than 1000 traffic classes, it is recommended that you configure a dedicated Master Controller. If you are deploying Performance Routing for a data center, we recommend that you configure a dedicated Master Controller. For small office or home office (SOHO) setups, it is acceptable if the Master Controller and the Border Router coexist on the same physical router.
Q. How do I use Performance Routing for performance monitoring when I only have one external interface?
A. Performance Routing is designed for multihoming, which requires a minimum of two external interfaces. However, Performance Routing can be configured to monitor application performance over a single interface by creating a second dummy interface, which will not forward packets. Use a Dialer interface for the second interface but do not attach any physical interfaces to the Dialer. The Dialer interface needs an IP address because Performance Routing checks that the interfaces are routable. The IP address assigned to the Dialer does not need to be advertised.
The following example configuration shows how to add a Dialer interface as the second dummy external interface to an existing configuration:
On PfR Border Router
configure terminal interface Dialer 1 ip address 10.9.9.9 255.255.255.254 end
On PfR Master Controller
configure terminal oer master border 10.1.1.1 interface Dialer 1 external end
The following is an example Master Controller configuration after adding the dummy Dialer interface:
On PfR Master Router
oer master border 10.1.1.1 key-chain key1 interface Dialer1 external interface Ethernet2/0 external interface Ethernet0/0 internal ! learn throughput periodic-interval 0 monitor-period 1
Q. How do I deploy Performance Routing in networks not running internal BGP (iBGP) within the enterprise?
A. To synchronize routing within the enterprise and take advantage of optimal Performance Routing routes, route redistribution into the local Interior Gateway Protocol (IGP; for example, EIGRP, OSPF, or RIP) needs to occur. Static routes injected by Performance Routing are tagged by an identifier that can be specifically redistributed. If you are running iBGP, BGP routes are usually not redistributed into an IGP. For more configuration details about route redistribution into IGPs, see the Setting Up OER Network Components module.
Q. What Performance Routing limitations exist on Cisco Catalyst® 6500 Switches and Cisco 7600 Series Routers?
A. In these platforms, due to architectural limitations with NetFlow on the EARL7 chip, Performance Routing cannot determine performance (delay/loss/reachability) characteristics from passive monitoring of TCP flows; Performance Routing can only measure passive throughput. Note that these platforms support active IP SLA measurements and throughput-based load balancing. In addition, Cisco Catalyst 6500 Switches support only Border Router functionality and cannot be used as a Performance Routing Master Controller.
Q. What does the "Disable hardware switching to enable netflow aggregation export in version 9 format" message mean? Do I have to disable hardware switching?
A. This is just an informational message. You do not have to disable hardware switching, and you can safely ignore this message. Performance Routing uses NetFlow Version 9 format internally, but the set of hardware you are running does not support NetFlow Version 9 export format. All this message is saying is that the platform cannot export version 9 when hardware switching. Note that while Performance Routing uses NetFlow for its operation, Performance Routing performance information is not exported in NetFlow export messages.
Q. Is Performance Routing VRF-aware?
Q. Does Performance Routing enforce symmetric routing?
A. No, Performance Routing selects the best path based on real-time performance data. Symmetric routing is not always optimal. In an enterprise deployment, if Performance Routing is deployed on both ends of the network, it will select the best path in both directions. However, these bidirectional decisions are made independently and do not guarantee path symmetry.
Q. Will Performance Routing cause route oscillation?
A. Performance Routing has a hold-down period that prevents route oscillation. After the traffic class is rerouted through a new or better link, by default, Performance Routing does not change the route of a traffic class for a period of time known as the hold-down period. The hold-down period can be configured, and the default is 300 seconds. The only exception to the rule occurs if the traffic class becomes unreachable prior to the completion of the hold-down period.
Q. How are Performance Routing system logging (syslog) messages formatted?
Sep 22 11:27:14.990: %OER_MC-5-NOTICE: Route changed Prefix 18.104.22.168/26, BR 22.214.171.124, i/f Et2/0, Reason Non-OER, OOP Reason None
Sep 22 11:27:32.042: %OER_MC-5-NOTICE: Route changed Prefix 126.96.36.199/26, BR 188.8.131.52, i/f Et2/0, Reason Delay, OOP Reason Timer Expired
Sep 22 11:27:52.242: %OER_MC-5-NOTICE: Prefix Learning WRITING DATA
Sep 22 11:29:55.350: %OER_MC-5-NOTICE: Prefix Learning STARTED
Sep 22 11:30:56.226: %OER_MC-5-NOTICE: Prefix Learning WRITING DATA
Sep 22 11:32:59.434: %OER_MC-5-NOTICE: Prefix Learning STARTED
Sep 22 11:33:04.974: %OER_MC-5-NOTICE: Passive ABS Delay OOP Prefix 184.108.40.206/26, delay 451, BR 220.127.116.11, i/f Et2/0
Sep 22 11:33:04.974: %OER_MC-5-NOTICE: Uncontrol Prefix 18.104.22.168/26, OOP, mode select-exit good
Sep 22 11:33:59.018: %OER_MC-5-NOTICE: Discovered Exit for Prefix 22.214.171.124/26, BR 126.96.36.199, i/f Et2/0
Passive Monitoring (NetFlow)
Q. Does Performance Routing require explicit NetFlow configuration?
A. No, when Performance Routing is enabled, it automatically configures NetFlow for you.
Q. How does Performance Routing use passive monitoring?
A. For passive monitoring, Performance Routing uses many of the services built into the Cisco IOS Software including:
- Cisco Performance Routing builds a list of top throughput and top latency talkers.
- Based on the list of learned and configured prefixes, Performance Routing passively monitors TCP flags for traffic on every flow (of the current exit) to measure latency, packet loss, and reachability.
A. Yes, if appropriate link grouping is configured, Performance Routing can revert back to the primary link when the primary link returns to an in-policy condition.
Q. When using select-exit best with mode active or mode both, does Performance Routing also initially probe all exits to find the best exit and then only probe all exits again if the current exit goes OOP?
A. The configuration of select-exit best is independent of how often Performance Routing probes exits. The probing is driven by the timer, the state of the prefix, and an OOP condition. In active, fast, or both modes Performance Routing always selects the best exit. Select-exit best configures Performance Routing to control or uncontrol a traffic class if the traffic class is OOP.
Q. When using select-exit best with mode fast, does Performance Routing always probe all exits and, at each periodic interval, can Performance Routing move the prefix to the best exit if the identified best exit is different from the current exit?
A. In fast mode, Performance Routing always probes all exits (continually) to allow Performance Routing to reroute traffic quickly.
Q. What is a parent route?
A. A parent route is a route that is equal to, or less specific than, the destination prefix of the traffic class being optimized by Performance Routing. The parent route should have a route through the Performance Routing external interfaces. All routes for the parent prefix are called parent routes. For Performance Routing to control a traffic class on a Performance Routing external interface, the parent route must exist on the Performance Routing external interface. BGP and Static routes qualify as Performance Routing parent routes. In Cisco IOS Release 12.4(24)T and later releases, any route in RIB, with an equal or less specific mask than the traffic class, will qualify as a parent route.
Q. Which parent route IP routing protocols are supported?
A. BGP and static routes are supported in all current releases. With the introduction of Performance Routing Protocol Independent Route Optimization (PIRO) in Cisco IOS Software Release 12.4(24)T and later releases, any route in the RIB, with an equal or less specific mask than the traffic class, will qualify as a parent route. PIRO allows Performance Routing to be used with any IP routing protocol. EIGRP support was introduced in Cisco IOS Release 15.0(1)M.
Q. Can Performance Routing control a traffic class that is more granular than a network address? If yes, how?
A. Yes, Performance Routing can control applications that are defined using access control lists (ACLs), network-based application recognition (NBAR) application IDs, or fixed static signatures (Performance Routing has a predefined list of signatures). Performance Routing controls applications using route maps as part of policy-based routing. Route maps are automatically generated, and no user configuration is required.
Q. Is prefix splitting supported with Cisco Performance Routing? If so, how is it done?
A. Yes. Prefix splitting means that a more specific route is derived from a prefix (for example, splitting a host route [/32] from a /24 prefix). If you configure a /24 prefix to be optimized but Cisco Performance Routing finds only /16 route in the routing table, it injects a /24 route with the new exit link using the attributes from the /16 route. This injection affects only the internal routes, and this new information is not propagated outside the autonomous system. If you configure a prefix and Performance Routing finds only a default route for it (from any Border Router), the following occurs:
- If BGP is not running, a new static route is injected.
- If BGP is running, a new BGP route is injected.
Q. How does the Master Controller inject a route?
A. Master Controller-to-Border Router communication takes place through a Cisco internal mechanism that does not rely on an iBGP session between them. When the Master Controller determines the best path for a specific prefix (whether learned or user-configured), it sends a route control command to a selected Border Router that has the best exit. If an exact route (BGP or static) already exists for this prefix, Cisco Performance Routing either changes the local preference for a BGP route or modifies the next hop of a static route. If a route does not exist for this prefix but there is a super route or a default route covering this prefix, the Cisco Performance Routing Master Controller injects a route that matches exactly the length of this prefix (called "prefix splitting") by sending a route control command to the selected Border Router. The Border Router then redistributes this route internally with its iBGP peers.
Q. Does the Master Controller have visibility of the Border Router BGP routing tables that it controls?
A. No, the Master Controller does not have a copy of the BGP or static routing tables from any of the Border Routers it controls. The Master Controller does not need to run any routing protocols and is typically not in the data forwarding path.
Q. What happens if the Master Controller fails?
A. If the Performance Routing Master Controller fails, the Border Routers notice that their internal communication to the Performance Routing Master Controller is no longer active. The Cisco IOS Software in the Performance Routing Border Router determines which routes are under Performance Routing control and withdraws these routes, which restores everything back to normal routing. The network experiences the same performance that was occurring before turning on Cisco Performance Routing.
Q. Does Performance Routing support the notion of redundant Master Controllers?
A. Yes, redundant Master Controllers can be deployed using Hot Standby Router Protocol (HSRP). Note that in this scenario, Master Controller failover is not stateful. When the Border Router learns that the primary Master Controller is no longer reachable, it will purge all Performance Routing-learned routes and restore itself to traditional IP routing. After the Master Controller HSRP switchover takes place, the Master Controller-to-Border Router communication is restored, and the system will restart the Performance Routing learning process.
Q. How is CPU utilization affected when Performance Routing is enabled?
A. This depends on the existing CPU load and the number of active traffic classes that are controlled.
Q. How many Border Routers are supported, and how many exits in total?
A. A total of 10 Border Routers and 200 exits are supported per Master Controller.
Traffic Class Optimization
Q. Do I have to specify the traffic classes that are to be optimized?
A. No. The traffic classes to be optimized either can be specified using prefix-list, access-list, NBAR, or static application definition or can be learned in real time.
Q. If a traffic class is configured using an ACL with "any any" instead of specifying a destination subnet, is it supported? For example, "access-list 101 permit tcp any any eq telnet."
A. No, the default prefix cannot be learned, no passive statistics can be gathered for the default prefix, and route control cannot work.