- Cisco BGP Overview
- BGP 4
- Configuring a Basic BGP Network
- BGP 4 Soft Configuration
- BGP Support for 4-byte ASN
- IPv6 Routing: Multiprotocol BGP Extensions for IPv6
- IPv6 Routing: Multiprotocol BGP Link-Local Address Peering
- IPv6 Multicast Address Family Support for Multiprotocol BGP
- Configuring Multiprotocol BGP (MP-BGP) Support for CLNS
- Connecting to a Service Provider Using External BGP
- BGP Route-Map Continue
- BGP Route-Map Continue Support for Outbound Policy
- Removing Private AS Numbers from the AS Path in BGP
- Configuring BGP Neighbor Session Options
- BGP Neighbor Policy
- BGP Dynamic Neighbors
- BGP Support for Next-Hop Address Tracking
- BGP Restart Neighbor Session After Max-Prefix Limit Reached
- BGP Support for Dual AS Configuration for Network AS Migrations
- Configuring Internal BGP Features
- BGP VPLS Auto Discovery Support on Route Reflector
- BGP FlowSpec Route-reflector Support
- BGP Flow Specification Client
- BGP NSF Awareness
- BGP Graceful Restart per Neighbor
- BGP Support for BFD
- IPv6 NSF and Graceful Restart for MP-BGP IPv6 Address Family
- BGP Link Bandwidth
- iBGP Multipath Load Sharing
- BGP Multipath Load Sharing for Both eBGP and iBGP in an MPLS-VPN
- Loadsharing IP Packets over More Than Six Parallel Paths
- BGP Policy Accounting
- BGP Policy Accounting Output Interface Accounting
- BGP Cost Community
- BGP Support for IP Prefix Import from Global Table into a VRF Table
- BGP Support for IP Prefix Export from a VRF Table into the Global Table
- BGP per Neighbor SoO Configuration
- Per-VRF Assignment of BGP Router ID
- BGP Next Hop Unchanged
- BGP Support for the L2VPN Address Family
- BGP Event-Based VPN Import
- BGP Best External
- BGP PIC Edge for IP and MPLS-VPN
- Detecting and Mitigating a BGP Slow Peer
- Configuring BGP: RT Constrained Route Distribution
- Configuring a BGP Route Server
- BGP Diverse Path Using a Diverse-Path Route Reflector
- BGP Enhanced Route Refresh
- Configuring BGP Consistency Checker
- BGP—Origin AS Validation
- BGP MIB Support
- BGP 4 MIB Support for Per-Peer Received Routes
- BGP Support for Nonstop Routing (NSR) with Stateful Switchover (SSO)
- BGP NSR Auto Sense
- BGP NSR Support for iBGP Peers
- BGP Graceful Shutdown
- BGP — mVPN BGP sAFI 129 - IPv4
- BGP-MVPN SAFI 129 IPv6
- BFD—BGP Multihop Client Support, cBit (IPv4 and IPv6), and Strict Mode
- BGP Attribute Filter and Enhanced Attribute Error Handling
- BGP Additional Paths
- BGP-Multiple Cluster IDs
- BGP-VPN Distinguisher Attribute
- BGP-RT and VPN Distinguisher Attribute Rewrite Wildcard
- VPLS BGP Signaling
- Multicast VPN BGP Dampening
- BGP—IPv6 NSR
- BGP-VRF-Aware Conditional Advertisement
- BGP—Selective Route Download
- BGP—Support for iBGP Local-AS
- eiBGP Multipath for Non-VRF Interfaces (IPv4/IPv6)
- L3VPN iBGP PE-CE
- BGP NSR Support for MPLS VPNv4 and VPNv6 Inter-AS Option B
- BGP-RTC for Legacy PE
- BGP PBB EVPN Route Reflector Support
- BGP Monitoring Protocol
- VRF Aware BGP Translate-Update
- BGP Support for MTR
- BGP Accumulated IGP
- BGP MVPN Source-AS Extended Community Filtering
- BGP AS-Override Split-Horizon
- BGP Support for Multiple Sourced Paths Per Redistributed Route
BGP-Multiple Cluster IDs
The BGP—Multiple Cluster IDs feature allows an iBGP neighbor (usually a route reflector) to have multiple cluster IDs: a global cluster ID and additional cluster IDs that are assigned to clients (neighbors). Prior to the introduction of this feature, a device could have a single, global cluster ID.
When a network administrator configures per-neighbor cluster IDs:
- Finding Feature Information
- Information About BGP-Multiple Cluster IDs
- How to Use BGP-Multiple Cluster IDs
- Configuration Examples for BGP-Multiple Cluster IDs
- Additional References
- Feature Information for BGP-Multiple Cluster IDs
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see 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 www.cisco.com/go/cfn. An account on Cisco.com is not required.
Information About BGP-Multiple Cluster IDs
Benefit of Multiple Cluster IDs Per Route Reflector
The BGP—Multiple Cluster IDs feature allows a route reflector (RR) to belong to multiple clusters, and therefore have multiple cluster IDs. An RR can have a cluster ID configured on a global basis and a per-neighbor basis. A single cluster ID can be assigned to two or more iBGP neighbors. Prior to this feature, an RR had a single, global cluster ID, which was configured by the bgp cluster-id router configuration command.
When a cluster ID is configured per neighbor (by the neighbor cluster-id router configuration command), the following two changes occur:
The loop prevention mechanism based on the CLUSTER_LIST attribute is automatically modified to take into account multiple cluster IDs.
The network administrator can disable client-to-client route reflection based on cluster ID, which allows the network design to change.
The loop prevention mechanism and the CLUSTER_LIST propagation rules are described in the section “How a CLUSTER_LIST Attribute is Used.” Disabling client-to-client reflection is described in the section “Behaviors When Disabling Client-to-Client Route Reflection.”
How a CLUSTER_LIST Attribute is Used
The CLUSTER_LIST propagation rules differ among releases, depending on whether the device is running a Cisco software release generated before or after the BGP—Multiple Cluster IDs feature was implemented. The same is true for loop prevention based on the CLUSTER_LIST.
The CLUSTER_LIST behavior is described below. Classic refers to the behavior of software released before the multiple cluster IDs feature was implemented; MCID refers to the behavior of software released after the feature was implemented.
CLUSTER_LIST Propagation Rules
Classic—Before reflecting a route, the RR appends the global cluster ID to the CLUSTER_LIST. If the received route had no CLUSTER_LIST attribute, the RR creates a new CLUSTER_LIST attribute with that global cluster ID.
MCID—Before reflecting a route, the RR appends the cluster ID of the neighbor the route was received from to the CLUSTER_LIST. If the received route had no CLUSTER_LIST attribute, the RR creates a new CLUSTER_LIST attribute with that cluster ID. This behavior includes a neighbor that is not a client of the speaker. If the nonclient neighbor the route was received from does not have an associated cluster ID, the RR uses the global cluster ID.
Loop Prevention Based on CLUSTER_LIST
Classic—When receiving a route, the RR discards the route if the RR's global cluster ID is contained in the CLUSTER_LIST of the route.
MCID—When receiving a route, the RR discards the route if the RR's global cluster ID or any of the cluster IDs assigned to any of the iBGP neighbors is contained in the CLUSTER_LIST of the route.
Behaviors When Disabling Client-to-Client Route Reflection
With the introduction of multiple cluster IDs per iBGP neighbor, it is possible to disable route reflection from client to client on the basis of cluster ID. Disabling route reflection allows you to change the network design. A typical (but not required) scenario after disabling route reflection is that clients are fully meshed, so they have to send more updates, and the RR has client-to-client reflection disabled, so that it has to send fewer updates.
You might want to disable route reflection in a scenario similar to the one in the figure below. An RR has several clients [Provider-Edge (PE) routers] with which it has sessions. The iBGP neighbors that should belong to one cluster were assigned the same cluster ID.
Because the PEs belonging to the same cluster are fully meshed (PE1 and PE2 have a session between them; PE3 and PE4 have a session between them), there is no need to reflect the routes between them. That is, routes from PE1 should be forwarded to PE3 and PE4, but not to PE2.
It is important to know that when the software changes reflection state for a given cluster ID, BGP sends an outbound soft refresh to all clients.
Disabling client-to-client route reflection is done differently and has different results, depending on whether the device is running Cisco software generated before or after the multiple cluster IDs feature was implemented. Classic refers to the behavior of software released before the multiple cluster IDs feature was implemented; MCID refers to the behavior of software released after the multiple cluster IDs feature was implemented.
Classic—When receiving a route from a client, the RR does not reflect it to any other client. Other scenarios for reflection (client-to-nonclient and nonclient-to-client) are maintained. Disabling of route reflection from client to client is usually done when all the clients are fully meshed (the routes are advertised between the clients via that mesh, so there is no need for reflection). The command to disable client-to-client route reflection is entered in router configuration mode (after the router bgp command) and it applies globally to all address families: no bgp client-to-client reflection
- MCID—When receiving a route from a client, the RR does not reflect it to another client if both clients belong to a cluster for which client-to-client reflection has been disabled. Therefore, route reflection is disabled only intracluster (within the cluster specified). Other cases for reflection (client-to-nonclient, nonclient-to-client, and intercluster) are maintained. This functionality is usually configured when all the clients for a particular cluster are fully meshed among themselves (but not with clients of other clusters). The command to disable client-to-client route reflection for a particular cluster is entered in router configuration mode and it applies globally to all address families:
no bgp client-to-client reflection intra-cluster cluster-id {any | cluster-id1 cluster-id2...}
The any keyword is used to disable client-to-client reflection for any cluster.
The Classic, previously released command for disabling all client-to-client reflection is also still available during this post-MCID release timeframe:
no bgp client-to-client reflection [all]
(The optional all keyword has no effect in either the positive or negative form of the command, and does not appear in configuration files. It is just to remind the network administrator that both intercluster and intracluster client-to-client reflection are enabled or disabled.)
In summary, after the introduction of the multiple cluster IDs feature, there are three levels of configuration that can disable client-to-client reflection. The software performs them in the following order, from least specific to most specific:
Least specific: no bgp client-to-client reflection [all] Disables intracluster and intercluster client-to-client reflection.
More specific: no bgp client-to-client reflection intra-cluster cluster-id any Disables intracluster client-to-client reflection for any cluster-id.
Most specific: no bgp client-to-client reflection intra-cluster cluster-id cluster-id1 cluster-id2 ... Disables intracluster client-to-client reflection for the specified clusters.
When BGP is advertising updates, the software evaluates each level of configuration in order. Once any level of configuration disables client-to-client reflection, no further evaluation of more specific policies is necessary.
Note the results of the base (positive) and negative (no) forms of the three commands listed above:
A negative configuration (that is, with the no keyword) overwrites any less specific configuration.
A positive configuration (that is, without the no keyword) will lose out to (default to) what is configured in a less specific configuration.
Configurations at any level appear in the configuration file only if they are negative.
All levels can be configured independently and all levels appear in the configuration file independently of the configuration of other levels.
Note that negative configuration makes any more specific configuration unnecessary (because even if the more specific configuration is positive, it is not processed after the negative configuration; if the more specific configuration is negative, it is functionally the same as the earlier negative configuration). The following examples illustrate this behavior.
Example 1
no bgp client-to-client reflection
no bgp client-to-client reflection intra-cluster cluster-id any
Intercluster and intracluster reflection are disabled (based on the first command). The second command disables intracluster reflection, but it is unnecessary because intracluster reflection is already disabled by the first command.
Example 2
no bgp client-to-client reflection intra-cluster cluster-id any
bgp client-to-client reflection intra-cluster cluster-id 1.1.1.1
Cluster ID 1.1.1.1 has intracluster route reflection disabled (even though the second command is positive), because the first command is used to evaluate the update. The first command was negative, and once any level of configuration disables client-to-client reflection, no further evaluation is performed.
Another way to look at this example is that the second command, because it is in a positive form, defaults to the behavior of the first command (which is less specific). Thus, the second command is unnecessary.
Note that the second command would not appear in a configuration file because it is not a negative command.
How to Use BGP-Multiple Cluster IDs
Configuring a Cluster ID per Neighbor
Perform this task on an iBGP peer (usually a route reflector) to configure a cluster ID per neighbor. Configuring a cluster ID per neighbor causes the loop-prevention mechanism based on the CLUSTER_LIST to be automatically modified to take into account multiple cluster IDs. Also, you gain the ability to disable client-to-client route reflection on the basis of cluster ID. The software tags the neighbor so that you can disable route reflection with the use of another command. (See the tasks for disabling client-to-client reflection later in this module.)
Note | When you change a cluster ID for a neighbor, BGP automatically does an inbound soft refresh and an outbound soft refresh for all iBGP peers. |
1.
enable
2.
configure
terminal
3.
router
bgp
as-number
4.
neighbor {ip-address |
ipv6-address}
remote-as
autonomous-system-number
5.
neighbor {ip-address |
ipv6-address}
cluster-id
cluster-id
6.
end
7.
show ip bgp cluster-ids
DETAILED STEPS
Disabling Intracluster and Intercluster Client-to-Client Reflection
Perform the following task on a route reflector if you want to disable both intracluster and intercluster client-to-client reflection. Doing so is the broadest (least specific) way to disable client-to-client reflection. Before advertising updates, the software evaluates each level of configuration in order from least specific to most specific. Once any level of configuration disables client-to-client reflection, no further evaluation of more specific policies is needed.
Note | When the software changes reflection state for a given cluster ID, BGP sends an outbound soft refresh to all clients. |
1.
enable
2.
configure
terminal
3.
router
bgp
as-number
4.
no
bgp client-to-client
reflection [all]
DETAILED STEPS
Disabling Intracluster Client-to-Client Reflection for Any Cluster ID
Perform the following task on a route reflector to disable intracluster client-to-client reflection for any cluster ID. Doing so is considered to be the middle of the three levels of commands available to disable client-to-client reflection. That is, it is more specific than disabling intracluster and intercluster client-to-client reflection, but it is not as specific as disabling intracluster client-to-client reflection for certain cluster IDs.
Before advertising updates, the software evaluates each level of configuration in order from least specific to most specific. Once any level of configuration disables client-to-client reflection, no further evaluation of more specific policies is needed.
Note | When the software changes reflection state for a given cluster ID, BGP sends an outbound soft refresh to all clients. |
1.
enable
2.
configure
terminal
3.
router
bgp
as-number
4.
no
bgp
client-to-client
reflection
intra-cluster
cluster-id
any
DETAILED STEPS
Disabling Intracluster Client-to-Client Reflection for Specified Cluster IDs
Perform the following task on a route reflector to disable intracluster client-to-client reflection for specified cluster IDs. Doing so is considered to be the most specific of the three levels of commands available to disable client-to-client reflection. Before advertising updates, the software evaluates each level of configuration in order from least specific to most specific. Once any level of configuration disables client-to-client reflection, no further evaluation of more specific policies is needed.
Note | When the software changes reflection state for a given cluster ID, BGP sends an outbound soft refresh to all clients. |
1.
enable
2.
configure
terminal
3.
router
bgp
as-number
4.
no
bgp
client-to-client
reflection
intra-cluster
cluster-id
cluster-id1 [cluster-id2...]
DETAILED STEPS
Configuration Examples for BGP-Multiple Cluster IDs
Example: Per-Neighbor Cluster ID
The following example is configured on a route reflector. The neighbor (client) at IPv6 address 2001:DB8:1::1 is configured to have the cluster ID of 0.0.0.6:
router bgp 6500 neighbor 2001:DB8:1::1 cluster-id 0.0.0.6
Example: Disabling Client-to-Client Reflection
The following example disables all intracluster and intercluster client-to-client reflection:
router bgp 65000 no bgp client-to-client reflection all
The following example disables intracluster client-to-client reflection for any cluster ID:
router bgp 65000 no bgp client-to-client reflection intra-cluster cluster-id any
The following example disables intracluster client-to-client reflection for the specified cluster IDs 0.0.0.1, 14, 15, and 0.0.0.6:
router bgp 65000 no bgp client-to-client reflection intra-cluster cluster-id 0.0.0.1 14 15 0.0.0.6
Remember that a cluster ID specified in the neighbor cluster-id command in decimal format (such as 23) will appear in a configuration file in dotted decimal format (such as 0.0.0.23). The decimal format does not appear in the configuration file. The running configuration might look like this:
router bgp 65000 no bgp client-to-client reflection intra-cluster cluster-id 0.0.0.1 no bgp client-to-client reflection intra-cluster cluster-id 0.0.0.6 no bgp client-to-client reflection intra-cluster cluster-id 0.0.0.14 no bgp client-to-client reflection intra-cluster cluster-id 0.0.0.15
Additional References
Related Documents
Related Topic |
Document Title |
---|---|
Cisco IOS commands |
|
BGP commands |
MIBs
MIB |
MIBs Link |
---|---|
None |
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL: |
Technical Assistance
Description |
Link |
---|---|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. |
Feature Information for BGP-Multiple Cluster IDs
The following table provides release information about the feature or features described in this module. This table 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.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.