On (2013-09-25 08:29 +1000), Luca Salvatore wrote: > This concerns me a little. I'M about to take a full table on a MX5. > Is it only an issue when the adjacencyis lost and we need to receive the > table again or will performance of the entire box be affected?
For what it's worth we're running metric crapton of MX80s which take 540k IPv4 routes, 15k IPv6 routes and some VPNv4 routes, from 1ks to 100ks. They mostly work in our environment and RPD or KRT Queue does not get too angry. However, recently we added MD5 to the IPv4 RR sessions, and during flapping the RR session we might get RPD slip and have unrelated customer facing VPNv4 peers flap. This issue only triggered on boxes which had more than few customer facing BGP sessions, JTAC is on the case but I'm not overly optimistic. I'd really hope that instead of just putting out fires, Juniper takes deeper architectural review of RPD, rip out protocol code and implement them in under newer, scalable more robust design. And maybe do phased migration, where customers have option to run old JunOS or new JunOS, like CSCO has done with catalyst and GSR. Allowing new platform to get exposure before it has feature-parity with old platform. How many good developers they'd need for that? Committed team of 5? -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
