BGP peer group vs. BGP templates

Most people who have done a little more than basic BGP configuration have encountered BGP peer groups. These groups help you manage larger configurations, or at least that is what you’ve been told.

BGP peer groups are not designed to manage large BGP configurations. That’s what BGP templates are for. But if that’s the case what are the peer groups used for? And what’s the difference between the two? This post will answer exactly those questions.

BGP peer groups

We will start with the peer groups. To explain the difference and the goals of both peer groups and templates we have to explore them both. Let’s start with the solution most people know.

BGP update process

Originally (before IOS 12.0) when a router needed to create updates for a neighbor it would scan its BGP table. Out of every prefix a NLRI would be created and these NLRIs would be put into updates (multiple packets if the update is large). For a router with 1000 prefixes and 10 neighbors this could lead to the generation of 10000 NLRIs, many of which would be duplicates of each other. Imagine this for a RIB containing over 500.000 prefixes and a BGP process with hundreds of peers. The router would fail due to CPU and memory limits.

All neighbors with identical outgoing policies would receive the same NLRIs. This led Cisco to create peer groups. All neighbors within a peer group have the same outgoing policy (and thus the same NLRIs). By configuring these neighbors in a group the router knew it only had to generate the NLRIs once and send them to all routers in the peer group. In the example of 1000 prefixes and 10 neighbors, if these neighbors could be grouped into two peer groups only 2000 NLRIs had to be generated.

Since IOS version 12 manual peer group configuration is no longer necessary to achieve this optimization. IOS is capable of recognizing neighbors with the same outbound policy. These are then grouped together automatically. This is a feature called Dynamic Update Peer Groups.

Ease of configuration

So Cisco introduced the peer-group command. This command had another benefit, it made for easier configuration. If you used to have 10 neighbors, all of which had the same outbound policy. You would need to configure the outbound policy for all 10 neighbors separately. Using a peer group you can configure the policy once and ensure the neighbors are configured as member of the peer group. This creates a smaller and more readable configuration.

This benefit is the most well known. This is probably why you and the people you know use peer groups.

The ease of configuration never was the primary goal for Cisco to introduce peer groups. So when using peer groups you might find some weird restrictions and configurations that aren’t as optimized as they could be. Remember the goal for these peer groups; to reduce the CPU and memory burden on the routers running large scale BGP. BGP templates are designed to streamline the configuration and should be used instead of peer groups for that purpose.

So, IOS automatically performs optimization. Templates take care of configuration efficiency. Are peer groups useless? No, not completely. For starters many administrators still prefer peer groups over templates. Templates are more flexible and are designed for configuration streamlining, but are aimed at really big environments. Furthermore, many administrators never learned to use templates, so they’re not using them. A last reason to keep using peer groups are dynamic neighbors, which we will cover in the next section.

Dynamic Neighbors

Say for example you’re the administrator of a route reflector service at a growing internet exchange. You get requests from customers on a regular basis to add a new neighbor to your route reflector. Of course the route reflector isn’t the only thing you’re responsible for, so you want to do as little as possible. Preferrably just set up the route reflector once, and let the customers create automatic peerings without any configuration on your part. This is exactly what the dynamic neighbors feature does.

You configure an IP range and any BGP speaker in this range that complies to the policy will automatically become a neighbor. You define this policy using a peer group. See the configuration example below.

router bgp 65000
 bgp log-neighbor-changes
 bgp listen range 0.0.0.0/0 peer-group iBGP
 neighbor iBGP peer-group
 neighbor iBGP remote-as 65000
 neighbor iBGP update-source Loopback0
 neighbor iBGP route-reflector-client
 neighbor iBGP password IBGP_PASSWORD

This configuration example allows for peers from the whole internet (0.0.0.0/0) to connect to the route reflector and become a client if they know the password.

This is currently one of very few reasons to use peer groups.

R3#show ip bgp peer-group iBGP
BGP peer-group is iBGP,  remote AS 65000
  BGP peergroup iBGP listen range group members: 
  0.0.0.0/0 
  BGP version 4
  Neighbor sessions:
    0 active, is not multisession capable (disabled)
  Do log neighbor state changes (via global configuration)
  Default minimum time between advertisement runs is 0 seconds

 For address family: IPv4 Unicast
  BGP neighbor is iBGP, peer-group internal, members:
  *1.1.1.1 *2.2.2.2 *6.6.6.6 *7.7.7.7 
  Index 0, Advertise bit 0
  Route-Reflector Client
  Update messages formatted 0, replicated 0
  Number of NLRIs in the update sent: max 0, min 0

BGP Peer templates

Cisco introduced peer templates along with BGP Dynamic update groups. They knew administrators used the peer groups as a way to simplify configuration. Because of this they needed something to do exactly that, but more flexible.

The flexibility of peer templates is the biggest advantage over peer groups. You can use a base template for all peers, but use specific templates and inherit other templates for other peers. This enables an administrator to create complex nested policies.

For this post we’ll keep it simple.

Peer templates are divided in two parts:

  • Peer Policy Templates
  • Peer Session Templates

Peer Policy Templates

The peer policy templates are all the things you configure for the policy between peers. Examples are route-maps, advertise-maps etc. Listed below is the complete list (IOS 15.6)

  accept-route-legacy-rt  Accept Legacy Route Target
  additional-paths        Negotiate additional paths capabilities with this
                          neighbor
  advertise               Advertise to this neighbor
  advertise-map           specify route-map for conditional advertisement
  advertisement-interval  Minimum interval between sending BGP routing updates
  aigp                    Enable a AIGP on neighbor
  allow-policy            Enable the policy support for this IBGP Neighbor
  allowas-in              Accept as-path with my AS present in it
  as-override             Override matching AS-number while sending update
  capability              Advertise capability to the peer
  default                 Set a command to its defaults
  default-originate       Originate default route to this neighbor
  distribute-list         Filter updates to/from this neighbor
  dmzlink-bw              Propagate the DMZ link bandwidth
  exit-peer-policy        Exit from template configuration mode
  filter-list             Establish BGP filters
  inherit                 Inherit a template
  inter-as-hybrid         Inter AS Hybrid mode
  internal-vpn-client     Stack iBGP-CE Neighbor Path in ATTR_SET for vpn
                          update
  maximum-prefix          Maximum number of prefixes accepted from this peer
  next-hop-self           Disable the next hop calculation for this neighbor
  next-hop-unchanged      Propagate next hop unchanged for iBGP paths to this
                          neighbor
  no                      Negate a command or set its defaults
  prefix-length-size      Packet Level storage size for Prefixes
  prefix-list             Filter updates to/from this neighbor
  remove-private-as       Remove private AS number from outbound updates
  route-map               Apply route map to neighbor
  route-reflector-client  Configure a neighbor as Route Reflector client
  route-server-client     Configure a neighbor as Route Server client
  send-community          Send Community attribute to this neighbor
  send-label              Send NLRI + MPLS Label to this peer
  slow-peer               Configure slow-peer
  soft-reconfiguration    Per neighbor soft reconfiguration
  soo                     Site-of-Origin extended community
  translate-topology      Translate topology id
  unsuppress-map          Route-map to selectively unsuppress suppressed routes
  validation              Validation of flowspec paths
  weight                  Set default weight for routes from this neighbor

Peer session Templates

A peer session template is used to configure things like the remote-as and the update-source. Basically everything you need to set up a BGP session. Again, listed below is the complete list.

BGP peer-policy configuration commands:
  bmp-activate             Activate the BMP monitoring for a BGP peer
  cluster-id               Configure Route-Reflector Cluster-id (peers may
                           reset)
  default                  Set a command to its defaults
  description              Neighbor specific description
  disable-connected-check  one-hop away EBGP peer using loopback address
  ebgp-multihop            Allow EBGP neighbors not on directly connected
                           networks
  exit-peer-session        Exit from template configuration mode
  fall-over                session fall on peer route lost
  ha-mode                  high availability mode
  inherit                  Inherit a template
  local-as                 Specify a local-as number
  no                       Negate a command or set its defaults
  password                 Set a password
  path-attribute           BGP optional attribute filtering
  remote-as                Specify a BGP neighbor
  shutdown                 Administratively shut down this neighbor
  timers                   BGP per neighbor timers
  transport                Transport options
  ttl-security             BGP ttl security check
  update-source            Source of routing updates
  version                  Set the BGP version to match a neighbor

Peer templates configuration example

Ok, so you have a list of all the configuration commands available in templates. How do we tie these things together? So for this post I’m working with a very simple topology. I’ve got 4 routers, R1 to R4. These are connected in a hub spoke topology with R1 as hub. This topology is shown in the image below.

Topology

All BGP connections will be between R1 and the other routers. R2, R3 and R4 will not create any BGP peerings between them as it’s not necessary for the example. To show the flexibility of templates we’ll configure all BGP sessions with ttl-security. Only the session between R1 and R4 will be authenticated using a password of cisco. We’ll let the peer session template be the same for all peerings, but in real life this doesn’t have to be the case.

R1:
router bgp 100
 template peer-policy PP_MASTER
  send-community both
 exit-peer-policy
 !
 template peer-session PS_MASTER
  ttl-security hops 1
 exit-peer-session
 !
 template peer-session PS_AS400
  password cisco
  inherit peer-session PS_MASTER
 exit-peer-session
 !
 neighbor 192.168.21.2 remote-as 200
 neighbor 192.168.21.2 inherit peer-session PS_MASTER
 neighbor 192.168.21.2 inherit peer-policy PP_MASTER
 neighbor 192.168.31.3 remote-as 300
 neighbor 192.168.31.3 inherit peer-session PS_MASTER
 neighbor 192.168.31.3 inherit peer-policy PP_MASTER
 neighbor 192.168.41.4 remote-as 400
 neighbor 192.168.41.4 inherit peer-session PS_AS400
 neighbor 192.168.41.4 inherit peer-policy PP_MASTER

R2:
router bgp 200
 bgp log-neighbor-changes
 neighbor 192.168.21.1 remote-as 100
 neighbor 192.168.21.1 ttl-security hops 1

R3:
router bgp 300
 bgp log-neighbor-changes
 neighbor 192.168.31.1 remote-as 100
 neighbor 192.168.31.1 ttl-security hops 1

R4:
router bgp 400
 bgp log-neighbor-changes
 neighbor 192.168.41.1 remote-as 100
 neighbor 192.168.41.1 password cisco
 neighbor 192.168.41.1 ttl-security hops 1

This configuration creates several templates. The peer-session template PS_AS400 is specific for AS 400. This AS requires password authentication with the password cisco. All sessions require ttl-security, so that is configured in the PS_MASTER template. PS_AS400 inherits the PS_MASTER template. This way it also gets the ttl-security setting.

For a network with 3 peers this is a bit overkill, but think about setting up peering with 25 or 250 peers. Using templates can save a lot of configuration.

Because the policy for all neighbors is the same all three neighbors on R1 are automatically grouped into a single update group. This can be seen with the show ip bgp update-group command.

R1#show ip bgp update-group 
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
  BGP Update version : 1/0, messages 0
  Community attribute sent to this neighbor
  Extended-community attribute sent to this neighbor
  Topology: global, highest version: 1, tail marker: 1
  Format state: Current working (OK, last not in list)
                Refresh blocked (not in list, last not in list)
  Update messages formatted 0, replicated 0, current 0, refresh 0, limit 1000
  Number of NLRIs in the update sent: max 0, min 0
  Minimum time between advertisement runs is 30 seconds
  Has 3 members:
   192.168.21.2     192.168.31.3     192.168.41.4    

Just to show that IOS creates update groups based on equal policy, let’s say we want to apply as-path prepending to as 300. We configure this in our policy, but we’ll need a new template for this as currently all neighbors have the same policy template.

 template peer-policy PP_AS300
  route-map SET_AS_PREPEND out
  inherit peer-policy PP_MASTER 1
 exit-peer-policy
 neighbor 192.168.31.3 inherit peer-policy PP_AS300
!
route-map SET_AS_PREPEND permit 10
 set as-path prepend 100 100 100

R1(config-router)#do sh ip bgp update-group
BGP version 4 update-group 4, external, Address Family: IPv4 Unicast
  BGP Update version : 1/0, messages 0
  Community attribute sent to this neighbor
  Extended-community attribute sent to this neighbor
  Topology: global, highest version: 1, tail marker: 1
  Format state: Current working (OK, last not in list)
                Refresh blocked (not in list, last not in list)
  Update messages formatted 0, replicated 0, current 0, refresh 0, limit 1000
  Number of NLRIs in the update sent: max 0, min 0
  Minimum time between advertisement runs is 30 seconds
  Has 2 members:
   192.168.21.2     192.168.41.4    

BGP version 4 update-group 5, external, Address Family: IPv4 Unicast
  BGP Update version : 1/0, messages 0
  Community attribute sent to this neighbor
  Extended-community attribute sent to this neighbor
  Route map for outgoing advertisements is SET_AS_PREPEND
  Topology: global, highest version: 1, tail marker: 1
  Format state: Current working (OK, last not in list)
                Refresh blocked (not in list, last not in list)
  Update messages formatted 0, replicated 0, current 0, refresh 0, limit 1000
  Number of NLRIs in the update sent: max 0, min 0
  Minimum time between advertisement runs is 30 seconds
  Has 1 member:
     192.168.31.3