A BGP peer group is a group of BGP neighbors that share a common set of update policies. Update policies are usually defined by route maps, distribution lists, prefix lists, and filter lists. Instead of defining the same policies for each individual neighbor, you define a peer group name and assign policies to the peer group.
The network shown in Figure 11-3 demonstrates the use of BGP peer groups.
RTC forms similar internal peering sessions with RTD, RTE, and RTH. Instead of formulating and applying similar policies for each neighbor individually, RTC defines a peer group that contains the policies and configures all the internal neighbors as members of the peer group. Example 11-15 illustrates this.
router bgp 1 neighbor INTERNALMAP peer-group neighbor INTERNALMAP remote-as 1 neighbor INTERNALMAP route-map INTERNAL out neighbor INTERNALMAP filter-list 1 out neighbor INTERNALMAP filter-list 2 in neighbor 172.16.11.1 peer-group INTERNALMAP neighbor 172.16.13.1 peer-group INTERNALMAP neighbor 172.16.12.1 peer-group INTERNALMAP neighbor 172.16.12.1 filter-list 3 in |
The configuration in Example 11-15 defines a peer group called INTERNALMAP that contains the following policies. (Note that INTERNALMAP is an arbitrary name I've selected; it could be any string. Usually, a descriptive phrase is the most practical.)
A route map named INTERNAL
A filter list for outgoing updates (filter list 1)
A filter list for incoming updates (filter list 2)
The configuration applies the peer group to all internal neighbors—RTD, RTE, and RTH.
Members of a peer group inherit all the configuration options of the peer group. Peer group members can also be configured to override configuration options if the options do not affect outgoing updates. In other words, peer group members can be configured to override options that affect incoming policies. The configuration of RTC, for example, also defines a filter list 3 for incoming updates from the neighbor at IP address 172.16.12.1 (RTH). Filter list 3 will override any incoming policies set by the peer group INTERNALMAP for neighbor RTH.
Example 11-16 demonstrates how to configure a BGP peer group named EXTERNALMAP on RTC and apply it to the exterior neighbors in AS3 and AS2.
router bgp 1 neighbor EXTERNALMAP peer-group neighbor EXTERNALMAP route-map SETMED out neighbor EXTERNALMAP filter-list 1 out neighbor EXTERNALMAP filter-list 2 in neighbor 172.16.20.2 remote-as 3 neighbor 172.16.20.2 peer-group EXTERNALMAP neighbor 172.16.20.3 remote-as 2 neighbor 172.16.20.3 peer-group EXTERNALMAP neighbor 172.16.20.3 filter-list 3 in ip as-path access-list 1 permit ^$ |
In the configuration in Example 11-16, the neighbor remote-as router configuration commands are placed outside the neighbor peer-group router configuration commands because different external ASs have to be defined. Also note that this configuration defines filter list 3, which can be used to override configuration options for incoming updates from the neighbor at IP address 172.16.20.3 (RTF).
The following two paragraphs apply only to older IOS versions; these are not restrictions of newer versions.
Note that the external BGP neighbors RTA and RTF that belong in the same peer group EXTERNALMAP were taken from the same subnet, 172.16.20.0. This restriction is needed to prevent loss of information. Placing the external neighbors in different subnets could result in RTC's sending updates to its neighbors (RTA and RTF) with a nonconnected next-hop IP address. These updates would be dropped due to the normal EBGP behavior of ignoring routes with nonconnected next hop (remember that ebgp-multihop was implemented to override this behavior).
Another restriction that applies is that peer groups should not be set on EBGP neighbors if the router is acting as a transit between those neighbors. If the router (RTC) is passing updates from one external neighbor to the other, placing external neighbors in peer groups might result in routes being mistakenly removed. Note that filter list 1 has been defined to allow AS1's local routes only to be sent to neighbors RTA and RTF. This way, RTC will not act as a transit router between RTA and RTF.
Predefined peer groups can ease configuration tasks (while decreasing error probability) when bringing up new peers. They can also significantly decrease the size of BGP configurations in the router. In addition, BGP UPDATE messages are generated only once for members of a peer group and then are copied to all the peers, potentially preserving a considerable amount of CPU resources versus what would be required to generate each UPDATE individually.