[c-nsp] ASR9k: RIB/FIB convergence

[adamv0025 at netconsultings.com]

> Thomas Schmid
> Sent: Friday, August 10, 2018 10:35 AM
> 
> 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" ...
> 
Sorry for the late response,

Well you've got to be careful here,
You haven’t stated that, during initial conditions, A believed that path via ISPA has been selected as the overall best path indeed. 
Cause if A believed that route via B from ISPB is the overall best path ,then A would not advertise its own route to B (unless A is configured with "advertise best-external" which I recommend in order to speed up convergence -please note though it increases FIB usage). 

If, during initial conditions,  A did select path via ISPA as the overall best path then I agree it’s a bug and should be reported.
(would be interesting to see from debug why the route is not advertised to B)
Also I believe that update-wait-install routine should not be used in this scenario (should be used only when a path is changed to best path). 

Seems like CSCuv02045 has been fixed only very recently ~6.2.2+
Isn't there a SMU available for older releases?

Oh and one last note,
Alternative solution is BGP PIC Edge with "advertise best-external" - this combo covers all the cases with exception of a new (unforeseen) path that is relayed to other speakers or reload of the box  -for these two cases the only solution is "update-wait-install". 


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::