[Contents] [Prev] [Next] [Index] [Report an Error]

# Configuring BGP Peer Groups

You will often want to apply the same policies to most or all of the peers of a particular BGP speaker. Update policies are usually defined by route maps, filter lists, and distribution lists. You can reduce the configuration effort by defining a peer group made up of these peers.

A peer group is defined relative to a particular BGP speaker. Figure 11 shows two peer groups, eastcoast and leftcoast. Each of these peer groups is defined for router Chicago, the hub router. Routers Boston, NY, and Miami have no knowledge of being members of Router Chicago’s eastcoast peer group. Similarly, routers SanFran, LA, and SanDiego have no knowledge of being members of router Chicago’s leftcoast peer group.

The following commands configure the eastcoast peer group on router Chicago:

`

host1(config)#router bgp 23
host1(config)#route-map wtset permit 10
host1(config-route-map)#set weight 25
host1(config-route-map)#exit
host1(config-router)#neighbor eastcoast peer-group
host1(config-router)#neighbor eastcoast route-map wtset in
host1(config-router)#neighbor 10.6.6.2 remote-as 12
host1(config-router)#neighbor 10.6.6.2 peer-group eastcoast
host1(config-router)#neighbor 10.7.3.2 remote-as 12
host1(config-router)#neighbor 10.7.3.2 peer-group eastcoast
host1(config-router)#neighbor 10.4.4.2 remote-as 12
host1(config-router)#neighbor 10.4.4.2 peer-group eastcoast

`

The following commands configure the leftcoast peer group on router Chicago:

`

host1(config-router)#neighbor leftcoast peer-group
host1(config-router)#neighbor 10.3.3.2 remote-as 78
host1(config-router)#neighbor 10.3.3.2 peer-group leftcoast
host1(config-router)#neighbor 10.3.2.2 remote-as 2143
host1(config-router)#neighbor 10.3.2.2 peer-group leftcoast
host1(config-router)#neighbor 10.3.1.2 remote-as 136
host1(config-router)#neighbor 10.3.1.2 peer-group leftcoast

`

The multiprotocol extensions to BGP enable the exchange of information within different types of address families. By default, peers and peer groups exist in the unicast IPv4 address family and exchange unicast IPv4 addresses. For information on configuring and activating BGP peer groups within address families, see Configuring the Address Family.

Figure 11: BGP Peer Groups

neighbor peer-group

- Two versions of this command exist. Use to create a BGP peer group or to configure a BGP neighbor to be a member of a peer group.
- To create a BGP peer group, specify a peerGroupName for the new peer group. Use the no version to remove a peer group.
- To assign members to a peer group, specify an ip-address and a peerGroupName of a BGP neighbor that belongs to this group.
- This command takes effect immediately.
- Use the no version to remove a neighbor from a peer group.
- See neighbor peer-group

| Note: You cannot mix IPv4 and IPv6 peer members in a peer group. Only one type peer is allowed, IPv4 or IPv6. For example, the following error is generated if an IPv6 peer group member is added to a peer group that already has IPv4 members; that is, where the peer-group type is IPv4:
    host1(config-router)#neighbor 1::1 peer-group hamburg
    % Unable to set 'peer-group' for address family ipv4:unicast for peer 1::1 in core (IPv6 peer cannot be member of a peer-group of type IPv4)

For information about the inheritance of configuration values by peer groups and peers, see Inheritance of Configuration Values.

## Setting the Peer Type

Each peer group must have a peer type before any BGP sessions for members of that peer group are allowed to come up and before the Adj-RIBs-Out table of that peer group can be filled. You can use the neighbor peer-type command to explicitly configure a peer type for a peer group.

Alternatively, you can implicitly configure the peer type of a peer group by either of the following methods:

- Configure a remote AS for the peer group.
- Assign a peer with a configured remote AS as a member of the peer group.

In both of these implicit cases, the remote AS is combined with the local AS, the configured confederation ID, and the configured confederation peers to determine the peer type of the peer group.

neighbor peer-type

- Use to specify a peer type for a peer group.
- This command is supported only for peer groups; it is not available for individual peers.
- Use the internal keyword to specify that peers must be in the same AS or, if confederations are employed, in the same sub-AS in the same confederation.
- Use the external keyword to specify that peers must be in a different AS.
- Use the confederation keyword to specify that peers must be in a different sub-AS in the same confederation. Use this keyword only if confederations are employed.
- This command takes effect immediately. If the command changes the peer type of the peer group, all BGP sessions for members of that peer group are automatically bounced.
- All the members of the peer group inherit the characteristic configured with this command. It cannot be overridden for a specific peer, because the command applies only to peer groups.
- Example
  `
  host1(config-router)#neighbor promispeers peer-type internal
  `
- Use the no version to remove the configuration from the peer group.
- See neighbor peer-type

## Assigning a Description

You can associate a description with a BGP neighbor or a peer group. This is a convenient way to store minimal pertinent information about the neighbor.

neighbor description

- Use to associate a textual description of up to 80 characters with a BGP neighbor or peer group.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- This command takes effect immediately.
- Example
  `
  host1(config-router)#neighbor 10.11.0.5 description bostonmetropeer
  `
- Use the no version to remove the description.
- See neighbor description

## Logging Neighbor State Changes

You can force BGP to log a message whenever a peer enters or leaves the Established state.

bgp log-neighbor-changes

- Use to log a notice message to the bgpNeighborChanges log when a neighbor enters or leaves the Established state for any reason.
- The severity of the log message is notice by default.
- Issue the log destination console severity notice command to display the messages on the console.
- This command takes effect immediately.
- Example
  `
  host1:3(config)#bgp log destination console severity notice
  host1:3(config)#router bgp 100
  host1:3(config-router)#bgp log-neighbor-changes
  NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,4.4.4.4): peer 4.4.4.4 in core leaves established state
  NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,5.5.5.5): peer 5.5.5.5 in core leaves established state
  NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,6.6.6.6): peer 6.6.6.6 in core leaves established state
  NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,13.13.13.1): peer 13.13.13.1 in core leaves established state
  NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,4.4.4.4): peer 4.4.4.4 in core enters established state
  NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,5.5.5.5): peer 5.5.5.5 in core enters established state
  NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,6.6.6.6): peer 6.6.6.6 in core enters established state
  NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,13.13.13.1): peer 13.13.13.1 in core enters established state
  `
- Use the no version to stop logging.
- See bgp log-neighbor-changes

## Specifying a Source Address for a BGP Session

By default, BGP uses the IP address of the outgoing interface toward the peer as the source IP address for the TCP connection over which the BGP session runs. If the outgoing interface goes down, the BGP session is dropped because the IP source address is no longer valid. This is appropriate behavior for EBGP sessions because the EBGP peers typically can reach each other only by virtue of being connected to a common subnet.

For IBGP sessions, however, you typically want BGP sessions to be automatically rerouted around interfaces that are down. You can issue the neighbor update-source command to accomplish this. This command instructs BGP to use the IP address of a specified interface as the source address of the underlying TCP connection. Typically, a loopback interface is used because it is inherently stable.

For example, you can specify that BGP use loopback interface 2 as the source for messages that it sends to peer 192.50.30.1:

`

host1(config)#neighbor 192.50.30.1 update-source loopback 2

`

neighbor update-source

- Use to allow a BGP session to use the IP address of a specific operational interface as the source address for TCP connections.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- This command takes effect immediately and automatically bounces the BGP session.
- If you specify an interface in this command and the interface is later removed, then this command is also removed from the router configuration.
- Use the no version to restore the interface assignment to the closest interface.
- See neighbor update-source

The source address that you specify with the neighbor update-source command is also used by BGP as the default value for the next hop address advertised for IPv4 or IPv6 prefixes.

The source addresses and next hop address that result from using the neighbor update-source command vary depending on the configuration of the command. Table 13 lists the results for different configurations.

Table 13: Source Addresses and Default Next Hop Addresses for Various Configurations

Configured Neighbor Address | Configured Update Source Address | Source Address used for TCPv4 and TCPv6 Connection | Default Next Hop Value for IPv4 Prefixes | Default Next Hop Value for IPv6 Prefixes
--- | --- | --- | --- | ---
IPv4 neighbor address | IPv4 source address | IPv4 source address | IPv4 source address | IPv4 source address mapped to an IPv6 address
IPv4 neighbor address | IPv6 source address | Not allowed | Not allowed | Not allowed
IPv4 neighbor address | Interface name | IPv4 address of the interface. If the interface does not have an IPv4 address, then the session does not come up. | IPv4 address of the interface | IPv6 address of the interface. If the interface does not have an IPv6 address, then the IPv4 address of the interface is mapped to an IPv6 address.
IPv6 neighbor address | IPv6 source address | IPv6 source address | 0.0.0.0 | IPv6 source address
IPv6 neighbor address | IPv4 source address | Not allowed | Not allowed | Not allowed
IPv6 neighbor address | Interface name | IPv6 address of the interface. If the interface does not have an IPv6 address, then the session does not come up. | IPv4 address of the interface. If the interface does not have an IPv4 address, then 0.0.0.0. | IPv6 address of the interface

You can override a native IPv6 next-hop address with either the neighbor update-source command or an outbound route map.

When you specify an interface with the neighbor update-source command, the IPv4-mapped IPv6 address of the interface is used instead of the native IPv6 address for the next hop.

`

host1(config)#interface loopback 0
host1(config-if)#ip address 10.1.1.1/32
host1(config-if)#exit
host1(config)#router bgp 100
host1(config-router)#neighbor 2::2 update-source loopback 0

`

In this example, the IPv4-mapped IPv6 address of the loopback 0 interface is the next-hop address sent when IPv6 prefixes are advertised. However, if loopback 0 has an IPv6 address, then that address is used as the default next hop for advertising IPv6 prefixes.

## Specifying Peers That Are Not Directly Connected

Normally, EBGP speakers are directly connected. When you cannot connect EBGP speakers directly, you can use the neighbor ebgp-multihop command to specify that the neighbor is more than one hop away. You generally need static routes to configure multihop connections. By default, the one-hop limitation per EBGP peers is enforced by the time-to-live attribute. You can override this default limit by using the ttl variable to specify the maximum number of hops to the peer.

In Figure 12, router Boston and router LA are connected together through router NY, rather than by a direct connection. Routers Boston and LA are configured as external peers with the neighbor ebgp-multihop command because no direct connection exists between them. Because router NY is not a BGP speaker, static routes are configured on routers Boston and LA. The configuration for router NY is not shown, because it does not involve BGP.

Figure 12: Using EBGP-Multihop

The following commands achieve the BGP configuration.

To configure router Boston:

`

host1(config)#ip route 10.7.4.0 255.255.255.0 10.1.10.2
host1(config)#router bgp 100
host1(config-router)#neighbor 10.7.4.3 remote-as 300
host1(config-router)#neighbor 10.7.4.3 ebgp-multihop

`

To configure router LA:

`

host2(config)#ip route 10.1.10.0 255.255.255.0 10.7.4.4
host2(config)#router bgp 300
host2(config-router)#neighbor 10.1.10.1 remote-as 100
host2(config-router)#neighbor 10.1.10.1 ebgp-multihop

`

neighbor ebgp-multihop

- Use to configure BGP to accept route updates from external peers in networks that are not directly connected to the local peer.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- Any external BGP peering that is not resolved by a connected route is treated as a multihop. Configurations with loopback-to-loopback external BGP peering require the neighbor ebgp-multihop command to work properly. In these configurations, the neighbor remote-as command is issued with the address of a loopback interface.
- This command takes effect immediately and automatically bounces the BGP session.
- Use the no version to return BGP to halt acceptance of such routers. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
- See neighbor ebgp-multihop

## Specifying a Single-Hop Connection for IBGP Peers

IBGP peers are multihop by default. However, you can use the neighbor ibgp-single-hop command to enable single-hop connections for IBGP peers.

neighbor ibgp-singlehop

- Use to specify an internal BGP peer as a single-hop peer for IBGP sessions.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- If the neighbor session type is anything other than internal BGP, issuing this command generates an error message.
- This command takes effect immediately and automatically bounces the BGP session.
- Example
  `
  host1(config-router)#neighbor 192.168.32.15 ibgp-singlehop
  `
- Use the no version to restore the default behavior, wherein the internal peer cannot be a single-hop peer. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
- See neighbor ibgp-singlehop

## Controlling the Number of Prefixes

As the routing table increases in size, the processor and memory resources required to process routing information increases. Some peers send so much routing information that a BGP speaker can be overwhelmed by the updates. You can use the neighbor maximum-prefix command to limit how many prefixes can be received from a neighbor.

The router resets the BGP connection when the specified maximum is exceeded. You can use the warning-only keyword to log a warning rather than reset the connection. You can also configure the router so that a warning is logged when a specified percentage of the maximum is exceeded.

In the following example, the router is configured to reset the BGP connection when it receives more than 1,000 prefixes from its neighbor at 2.2.2.2:

`

host1(config)#router bgp 100
host1(config-router)#neighbor 2.2.2.2 maximum-prefix 1000

`

neighbor maximum-prefix

- Use to control how many prefixes can be received from a neighbor.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- By default, BGP checks the maximum prefix limit only against accepted routes. You can specify the strict keyword to force BGP to check the maximum prefix against all received routes. The accepted and received routes will likely differ when you have configured inbound soft reconfiguration and route filters for incoming traffic.
- This command takes effect immediately. To prevent a peer from continually flapping, when it goes to state idle because the maximum number of prefixes has been reached, the peer stays in state idle until you use the clear ip bgp command to issue a hard clear.
- Use the no version to remove the maximum number of prefixes.
- See neighbor maximum-prefix

## Removing Private AS Numbers from Updates

You might choose to conserve AS numbers by assigning private AS numbers to some customers. You can assign private AS numbers from the range 64,512 to 65,535. However, when BGP advertises prefixes to other ISPs, it is undesirable to include the private AS numbers in the path. Configure the external neighbors to drop the numbers with the neighbor remove-private-as command.

neighbor remove-private-as

- Use to remove private AS numbers only in updates sent to external peers.
- All private AS numbers are removed regardless of their position in the AS-path attribute and regardless of the presence of public AS numbers.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group.
- Example
  `
  host1(config-router)#neighbor 10.10.128.52 remove-private-as
  `
- New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command.

  To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.

  Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.

- Use the no version to halt the removal of private AS numbers in updates sent to external peers. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
- See neighbor remove-private-as

## Checking AS Path Length

You can use the bgp maxas-limit command to prevent the forwarding of routes having AS paths longer than a specified limit.

bgp maxas-limit

- Use to require BGP to check the AS path in all received update messages.
- If a received AS path is longer than the specified limit:
  - The route is stored in the BGP routing table and therefore is displayed by the show ip bgp commands.
  - The route is not a candidate for being selected as a best path, is not stored in the forwarding information base, and is not propagated to external or internal peers.
- Changes in the limit do not affect routes previously received. Clearing the BGP sessions (clear ip bgp) forces a resend of all routes; the new limits are then applied on receipt of the routes.
- Example
  `
  host1(config-router)#bgp maxas-limit 42
  `
- Causes BGP to check the AS path of all routes received after you issue the command.

  To apply the new behavior to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.

- Use the no version to halt checking of received AS path lengths.
- See bgp maxas-limit

If you use the fields as-path option with the show ip bgp command, the display indicates routes whose AS path exceeds the limit. The following display illustrates the result of setting the AS path length limit to 5:

    host1:3# show ip bgp fields intro best peer loc-pref as-path
    Local router ID 13.13.13.3, local AS 200
     10 paths, 5 distinct prefixes (520 bytes used)
     6 paths selected for route table installation
     14 path attribute entries (1943 bytes used)
    Status codes: > best
     Prefix              Peer            LocPrf AS-path
      10.23.40.1/32      192.168.13.1    200    100 211 32 15 67 44 (too long)
    > 10.23.40.1/32      172.123.23.2    100    100 211
    > 10.23.40.2/32      192.168.13.1    200    100 211 32 15 67
      10.23.40.2/32      172.123.23.2    100    100 211 32
    > 10.23.40.3/32      192.168.13.1           100 211 32 15
      10.23.40.3/32      172.123.23.2           100 211 32 15
      10.23.40.4/32      192.168.13.1    100    100 211 32
    > 10.23.40.4/32      172.123.23.2    200    100 211 32 15 67
    > 10.23.40.5/32      192.168.13.1    100    100 211
      10.23.40.5/32      172.123.23.2    200    100 211 32 15 67 44 (too long)

## Enabling MD5 Authentication on a TCP Connection

You can use the neighbor password command to enable MD5 authentication on a TCP connection between two BGP peers. Enabling MD5 authentication causes each segment sent on the TCP connection between them to be verified.

You must configure MD5 authentication with the same password on both BGP peers; otherwise, the router does not make the connection between the BGP peers.

The MD5 authentication feature uses the MD5 algorithm. When you specify this command, the router generates and checks the MD5 digest on every segment sent on the TCP connection.

In the following example, the password is set to “ opensesame” :

`

host1(config)#router bgp 100
host1(config-router)#neighbor 2.2.2.2 password opensesame

`

The show ip bgp neighbors command does not reveal the password, but does indicate whether MD5 authentication is configured for the session. The output of the show configuration command varies as follows:

- If you use the 8 keyword to specify that the password is encrypted, then the output of the show configuration command displays the text that you entered (the ciphertext password).
- If you do not use the 8 keyword (that is, you use the 0 keyword or no encryption keyword), and if the service password-encryption command has not been issued, then the output of the show configuration command displays the text that you entered (the plaintext password).
- If you do not use the 8 keyword (that is, you use the 0 keyword or no encryption keyword) but the service password-encryption command has been issued, then the output of the show configuration command displays an encrypted password that is equivalent to the cleartext password that you entered.

neighbor password

- Use to enable MD5 authentication on a TCP connection between two BGP peers.
- If you configure a password for a neighbor, an existing session is torn down and a new one established.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- If a router has a password configured for a neighbor, but the neighbor router does not, a message indicating this condition appears on the console while the routers attempt to establish a BGP session between them.
- Similarly, if the two routers have different passwords configured, a message appears on the console indicating that this condition exists.
- Use the 8 keyword to indicate that the password is encrypted (entered in ciphertext). Use the 0 keyword to indicate that the password is unencrypted (entered in plaintext).
- This command takes effect immediately and automatically bounces the BGP session.
- Use the no version to disable MD5 authentication.
- See neighbor password

## Setting the Maximum Size of Update Messages

You can use the neighbor maximum-update-size command to set the maximum size of update messages transmitted to a BGP peer.

For example, to set the maximum update size to 2,000 octets:

`

host1(config)#router bgp 100
host1(config-router)#neighbor 10.12.2.5 maximum-update-size 2000

`

neighbor maximum-update-size

- Use to set the maximum size for transmitted BGP update messages.
- Set the maximum-update-size to a range: 256–4096.
- The default is 1024 octets.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- BGP always accepts updates of up to 4096 octets, regardless of the setting for transmitted updated messages.
- Applies to all update messages sent after you issue the command.
- Use the no version to restore the default value.
- See neighbor maximum-update-size.

## Setting Automatic Fallover

You can use the bgp fast-external-fallover command to specify that in the event of the failure of a link to any adjacent external peer, the BGP session is immediately and automatically brought down rather than waiting for the TCP connection to fail or for the hold timer to expire.

bgp fast-external-fallover

- Use to immediately bring down a BGP session if the link to an adjacent external peer fails.
- If you do not issue this command, the BGP session is not brought down in the event of a link failure until the TCP connection fails or the hold timer expires.
- This command takes effect immediately.
- Use the no version to stop automatically bringing down the session in the event of link failure.
- See bgp fast-external-fallover.

## Setting Timers

BGP uses a keepalive timer to control the interval at which keepalive messages are sent. A hold-time timer controls how long BGP waits for a keepalive message before declaring a peer not available.

BGP negotiates the hold time with each neighbor when establishing the BGP connection. The peers use the lower of the two configured hold times. BGP sets the keepalive timer based on this negotiated hold time and the configured keepalive time.

neighbor timers

- Use to set the keepalive and hold-time timers for the specified neighbor or peer group.
- Overrides timer values set with the timers bgp command.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- If you set the keepalive timer to 0, BGP does not send any keepalive messages.
- If you do not expect the peer to send any keepalives, set the hold-time timer to 0.
- This command takes effect immediately and automatically bounces the session to force BGP to send a new open message to renegotiate the new timer values.
- Example
  `
  host1(config-router)#neighbor 192.168.21.5 timers 90 240
  `
- Use the no version to restore the default values on the specified neighbor or peer group—30 seconds for the keepalive timer and 90 seconds for the hold-time timer.
- See neighbor timers.

timers bgp

- Use to set the keepalive and hold-time timers for all neighbors.
- If you set the keepalive timer to 0, BGP does not send any keepalive messages.
- If you do not expect the peer to send any keepalives, set the hold-time timer to 0.
- Example
  `
  host1(config-router)#timers bgp 75 300
  `
- The new timer values are used by every session that comes up after you issue the command; timers configured specifically for the sessions take precedence over these values.

  To force sessions that are already established to use the new timer values, you must use the clear ip bgp command to perform a hard clear.

- Use the no version to restore the default values on all neighbors—30 seconds for the keepalive timer and 90 seconds for the hold-time timer.
- See timers bgp.

## Automatic Summarization of Routes

By default, all routes redistributed into BGP from an IGP are automatically summarized to their natural network masks.

auto-summary

- Use to reenable automatic summarization of routes redistributed into BGP.
- Automatic summarization is enabled by default. However, creating an address family for a VRF automatically disables automatic summarization for that address family.
- This command takes effect immediately.
- Use the no version to disable automatic summarization of redistributed routes.
- See auto-summary.

## Administrative Shutdown

You can administratively shut down particular BGP neighbors or peer groups without removing their configuration from BGP by using the neighbor shutdown command.

You can also administratively shut down BGP globally by using the bgp shutdown command.

bgp shutdown

- Use to shut down BGP globally.
- This command takes effect immediately.
- Example
  `
  host1(config-router)#bgp shutdown
  `
- Use the no version to reenable BGP.
- See bgp shutdown.

neighbor shutdown

- Use to shut down a neighbor or peer group without removing their configuration.
- This command takes effect immediately.
- Use the no version to reenable a neighbor or peer group that was previously shut down. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
- See neighbor shutdown.

## Configuring BGP for Overload Conditions

You can specify how you want BGP to behave when it is running out of memory in an overload condition. You can have BGP either shut itself down or continue running; in the latter case, BGP performance might be altered because of the lack of resources.

overload shutdown

- Use to shut down BGP if it runs out of memory.
- The default behavior is for BGP to transition from the Up state to the Overload state and continue running.
- This command takes effect immediately.
- Example
  `
  host1(config-router)#overload shutdown
  `
- Use the no version to restore the default behavior.
- See overload shutdown.

The following partial outputs show how the BGP state is indicated by the show ip bgp summary command:

    host1#show ip bgp summary
    Local router ID 10.1.0.1, local AS 1
      Administrative state is Start
      Operational state is Overload
      Shutdown in overload state is disabled
      Default local preference is 100
    ...
    host1#show ip bgp summary
    Local router ID 10.1.0.1, local AS 1
      Administrative state is Start
      Operational state is Down due to transition from Overload state
      Shutdown in overload state is enabled
      Default local preference is 100
    ...

## Enabling Route Storage in Adj-RIBs-Out Tables

By default, a BGP speaker does not store a copy of each route it sends to a BGP peer in the Adj-RIBs-Out table for that peer. However, you can force BGP to store a copy of routes in the Adj-RIBs-Out table for a particular peer or peer group by enabling that Adj-RIBs-Out table (“ enabling rib-out” ) with the no neighbor rib-out disable command. Alternatively, you can use the no rib-out disable command to affect all BGP peers. The details of route storage vary between peers and peer groups.

For peers, BGP stores a single bit with each route in the table to indicate whether it has previously advertised the route to the peer, enabling the avoidance of spurious withdrawals. The full set of attributes for each route is not stored in the peer Adj-RIBs-Out table.

After enabling rib-out for a peer, you can issue the show ip bgp neighbors advertised-routes command to display the routes that have been advertised to the peer. The attributes displayed for the routes are those from the local routing table, not those that were advertised. In other words, BGP stores the attributes prior to the application of any outbound policy.

For peer groups, BGP stores the full set of attributes associated with the route after the application of any outbound policy; that is, it stores the attributes as they will be advertised. BGP does not store a bit to track whether a route was advertised to the peer group. Storing the full attribute set for each peer group route is memory intensive but acceptable for peer groups, because the number of peer groups is relatively small. An advantage of enabling rib-out for peer groups is that convergence is accelerated because the attributes for each route are already determined for all routes to be advertised to the peer group. BGP has to apply outbound policy only once for each route rather than once for each peer for each route.

After enabling rib-out for a peer group, you can issue the show ip bgp advertised-routes command to display the routes that will be advertised to the peer group and the attributes (after the application of any outbound policy) that will be advertised with the routes.

When you have enabled rib-out for individual peers or a peer group, before sending an advertisement or withdrawal the router compares the route it is about to send with the last route sent for the same prefix (and stored in the Adj-RIBs-Out table for the peer or peer group) and sends the update message only if the new information is different from the old.

The comparison prevents the sending of unnecessary withdrawals for both peers and peer groups, because the BGP speaker will not send a withdrawal if the table indicates it has not previously advertised that route to the peer. However, because the route attributes are no longer stored with the routes in peer Adj-RIBs-Out tables, BGP cannot compare them with the attributes in the new update message. Consequently, BGP cannot determine whether the update contains new attributes or the same attributes as those previously advertised, and might send superfluous advertisements to peers. This circumstance does not happen for peer groups, because their Adj-RIBs-Out tables store the full attribute set.

### Effects of Changing Outbound Policies

After you change the outbound policy for a peer or peer group, the policy changes do not take effect until you issue either a hard clear or an outbound soft clear. (See Resetting a BGP Connection for information about performing clears with the clear ip bgp command.) The clear action causes BGP to reapply the outbound policy of the peer or peer group to each route in the BGP routing table. BGP then stores the results in the Adj-RIBs-Out table for that peer or peer group. The BGP session with each peer or peer group member takes the routes from the appropriate Adj-RIBs-Out table and sends them in update messages to the peer or peer group member.

| Note: You cannot change outbound policy for an individual peer group member. You can change outbound policy only for a peer group as a whole or for peers that are not members of a peer group.

neighbor rib-out disable

- Use to disable storage of routes (disable rib-out) in the specified neighbor’s Adj-RIBs-Out table or in a single Adj-RIBs-Out table for the entire specified peer group.
- Route storage is disabled by default.
- If you enable storage for a peer, the peer’s Adj-RIBs-Out table contains all routes actually sent to the peer. By contrast, if you enable storage for a peer group, the peer group’s Adj-RIBs-Out table contains those routes that the BGP speaker intends to send to the peer group members; individual members might or might not have already received updates that advertise the routes.
- If you specify a BGP peer group by using the peerGroupName argument, a single Adj-RIBs-Out table is enabled for the entire peer group. You can override this configuration for a member of the peer group by issuing the command for that peer.
- Limit the number of Adj-RIBs-Out tables to no more than ten for peer groups to conserve memory resources. No limit applies to peers.
- This command takes effect immediately and automatically bounces the BGP session(s) if the command changes the current configuration.
- Example
  `
  host1(config-router)#no neighbor 10.15.24.5 rib-out disable
  `
- Use the no version to enable the route storage. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
- See neighbor rib-out disable.

rib-out disable

- Use to disable storage of routes in the Adj-RIBs-Out tables (disable rib-out) for all BGP peers.
- Route storage is disabled by default.
- This command takes effect immediately and automatically bounces the BGP session if the command changes the current configuration.
- Example
  `
  host1(config)#rib-out disable
  `
- Use the no version to enable the route storage. Use the default version to remove the explicit global configuration from all peers and reestablish inheritance of the feature configuration.
- See rib-out disable.

## Configuring the Address Family

The BGP multiprotocol extensions specify that BGP can exchange information within different types of address families. The JUNOSe BGP implementation defines the following different types of address families:

- Unicast IPv4—If you do not explicitly specify the address family, the router is configured to exchange unicast IPv4 addresses by default. You can also configure the router to exchange unicast IPv4 routes in a specified VRF.
- Multicast IPv4—If you specify the multicast IPv4 address family, you can use BGP to exchange routing information about how to reach a multicast source instead of a unicast destination. For information about BGP multicasting commands, see Configuring BGP Routing . For a general description of multicasting, see JUNOSe Multicast Routing Configuration Guide.
- VPN IPv4—If you specify the VPN-IPv4 (also known as VPNv4) address family, you can configure the router to provide IPv4 VPN services over an MPLS backbone. These VPNs are often referred to as BGP/MPLS VPNs. For detailed information, see Configuring BGP-MPLS Applications.
- Unicast IPv6—If you specify the IPv6 unicast address family, you can configure the router to exchange unicast IPv6 routes or unicast IPv6 routes in a specified VRF. For a description of IPv6, see JUNOSe IP, IPv6, and IGP Configuration Guide.
- Multicast IPv6—If you specify the multicast IPv6 address family, you can use BGP to exchange routing information about how to reach an IPv6 multicast source instead of an IPv6 unicast destination. For a general description of multicasting, see JUNOSe Multicast Routing Configuration Guide.
- VPN IPv6—If you specify the VPN-IPv6 address family, you can configure the router to provide IPv6 VPN services over an MPLS backbone. These VPNs are often referred to as BGP/MPLS VPNs.
- L2VPN—If you specify the L2VPN address family, you can configure the PE router for VPLS L2VPNs or VPWS L2VPNs to exchange layer 2 network layer reachability information (NLRI) for all VPLS or VPWS instances. Optionally, you can use the signaling keyword with the address-family command for the L2VPN address family to specify BGP signaling of L2VPN reachability information. Currently, you can omit the signaling keyword with no adverse effects. For a description of VPLS, see Configuring VPLS. For a description of VPWS, see Configuring VPWS.
- Route-target—If you specify the route-target address family, you can configure the router to exchange route-target membership information to limit the number of routes redistributed among members. For a description of route-target filtering, see Configuring BGP-MPLS Applications.
- VPLS—If you specify the VPLS address family, you can configure the router to exchange layer 2 NLRI for a specified VPLS instance. For a description of VPLS, see Configuring VPLS.
- VPWS—If you specify the VPWS address family, you can configure the PE router to exchange layer 2 NLRI for a specified VPWS instance. For a description of VPWS, see Configuring VPWS.

Any command issued outside the context of an address family applies to the unicast IPv4 address family by default.

To limit the exchange of routes to those from within the address family and to set other desired BGP parameters:

1. Access Router Configuration mode and create peers and peer groups. These peers and peer groups are in the default IPv4 address family.
   `
   host1(config)#router bgp 100
   host1(config-router)#neighbor 10.10.2.2 remote-as 100
   host1(config-router)#neighbor 10.10.3.3 remote-as 100
   host1(config-router)#neighbor ibgp peer-group
   `
2. In Router Configuration mode, create the address family within which the router exchanges addresses; this creation accesses Address Family Configuration mode.
   `
   host1(config-router)#address-family vpn4 unicast
   `
3. From within the address family, activate individual neighbors or peer groups to exchange routes from within the current address family. These peers or peer groups must first be created in the IPv4 address family.
   `
   host1(config-router-af)#neighbor ibgp activate
   `
4. If you have activated a peer group, from within the address family add peers as members of the peer group. These peers must first be created in the IPv4 address family.
   `
   host1(config-router-af)#neighbor 10.10.2.2 peer-group ibgp
   host1(config-router-af)#neighbor 10.10.3.3 peer-group ibgp
   `
5. From within the address family, configure BGP parameters for the address family.
6. Exit Address Family Configuration mode.
   `
   host1:vr1(config-router-af)#exit-address-family
   `

address-family

- Use to configure the router or VRF to exchange IPv4 or IPv6 addresses by creating the specified address family.
- IPv4 and IPv6 addresses can be exchanged in unicast, multicast, or VPN mode.
- The default setting is to exchange IPv4 addresses in unicast mode from the default router.
- Creating an address family for a VRF automatically disables both synchronization and automatic summarization for that VRF.
- This command takes effect immediately.
- Examples
  `
  host1:vr1(config-router)#address-family ipv4 multicast
  host1:vr1(config-router)#address-family ipv4 unicast
  host1:vr1(config-router)#address-family ipv4 unicast vrf vr2
  host1:vr1(config-router)#address-family vpn4 unicast
  host1:vr1(config-router)#address-family ipv6 unicast
  `
- Use the no version to disable the exchange of a type of prefix.
- See address-family.

bgp default ipv4-unicast

- Use to configure all neighbors to exchange addresses in the IPv4 unicast address family.
- All neighbors must be activated with the neighbor activate command in the IPv4 address family.
- Example
  `
  host1:vr1(config-router)#bgp default ipv4-unicast
  `
- Affects only neighbors created after you issue the command. To affect existing neighbors created before you issued the command, you must use the neighbor activate command in the context of the IPv4 unicast address family.
- Use the no version to disable the exchange of IPv4 addresses on all neighbors.
- See bgp default ipv4-unicast.

exit-address-family

- Use to exit Address Family Configuration mode and access Router Configuration mode.
- Example
  `
  host1:vr1(config-router-af)#exit-address-family
  `
- There is no no version.
- See exit-address-family.

neighbor activate

- Use to specify a peer or peer group with which routes of the current address family are exchanged.
- A peer or peer group can be activated in more than one address family. By default, a peer is activated only for the IPv4 unicast address family.
- The peer or peer group must be created in unicast IPv4 before you can activate it in another address family.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- The address families that are actively exchanged over a BGP session are negotiated when the session is established.
- This command takes effect immediately. If dynamic capability negotiation was not negotiated with the peer, the session is automatically bounced so that the exchanged address families can be renegotiated in the open messages when the session comes back up.

  If dynamic capability negotiation was negotiated with the peer, BGP sends a capability message to the peer to advertise or withdraw the multiprotocol capability for the address family in which this command is issued. If a neighbor is activated, BGP also sends the full contents of the BGP routing table of the newly activated address family.

- Example
  `
  host1:vr1(config-router-af)#neighbor 192.168.1.158 activate
  `
- Use the no version to indicate that routes of the current address family are not to be exchanged with the peer. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
- See neighbor activate.

If you have configured some or all neighbors to be in the multicast or VPN-IPv4 address families, you can quickly configure all neighbors to be part of the IPv4 unicast address family by issuing the bgp default ipv4-unicast command.

## Enabling Lenient Behavior

You can use the neighbor lenient command to enable the BGP speaker to attempt to recover from malformed packet errors and finite state machine errors generated by a peer. If BGP can recover from the error, it logs a warning message and attempts to maintain the session with the peer. The normal, nonlenient behavior is for the BGP speaker to send a notification message to the peer generating the error and to terminate the session. By default, lenient behavior is disabled.

neighbor lenient

- Use to enable a BGP speaker to be more tolerant of some errors generated by a peer, such as malformed BGP messages or finite state machine errors.
- The speaker attempts to recover from the errors and avoid bringing down the BGP session with the peer.
- Lenient behavior is disabled by default.
- Example
  `
  host1(router-config)#neighbor 10.12.45.23 lenient
  `
- Use the no version to restore the default condition, disabling lenient behavior.
- See neighbor lenient.

## Configuring Promiscuous Peers and Dynamic Peering

You can use the neighbor allow command to enable a peer group to accept incoming BGP connections from any remote address that matches an access list. Such a peer group is known as a promiscuous peer group; the member peers are sometimes referred to as promiscuous peers.

Promiscuous peers are useful when the remote address of the peer is not known ahead of time. An example is in B-RAS applications, in which interfaces for subscribers are created dynamically and the remote address of the subscriber is assigned dynamically from a local pool or by using RADIUS or some other method.

BGP automatically creates a dynamic peer when a peer group member accepts the incoming BGP connection. Dynamic peers are passive, meaning that when they are not in the established state, they will accept inbound connections but they will not initiate outbound connections. You cannot configure any attributes for the dynamic peers. You cannot remove a dynamic peer with the no neighbor ip-address command.

When a dynamic peer goes from the established state to the idle state for any reason, BGP removes the dynamic peer only if it does not go back to the established state within 1 minute. This delay enables you to see the dynamic peer in show command output; for example, you might want to see the reason for the last reset or how many times the session flapped.

While a dynamic peer is not in the established state, the show ip bgp neighbor command displays the number of seconds remaining until the dynamic peer will be removed.

If you have configured the neighbor allow command for multiple peer groups, when an incoming BGP connection matches the access list of more than one of these peer groups, the dynamic peer is created only in the first peer group. (BGP orders peer groups alphabetically by name.)

When the BGP speaker receives an open message from a dynamic peer, the remote AS number must match one of the following criteria; the connection is closed if it does not:

- If the peer group has a configured remote AS number, then the received AS number must be the same as the configured remote AS number.
- If the peer group does not have a configured AS number, then the received AS number must be consistent with the peer type of the peer group. Use the neighbor peer-type command to configure the type of the peer-group.

If a peer group has been configured with a peer type but not a remote AS, then the remote AS for dynamic peers is not known until an open message has been received from the peer. Until then, show commands display the remote AS as “ ?” or “ unknown.”

Static peers that you configure with the neighbor remote-as or neighbor peer-group commands take precedence over the dynamic peers created as a result of the neighbor allow command. If the remote address of an incoming BGP connection matches both a static peer and the access list, the static peer is used and no dynamic peer is created. If you configure a new static peer while a dynamic peer for the same remote address already exists, BGP automatically removes the dynamic peer.

You can optionally specify the maximum number of dynamic peers that BGP can create for the peer group. There is no default maximum. In the absence of a specified maximum, the number of dynamic peers allowed is determined by the available memory and CPU. Dynamic peers consume about the same resources as static peers.

When the maximum number of dynamic peers has been created for a peer group, BGP rejects all subsequent connection attempts for that group. This behavior means that you can specify a maximum to help protect against denial-of-service attacks that attempt to create many dynamic peers to overwhelm your router resources.

BGP generates a log message whenever a dynamic peer is created, rejected because the maximum has been reached, or removed. BGP maintains counters for each peer group for the current number of dynamic peers, the highest number of concurrent dynamic peers ever reached, and the number of times a dynamic peer was rejected because the maximum was reached.

Because dynamic peers always fully inherit their configuration from a peer group, any features that are available for peers but not for peer group members are not supported for the dynamic peers. Currently, only ORFs are not supported for peer group members and therefore are not supported for dynamic peers.

clear bgp ipv6 dynamic-peers

clear ip bgp dynamic-peers

- Use to remove all dynamic peers in the specified scope.
- You can specify the IP address of a BGP neighbor or the name of a BGP peer group as the scope. For IPv4 only, you can also include a VRF in the scope.
- Use the asterisk (*) to remove all BGP dynamic peers.
- This command takes effect immediately.
- Example
  `
  host1#clear ip bgp 192.168.1.158 vrf boston5 dynamic-peers
  `
- There is no no version.
- See clear bgp ipv6 dynamic-peers.
- See clear ip bgp dynamic-peers.

neighbor allow

- Use to configure a peer group to accept incoming BGP connections from any remote address that matches the specified access list.
- When the BGP connection is accepted, a dynamic peer is automatically created.
- This command is supported only for peer groups; it is not available for individual peers. These dynamic peers are not displayed by the show configuration command and are not stored in NVS. However, the dynamic peers are displayed by show commands that display information about BGP peers, such as show ip bgp neighbors, show ip bgp summary, and so on.
- Incoming connections that match the specified access list are rejected if no peer type has been configured for the peer group.
- This command takes effect immediately. Any existing dynamic BGP sessions that are no longer allowed by the new configuration are removed automatically and immediately. Preexisting dynamic peers that are still allowed by the new configuration are not affected.
- All the members of the peer group inherit the characteristic configured with this command. It cannot be overridden for a specific peer, because the command applies only to peer groups.
- Example
  `
  host1(config-router)#neighbor promispeers allow remotelist1 max-peers 1023
  `
- Use the no version to remove the configuration from the peer group.
- See neighbor allow.

## Configuring Passive Peers

You can configure BGP to be passive regarding specific peers, meaning that the BGP speaker will accept inbound BGP connections from the peers but will never initiate an outbound BGP connection to the peers. This passive status conserves CPU and TCP connection resources when the neighbor does not exist.

For example, suppose you preprovision a router before installation with a large number of customer circuits to minimize the configuration changes you might have to make to the router. Any peers that do not exist will consume resources as BGP repeatedly attempts to establish a session with them.

If instead you initially configure the router as passive for those peers, BGP will not attempt to establish sessions to those peers but will wait until these remote peers initiate a session, thus conserving CPU resources.

If you configure both sides of a BGP session as passive, then the session can never come up because neither side can initiate the connection.

neighbor passive

- Use to configure the BGP speaker to only accept inbound BGP connections from the specified peer and never initiate outbound connections to that peer.
- This command takes effect immediately. If the session is not yet established, BGP immediately stops initiating outbound connections to the peer. If the session is already established, it is not bounced regardless of which side initiated the connection.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- Example
  `
  host1(config-router)#neighbor 10.12.3.5 passive
  `
- Use the no version to restore the default condition, permitting the initiation of outbound connections to the peer.
- See neighbor passive.

[Contents] [Prev] [Next] [Index] [Report an Error]