Peer groups are used with the Border Gateway Routing Protocol (BGP) to reduce processor load by cutting down on the footprint of BGP updates. Additionally, peer groups trim the fat from BGP configurations.
For example, in the diagram below, the BGP-Router has five BGP neighbors to peer with. These neighbors will use the same BGP authentication key, ttl-security value, peer with the same AS and use the same interface to source peer establishment from; Peer groups will reduce the amount of syntax required for this task significantly. The routers in AS 321 are not using peer groups and are configured in a full-mesh as iBGP neighbors.
BGP-Router#show run | s bgp router bgp 100 no synchronization bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 123 neighbor 1.1.1.1 password C1sc0123 neighbor 1.1.1.1 ttl-security hops 2 neighbor 1.1.1.1 update-source Loopback0 neighbor 2.2.2.2 remote-as 123 neighbor 2.2.2.2 password C1sc0123 neighbor 2.2.2.2 ttl-security hops 2 neighbor 2.2.2.2 update-source Loopback0 neighbor 3.3.3.3 remote-as 123 neighbor 3.3.3.3 password C1sc0123 neighbor 3.3.3.3 ttl-security hops 2 neighbor 3.3.3.3 update-source Loopback0 neighbor 4.4.4.4 remote-as 123 neighbor 4.4.4.4 password C1sc0123 neighbor 4.4.4.4 ttl-security hops 2 neighbor 4.4.4.4 update-source Loopback0 neighbor 5.5.5.5 remote-as 123 neighbor 5.5.5.5 password C1sc0123 neighbor 5.5.5.5 ttl-security hops 2 neighbor 5.5.5.5 update-source Loopback0 network 11.11.11.0 mask 255.255.255.0 no auto-summary
Peer groups turn this laboriousness into F-U-N! (not really, but seriously…) The BGP neighbor configuration in this example is reduced from 16 lines to 10.
BGP-Router(config)#router bgp 123 BGP-Router(config-router)#neighbor PEERgroupNAME peer-group BGP-Router(config-router)#neighbor PEERgroupNAME password C1sc0123 BGP-Router(config-router)#neighbor PEERgroupNAME ttl-security hops 2 BGP-Router(config-router)#neighbor PEERgroupNAME update-source loopback 0 BGP-Router(config-router)#neighbor PEERgroupNAME remote-as 321 BGP-Router(config-router)#neighbor 1.1.1.1 peer-group PEERgroupNAME BGP-Router(config-router)#neighbor 2.2.2.2 peer-group PEERgroupNAME BGP-Router(config-router)#neighbor 3.3.3.3 peer-group PEERgroupNAME BGP-Router(config-router)#neighbor 4.4.4.4 peer-group PEERgroupNAME BGP-Router(config-router)#neighbor 5.5.5.5 peer-group PEERgroupNAME BGP-Router(config-router)#do show run | s bgp router bgp 123 no synchronization bgp log-neighbor-changes network 11.11.11.0 mask 255.255.255.0 neighbor PEERgroupNAME peer-group neighbor PEERgroupNAME remote-as 321 neighbor PEERgroupNAME password C1sc0123 neighbor PEERgroupNAME ttl-security hops 2 neighbor PEERgroupNAME update-source Loopback0 neighbor 1.1.1.1 peer-group PEERgroupNAME neighbor 2.2.2.2 peer-group PEERgroupNAME neighbor 3.3.3.3 peer-group PEERgroupNAME neighbor 4.4.4.4 peer-group PEERgroupNAME neighbor 5.5.5.5 peer-group PEERgroupNAME no auto-summary
We can use the “show ip bgp peer-group” command to verify current members.
BGP-Router#show ip bgp peer-group BGP peer-group is PEERgroupNAME, remote AS 321 BGP version 4 Default minimum time between advertisement runs is 30 seconds For address family: IPv4 Unicast BGP neighbor is PEERgroupNAME, peer-group external, members: 1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 5.5.5.5 Index 0, Offset 0, Mask 0x0 Update messages formatted 0, replicated 0 Number of NLRIs in the update sent: max 0, min 0
It is true that peer groups were created to use less processing power by cloning updates to group members. However, if we compare the the update behavior of R1, a router not using peer groups, to the BGP-Router, that is using peer groups, we see that IOS is sending a dynamic group update with both.
BGP-Router(config-router)#debug ip bgp updates *Mar 1 01:06:38.747: BGP(0): 1.1.1.1 send UPDATE (format) 11.11.11.0/24, next 6.6.6.6, metric 0, path Local *Mar 1 01:06:38.791: BGP(0): updgrp 1 - 1.1.1.1 updates replicated for neighbors: 2.2.2.2 3.3.3.3 4.4.4.4 5.5.5.5 R1(config-router)#debug ip bgp updates *Mar 1 01:06:38.747: BGP(0): 2.2.2.2 send UPDATE (format) 1.1.1.1/32, next 1.1.1.1, metric 0, path Local *Mar 1 01:06:38.791: BGP(0): updgrp 1 - 2.2.2.2 updates replicated for neighbors: 3.3.3.3 4.4.4.4 5.5.5.5
This dynamic group update feature was introduced in IOS 12.0(24)S to identify, and lump together, BGP neighbors sending out the same updates, all in an effort to reduce CPU overhead. You can read more about the dynamic group update feature on Cisco’s website.
Caveats:
Due to the cookie cutter nature of peer groups, we are limited with what we can accomplish. For example, if the BGP neighbors that we are peering with require some of the same policies, as well as a few different policies, we can only manually supersede the peer group configurations that don’t affect outbound updates.
BGP-Router(config)#do show run | s bgp [.........Relevant BGP Configuration.........] neighbor PEERgroupNAME peer-group neighbor PEERgroupNAME remote-as 321 neighbor PEERgroupNAME password C1sc0123 neighbor PEERgroupNAME ebgp-multihop 2 neighbor PEERgroupNAME update-source Loopback0 neighbor 4.4.4.4 peer-group PEERgroupNAME BGP-Router(config)#ip as-path access-list 6 deny _42_ BGP-Router(config)#ip as-path access-list 6 permit ^$ BGP-Router(config-router)#neighbor 4.4.4.4 filter-list 6 out % Invalid command for a peer-group member BGP-Router(config-router)#neighbor 4.4.4.4 filter-list 6 in BGP-Router(config-router)#
A more flexible and dynamic way to configure BGP peers is to use peer templates. Peer templates are hierarchical and overcome the limitations of peer groups with peer template inheritance.
