From a8038460bd2b413a0c082fbd629cdae00708b133 Mon Sep 17 00:00:00 2001 From: Donald Sharp Date: Sat, 11 Mar 2023 12:05:44 -0500 Subject: bgpd: Increment version number even when no data is sent When an update group decides to not send a prefix announcement because it has not changed, still increment the version number. Why? To allow for the situation where you have say 2 peers in 1 peer group and shortly after they come up a 3rd peer comes up. It will be placed into a separate update group and could be coalesced down, when it finishes updating all data to it. Now imagine that a single prefix changes at this point in time as well. Then first 2 peers may decide to not send the data, since nothing has changed. While the 3rd peer will and since the versions numbers never match they will never coalesce. So when the decision is made to skip, update the version number as well. Signed-off-by: Donald Sharp --- bgpd/bgp_updgrp_adv.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'bgpd/bgp_updgrp_adv.c') diff --git a/bgpd/bgp_updgrp_adv.c b/bgpd/bgp_updgrp_adv.c index d6eb3ff20..aa3121257 100644 --- a/bgpd/bgp_updgrp_adv.c +++ b/bgpd/bgp_updgrp_adv.c @@ -497,6 +497,23 @@ void bgp_adj_out_set_subgroup(struct bgp_dest *dest, zlog_debug("%s suppress UPDATE w/ attr: %s", peer->host, attr_str); } + + /* + * If BGP is skipping sending this value to it's peers + * the version number should be updated just like it + * would if it sent the data. Why? Because update + * groups will not be coalesced until such time that + * the version numbers are the same. + * + * Imagine a scenario with say 2 peers and they come + * up and are placed in the same update group. Then + * a new peer comes up a bit later. Then a prefix is + * flapped that we decide for the first 2 peers are + * mapped to and we decide not to send the data to + * it. Then unless more network changes happen we + * will never be able to coalesce the 3rd peer down + */ + subgrp->version = MAX(subgrp->version, dest->version); return; } -- cgit v1.2.3