> Thomas Schmid > Sent: Friday, August 10, 2018 10:35 AM > > Hi, > > Am 03.08.2018 um 15:46 schrieb [email protected]: > >> 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:: _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
