[c-nsp] ASR9k: RIB/FIB convergence

[adamv0025 at netconsultings.com]

> From: Thomas Schmid [mailto:schmid at dfn.de]
> Sent: Thursday, August 02, 2018 12:12 PM
> 
> Hi Adam,
> 
> Am 02.08.2018 um 12:23 schrieb adamv0025 at 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.
> 
Seems like the control plane is all good it's just the bcdlv2 having troubles - or GSP as the underlying transport.
The " show bcdlv2 trace" should give TAC engineers tons of info.
Btw if you do "show rib update-groups" you see no freeze counts right?


adam

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