Discussion

Throughout 1997 and early 1998, all the Juniper engineering teams worked pretty
much flat-out to finish the M40. The engineering labs were seldom quiet, and it was
hard to tell the weekends from the weekdays by counting cars in the parking lot. The
software teams designed and implemented a truly astonishing amount of code in a
very short period of time. FreeBSD kernel extensions were added to provide support
for chassis management and new Juniper network interfaces. A clean user interface
was designed and implemented to provide a seamless interface to the system and prevent
users from having to edit raw configuration files by hand. An entire embedded
microkernel was written to manage the packet-forwarding engine boards in the system
(a fully-loaded M40 would have nine PFE-related boards), which would allow
users to exchange configuration and status messages with the routing engine and
each other. Drivers for the embedded microkernel were written to manage the ASICs
and to allow the route engine to configure the PFE. The size and complexity of the
software required to manage just the various control boards eventually grew to rival
the route engine itself.
The real headache for the software team was that the hardware wasn’t available to
test with. It can take many months after a system is assembled in the engineering lab
to get it to a usable state as a complete system. But Juniper couldn’t afford for us to
spend six months in the lab; there just wasn’t enough money or time. The solution
was to get extremely creative with test equipment, evaluation boards, and generic
PCs before the final hardware was available. All sorts of emulation environments
were developed to allow the new routing engine and embedded software to be
debugged ahead of the actual hardware. For months, we used a motley collection of
machines cobbled together from parts and equipment that emulated the final hardware.
We didn’t really have to disguise the lab for external visitors—they wouldn’t
have been able to guess that each ratty bundle of machines was a virtual M40.
The payback from this approach was enormous. When the hardware finally arrived,
it took just one week in the engineering lab for the first network packets to be forwarded
successfully! Considering the complexity of the routing engine and PFE
interaction, this was a monumental achievement and meant that we could quickly
verify that the hardware worked before shipping the systems to our early test customers
in September of 1998.
Designing and implementing the first release of the JUNOS software was an unforgettable
time. Although the reader may think I’ve concentrated way too much on the
hardware, the JUNOS software is intrinsically the way it is because of the hardware.
That it has gone through so many iterations since then, and continues to evolve with
the advancement of Juniper routers, is the first item you should learn in this book.
The second thing that you should know is that although creating the JUNOS software
really was a team effort, Aviva Garrett had the dubious task of documenting
our efforts. In fact, she wrote the first manual. And then, as the manager of Juniper
Networks technical publications, she led the effort from Version 1.0 until very
This is the Title of the Book, eMatter Edition
Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved.
Foreword | xv