bgpd: handling flapped updates considered as duplicates in route proc…

…essing

When many routes are involved, clearing a neighbor and reconnecting
causes some updates to arrive too quickly before bgpd finishes
processing the route flush. I observed that updates are scheduled for
withdrawal, but by the time bgpd re-establishes the connection and
finishes receiving updates, it starts processing them. Some updates are
considered duplicates because they use the same bgp_dest instance (which
is destroyed once the withdrawal is processed), leading to route losses.

The fix is to check if a withdrawal advertisement is already scheduled
when a duplicate update occurs. If so, the withdraw message is dropped.

Signed-off-by: Loïc Sang <loic.sang@6wind.com>

bgpd/bgp_updgrp_adv.c

@@ -593,6 +593,18 @@ bool bgp_adj_out_set_subgroup(struct bgp_dest *dest,
 				   attr_str);
 		}
 
+		/* Duplicate update received, ignoring it. If the prefix
+		 * changes too quickly before we process the withdraw,
+		 * the update is dropped and the route is lost. Checking if
+		 * a withdraw is already scheduled for this adj.
+		 * If so, the withdraw is dropped.
+		 */
+		if (adj->adv && !adj->adv->baa) {
+			bgp_adv_fifo_del(&subgrp->sync->withdraw, adj->adv);
+			bgp_advertise_free(adj->adv);
+			adj->adv = NULL;
+		}
+
 		/*
 		 * If BGP is skipping sending this value to it's peers
 		 * the version number should be updated just like it