> Rob Foehl
> Sent: Tuesday, November 10, 2020 6:26 PM
>
> On Tue, 10 Nov 2020, Jeffrey Haas wrote:
>
> > The thing to remember is that even though you're not getting a given
afi/safi
> as front-loaded as you want (absolute front of queue), as soon as we have
> routes for that priority they're di
On Tue, 10 Nov 2020, Robert Raszuk wrote:
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 c
On Tue, 10 Nov 2020, Gert Doering wrote:
Can you do the EVPN routes on a separate session (different loopback on
both ends, dedicated to EVPN-afi-only BGP)? Or separate RRs?
Yes, this is not what you're asking, just a wild idea to make life
better :-)
Not that wild -- I've already been pinni
>
> 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 th
Hi,
On Tue, Nov 10, 2020 at 01:26:09PM -0500, Rob Foehl wrote:
> Ah, maybe this is the sticking point: on a route reflector with an
> RE-S-X6-64 carrying ~10M inet routes and ~10K evpn routes, a new session
> toward an RR client PE needing to be sent ~1.6M inet routes (full table,
> add-path 2)
On Tue, 10 Nov 2020, Jeffrey Haas wrote:
The thing to remember is that even though you're not getting a given afi/safi
as front-loaded as you want (absolute front of queue), as soon as we have
routes for that priority they're dispatched accordingly.
Right, that turns out to be the essential
--- Begin Message ---
Rob,
> On Nov 9, 2020, at 9:53 PM, Rob Foehl wrote:
>
>> An immense amount of work in the BGP code is built around the need to not
>> have to keep full state on EVERYTHING. We're already one of the most
>> stateful BGP implementations on the planet. Many times that hel
On Mon, 9 Nov 2020, Jeffrey Haas wrote:
As the source of this particular bit of difficulty, a bit of explanation for
why it simply wasn't done when the initial feature was authored.
Much appreciated -- the explanation, anyway ;)
An immense amount of work in the BGP code is built around the
--- Begin Message ---
> On Nov 9, 2020, at 12:19 PM, Rob Foehl wrote:
>
> [External Email. Be cautious of content]
>
>
> On Mon, 27 Jul 2020, Rob Foehl wrote:
>
>> Anyone know the secret to getting BGP output queue priorities working across
>> multiple NLRIs?
> [...]
>> I've tried about a do
On Mon, 27 Jul 2020, Rob Foehl wrote:
Anyone know the secret to getting BGP output queue priorities working across
multiple NLRIs?
[...]
I've tried about a dozen combinations of options, and cannot get any other
result with inet/evpn routes in the same session -- inet.0 routes always
arrive a
On Tue, 28 Jul 2020, Jeffrey Haas wrote:
- "show bgp output-scheduler" is empty without top-level "protocols bgp
output-queue-priority" config, regardless of anything else
- Top-level "protocols bgp family evpn signaling" priority config -- and
nothing else within that stanza -- broke every v
To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] BGP output queue priorities between RIBs/NLRIs
>
> Anyone know the secret to getting BGP output queue priorities working
> across multiple NLRIs?
>
> Had trouble with EVPN routes getting stuck behind full refreshes of the v4
>
--- Begin Message ---
See below:
> On Jul 27, 2020, at 11:05 PM, Rob Foehl wrote:
>
> [External Email. Be cautious of content]
>
>
> Anyone know the secret to getting BGP output queue priorities working
> across multiple NLRIs?
>
> Had trouble with EVPN routes getting stuck behind full refres
Anyone know the secret to getting BGP output queue priorities working
across multiple NLRIs?
Had trouble with EVPN routes getting stuck behind full refreshes of the v4
RIB, often for minutes at a time, which causes havoc with the default DF
election hold timer of 3 seconds. Bumping those time
14 matches
Mail list logo
