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 <sharpd@nvidia.com>

1 files changed, 17 insertions, 0 deletions

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;
 	}