Basic Configuration

Two tasks are common to every BGP configuration: You must enable the BGP routing process, and you must configure BGP neighbors. All other basic configuration tasks are optional.

You can configure certain BGP attributes globally, for peer groups, or for individual peers. The most specific level of configuration takes precedence. For example, if you configure an attribute both globally and for a peer group, the peer group configuration takes precedence for that peer group, but does not affect other peer groups. If you configure an attribute both for a peer group and for a peer, the peer configuration takes precedence for that peer, but does not affect other members of that peer group.

Enabling BGP Routing

All BGP configurations require that you enable the BGP routing process on one or more routers.

    router bgp

• Use to enable the BGP routing protocol and to specify the local AS—the AS to which this BGP speaker belongs.
• All subsequent BGP configuration commands are placed within the context of this router and AS; you can have only a single BGP instance per virtual router.
• Specify only one BGP AS per virtual router.
• Example

host1(config)#router bgp 100

• This command takes effect immediately.
• Use the no version to remove the BGP process.

Understanding BGP Command Scope

BGP commands can be sorted into the following categories, each of which has a different scope; that is, each configures parameters within a different area of applicability:

• The commands listed in Table 1-2 configure parameters for the BGP process globally, regardless of address family.

Table 1-2 Commands affecting BGP globally 

bgp advertise-inactive	bgp log-neighbor-changes
bgp always-compare-med	bgp maxas-limit
bgp bestpath med confed	bgp redistribute-internal
bgp bestpath missing-as-worst	bgp router-id
bgp client-to-client reflection	bgp shutdown
bgp cluster-id	ip bgp-community new-format
bgp confederation identifier	maximum-paths
bgp confederation peers	overload shutdown
bgp default local-preference	rib-out disable
bgp enforce-first-as	router bgp
bgp fast-external-fallover	timers bgp

• The commands listed in Table 1-3 configure parameters for all address families within the current VRF context.

Table 1-3 Commands affecting all address families in a VRF

distance bgp

synchronization

• The commands listed in Table 1-4 configure parameters only for the current address family context.

Table 1-4 Commands affecting the current address family 

address family	ip route-type
aggregate-address	network
bgp dampening	redistribute
default-information originate	table-map
disable-dynamic-redistribute

• The commands listed in Table 1-5 configure parameters for a peer or peer group, regardless of address family. If the peer or peer group is activated in more than one address family, the values are changed in all those address families. These commands are said to apply on a per-VRF basis. In the following example, EBGP multihop is configured for the session, but when you configure an address family, it is not available—that is, it is not configurable per address family:

host1(config-router)#neighbor 1.1.3.4 remote-as 1234

host1(config-router)#neighbor 1.2.3.4 ebgp-multihop 5

host1(config-router)#address-family ipv4 multicast

host1(config-router-af)#neighbor 1.2.3.4 ebgp-multihop ?

                                                ^

% Invalid input detected at '^' marker.

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

Table 1-5 Commands affecting all address families for the specified peer or peer group 

neighbor advertisement -interval	neighbor remote-as
neighbor capability	neighbor rib-out disable
neighbor description	neighbor shutdown
neighbor ebgp-multihop	neighbor timers
neighbor maximum-update-size	neighbor update-source
neighbor password	neighbor weight

• The commands listed in Table 1-6 configure parameters separately for each address family exchanged over the BGP session. If you configure these parameters for a peer or peer group that is activated in more than one address family, the values are affected only for the current address family. The inbound route map is such a parameter; the following example demonstrates that a BGP session can have a different inbound route map for each address family.

host1(config-router)#neighbor 1.1.3.4 remote-as 1234

host1(config-router)#neighbor 1.2.3.4 route-map ucast-map in

host1(config-router)#address-family ipv4 multicast

host1(config-router-af)#neighbor 1.2.3.4 activate

host1(config-router-af)#neighbor 1.2.3.4 route-map mcast-map 
in

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

Table 1-6 Commands affecting only the current address family for the specified peer or peer group 

neighbor-activate	neighbor peer-group
neighbor allowas-in	neighbor prefix-list
neighbor as-override	neighbor prefix-tree
neighbor default-originate	neighbor remote-private-as
neighbor distribute-list	neighbor route-map
neighbor filter-list	neighbor route-reflector-client
neighbor local-as	neighbor send-community
neighbor maximum-prefix	neighbor soft-reconfiguration inbound
neighbor next-hop-self	neighbor unsuppress-map

Inheritance of Configuration Values

Peer groups inherit all configuration values that are globally configured. However, attributes configured for a peer group override inherited global configuration values. Individual peers that are members of peer groups inherit all configuration values from the peer group. However, attributes configured on a peer override values inherited from the peer group of which it is a member.

The neighbor commands enable you to control features or set parameters for individual peers or for peer groups. These commands can be classified into the four categories shown in Table 1-7, based on whether the command enables a feature or sets parameters, the levels at which it behaves, and how the no version of the command compares to the default version.

Table 1-7 Behavior of neighbor commands 

Category A: Enable or disable a feature that can be configured for a peer or for a peer group	Category B: Enable or disable a feature that can be configured for a peer, for a peer group, or globally	Category C: Set parameters for a peer or for a peer group	Category D: Set parameters for a peer, for a peer group, or globally
neighbor activate neighbor as-override neighbor ebgp-multihop neighbor next-hop-self neighbor remove-private-as neighbor route-reflector-client neighbor send-community neighbor soft-reconfiguration inbound	neighbor default-originate1 neighbor rib-out disable2 neighbor shutdown3	neighbor advertisement -interval neighbor allowas-in neighbor description neighbor distribute-list neighbor filter-list neighbor maximum-prefix neighbor maximum-update-size neighbor password neighbor prefix-list neighbor prefix-tree neighbor remote-as neighbor route-map neighbor unsuppress-map neighbor update-source neighbor weight	neighbor timers

Example 1

For category A and B commands, the behavior of the no version of the command is different from the behavior of the default version of the command. The no version explicitly disables the feature:

• Applied to a peer, the no version disables the feature regardless of whether the feature is enabled for any peer group to which it belongs.
• Applied to a peer group, the no version disables the feature regardless of whether the feature is enabled for BGP globally or by default.

The default version simply unconfigures the feature for the peer or peer group.

• Applied to a peer, the default version causes the peer to inherit the state of the feature (enabled or disabled) from any peer group to which it belongs.
• Applied to a peer group, the default version causes the peer group to inherit the state of the feature (enabled or disabled) from the BGP global configuration.

The following example illustrates this difference and the inheritance concept with the neighbor soft-reconfiguration inbound command.

host1(config-router)#neighbor lisbon peer-group

host1(config-router)#neighbor 10.19.7.8 peer-group lisbon

Inbound soft-reconfiguration is disabled by default, hence it is currently disabled for both the lisbon peer group and peer 10.19.7.8.

host1(config-router)#neighbor lisbon soft-reconfiguration 
inbound

Inbound soft-reconfiguration is now enabled for the lisbon peer group. Because the peer inherits values from the peer group, inbound soft-reconfiguration is now also enabled for peer 10.19.7.8.

host1(config-router)#no neighbor 10.19.7.8 
soft-reconfiguration inbound

The no command disables inbound soft-reconfiguration for peer 10.19.7.8, overriding the configuration of the peer group to which the peer 10.19.7.8 belongs. The configuration of an individual peer takes precedence over the configuration of the peer group to which the peer belongs.

host1(config-router)#default neighbor 10.19.7.8 
soft-reconfiguration inbound

The default version returns the peer to inheriting the peer group configuration. Because inbound soft-reconfiguration is still enabled for lisbon, it is now also enabled for peer 10.19.7.8.

host1(config-router)#default neighbor lisbon 
soft-reconfiguration inbound

Finally, this last command returns the peer group configuration to the default value, disabling inbound soft-reconfiguration. The peer 10.19.7.8 inherits this value.

Example 2

For category C and D commands, the behavior of the no version of the command is the same as the behavior of the default version of the command. The following example illustrates this behavior and the inheritance concept for the neighbor timers command.

By default, the BGP global keepalive timer is 30 seconds and the global hold-time timer is 90 seconds.

host1(config-router)#neighbor eastcoast peer-group

host1(config-router)#neighbor 10.10.21.23 peer-group 
eastcoast

Peer group eastcoast and peer 10.10.21.23 both have the default timer values. The peer group inherits the global timer values; the peer is a member of eastcoast and inherits the timer values from the peer group.

host1(config-router)#neighbor eastcoast timers 15 40

Now peer group eastcoast has a keepalive timer of 15 seconds and a hold-time timer of 40 seconds. Peer 10.10.21.23 inherits these values from the peer group.

host1(config-router)#no neighbor 10.10.21.23 timers

Now peer 10.10.21.23 has its timers reset to the global values of 30 and 90 seconds. The configuration of an individual peer takes precedence over the configuration of the peer group to which the peer belongs, which in turn takes precedence over the global configuration.

host1(config-router)#default neighbor 10.10.21.23 timers

Nothing changes. For commands in categories C and D, the behavior of the default version is the same as the no version. Peer 10.10.21.23 still has the global timer values.

host1(config-router)#neighbor eastcoast timers 20 20

The eastcoast peer group now has timer values of 20 seconds. Peer 10.10.21.23 still has the global timer values.

Limitations on Inheritance

All BGP peers that are members of the same peer group must send essentially the same updates. Accordingly, all members of a peer group must be the same kind of peer; that is, all must be internal peers, all must be external peers, or all must be confederation peers.

Outbound policies configured for peer groups are still inherited by peer group members, but you cannot override this inherited outbound policy by configuring a different outbound policy on individual members of that peer group with the following commands:

neighbor as-override	neighbor next-hop-self	neighbor route-map out
neighbor default-originate	neighbor prefix-list out	neighbor route-reflector-client
neighbor distribute-list out	neighbor prefix-tree out	neighbor send-community
neighbor filter-list out	neighbor remove-private-as	neighbor unsuppress-map

Note: This restriction does not apply to inbound policy, which you can still override per peer.

The update messages can vary for members of a peer group as follows:

• The next hop can be different for each update sent to peer group members if the members are all external peers.
• The AS path can be different for each update sent to peer group members if the members are all external peers if you have enabled AS override with the neighbor as-override command.

Setting the BGP Identifier

By default, the router ID of the system is used as the BGP identifier. You can use the bgp router-id command to configure an IP address as the BGP identifier.

    bgp router-id

• Use to configure an IP address as the BGP identifier.
• Example

host1(config-router)#bgp router-id 10.25.1.1 

• The new BGP identifier is used in open messages sent after you issue the command. To use the new BGP identifier for sessions already in the established state, you must use the clear ip bgp command to perform a hard clear.
• Use the no version to restore the system's router ID as the BGP identifier.

Configuring Neighbors

Use the neighbor remote-as command to create a BGP peering session with a given BGP peer—identified by its IP address—in a given AS. Note that the neighbor remote-as command must be issued on both routers on either side of a BGP session for the BGP session to become established.

Consider the simple network structure shown in Figure 1-8. Routers LA and SanJose are IBGP peers within AS 873. Router SanJose has an EBGP peer, router Boston, in AS 17.

Figure 1-8 Configuring neighbors

The following commands configure router Boston with router SanJose as a peer:

host1(config)#router bgp 17

host1(config-router)#neighbor 10.5.5.4 remote-as 873

The following commands configure router SanJose with router LA and router Boston as peers:

host2(config)#router bgp 873

host2(config-router)#neighbor 10.2.2.3 remote-as 873

host2(config-router)#neighbor 10.5.5.1 remote-as 17

The following commands configure router LA with router SanJose as a peer:

host3(config)#router bgp 873

host3(config-router)#neighbor 10.2.2.4 remote-as 873

    neighbor remote-as

• Use to add an entry to the BGP neighbor table.
• Specifying a neighbor with an AS number that matches the AS number specified in the router bgp command identifies the neighbor as internal to the local AS. Otherwise, the neighbor is considered external.
• 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.
• Use the no version to remove an entry from the table.

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

• Associates 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.
• Example

host1(config-router)#neighbor 10.11.0.5 description 
bostonmetropeer

• This command takes effect immediately.
• Use the no version to remove the 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.
• 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

• This command takes effect immediately.
• Use the no version to stop logging.

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.
• Use the no version to restore the interface assignment to the closest interface.

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 1-9, router Boston and router LA are connected together via router NY, rather than by a direct connection. Routers Boston and LA are configured as external peers with the 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.

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

Figure 1-9 Using 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.
• 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.

Controlling the Number of Prefixes

As your 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.

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 should not include the private AS numbers in the path. Configure your 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 RIB, 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.

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 RIB and therefore is displayed via 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 RIB, 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.

If you use the fields as-path option with the show ip bgpo 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 system does not make the connection between the BGP peers.

The MD5 authentication feature uses the MD5 algorithm. When you specify this command, the system 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.

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.

Setting Memory Limits for BGP Tables

You can use the limits command to configure the memory limits of the internal BGP tables stored by the system. We recommend that you do not change these limits unless absolutely necessary. In most BGP environments, modifying the limits is unnecessary.

You can set the limits for one or more of the following BGP tables:

Address Family	Peer
Aggregated Routes	Peer Address Family
BGP Destinations	Peer Group
Dampening	Peer Group Address Family
Network Layer Reachability Entry	Received Routes
Network Layer Reachability Information	Redistributed Routes
Network Routes	RIB-Out
Next Hop	Route Flap History
Path Attributes	VRF

    limits

• Use to set memory limits for the BGP internal tables maintained by BGP software.
• Specify any limit as an integer in the range 0-214783648.
• All limits have a default value of 5000000, except the rib-out limit, which defaults to 1000000.
• Example

host1(config-router)#limits vrf 1250000 

host1(config-router)#limits next-hop 7500000 

• This command takes effect immediately.
• Use the no version to return the memory limits to their default values.

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.

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 via 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.
• Example

host1(config-router)#neighbor 192.168.21.5 timers 90 240

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

    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.

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.

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.

    bgp shutdown

• Use to shut down BGP globally.
• Example

host1(config-router)#bgp shutdown

• This command takes effect immediately.
• Use the no version to reenable BGP.

    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.

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

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.
• Example

host1(config-router)#overload shutdown

• This command takes effect immediately.
• Use the no version to restore the default behavior.

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 only has to apply outbound policy 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 system 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 only sends the update message if the new information is different than 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 does not happen for peer groups, because their Adj-RIBs-Out tables stores 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 later in this chapter for information on 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 RIB. 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 only change outbound policy 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 contains all routes actually sent to the peer. In contrast, if you enable storage for a peer group, the peer group's Adj-RIBs-Out 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.
• Example

host1(config-router)#no neighbor 10.15.24.5 rib-out disable

• This command takes effect immediately and automatically bounces the BGP session(s) if the command changes the current configuration.
• 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.

    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.
• Example

host1(config)#rib-out disable

• This command takes effect immediately and automatically bounces the BGP session if the command changes the current configuration.
• 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.

Configuring the Address Family

The BGP multiprotocol extensions specify that BGP can exchange information within different types of address families. Our BGP implementation defines three different types of address families:

• Unicast IPv4 - If you do not explicitly specify the address family, the system employs Unicast IPv4 addresses by default.
• 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 a general description of multicasting, see ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 3, Configuring IP Multicasting.
• VPN IPv4 - If you specify the VPN-IPv4 address family, you can configure the system to provide IPv4 VPN services via an MPLS backbone. These VPNs are often referred to as BGP/MPLS VPNs. For detailed information, see Chapter 3, Configuring BGP/MPLS VPNs.

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. Specify an address family within which the router should exchange addresses.
2. Specify individual neighbors or peer groups that will exchange routes only from within the current address family.
3. Configure BGP parameters for the address family.
4. Exit Address Family Configuration mode.

    address-family

• Use to configure the router or VRF to exchange IPv4 addresses in unicast, multicast, or VPN mode by creating the specified address family.
• The default setting is to exchange IPv4 addresses in unicast mode from the default router.
• Examples:

host1:vr1(config-router)#address-family ipv4 multicast

host1:vr1(config-router)#address-family vpnv4 vrf vr2

host1:vr1(config-router)#address-family ipv4 unicast

• Creating an address family for a VRF automatically disables both synchronization and automatic summarization for that VRF.
• This command takes effect immediately.
• Use the no version to disable the exchange of a type of prefix.

    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.

    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.

    neighbor activate

• Use to specify a peer with which routes of the current address family are exchanged.
• A peer can be activated in more than one address family. By default, a peer is activated only for the IPv4 unicast address family.
• The peer must be created in unicast IPv4 or VPN 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.
• Example

host1:vr1(config-router-af)#neighbor 192.168.1.158 activate

• 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 RIB of the newly activated address family.

• Use the no version to indicate that routes of the current address family should not 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.

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.