01-11-2013 08:06 PM - edited 03-07-2019 11:03 AM
Hi everybody
I am trying to understand what is " update group " and " 2" in output below:
R1#show ip bgp 120.120.120.0/24
BGP routing table entry for 120.120.120.0/24, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
1
2.2.2.2 (metric 1) from 2.2.2.2 (20.20.20.2)
Origin IGP, metric 0, localpref 100, valid, external, best
R1#
Thanks for help and have a great a weekend.
Solved! Go to Solution.
01-11-2013 09:07 PM
The concept of update group was developed to help BGP processing be more efficient. By default BGP processing creates the routing updates for each neighbor separately and independently. So if a router had 4 neighbors then it would go through the process of creating and sending the routing update 4 times - even if all 4 neighbors get exactly the same advertisements. With update group you are telling the router that each of these neighbors gets the same advertisements. So the router generates the update one time and transmits 4 times.
HTH
Rick
Sent from Cisco Technical Support iPad App
01-12-2013 04:24 AM
In addition to what Rick said, you can also see who these update groups are with "show ip bgp update-group
HTH,
John
*** Please rate all useful posts ***
01-12-2013 06:50 AM
Hello Sarah,
In addition to excellent Rick's response, let me add that these "update groups" are also called dynamic peer-groups, or dynamic update peer-groups because their members are computed by IOS on the fly, without any specific explicit configuration.
While the documentation is not very specific on how these dynamic update groups are computed, the algorithm is fairly easy: you group together all neighbors that have the same type (internal or external) and which have the same outbound policies. Now, the "same outbound policies" criterion is again very simple: those are all neighbors that are configured with the same set of outbound prefix lists, ACLs, AS-path lists and/or route-maps.
Consider this 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 192.0.2.0
neighbor 10.0.0.2 remote-as 1
neighbor 10.0.0.3 remote-as 1
neighbor 10.0.0.4 remote-as 1
neighbor 10.0.0.5 remote-as 2
no auto-summary
In this configuration, just 4 neighbors, 3 iBGP and 1 eBGP, the show ip bgp update-group says:
R1#show ip bgp update-group
BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 1, replicated 2
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 3 members (* indicates the members currently being sent updates):
10.0.0.2 10.0.0.3 10.0.0.4
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 2, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.5
Notice that there are 2 update groups identified. The first update group currently holds all my iBGP neighbors and the second update group holds my eBGP neighbors - clearly because the updates towards the iBGP neighbors are the same (no outbound policies specified), while the eBGP neighbor gets to receive different updates (the AS_PATH and NEXT_HOP manipulation in eBGP, at least).
Imagine now that I configure the 10.0.0.2 and 10.0.0.3 peers with an outbound prefix list P1. This partitions the set of all neighbors into three subsets: 10.0.0.2 and 10.0.0.3 internal using prefix-list P1, 10.0.0.4 internal without a prefix-list, 10.0.0.5 external without a prefix list.
router bgp 1
no synchronization
bgp log-neighbor-changes
network 192.0.2.0
neighbor 10.0.0.2 remote-as 1
neighbor 10.0.0.2 prefix-list P1 out
neighbor 10.0.0.3 remote-as 1
neighbor 10.0.0.3 prefix-list P1 out
neighbor 10.0.0.4 remote-as 1
neighbor 10.0.0.5 remote-as 2
no auto-summary
Now, the show ip bgp update-group says:
BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 2, replicated 2
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.4
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P1
Update messages formatted 1, replicated 1
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 2 members (* indicates the members currently being sent updates):
10.0.0.2 10.0.0.3
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 3, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.5
The dynamic update peer-groups have been recalculated as a result of changed outbound policies. Note that the description of the update-group 2 also explains what kind of outbound policy is used - in this case, the prefix-list P1.
Note that the computation in IOS is very simple, referring simply to the names of prefix-lists, ACLs, as-path ACLs and route-maps in the neighbor commands to know if multiple neighbors are using the same set of outbound route manipulations. Note that my two prefix-lists, P1 and P2, are identical, but their names are different. If I configure the 10.0.0.2 to use P1 while the 10.0.0.3 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 produce identical results:
router bgp 1
no synchronization
bgp log-neighbor-changes
network 192.0.2.0
neighbor 10.0.0.2 remote-as 1
neighbor 10.0.0.2 prefix-list P1 out
neighbor 10.0.0.3 remote-as 1
neighbor 10.0.0.3 prefix-list P2 out
neighbor 10.0.0.4 remote-as 1
neighbor 10.0.0.5 remote-as 2
no auto-summary
And the corresponding show ip bgp update-group:
BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 3, replicated 2
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.4
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P1
Update messages formatted 2, replicated 1
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.2
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 4, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.5
BGP version 4 update-group 4, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P2
Update messages formatted 1, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.3
Note that now, the neighbors are split into four subsets: 10.0.0.2, internal using P1, 10.0.0.3, internal using P2, 10.0.0.4, internal without a prefix-list, and 10.0.0.5, external without a prefix-list. Note again that the update groups 2 and 4 say what are they outbound policies: update group 2 refers to prefix-list P1 while update group 4 refers to prefix-list P2.
The total combination of all outbound policies for individual neighbors is also important. Suppose that 10.0.0.2 will be using just P1, and 10.0.0.3 and 10.0.0.4 will be using both P1 and as-path ACL 1. This will again partition the set of all neighbors into three subsets, with the two already mentioned, plus 10.0.0.5 as an eBGP peer.
router bgp 1
no synchronization
bgp log-neighbor-changes
network 192.0.2.0
neighbor 10.0.0.2 remote-as 1
neighbor 10.0.0.2 prefix-list P1 out
neighbor 10.0.0.3 remote-as 1
neighbor 10.0.0.3 prefix-list P1 out
neighbor 10.0.0.3 filter-list 1 out
neighbor 10.0.0.4 remote-as 1
neighbor 10.0.0.4 prefix-list P1 out
neighbor 10.0.0.4 filter-list 1 out
neighbor 10.0.0.5 remote-as 2
no auto-summary
And the show ip bgp update-group:
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P1
Update messages formatted 3, replicated 1
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.2
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 5, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.5
BGP version 4 update-group 4, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P1
Outgoing update AS path filter list is 1
Update messages formatted 4, replicated 1
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 2 members (* indicates the members currently being sent updates):
10.0.0.3 10.0.0.4
You see now that based on the outbound policies, IOS has separated the BGP neighbors into three groups again. The update group 2 contains only 10.0.0.2 with the prefix-list P1. Update group 3 contains the eBGP peer 10.0.0.5. Update group 4 countains iBGP peers 10.0.0.3 and 10.0.0.4 using prefix-list P1 and AS path ACL 1.
Feel welcome to ask further!
Best regards,
Peter
Message was edited by: Peter Paluch - corrected the prefix lists - their former form of 0.0.0.0/32 didn't make sense although it is not that relevant to the topic of this discussion.
01-11-2013 09:07 PM
The concept of update group was developed to help BGP processing be more efficient. By default BGP processing creates the routing updates for each neighbor separately and independently. So if a router had 4 neighbors then it would go through the process of creating and sending the routing update 4 times - even if all 4 neighbors get exactly the same advertisements. With update group you are telling the router that each of these neighbors gets the same advertisements. So the router generates the update one time and transmits 4 times.
HTH
Rick
Sent from Cisco Technical Support iPad App
01-12-2013 04:24 AM
In addition to what Rick said, you can also see who these update groups are with "show ip bgp update-group
HTH,
John
*** Please rate all useful posts ***
01-12-2013 06:31 AM
Thanks Richard and John
01-12-2013 06:50 AM
Hello Sarah,
In addition to excellent Rick's response, let me add that these "update groups" are also called dynamic peer-groups, or dynamic update peer-groups because their members are computed by IOS on the fly, without any specific explicit configuration.
While the documentation is not very specific on how these dynamic update groups are computed, the algorithm is fairly easy: you group together all neighbors that have the same type (internal or external) and which have the same outbound policies. Now, the "same outbound policies" criterion is again very simple: those are all neighbors that are configured with the same set of outbound prefix lists, ACLs, AS-path lists and/or route-maps.
Consider this 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 192.0.2.0
neighbor 10.0.0.2 remote-as 1
neighbor 10.0.0.3 remote-as 1
neighbor 10.0.0.4 remote-as 1
neighbor 10.0.0.5 remote-as 2
no auto-summary
In this configuration, just 4 neighbors, 3 iBGP and 1 eBGP, the show ip bgp update-group says:
R1#show ip bgp update-group
BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 1, replicated 2
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 3 members (* indicates the members currently being sent updates):
10.0.0.2 10.0.0.3 10.0.0.4
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 2, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.5
Notice that there are 2 update groups identified. The first update group currently holds all my iBGP neighbors and the second update group holds my eBGP neighbors - clearly because the updates towards the iBGP neighbors are the same (no outbound policies specified), while the eBGP neighbor gets to receive different updates (the AS_PATH and NEXT_HOP manipulation in eBGP, at least).
Imagine now that I configure the 10.0.0.2 and 10.0.0.3 peers with an outbound prefix list P1. This partitions the set of all neighbors into three subsets: 10.0.0.2 and 10.0.0.3 internal using prefix-list P1, 10.0.0.4 internal without a prefix-list, 10.0.0.5 external without a prefix list.
router bgp 1
no synchronization
bgp log-neighbor-changes
network 192.0.2.0
neighbor 10.0.0.2 remote-as 1
neighbor 10.0.0.2 prefix-list P1 out
neighbor 10.0.0.3 remote-as 1
neighbor 10.0.0.3 prefix-list P1 out
neighbor 10.0.0.4 remote-as 1
neighbor 10.0.0.5 remote-as 2
no auto-summary
Now, the show ip bgp update-group says:
BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 2, replicated 2
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.4
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P1
Update messages formatted 1, replicated 1
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 2 members (* indicates the members currently being sent updates):
10.0.0.2 10.0.0.3
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 3, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.5
The dynamic update peer-groups have been recalculated as a result of changed outbound policies. Note that the description of the update-group 2 also explains what kind of outbound policy is used - in this case, the prefix-list P1.
Note that the computation in IOS is very simple, referring simply to the names of prefix-lists, ACLs, as-path ACLs and route-maps in the neighbor commands to know if multiple neighbors are using the same set of outbound route manipulations. Note that my two prefix-lists, P1 and P2, are identical, but their names are different. If I configure the 10.0.0.2 to use P1 while the 10.0.0.3 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 produce identical results:
router bgp 1
no synchronization
bgp log-neighbor-changes
network 192.0.2.0
neighbor 10.0.0.2 remote-as 1
neighbor 10.0.0.2 prefix-list P1 out
neighbor 10.0.0.3 remote-as 1
neighbor 10.0.0.3 prefix-list P2 out
neighbor 10.0.0.4 remote-as 1
neighbor 10.0.0.5 remote-as 2
no auto-summary
And the corresponding show ip bgp update-group:
BGP version 4 update-group 1, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 3, replicated 2
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.4
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P1
Update messages formatted 2, replicated 1
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.2
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 4, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.5
BGP version 4 update-group 4, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P2
Update messages formatted 1, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.3
Note that now, the neighbors are split into four subsets: 10.0.0.2, internal using P1, 10.0.0.3, internal using P2, 10.0.0.4, internal without a prefix-list, and 10.0.0.5, external without a prefix-list. Note again that the update groups 2 and 4 say what are they outbound policies: update group 2 refers to prefix-list P1 while update group 4 refers to prefix-list P2.
The total combination of all outbound policies for individual neighbors is also important. Suppose that 10.0.0.2 will be using just P1, and 10.0.0.3 and 10.0.0.4 will be using both P1 and as-path ACL 1. This will again partition the set of all neighbors into three subsets, with the two already mentioned, plus 10.0.0.5 as an eBGP peer.
router bgp 1
no synchronization
bgp log-neighbor-changes
network 192.0.2.0
neighbor 10.0.0.2 remote-as 1
neighbor 10.0.0.2 prefix-list P1 out
neighbor 10.0.0.3 remote-as 1
neighbor 10.0.0.3 prefix-list P1 out
neighbor 10.0.0.3 filter-list 1 out
neighbor 10.0.0.4 remote-as 1
neighbor 10.0.0.4 prefix-list P1 out
neighbor 10.0.0.4 filter-list 1 out
neighbor 10.0.0.5 remote-as 2
no auto-summary
And the show ip bgp update-group:
BGP version 4 update-group 2, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P1
Update messages formatted 3, replicated 1
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.2
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Update messages formatted 5, replicated 0
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 30 seconds
Has 1 member (* indicates the members currently being sent updates):
10.0.0.5
BGP version 4 update-group 4, internal, Address Family: IPv4 Unicast
BGP Update version : 2/0, messages 0
Outgoing update prefix filter list is P1
Outgoing update AS path filter list is 1
Update messages formatted 4, replicated 1
Number of NLRIs in the update sent: max 1, min 1
Minimum time between advertisement runs is 0 seconds
Has 2 members (* indicates the members currently being sent updates):
10.0.0.3 10.0.0.4
You see now that based on the outbound policies, IOS has separated the BGP neighbors into three groups again. The update group 2 contains only 10.0.0.2 with the prefix-list P1. Update group 3 contains the eBGP peer 10.0.0.5. Update group 4 countains iBGP peers 10.0.0.3 and 10.0.0.4 using prefix-list P1 and AS path ACL 1.
Feel welcome to ask further!
Best regards,
Peter
Message was edited by: Peter Paluch - corrected the prefix lists - their former form of 0.0.0.0/32 didn't make sense although it is not that relevant to the topic of this discussion.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide