As a router gains more and more BGP neighbors, two issues arise. The first one is that with
many neighbors, whenever the router needs to send out a BGP update, it has to create an
update message for each neighbor. Second, the BGP configuration can get quite long and
unwieldy. BGP peer groups were the original solution to both problems. Later, the same two
problems were tackled slightly differently with dynamic update peer groups and BGP
templates.
First, let’s look at peer groups. Peer groups have been around for a long time, so it’s safe to
assume all Cisco routers and other routers that use a similar configuration style support
them. And often the limitations of peer groups are not problematic, so they can still be
useful. Suppose we have the following configuration towards an ISP:
! router bgp 65000 network 192.0.2.0/24 neighbor 10.0.75.21 remote-as 65030 neighbor 10.0.75.21 description ISP A link to their R1 neighbor 10.0.75.21 password 12345 neighbor 10.0.75.21 prefix-list only-our-prefix out neighbor 10.0.75.21 filter-list only-our-as out neighbor 10.0.75.25 remote-as 65030 neighbor 10.0.75.25 description ISP A link to their R2 neighbor 10.0.75.25 password 12345 neighbor 10.0.75.25 prefix-list only-our-prefix out neighbor 10.0.75.25 filter-list only-our-as out !
Astute readers will observe that the configuration for neighbors 10.0.75.21 and 10.0.75.25 is identical, except for the description. Using a peer group will make this more readable:
! router bgp 65000 network 192.0.2.0/24 neighbor ispa peer-group neighbor ispa remote-as 65030 neighbor ispa description ISP A neighbor ispa password 12345 neighbor ispa prefix-list only-our-prefix out neighbor ispa filter-list only-our-as out neighbor 10.0.75.21 peer-group ispa neighbor 10.0.75.21 description ISP A link to their R1 neighbor 10.0.75.25 peer-group ispa neighbor 10.0.75.25 description ISP A link to their R2 !
The first neighbor that is defined here is a peer group, as is immediately obvious from the fact that this neighbor has a name rather than an address. That name is followed by the statement “peer-group”. Then, we can assign settings to the peer group as usual for any neighbor.
After the peer group is done, we define two actual neighbors. Normally, the first thing we need to specify for a BGP neighbor is the remote AS. Instead, we refer to the previously created peer group, so the remote AS specified there is used, along with all other settings specified for the peer group. The result is as follows:
Router# show ip bgp 192.0.2.0/24
BGP routing table entry for 192.0.2.0/24, version 6
Advertised to peer-groups:
ispa
With the previous non peer group configuration, this looked slightly differently:
Router#s how ip bgp 192.0.2.0/24 BGP routing table entry for 192.0.2.0/24, version 3 Advertised to non peer-group peers: 10.0.75.21 10.0.75.25
The output above reflects the difference in behavior with and without peer groups. Without any peer groups, the router generates a separate BGP Update message for each neighbor that needs to get the update. When neighbors are part of a peer group, the router just generates one Update message for that set of neighbors and sends copies of that single Update message to all members of the peer group. With many neighbors and complex filters, this can save a lot of work for the router.
It is possible to overrule settings inherited from a peer group. For instance, if we add a BGP session towards a third router to our peer group configuration example, but this BGP session has a different MD5 password, the additions could look as follows:
! router bgp 65000 neighbor 10.0.75.29 peer-group ispa neighbor 10.0.75.29 description ISP A link to their R3 neighbor 10.0.75.29 password 67890 !
So neighbors 10.0.75.21 and 10.0.75.25 inherit the password setting from the peer group, but for 10.0.75.29 the “neighbor 10.0.75.29 password 67890” line overrules peer group password setting.
Because the router must be able to send the same Update messages to all peer group members, outgoing filters and route maps must be shared by all peer group members. So those need to be part of the peer group configuration and can’t be set for individual members. However, it’s perfectly fine to have separate incoming filters and route maps for different neighbors, and have those overrule the ones set for the peer group.
Some additional complexity arises when we use peer groups with IPv6. Peer groups can have session related settings, such as the remote AS and the MD5 password, but also address family related settings, such as filters and route maps. When applying a peer group to a neighbor in the BGP configuration, that peer group is applied to the session settings as well the address family IPv4 settings. The peer group does not automatically apply to the address family IPv6 settings.
This means that for eBGP sessions, it’s necessary to have different peer groups for IPv4 neighbors and IPv6 neighbors, because with the same peer group, it wouldn’t be possible to deactivate IPv4 for the IPv6 neighbors without also deactivating IPv4 for the IPv4 neighbors (which would be an unusual configuration, to say the least).
It’s best to not exchange IPv6 prefixes over an IPv4 eBGP session or the other way around because this can get in the way of properly updating the next hop address. With iBGP, the next hop address isn’t updated, so here there is no trouble exchanging IPv6 prefixes over IPv6. That could look like this:
! router bgp 65000 neighbor ibgp peer-group neighbor ibgp remote-as 65000 neighbor ibgp password 12345 neighbor 203.0.113.75 peer-group ibgp neighbor 203.0.113.77 peer-group ibgp ! address-family ipv6 neighbor ibgp activate neighbor 203.0.113.75 peer-group ibgp neighbor 203.0.113.77 peer-group ibgp exit-address-family exit !
However, the configuration would be shorter (granted, only by a single line) by not using a peer group in the address-family ipv6 part:
! address-family ipv6 neighbor 203.0.113.75 activate neighbor 203.0.113.77 activate exit-address-family exit !
These days, it’s no longer necessary to explicitly create peer groups for performance reasons. Instead, Cisco routers automatically create dynamic update peer groups that allow the router to send the same Update message to multiple neighbors if the outgoing policies for multiple neighbors are the same. This results in the following output:
Router# show ip bgp 192.0.2.0/24
BGP routing table entry for 192.0.2.0/24, version 8
Advertised to update-groups:
2
There is no need to configure dynamic update peer groups, they are created and maintained automatically. However, it helps to use the same filters and route maps for multiple neighbors where possible to allow the router to create the dynamic update peer groups.
With the performance aspects covered by dynamic update peer groups, BGP templates replace the configuration simplification aspect of peer groups. A BGP template version of the second example above would look like this:
! router bgp 65000 template peer-policy ispa-filters prefix-list only-our-prefix out filter-list only-our-as out exit-peer-policy ! template peer-session ispa-session remote-as 65030 description ISP A password 12345 exit-peer-session ! neighbor 10.0.75.21 inherit peer-session ispa-session neighbor 10.0.75.21 inherit peer-policy ispa-filters neighbor 10.0.75.21 description ISP A link to their R1 neighbor 10.0.75.25 inherit peer-session ispa-session neighbor 10.0.75.25 inherit peer-policy ispa-filters neighbor 10.0.75.25 description ISP A link to their R2 neighbor 10.0.75.29 inherit peer-session ispa-session neighbor 10.0.75.29 inherit peer-policy ispa-filters neighbor 10.0.75.29 description ISP A link to their R3 neighbor 10.0.75.29 password 67890 !
There’s now a clean separation of the session and the policy configuration. Policy templates are address family specific. A template may inherit settings from another template, to a maximum depth of eight templates total. Higher levels can overrule settings in lower level, deeper nested templates. An iBGP example could look like this:
! router bgp 65000 template peer-session ibgp remote-as 65000 password 12345 exit-peer-session ! template peer-session ibgp-east description iBGP sessions to routers East inherit peer-session ibgp exit-peer-session ! template peer-session ibgp-west description iBGP sessions to routers West inherit peer-session ibgp exit-peer-session ! neighbor 203.0.113.71 inherit peer-session ibgp-east neighbor 203.0.113.73 inherit peer-session ibgp-east neighbor 203.0.113.75 inherit peer-session ibgp-west neighbor 203.0.113.77 inherit peer-session ibgp-west ! address-family ipv6 neighbor 203.0.113.75 activate neighbor 203.0.113.77 activate exit-address-family exit !
This configuration makes it very easy to shut down a group of BGP sessions, for instance, in preparation for maintenance:
! router bgp 65000 template peer-session ibgp-east shutdown exit-peer-session ! !
Afterwards, we can then bring all the sessions back up again:
! router bgp 65000 template peer-session ibgp-east no shutdown exit-peer-session ! !
This shows the advantage of inheritance that BGP templates provide: we can now still change settings for all iBGP neighbors in one place, under the ibgp template, while we can also change settings for a subset of iBGP neighbors.