When you configure BGP on a router it’s possible that some of the BGP neighbors share the exact same configuration. This can be annoying since you have to type in the exact same commands for each of these neighbors. Also, when BGP prepares updates it does this separately for each neighbor. This means that it has to use CPU resources to prepare the update for each neighbor.
To simplify the configuration of BGP and to reduce the number of updates BGP has to create, we can use peer groups. We can add neighbors to a peer group and then apply all our configurations to the peer group. BGP will prepare the updates for the peer group which requires less CPU resources than preparing them for each neighbor separately.
Let’s take a look at two examples so you can see the difference between using peer groups or not. I’ll use the following topology to demonstrate this:
Above we have 4 routers in different autonomous systems. R1 is connected to R2, R3 and R4. Let’s say that we have the following requirements for these eBGP neighbors:
- Use eBGP multihop and source updates from the loopback interface.
- Set the default metric (MED) to 2323.
Let’s start with the example without the peer group…
I am using loopback interfaces for the neighbor adjacency so don’t forget to add some static routes:
R1(config)#ip route 18.104.22.168 255.255.255.255 192.168.12.2 R1(config)#ip route 22.214.171.124 255.255.255.255 192.168.13.3 R1(config)#ip route 126.96.36.199 255.255.255.255 192.168.14.4
R2(config)#ip route 188.8.131.52 255.255.255.255 192.168.12.1
R3(config)#ip route 184.108.40.206 255.255.255.255 192.168.13.1
R4(config)#ip route 220.127.116.11 255.255.255.255 192.168.14.1
And here s the route-map to set the MED:
R1(config)#route-map SET_MED permit 10 R1(config-route-map)#set metric 2323
Without BGP Peer Group
Here’s what our BGP configuration on R1 would look like:
R1(config)#router bgp 1 R1(config-router)#neighbor 18.104.22.168 remote-as 2 R1(config-router)#neighbor 22.214.171.124 remote-as 3 R1(config-router)#neighbor 126.96.36.199 remote-as 4 R1(config-router)#neighbor 188.8.131.52 update-source loopback 0 R1(config-router)#neighbor 184.108.40.206 update-source loopback 0 R1(config-router)#neighbor 220.127.116.11 update-source loopback 0 R1(config-router)#neighbor 18.104.22.168 ebgp-multihop 2 R1(config-router)#neighbor 22.214.171.124 ebgp-multihop 2 R1(config-router)#neighbor 126.96.36.199 ebgp-multihop 2 R1(config-router)#neighbor 188.8.131.52 route-map SET_MED out R1(config-router)#neighbor 184.108.40.206 route-map SET_MED out R1(config-router)#neighbor 220.127.116.11 route-map SET_MED out
In the configuration of R1 above the only difference is the AS number for each neighbor. The update-source, ebgp-multihop and route-map are the same. This works but we have to repeat the same commands over and over again.
With BGP Peer Group
Let’s simplify the configuration of R1 with our peer group. I will start with a fresh BGP configuration on R1.
First we have to configure the AS number for each eBGP neighbor separately:
R1(config)#router bgp 1 R1(config-router)#neighbor 18.104.22.168 remote-as 2 R1(config-router)#neighbor 22.214.171.124 remote-as 3 R1(config-router)#neighbor 126.96.36.199 remote-as 4
Now we can create the peer group. If you look at the neighbor command you will see some options:
R1(config-router)#neighbor ? A.B.C.D Neighbor address WORD Neighbor tag X:X:X:X::X Neighbor IPv6 address
We can specify an IPv4 or IPv6 address for the neighbor or we can use a tag. That’s what we need to use for the peer group, let’s try that:
Great explanation. Peer groups saves a lot of time and headache. Thanks
CCIE R&S - in progress
I think that in configuration there is missing a static route to each of the peer’s loopback addresses.
That’s right, this example only shows a “before” and “after” of using peer groups. You will need static routes to reach the loopback addresses of the remote peers.
how does this reduce CPU cycle by means of BGP updates ? only the configuration command got collapsed but the functionality remains the same right ?
The functionality remains the same but behind the scenes, something is different. Imagine you have 100 BGP neighbors…they all have the same configuration. Without peer groups, the router will have to generate an update for each neighbor, one-by-one.
With peer groups, the update is generated only once for the peer group. For each neighbor, we only have to replicate the update…that’s it. That saves some CPU cycles on the router.
I have to say that most routers also support BGP Dynamic Update Peer-Groups. This means that routers will automatically try to... Continue reading in our forum