Pekka, for the I-chip that is used in the MX, there are enchancements to keep second best hop in the I-chip so it doesnt have to update the fib from the RE in JUNOS 10.0.
This in combination with BFD, IP FRR and BGP nexthop should take care of any reconvergence performance problems in MX. Patrik Pekka Savola wrote: > On Thu, 24 Sep 2009, Patrik Olsson wrote: >> I dont know when there is a an official response, but the report seems >> very Cisco friendly... >> I have performed very tough tests on the MX, putting both multicast >> and QoS to the test and I have seen none of the problems Miercom >> claims they see... > > Have you tested MX also during RIB or FIB changes? I'd like to use this > as a soapbox. On Juniper platforms, when a next-hop changes, this > results in first DELETE and then (maybe much later) ADD operations in > FIB. We have noticed that when BGP next-hop changes for 300K prefixes, > this has led to up to 7 minutes of packet loss due to a lack of FIB > entry for a destination. This was seen on T-series, but MX has the same > architectural limitations. This slowness was introduced sometime in > JunOS 8.x. And this is "working as designed" and "no way to speed it up". > > Hopefully at some point someone will do performance testing in these > kind of scenarios as well; I don't recall seeing such a test myself. > -- //Patrik Webkom http://www.webkom.se +46 (0)709 35 22 99 +46 (0)8 559 26 488 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp