Feedback
|
Table Of Contents
BGP Diverse Path Using a Diverse-Path Route Reflector
Prerequisites for BGP Diverse Path Using a Diverse-Path Route Reflector
Restrictions for BGP Diverse Path Using a Diverse-Path Route Reflector
Information About BGP Diverse Path Using a Diverse-Path Route Reflector
Limitation that a BGP Diverse Path Overcomes
BGP Diverse Path Using a Diverse-Path Route Reflector
Triggers to Compute a BGP Diverse Path
How to Configure a BGP Diverse-Path Route Reflector
Determine Whether You Need to Disable the IGP Metric Check
Configure the Route Reflector for BGP Diverse Path
Configuration Examples for BGP Diverse Path Using a Diverse-Path Route Reflector
Example: BGP Diverse Path Where Additional Path Is the Backup Path
Example: BGP Diverse Path Where Additional Path Is the Multipath
Example: BGP Diverse Path Where Both Multipath and Backup Path Calculations Are Triggered
Example: Triggering Computation and Installation of a Backup Path
Feature Information for BGP Diverse Path Using a Diverse-Path Route Reflector
BGP Diverse Path Using a Diverse-Path Route Reflector
First Published: July 25, 2011Last Updated: July 25, 2011The BGP Diverse Path Using a Diverse-Path Route Reflector feature allows BGP to distribute an alternative path other than the best path between BGP speakers when route reflectors are deployed. This feature is meant to provide path diversity within an AS, within a single cluster only. That is, an RR is allowed to advertise the diverse path to its client peers only.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see 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 for BGP Diverse Path Using a Diverse-Path Route Reflector" section.
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.
Contents
•
Prerequisites for BGP Diverse Path Using a Diverse-Path Route Reflector
•
Restrictions for BGP Diverse Path Using a Diverse-Path Route Reflector
•
Information About BGP Diverse Path Using a Diverse-Path Route Reflector
•
How to Configure a BGP Diverse-Path Route Reflector
•
Configuration Examples for BGP Diverse Path Using a Diverse-Path Route Reflector
•
Feature Information for BGP Diverse Path Using a Diverse-Path Route Reflector
Prerequisites for BGP Diverse Path Using a Diverse-Path Route Reflector
You should understand the BGP Best External feature.
Restrictions for BGP Diverse Path Using a Diverse-Path Route Reflector
•
A diverse path can be configured on an RR only.
•
Only one shadow RR is allowed per existing RR, which will calculate one additional best path (the second best path). In other words, only one additional plane (topology) is configured.
•
Path diversity is configured within an AS, within a single RR cluster. That is, the RR will advertise the diverse path to its RR client peers only.
•
Diverse path functionality is not supported on a route server.
Information About BGP Diverse Path Using a Diverse-Path Route Reflector
•
Limitation that a BGP Diverse Path Overcomes
•
BGP Diverse Path Using a Diverse-Path Route Reflector
•
Triggers to Compute a BGP Diverse Path
•
Route Reflector Determination
Limitation that a BGP Diverse Path Overcomes
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 (RR) is one of the main reasons for poor path diversity within an autonomous system (AS). In a network with RRs, even if a prefix is learned from multiple egress routers, the RR reflects only the best path to its clients. Figure 1 shows how deploying RRs might reduce path diversity in an AS, even when the BGP Best External feature is deployed.
Figure 1 Route Reflectors in an AS Reduce Path Diversity
In Figure 1, P1 and P2 are diverse paths for prefix p. Assume Path2 (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 RRs, regardless of P2 having a lower MED and higher local preference. The RRs 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 RRs 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.
BGP Diverse Path Using a Diverse-Path Route Reflector
The BGP Diverse Path Using a Diverse-Path Route Reflector feature overcomes the lack of path diversity in an AS containing RRs. This feature is meant to provide path diversity within an AS, within a single cluster only. That is, an RR is allowed to advertise the diverse path to its client peers only.
For each RR in the AS, a shadow RR is added to distribute the second best path, also known as the diverse path. Figure 2 shows the shadow RR for RR2. The shadow RR improves path diversity because PE3 can now learn both P1 (from RR1/RR2) and learn P2 from the shadow RR.
Note
The primary RR and shadow RR must have the exact same connections (physical/control plane) to the rest of the routers in the network.
Shadow RRs can be both control plane RRs and data plane RRs.
Figure 2 Shadow RR Provides Second Best Path for Path Diversity
Figure 3 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.
Figure 3 RR and Shadow RR Provide Two Different Next Hops for Path Diversity
Triggers to Compute a BGP Diverse Path
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).
IGP Metric Check
Disabling the IGP metric check and configuring BGP Diverse Path 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 RR and shadow RR are co-located).
The bgp bestpath igp-metric ignore command can be configurd at RRs and 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.
Route Reflector Determination
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
How to Configure a BGP Diverse-Path Route Reflector
Perform the tasks in this section to configure a BGP Diverse-Path Route Reflector.
•
Determine Whether You Need to Disable the IGP Metric Check (required)
•
Configure the Route Reflector for BGP Diverse Path (required)
Determine Whether You Need to Disable the IGP Metric Check
Before you configure a shadow RR 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 OSPF, EIGRP, or RIP. A smaller IGP metric is preferred over a larger IGP metric.
The locations of the RR and shadow RR determine whether or not you need to disable the IGP metric check, as follows:
•
When the RR and shadow RR are co-located—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 RR going down. When RRs are co-located, 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 RR. Since there is no need to disable the IGP metric check, the first plane RRs do not need to be upgraded to Cisco IOS XE Release 3.4S.
•
When the shadow RR is in a different IGP place from the RR (it is not co-located with its best path RR)—In this case, the IGP metric check is ignored on both the best path RR and shadow RR when the best path and second best path are being calculated. The IGP metric check must be disabled on the primary RR 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.
Configure the Route Reflector for BGP Diverse Path
Perform this task to configure a route reflector for the BGP Diverse Path feature. This task specifies the IPv4 address family, but other address families are also supported.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
router bgp autonomous-system-number
4.
neighbor ip-address remote-as autonomous-system-number
5.
address-family ipv4 unicast
6.
neighbor ip-address activate
7.
maximum-paths ibgp number-of-paths
8.
bgp bestpath igp-metric ignore
9.
bgp additional-paths select [backup]
10.
bgp additional-paths install
11.
neighbor ip-address route-reflector-client
12.
neighbor ip-address advertise diverse-path backup [mpath]
13.
end
14.
show ip bgp neighbor ip-address advertised-routes
DETAILED STEPS
Configuration Examples for BGP Diverse Path Using a Diverse-Path Route Reflector
•
Example: BGP Diverse Path Where Additional Path Is the Backup Path
•
Example: BGP Diverse Path Where Additional Path Is the Multipath
•
Example: BGP Diverse Path Where Both Multipath and Backup Path Calculations Are Triggered
•
Example: Triggering Computation and Installation of a Backup Path
Example: BGP Diverse Path Where Additional Path Is the Backup Path
Diverse path functionality is contained to within a single cluster; that is, only the clients of an RR can be configured to advertise the diverse path. A diverse path is advertised to the clients of an RR only if the client is configured to get the additional path.
A shadow RR can be added to calculate and advertise the additional path, or an existing RR can be configured to calculate and advertise the additional path. In Figure 4, instead of adding a shadow RR, RR2 (the existing backup RR) is configured to calculate the additional path and advertise it to a particular neighbor.
In Figure 4, assume that from the RRs, the path to CE1 via PE1 is preferred over the path via PE2. Without the diverse path feature, both RRs will advertise to PE3 that the path to CE1 is via PE1. If the connection between RR1 and PE1 fails (or the path between PE1 and CE1 fails), there is no other path.
Figure 4 BGP Diverse Path Scenario
In the following configuration example based on Figure 4, RR2 is configured with an additional path, which is a backup path.
If RR1 and RR2 are not co-located, you must configure the bgp bestpath igp-metric ignore command before the additional path is calculated. (If RR1 and RR2 are co-located, do not configure that command.)
The bgp additional-paths select backup command triggers calculation of the backup path at RR2, which is the path via PE2.
The bgp additional-paths install command installs the backup path if RR2 is in the forwarding plane. (Do not configure this command if RR2 is in the control plane.)
The address of PE3 is 10.1.1.1, and that address is used in the neighbor advertise diverse-path backup command on RR2. This command triggers advertisement of the backup path to PE3. PE3 will learn the best path, (which is the path via PE1) from RR1, and it will learn the backup path from RR2.
RR2
router bgp 1neighbor 10.1.1.1 remote-as 1address-family ipv4 unicastneighbor 10.1.1.1 activatemaximum-paths ibgp 4bgp bestpath igp-metric ignorebgp additional-paths select backupbgp additional-paths installneighbor 10.1.1.1 route-reflector-clientneighbor 10.1.1.1 advertise diverse-path backupExample: BGP Diverse Path Where Additional Path Is the Multipath
In the following example based on Figure 4, assume that paths toward CE1 via PE1 and PE2 are multipaths. The maximum-paths ibgp command will trigger calculation of multipaths.
The address of PE3 is 10.1.1.1, and that address is used in the neighbor advertise diverse-path mpath command on RR2. This command will trigger advertisement of the multipath, that is, the second best path, to PE3. PE3 will learn the best path, path via PE1 from RR1, and will learn second best path from RR2.
RR2
router bgp 1neighbor 10.1.1.1 remote-as 1address-family ipv4 unicastneighbor 10.1.1.1 activatemaximum-paths ibgp 4neighbor 10.1.1.1 remote-as 1neighbor 10.1.1.1 route-reflector-clientneighbor 10.1.1.1 advertise diverse-path mpathExample: BGP Diverse Path Where Both Multipath and Backup Path Calculations Are Triggered
The following example is based on Figure 4. The maximum-paths ibgp command will trigger calculation of multipaths. When both multipath and backup path calculations are triggered, the backup path and the second multipath (which is the second best path) are the same paths and it will be installed as the active path, regardless of whether the RR is in the control plane or forwarding plane.
The address of PE3 is 10.1.1.1, and that address is used in the neighbor advertise diverse-path backup mpath command on RR2. This command causes RR2 to advertise the second best path, which is the second multipath, to PE3.
RR2
router bgp 1neighbor 10.1.1.1 remote-as 1address-family ipv4 unicastneighbor 10.1.1.1 activatemaximum-paths ibgp 4bgp additional-paths select backupneighbor 10.1.1.1 remote-as 1neighbor 10.1.1.1 route-reflector-clientneighbor 10.1.1.1 advertise diverse-path backup mpathExample: Triggering Computation and Installation of a Backup Path
When the bgp additional-paths install command is configured without configuring bgp additional-paths select backup, the former command will trigger both computation and installation of the backup path (as it is with the existing BGP PIC feature).
The address of PE3 is 10.1.1.1, and that address is used in the neighbor advertise diverse-path backup command on RR2. This command will trigger advertisement of a backup path to PE3. PE3 will learn the best path, a path via PE1 from RR1, and it will learn a backup path from RR2.
RR2
router bgp 1neighbor 10.1.1.1 remote-as 1address-family ipv4 unicastneighbor 10.1.1.1 activatemaximum-paths ibgp 4bgp additional-paths installneighbor 10.1.1.1 remote-as 1neighbor 10.1.1.1 route-reflector-clientneighbor 10.1.1.1 advertise diverse-path backupAdditional References
Related Documents
Related Topic Document TitleCisco IOS commands
BGP commands
Configuring BGP Best External Path on an RR for Intercluster
BGP configuration tasks
Standards
MIBs
RFCs
Technical Assistance
Feature Information for BGP Diverse Path Using a Diverse-Path Route Reflector
Table 1 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2011 Cisco Systems, Inc. All rights reserved.
Feedback



