[j-nsp] Prioritize route advertisement

Jeffrey Haas jhaas at juniper.net
Mon Apr 6 13:05:52 EDT 2020



> On Apr 6, 2020, at 12:59 PM, <adamv0025 at netconsultings.com> <adamv0025 at netconsultings.com> wrote:
> 
>> Gustavo Santos
>> Sent: Monday, April 6, 2020 4:06 PM
>> 
>> Is there a way to prioritize advertisement on some BGP sessions above
>> others? I tried the
>> https://www.juniper.net/documentation/en_US/junos/topics/topic-
>> map/bgp-route-prioritization.html
>> 
> The feature you mentioned is used to say first send L3VPN routes before
> L2VPN routes when talking to a given peer.
> I'm not aware of any such mechanism to say peer 192.0.2.1 should be served
> first and then peer 192.0.2.2 should be next, etc...

Junos roughly serves the back queue for the peer group based on the subsets of peers that get common updates vs. the peers that are ready to write.  In the presence of a large back queue for a peer in the group, we might appear sluggish to service some of the more in sync peers.  However, what will tend to happen is those slower and more out of sync peers will write block and next round we just move along to do other work.

> 
>> The question is if there is a way to work around this change that
> behavior?
>> 
> Wondering if it was due to some slow peer(s)
> Not sure if juniper BGP works similarly to cisco BGP in this area (but
> considering the differences in update groups between the two it might very
> well NOT be the case)
> But cisco has the following to address slow peers holding down the whole
> update group more info at:

Yeah, we don't need that.  We just form optimal micro-groups for the peers that are in the same sync level at a given part of the queue and are ready to write.

The prior email on path MTU issues will account for all sorts of headaches.  BGP is a TCP application, and things that manifest in a fashion similar to lost packets will do terrible things to throughput.

-- Jeff



More information about the juniper-nsp mailing list