Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Top Differences Between Junos OS Evolved and Junos OS

Although we've aligned Junos OS Evolved with Junos OS, there are some key differences to keep in mind when operating Junos OS Evolved. Junos OS Evolved is built on top of a Linux kernel, while Junos OS operates on the FreeBSD kernel. This and other fundamental differences in the design of Junos OS Evolved may be relevant in the management of your network. Read on to learn about the top differences between Junos OS Evolved and Junos OS.

System Differences

The concept of system in Junos OS Evolved is different from Junos OS. Junos OS uses a Routing Engine centric model, where system usually refers to a Routing Engine. However, Junos OS Evolved uses a node-based model, where system refers to all nodes, including Routing Engines, Flexible PIC Concentrators (FPCs), and more. In Junos OS Evolved, a node is any component that can run the Linux kernel and Junos OS Evolved applications, and all nodes are considered compute nodes.

Operational Impact

In Junos OS Evolved you can perform many actions on a per-node basis. You can use CLI commands to view information and request operations on individual nodes.

Relevant CLI Commands

  • show system nodes — View a list of all nodes in the system.

  • show node ( reboot | statistics ) node-name — View information about a specific node.

  • show system applications <node node-name> — Display application summary information for all nodes or a specific node.

  • show system core-dumps <node node-name> — Show system core files for all nodes or a specific node.

  • show system errors active—Use this command instead of the show chassis errors active command to view system error information.

  • show system processes <node node-name> <detail> — Display process information for all nodes or a specific node.

  • show system storage node ( re0 | re1 | fpc0 | fpc1 | ...) — View the free disk space for a specific node.

  • show version node ( all | node-name ) — Display software version information for all nodes or a specific node.

  • request node ( halt | offline | online | power-off/on | reboot ) node-name — Request an operation on a specific node.

  • request system reboot — In Junos OS Evolved this command will reboot all nodes.

Software Structure and Applications

Junos OS Evolved functions as a distributed Linux OS with processes running as self-contained applications. Every Junos OS Evolved process runs as an application. All Junos OS Evolved applications are managed by the systemd process using service units. Applications run as separate services, which provides fault isolation because you can restart an application separately without impacting other applications. Most applications publish and consume state, which is stored in a central database.

Operational Impact

In Junos OS Evolved, many high availability features are per-application rather than per-node. Some applications run a full-time backup for rapid failover, while other applications are restarted on a new node in the event of a failure.

Relevant CLI Commands

  • show system applications <node node-name> — Display application summary information for all nodes or a specific node.

  • restart process — In Junos OS this command restarts a specific process. In Junos OS Evolved the same command restarts a specific application (process) on the same node from which the command is issued.

  • request system application restart app application node node — This command is specific to Junos OS Evolved and restarts a specific application on a specific node.

State Model

Junos OS Evolved uses a distributed state infrastructure. Applications publish or subscribe to state objects, which are stored in a state database called the Distributed Data Store (DDS) that is distributed across nodes. By comparison, Junos OS processes store state internally, exchanging state information and state changes with other processes through the kernel. The Junos OS Evolved state model is asynchronous and eventually consistent at the transport layer with causal consistency at the application layer when accessing state. This means that if a process restarts in Junos OS Evolved, information is not lost because it can retrieve state information from the DDS.

Operational Impact

The Junos OS Evolved state model leads to faster performance because you don't have to wait for the slowest component to update. Applications read from and write to system state without waiting for every other process to first complete updates. If an application restarts, state is preserved and retrieved from the DDS by the new instance, even if the application is spawned on a different node.

Software Management

Each time you install a software image on Junos OS Evolved, the previous software image and configuration are preserved automatically. Junos OS Evolved stores software images in the /soft directory. Each version of the software is stored in a distinct area, thus ensuring that a software package installation does not affect the other software versions installed on the system. While Junos OS supports installing two software versions on the device, Junos OS Evolved supports storing as many software images as space allows. However, we recommend that you keep no more than five versions of software on the system.

During a successful installation, the installation package completely re-installs the existing software. It retains configuration files and similar information, such as secure shell and host keys, from the previous version. When you reboot the system after a software package installation, all the Routing Engines and FPCs in the system run the new version of the software.

Operational Impact

Junos OS Evolved ensures that all Routing Engines and FPCs in the system are running the same software version. When you install a software image on the primary Routing Engine, the system installs the new version of software on both Routing Engines, if the Routing Engines are online and part of the system. If you insert a Routing Engine that has a different software version into the system and you have not configured the system auto-sw-sync enable statement, the Routing Engine is kept outside the system, and the system generates a software mismatch alarm.

When you install a new software image, the previous software package is preserved in a separate area, and you can manually roll back to it if necessary. Junos OS Evolved enables you to roll back to an alternate image with either the current configuration file or with the configuration snapshot from when the alternate image was last running.

Relevant CLI Commands

  • show system software list — On Junos OS Evolved, view the currently installed images on each node.

  • show system storage — View available storage space. On Junos OS Evolved, the /soft, /var, and /data directories must have less than 90% capacity to install additional images.

  • request system software delete — Clean up old images. Starting in Junos OS Evolved Release 20.1R1, use this command instead of the request system storage cleanup command to remove ISO images from the system.

  • request system snapshot — Take a snapshot of the files currently used to run the device, and copy the files onto the alternate solid-state drive (SSD). The snapshot includes the complete contents of the /soft, /config, and /root directories, copies of user data, and content from the /var directory (except the /var/core, /var/external, /var/log, and /var/tmp directories).

  • request system software rollback reboot <package-name> <with-old-snapshot-config> — Roll back all Routing Engines and FPCs to another software version and reboot. Include the with-old-snapshot-config option to use the saved configuration that corresponds to the rollback software image.

  • request system software sync ( all-versions | current | rollback ) — Synchronize software and configurations from the primary Routing Engine to the other nodes and reboot the other nodes.

  • set system auto-sw-sync enable — Automatically synchronize the software and the configuration from the primary Routing Engine to a newly added Routing Engine and reboot, when the newly added Routing Engine has a different software version from the rest of the system.

Management Interfaces

On Junos OS Evolved, management interfaces are renamed to accommodate more than one management port per Routing Engine node.

Operational Impact

Management interfaces in Junos OS Evolved do not use the same names as Junos OS (fxp0, em0, me0). Instead, the Junos OS Evolved management interface name format is device-name:type-port. For example: re0:mgmt-0, re0:mgmt-1, re1:mgmt-0, re1:mgmt-1.

The show interfaces output displays the status of all interfaces, including management Ethernet interfaces from both Routing Engines of a dual Routing Engine system.

System Hostnames

In Junos OS Evolved, system hostnames are appended with a corresponding Routing Engine number such as -re0 or -re1.

Operational Impact

In Junos OS Evolved, when you specify the host-name statement, the current Routing Engine name is appended to the hostname you specify. For example, on Routing Engine 0, set system host-name my-host sets the hostname to my-host-re0. You can also use the %s character to designate where to substitute the Routing Engine name. For example, on Routing Engine 1, set system host-name %s_my_host sets the hostname to re1_my-host .

Relevant CLI Commands

  • set system host-name hostname

Routing Engine Firewall Filters

In Junos OS, to control the flow of local packets between the physical interfaces and the Routing Engine, you can apply stateless firewall filters to the input or output of the loopback interface. The loopback interface (lo0) is the interface to the Routing Engine and carries no data packets. In Junos OS, filters applied to the loopback interface apply to both network control traffic and management traffic.

Junos OS Evolved, on the other hand, supports two different filters to control the flow of local packets: one for network control traffic (loopback traffic) and one for management traffic. Thus, filters applied to the loopback interface apply only to network control traffic. You can also apply filters separately to the management interface, which enables you to configure a stricter filter on management traffic.

Operational Impact

In Junos OS Evolved, firewall filters applied to the loopback interface apply only to network control traffic. You must explicitly apply firewall filters to the management interface to filter management traffic. In Junos OS Evolved, management filtering uses Routing Engine filters based on Netfilter, a framework that the Linux kernel provides. As a result, only certain matches and actions are supported. Table 1 outlines the Junos OS Evolved filter application.

Table 1: Filter Application for Network Control Traffic and Management Traffic
Interface Filter Direction Junos OS Evolved Behavior

lo0

input

Filters are applied at the Packet Forwarding Engine and applied on network ingress traffic.

output

Filters are applied at the Routing Engine and applied on network egress traffic.

management

input

Filters are applied at the Routing Engine and applied on management ingress traffic.

output

Filters are applied at the Routing Engine and applied on management egress traffic.

Junos OS Evolved Network Stack

Junos OS Evolved runs on native Linux. There are some differences between the way Linux displays requested network topology information, such as interface and route data, and the way Junos OS displays this information. The Junos OS Evolved CLI is designed to overcome these differences. Thus, we recommend that you use CLI commands rather than shell commands for any network operations, particularly for operations that require specifying a routing instance.

If you must perform operations in the Linux shell when using Junos OS Evolved, you need to know about the following routing instances, also known as virtual routing and forwarding instances (VRFs):

  • default—Handles both WAN and management traffic by default, unless you configure the mgmt_junos routing instance.
  • mgmt_junos—When you configure this routing instance, it puts the management port into its own routing instance, which separates the management traffic from the WAN traffic for the Routing Engine.

  • iri—Handles control plane traffic (internode communication). In the Junos OS Evolved CLI, this is equivalent to the __juniper_private1__ routing instance.

Operational Impact

In the Junos OS Evolved shell, you can use the chvrf (change VRF) utility to execute a command in the context of a specific routing instance, or VRF. For example:

System Logging

In Junos OS Evolved, each node has the standard journalctl tool, which is an interface to retrieve and filter the system journal. System log messages are parsed from the system journal. The relay-eventd process runs on all nodes and retrieves events (based on the syslog configuration) from the system journal as well as error messages from the different applications and forwards them to the master-eventd process. The master-eventd process runs on the primary Routing Engine and writes the log messages and errors to disk.

Use the System Log Explorer application to view or compare system log messages in different releases.

Operational Impact

In Junos OS Evolved there is no messages file on the backup Routing Engine. All backup Routing Engine logs are in the messages file on the primary Routing Engine node.

System Log Message Format

By default, Junos OS Evolved appends the node name to the hostname in system log messages; Junos OS does not. This action keeps Junos OS Evolved system log messages compliant with RFC5424. However, some monitoring systems may not identify a Junos OS Evolved hostname correctly, because the hostname-node name combination does not match any hostnames in the inventory of hostnames.

Operational Impact

If your monitoring system is not identifying Junos OS Evolved hostnames correctly, you should issue the set system syslog alternate-format configuration mode command. This command changes the format of the Junos OS Evolved system log messages. The node name is prepended to the process name in the message rather than appended to the hostname, thereby allowing the monitoring system to identify the hostname correctly.

Tracing Architecture

Junos OS Evolved uses a new tracing architecture. All running applications create trace information, with multiple instances of the same application having their own trace information. The Junos OS Evolved trace-relay and trace-writer applications coordinate tracing information. The trace-relay application runs on local nodes and shares a memory buffer with each application. When a Junos OS Evolved application writes to memory, the trace-relay application reads the data directly from memory and sends it to the trace-writer applications. A trace-writer application runs on each Routing Engine node. It receives the trace information sent from the trace-relay applications and writes it to the appropriate file in Common Trace Format (CTF).

Note:

For general monitoring and troubleshooting of devices running Junos OS or Junos OS Evolved, we recommend using standard tools such as CLI show commands, system log messages, SNMP, and telemetry data. You should avoid using trace messages for general debugging purposes and long-term solutions because they are subject to change without notice.

Operational Impact

In Junos OS, you enable tracing operations by configuring the traceoptions statement at the specific hierarchy level you want to trace. Junos OS Evolved, on the other hand, uses an application-based model, and thus trace messages are logged, viewed, and configured by application. As a result, Junos OS Evolved does not support the traceoptions statement at many of the hierarchy levels that Junos OS supports. However, some hierarchy levels, such as those under [edit protocols], still require configuring the traceoptions statement to enable trace messages.

Although Junos OS disables global tracing operations for many hierarchy levels by default, some processes log trace messages by default for important events. In contrast, all running applications on Junos OS Evolved create trace information at the info level by default.

In Junos OS Evolved, you do not view trace files directly, and you should never add, edit, or remove trace files under the /var/log/traces directory because this can corrupt the traces. Instead, you use the show trace application application-name node node-name command to read and decode trace messages stored in the trace files.

Relevant CLI Commands

  • show trace application application-name node node-name — Read and decode trace files.

  • clear trace — Manually clean up trace files.

  • set system trace application — Modify trace message configurations at the application level.