Mailing List Archive

Is it possible it’s related to the MTU change itself? I only mention it because I ran into a convergence issue between a MX10K3 and a JRR200 in the lab when I was timing convergence speeds. It took many minutes for the JRR to receive the full table. It turned out to be a lower MTU on an intermediate device in the lab core. Once that was fixed, the JRR receive the full table in less than a minute.

> On Apr 6, 2020, at 11:05 AM, Gustavo Santos <gustkiller@gmail.com> wrote:
>
> Hi,
>
> We have a MX10003 as peering router with over 400 BGP sessions. Last week
> we had to change MTU from one Interface and after change, the router took
> about 20 minutes to advertise routes some of our transit providers.
>
> 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 first time I noticed that behavior and with that event , this options
> did not worked as expected.
>
> The question is if there is a way to work around this change that behavior?
>
> Regards.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

If you have inconsistent MTUs throughout your implementation, you can cause fragmentation and this will lead to re-transmittals.

In other words… it will be slower, possibly extremely slow depending on the volume.

- Brian


Brian Johnson
brian@sdjohnsons.us

> On Apr 6, 2020, at 10:16 AM, Jason Lixfeld <jason-jnsp@lixfeld.ca> wrote:
>
> Is it possible it’s related to the MTU change itself? I only mention it because I ran into a convergence issue between a MX10K3 and a JRR200 in the lab when I was timing convergence speeds. It took many minutes for the JRR to receive the full table. It turned out to be a lower MTU on an intermediate device in the lab core. Once that was fixed, the JRR receive the full table in less than a minute.
>
>> On Apr 6, 2020, at 11:05 AM, Gustavo Santos <gustkiller@gmail.com> wrote:
>>
>> Hi,
>>
>> We have a MX10003 as peering router with over 400 BGP sessions. Last week
>> we had to change MTU from one Interface and after change, the router took
>> about 20 minutes to advertise routes some of our transit providers.
>>
>> 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 first time I noticed that behavior and with that event , this options
>> did not worked as expected.
>>
>> The question is if there is a way to work around this change that behavior?
>>
>> Regards.
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> Gustavo Santos
> Sent: Monday, April 6, 2020 4:06 PM
>
> Hi,
>
> We have a MX10003 as peering router with over 400 BGP sessions. Last week
> we had to change MTU from one Interface and after change, the router took
> about 20 minutes to advertise routes some of our transit providers.
>
> 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...

> 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:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/
xe-3s/irg-xe-3s-book/detecting-and-mitigating-a-bgp-slow-peer.html
Could not find how Juniper deals with slow peers (other than manually carve
them up into a separate update group) or whether that's even an issue in
junos?

adam




_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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@juniper.net> wrote:

>
>
> > On Apr 6, 2020, at 12:59 PM, <adamv0025@netconsultings.com> <
> adamv0025@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
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> From: Jeffrey Haas <jhaas@juniper.net>
> Sent: Monday, April 6, 2020 6:06 PM
>
> > On Apr 6, 2020, at 12:59 PM, <adamv0025@netconsultings.com>
> <adamv0025@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.
>
Hi Jeff,
Can you please expand on this last statement please?
How do these 17 output queues of the route prioritization system interwork
with the micro-groups you mentioned please?
The doc quoted by OP says " The queue servicing procedure operates per-BGP
peer group with each group maintaining its own token buckets." - I think it
means update-group rather than peer-group, where update-group might or might
not have a one-to-one relationship to actual update-group. But it also says
" This means that route priority can vary in each BGP peer group as well as
in specific neighbor configurations within the BGP peer groups" so I'm
guessing if it differs per peer then that peer is assigned to its own update
group (hence the reset of the session)?
Thank you.

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp