[j-nsp] BGP output queue priorities between RIBs/NLRIs

Robert Raszuk robert at raszuk.net
Tue Nov 10 14:21:27 EST 2020


>
> Can you do the EVPN routes on a separate session (different loopback on
> both ends, dedicated to EVPN-afi-only BGP)?


Separate sessions would help if TCP socket would be the real issue, but
here clear it is not.


> Or separate RRs?
>

Sure that may help. In fact even separate RPD demon on the same box may
help :)

But what seems wired is last statement:

"This has problems with blackholing traffic for long periods in several
cases,..."

We as the industry have solved this problem many years ago, by clearly
decoupling connectivity restoration term from protocol convergence term.

IMO protocols can take as much as they like to "converge" after bad or good
network event yet connectivity restoration upon any network event within a
domain (RRs were brought as example) should be max of 100s of ms. Clearly
sub second.

How:

- RIB tracks next hops and when they go down (known via fast IGP flooding)
or their metric changes then paths with such next hop are either removed or
best path is run
- Data plane has precomputed backup paths and switchover happens in the PIC
fashion in parallel to any control plane stress free work

I think this would be a recommended direction not so much to mangle BGP
code to optimize here and in the same time cause new maybe more severe
issues somewhere else. Sure per SAFI refresh should be the norm, but I
don't think this is the main issue here.

Thx,
R.


More information about the juniper-nsp mailing list