BGP: crash in update_subgroup_merge()

Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:   Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-8191

On my hard node I have a route to 10.0.0.0/22 via eth0, I then learn
10.0.0.8/32 from peer 10.0.0.8 with a nexthop of 10.0.0.8:

superm-redxp-05# show ip bgp 10.0.0.8/32
BGP routing table entry for 10.0.0.8/32
Paths: (1 available, no best path)
  Not advertised to any peer
  80
    10.0.0.8 from r8(swp6) (10.0.0.8)
      Origin IGP, metric 0, localpref 100, valid, external
      AddPath ID: RX 0, TX 9
      Last update: Thu Nov 12 14:00:00 2015

superm-redxp-05#

I do a lookup for the nexthop and see that 10.0.0.8 is reachable via my
eth0 10.0.0.22 so I select a bestpath and install the route.  At this
point my route to 10.0.0.8 is a /32 that resolves via itself, NHT sees
that this is illegal and flags the nexthop as inaccessible.

superm-redxp-05# show ip bgp 10.0.0.8/32
BGP routing table entry for 10.0.0.8/32
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  r6(swp4) r7(swp5) r8(swp6) r2(10.1.2.2) r3(10.1.3.2) r4(10.1.4.2)
  80
    10.0.0.8 (inaccessible) from r8(swp6) (10.0.0.8)
      Origin IGP, metric 0, localpref 100, invalid, external, bestpath-from-AS 80, best
      AddPath ID: RX 0, TX 9
      Last update: Thu Nov 12 14:00:00 2015

superm-redxp-05#

at which point we withdraw the route, things churn, we relearn it and go
through the whole process over and over again.  We end up advertising and
withdrawing this route about 9 times a second!!

This exposed a crash in the update-group code where we try to merge two sub-groups
but the assert on adj_count fails because the timing worked out where one had
advertised 10.0.0.8/32 but the other had not.

NOTE: the race condition described above will be resolved via a separate patch.

0 files changed, 0 insertions, 0 deletions