Cisco Performance Routing (PfR) leverages the intelligence that is integrated into the Cisco IOS software to determine the optimal path based upon network and application policies. PfR can be used to automatically detect the degradation of a path and respond accordingly to avoid any further degradation. Cisco PfR policies can be based on the following parameters:
- WAN outbound performance: Delay, loss, reachability, throughput, jitter, and MOS
- WAN inbound performance: Delay, loss, reachability, and throughput
- WAN and Internet path parameters: Reachability, throughput, load, and link usage cost
PfR routing is different from classic routing which is based only on reachability and does take into consideration traffic service needs, such as low loss or low delay. In addition, Cisco PfR allows a multihomed enterprise to use all available WAN or Internet links by tracking throughput, link usage, and link cost, and automatically determining the best load balancing to optimize throughput, load, and cost. PfR consists of two elements, which are:
- Border Routers
- Mater Controller
The border routers connect enterprises to the WAN or the Internet. These routers gather traffic and path information which they then sent to the master controller, which places all information received from the border routers into a database.
The master controller is a software entity supported by Cisco IOS Software on a router platform. The master controller is configured with the requested service policies, so it is aware of everything that happens at the network edge and can automatically detect and take action when certain parameters are out-of-policy (OOP). Figure 4-2 illustrates a typical PfR deployment:
Fig. 4-2. Understanding Cisco Performance Routing (PfR)
Referencing Figure 4-2, border routers, B1 and B2, which are connected to two different Internet Service Providers (ISPs), send statistics to the master controller, router MC. The master controller sends relevant commands to the border routers depending on policy configuration implemented on the router. For example, if the link between border router B1 and ISP A is congested, the master controller may send Internet-bound traffic via the link between border router B2 and ISP B instead by injecting routes on router B2 based on policy configuration.
This overall solution allows for routing based on network performance and is not dependent on NetFlow, Cisco IOS IP SLA, or other Cisco IOS software features explicitly on either the master controller or the border router. PfR is its own technology, although it may be used in conjunction with other Cisco IOS software technologies, as will be described later in this section.
Implementing Cisco Performance Routing
Cisco PfR is supported natively in Cisco IOS software and requires no additional licensing to enable this functionality, other than a supported IOS image. In order to run PfR, border the border routers must be configured to run Cisco Express Forwarding (CEF). Additionally, the master controller must be able to communicate with and reach all border routers.
NOTE: Cisco Express Forwarding, or CEF, operates at the data plane and is a topology-driven proprietary switching mechanism that creates a forwarding table that is tied to the routing table, i.e. the control plane. CEF will be described later in this chapter; however, more detailed information on CEF can be found in the SWITCH guide in the Multilayer switching chapter.
In Cisco IOS software, the initial implementation of Cisco PfR uses Cisco IOS Optimized Edge Routing (OER) techniques. In other words, PfR functions are enabled using OER CLI commands. OER was introduced in Cisco IOS version 12.3(8) T, with additional features added in Cisco IOS version 12.3(11) T, 12.3(14) T, and 12.4(2) T.
When implementing PfR, the minimum design requirement is for at least one master controller function, one border router function, and two WAN links. However, both master and border router functions can be implemented on the same router. In addition, it is mandatory that the border router must be in the traffic forwarding path, i.e. packets to the WAN or Internet must physically traverse the border router. However, this requirement is not mandatory for the master controller, which does not have to be in the forwarding path. As of the time of this text, the master controller can manage up to ten border routers.
When implementing PfR, each border router must be configured as follows:
- The border router must have Cisco Express Forwarding (CEF) enabled
- The session between the border router and the master controller must be authenticated
- The local PfR interface must be able to communicate with the master controller
- The border router must be configured with the IP address of the master controller
When implementing PfR, the master controller must be configured as follows:
- The master controller must be configured with the IP addresses of all its border routers
- PfR policies must be configured on the master controller
- The session between the border router and the master controller must be authenticated
PfR Traffic Classes, Prefixes and Monitoring
PfR monitors performance for selected prefixes or traffic classes. When implementing PfR, you must specify the prefixes or traffic classes to monitor and what aspects of performance to monitor for those prefixes or traffic classes. A traffic class is as a combination of prefix, protocol, port numbers, and Differentiated Services Code Point (DSCP) values.
NOTE: DSCP is described in detail in the SWITCH guide in the chapter on LAN Quality of Service. A basic overview on DSCP will be provided later in this chapter.
In Cisco IOS software, PfR can be instructed to learn these interesting elements through manual router configuration using a dynamic learning based on Cisco IOS NetFlow technology. PfR monitors the set of prefixes or traffic classes using three methods of performance measurement. These three methods, which are described in the following section, are:
- Passive Monitoring
- Active Monitoring
- Active and Passive Monitoring
Passive monitoring is used to measure the performance metrics of interesting prefixes while the traffic is flowing through the device using NetFlow. NetFlow data captures delay and throughput statistics. The delay measurements are based on TCP RTT. The data also records TCP packet loss and reachability.
Active monitoring is enabled via the generation of a stream of traffic replicating the interesting traffic classes as closely as possible in order to measure the performance metrics of this traffic. Active probing can be configured to use IP SLA operations and metrics used include delay, reachability, MOS, and jitter, which can be measured using SLA ICMP echoes, TCP connections, and UDP echoes, as was described earlier in this chapter. And finally, active and passive monitoring uses both active and passive monitoring to generate a more complete picture of traffic flows within the network.
NOTE: PfR configuration will not be illustrated in this chapter or the remainder of this guide for the simple reason that there are far too many ways in which PfR can be implemented, meaning there is no ‘one-size-fits-all’ implementation. Additionally, the configuration of PfR exceeds the required level of knowledge for the current ROUTE exam.