BGP peer groups, dynamic update peer groups and BGP templates

Peer groups

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
!

Dynamic update peer groups

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.

BGP templates

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.