[j-nsp] Prioritize route advertisement

[Gustavo Santos]

Thanks for all inputs.

Before the change I set the vlans that the peer was 1500Bytes MTU set on
the interface to avoid MTU issues, but I can try with some
of this transit providers the IP MTU on their side to match and check if
the convergence time will get better.

Regards!

On Mon, Apr 6, 2020 at 2:06 PM Jeffrey Haas <jhaas at juniper.net> wrote:

>
>
> > 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
>
>