Hi Adam, Am 02.08.2018 um 12:23 schrieb adamv0...@netconsultings.com: > First thing first, > To mitigate the damage due to RIB-FIB inconsistencies you could use the: > "BGP-RIB Feedback Mechanism for Update Generation" > "To configure BGP to wait for feedback from RIB indicating that the routes > that BGP installed in RIB are installed in FIB, before BGP sends out updates > to neighbors, use the "update wait-install" command in router address-family > IPv4 or router address-family VPNv4 configuration mode." >
good point. Haven't heard of this from Cisco yet. Will discuss this with the TAC. > > Are you seeing any log messages indicating bottleneck between RIB and FIB > please? no. > Do you drop BGP updates on ingress with "as-path length ge 51" please? -not > only it's a good practice, but apparently long as-paths caused RIB-FIB > clogging in the past. > > On your note regarding the apparent relation to number of peers. > So how long does it take for the process to complete for the 200 peers nodes > is it linearly proportional to the 20-30 minutes seen on 300 peers nodes > please?> Or the relation between number of peers and time follows more of an > exponential function (e.g. 290 all good and then 301 bang 30min) , in which > case that could also indicate something special with those "delta" peers > (e.g. some peers sending somewhat funky updates) (any slow peers btw?) > to be more clear: the full 700k BGP updates are only sent to a small fraction of the e/iBGP peers (10-20). The BGP updates are sent out without delay to the neighbors. Wrt. the number of sessions when things get bad, it's hard to tell since the number of routers is 8 with 4 ASR9000 and 4 ASR9900 (many BGP peers). Within the 4 ASR9900 it looks more or less linear. Thanks, Thomas
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
