Usage Guidelines

Use the bmp server command to enter BMP server configuration mode and configure a specific BMP server. To configure BGP BMP neighbors to which the BMP servers establish a connection, use the neighbor bmp-activate command in router configuration mode. Use the show ip bgp bmp command to verify whether the connection is established or not.

Usage Guidelines

The additional-paths command is part of a template; the syntax differs from the global bgp additional-paths command. The ability to send and receive additional paths is negotiated between two BGP neighbors during session establishment.

The no additional-paths command removes the policy from the current template. A peer applying this policy might still be subject to the address-family-wide bgp additional-paths command.

Use the show ip bgp neighbors command to display whether neighbors are capable of sending or receiving additional paths. Use the show ip bgp command with a network address to display the path selections and path IDs.

Usage Guidelines

Use the bmp server command to enter BMP server configuration mode and configure a specific BMP server. To configure BGP BMP neighbors to which the BMP servers establish a connection, use the neighbor bmp-activate command in router configuration mode. Use the show ip bgp bmp command to verify that IP address and port number have been configured.

Usage Guidelines

The address-family ipv4 command replaces the match nlri and set nlri commands. The address-family ipv4 command places the device in address family configuration mode (prompt: config-router-af), from which you can configure routing sessions that use standard IPv4 address prefixes. To leave address family configuration mode and return to router configuration mode, type exit .

Note	Routing information for address family IPv4 is advertised by default for each Border Gateway Protocol (BGP) routing session configured with the neighbor remote-as command unless you enter the no bgp default ipv4-unicast command before configuring the neighbor remote-as command.

The tunnel keyword is used to enable the tunnel subaddress family identifier (SAFI) under the IPv4 address family identifier. This SAFI is used to advertise the tunnel endpoints and the SAFI-specific attributes (which contain the tunnel type and tunnel capabilities). Redistribution of tunnel endpoints into the BGP IPv4 tunnel SAFI table occurs automatically when the tunnel address family is configured. However, peers need to be activated under the tunnel address family before the sessions can exchange tunnel information.

The mdt keyword is used to enable the MDT SAFI under the IPv4 address family identifier. This SAFI is used to advertise tunnel endpoints for inter-AS multicast VPN peering sessions.

If you specify the address-family ipv4 multicast command, you will then specify the network network-number [mask network-mask] command. The network command advertises (injects) the specified network number and mask into the multicast BGP database. This route must exist in the forwarding table installed by an Interior Gateway Protocol (IGP) (that is, by EIGRP, OSPF, RIP, IGRP, static, or IS-IS), but not BGP.

In Cisco IOS Release 12.2(33)SRB and later releases, the ability to use address family configuration under the router scope configuration mode was introduced. The scope hierarchy can be defined for BGP routing sessions and is required to support Multitopology Routing (MTR). To enter the router scope configuration mode, use the scope command, which can apply globally or for a specific VRF. When using the scope for a specific VRF, only the unicast keyword is available.

Usage Guidelines

The address-family l2vpn command places the router in address family configuration mode (prompt: config-router-af), from which you can configure routing sessions that support L2VPN endpoint provisioning.

BGP support for the L2VPN address family introduces a BGP-based autodiscovery mechanism to distribute L2VPN endpoint provisioning information. BGP uses a separate L2VPN routing information base (RIB) to store endpoint provisioning information, which is updated each time any Layer 2 (L2) virtual forwarding instance (VFI) is configured. Prefix and path information is stored in the L2VPN database, allowing BGP to make best-path decisions. When BGP distributes the endpoint provisioning information in an update message to all its BGP neighbors, the endpoint information is used to set up a pseudowire mesh to support L2VPN-based services.

The BGP autodiscovery mechanism facilitates the setting up of L2VPN services, which are an integral part of the Cisco IOS Virtual Private LAN Service (VPLS) feature. VPLS enables flexibility in deploying services by connecting geographically dispersed sites as a large LAN over high-speed Ethernet in a robust and scalable IP MPLS network.

The multiprotocol capability for address family L2VPN EVPN is advertised when the Address Family Identifier (AFI) is enabled under the internal BGP (iBGP) and external BGP (eBGP) neighbors for both IPv4 and IPv6 neighbors.

Note	Routing information for address family IPv4 is advertised by default for each BGP routing session configured with the neighbor remote-as command unless you configure the no bgp default ipv4-unicast command before configuring the neighbor remote-as command.

Usage Guidelines

The address-family mvpn command places the router in address family configuration mode (prompt: config-router-af), from which you can configure routing sessions that use MVPN address information. To leave address family configuration mode and return to router configuration mode, type exit .

Configure address-family ipv4 mvpn to enable IPv4 multicast customer-route (c-route) exchange.

Configure address-family ipv6 mvpn to enable IPv6 multicast c-route exchange.

Usage Guidelines

The address-family nsap command enters address family configuration mode (prompt: config-router-af )#, from which you can configure routing sessions that use standard NSAP address prefixes; you must enter NSAP address family configuration mode to configure BGP for CLNS prefixes.

To leave address family configuration mode and return to router configuration mode without removing the existing configuration, enter the exit-address-family command.

Usage Guidelines

Use this command when you are configuring the BGP: RT Constrained Route Distribution feature.

The address-family rtfilter unicast command is configured on the provider edge (PE) and route reflector (RR). The command enables the PE to send RTC Network Layer Reachability Information (NLRI) to an RR. As soon as you configure a peer as a RR client, the default filter and default route are sent out also.

Usage Guidelines

The address-family vpnv4 command replaces the match nlri and set nlri commands.

The address-family vpnv4 command places the router in address family configuration mode (prompt: config-router-af ), from which you can configure routing sessions that use VPN Version 4 address prefixes.

To leave address family configuration mode and return to router configuration mode without removing the existing configuration, enter the exit-address-family command.

Usage Guidelines

Use this command to specify for the peer policy template which additional paths are advertised. You can advertise additional paths based on any combination of the selection methods, but you must choose at least one selection method if you use this command.

Keep in mind that in order to advertise additional-paths, you also need to:

• Configure the additional-path send capability, and that send capability must be negotiated (other than best-path).

• Select paths (other than best-path) with the bgp additional-paths select command, which sets the tags.

Usage Guidelines

You can implement aggregate routing in BGP and Multiprotocol BGP (mBGP) either by redistributing an aggregate route into BGP or mBGP, or by using the conditional aggregate routing feature. In method of route aggregation, a route towards Null0 inserted into RIB automatically to help prevent forwarding loops caused by aggregation.

Using the aggregate-address command with no keywords will create an aggregate entry in the BGP or mBGP routing table if any more-specific BGP or mBGP routes are available that fall within the specified range. (A longer prefix that matches the aggregate must exist in the Routing Information Base (RIB).) The aggregate route will be advertised as coming from your autonomous system and will have the atomic aggregate attribute set to show that information might be missing. (By default, the atomic aggregate attribute is set unless you specify the as-set keyword.)

Using the as-set keyword creates an aggregate entry using the same rules that the command follows without this keyword, but the path advertised for this route will be an AS_SET consisting of all elements contained in all paths that are being summarized. Do not use this form of the aggregate-address command when aggregating many paths, because this route must be continually withdrawn and updated as autonomous system path reachability information for the summarized routes changes.

Using the as-confed-set keyword creates an aggregate entry using the same rules that the command follows without this keyword. This keyword performs the same function as the as-set keyword, except that it generates autonomous confed set path information.

Using the summary-only keyword not only creates the aggregate route (for example, 192.*.*.*) but also suppresses advertisements of more-specific routes to all neighbors. If you want to suppress only advertisements to certain neighbors, you may use the neighbor distribute-list command, with caution. If a more-specific route leaks out, all BGP or mBGP routers will prefer that route over the less-specific aggregate you are generating (using longest-match routing).

Using the suppress-map keyword creates the aggregate route but suppresses advertisement of specified routes. You can use the match clauses of route maps to selectively suppress some more-specific routes of the aggregate and leave others unsuppressed. IP access lists and autonomous system path access lists match clauses are supported.

Using the advertise-map keyword selects specific routes that will be used to build different components of the aggregate route, such as AS_SET or community. This form of the aggregate-address command is useful when the components of an aggregate are in separate autonomous systems and you want to create an aggregate with AS_SET, and advertise it back to some of the same autonomous systems. You must remember to omit the specific autonomous system numbers from the AS_SET to prevent the aggregate from being dropped by the BGP loop detection mechanism at the receiving router. IP access lists and autonomous system path access lists match clauses are supported.

Using the attribute-map keyword allows attributes of the aggregate route to be changed. This form of the aggregate-address command is useful when one of the routes forming the AS_SET is configured with an attribute such as the community no-export attribute, which would prevent the aggregate route from being exported. An attribute map route map can be created to change the aggregate attributes.

Usage Guidelines

Use the aigp command to enable sending and receiving of the AIGP attribute per neighbor.

Usage Guidelines

This command was introduced as part of the Multiprotocol Label Switching (MPLS)-based L2VPN command modifications for cross-OS support. This command will replace the l2 vfi autodiscovery command in future releases.

Layer 2 VFI autodiscovery enables each VPLS PE router to discover other PE routers that are part of the same VPLS domain. VPLS autodiscovery also automatically detects when PE routers are added to or removed from the VPLS domain

The bgp keyword specifies that BGP should be used for signaling and autodiscovery, accordance with RFC 4761.

The ldp keyword specifies that LDP should be used for signaling. BGP will be used for autodiscovery.

Use of the autodiscovery command places the device into L2VPN VFI autodiscovery configuration mode (config-vfi-autodiscovery).

Usage Guidelines

BGP automatically summarizes routes to classful network boundaries when this command is enabled. Route summarization is used to reduce the amount of routing information in routing tables. Automatic summarization applies to connected, static, and redistributed routes.

Note	The MPLS VPN Per VRF Label feature does not support auto-summary.

By default, automatic summarization is disabled and BGP accepts subnets redistributed from an Interior Gateway Protocol (IGP). To block subnets and create summary subprefixes to the classful network boundary when crossing classful network boundaries, use the auto-summary command.

To advertise and carry subnet routes in BGP when automatic summarization is enabled, use an explicit network command to advertise the subnet. The auto-summary command does not apply to routes injected into BGP via the network command or through iBGP or eBGP.

Why auto-summary for BGP Is Disabled By Default

When auto-summary is enabled, routes injected into BGP via redistribution are summarized on a classful boundary. Remember that a 32-bit IP address consists of a network address and a host address. The subnet mask determines the number of bits used for the network address and the number of bits used for the host address. The IP address classes have a natural or standard subnet mask, as shown in the table below.

Reserved addresses include 128.0.0.0, 191.255.0.0, 192.0.0.0, and 223.255.255.0.

When using the standard subnet mask, Class A addresses have one octet for the network, Class B addresses have two octets for the network, and Class C addresses have three octets for the network.

Consider the Class B address 156.26.32.1 with a 24-bit subnet mask, for example. The 24-bit subnet mask selects three octets, 156.26.32, for the network. The last octet is the host address. If the network 156.26.32.1/24 is learned via an IGP and is then redistributed into BGP, if auto-summary were enabled, the network would be automatically summarized to the natural mask for a Class B network. The network that BGP would advertise is 156.26.0.0/16. BGP would be advertising that it can reach the entire Class B address space from 156.26.0.0 to 156.26.255.255. If the only network that can be reached via the BGP router is 156.26.32.0/24, BGP would be advertising 254 networks that cannot be reached via this router. This is why the auto-summary (BGP) command is disabled by default.

Usage Guidelines

Using this command will enable the sending and receiving of additional path capability for an address family, after successful negotiation with a neighbor. The ability to send and receive additional paths is negotiated between two BGP neighbors during session establishment. The following address families are supported: IPv4 unicast, IPv4 multicast, IPv4 unicast + label, IPv6 unicast, IPpv6 multicast, and IPv6 multicast + label.

The bgp additional-paths command controls whether the local device can send or receive additional paths to and from all neighbors within an address family. If the neighbor additional-paths command is configured, its send and receive configurations for that neighbor or peer group override the configuration for the address family.

When the additional paths feature is used with IPv4+label or IPv6+label, only one label is allocated.

Use the show ip bgp neighbors command to display whether neighbors are capable of sending or receiving additional paths. Use the show ip bgp command with a network address to display the path selections, path IDs, and the capabilities for advertising and receiving additional paths.

When bgp additional-paths is configured, that configuration is applied to all neighbors in that address family.

• If you want to disable additional paths for the address family, use the no bgp additional-paths {send [receive] | receive} command.

• If you want to disable additional paths for one of the neighbors, use the neighbor additional-paths disable command.

Usage Guidelines

You can issue the bgp additional-paths install command in different modes, each of which protects VRFs in its own way:

• VPNv4 address family configuration mode protects all VRFs.

• IPv4 address family configuration mode protects only IPv4 VRFs.

• IPv6 address family configuration mode protects only IPv6 VRFs.

• Router configuration mode protects VRFs in the global routing table.

Usage Guidelines

This command configures part of the BGP Additional Paths feature. This feature allows you to calculate multiple paths for the same prefix without the new paths implicitly replacing any previous paths. Use this command to select which paths are candidates as additional paths to be advertised to BGP peers.

You can specify any combination of the keywords in the same instance of the bgp additional-paths select command; you must specify at least one keyword.

In order to enable the BGP Additional Paths feature and have a reason for selecting which paths will be advertised, you must have the additional path Send capability specified and it must be negotiated (other than best-path).

After you have selected which additional paths are candidates for advertisement, you typically use the neighbor advertise additional-paths command to advertise the additional paths to a specific neighbor. Alternatively, you could use the advertise additional-paths command under the template peer-policy command to advertise the additional paths to BGP peers in the peer policy template.

Note	The bgp additional-paths select backup and bgp additional-paths select best-external commands are for the diverse path feature, not the Additional Paths feature. If the diverse path feature is also configured, it will apply only to neighbors where additional path capability is not negotiated.

You can remove every selection option configured by issuing the no bgp additional-paths select command.

Note

The no bgp additional-paths select command will remove anything configured after the select keyword, which means that it will remove diverse path configurations: bgp additional-paths select backup and bgp additional-paths select best-external , and additional path configurations: bgp additional-paths select best number , bgp additional-paths select group-best , and bgp additional-paths select all .

Usage Guidelines

The BGP Diverse Path feature can be enabled on a route reflector to calculate a best path and an additional path per address family.

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. Either the best-external keyword or the backup keyword is required; both keywords can be specified. If both keywords (best-external and backup ) are specified, the system will install a backup path.

Note

The bgp additional-paths select backup and bgp additional-paths select best-external commands are for the Diverse Path feature, not the BGP Additional Paths feature. If the Diverse Path feature and the Additional Paths feature are configured, the Diverse Path feature will apply only to neighbors where additional path capability is not negotiated.

You can remove every selection option configured by issuing the no bgp additional-paths select command.

Note

The no bgp additional-paths select command will remove anything configured after the select keyword, which means that it will remove diverse path configurations: bgp additional-paths select backup and bgp additional-paths select best-external , and additional path configurations: bgp additional-paths select best number , bgp additional-paths select group-best , and bgp additional-paths select all .

Usage Guidelines

When you configure the Best External feature with the bgp advertise-best-external command, you need not enable the Prefix Independent Convergence (PIC) feature with the bgp additional-paths install command. The Best External feature automatically installs a backup path. If you try to configure the PIC feature after configuring the Best External feature, you receive an error. This behavior applies to both BGP and MPLS.

When you configure the MPLS VPN: Best External feature with the bgp advertise-best-external command, it will override the functionality of the MPLS VPN--BGP Local Convergence feature. You need not remove the protection local-prefixes command from the configuration.

You can issue the bgp advertise-best-external command in different modes, each of which protects VRFs in its own way:

• VPNv4 address-family configuration mode protects all VRFs.

• IPv4 address-family configuration mode protects only IPv4 VRFs.

• IPv6 address family configuration mode protects only IPv6 VRFs.

• Router configuration mode protects VRFs in the global routing table.

Usage Guidelines

Use this command to change the default interval at which BGP routes are aggregated.

In very large configurations, even if the aggregate-address summary-only command is configured, more specific routes are advertised and later withdrawn. To avoid this behavior, configure the bgp aggregate-timer to 0 (zero), and the system will immediately check for aggregate routes and suppress specific routes.

Usage Guidelines

The MED, as stated in RFC 1771, is an optional nontransitive attribute that is a four octet non-negative integer. The value of this attribute may be used by the BGP best path selection process to discriminate among multiple exit points to a neighboring autonomous system.

The MED is one of the parameters that is considered when selecting the best path among many alternative paths. The path with a lower MED is preferred over a path with a higher MED. During the best-path selection process, MED comparison is done only among paths from the same autonomous system. The bgp always-compare-med command is used to change this behavior by enforcing MED comparison between all paths, regardless of the autonomous system from which the paths are received.

The bgp deterministic-med command can be configured to enforce deterministic comparison of the MED value between all paths received from within the same autonomous system.

Usage Guidelines

Prior to January 2009, BGP autonomous system numbers that were allocated to companies were 2-octet numbers in the range from 1 to 65535 as described in RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Due to increased demand for autonomous system numbers, the Internet Assigned Number Authority (IANA) will start in January 2009 to allocate four-octet autonomous system numbers in the range from 65536 to 4294967295. RFC 5396, Textual Representation of Autonomous System (AS) Numbers , documents three methods of representing autonomous system numbers. Cisco has implemented the following two methods:

• Asplain--Decimal value notation where both 2-byte and 4-byte autonomous system numbers are represented by their decimal value. For example, 65526 is a 2-byte autonomous system number and 234567 is a 4-byte autonomous system number.

• Asdot--Autonomous system dot notation where 2-byte autonomous system numbers are represented by their decimal value and 4-byte autonomous system numbers are represented by a dot notation. For example, 65526 is a 2-byte autonomous system number and 1.169031 is a 4-byte autonomous system number (this is dot notation for the 234567 decimal number).

For details about the third method of representing autonomous system numbers, see RFC 5396.

In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain as the default display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain and asdot format. In addition, the default format for matching 4-byte autonomous system numbers in regular expressions is asplain, so you must ensure that any regular expressions to match 4-byte autonomous system numbers are written in the asplain format. If you want to change the default show command output to display 4-byte autonomous system numbers in the asdot format, use the bgp asnotation dot command under router configuration mode. When the asdot format is enabled as the default, any regular expressions to match 4-byte autonomous system numbers must be written using the asdot format, or the regular expression match will fail. The tables below show that although you can configure 4-byte autonomous system numbers in either asplain or asdot format, only one format is used to display show command output and control 4-byte autonomous system number matching for regular expressions, and the default is asplain format. To display 4-byte autonomous system numbers in show command output and to control matching for regular expressions in the asdot format, you must configure the bgp asnotation dot command. After enabling the bgp asnotation dot command, a hard reset must be initiated for all BGP sessions by entering the clear ip bgp * command.

Note

If you are upgrading to an image that supports 4-byte autonomous system numbers, you can still use 2-byte autonomous system numbers. The show command output and regular expression match are not changed and remain in asplain (decimal value) format for 2-byte autonomous system numbers regardless of the format configured for 4-byte autonomous system numbers.

Usage Guidelines

Use the bgp bestpath aigp ignore command to not evaluate the AIGP attribute during the best path selection process between two paths when one path does not have the AIGP attribute. When bgp bestpath aigp ignore is enabled, BGP does not use AIGP tie-breaking rules unless paths have the AIGP attribute.

Usage Guidelines

The bgp bestpath compare-routerid command is used to configure a BGP routing process to use the router ID as the tie breaker for best path selection when two identical routes are received from two different peers (all the attributes are the same except for the router ID). When this command is enabled, the lowest router ID will be selected as the best path when all other attributes are equal.

Usage Guidelines

The bgp bestpath cost-community ignore command is used to disable the evaluation of the cost community attribute to help isolate problems and troubleshoot issues that relate to BGP path selection. This command can also be used to delay the activation of cost community attribute evaluation so that cost community filtering can be deployed in a large network at the same time.

Usage Guidelines

The IGP metric is a configurable metric for EIGRP, IS-IS, or OSPF that is related to distance. The bgp bestpath igp-metric ignore command can be used independently or in conjunction with the BGP Diverse Path feature. This command does not enable the BGP Diverse Path feature.

Similarly, enabling the BGP Diverse Path feature does not necessarily require that the IGP metric be ignored. If you enable the BGP Diverse Path feature and the route reflector and its shadow route reflector are not colocated, this command must be configured on the route reflector, shadow route reflector, and provider edge (PE) routers.

This command is supported in the following address families:

• ipv4 unicast

• vpnv4 unicast

• ipv6 unicast

• vpnv6 unicast

• ipv4+label

• ipv6+label

Note	This command is not supported per virtual routing and forwarding (VRF); if you use it per VRF, it is at your own risk.

This command applies per VRF as follows (which is consistent with the BGP PIC/Best External feature):

• When configured under the VPNv4 or VPNv6 address-family, it applies to all VRFs, but it will be nvgened only under VPNv4/VPNv6 global.

• When configured under a particular VRF, it applies only to that VRF and will be nvgened only for that VRF.

• When configured under vpnv4 or vpnv6 global, this command can be disabled for a particular VRF by specifying the no bgp bestpath igp-metric ignore command. The no form will be nvgened under that VRF, while under VPNv4 or VPNv6 the bgp bestpath igp-metric ignore command is nvgened and the command applies to all other VRFs.

Usage Guidelines

The MED comparison between confederation peers occurs only if no external autonomous systems are in the path (an external autonomous system is an autonomous system that is not within the confederation). If an external autonomous system in the path, then the external MED is passed transparently through the confederation, and the comparison is does not occur.

For example, assume that autonomous system 65000, 65001, 65002, and 65004 are part of the confederation; autonomous system 1 is not; and we are comparing route A with four paths. If the bgp bestpath med confed command is enabled, path 1 would be chosen. The fourth path has a lower MED, but it is not involved in the MED comparison because there is an external autonomous system in this path. The following list displays the MED for each autonomous system.

path = 65000 65004, med = 2

path = 65001 65004, med = 3

path = 65002 65004, med = 4

path = 65003 1, med = 1

Usage Guidelines

This command is useful for configuration testing and for use with a route map.

The default behavior, if neither the bgp bestpath prefix-validate disable nor the bgp bestpath prefix-validate allow-invalid command is configured, is to prefer prefixes in the following order:

• Those with a validation state of valid

• Those with a validation state of not found

• Those with a validation state of invalid (which will never be installed in the routing table)

If both the bgp bestpath prefix-validate disable command and the bgp bestpath prefix-validate allow-invalid command are configured, the disable command will prevent a validation state from being assigned to prefixes, so the allow-invalid command will have no effect.

Usage Guidelines

This command affects route reflection of all routes, both intracluster and intercluster.

By default, the clients of a route reflector are not required to be fully meshed and the routes from a client are reflected to other clients. However, if the clients are fully meshed, route reflection is not required. In this case, use the no bgp client-to-client reflection command to disable client-to-client reflection.

Note that the bgp client-to-client reflection command affects intracluster and intercluster client-to-client reflection, unlike the bgp client-to-client reflection intra-cluster command, which affects only intracluster (within a cluster) client-to-client route reflection.

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:

1. Least specific: no bgp client-to-client reflection [all] Disables intracluster and intercluster client-to-client reflection.

2. More specific: no bgp client-to-client reflection intra-cluster cluster-id any Disables intracluster client-to-client reflection for any cluster-id.

3. 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.

Usage Guidelines

By default, the clients of a route reflector are not required to be fully meshed and the routes from a client are reflected to other clients. However, if the clients are fully meshed, route reflection is not required. In this case, use the no bgp client-to-client reflection intra-cluster command to disable client-to-client reflection; updates are not sent (reflected) because they are not necessary. Configure this command on a route reflector.

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:

1. Least specific: no bgp client-to-client reflection [all] Disables intracluster and intercluster client-to-client reflection.

2. More specific: no bgp client-to-client reflection intra-cluster cluster-id any Disables intracluster client-to-client reflection for any cluster-id.

3. 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.

Usage Guidelines

Together, a route reflector and its clients form a cluster . When a single route reflector is deployed in a cluster, the cluster is identified by the router ID of the route reflector.

The bgp cluster-id command is used to assign a cluster ID to a route reflector when the cluster has one or more route reflectors. Multiple route reflectors are deployed in a cluster to increase redundancy and avoid a single point of failure. When multiple route reflectors are configured in a cluster, the same cluster ID is assigned to all route reflectors. This allows all route reflectors in the cluster to recognize updates from peers in the same cluster and reduces the number of updates that need to be stored in BGP routing tables.

Note	All route reflectors must maintain stable sessions between all peers in the cluster. If stable sessions cannot be maintained, then overlay route reflector clusters should be used instead (route reflectors with different cluster IDs).

Usage Guidelines

The bgp confederation identifier command is used to configure a single autonomous system number to identify a group of smaller autonomous systems as a single confederation.

A confederation can be used to reduce the internal BGP (iBGP) mesh by dividing a large single autonomous system into multiple subautonomous systems and then grouping them into a single confederation. The subautonomous systems within the confederation exchange routing information like iBGP peers. External peers interact with the confederation as if it were a single autonomous system.

Each subautonomous system is fully meshed within itself and has a few connections to other autonomous systems within the confederation. Next hop, Multi Exit Discriminator (MED), and local preference information is preserved throughout the confederation, allowing you to retain a single Interior Gateway Protocol (IGP) for all the autonomous systems.

In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain--65538 for example--as the default regular expression match and output display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain format and the asdot format as described in RFC 5396. To change the default regular expression match and output display of 4-byte autonomous system numbers to asdot format, use the bgp asnotation dot command followed by the clear ip bgp * command to perform a hard reset of all current BGP sessions.

In Cisco IOS Release 12.0(32)S12, 12.4(24)T, and Cisco IOS XE Release 2.3, the Cisco implementation of 4-byte autonomous system numbers uses asdot--1.2 for example--as the only configuration format, regular expression match, and output display, with no asplain support.

If one member of a BGP confederation is identified using a 4-byte autonomous system number, all other members of a BGP confederation must be upgraded to support 4-byte autonomous system numbers.

Usage Guidelines

The bgp confederation peers command is used to configure multiple autonomous systems as a single confederation. The ellipsis (...) in the command syntax indicates that your command input can include multiple values for the autonomous-system-number argument.

The autonomous system number of the router on which this command is being specified is not allowed in this command (not allowed as a confederation peer). If you specify the local router’s autonomous system number in the bgp confederation peers command, the error message “Local member-AS not allowed in confed peer list” will appear.

The autonomous systems specified in this command are visible internally to the confederation. Each autonomous system is fully meshed within itself. Use the bgp confederation identifier command to specify the confederation to which the autonomous systems belong.

In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, Cisco IOS XE Release 2.4 , and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain--65538 for example--as the default regular expression match and output display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain format and the asdot format as described in RFC 5396. To change the default regular expression match and output display of 4-byte autonomous system numbers to asdot format, use the bgp asnotation dot command followed by the clear ip bgp * command to perform a hard reset of all current BGP sessions.

In Cisco IOS Release 12.0(32)S12, 12.4(24)T, and Cisco IOS XE Release 2.3, the Cisco implementation of 4-byte autonomous system numbers uses asdot--1.2 for example--as the only configuration format, regular expression match, and output display, with no asplain support.

If one member of a BGP confederation is identified using a 4-byte autonomous system number, all other members of a BGP confederation must be upgraded to support 4-byte autonomous system numbers.

Usage Guidelines

A BGP route inconsistency with a peer occurs when an update or a withdraw is not sent to a peer, and a routing absence can result. The BGP consistency checker feature is a low-priority process created to address this issue. This feature performs nexthop-label, RIB-out, and aggregation consistency checks. When BGP consistency checker is enabled, it is performed for all address families. Once the process identifies such an inconsistency:

• If the error-message keyword is specified, the system will report the inconsistency with a syslog message, and will also perform forceful aggregation reevaluation in the case of an aggregation inconsistency.

• If the auto-repair keyword is specified, the system will report the inconsistency with a syslog message and also take appropriate action, such as a route refresh request or an aggregation reevaluation, depending on the type of inconsistency.

Usage Guidelines

The bgp dampening command is used to enable BGP route dampening. This command can be entered without any arguments or keywords. The half-life , reuse , suppress , and max-suppress-time arguments are position-dependent; meaning that if any of these arguments are entered, then all optional arguments must be entered.

When BGP dampening is configured and a prefix is withdrawn, BGP considers the withdrawn prefix as a flap and increases the penalty by a 1000. If BGP receives an attribute change, BGP increases the penalty by 500. If then the prefix has been withdrawn, BGP keeps the prefix in the BGP table as a history entry. If the prefix has not been withdrawn by the neighbor and BGP is not using this prefix, the prefix is marked as dampened. Dampened prefixes are not used in the BGP decision process and not installed to the routing table.

Note	This command is not supported in the address family configuration mode in Cisco IOS Release 12.2SX and later releases.

Usage Guidelines

The bgp default ipv4-unicast command is used to enable the automatic exchange of IPv4 address family prefixes. The neighbor activate address family configuration command must be entered in each IPv4 address family session before prefix exchange will occur.

Usage Guidelines

The local preference attribute is a discretionary attribute that is used to apply the degree of preference to a route during the BGP best path selection process. This attribute is exchanged only between iBGP peers and is used to determine local policy. The route with the highest local preference is preferred.

Usage Guidelines

The bgp dmzlink-bw command is used to configure BGP to distribute traffic proportionally to the bandwidth of external links. This command is configured for multipath load balancing between directly connected external BGP (eBGP) neighbors. This command is used with BGP multipath features to configure load balancing over links with unequal bandwidth. The neighbor dmzlink-bw command must also be configured for each external link through which multipath load balancing is configured to advertise the link bandwidth as an extended community. The neighbor send-community command must be configured to exchange the link bandwidth extended community with internal BGP (iBGP) peers.

Usage Guidelines

The bgp enforce-first-as command is used to deny incoming updates received from eBGP peers that do not list their autonomous system number as the first segment in the AS_PATH attribute. Enabling this command prevents a misconfigured or unauthorized peer from misdirecting traffic (spoofing the local router) by advertising a route as if it was sourced from another autonomous system.

Usage Guidelines

This command controls the BGP Enhanced Attribute Error Handling feature, which is enabled by default. This feature avoids peer sessions flapping due to malformed Update messages. Such Update messages are treat-as-withdraw.

This feature causes BGP to format the MP_REACH attribute in front of other attributes in the Update message. That is necessary because if any of the attribute lengths are malformed, there is no way of reaching the MP_REACH attribute if it is put at the end, and therefore no way to withdraw the prefixes. If the feature is disabled, BGP will format the MP_REACH attribute at the end of the Update message.

Usage Guidelines

The bgp fast-external-fallover command is used to disable or enable fast external fallover for BGP peering sessions with directly connected external peers. The session is immediately reset if link goes down. Only directly connected peering sessions are supported.

If BGP fast external fallover is disabled, the BGP routing process will wait until the default hold timer expires (3 keepalives) to reset the peering session. BGP fast external fallover can also be configured on a per-interface basis using the ip bgp fast-external-fallover interface configuration command.