[c-nsp] ASR9k: RIB/FIB convergence

[Thomas Schmid]

Hi,

Am 03.08.2018 um 15:46 schrieb adamv0025 at netconsultings.com:
>> giving it a second thought: this may help in some cases, in others not. E.g.
>> BGP link to upstream dies -> FIB is still pointing to upstream -> router is still
>> announcing himself as exit point until all FIB entries are updated -> traffic is
>> dropped.
>>
>> It may help if e.g. as-path length is changing. The routing will then be
>> suboptimal for a while, but the rate with which the updates are announced
>> to the neighboring routers should be such that they can sync their FIB in
>> time.
>>
>> Waiting for feedback from TAC if this command is indeed checking the LC FIB
>> or if it's just looking at the RP.
>>
> Hmm, 
> Very good point, but if this feature should be of any use then it should be associated only with "ADD'' operation, possibly with "UPDATE" operation, but certainly not with "DELETE" operation.
> (not mentioning it should get the state back from the LC's NP HW-FIB or at least LC's CPU SW-FIB)
>

it turns out you run into funny situations with that 'update wait-install' command enabled:

RTA: 'update wait-install' configured. Learns route a.b.c.0/24 from direct peer ISPA.

RTB: learns a.b.c.0/24 from eBGP peer ISPB with longer AS-path.

RTA, RTB in BGP full mesh.

If I prepend the route for a.b.c.0/24 on RTA, the local BGP table is updated, but
the announcement with the longer as-path *never* makes it to RTB, probably because
the CEF entry locally is not updated and does not change. So RTA is holding back the
BGP announcement of the longer route to his neighbors.

So RTB never sees the longer as-path for the prefix and therefore *never* announces
the shorter route via  back to RTA. Therefore the routing never changes in the network.

In addition: 5.3.3 has bug CSCuv02045 "Mutex in ipv4_rib/ipv6_rib when
update-wait-install is enabled" ...
 
Cheers,

   Thomas