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


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

host1(config)#router bgp 100

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:

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

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

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

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

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:

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

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:

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

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

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

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

host1(config-router)#neighbor 10.11.0.5 description 
bostonmetropeer

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

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

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

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

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

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

host1(config-router)#neighbor 10.10.128.52 remove-private-as

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.

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

host1(config-router)#bgp maxas-limit 42

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.

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:

    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

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

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

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

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

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

    timers bgp

host1(config-router)#timers bgp 75 300

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.

Automatic Summarization of Routes

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

    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.

    bgp shutdown

host1(config-router)#bgp shutdown

    neighbor shutdown

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

host1(config-router)#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 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

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

    rib-out disable

host1(config)#rib-out disable

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:

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

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

    bgp default ipv4-unicast

host1:vr1(config-router)#bgp default ipv4-unicast

    exit-address-family

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

    neighbor activate

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

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.

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.


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