> From: Saku Ytti [mailto:s...@ytti.fi] > Thursday, April 20, 2017 10:08 AM > > The memory is just DRAM on Trio, DRAM isn't significant bottleneck, > considering there are/were pathological cases where router has advertised > new path and not programmed in in HW for 30min or more. > Also somewhere JNPR has gotten wrong message from customers, as they > seemed to think this is just about FIB update being slow, but that's not even > the main problem, Agree, there's a solution for that in form of FRR for IGP/RSVP and BGP, so in my opinion there's no value in investing time and effort into this.
> main problem is software and hardware being decoupled. > Blackholing is bad, using old path in software and hardware until you can > actually program the new entry is acceptable. After this is done, THEN focus > on making it faster. > IOS-XR has BGP-RIB Feedback since 4.3.0. (It actually is FIB feedback, the name is so confusing). And you have also the periodic Route and Label Consistency Checker -very helpful to point out HW programming issues. I can't recall whether Junos has a similar feedback mechanism implemented or planned. > The synchronicity guarantees are not JNPR specific problem at all, I know > people see these in some CSCO platforms and Arista by default does not > guarantee it, they have knob for it today. It wasn't entirely obvious to me > what the guarantee actually does, it wasn't all-the-way-to-chip guarantee, I > guess it was to the LC CPU guarantee. > Good point, I haven't checked actually but if the feedback wouldn't be all the way down to NPU lookup memory it wouldn't be of much help. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
