]> git.puffer.fish Git - matthieu/frr.git/commitdiff
bgpd: Increment version number even when no data is sent
authorDonald Sharp <sharpd@nvidia.com>
Sat, 11 Mar 2023 17:05:44 +0000 (12:05 -0500)
committerDonald Sharp <sharpd@nvidia.com>
Sat, 11 Mar 2023 17:09:23 +0000 (12:09 -0500)
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>
bgpd/bgp_updgrp_adv.c

index d6eb3ff20be630ca18b5ebd3963ca7841d1a8f9b..aa312125764340508a1e93de2b72c48664f253ae 100644 (file)
@@ -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;
        }