Configuring Basic Performance Routing

Performance Routing (PfR) is an advanced Cisco technology to allow businesses to complement classic routing technologies with additional serviceability parameters to select the best egress or ingress path. It complements these classic routing technologies with additional intelligence. PfR can select an egress or ingress WAN interface based upon parameters like reachability, delay, cost, jitter, MOS score, or it can use interface parameters like load, throughput and monetary cost. Classic routing (for example, EIGRP, OSPF, RIPv2, and BGP) generally focuses upon creating a loop-free topology based upon the shortest or least cost path.

PfR gains additional intelligence using measurement instrumentation. It uses interface statistics, Cisco IP SLA for active monitoring, and NetFlow for passive monitoring. No prior knowledge or experience of IP SLA or NetFlow is required, PfR automatically enables these technologies without any manual configuration.

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.

PfR is an integrated Cisco IOS solution that allows you to monitor IP traffic flows and then define policies and rules based on traffic class performance, link load distribution, link bandwidth monetary cost, and traffic type. PfR provides active and passive monitoring systems, dynamic failure detection, and automatic path correction. Deploying PfR enables intelligent load distribution and optimal route selection in an enterprise network.

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 Optimized Edge Routing (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.

If you are migrating to Performance Routing from an implementation of Optimized Edge Routing in an earlier Cisco IOS Release image, you must be aware of the following information to ensure a smooth migration path. In Cisco IOS Release 15.1(2)T, the OER syntax is still recognized. When you enter OER syntax the software changes the syntax to the new PfR syntax in the running configuration. When the running configuration is saved, the PfR version of the syntax is saved. If you need to reload an older Cisco IOS image, we recommend that you save backup copies of all configuration scripts with the OER syntax version because the new PfR syntax will not run in an older Cisco IOS software image.

With CSCtr26978, the OER syntax is removed and old configuration scripts with the OER syntax will no longer run.

PfR was developed to identify and control network performance issues that traditional IP routing cannot address. In traditional IP routing, each peer device communicates its view of reachability to a prefix destination with some concept of a cost related to reaching the metric. The best path route to a prefix destination is usually determined using the least cost metric, and this route is entered into the routing information base (RIB) for the device. As a result, any route introduced into the RIB is treated as the best path to control traffic destined for the prefix destination. The cost metric is configured to reflect a statically engineered view of the network, for example, the cost metric is a reflection of either a user preference for a path or a preference for a higher bandwidth interface (inferred from the type of interface). The cost metric does not reflect the state of the network or the state of the performance of traffic traveling on that network at that time. Traditional IP routed networks are therefore adaptive to physical state changes in the network (for example, interfaces going down) but not to performance changes (degradation or improvement) in the network. Occasionally, degradation in traffic can be inferred from either the degradation in performance of the routing device or the loss of session connectivity, but these traffic degradation symptoms are not a direct measure of the performance of the traffic and cannot be used to influence decisions about best-path routing.

To address performance issues for traffic within a network, PfR manages traffic classes. Traffic classes are defined as subsets of the traffic on the network, and a subset may represent the traffic associated with an application, for example. The performance of each traffic class is measured and compared against configured or default metrics defined in an PfR policy. PfR monitors the traffic class performance and selects the best entrance or exit for the traffic class. If the subsequent traffic class performance does not conform to the policy, PfR selects another entrance or exit for the traffic class.

PfR is configured on Cisco routers using Cisco IOS command-line interface (CLI) configurations. Performance Routing comprises two components: the Master Controller (MC) and the Border Router (BR). A PfR deployment requires one MC and one or more BRs. Communication between the MC and the BR is protected by key-chain authentication. 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.

A PfR-managed network must have at least two egress interfaces that can carry outbound traffic and can be configured as external interfaces, see the figure below. These interfaces should connect to an ISP or WAN link (Frame-Relay, ATM) at the network edge. The router must also have one interface (reachable by the internal network) that can be configured as an internal interface for passive monitoring. There are three interface configurations required to deploy PfR: external interfaces, internal interfaces, and local interfaces.

The BR component resides within the data plane of the edge router with one or more exit links to an ISP or other participating network.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. The BR is where all policy decisions and changes to routing in the network are enforced. The BR 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 BR enforces policy changes by injecting a preferred route to alter routing in the network. A BR process can be enabled on the same router as a master controller process.

The MC is a single router that 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 master controller maintains communication and authenticates the sessions with the BRs. 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 ensure that traffic classes remain in policy using route injection or dynamic PBR injection.

On Cisco 7600 series routers, due to architectural limitations with NetFlow on the hardware chip, PfR cannot determine performance (delay/loss/reachability) characteristics from passive monitoring of TCP flows; PfR can only measure passive throughput. The Cisco 7600 routers do support active IP SLA measurements and throughput-based load balancing.

The PfR master controller software has been modified to handle the limited functionality supported by the Cisco 7600 series border routers. Using the Route Processor (RP), the Cisco 7600 series border routers can capture throughput statistics only for a traffic class compared to the delay, loss, unreachability, and throughput statistics collected by non-Cisco 7600 series border routers. A master controller automatically detects the limited capabilities of the Cisco 7600 series border routers and downgrades other border routers to capture only the throughput statistics for traffic classes. By ignoring other types of statistics, the master controller is presented with a uniform view of the border router functionality.

When new PfR functionality is introduced that changes the API between the MC and the BR, the version number for the Performance Routing components, master controller and border router, is incremented. The version number of the master controller must be equal or higher to the version number for the border routers.The version numbers for both the master controller and the border routers are displayed using the show pfr master command. In the following partial output, the MC version is shown in the first paragraph and the BR versions are shown in the last column of the information for the border routers.

Router# show pfr master
OER state: ENABLED and ACTIVE
 Conn Status: SUCCESS, PORT: 7777
  Version: 2.0
  Number of Border routers: 2
  Number of Exits: 2
.
.
.
Border           Status   UP/DOWN             AuthFail  Version
1.1.1.2          ACTIVE   UP       00:18:57          0  2.0
1.1.1.1          ACTIVE   UP       00:18:58          0  2.0
.
.
.

The version numbers are not updated at each Cisco IOS software release for a specific release train, but if the Cisco IOS software image is the same release on the devices configured as a master controller and all the border routers, then the versions will be compatible.

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, see the "Managing Authentication Keys" section of the Configuring IP Routing Protocol-Independent Features chapter in the Cisco IOS IP Routing: Protocol Independent Configuration Guide.

A PfR-managed network must have at least two egress interfaces that can carry outbound traffic and that can be configured as external interfaces. These interfaces should connect to an ISP or WAN link (Frame-Relay, ATM) at the network edge. The router must also have one interface (reachable by the internal network) that can be configured as an internal interface for passive monitoring. There are three interface configurations required to deploy PfR:

• External interfaces are configured as PfR-managed exit links to forward traffic. The physical external interface is enabled on the border router. The external interface is configured as a PfR external interface on the master controller. The master controller actively monitors prefix and exit link performance on these interfaces. Each border router must have at least one external interface, and a minimum of two external interfaces are required in an PfR-managed network.
• Internal interfaces are used only for passive performance monitoring with NetFlow. No explicit NetFlow configuration is required. The internal interface is an active border router interface that connects to the internal network. The internal interface is configured as an PfR-internal interface on the master controller. At least one internal interface must be configured on each border router.
• Local interfaces are used only for master controller and border router communication. A single interface must be configured as a local interface on each border router. The local interface is identified as the source interface for communication with the master controller.

Tip	If a master controller and border router process are enabled on the same router, a loopback interface should be configured as the local interface.

The following interface types can be configured as external and internal interfaces:

• ATM
• Basic Rate Interface (BRI)
• CTunnel
• Dialer
• Ethernet
• Fast Ethernet
• Gigabit Ethernet
• High-Speed Serial Interface (HSSI)
• Loopback (supported in Cisco IOS 15.0(1)M and later releases)
• Multilink
• Multilink Frame Relay (MFR)
• Null
• Packet-over-SONET (POS)
• Port Channel
• Serial
• Tunnel
• VLAN

The following interface types can be configured as local interfaces:

• Async
• Bridge Group Virtual Interface (BVI)
• Code division multiple access Internet exchange (CDMA-Ix)
• CTunnel
• Dialer
• Ethernet
• Group-Async
• Loopback
• Multilink
• Multilink Frame Relay (MFR)
• Null
• Serial
• Tunnel
• Virtual host interface (Vif)
• Virtual-PPP
• Virtual-Template
• Virtual-TokenRing

Note	A virtual-TokenRing interface can be configured as a local interface. However, Token Ring interfaces are not supported and cannot be configured as external, internal, or local interfaces.

Note	PfR does not support Ethernet interfaces that are Layer 2 only, for example, Ethernet switched interfaces.

Every traditional routing protocol creates a feedback loop among devices to create a routing topology. Performance Routing infrastructure includes a performance routing protocol that is communicated in a client-server messaging mode. The routing protocol employed by PfR runs between a network controller called a master controller and performance-aware devices called border routers. This performance routing protocol creates a network performance loop in which the network profiles which traffic classes have to be optimized, measures and monitors the performance metrics of the identified traffic classes, applies policies to the traffic classes, and routes the identified traffic classes based on the best performance path. The diagram below shows the five PfR phases: profile, measure, apply policy, enforce, and verify.

To understand how PfR operates in a network, you should understand and implement the five PfR phases. The PfR performance loop starts with the profile phase followed by the measure, apply policy, control, and verify phases. The flow continues after the verify phase back to the profile phase to update the traffic classes and cycle through the process.

• Profile Phase
• Measure Phase
• Apply Policy Phase
• Enforce Phase
• Verify Phase

Enterprise networks use multiple Internet Service Provider (ISP) or WAN connections at the network edge for reliability and load distribution. Existing reliability mechanisms depend on link state or route removal on the border router to select the best exit link for a prefix or set of prefixes. Multiple connections protect enterprise networks from catastrophic failures but do not protect the network from brownouts, or soft failures, that occur because of network congestion. Existing mechanisms can respond to catastrophic failures at the first indication of a problem. However, blackouts and brownouts 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 of 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.

Although many of the examples used to describe PfR deployment show ISPs as the network with which the edge devices communicate, there are other solutions. The network edge can be defined as any logical separation in a network: can be another part of the network such as a data center network within the same location, as well as WAN and ISP connections. The network, or part of the network, connected to the original network edge devices must have a separate autonomous system number when communicating using BGP.

PfR is implemented as an integrated part of Cisco core routing functionality. Deploying PfR enables intelligent network traffic load distribution and dynamic failure detection for data paths at the network edge. While other routing mechanisms can provide both load distribution and failure mitigation, only PfR 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 PfR allows you to optimize network performance and link load utilization while minimizing bandwidth costs and reducing operational expenses.

• Typical Topology on Which PfR is Deployed

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    key chain name-of-chain

4.    key key-id

5.    key-string text

6.    exit

7.    Repeat Step 6

8.    Repeat Step 3 through Step 7 with appropriate changes to configure key chain authentication for each border router.

9.    pfr master

10.    logging

11.    border ip-address [key-chain key-chain-name]

12.    interface type number external

13.    exit

14.    interface type number internal

15.    exit

16.    Repeat Step 11 through Step 15 with appropriate changes to establish communication with each border router.

17.    keepalive timer

18.    end

19.    show running-config

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	key chain name-of-chain Example: Router(config)# key chain border1_PFR	Enables key-chain authentication and enters key-chain configuration mode. Key-chain authentication protects the communication session between the master controller and the border router. The key ID and key string must match in order for communication to be established. In this example, a key chain is created for use with border router 1.
Step 4	key key-id Example: Router(config-keychain)# key 1	Identifies an authentication key on a key chain. The key ID must match the key ID configured on the border router.
Step 5	key-string text Example: Router(config-keychain-key)# key-string b1	Specifies the authentication string for the key and enters key-chain key configuration mode. The authentication string must match the authentication string configured on the border router. Any encryption level can be configured. In this example, a key string is created for use with border router 1.
Step 6	exit Example: Router(config-keychain-key)# exit	Exits key-chain key configuration mode and returns to key-chain configuration mode.
Step 7	Repeat Step 6	Exits key-chain configuration mode and returns to global configuration mode.
Step 8	Repeat Step 3 through Step 7 with appropriate changes to configure key chain authentication for each border router.	--
Step 9	pfr master Example: Router(config)# pfr master	Enters PfR master controller configuration mode to configure a router as a master controller. A master controller and border router process can be enabled on the same router (for example, in a network that has a single router with two exit links to different service providers).
Step 10	logging Example: Router(config-pfr-mc)# logging	Enables syslog messages for a master controller or border router process. The notice level of syslog messages is enabled by default.
Step 11	border ip-address [key-chain key-chain-name] Example: Router(config-pfr-mc)# border 10.1.1.2 key-chain border1_PFR	Enters PfR-managed border router configuration mode to establish communication with a border router. An IP address is configured to identify the border router. At least one border router must be specified to create an PfR-managed network. A maximum of ten border routers can be controlled by a single master controller. The value for the key-chain-name argument must match the key-chain name configured in Step 3. Note    The key-chain keyword and key-chain-name argument must be entered when a border router is initially configured. However, this keyword is optional when reconfiguring an existing border router.
Step 12	interface type number external Example: Router(config-pfr-mc-br)# interface Ethernet 1/0 external	Configures a border router interface as an PfR-managed external interface. External interfaces are used to forward traffic and for active monitoring. A minimum of two external border router interfaces are required in an PfR-managed network. At least one external interface must be configured on each border router. A maximum of 20 external interfaces can be controlled by single master controller. Tip    Configuring an interface as an PfR-managed external interface on a router enters PfR border exit interface configuration mode. In this mode, you can configure maximum link utilization or cost-based optimization for the interface. Note    Entering the interface (PfR) command without the external orinternal keyword places the router in global configuration mode and not PfR border exit configuration mode. The no form of this command should be applied carefully so that active interfaces are not removed from the router configuration.
Step 13	exit Example: Router(config-pfr-mc-br-if)# exit	Exits PfR-managed border exit interface configuration mode and returns to PfR-managed border router configuration mode.
Step 14	interface type number internal Example: Router(config-pfr-mc-br)# interface Ethernet 0/0 internal	Configures a border router interface as an PfR controlled internal interface. Internal interfaces are used for passive monitoring only. Internal interfaces do not forward traffic. At least one internal interface must be configured on each border router.
Step 15	exit Example: Router(config-pfr-mc-br)# exit	Exits PfR-managed border router configuration mode and returns to PfR master controller configuration mode.
Step 16	Repeat Step 11 through Step 15 with appropriate changes to establish communication with each border router.	--
Step 17	keepalive timer Example: Router(config-pfr-mc)# keepalive 10	(Optional) Configures the length of time that an PfR master controller will maintain connectivity with an PfR border router after no keepalive packets have been received. The example sets the keepalive timer to 10 seconds. The default keepalive timer is 60 seconds.
Step 18	end Example: Router(config-pfr-mc-learn)# end	Exits PfR Top Talker and Top Delay learning configuration mode and returns to privileged EXEC mode.
Step 19	show running-config Example: Router# show running-config	(Optional) Displays the running configuration to verify the configuration entered in this task.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    key chain name-of-chain

4.    key key-id

5.    key-string text

6.    exit

7.    Repeat Step 6

8.    pfr border

9.    local type number

10.    master ip-address key-chain key-chain-name

11.    end

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	key chain name-of-chain Example: Router(config)# key chain border1_PFR	Enables key-chain authentication and enters key-chain configuration mode. Key-chain authentication protects the communication session between both the master controller and the border router. The key ID and key string must match in order for communication to be established.
Step 4	key key-id Example: Router(config-keychain)# key 1	Identifies an authentication key on a key chain and enters key-chain key configuration mode. The key ID must match the key ID configured on the master controller.
Step 5	key-string text Example: Router(config-keychain-key)# key-string b1	Specifies the authentication string for the key. The authentication string must match the authentication string configured on the master controller. Any level of encryption can be configured.
Step 6	exit Example: Router(config-keychain-key)# exit	Exits key-chain key configuration mode and returns to key-chain configuration mode.
Step 7	Repeat Step 6 Example: Router(config-keychain)# exit	Exits key-chain configuration mode and returns to global configuration mode.
Step 8	pfr border Example: Router(config)# pfr border	Enters PfR border router configuration mode to configure a router as a border router. The border router must be in the forwarding path and contain at least one external and internal interface.
Step 9	local type number Example: Router(config-pfr-br)# local Ethernet 0/0	Identifies a local interface on a PfR border router as the source for communication with an PfR master controller. A local interface must be defined. Tip    A loopback should be configured when a single router is configured to run both a master controller and border router process.
Step 10	master ip-address key-chain key-chain-name Example: Router(config-pfr-br)# master 10.1.1.1 key-chain border1_PFR	Enters PfR-managed border router configuration mode to establish communication with a master controller. An IP address is used to identify the master controller. The value for the key-chain-name argument must match the key-chain name configured in Step 3.
Step 11	end Example: Router(config-pfr-br)# end	Exits PfR Top Talker and Top Delay learning configuration mode and returns to privileged EXEC mode.

• What to Do Next