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
