Information About PfR Target Discovery
PfR Target Discovery
Cisco Performance Routing (PfR) complements classic IP routing technologies by adding intelligence to select best paths to meet application performance requirements. The figure below illustrates the difference between PfR and classic IP routing technologies. In the figure below, the traffic is running from the head office at Site 1 to a remote office at Site 2. Traditional routing technologies would use the routing table information and route the traffic through Service Provider 1 because of the shorter path. If, however, there is heavy congestion leading to traffic loss and an increased delay through SP1, a traditional routing technology cannot see the performance degradation and will continue to route the traffic through SP1. PfR routes traffic across the network using a best path determined by data measurements such as reachability, delay, loss. jitter, MOS, throughput, and load, with the ability to consider monetary cost and user-defined policies. Unlike classic IP routing technologies, PfR provides adaptive routing adjustments based on real-time performance metrics. In the figure below, for example, PfR reroutes the traffic through SP2 and SP3 as the best path because of the poor performance measurements of traffic through SP1.
Note |
The network diagram below relates to both SPs within an MPLS VPN network and Internet Service Providers (ISPs) for a smaller enterprise network. |
To optimize voice and video applications, PfR uses jitter, loss, and delay measurements to determine the best media path. The IP SLA udp-jitter probe provides these measurements but requires an IP SLA responder. PfR needs to know the IP address of the nearest IP SLA responder to the destination prefix for a voice and video traffic class. Manual configuration of IP SLA responders for each destination IP prefix range within each PfR application policy is not seen as a scalable solution in Enterprise networks with hundreds or potentially thousands of branch sites over the WAN.
To address these manual configuration issues, PfR target-discovery introduces master controller peering and uses EIGRP Service Advertisement Facility (SAF) to advertize IP SLA responder IP addresses to allow automatic discovery and configuration of the responders and associated destination IP prefix ranges.
Target Discovery Data Distribution
-
Reduces IP SLA target configuration per destination and per policy.
-
Improves IP SLA probing efficiency by sharing probe data across multiple policies.
Each PfR master controller (MC) running target discovery advertises the local known IP prefix ranges and local IP SLA responder(s) for other MCs to discover or learn over the WAN. Each MC running target discovery also learns advertised IP SLA responders and associated destination IP prefix ranges from other MCs to dynamically configure policies requiring probe data from IP SLA responders. PfR uses the Cisco Service Routing (SR) and Service Advertisement Framework (SAF) to distribute and discover IP SLA target information.
For more details about SAF, see the Service Advertisement Framework Configuration Guide.
Master Controller Peering Using SAF
PfR master controller peering runs over Service Advertisement Framework (SAF). Using Service Routing (SR) forwarders on each master controller to establish peering between MCs at different sites, MC peering allows the advertisement and discovery of PfR target discovery data.
The target-discovery-enabled MCs at the hub site (known as a headend) and at the branch office serve as both an SR internal client and an SR forwarder. Before any of the target discovery services can be advertised, the MCs must be configured as SR forwarders and for SR peering. After MC peering is established, an MC can advertise local information to allow other MCs to perform target discovery and autoconfigure.
Every customer network deployment is different, and with each deployment there are various methods to configure an SR topology configuration. The deployment model used by the customer for the network dictates how the SR forwarder must be configured. The MC-MC peering aspect of the target discovery feature supports two different customer network deployments:
-
Multihop—Networks in which the customer headend and branch offices are separated by one or more routers not under the administrative control of the customer or not SAF-enabled. An example would be an MPLS VPN WAN service.
-
SAF-Everywhere—Networks in which all routers are enabled for EIGRP SAF in a contiguous path from the headend MC to the branch office MC. An example would be a DMVPN WAN.
The topology in the figure below illustrates an example deployment of MC peering in a multihop type of network. The hub site (San Jose) MC and the branch office sites (New York and Miami) MC systems peer across a logical unicast topology. In this model, the hub site and branch sites are separated by a network—typically a Service Provider (SP)—where EIGRP SR forwarders are not configured.
The figure below shows PfR target discovery implemented in the same enterprise WAN network as in the figure above running MPLS IP VPN and DMVPN. After MC peering is enabled, the San Jose master controller is the SAF hub forwarder and the New York and Miami MCs peer with the San Jose MC. Target discovery allows each MC to advertise local IP prefixes and IP SLA responders using SAF, and each MC learns the remote IP prefixes and IP SLA responders from SAF. PfR probes the remote-site IP SLA responders to measure the network performance.
MC peering over a multihop network is an overlay model similar to a BGP route reflector. The MC peering system must configure a source loopback interface with an IP address that is reachable (routed) through the network.
Master Controller Peering Configuration Options
Each PfR master controller (MC) running target discovery advertises the local known IP prefix ranges and local IP SLA responder(s) for other MCs to discover or learn over the WAN. Each MC running target discovery also learns advertised IP SLA responders and associated destination IP prefix ranges from other MCs to dynamically configure policies requiring probe data.
Depending on the network structure and the degree of control required over the configuration of probe targets and IP SLA responders, there are three main options available when configuring MC peering using the mc-peer command:
-
Configuring the headend (at the hub site) or the peer IP address (at the branch site). When using this option, configuring a loopback interface as the source of EIGRP SAF adjacency is recommended. This configuration option is used in the multihop type of network.
-
Configuring a SAF domain ID or using the default SAF domain ID of 59501. This option requires EIGRP SAF configuration on both hub-site and branch-site master controller routers and can be used in the SAF-everywhere type of network.
-
Configuring the EIGRP option where there is no autoconfiguration of EIGRP SAF. This option is used in the SAF-everywhere type of network. If SAF is already configured on routers in the network, you can use the same network and overlay PfR target discovery. Please refer to the SAF configuration guide to learn how to configure SAF independent of PfR target discovery.