This document describes the requirements, limitations, and benefits when you use peer groups with Border Gateway Protocol (BGP).
The major benefit you achieve when you specify a BGP peer group is that a BGP peer group reduces the amount of system resources (CPU and memory) necessary in an update generation. In addition, a BGP peer group also simplifies the BGP configuration. A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. Based on the number of peer group members, the number of prefixes in the table, and the number of prefixes advertised, this can significantly reduce the load. It is recommended that you group together peers with identical outbound announcement policies.
Cisco recommends that you have an in-depth understanding of BGP.
The information in this document is based on the fact that BGP peer groups have been supported in Cisco IOS® software since Cisco IOS Software Release 11.0.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
You can group BGP neighbors who share the same outbound policies together in what is called a BGP peer group. Instead of configuring each neighbor with the same policy individually, a peer group allows you to group the policies which can be applied to individual peers thus making efficient update calculation along with simplified configuration.
Peer groups have these requirements:
All members of a peer group must share identical outbound announcement policies (such as distribute-list, filter-list, and route-map), except for default-originate, which is handled on a per-peer basis even for peer group members.
You can customize the inbound update policy for any member of a peer group.
A peer group must be either internal (with internal BGP (iBGP) members) or external (with external BGP (eBGP) members). Members of an external peer group have different autonomous system (AS) numbers.
Cisco IOS Software Releases earlier than 11.1(18)CC have the limitations described in this section. Failure to adhere to these rules can result in inconsistent routing.
If you use peer groups for clients of a route reflector, all the clients must be fully meshed.
If you use an eBGP peer group, transit cannot be provided among the peer group members.
All eBGP peer group members must be from the same subnet to avoid non-connected next hop announcements.
However, these limitations were removed starting with Cisco IOS Software Releases 11.1(18)CC, 11.3(4), and 12.0. Only the router on which the peer groups are defined needs to be upgraded to the new code.
Note: Before you declare any device as a route-reflector-client using peer-group, you must first configure a neighborship with that device. Failure to do so results in the removal of the route-reflector-client from the configuration when a reboot is performed.
This behavior was first found in Cisco IOS Software Releases 12.0(25)S01 and 12.2(15)T02 and is corrected in Cisco IOS Software Release 12.2 and later.
Note: The total number of BGP peers and the configurable limit and the maximum number of established BGP peers that are supported on a router depends on many variables, such as:
Total number of routes in the BGP table
Level of stability of the routes
Number of routes sent to each peer
Similarity between routes sent to different neighbors
Devices available memory and processor power
Typically BGP peers on a router can be grouped into peer groups based on their outbound update policies. A list of peer-groups used commonly by ISPs are listed here:
Normal iBGP peer group for normal iBGP peers
iBGP client peer group for reflection peers on a route reflector
eBGP full-routes for peers to receive full Internet routes
eBGP customer-routes for peers to receive only routes from direct customers of the ISP. (You can configure some members with default-originate to receive the default route in addition to the customer routes.
eBGP default-routes for peers to receive the default route, and possibly a few other routes.
Refer to Configuring BGP for detailed examples of how to configure BGP peer groups.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.