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 [email protected] > On Apr 6, 2020, at 10:16 AM, Jason Lixfeld <[email protected]> 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 <[email protected]> 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 [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
