Re: [j-nsp] Junos 20 - slow RPD

[Mark Tinka via juniper-nsp]

On 3/25/22 11:21, Mihai via juniper-nsp wrote:

In my case I just upgraded one MX204 in the lab to 21.2R2, enabled 
rib-sharding and increased the JunosVM memory to 24G and things look 
better now.


Glad to hear!

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

Re: [j-nsp] Junos 20 - slow RPD

[Mihai via juniper-nsp]

In my case I just upgraded one MX204 in the lab to 21.2R2, enabled 
rib-sharding and increased the JunosVM memory to 24G and things look 
better now.



On 25/03/2022 00:58, Gustavo Santos via juniper-nsp wrote:

Hi,
I think that I was the only one with this issue.

Even with a  RE-S-X6-64G.  We have very slow outbound updates. sending a
lot of fullrouting tables to customers may take upto 60 minutes or more
when you
have a lot of BGP groups , for instance, one group per customer ...  and if
the we have an issue with the preferred upstream provider, the customer
routers may me offline
until all updates are sent..

We got new routers and we are going to try Junos 20.4R3 latest service
release with update threading and rib-sharding to see if we get some
improvement, it is better to lost NSR than blackhole
traffic for over an hour..



Em qua., 23 de mar. de 2022 às 06:41, Mark Tinka via juniper-nsp <
juniper-nsp@puck.nether.net> escreveu:




On 3/22/22 22:42, Mihai via juniper-nsp wrote:



Hi Saku,

The routes are in VRF so no support for rib-sharding unfortunately.
This MX204 is running 20.2R3-S3 so probably the only option is to try
another version.


We've had some terrible experiences with RPD due to NSR sync. to re1 for
BGP, on an RE-S-1800 running Junos 20.4R3.8. Turns out the code can't
deal with grouping outbound updates to eBGP neighbors at scale for that
RE, which crashes RPD on re1.

The options were to either disable NSR, rewrite our outbound policies
and combine multiple customers in the same outbound group, or get more
memory. We went for the last option.

No more problems on the RE-S-X6-64G.

Juniper have some work to do to optimize the code in these use-cases.

Mark.
___
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

Re: [j-nsp] Junos 20 - slow RPD

[Mark Tinka via juniper-nsp]

On 3/25/22 02:58, Gustavo Santos via juniper-nsp wrote:


Hi,
I think that I was the only one with this issue.


From their feedback, it seems the issue of scaling outbound updates of 
full tables to eBGP neighbors is known within Juniper, because they told 
us they have had to come up with all manner of hacks for many of their 
large scale customers as well.


So it's a fundamental problem, one I'm not sure they are addressing very 
well.


We can't keep throwing hardware at the problem.



it is better to lost NSR than blackhole
traffic for over an hour..


Agreed - we had gotten to the point where we were willing to give up NSR 
until we figure this out.


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