Cisco IOS IP Routing: BGP Command Reference

match as-path

To match a BGP autonomous system path access list, use the match as-path command in route-map configuration mode. To remove a path list entry, use the no form of this command.

match as-path path-list-number

no match as-path path-list-number

Syntax Description

Defaults

No path lists are defined.

Command Modes

Route-map configuration

Command History

Usage Guidelines

The values set by the match as-path and set weight commands override global values. For example, the weights assigned with the match as-path and set weight route-map configuration commands override the weight assigned using the neighbor weight command.

A route map can have several parts. Any route that does not match at least one match clause relating to a route-map command will be ignored; that is, the route will not be advertised for outbound route maps and will not be accepted for inbound route maps. If you want to modify only some data, you must configure a second route-map section with an explicit match specified.

Examples

The following example sets the autonomous system path to match BGP autonomous system path access list 20:

route-map IGP2BGP

 match as-path 20

Related Commands

match community

To match a Border Gateway Protocol (BGP) community, use the match community command in route-map configuration mode. To remove the match community command from the configuration file and restore the system to its default condition where the software removes the BGP community list entry, use the no form of this command.

match community {standard-list-number | expanded-list-number | community-list-name [exact]}

no match community {standard-list-number | expanded-list-number | community-list-name [exact]}

Syntax Description

Command Default

No community list is matched by the route map.

Command Modes

Route-map configuration

Command History

Usage Guidelines

A route map can have several parts. Any route that does not match at least one match command relating to a route-map command will be ignored; that is, the route will not be advertised for outbound route maps and will not be accepted for inbound route maps. If you want to modify only some data, you must configure a second route-map section with an explicit match specified.

Matching based on community list number is one of the types of match commands applicable to BGP.

Examples

The following example shows that the routes matching community list 1 will have the weight set to 100. Any route that has community 109 will have the weight set to 100.

Router(config)# ip community-list 1 permit 109

Router(config)# route-map set_weight

Router(config-route-map)#  match community 1

Router(config-route-map)# set weight 100

The following example shows that the routes matching community list 1 will have the weight set to 200. Any route that has community 109 alone will have the weight set to 200.

Router(config)# ip community-list 1 permit 109

Router(config)# route-map set_weight

Router(config-route-map)# match community 1 exact

Router(config-route-map)# set weight 200

In the following example, the routes that match community list LIST_NAME will have the weight set to 100. Any route that has community 101 alone will have the weight set to 100.

Router(config)# ip community-list LIST_NAME permit 101

Router(config)# route-map set_weight

Router(config-route-map)# match community LIST_NAME 

Router(config-route-map)# set weight 100

The following example shows that the routes that match expanded community list 500. Any route that has extended community 1 will have the weight set to 150.

Router(config)# ip community-list 500 permit [0-9]*

Router(config)# route-map MAP_NAME permit 10

Router(config-route-map)# match extcommunity 500

Router(config-route-map)# set weight 150

Related Commands

match extcommunity

To match Border Gateway Protocol (BGP) or Enhanced Interior Gateway Routing Protocol (EIGRP) extended community list attributes, use the match extcommunity command in route-map configuration mode. To remove the match extcommunity command from the configuration file and remove the BGP or EIGRP extended community list attribute entry, use the no form of this command.

match extcommunity extended-community-list-name

no match extcommunity extended-community-list-name

Syntax Description

Command Default

BGP and EIGRP extended community list attributes are not matched.

Command Modes

Route-map configuration (config-route-map)

Command History

Usage Guidelines

Extended community attributes are used to configure, filter, and identify routes for virtual routing and forwarding instances (VRFs) and Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs).

The match extcommunity command is used to configure match clauses that use extended community attributes in route maps. All of the standard rules of match and set clauses apply to the configuration of extended community attributes.

Examples

The following example shows that the routes that match extended community list 500 will have the weight set to 100. Any route that has extended community 1 will have the weight set to 100.

Router(config)# ip extcommunity-list 500 rt 100:2

Router(config-extcomm-list)# exit

Router(config)# route-map MAP_NAME permit 10

Router(config-route-map)# match extcommunity 1

Router(config-route-map)# set weight 100

Related Commands

match local-preference

To configure a route map to match routes based on the Border Gateway Protocol (BGP) local-preference attribute, use the match local-preference command in route-map configuration mode. To remove the match clause entry from the route map, use the no form of this command.

match local-preference value

no match local-preference value

Syntax Description

Command Default

Cisco IOS software uses a default value of 100 for the local-preference attribute. However, a local-preference value must be entered when configuring a match clause with this command.

Command Modes

Route-map configuration

Command History

Usage Guidelines

The match local-preference command is used to filter routes based on the value of the local preference attribute. The local-preference attribute is a well-known discretionary attribute that is used to set the preference for an exit point within an autonomous system. The route with the highest local-preference value is preferred by the BGP best path selection process.

Redistributing OER Injected Routes

Optimized Edge Routing (OER) uses a local-preference value of 5000 (default) to move traffic to the preferred exit point in a BGP network (This value can be configured on the OER master controller). The match local-preference command can be used to redistribute OER injected routes within an autonomous system that is monitored and controlled by OER.

Examples

The following example configures the route-map name RED to match OER injected routes:

Router(config)# route-map RED permit 10 

Router(config-route-map)# match local-preference 5000 

Related Commands

match policy-list

To configure a route map to evaluate and process a Border Gateway Protocol (BGP) policy list in a route map, use the match policy-list command in route-map configuration mode. To remove a path list entry, use the no form of this command.

match policy-list policy-list-name

no match policy-list policy-list-name

Syntax Description

Defaults

This command is not enabled by default.

Command Modes

Route-map configuration

Command History

Usage Guidelines

When a policy list is referenced within a route map, all the match statements within the policy list are evaluated and processed.

Two or more policy lists can be configured with a route map. Policy lists can be configured within a route map to be evaluated with AND semantics or OR semantics.

Policy lists can also coexist with any other preexisting match and set statements that are configured within the same route map but outside of the policy lists.

When multiple policy lists perform matching within a route map entry, all policy lists match on the incoming attribute only.

Examples

The following configuration example creates a route map that references policy lists and separate match and set clauses in the same configuration:

Router(config)# route-map MAP-NAME-1 10

Router(config-route-map)# match ip-address 1

Router(config-route-map)# match policy-list POLICY-LIST-NAME-1 

Router(config-route-map)# set community 10:1

Router(config-route-map)# set local-preference 140

Router(config-route-map)# end

The following configuration example creates a route map that references policy lists and separate match and set clauses in the same configuration. This example processes the policy lists named POLICY-LIST-NAME-2 and POLICY-LIST-NAME-3 with OR semantics. A match is required from only one of the policy lists.

Router(config)# route-map MAP-NAME-2 10

Router(config-route-map)# match policy-list POLICY-LIST-NAME-2 POLICY-LIST-NAME-3

Router(config-route-map)# set community 10:1

Router(config-route-map)# set local-preference 140

Router(config-route-map)# end

Related Commands

match source-protocol

To match Enhanced Interior Gateway Routing Protocol (EIGRP) external routes based on a source protocol and autonomous system number, use the match source-protocol command in route-map configuration mode. To remove the protocol to be matched, use the no form of this command.

match source-protocol source-protocol [autonomous-system-number]

no match source-protocol source-protocol [autonomous-system-number]

Syntax Description

Command Default

EIGRP external routes are not matched on a source protocol and autonomous system number.

Command Modes

Route-map configuration (config-route-map)

Command History

Usage Guidelines

This command may not be useful with a redistribution operation that employs route maps because redistribution usually requires the configuration of a source protocol and an autonomous system value in order to redistribute. In many cases, it is more useful to configure a route map that includes matching the route type based on the source protocol and autonomous system using the distribute-list command for EIGRP.

Examples

The following example shows how to configure a route map to match a source protocol of BGP and an autonomous system 45000. When the match clause is true, the tag value of the destination routing protocol is set to 5. The route map is used to distribute incoming packets for an EIGRP process.

route-map metric_source

 match source-protocol bgp 45000

 set tag 5

!

router eigrp 1

 network 172.16.0.0

 distribute-list route-map metric_source in

The following example shows how to configure a route map to match a source protocol of BGP and a 4-byte autonomous system of 65538 in asplain format. When the match clause is true, the tag value of the destination routing protocol is set to 5. The route map is used to distribute incoming packets for an EIGRP process. This example requires 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, or a later release.

route-map metric_source

 match source-protocol bgp 65538

 set tag 5

!

router eigrp 1

 network 172.16.0.0

 distribute-list route-map metric_source in

The following example shows how to configure a route map to match a source protocol of BGP and a 4-byte autonomous system of 1.2 in asdot format. When the match clause is true, the tag value of the destination routing protocol is set to 5. The route map is used to distribute incoming packets for an EIGRP process. This example requires Cisco IOS Release 12.0(32)S12, 12.4(24)T, or Cisco IOS XE Release 2.3 where asdot notation is the only format for 4-byte autonomous system numbers. This configuration can also be performed using 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, or a later release.

route-map metric_source

 match source-protocol bgp 1.2

 set tag 5

!

router eigrp 1

 network 172.16.0.0

 distribute-list route-map metric_source in

Related Commands

maximum-paths eibgp

To configure multipath load sharing for external Border Gateway Protocol (eBGP) and internal BGP (iBGP) routes, use the maximum-paths eibgp command in address family configuration mode. To disable multipath load sharing for eBGP and iBGP routes, use the no form of this command.

maximum-paths eibgp number-of-paths [import number-of-import-paths]

no maximum-paths eibgp number-of-paths [import number-of-import-paths]

Syntax Description

Command Default

BGP, by default, will install only one best path in the routing table.

Command Modes

Address family configuration (config-router-af)

Command History

Usage Guidelines

The maximum-paths eibgp command is used to configure BGP multipath load sharing in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) using eBGP and iBGP routes. This command is configured under a VRF in address family configuration mode. The number of multipaths is configured separately for each VRF.

The number of paths that can be configured is determined by the version of Cisco IOS software as shown in the following list:

•Cisco IOS Release 12.0S-based software: 8 paths

•Cisco IOS Release 12.3T, 12.4, 12.4T, and 15.0-based software: 16 paths

•Cisco IOS Release 12.2S-based software: 32 paths

The maximum-paths eibgp command cannot be configured with the maximum-paths or maximum-paths ibgp command because the maximum-paths eibgp command is a superset of these commands.

Note The configuration of this command does not override the existing outbound routing policy.

Configuring VRF Import Paths

A VRF will import only one path (best path) per prefix from the source VRF table, unless the prefix is exported with a different route target. If the best path goes down, the destination will not be reachable until the next import event occurs, and then a new best path will be imported into the VRF table. The import event runs every 15 seconds by default.

The import keyword allows the network operator to configure the VRF table to accept multiple redundant paths in addition to the best path. An import path is a redundant path, and it can have a next hop that matches an installed multipath. This keyword should be used when multiple paths with identical next hops are available to ensure optimal convergence times. A typical application of this keyword is to configure redundant paths in a network that has multiple route reflectors for redundancy.

The maximum number of import paths that can be configured in Cisco IOS Release 12.2SY-based software is 16.

Note Configuring redundant paths with the import keyword can increase CPU and memory utilization significantly, especially in a network where there are many prefixes to learn and a large number of configured VRFs. It is recommended that this keyword be configured only as necessary and that the minimum number of redundant paths be configured (typically, not more than two).

In Cisco IOS Releases 15.0(1)M and 12.2(33)SRE, and in later releases, the import keyword was replaced by the import path selection and import path limit commands. If the import keyword is configured, the configuration is converted to the new commands, as show in the following example:

Router(config-router-af)# maximum-paths eibgp import 3 

%NOTE: Import option has been deprecated.

%      Converting to 'import path selection all; import path limit 3'.

Examples

In the following example, the router is configured to install six eBGP or iBGP routes into the VRF routing table:

Router(config)# router bgp 40000 

Router(config-router)# address-family ipv4 vrf vrf-1 

Router(config-router-af)# maximum-paths eibgp 6 

In the following example, the router is configured to install four equal-cost routes and two import routes (backup) in the VRF routing table:

Router(config)# router bgp 45000 

Router(config-router)# address-family ipv4 vrf vrf-2 

Router(config-router-af)# maximum-paths eibgp 4 import 2 

In the following example, the router is configured to install two import routes in the VRF routing table:

Router(config)# router bgp 50000

Router(config-router)# address-family ipv4 vrf vrf-3 

Router(config-router-af)# maximum-paths eibgp import 2 

Note Separate VRFs must be configured with different route distinguishers to support separate multipath configurations.

Related Commands

maximum-paths ibgp

To control the maximum number of parallel internal Border Gateway Protocol (iBGP) routes that can be installed in a routing table, use the maximum-paths ibgp command in router or address family configuration mode. To restore the default value, use the no form of this command.

Router Configuration Mode

maximum-paths ibgp number-of-paths

no maximum-paths ibgp number-of-paths

Under VRF in Address Family Configuration Mode

maximum-paths ibgp {number-of-paths [import number-of-import-paths] | unequal-cost number-of-import-paths}

no maximum-paths ibgp {number-of-paths [import number-of-import-paths] | unequal-cost number-of-import-paths}

Syntax Description

Command Default

BGP, by default, will install only one best path in the routing table.

Command Modes

Address family configuration (config-router-af)
Router configuration (config-router)

Command History

Usage Guidelines

The maximum-paths ibgp command is used to configure equal-cost or unequal-cost multipath load sharing for iBGP peering sessions. In order for a route to be installed as a multipath in the BGP routing table, the route cannot have a next hop that is the same as another route that is already installed. The BGP routing process will still advertise a best path to iBGP peers when iBGP multipath load sharing is configured. For equal-cost routes, the path from the neighbor with the lowest router ID is advertised as the best path.

To configure BGP equal-cost multipath load sharing, all path attributes must be the same. The path attributes include weight, local preference, autonomous system path (entire attribute and not just the length), origin code, Multi Exit Discriminator (MED), and Interior Gateway Protocol (IGP) distance.

The number of paths that can be configured is determined by the version of Cisco IOS software as shown in the following list:

•Cisco IOS Release 12.0S-based software: 8 paths

•Cisco IOS Release 12.3T, 12.4, 12.4T, and 15.0-based software: 16 paths

•Cisco IOS Release 12.2S-based software: 32 paths

Note In IPv6, the maximum-paths ibgp command does not work for prefixes learned from iBGP neighbors that have been configured to distribute a Multiprotocol Label Switching (MPLS) label with its IPv6 prefix advertisements. If multiple routes exist for such prefixes, all of them are inserted into the Routing Information Base (RIB) when the maximum-paths ibgp command is configured, but only one is used and no load balancing occurs between equal-cost paths. The maximum-paths ibgp command works with 6PE only in Cisco IOS Release 12.2(25)S and subsequent 12.2S releases.

Configuring VRF Import Paths

A VRF will import only one path (the best path) per prefix from the source VRF table, unless the prefix is exported with a different route target. If the best path goes down, the destination will not be reachable until the next import event occurs, and then a new best path will be imported into the VRF table. The import event runs every 15 seconds by default.

The import keyword allows the network operator to configure the VRF table to accept multiple redundant paths in addition to the best path. An import path is a redundant path, and it can have a next hop that matches an installed multipath. This keyword should be used when multiple paths with identical next hops are available to ensure optimal convergence times. A typical application of this keyword is to configure redundant paths in a network that has multiple route reflectors for redundancy.

The maximum number of import paths that can be configured in Cisco IOS Release 12.2SY-based software is 16.

Note Configuring redundant paths with the import keyword can increase CPU and memory utilization significantly, especially in a network where there are many prefixes to learn and a large number of configured VRFs. It is recommended that this keyword be configured only as necessary and that the minimum number of redundant paths be configured (typically, not more than two).

In Cisco IOS Releases 15.0(1)M and 12.2(33)SRE, and in later releases, the import keyword was replaced by the import path selection and import path limit commands. If the import keyword is configured, the configuration is converted to the new commands, as show in the following example:

Router(config-router-af)# maximum-paths ibgp import 3 

%NOTE: Import option has been deprecated.

%      Converting to 'import path selection all; import path limit 3'.

Examples

The following example configuration installs three parallel iBGP paths in a non-MPLS topology:

Router(config)# router bgp 100 

Router(config-router)# maximum-paths ibgp 3 

The following example configuration installs three parallel iBGP paths in an MPLS Virtual Private Network (VPN) topology:

Router(config)# router bgp 100 

Router(config-router)# address-family ipv4 unicast vrf vrf-A 

Router(config-route-af)# maximum-paths ibgp 3 

The following example configuration installs two parallel routes in the VRF table:

Router(config)# router bgp 100 

Router(config-router)# address-family ipv4 vrf vrf-B 

Router(config-router-af)# maximum-paths ibgp 2 import 2 

Router(config-router-af)# end 

The following example configuration installs two parallel routes in the VRF table:

Router(config)# router bgp 100 

Router(config-router)# address-family ipv4 vrf vrf-C 

Router(config-router-af)# maximum-paths ibgp import 2 

Router(config-router-af)# end 

Related Commands

neighbor activate

To enable the exchange of information with a Border Gateway Protocol (BGP) neighbor, use the neighbor activate command in address family configuration mode or router configuration mode. To disable the exchange of an address with a BGP neighbor, use the no form of this command.

neighbor {ip-address | peer-group-name | ipv6-address%} activate

no neighbor {ip-address | peer-group-name | ipv6-address%} activate

Syntax Description

Command Default

The exchange of addresses with BGP neighbors is enabled for the IPv4 address family. Enabling address exchange for all other address families is disabled.

Note Address exchange for address family IPv4 is enabled by default for each BGP routing session configured with the neighbor remote-as command unless you configure the no bgp default ipv4-activate command before configuring the neighbor remote-as command, or you disable address exchange for address family IPv4 with a specific neighbor by using the no form of the neighbor activate command.

Command Modes

Address family configuration
Router configuration

Command History

Usage Guidelines

Use this command to advertise address information in the form of an IP or IPv6 prefix. The address prefix information is known as Network Layer Reachability Information (NLRI) in BGP.

The % keyword is used whenever link-local IPv6 addresses are used outside the context of their interfaces. This keyword does not need to be used for non-link-local IPv6 addresses.

Examples

Address Exchange Example for Address Family vpn4

The following example shows how to enable address exchange for address family vpnv4 for all neighbors in the BGP peer group named PEPEER and for the neighbor 10.0.0.44:

Router(config)# address-family vpnv4

Router(config-router-af)# neighbor PEPEER activate

Router(config-router-af)# neighbor 10.0.0.44 activate

Router(config-router-af)# exit-address-family

Address Exchange Example for Address Family IPv4 Unicast

The following example shows how to enable address exchange for address family IPv4 unicast for all neighbors in the BGP peer group named group1 and for the BGP neighbor 172.16.1.1:

Router(config)# address-family ipv4 unicast

Router(config-router-af)# neighbor group1 activate

Router(config-router-af)# neighbor 172.16.1.1 activate

Address Exchange Example for Address Family IPv6

The following example shows how to enable address exchange for address family IPv6 for all neighbors in the BGP peer group named group2 and for the BGP neighbor 7000::2:

Router(config)# address-family ipv6

Router(config-router-af)# neighbor group2 activate

Router(config-router-af)# neighbor 7000::2 activate

Related Commands

neighbor advertise best-external

To have a neighbor receive the advertisement of the best external path, use the neighbor advertise best-external command in address family configuration mode. To remove the designation, use the no form of the command.

neighbor {ip-address | ipv6-address | peer-group-name | policy-template-name} advertise best-external

no neighbor {ip-address | ipv6-address | peer-group-name | policy-template-name} advertise best-external

Syntax Description

Command Default

This command is disabled by default; the BGP bestpath is advertised to neighbors.

Command Modes

Address family configuration (config-router-af)

Command History

Usage Guidelines

By default, the BGP bestpath is advertised to a peer. However, if the BGP Diverse Path feature is configured, you can use this command to specify that the best external path is advertised to the peer also.

This command does not enable the BGP Best External feature or the BGP Diverse Path feature. The bgp additional-paths select best-external command must be configured before the neighbor advertise best-external command can be configured. If the neighbor advertise best-external command is configured, but the bgp additional-paths select best-external command is not configured, an error message is generated.

This command can be configured for non-client iBGP peers only. It can be configured at the PE, ASBR, or RR. When it is configured at an RR, the best-external functionality is inter-cluster, best-external functionality.

When the neighbor advertise best-external command is configured:

•At the PE:

–If the new style command (bgp additional-paths select best-external) is used to calculate the best external path, the best external path is advertised.

–If the old style command (bgp advertise-best-external) command is already present, the neighbor advertise best-external command cannot be configured and an error message is generated.

•At the RR:

–The RR advertises the best internal path to non-client iBGP peers only when the overall best path is a path learned from another cluster.

This command cannot be configured on an RR toward its clients; it can be configured only for non-client RRs.

Examples

In the following example, the neighbor at 10.1.1.1 is configured to receive the advertisement of the best-external path:

router bgp 1

 neighbor 10.1.1.1 remote-as 1

 address-family ipv4 unicast

 neighbor 10.1.1.1 activate

 maximum-paths ibgp 4

 bgp bestpath igp-metric ignore

 bgp additional-paths select best-external

 bgp additional-paths install

 neighbor 10.1.1.1 advertise best-external

Related Commands

neighbor advertise diverse-path

To specify that an additional path (a backup path or multipath or both) is advertised to a peer in addition to the bestpath, use the neighbor advertise diverse-path command in address family configuration mode. To remove the designation, use the no form of the command.

neighbor {ip-address | ipv6-address | peer-group-name | policy-template-name} advertise diverse-path {backup [mpath] | mpath}

no neighbor {ip-address | ipv6-address | peer-group-name | policy-template-name} advertise diverse-path {backup [mpath] | mpath}

Syntax Description

Command Default

This command is disabled by default; the BGP bestpath is advertised to neighbors.

Command Modes

Address family configuration (config-router-af)

Command History

Usage Guidelines

By default, the BGP bestpath is advertised to a peer. However, if the BGP Diverse Path feature is configured, you can use this command to specify that the backup path or multipath (or both) is advertised to the peer also. This command is not supported for VRFs.

This command does not enable the BGP Diverse Path feature. If this command is configured, but the BGP Diverse Path feature is not configured (by one of the commands in the Related Commands table), a warning message is generated.

If any of the Related Commands is configured, but there is no multipath or backup path (no additional path), then the specified neighbor will receive the bestpath in advertisements.

Neighbors for which this command is not specified will receive the bestpath in advertisements.

This command can be configured for route reflector clients only (because the BGP Diverse Path feature applies within an AS and within a single cluster).

If the bgp additional-paths select backup command was configured and is subsequently removed from the configuration before the neighbor advertise diverse-path backup command is removed, then the specified neighbor will receive the bestpath in advertisements.

Note If the old style command for BGP PIC or Best External is already configured (bgp additional-paths install or bgp advertise-best-external), the neighbor advertise diverse-path command cannot be configured; an error message is generated.

Either the backup keyword or the mpath keyword is required; both keywords can be specified.

Examples

In the following example, the neighbor at 10.1.1.1 will receive an advertisement for a backup path in addition to the bestpath:

router bgp 1

 neighbor 10.1.1.1 remote-as 1

 address-family ipv4 unicast

 neighbor 10.1.1.1 activate

 maximum-paths ibgp 4

 bgp bestpath igp-metric ignore

 bgp additional-paths select backup

 bgp additional-paths install

 neighbor 10.1.1.1 advertise diverse-path backup

Related Commands

neighbor advertise-map

To install a Border Gateway Protocol (BGP) route as a locally originated route in the BGP routing table for conditional advertisement, use the neighbor advertise-map command in router configuration mode. To disable conditional advertisement, use the no form of this command.

neighbor ip-address advertise-map map-name {exist-map map-name | non-exist-map map-name}

no neighbor ip-address advertise-map map-name {exist-map map-name | non-exist-map map-name}

Syntax Description

Defaults

No default behavior or values

Command Modes

Router configuration

Command History

Usage Guidelines

Use the neighbor advertise-map router configuration command to conditionally advertise selected routes. The routes or prefixes that will be conditionally advertised are defined in 2 route-maps, an advertise map and an exist map or nonexist map. The route map associated with the exist map or nonexist map specifies the prefix that the BGP speaker will track. The route map associated with the advertise-map specifies the prefix that will be advertised to the specified neighbor when the condition is met. When configuring an exist map, the condition is met when the prefix exists in both the advertise map and the exist map. When configuring a nonexist map, the condition is met when the prefix exists in the advertise map but does not exist in the nonexist map. If the condition is not met, the route is withdrawn and conditional advertisement does not occur. All routes that may be dynamically advertised or not advertised need to exist in the BGP routing table for conditional advertisement to occur.

Examples

The following router configuration example configures BGP to conditionally advertise a prefix to the 10.2.1.1 neighbor using an exist map. If the prefix exists in MAP1 and MAP2, the condition is met and the prefix is advertised.

router bgp 5

 neighbor 10.2.1.1 advertise-map MAP1 exist-map MAP2

The following address family configuration example configures BGP to conditionally advertise a prefix to the 10.1.1.1 neighbor using a nonexist map. If the prefix exists in MAP3 but not MAP4, the condition is met and the prefix is advertised.

router bgp 5

 address-family ipv4 multicast

 neighbor 10.1.1.1 advertise-map MAP3 non-exist-map MAP4

Related Commands

neighbor advertisement-interval

To set the minimum route advertisement interval (MRAI) between the sending of BGP routing updates, use the neighbor advertisement-interval command in address family or router configuration mode. To restore the default value, use the no form of this command.

neighbor {ip-address | peer-group-name} advertisement-interval seconds

no neighbor {ip-address | peer-group-name} advertisement-interval seconds

Syntax Description

Defaults

eBGP sessions not in a VRF: 30 seconds
eBGP sessions in a VRF: 0 seconds
iBGP sessions: 0 seconds

Command Modes

Router configuration

Command History

Usage Guidelines

When the MRAI is equal to 0 seconds, BGP routing updates are sent as soon as the BGP routing table changes.

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command.

Examples

The following router configuration mode example sets the minimum time between sending BGP routing updates to 10 seconds:

router bgp 5

 neighbor 10.4.4.4 advertisement-interval 10

The following address family configuration mode example sets the minimum time between sending BGP routing updates to 10 seconds:

router bgp 5

address-family ipv4 unicast

 neighbor 10.4.4.4 advertisement-interval 10

Related Commands

neighbor capability orf prefix-list

To advertise outbound route filter (ORF) capabilities to a peer router, use the neighbor capability orf prefix-list command in address family or router configuration mode. To disable ORF capabilities, use the no form of this command.

neighbor ip-address capability orf prefix-list [receive | send | both]

no neighbor ip-address capability orf prefix-list [receive | send | both]

Syntax Description

Command Default

No ORF capabilities are advertised to a peer router.

Command Modes

Address family

Command History

Usage Guidelines

The neighbor capability orf prefix-list command is used to reduce the number of BGP prefixes that a BGP speaker sends or receives from a peer router based on prefix filtering.

In most configurations, this command will be used to advertise both send and receive ORF capabilities with the both keyword. However, this feature can be configured in one direction between two routers with one router configured to send ORF capabilities and another router configured to receive ORF capabilities from the first router.

Examples

The following examples configure routers to advertise ORF send or receive capabilities to BGP 
neighbors.

Router-A Configuration (Sender)

The following example creates an outbound route filter and configures Router-A (10.1.1.1) to advertise the filter to Router-B (172.16.1.2). An IP prefix list named FILTER is created to specify the 192.168.1.0/24 subnet for outbound route filtering. The ORF send capability is configured on Router-A so that Router-A can advertise the outbound route filter to Router-B.

ip prefix-list FILTER seq 10 permit 192.168.1.0/24 

!

router bgp 100

 address-family ipv4 unicast 

 neighbor 172.16.1.2 remote-as 200

 neighbor 172.16.1.2 ebgp-multihop 

 neighbor 172.16.1.2 capability orf prefix-list send

 neighbor 172.16.1.2 prefix-list FILTER in

 exit 

Router-B Configuration (Receiver)

The following example configures Router-B to advertise the ORF receive capability to Router-A. Router-B will install the outbound route filter, defined in the FILTER prefix list, after ORF capabilities have been exchanged. An inbound soft reset is initiated on Router-B at the end of this configuration to activate the outbound route filter.

router bgp 200

 address-family ipv4 unicast 

 neighbor 10.1.1.1 remote-as 100

 neighbor 10.1.1.1 ebgp-multihop 255

 neighbor 10.1.1.1 capability orf prefix-list receive

 end 

clear ip bgp 10.1.1.1 in prefix-filter

Note The inbound soft refresh must be initiated with the clear ip bgp command in order for the BGP ORF feature to function.

Related Commands

neighbor default-originate

To allow a BGP speaker (the local router) to send the default route 0.0.0.0 to a neighbor for use as a default route, use the neighbor default-originate command in address family or router configuration mode. To send no route as a default, use the no form of this command.

neighbor {ip-address | peer-group-name} default-originate [route-map map-name]

no neighbor {ip-address | peer-group-name} default-originate [route-map map-name]

Syntax Description

Defaults

No default route is sent to the neighbor.

Command Modes

Address family
Router configuration

Command History

Usage Guidelines

This command does not require the presence of 0.0.0.0 in the local router. When used with a route map, the default route 0.0.0.0 is injected if the route map contains a match ip address clause and there is a route that matches the IP access list exactly. The route map can contain other match clauses also.

You can use standard or extended access lists with the neighbor default-originate command.

Examples

In the following router configuration example, the local router injects route 0.0.0.0 to the neighbor 172.16.2.3 unconditionally:

router bgp 109

 network 172.16.0.0

 neighbor 172.16.2.3 remote-as 200

 neighbor 172.16.2.3 default-originate

In the following example, the local router injects route 0.0.0.0 to the neighbor 172.16.2.3 only if there is a route to 192.168.68.0 (that is, if a route with any mask exists, such as 255.255.255.0 or 255.255.0.0):

router bgp 109

 network 172.16.0.0

 neighbor 172.16.2.3 remote-as 200

 neighbor 172.16.2.3 default-originate route-map default-map

!

route-map default-map 10 permit

 match ip address 1

!

access-list 1 permit 192.168.68.0

In the following example, the last line of the configuration has been changed to show the use of an extended access list. The local router injects route 0.0.0.0 to the neighbor 172.16.2.3 only if there is a route to 192.168.68.0 with a mask of 255.255.0.0:

router bgp 109

 network 172.16.0.0

 neighbor 172.16.2.3 remote-as 200

 neighbor 172.16.2.3 default-originate route-map default-map

!

route-map default-map 10 permit

 match ip address 100

!

access-list 100 permit ip host 192.168.68.0 host 255.255.0.0

Related Commands

neighbor description

To associate a description with a neighbor, use the neighbor description command in router configuration mode or address family configuration mode. To remove the description, use the no form of this command.

neighbor {ip-address | peer-group-name} description text

no neighbor {ip-address | peer-group-name} description [text]

Syntax Description

Command Default

There is no description of the neighbor.

Command Modes

Router configuration (config-router)
Address family configuration (config-router-af)

Command History

Examples

In the following examples, the description of the neighbor is "peer with example.com":

Router(config)# router bgp 109

Router(config-router)# network 172.16.0.0

Router(config-router)# neighbor 172.16.2.3 description peer with example.com

In the following example, the description of the address family neighbor is "address-family-peer":

Router(config)# router eigrp virtual-name

Router(config-router)# address-family ipv4 autonomous-system 4453

Router(config-router-af)# network 172.16.0.0

Router(config-router-af)# neighbor 172.16.2.3 description address-family-peer

Related Commands

neighbor disable-connected-check

To disable connection verification to establish an eBGP peering session with a single-hop peer that uses a loopback interface, use the neighbor disable-connected-check command in address family or router configuration mode. To enable connection verification for eBGP peering sessions, use the no form of this command.

neighbor {ip-address | peer-group-name} disable-connected-check

no neighbor {ip-address | peer-group-name} disable-connected-check

Syntax Description

Command Default

A BGP routing process will verify the connection of single-hop eBGP peering session (TTL=254) to determine if the eBGP peer is directly connected to the same network segment by default. If the peer is not directly connected to same network segment, connection verification will prevent the peering session from being established.

Command Modes

Address family
Router configuration

Command History

Usage Guidelines

The neighbor disable-connected-check command is used to disable the connection verification process for eBGP peering sessions that are reachable by a single hop but are configured on a loopback interface or otherwise configured with a non-directly connected IP address.

This command is required only when the neighbor ebgp-multihop command is configured with a TTL value of 1. The address of the single-hop eBGP peer must be reachable. The neighbor update-source command must be configured to allow the BGP routing process to use the loopback interface for the peering session.

Examples

In the following example, a single-hop eBGP peering session is configured between two BGP peers that are reachable on the same network segment through a local loopback interfaces on each router:

BGP Peer 1

Router(config)# interface loopback 1 

Router(config-if)# ip address 10.0.0.100 255.255.255 

Router(config-if)# exit 

Router(config)# router bgp 64512 

Router(config-router)# neighbor 192.168.0.200 remote-as 65534 

Router(config-router)# neighbor 192.168.0.200 ebgp-multihop 1 

Router(config-router)# neighbor 192.168.0.200 update-source loopback 2 

Router(config-router)# neighbor 192.168.0.200 disable-connected-check

Router(config-router)# end 

BGP Peer 2

Router(config)# interface loopback 2 

Router(config-if)# ip address 192.168.0.200 255.255.255 

Router(config-if)# exit 

Router(config)# router bgp 65534 

Router(config-router)# neighbor 10.0.0.100 remote-as 64512 

Router(config-router)# neighbor 10.0.0.100 ebgp-multihop 1 

Router(config-router)# neighbor 10.0.0.100 update-source loopback 1 

Router(config-router)# neighbor 10.0.0.100 disable-connected-check

Router(config-router)# end 

Related Commands

neighbor distribute-list

To distribute BGP neighbor information as specified in an access list, use the neighbor distribute-list command in address family or router configuration mode. To remove an entry, use the no form of this command.

neighbor {ip-address | peer-group-name} distribute-list {access-list-number | expanded-list-number | access-list-name| prefix-list-name} {in | out}

no neighbor {ip-address | peer-group-name} distribute-list {access-list-number | expanded-list-number | access-list-name| prefix-list-name} {in | out}

Syntax Description

Defaults

No BGP neighbor is specified.

Command Modes

Address family
Router configuration

Command History

Usage Guidelines

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command. Specifying the command for a neighbor overrides the inbound policy that is inherited from the peer group.

Using a distribute list is one of several ways to filter advertisements. Advertisements can also be filtered by using the following methods:

•Autonomous system path filters can be configured with the ip as-path access-list and neighbor filter-list commands.

•The access-list (IP standard) and access-list (IP extended) commands can be used to configure standard and extended access lists for the filtering of advertisement.

•The route-map (IP) command can be used to filter advertisements. Route maps may be configured with autonomous system filters, prefix filters, access lists and distribute lists.

Standard access lists may be used to filter routing updates. However, in the case of route filtering when using classless interdomain routing (CIDR), standard access lists do not provide the level of granularity that is necessary to configure advanced filtering of network addresses and masks. Extended access lists, configured with the access-list (IP extended) command, should be used to configure route filtering when using CIDR because extended access lists allow the network operator to use wild card bits to filter the relevant prefixes and masks. Wild card bits are similar to the bit masks that are used with normal access lists; prefix and mask bits that correspond to wild card bits that are set to 0 are used in the comparison of addresses or prefixes and wild card bits that are set to 1 are ignored during any comparisons. This function of extended access list configuration can also be used to filter addresses or prefixes based on the prefix length.

Note Do not apply both a neighbor distribute-list and a neighbor prefix-list command to a neighbor in any given direction (inbound or outbound). These two commands are mutually exclusive, and only one command (neighbor prefix-list or neighbor distribute-list) can be applied to each inbound or outbound direction.

Examples

The following router configuration mode example applies list 39 to incoming advertisements from neighbor172.16.4.1. List 39 permits the advertisement of network 10.109.0.0.

router bgp 109 

 network 10.108.0.0 

 neighbor 172.16.4.1 distribute-list 39 in 

The following three examples show different scenarios for using an extended access list with a distribute list. The three examples are labeled "Example A", "Example B", and "Example C." Each of the example extended access list configurations are used with the neighbor distribute-list command configuration example below.

router bgp 109 

 network 10.108.0.0

 neighbor 172.16.4.1 distribute-list 101 in 

Example A

The following extended access list example will permit route 192.168.0.0 255.255.0.0 but deny any more specific routes of 192.168.0.0 (including 192.168.0.0 255.255.255.0):

access-list 101 permit ip 192.168.0.0 0.0.0.0 255.255.0.0 0.0.0.0 

access-list 101 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 

Example B

The following extended access list example will permit route 10.108.0/24 but deny 10.108/16 and all other subnets of 10.108.0.0:

access-list 101 permit ip 10.108.0.0 0.0.0.0 255.255.255.0 0.0.0.0

access-list 101 deny ip 10.108.0.0 0.0.255.255 255.255.0.0 0.0.255.255 

Example C

The following extended access list example will deny all prefixes that are longer than 24 bits and permit all of the shorter prefixes:

access-list 101 deny ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.255 

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 

Related Commands

neighbor dmzlink-bw

To configure Border Gateway Protocol (BGP) to advertise the bandwidth of links that are used to exit an autonomous system, use the neighbor dmzlink-bw command in address family configuration mode. To disable the link bandwidth advertisement, use the no form of this command.

neighbor ip-address dmzlink-bw

no neighbor ip-address dmzlink-bw

Syntax Description

Command Default

This command is disabled by default.

Command Modes

Address family configuration

Command History

Usage Guidelines

The neighbor dmzlink-bw command is used to configure BGP to advertise the bandwidth of the specified external interface as an extended community. This command is configured for links between directly connected external BGP (eBGP) neighbors. The link bandwidth extended community attribute is propagated to iBGP peers when extended community exchange is enabled with the neighbor send-community command. This feature is used with BGP multipath features to configure load balancing over links with unequal bandwidth. This feature is not enabled until the bgp dmzlink-bw command is entered under the address family session for each router that has a directly connected external link.

Examples

In the following example, the BGP Link Bandwidth feature is configured to allow multipath load balancing to distribute link traffic proportionally to the bandwidth of each external link, and to advertise the bandwidth of these links to iBGP peers as an extended community:

Router(config)# router bgp 100 

Router(config-router)# neighbor 10.10.10.1 remote-as 100 

Router(config-router)# neighbor 10.10.10.1 update-source Loopback 0 

Router(config-router)# neighbor 10.10.10.3 remote-as 100 

Router(config-router)# neighbor 10.10.10.3 update-source Loopback 0 

Router(config-router)# neighbor 172.16.1.1 remote-as 200 

Router(config-router)# neighbor 172.16.1.1 ebgp-multihop 1 

Router(config-router)# neighbor 172.16.2.2 remote-as 200 

Router(config-router)# neighbor 172.16.2.2 ebgp-multihop 1 

Router(config-router)# address-family ipv4 

Router(config-router-af)# bgp dmzlink-bw 

Router(config-router-af)# neighbor 10.10.10.1 activate 

Router(config-router-af)# neighbor 10.10.10.1 next-hop-self 

Router(config-router-af)# neighbor 10.10.10.1 send-community both 

Router(config-router-af)# neighbor 10.10.10.3 activate 

Router(config-router-af)# neighbor 10.10.10.3 next-hop-self 

Router(config-router-af)# neighbor 10.10.10.3 send-community both 

Router(config-router-af)# neighbor 172.16.1.1 activate 

Router(config-router-af)# neighbor 172.16.1.1 dmzlink-bw 

Router(config-router-af)# neighbor 172.16.2.2 activate 

Router(config-router-af)# neighbor 172.16.2.2 dmzlink-bw

Router(config-router-af)# maximum-paths ibgp 6

Router(config-router-af)# maximum-paths 6

Related Commands

neighbor ebgp-multihop

To accept and attempt BGP connections to external peers residing on networks that are not directly connected, use the neighbor ebgp-multihop command in router configuration mode. To return to the default, use the no form of this command.

neighbor {ip-address | ipv6-address | peer-group-name} ebgp-multihop [ttl]

no neighbor {ip-address | ipv6-address | peer-group-name} ebgp-multihop

Syntax Description

Command Default

Only directly connected neighbors are allowed.

Command Modes

Router configuration

Command History

Usage Guidelines

This feature should be used only under the guidance of Cisco technical support staff.

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command.

To prevent the creation of loops through oscillating routes, the multihop will not be established if the only route to the multihop peer is the default route (0.0.0.0).

Examples

The following example allows connections to or from neighbor 10.108.1.1, which resides on a network that is not directly connected:

router bgp 109

 neighbor 10.108.1.1 ebgp-multihop

Related Commands

neighbor fall-over

To enable Border Gateway Protocol (BGP) to monitor the peering session of a specified neighbor for adjacency changes and to deactivate the peering session, use the neighbor fall-over command in address family or router configuration mode. To disable BGP monitoring of the neighbor peering session, use the no form of this command.

neighbor {ip-address | ipv6-address} fall-over [bfd | route-map map-name]

no neighbor {ip-address | ipv6-address} fall-over [bfd | route-map map-name]

Syntax Description

ip-address	IPv4 address of a BGP neighbor.
ipv6-address	IPv6 address of a BGP neighbor.
bfd	(Optional) Enables Bidirectional Forwarding Detection (BFD) protocol support for fallover.
route-map map-name	(Optional) Specifies the use of a route map by name. Note The route map applies only to a neighbor with an IPv4 address.

Command Default

BGP does not monitor neighbor peering sessions.

Command Modes

Address family configuration (config-router-af)
Router configuration (config-router)

Command History

Usage Guidelines

The neighbor fall-over command is a BGP neighbor session command that is used to enable BGP fast peering session deactivation. BGP fast peering session deactivation improves BGP convergence and response time to adjacency changes with BGP neighbors. BGP fast peering session deactivation is event-driven and is configured on a per-neighbor basis. When BGP fast peering session deactivation is enabled, BGP will monitor the peering session with the specified neighbor. Adjacency changes are detected, and terminated peering sessions are deactivated in between the default or configured BGP scanning interval.

In Cisco IOS Release 12.4(4)T, 12.2(33)SRB, and later releases, the optional route-map keyword and map-name argument are used with this command to determine if a peering session with a BGP neighbor should be deactivated (reset) when a route to the BGP peer changes. The route map is evaluated against the new route, and if a deny statement is returned, the peer session is reset. The route map is not used for session establishment.

Note Only the match ip address and match source-protocol commands are supported in the route map. No set commands or other match commands are supported.

In Cisco IOS Release 12.2(33)SRA, 12.2(33)SB, and later releases, the optional bfd keyword is used to enable BFD protocol support for fallover. BFD provides fast forwarding path failure detection and a consistent failure detection method for network administrators. Because the network administrator can use BFD to detect forwarding path failures at a uniform rate, rather than the variable rates for different routing protocol hello mechanisms, network profiling and planning will be easier, and reconvergence time will be consistent and predictable. The main benefit of implementing BFD for BGP is a marked decrease in reconvergence time.

In Cisco IOS Release 15.1(2)S, Cisco IOS XE Release 3.3S, and later releases, an IPv6 address can be specified with the bfd keyword. Once it has been verified that BFD neighbors are up, the show bgp ipv6 unicast neighbors command with a specified IPv6 address will display that BFD is being used to detect fast fallover.

Examples

In the following example, the BGP routing process is configured to monitor and use fast peering session deactivation for the neighbor session with the neighbor at 192.168.1.2:

router bgp 45000 

 neighbor 192.168.1.2 remote-as 40000 

 neighbor 192.168.1.2 fall-over 

 end

In the following example, the BGP peering session will be reset if a route with a prefix of /28 or a more specific route to a peer destination is no longer available:

router bgp 45000 

 neighbor 192.168.1.2 remote-as 40000 

 neighbor 192.168.1.2 fall-over route-map CHECK-NBR

 exit

ip prefix-list FILTER28 seq 5 permit 0.0.0.0/0 ge 28

route-map CHECK-NBR permit 10

 match ip address prefix-list FILTER28

 end

In the following example, BFD is enabled for Fast Ethernet interface 0/1 with a specified BFD interval. The BGP peering session is also BFD enabled and this will result in a decreased reconvergence time for BGP if any of the forwarding paths to specified neighbors fail.

interface FastEthernet 0/1

 ip address 172.16.10.1 255.255.255.0

 bfd interval 50 min_rx 50 multiplier 3

 exit

router bgp 40000

 bgp log-neighbor-changes

 neighbor 172.16.10.2 remote-as 45000 

 neighbor 172.16.10.2 fall-over bfd

 exit

In the following IPv6 example, BFD is enabled for Fast Ethernet interface 0/1 with a specified BFD interval. The BGP peering session is also BFD enabled and this will result in a decreased reconvergence time for BGP if any of the forwarding paths to the specified neighbor at 2001:DB8:2:1::4 fail.

ipv6 unicast-routing

ipv6 cef

interface fastethernet 0/1

 ipv6 address 2001:DB8:1:1::1/64

 bfd interval 500 min_rx 500 multiplier 3

 no shutdown

 exit

router bgp 65000 
 no bgp default ipv4-unicast 
 address-family ipv6 unicast

 bgp log-neighbor-changes

 neighbor 2001:DB8:2:1::4 remote-as 45000 

 neighbor 2001:DB8:2:1::4 fall-over bfd

 end

Related Commands

neighbor filter-list

To set up a BGP filter, use the neighbor filter-list command in address family or router configuration mode. To disable this function, use the no form of this command.

neighbor {ip-address | peer-group-name} filter-list access-list-number {in | out}

no neighbor {ip-address | peer-group-name} filter-list access-list-number {in | out}

Syntax Description

Command Default

No BGP filter is used.

Command Modes

Router configuration or Address family configuration

Command History

Usage Guidelines

This command establishes filters on both inbound and outbound BGP routes.

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command. Specifying the command with an IP address will override the value inherited from the peer group.

Note Do not apply both a neighbor distribute-list and a neighbor prefix-list command to a neighbor in any given direction (inbound or outbound). These two commands are mutually exclusive, and only one command ( neighbor distribute-list or neighbor prefix-list) can be applied to each inbound or outbound direction.

Examples

In the following router configuration mode example, the BGP neighbor with IP address 172.16.1.1 is not sent advertisements about any path through or from the adjacent autonomous system 123:

ip as-path access-list 1 deny _123_

ip as-path access-list 1 deny ^123$

 router bgp 109

 network 10.108.0.0

 neighbor 192.168.6.6 remote-as 123

 neighbor 172.16.1.1 remote-as 47

 neighbor 172.16.1.1 filter-list 1 out

In the following address family configuration mode example, the BGP neighbor with IP address 172.16.1.1 is not sent advertisements about any path through or from the adjacent autonomous system 123:

ip as-path access-list 1 deny _123_

ip as-path access-list 1 deny ^123$

router bgp 109

 address-family ipv4 unicast

  network 10.108.0.0

  neighbor 192.168.6.6 remote-as 123

  neighbor 172.16.1.1 remote-as 47

  neighbor 172.16.1.1 filter-list 1 out

Related Commands

neighbor ha-mode graceful-restart

To enable or disable the Border Gateway Protocol (BGP) graceful restart capability for a BGP neighbor or peer group, use the neighbor ha-mode graceful-restart command in router configuration mode. To remove from the configuration the BGP graceful restart capability for a neighbor, use the no form of this command.

neighbor {ip-address | peer-group-name} ha-mode graceful-restart [disable]

no neighbor {ip-address | peer-group-name} ha-mode graceful-restart [disable]

Syntax Description

Command Default

BGP graceful restart capability is disabled.

Command Modes

Router configuration (config-router)

Command History

Usage Guidelines

The neighbor ha-mode graceful-restart command is used to enable or disable the graceful restart capability for an individual BGP neighbor or peer group in a BGP network. Use the disable keyword to disable the graceful restart capability when graceful restart has been previously enabled for the BGP peer.

The graceful restart capability is negotiated between nonstop forwarding (NSF)-capable and NSF-aware peers in OPEN messages during session establishment. If the graceful restart capability is enabled after a BGP session has been established, the session will need to be restarted with a soft or hard reset.

The graceful restart capability is supported by NSF-capable and NSF-aware routers. A router that is NSF-capable can perform a stateful switchover (SSO) operation (graceful restart) and can assist restarting peers by holding routing table information during the SSO operation. A router that is NSF-aware functions like a router that is NSF-capable but cannot perform an SSO operation.

To enable the BGP graceful restart capability globally for all BGP neighbors, use the bgp graceful-restart command. When the BGP graceful restart capability is configured for an individual neighbor, each method of configuring graceful restart has the same priority, and the last configuration instance is applied to the neighbor.

Use the show ip bgp neighbors command to verify the BGP graceful restart configuration for BGP neighbors.

Examples

The following example enables the BGP graceful restart capability for the BGP neighbor, 172.21.1.2:

router bgp 45000

 bgp log-neighbor-changes

 address-family ipv4 unicast

 neighbor 172.21.1.2 remote-as 45000

 neighbor 172.21.1.2 activate

 neighbor 172.21.1.2 ha-mode graceful-restart

 end

The following example enables the BGP graceful restart capability globally for all BGP neighbors and then disables the BGP graceful restart capability for the BGP peer group PG1. The BGP neighbor 172.16.1.2 is configured as a member of the peer group PG1 and inherits the disabling of the BGP graceful restart capability.

router bgp 45000

 bgp log-neighbor-changes

 bgp graceful-restart

 address-family ipv4 unicast

 neighbor PG1 peer-group

 neighbor PG1 remote-as 45000

 neighbor PG1 ha-mode graceful-restart disable

 neighbor 172.16.1.2 peer-group PG1

 end

Related Commands

neighbor ha-mode sso

To configure a Border Gateway Protocol (BGP) neighbor to support BGP nonstop routing (NSR) with stateful switchover (SSO), use the neighbor ha-mode sso command in the appropriate command mode. To remove the configuration, use the no form of this command.

neighbor ip-address ha-mode sso

no neighbor ip-address ha-mode sso

Syntax Description

Command Default

BGP NSR with SSO support is disabled.

Command Modes

Address family configuration
Session-template configuration

Command History

Usage Guidelines

The neighbor ha-mode sso command is used to configure a BGP neighbor to support BGP NSR with SSO. BGP NSR with SSO is disabled by default.

BGP NSR with SSO is supported in BGP peer, BGP peer group, and BGP session template configurations. To configure BGP NSR with SSO in BGP peer and BGP peer group configurations, use the neighbor ha-mode sso command in address family configuration mode for IPv4 VRF address family BGP peer sessions. To include support for Cisco BGP NSR with SSO in a peer session template, use the ha-mode sso command in session-template configuration mode.

Examples

The following example shows how to configure a BGP neighbor to support SSO:

Router(config-router-af)# neighbor 10.3.32.154 ha-mode sso

Related Commands

neighbor inherit peer-policy

To send a peer policy template to a neighbor so that the neighbor can inherit the configuration, use the neighbor inherit peer-policy command in address family or router configuration mode. To stop sending the peer policy template, use the no form of this command.

neighbor ip-address inherit peer-policy policy-template-name

no neighbor ip-address inherit peer-policy policy-template-name

Syntax Description

Defaults

No default behavior or values

Command Modes

Address family
Router configuration

Command History

Usage Guidelines

This command is used to send locally configured policy templates to the specified neighbor. If the policy template is configured to inherit configurations from other peer policy templates, the specified neighbor will also indirectly inherit these configurations from the other peer policy templates. A directly applied peer policy template can directly or indirectly inherit configurations from up to seven peer policy templates. So, a total of eight peer policy templates can be applied to a neighbor or neighbor group.

Note A Border Gateway Protocol (BGP) neighbor cannot be configured to work with both peer groups and peer templates. A BGP neighbor can be configured to belong only to a peer group or to inherit policies only from peer templates.

Examples

The following example configures the 10.0.0.1 neighbor in address family configuration mode to inherit the peer policy template name CUSTOMER-A. The 10.0.0.1 neighbor will also indirectly inherit the peer policy templates in CUSTOMER-A. The explicit remote-as statement is required for the neighbor inherit statement to work. If a peering is not configured, the specified neighbor will not accept the session template.

Router(config)# router bgp 101

Router(config-router)# neighbor 10.0.0.1 remote-as 202

Router(config-router)# address-family ipv4 unicast

Router(config-router-af)# neighbor 10.0.0.1 inherit peer-policy CUSTOMER-A

Router(config-router-af)# exit

Related Commands

neighbor inherit peer-session

To send a peer session template to a neighbor so that the neighbor can inherit the configuration, use the neighbor inherit peer-session command in address family or router configuration mode. To stop sending the peer session template, use the no form of this command.

neighbor ip-address inherit peer-session session-template-name

no neighbor ip-address inherit peer-session session-template-name

Syntax Description

Defaults

No default behavior or values

Command Modes

Address family
Router configuration

Command History

Usage Guidelines

This command is used to send locally configured session templates to the specified neighbor. If the session template is configured to inherit configurations from other session templates, the specified neighbor will also indirectly inherit these configurations from the other session templates. A neighbor can directly inherit only one peer session template and indirectly inherit up to seven peer session templates.

Note A Border Gateway Protocol (BGP) neighbor cannot be configured to work with both peer groups and peer templates. A BGP neighbor can be configured to belong only to a peer group or to inherit policies only from peer templates.

Examples

The following example configures the 172.16.0.1 neighbor to inherit the CORE1 peer session template. The 172.16.0.1 neighbor will also indirectly inherit the configuration from the peer session template named INTERNAL-BGP. The explicit remote-as statement is required for the neighbor inherit statement to work. If a peering is not configured, the specified neighbor will not accept the session template.

Router(config)# router bgp 101

Router(config)# neighbor 172.16.0.1 remote-as 202

Router(config-router)# neighbor 172.16.0.1 inherit peer-session CORE1

Related Commands

neighbor local-as

To customize the AS_PATH attribute for routes received from an external Border Gateway Protocol (eBGP) neighbor, use the neighbor local-as command in address family or router configuration mode. To disable AS_PATH attribute customization, use the no form of this command.

neighbor {ip-address | peer-group-name} local-as [autonomous-system-number [no-prepend [replace-as [dual-as]]]]

no neighbor {ip-address | peer-group-name} local-as

Syntax Description

Command Default

The autonomous system number from the local BGP routing process is prepended to all external routes by default.

Command Modes

Address family configuration (config-router-af)
Router configuration (config-router)

Command History

Usage Guidelines

The neighbor local-as command is used to customize the AS_PATH attribute by adding and removing autonomous system numbers for routes received from eBGP neighbors. The configuration of this command allows a router to appear to external peers as a member of another autonomous system for the purpose of autonomous system number migration. This feature simplifies the process of changing the autonomous system number in a BGP network by allowing the network operator to migrate customers to new configurations during normal service windows without disrupting existing peering arrangements.

Caution BGP prepends the autonomous system number from each BGP network that a route traverses to maintain network reachability information and to prevent routing loops. This command should be configured only for autonomous system migration, and should be deconfigured after the transition has been completed. This procedure should be attempted only by an experienced network operator. Routing loops can be created through improper configuration.

This command can be used for only true eBGP peering sessions. This command does not work for two peers in different subautonomous systems of a confederation.

This command supports individual peering sessions and configurations applied through peer groups and peer templates. If this command is applied to a group of peers, the individual peers cannot be customized.

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.

To ensure a smooth transition, we recommend that all BGP speakers within an autonomous system that is identified using a 4-byte autonomous system number, be upgraded to support 4-byte autonomous system numbers.

Examples

local-as Configuration: Example

The following example establishes peering between Router 1 and Router 2 through autonomous system 300, using the local-as feature:

Router 1 (Local Router)

router bgp 100

 address-family ipv4 unicast 

  neighbor 172.16.1.1 remote-as 200

  neighbor 172.16.1.1 local-as 300

Router 2 (Remote Router)

router bgp 200

 address-family ipv4 unicast 

  neighbor 10.0.0.1 remote-as 300

no-prepend Keyword Configuration: Example

The following example configures BGP to not prepend autonomous system 500 to routes received from the 192.168.1.1 neighbor:

router bgp 400

 address-family ipv4 multicast

  network 192.168.0.0

  neighbor 192.168.1.1 local-as 500 no-prepend 

replace-as Keyword Configuration: Example

The following example strips private autonomous system 64512 from outbound routing updates for the 172.20.1.1 neighbor and replaces it with autonomous system 600:

router bgp 64512 

 address-family ipv4 unicast 

  neighbor 172.20.1.1 local-as 600 no-prepend replace-as 

  neighbor 172.20.1.1 remove-private-as 

dual-as Keyword Configuration: Example

The following examples show the configurations for two provider networks and one customer network. Router 1 belongs to autonomous system 100, and Router 2 belongs to autonomous system 200. Autonomous system 200 is being merged into autonomous system 100. This transition needs to occur without interrupting service to Router 3 in autonomous system 300 (customer network). The neighbor local-as command is configured on router 1 to allow Router 3 to maintain peering with autonomous system 200 during this transition. After the transition is complete, the configuration on Router 3 can be updated to peer with autonomous system 100 during a normal maintenance window or during other scheduled downtime.

Router 1 Configuration (Local Provider Network)

interface Serial3/0

 ip address 10.3.3.11 255.255.255.0

!

router bgp 100

 no synchronization

 bgp router-id 100.0.0.11

 neighbor 10.3.3.33 remote-as 300

 neighbor 10.3.3.33 local-as 200 no-prepend replace-as dual-as

Router 2 Configuration (Remote Provider Network)

interface Serial3/0

 ip address 10.3.3.11 255.255.255.0

 !

router bgp 200 

 bgp router-id 100.0.0.11

 neighbor 10.3.3.33 remote-as 300

Router 3 Configuration (Remote Customer Network)

interface Serial3/0

 ip address 10.3.3.33 255.255.255.0

 !

router bgp 300

 bgp router-id 100.0.0.3

 neighbor 10.3.3.11 remote-as 200 

To complete the migration after the two autonomous systems have merged, the peering session is updated on Router 3:

neighbor 10.3.3.11 remote-as 100

4-Byte Autonomous System Number no-prepend Keyword Configuration: Examples

The following example configures BGP to not prepend the 4-byte autonomous system number of 65536 in asplain format to routes received from the 192.168.1.2 neighbor. This example requires 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, or a later release.

router bgp 65538

 address-family ipv4 multicast

  network 192.168.0.0

  neighbor 192.168.1.2 local-as 65536 no-prepend

The following example configures BGP to not prepend the 4-byte autonomous system number of 1.0 in asdot format to routes received from the 192.168.1.2 neighbor. This example requires Cisco IOS Release 12.0(32)SY8, 12.0(32)S12, 12.2(33)SRE, 12.2(33)XNE, 12.2(33)SXI1, 12.4(24)T, or Cisco IOS XE Release 2.3.

router bgp 1.2

 address-family ipv4 multicast

  network 192.168.0.0

  neighbor 192.168.1.2 local-as 1.0 no-prepend

Related Commands

neighbor maximum-prefix

To control how many prefixes can be received from a neighbor, use the neighbor maximum-prefix command in router configuration mode. To disable this function, use the no form of this command.

neighbor {ip-address | peer-group-name} maximum-prefix maximum [threshold] [warning-only]

no neighbor {ip-address | peer-group-name} maximum-prefix maximum

Syntax Description

Defaults

This command is disabled by default. There is no limit on the number of prefixes.

Command Modes

Router configuration

Command History

Usage Guidelines

This command allows you to configure a maximum number of prefixes that a BGP router is allowed to receive from a peer. It adds another mechanism (in addition to distribute lists, filter lists, and route maps) to control prefixes received from a peer.

When the number of received prefixes exceeds the maximum number configured, the router terminates the peering (by default). However, if the warning-only keyword is configured, the router instead only sends a log message, but continues peering with the sender. If the peer is terminated, the peer stays down until the clear ip bgp command is issued.

Examples

The following example sets the maximum number of prefixes allowed from the neighbor at 192.168.6.6 to 1000:

router bgp 109

 network 10.108.0.0

 neighbor 192.168.6.6 maximum-prefix 1000

Related Commands

neighbor maximum-prefix (BGP)

To control how many prefixes can be received from a neighbor, use the neighbor maximum-prefix command in router configuration mode. To disable this function, use the no form of this command.

neighbor {ip-address | peer-group-name} maximum-prefix maximum [threshold] [restart restart-interval] [warning-only]

no neighbor {ip-address | peer-group-name} maximum-prefix maximum

Syntax Description

Defaults

This command is disabled by default. Peering sessions are disabled when the maximum number of prefixes is exceeded. If the restart-interval argument is not configured, a disabled session will stay down after the maximum-prefix limit is exceeded.

threshold: 75 percent

Command Modes

Router configuration

Command History

Usage Guidelines

The neighbor maximum-prefix command allows you to configure a maximum number of prefixes that a Border Gateway Protocol (BGP) routing process will accept from the specified peer. This feature provides a mechanism (in addition to distribute lists, filter lists, and route maps) to control prefixes received from a peer.

When the number of received prefixes exceeds the maximum number configured, BGP disables the peering session (by default). If the restart keyword is configured, BGP will automatically reestablish the peering session at the configured time interval. If the restart keyword is not configured and a peering session is terminated because the maximum prefix limit has been exceed, the peering session will not be be reestablished until the clear ip bgp command is entered. If the warning-only keyword is configured, BGP sends only a log message and continues to peer with the sender.

There is no default limit on the number of prefixes that can be configured with this command. Limitations on the number of prefixes that can be configured are determined by the amount of available system resources.

Examples

In the following example, the maximum prefixes that will be accepted from the 192.168.1.1 neighbor is set to 1000:

Router(config)# router bgp 40000 

Router(config-router)# network 192.168.0.0 

Router(config-router)# neighbor 192.168.1.1 maximum-prefix 1000 

In the following example, the maximum number of prefixes that will be accepted from the 192.168.2.2 neighbor is set to 5000. The router is also configured to display warning messages when 50 percent of the maximum-prefix limit (2500 prefixes) has been reached.

Router(config)# router bgp 40000 

Router(config-router)# network 192.168.0.0 

Router(config-router)# neighbor 192.168.2.2 maximum-prefix 5000 50 

In the following example, the maximum number of prefixes that will be accepted from the 192.168.3.3 neighbor is set to 2000. The router is also configured to reestablish a disabled peering session after 30 minutes.

Router(config)# router bgp 40000 

Router(config-router) network 192.168.0.0 

Router(config-router)# neighbor 192.168.3.3 maximum-prefix 2000 restart 30 

In the following example, warning messages will be displayed when the threshold of the maximum-prefix limit (500 x 0.75 = 375) for the 192.168.4.4 neighbor is exceeded:

Router(config)# router bgp 40000 

Router(config-router)# network 192.168.0.0 

Router(config-router)# neighbor 192.168.4.4 maximum-prefix 500 warning-only 

Related Commands

neighbor next-hop-self

To configure the router as the next hop for a BGP-speaking neighbor or peer group, use the neighbor next-hop-self command in router configuration mode. To disable this feature, use the no form of this command.

neighbor {ip-address | peer-group-name} next-hop-self

no neighbor {ip-address | peer-group-name} next-hop-self

Syntax Description

Defaults

This command is disabled by default.

Command Modes

Router configuration

Command History

Usage Guidelines

This command is useful in unmeshed networks (such as Frame Relay or X.25) where BGP neighbors may not have direct access to all other neighbors on the same IP subnet.

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group will inherit the characteristic configured with this command. Specifying the command with an IP address will override the value inherited from the peer group.

For a finer granularity of control, see the set ip next-hop command.

Examples

The following example forces all updates destined for 10.108.1.1 to advertise this router as the next hop:

router bgp 109

 neighbor 10.108.1.1 next-hop-self

Related Commands

neighbor next-hop-unchanged

To enable an external BGP (eBGP) peer that is configured as multihop to propagate the next hop unchanged, use the neighbor next-hop-unchanged command in address family or router configuration mode. To disable that propagation of the next hop being unchanged, use the no form of this command.

neighbor {ip-address | ipv6-address | peer-group-name} next-hop-unchanged [allpaths]

no neighbor {ip-address | ipv6-address | peer-group-name} next-hop-unchanged [allpaths]

Syntax Description

Command Default

This command is disabled by default.

Command Modes

Address family configuration (config-router-af)
Router configuration (config-router)

Command History