Am 03.08.2018 um 15:46 schrieb adamv0...@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 

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, 
the announcement with the longer as-path *never* makes it to RTB, probably 
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* 
the shorter route via  back to RTA. Therefore the routing never changes in the 

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


cisco-nsp mailing list  cisco-nsp@puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to