bgpd: fix wrong 'pending' labelpool counter value at startup

If BGP starts with a l3vpn configuration, the 'pending' value
of the 'show bgp labelpool summary' command is set to 128,
whereas the 'pending' value is 0 if the l3vpn configuration is
applied after.

with no config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger:       1
> InUse:        1
> Requests:     0
> LabelChunks:  1
> Pending:      0
> Reconnects:   1

with config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger:       1
> InUse:        1
> Requests:     0
> LabelChunks:  1
> Pending:      128
> Reconnects:   1

When BGP configuration is applied at startup, the label request fails,
because the zapi connection with zebra is not yet up. At zebra
up event, the label request is done again, succeeds, decrements the
'pending_count' value in 'bgp_lp_event_chunk() function, then sets
the 'pending_count' value to the 'labels_needed' value.

This method was correct when label requests were asyncronous: the
'pending_count' value was first set, then decremented. In syncronous
label requests, the operations are swapped.

Fix this by incrementing the expected 'labels_needed' value instead.

Fixes: 0043ebab996e ("bgpd: Use synchronous way to get labels from Zebra")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

diff --git a/bgpd/bgp_labelpool.c b/bgpd/bgp_labelpool.c
index 46443d9d188dac88952be86a0758c7d45f66c198..b2bb49b943969e254cf9ba6d832e44e869ac8653 100644 (file)
--- a/bgpd/bgp_labelpool.c
+++ b/bgpd/bgp_labelpool.c
@@ -667,8 +667,7 @@ void bgp_lp_event_zebra_up(void)
        if (labels_needed && !bgp_zebra_request_label_range(MPLS_LABEL_BASE_ANY,
                                                            labels_needed, true))
                return;
-
-       lp->pending_count = labels_needed;
+       lp->pending_count += labels_needed;
 
        /*
         * Invalidate any existing labels and requeue them as requests