A concept known as the update group was developed to make BGP processing more efficient. Under the default settings, BGP creates and sends routing updates to each neighbor individually. For example, if a router had four neighbors, the router would generate and transmit the routing update four times, even if all four neighbors received identical advertisements. With an update group, you instruct the router that all of these neighbors will receive the same advertisements. The router will thus generate the update once and transmit it four times.
Let’s take this concept further with dynamic peer-groups, also called update groups. The members of these dynamic peer groups are calculated by the IOS in real-time, without the need for specific, explicit configuration. The grouping criteria are simple: neighbors with the same type (internal or external) and identical outbound policies are grouped together. The outbound policies are determined by the same set of outbound prefix lists, ACLs, AS-path lists, and/or route-maps.
Consider the following CLI configuration:
ip prefix-list PL1 seq 5 permit 0.0.0.0/0 le 32 ip prefix-list PL2 seq 5 permit 0.0.0.0/0 le 32 ip as-path access-list 1 permit .* router bgp 1 no synchronization bgp log-neighbor-changes network 203.0.113.0 neighbor 10.100.0.1 remote-as 1 neighbor 10.100.0.2 remote-as 1 neighbor 10.100.0.3 remote-as 1 neighbor 10.100.0.4 remote-as 2 no auto-summary
We have four neighbors in this configuration—three iBGP and one eBGP. When you input `show ip bgp update-group`, it returns that there are two update groups. The first update group consists of all iBGP neighbors, and the second group comprises my eBGP neighbors. This distribution is due to the identical updates towards the iBGP neighbors (with no outbound policies specified), while the eBGP neighbor receives different updates due to AS_PATH and NEXT_HOP manipulation in eBGP.
Now let’s look at a different scenario. Suppose you assign the peers at 10.100.0.1 and 10.100.0.2 an outbound prefix list P1. Now the set of all neighbors is partitioned into three subsets: 10.100.0.1 and 10.100.0.2 are internal and use prefix-list P1, 10.100.0.3 is internal without a prefix list, and 10.100.0.4 is external without a prefix list.
router bgp 1 no synchronization bgp log-neighbor-changes network 203.0.113.0 neighbor 10.100.0.1 remote-as 1 neighbor 10.100.0.1 prefix-list P1 out neighbor 10.100.0.2 remote-as 1 neighbor 10.100.0.2 prefix-list P1 out neighbor 10.100.0.3 remote-as 1 neighbor 10.100.0.4 remote-as 2 no auto-summary
The dynamic update peer groups are recalculated due to the changed outbound policies. The new `show ip bgp update-group` will show this shift, highlighting which outbound policy is used, in this case, prefix-list P1.
Interestingly, the IOS computation is simple—it refers merely to the names of prefix lists, ACLs, AS-path ACLs, and route-maps in the neighbor commands to determine if multiple neighbors use the same outbound route manipulations. My two prefix lists, P1 and P2, are identical, but their names are different.
If I configure the 10.100.0.1 to use P1 while the 10.100.0.2 is configured with P2, the IOS will split them into two separate update groups because the names of the prefix lists are different, even though the prefix lists yield the same results:
router bgp 1 no synchronization bgp log-neighbor-changes network 203.0.113.0 neighbor 10.100.0.1 remote-as 1 neighbor 10.100.0.1 prefix-list P1 out neighbor 10.100.0.2 remote-as 1 neighbor 10.100.0.2 prefix-list P2 out neighbor 10.100.0.3 remote-as 1 neighbor 10.100.0.4 remote-as 2 no auto-summary
The updated `show ip bgp update-group` would show that the neighbors are now split into four subsets: 10.100.0.1 (internal using P1), 10.100.0.2 (internal using P2), 10.100.0.3 (internal without a prefix list), and 10.100.0.4 (external without a prefix list). The update groups 2 and 4 now reference the prefix-lists P1 and P2, respectively, clarifying their outbound policies.
To further illustrate, if we assume 10.100.0.1 is using just P1 and both 10.100.0.2 and 10.100.0.3 are using P1 and AS-path ACL 1, this will again segregate the neighbors into three subsets, demonstrating how outbound policies are tied to the grouping of the neighbors.
router bgp 1 no synchronization bgp log-neighbor-changes network 203.0.113.0 neighbor 10.100.0.1 remote-as 1 neighbor 10.100.0.1 prefix-list P1 out neighbor 10.100.0.2 remote-as 1 neighbor 10.100.0.2 prefix-list P1 out neighbor 10.100.0.2 filter-list 1 out neighbor 10.100.0.3 remote-as 1 neighbor 10.100.0.3 prefix-list P1 out neighbor 10.100.0.3 filter-list 1 out neighbor 10.100.0.4 remote-as 2 no auto-summary
It’s now apparent that driven by the outbound policies; IOS has categorized the BGP neighbors into three renewed groups. Update group 2 is exclusive to 10.100.0.1, utilizing prefix-list P1. Update group 3 houses the eBGP peer at 10.100.0.4. Finally, Update group 4 consists of the iBGP peers at 10.100.0.2 and 10.100.0.3, both applying prefix-list P1 and AS path ACL 1.
In conclusion, by leveraging update groups, the BGP can dynamically compute members and adjust to changes in outbound policies seamlessly. This mechanism enhances the efficiency and flexibility of BGP routing.