Home Blog BGP peer groups, dynamic update peer groups and BGP templates

BGP peer groups, dynamic update peer groups and BGP templates

    BGP Peer GroupsAs 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.

    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.


    Boost BGP Preformance

    Automate BGP Routing optimization with Noction IRP

    BGP Demo

    NO COMMENTS

    Leave a Reply