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

BGP Peer Groups

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:

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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:

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

bgp default ipv4-unicast

exit-address-family

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

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

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

Copyright© 1999-2014 Juniper Networks, Inc. All rights reserved.