Your software release may not support all the features documented in this module. For the latest caveats and feature information, see the Bug Search Tool and 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 table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn . An account on Cisco.com is not required.

As a path vector routing protocol, BGP-4 requires a router to advertise to its neighbors only the best path for a destination. However, multiple paths to the same destination would allow mechanisms that can improve resilience, quickly recover from failures, and load balance, for example.

The use of route reflectors is one of the main reasons for poor path diversity within an autonomous system (AS). In a network with route reflectors, even if a prefix is learned from multiple egress routers, the route reflector reflects only the best path to its clients. The figure below shows how deploying route reflectors might reduce path diversity in an AS, even when the BGP Best External feature is deployed.

In the figure above, P1 and P2 are diverse paths for prefix p. Assume Path 2 (P2) has a lower MED and higher local preference than P1. The BGP Best External feature on PE1 will make sure that P1 is propagated to the route reflectors, regardless of P2 having a lower MED and higher local preference. The route reflectors will have path diversity; they will learn both P1 and P2 with different exit points PE1 and PE2 (assuming that PE1 and PE2 have the set ip next-hop self command configured). However, both route reflectors select the best path as P2 due to its lower MED/higher local preference and advertise it to PE3. PE3 will not learn P1 (that is, PE3 will not learn about existing path diversity).

The BGP Diverse Path Using a Diverse-Path Route Reflector feature is a way to resolve that limitation and achieve path diversity.

The BGP Diverse Path Using a Diverse-Path Route Reflector feature overcomes the lack of path diversity in an AS containing route reflectors. This feature is meant to provide path diversity within an AS, within a single cluster only. That is, a route reflector is allowed to advertise the diverse path to its client peers only.

For each route reflector in the AS, a shadow route reflector is added to distribute the second best path, also known as the diverse path. The figure below shows the shadow route reflector for RR2. The shadow route reflector improves path diversity because PE3 can now learn both P1 (from RR1/RR2) and learn P2 from the shadow route reflector.

Note	The primary route reflector and shadow route reflector must have the exact same connections (physical/control plane) to the rest of the routers in the network.

Shadow route reflectors can be both control plane route reflectors and data plane route reflectors.

The figure below shows a diverse path in greater detail, indicating the next hops:

• BR2 announces to RR1 and shadow RR2 that R2 (BR2) is the Next Hop for those who want to reach Prefix Z. Likewise, BR3 announces to RR1 and shadow RR2 that R3 (BR3) is the Next Hop for those who want to reach Prefix Z

• RR1 sends a packet to BR1 announcing that the Next Hop is R2 if BR1 wants to reach Prefix Z. The second best path (or diverse path) comes from shadow RR2, which sends a packet to BR1 announcing that the Next Hop is R3 if BR1 want to reach Prefix Z.

• At BR1 (far right), we see there are two (diverse) paths to Prefix Z.

Computation of a diverse path per address family is triggered by any of the following commands:

• bgp additional-paths install

• bgp additional-paths select

• maximum-paths ebgp

• maximum-paths ibgp

The bgp additional-paths install command will install the type of path that is specified in the bgp additional-paths select command. If the bgp additional-paths select command specifies both keyword options (best-external and backup ), the system will install a backup path.

The maximum-paths ebgp and maximum-paths ibgp commands trigger a multipath computation, and multipaths are automatically installed as primary paths.

On the other hand, the bgp additional-paths install command triggers computation of a backup path or best-external path.

If the bgp additional-paths select command is not configured, the bgp additional-paths install command will trigger both computation and installation of a backup path (as is done with the BGP PIC feature).

Disabling the Interior Gateway Protocol (IGP) metric check and configuring the BGP Diverse Path feature are independent of each other. One does not imply the other. That is, configuring bgp bestpath igp-metric ignore does not imply that the BGP Diverse Path feature is enabled. Conversely, enabling the BGP Diverse Path feature might not require that bgp bestpath igp-metric ignore be configured (because, for example, the route reflector and shadow route reflector are co-located).

The bgp bestpath igp-metric ignore command can be configured at route reflectors and provider edges (PEs).

Note	Per-VRF functionality for the bgp bestpath igp-metric ignore command is not supported. If you use it anyway, it is at your own risk.

If a router’s configuration includes either one of the following commands, the router is a route reflector:

• bgp cluster-id

• neighbor route-reflector-client

Before you configure a shadow route reflector in order to get a BGP diverse path, determine whether you need to disable the IGP metric check. The IGP metric is a configurable value indicating physical distance, and is used by an Interior Gateway Protocol, such as Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), or Routing Information Protocol (RIP). A smaller IGP metric is preferred over a larger IGP metric.

The locations of the route reflector and shadow route reflector determine whether or not you need to disable the IGP metric check, as follows:

• When the route reflector and shadow route reflector are colocated—They have the same IP subnetwork address and are connected to the Ethernet switch with different links. Failure of such a link is equivalent to the route reflector going down. When RRs are colocated, their IGP metrics cannot be different from each other; and therefore there is no need to disable the IGP metric check during the best path calculation at any route reflector. Because there is no need to disable the IGP metric check, the first plane route reflectors do not need to be upgraded to Cisco IOS XE Release 3.4S.

• When the shadow route reflector is in a different IGP place from the route reflector (it is not colocated with its best path route reflector)--In this case, the IGP metric check is ignored on both the best path route reflector and shadow route reflector when the best path and second best path are being calculated. The IGP metric check must be disabled on the primary route reflector by configuring the bgp bestpath igp-metric ignore command. This command is available beginning with Cisco IOS XE Release 3.4S, which means you need to upgrade to that release.