CLI User Guide for Junos OS

 The Junos OS command-line interface (CLI) is a command shell specific to Juniper Networks. This command shell runs on top of the FreeBSD UNIX-based operating system kernel for Junos OS. Using industry-standard tools and utilities, the CLI provides a powerful set of commands that you can use to monitor and configure Juniper Networks devices running Junos OS. This guide contains information about the CLI for Junos OS.

 The Junos OS CLI Guide explains how to use the command-line interface (CLI). This guide also describes advanced concepts and device configuration when working with Juniper Networks devices running Junos OS.

In this guide, you will learn about:

• Using configuration statements to configure network devices

• Managing device configurations

• Using operational commands to monitor devices

• Syntax for configuration statements, operational commands, and environmental commands

For a basic introduction to Junos OS, see the Getting Started Guide for Junos OS. It provides a high-level description of Junos OS, describes how to access devices, and provides simple step-by-step instructions for initial device configuration.

For a technical and detailed exploration of Junos OS, see the Overview for Junos OS. It further explains how Junos OS works and describes the security, configuration, monitoring, and management of network devices.

Another useful learning resource is Day One: Exploring the Junos CLI.

 

The CLI is the software interface used to access your device. You use the CLI to configure the device, monitor its operations, and adjust the configuration as needed. You access the CLI through a console connection interface or through a network connection.

Introducing the Command-Line Interface

The Junos OS CLI is a command shell specific to Juniper Networks that runs on top of the operating system kernel. Through industry-standard tools and utilities, the CLI provides a powerful set of commands that you can use to monitor and to configure devices running Junos OS.

The CLI has two modes:

• Operational mode—Use this mode to display the current status of the device. In operational mode, you enter commands to monitor and to troubleshoot the network operating system, devices, and network connectivity.

• Configuration mode—Use this mode to configure the device. In this mode, you enter statements to configure all properties of the device, including interfaces, general routing information, routing protocols, user access, and several system and hardware properties. Junos OS stores a configuration as a hierarchy of configuration statements.

  When you enter configuration mode, you are viewing and changing a file called the candidate configuration. You use the candidate configuration file, you make configuration changes without causing operational changes to the current operating configuration, called the active configuration. The device does not implement the changes you added to the candidate configuration file until you commit the changes. Committing the configuration changes activates the revised configuration on the device. Candidate configurations enable you to alter your configuration without damaging your current network operations.

Key Features of the CLI

The CLI commands and statements follow a hierarchical organization and have a regular syntax. The CLI provides the following features to simplify CLI use:

• Consistent command names—Commands that provide the same type of function have the same name, regardless of the specific device type on which you are operating. For example, all show commands display software information and statistics, and all clear commands erase various types of system information.

• Lists and short descriptions of available commands—The CLI provides information about available commands t each level of the command hierarchy. If you type a question mark (?) at any level, you see a list of the available commands along with a short description of each. This means that if you are already familiar with Junos OS or with other routing software, you can use many of the CLI commands without referring to the documentation.

• Command completion—Command completion for command names (keywords) and for command options is available at each level of the hierarchy. To complete a command or option that you have partially typed, press the Tab key or the Spacebar. If the partially typed letters begin a string that uniquely identifies a command, the complete command name appears. Otherwise, a beep indicates that you have entered an ambiguous command, and the CLI displays possible completions. Completion also applies to other strings, such as filenames, interface names, usernames, and configuration statements.

  If you have typed the mandatory arguments for executing a command in operational mode or configuration mode, the CLI displays <[Enter]> as one of the choices when you type a question mark (?). This output indicates that you have entered the mandatory arguments and can execute the command at that level without specifying any further options. Likewise, the CLI also displays <[Enter]> when you reach a specific hierarchy level in the configuration mode and do not need to enter any more mandatory arguments or statements.

• Industry-standard technology—With FreeBSD UNIX as the kernel, a variety of UNIX utilities are available on the CLI. For example, you can:

  • Use regular expression matching to locate and to replace values and identifiers in a configuration, to filter command output, and to examine log file entries.

  • Use Emacs-based key sequences to move around on a command line and scroll through the recently executed commands and command output.

  • Store and archive Junos OS device files on a UNIX-based file system.

    Use standard UNIX conventions to specify filenames and paths.

    Exit the CLI environment and create a UNIX C shell or Bourne shell to navigate the file system, manage router processes, and so on.

CLI Modes, Commands, and Statement Hierarchies—An Overview

The Junos OS CLI commands and statements are organized under two command modes and various hierarchies. The following sections provide an overview of the CLI command modes and the command and statement hierarchies.

• CLI Command Hierarchy
• Configuration Statement Hierarchy
• Move Among Hierarchy Levels

CLI Command Hierarchy

CLI commands are organized in a hierarchy. Commands that perform a similar function are grouped together under the same level of the hierarchy. For example, all commands that display information about the system and the system software are under the show system command. All commands that display information about the routing table are under the show route command.

To execute a command, enter the full command name, starting at the top level of the hierarchy. For example, to display a brief view of the routes in the routing table, use the command show route brief.

Configuration Statement Hierarchy

The configuration statement hierarchy has two types of statements: Container statements, which are statements that contain other statements, and leaf statements, which do not contain other statements. All the container statements and leaf statements together form the configuration hierarchy.

The following illustration shows a part of the hierarchy tree. The protocols statement is a top-level statement at the trunk of the configuration tree. The ospf, area, and interface statements are all subordinate container statements of a higher statement; that is, they are branches of the hierarchy tree. The hello-interval statement is a leaf on the tree.

Figure 1: Configuration Statement Hierarchy Example

Move Among Hierarchy Levels

The following table shows the CLI commands you use to navigate the levels of the configuration statement hierarchy.

Table 1: CLI Configuration Mode Navigation Commands

Command	Description
edit hierarchy-level	Moves to an existing configuration statement hierarchy or creates a hierarchy and moves to that level.
exit	Moves up the hierarchy to the previous level where you were working. This command is, in effect, the opposite of the edit command. Alternatively, you can use the quit command. The exit command and the quit command are interchangeable.
up	Moves up the hierarchy one level at a time.
top	Moves directly to the top level of the hierarchy.

Other Tools to Configure and Monitor Juniper Networks Devices

Apart from the CLI, Junos OS also supports the following applications, scripts, and utilities that enable you to configure and monitor Juniper Networks devices:

• J-Web GUI—Available on select Juniper Networks devices, the J-Web GUI enables you to monitor, configure, troubleshoot, and manage the device by means of a browser with HTTP or HTTPS enabled. For more information, see the J-Web Interface User Guide.

• Junos XML management protocol—The Junos XML management protocol enables you to monitor and configure Juniper Networks devices. For more information, see the Junos XML Management Protocol Developer Guide.

• NETCONF API—You can also use the NETCONF XML management protocol to monitor and configure Juniper Networks devices. For more information, see the NETCONF XML Management Protocol Developer Guide.

• Commit scripts and self-diagnosis features—You can define scripts to enforce custom configuration rules, use commit script macros to provide simplified aliases for frequently used configuration statements, and configure diagnostic event policies and actions associated with each policy. For more information, see the Junos OS Automation Scripting User Guide.

• MIBs—You can use enterprise-specific and standard MIBS to retrieve information about the hardware and software components on a Juniper Networks device. For more information about MIBs, see the Junos OS Network Management Administration Guide for Routing Devices.

Configure Junos OS in a FIPS Environment

With Junos-FIPS you can configure a network of Juniper Networks devices in a FIPS 140-2 environment.

The Junos-FIPS software environment requires the installation of FIPS software by a Crypto Officer. In Junos-FIPS, some Junos OS commands and statements have restrictions and some additional configuration statements are available. For more information, see the following resources:

• Common Criteria and FIPS Certifications—Provides links to guidelines for configuring Juniper Networks devices so the secure environment complies with the requirements of public sector certifications such as Common Criteria and FIPS certification.

• Compliance Advisor—A Web application that provides regulatory compliance information about Common Criteria, FIPS, Homologation, ROHS2, and USGv6 for Juniper Networks products.

   

   

Junos OS Release 23.2R1

 

Junos OS runs on the following Juniper Network's ® products: ACX Series, cRPD, cSRX, EX Series, JRR Series, Juniper Secure Connect, MX Series, NFX Series, QFX Series, SRX Series, vMX, vRR, and vSRX. These release notes accompany Junos OS Release 23.2R1. They describe new and updated features, limitations, open and resolved problems in the hardware and software.

You can find release notes for all Junos OS releases at https://www.juniper.net/documentation/product/us/en/junos-os#cat=release_notes.

What is Juniper Paragon Active Assurance?

Juniper Paragon Active Assurance is a programmable, active test and monitoring solution for physical, hybrid, and virtual networks. 

It turns the Cloud Metro network into a distributed sensor for assuring user experience proactively, which removes the need to deploy additional, standalone probe hardware. 

(To learn more, see the Juniper Cloud Metro as the Experience Sensor solution sheet.) With the capability of emulating 5G UE/gNB, service providers can now simulate traffic for both the control plane and user plane, ensuring each 5G network slice meets expected service level agreements (SLAs).

Junos Upgrade FAQs and Junos End-of-Support (EOS) enforcement notification for 17.x, 18.x, and 19.x

Alert Type PSN - Product Support Notification RiskRisk Description Medium End of Support (EOS) notification ImpactImpact Description Medium End of Support (EOS) notification Product Affected M-Series, MX-Series, T-Series, PTX-Series, ACX-Series, EX-Series, QFX-Series, SRX-Series Alert Description Notification of technical support eligibility: Effective April 2, 2025, support for Junos software release 17.x will no longer be accepted; only cases eligible for hardware support (including RMAs) will continue. Effective October 1, 2025, support cases for Junos software releases 18.x and 19.x will no longer be accepted; only cases eligible for hardware support (including RMAs) will continue. Solution For complete details, including FAQs for hardware exceptions and next steps, read:Junos EOS enforcement notification for 17.x, 18.x, and 19.x

Junos OS® Evolved: Juniper’s Industry-Leading Network Operating System (NOS) for the Future

Juniper Networks developed the Junos OS® Evolved disaggregated network operating system (NOS) building on the strengths of the Junos operating system, to bring industry leading routing and switching solutions to a native Linux environment. Junos OS Evolved provides a modern, programmable, highly available and resilient platform and at the same time, delivers a secure execution environment. This blog offers “a peek under the hood,” and is the first in a series where we will discuss the Junos OS Evolved system, take a deep dive into the capabilities and review the design choices that brought these capabilities to life. Core Architecture Almost all important characteristics of a system can be traced to a handful of fundamental choices that form the foundation of the NOS, including the choice of the environment and the choice of the communications infrastructure. Some may argue that these choices ultimately play a larger role in the system characteristics than the actual implementation itself. At Juniper, we believe that the intent, as expressed in these choices and the quality of the implementation, play equal roles. Choice of the environment – Picking the battlefield in which to wrestle with the problem space is one such choice. An argument can be made that the most efficient way to solve some of the core problems in a network operating system (NOS) are by doing this within the operating system kernel, by customizing and extending a standard kernel or by building a proprietary kernel. The Junos OS Evolved system chose to perform most operations in the Linux user space, recognizing that the kernel is a particularly anemic environment in which to develop rich features. The kernel is well suited to manage shared resources and the physical hardware, but any efficiency gains or optimizations obtained by building key communications infrastructure inside the kernel are easily offset by the lack of agility in that environment. Choice of communications infrastructure – Junos OS Evolved, at the very core, uses a formally modelled state-based, persistent and self-compressing publish-subscribe mechanism for all inter-process interactions. The communications infrastructure handles all aspects of marshalling and demarshalling, addressing, delivery and back pressure, enabling applications to focus exclusively on their business logic. The pub-sub system removes any space and time coupling between the sender and the receiver(s) bringing in the much-needed isolation between processes when there are failures, along with advanced capabilities like the ability to transparently distribute processes across distinct compute nodes. Contrast this with a system based on multiple point-to-point connections each needing to get involved on a component/service failure and the advantages of a pub-sub system are clear. State-based – All exchanges over the Junos OS Evolved pub-sub system are modelled as state updates that owners of state publish and to which consumers react. These exchanges are distinctly different from systems where message exchanges drive changes in state that are always internal to the application. Such systems suffer from message explosion problems due to fast changing external triggers that cannot be compressed, as computation of the final state relies on visibility into all intermediate state transition driven by individual messages. This aspect is fundamental and key to ensuring that the information seen on the pub-sub system is always complete and usable for reconstructing application state on a failure. Self-compressing – The number of events are not bounded in a typical NOS as these are the result of external triggers, such as an unstable interface link that keeps flapping or a peer device gone bad. On the other hand, the total state in a system is bounded, at least to the extent that one can model the upper bound more accurately. Subscribers to the Junos OS Evolved pub-sub system rely only on the final state, allowing the system to compress intermediate state updates to slow consumers. This is critical in preventing unbounded queuing in the system when under network churn and in the presence of a slow consumer. Formal modelling – All state is formally modelled using Domain Specific Languages (DSLs) that describe every bit of information encapsulated by the object. This includes field information and relationship information, tying together individual state objects into a larger directed acyclic graph of information that makes up the operational state of a router/switch. Formal modelling elevates this meta-data information from inside the application code to a plane that is visible, inspectable to generic application-agnostic infrastructure layers. This opens up a whole host of new possibilities around automatic failure detection and modern tooling to view the system state in a more intuitive manner, some of which we will discuss in future blogs. Persistent – The pub-sub system guarantees persistence of state objects, allowing services to handle failures and upgrades with minimal impact. A service restart does not need to be coordinated with adjacent services due to the lack of time coupling in a pub-sub model. State persistence allows simple reconciliation schemes at the service level to minimize impact. Upgrades are restarts of a service into a new version of the software. Visibility – Visibility was a key design factor in the system. Data is exposed to the infrastructure, not only because there is a need today, but because there may be a need tomorrow. Juniper built the system to eliminate the need to go back and add probes or logging. The extensive analytics and visibility design ensures that all interactions are modeled and inspectable. It also ensures that any new feature comes with visibility enabled by default. This is key for both managing the infrastructure and integrating applications with Junos OS Evolved to enable deeper integration and better management. Security – There is an age-old battle in networking between security and flexibility. Junos OS Evolved provides a secure execution environment based on the Linux IMA stack. This design provides security while also providing the flexibility to modify software as well as install your own agents and applications. All of the Juniper provided software is signed and if it has been tampered with, it will not run in the system. We also provide the ability to use your own keys to sign any modifications or custom components that your IT team has produced, tested and approved to run in the system. The ability to sign these modifications and custom components with your own keys ensures their authenticity and allows them to run in the system. Software Upgrades – Software upgrades in a modern cloud environment need to be agile and reliable with minimal impact. In order to achieve this, a component-based architecture that views the system as a versioned collection of granular pieces of independent software is required. This architecture enables smart software upgrades required for feature velocity, quality and a hitless upgrade process, thus increasing the availability and performance of your infrastructure – even during upgrades. With Junos OS Evolved, we have brought our industry leading routing and switching solutions to a native Linux environment. In doing so, we have simplified network operations with a highly scalable unified end-to-end network OS while providing the reliability, quality, agility, visibility, open programmability and simplicity to facilitate cloud operator success with a flexible and cost-effective network infrastructure at cloud scale.

Junos OS Release Numbers

The release number represents a particular revision of the software that runs on a Juniper Networks routing platform, for example, Junos OS Release 14.1,14.2, 15.1, or 17.1. Each release has certain new features that complement the software processes that support Internet routing protocols, control the device’s interfaces and the device chassis itself, and allow device system management. On the Juniper Networks Support web page, you download software for a particular release number. In this example, we dissect the format of the software release number to show what it indicates. The generalized format is as follows: Given the format of m.nZb.s The software release number 17.2R1.13, for example, maps to this format as follows: m is the main release number of the product, for example, 17. n is the minor release number of the product, for example, 2. Z is the type of software release, for example, R for FRS or maintenance release. For types of software releases, see Table 4. b is the build number of the product, for example, 1, indicating the FRS rather than a maintenance release.. s is the spin number of the product, for example, 13. Table 4: Software Release Types Release Type Description R First revenue ship (FRS) or maintenance release software. R1 is FRS. R2 onward are maintenance releases. F Feature velocity release. Feature velocity releases are only in Junos OS Release 15.1. B Beta release software. I Internal release software. These are private software releases for verifying fixes. S Service release software, which are released to customers to solve a specific problem—this release will be maintained along with the life span of the underlying release. The service release number is added after the R number, for example, 14.2R3-S4.4. Here S4 represents the 4th service release on top of 14.2R3 and is the 4th re-spin. X Special (eXception) release software. X releases follow a numbering system that differs from the standard release numbering. Starting with Junos OS Release 12.1X44-D10, SRX Series Firewalls follow a special naming convention for Junos OS releases. For more information, refer to the Knowledge Base article KB30092 at https://kb.juniper.net/InfoCenter/index?page=home. Note: Prior to Junos OS Release 11.4, the software release number format for service releases was same as other releases. For example, 10.4S4.2 represented the 4th service release and 2nd re-spin of 10.4.