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.
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: *220.127.116.11 *18.104.22.168 *22.214.171.124 *126.96.36.199 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