Junos : Robust, Modular Operating System

 

The Junos OS is a single software train for all platforms running. It’s built on top of FreeBSD; with this comes all of the benefits of a monolithic kernel as a control plane:

• Each component of Junos executes as a separate process.
• Because each control plane component executes as a separate process, the network operating system becomes more stable.  For example a bug with SNMP wouldn’t impact BGP and vice versa.
• Tools such as tcpdump can be used to sniff control packets sourced or destined to the control plane  such as STP BPDUs and OSPF Hellos.
• Provides a true separation of control and data plane. Management functions do not impact transit traffic and vice versa. For example if the data plane was running at line-rate, the control plane is still perfectly accessible and responsive.
• Starting as of Junos 12.1, there are three releases of the software each year.
• The major release is tied to the year and the minor release is tied to the release number.  For example 12.1 was released in 2012 and was the first release of that year.
• The first release is scheduled roughly around March; the second release is scheduled roughly around July; and the third release is scheduled roughly around November.
• Each release is supported for two years.
• The last release of the year is supported for three years. For example 12.3 is the last release of 2012 and will be supported for three years.
• Change control is built into Junos.
• As soon as you enter the configuration mode, a copy of the running configuration presented to you and is referred to the as candidate configuration.
• As you make changes only the candidate configuration is modified. For example if you add a new OSPF area to the candidate configuration, it will not impact the running configuration.
• All changes must be committed to the system in order to take effect. As changes are committed to the system, all changes are logged into a database. This database of previous changes can be used to rollback to a previous state of the system. This allows network engineers to treat changes to the system as snapshots; if somethings breaks, simply rollback to a previous snapshot or last known good configuration.
• Configuration commits can be marked with a comment. For example it’s common practice to associate the change control number of the network maintenance wit the commit comment. In addition to a commit comment, Junos will also log which user made the change, what exactly was modified, and what time the change took place. This makes auditing of the device very simple as it answers the who, what, and when questions with a single command.
• Junos supports full automation.
• Junos leverages XML for all inter-process communication and configuration data. Using a common language allows for the automation and programming of the entire network operating system.
• All major programming languages such as Java and Perl can be used to interact with Junos.
• Junos supports a custom programming language called SLAX that can be used off-box or on-box to fully program and automate Junos.
• Junos also supports three types of automation scripts:
• Commit scripts. These scripts are executed with each commit. For example a commit script could check all interfaces descriptions that contain the keyword “CORE” and ensure that the MTU is at least 4,000 or return a commit error.
• Operation scripts. These scripts are executed as regular operational commands. For example if you don’t like the output of the “show interfaces” command, you can simply write your own version of the command instead.
• Event scripts. These scripts are executed when an event takes place. For example if an interface went down or a destination IP address became unreachable, you can trigger an event such as installing a new static route.