The JUNOS Software Architecture

In the previous post I gave you the briefest insight into the JUNOS software architecture by telling you that its kernel is based on FreeBSD. Juniper developers start turning a FreeBSD kernel into a JUNOS kernel by reviewing the FreeBSD code line-by-line, removing all unwanted components and drivers. Some of the code is rewritten to match internal Juniper style guidelines, and the code is commented as needed. Juniper-specific “hooks” are then added.

This process (which is occasionally repeated when Juniper decides to incorporate FreeBSD updates into JUNOS) results in a kernel that, although based on FreeBSD, is no longer FreeBSD. It’s a JUNOS kernel now and is treated with the same management and change control processes as any other internal code.

The kernel is then the foundation and common component on which the rest of JUNOS is built. And that brings us to the next important characteristic of JUNOS: It’s a modular operating system.

Why Modularity Matters

The various functional components of JUNOS are separated into modules, called daemons. For example, there is the Routing Protocol Daemon (RPD) that runs all the routing protocols, a Device Control Daemon (DCD) that controls all the interfaces, a Chassis Daemon to control the chassis hardware, a Management Demon, and so on.

Each of the modules runs in its own protected memory space, and no module can use memory belonging to another module – thus protecting against various memory overruns and similar errors. The kernel supervises everything, managing intercommunications among the modules and with the physical system.

One of the benefits of such a modular architecture is that if a software bug or some sort of network event causes a functional failure, the failure is usually isolated to the module supporting that function, rather than causing a systemwide crash. So for example a bug, a severe misconfiguration, or a malicious protocol attack against OSPF might cause the RPD to fail, but the rest of the system stays up so that you can still gain access to the box to correct the problem.

Similarly, a bug fix can be issued for a single module. Rather than taking the system offline and replacing the entire OS, a problem module can be individually replaced and brought back online without the need to perform a full system restart.

Major new functional components can also be added to the operating system by adding a new module, which sharply reduces the amount of regression testing that must be performed during new feature development.

Modularity also matters in that when you have a codeset with boundaries and defined interface points for communication outside of the module, it is far easier for a reasonably small team of engineers to manage the code and understand it intimately. When changes are to be made, the complete effect of those changes can be clearly understood; when a bug arises, it can be quickly located and remedied.

All of these qualities mean that modular operating systems tend to be much more reliable and stable.

IOS and Modularity

Cisco’s IOS is not modular, due to the different circumstances of the networking world that existed when IOS was created. It’s reasonable to assume that Cisco will, at some point, release a modular operating system for broad use across most of its routers – whether that system is called IOS or something different.

You can already see the early moves in that direction with IOS-XR. This operating system is completely modular, and carries many features similar to JUNOS. The problem with IOS-XR, however, is that it is limited to the CRS and GSR routers; it can’t be run on smaller platforms.

Then there is ION, a sort of modularized IOS but again limited to just some platforms.

I asked Russ White at Cisco if there are plans to modularize IOS. “The question isn’t ‘Are there any other plans to modularize IOS?’” he replied,  “but rather, ‘Which of the 5,968 existing plans will the IOS folks actually choose?’”

I like that answer; it says there are definite plans afoot, it’s just a matter of choosing the right one. That could be quite a challenge, given the diversity of platforms that currently run IOS and the diversity of IOS releases. The move to a “modular IOS” is likely to be evolutionary rather than a sudden jump from monolithic to modular.

The JUNOS Release Train

All of that diversity in IOS is something Cisco Systems and Cisco users have struggled with for a long time. JUNOS, on the other hand, has a linear release train: For any given release there is a single image that runs on all routing platforms (except the E series and Netscreen, post-JUNOS acquisitions that have been difficult to adapt to JUNOS). There are also no separate feature packages; if you want IPv6 or MPLS or IP multicast, it’s all in the one image.

Juniper is also adamant about not adding new features to existing releases; new features always come in the next release in line.

This principle of one image for all platforms, all features in one image, and no new feature development in production releases means that internal code management and regression testing of new features is greatly simplified. It also means simplified, safer upgrades for Juniper customers.

In the next post, we’ll begin looking at the organization of the JUNOS configuration file.