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.
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