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

[Rob Foehl]

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 v6 session on the box,
>>  even with family inet6 explicitly configured under those groups
>
> If you're simply trying to prioritize evpn differently than inet unicast, simply having a separate priority for that address family should have been sufficient.

Right, that's what I took away from the docs...  No luck in any case, 
starting from the "simplest" of just adding this:

set protocols bgp group X family evpn signaling output-queue-priority expedited

That'll produce this in "show bgp group output-queues" for that group:

   NLRI evpn:
     OutQ: expedited RRQ: priority 1 WDQ: priority 1

...but that's it, and no change in behavior.  Same config for family inet 
in the same group would show NLRI inet: output, and no more evpn if both 
were configured.  Still no change.

> Can you clarify what you mean "broke every v6 session"?

For that one, it shut down every session on the box that didn't explicitly 
have family inet / family evpn configured at the group/neighbor level, 
refused all the incoming family inet sessions with NLRI mismatch (trying 
to send evpn only), and made no attempt to reestablish any of the family 
inet6 sessions.

> I think what you're running into is one of the generally gross things about the address-family stanza and the inheritance model global => group => neighbor.  If you specify ANY address-family configuration at a given scope level, it doesn't treat it as inheriting the less specific scopes; it overrides it.

In that specific case, yes; maybe I didn't wait long enough, but this was 
only an experiment to see whether setting something under global family 
evpn would do anything different -- and had about the expected result, 
given the way inheritance works.  (This was the least surprising result 
out of everything I tried.  I have logs, if you want 'em.)

> FWIW, the use case of "prioritize a family different" is one of the things this was intended to address.  Once you have a working config you may find that you want to do policy driven config and use the route-type policy to prioritize the DF related routes in its own queue.  That way you're not dealing with the swarm of ARP related routes.

Eventually, yes -- same for certain classes of inet routes -- but for now 
I'd have been happy with "just shove everything EVPN into the expedited 
queue".  I couldn't get them ahead of inet, and it was a many-minute wait 
for anything else to arrive, so pretty easy to observe...

-Rob


>> - Per-group family evpn priority config would show up under "show bgp
>>  group output-queues" and similar, but adding family inet would cause the
>>  NLRI evpn priority output to disappear
>>
>> - Policy-level adjustments to any of the above had no effect between NLRIs
>>
>> - "show bgp neighbor output-queue" output always looks like this:
>>
>>  Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
>>    Output Queue[1]: 0            (inet.0, inet-unicast)
>>
>>  Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
>>    Output Queue[2]: 0            (bgp.evpn.0, evpn)
>>
>>  ...which seems to fit the default per-RIB behavior as described.