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

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. Individual command descriptions in this chapter and in Configuring BGP-MPLS Applications, provide more information about command behavior.

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 10, 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 with the default version.

Table 10: 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 advertise-map
  • neighbor as-override
  • neighbor
    bfd-liveness-detection
  • neighbor capability
  • neighbor ebgp-multihop
  • neighbor ibgp-singlehop
  • neighbor lenient
  • neighbor next-hop-self
  • neighbor next-hop-unchanged
  • neighbor passive
  • neighbor remove-private-as
  • neighbor route-reflector-client
  • neighbor send-community
  • neighbor soft-reconfiguration inbound
  • neighbor default-
    originate
  • neighbor graceful-
    restart
  • neighbor rib-out disable
  • neighbor shutdown
  • neighbor
    advertisement-interval
  • neighbor allow
  • neighbor allowas-in
  • neighbor description
  • neighbor distribute-list
  • neighbor filter-list
  • neighbor graceful-restart restart-time
  • neighbor graceful-restart stalepaths-time
  • neighbor local-as
  • neighbor maximum-orf-entries
  • neighbor maximum-prefix
  • neighbor maximum-update-size
  • neighbor password
  • neighbor peer-group
  • neighbor peer-type
  • neighbor prefix-list
  • neighbor prefix-tree
  • neighbor remote-as
  • neighbor route-map
  • neighbor send-label
  • neighbor site-of-origin
  • neighbor unsuppress-map
  • neighbor update-source
  • neighbor weight
  • neighbor
    timers

Some of the commands in Table 10 inherit global values set by other commands. Table 11 describes the relationship between these commands.

Table 11: Inheritance from Other Commands

Category B Command

Inherits Global Values Set By

neighbor default-originate

default-information originate

neighbor graceful-restart

bgp graceful-restart

neighbor rib-out disable

rib-out disable

neighbor shutdown

bgp shutdown

neighbor graceful-restart restart-time

bgp graceful-restart restart-time

neighbor graceful-restart stalepaths-time

bgp graceful-restart stalepaths-time

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:

Table 12: Commands That Do Not Override Inherited Outbound Policy

neighbor as-override

neighbor next-hop-unchanged

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

neighbor next-hop-self

 

 

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 router 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

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 10. Routers LA and SanJose are IBGP peers within AS 873. Router SanJose has an EBGP peer, router Boston, in AS 17.

Figure 10: Configuring Neighbors

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