On Tue, Mar 29, 2016 at 03:46:07PM +0300, Saku Ytti wrote: > On 29 March 2016 at 15:05, chip <[email protected]> wrote: > > Juniper has a "This Week" book freely available that discussess, in detail, > > the path of a packet through an MX. It's quite an informative read. > > > > http://www.juniper.net/us/en/training/jnbooks/day-one/networking-technologies-series/packet-walkthrough-mx-series/ > > I love that 'few milliseconds', only 3 orders of magnitude off. > > > This Week: An Expert Packet Walkthrough on the MX Series 3D provides the > > curious engineer with a global view of the short life (a few milliseconds) > > of packets inside the Juniper Networks MX Series of 3D routers. > > Technically not JNPR book, but reverse engineered by JNPR customer, > which is bit of ironic that we have to do that. There is great > internal Trio document (now dated) by Steven Wong. But it is really > really good for external customers too. Who knows what gems they have > I don't have any idea, which would have helped me avoid downtime or > bad design choices. > I would put in all future RFQ/RFP requirement for internal-level > architecture documentation, since getting these otherwise is super > hard. I don't understand why vendors don't publish these.
Almost certainly such documents would contain 'secret sauce' that the vendor does not want to disclose to competitors. > Mentioned > document has helped me countless time, to choose design which least > exposes platforms compromises, to troubleshoot issue without bothering > JTAC or helped me give JTAC precise troubleshooting information > potentially cutting weeks of solution time and downtime of repeated > problems. As alluded to in this thread, the number of customers who invest such effort can be counted on a very small number of hands, and I doubt vendors will see sufficient business benefit in disclosing the information you describe. > Lot of the good instrumentation is not exposed to end-users at all, > like packet-via-dmem or capturing exception packets (you're getting > CRC errors from IXP, which neighbour is to blame?, you're getting IP > checksum errors from MPLS core, who is mangling them?). Traditionally > very hard to answer questions become trivial with supplied > instrumentation. Debugging tools, sure disclose all those - but that is very different than what you are asking for. /Jesper _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
