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.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to