Ssfjun01j ML5

e d u c a t io n se rv ic e s c o u rse w a re
Junos Operating System

Highlights
Student Guide
Junos Operating System Highlights
NOTE: Please note this Student Guide has been developed from an audio narration. Therefore it will have
conversational English. The purpose of this transcript is to help you follow the online presentation and may require
reference to it.
Slide 1
Build the Best
2015 Juniper Networks, Inc. All rights reserved. CONFIDENTIAL SSFJUN01J-ML5 www.juniper.net | 1
Course SSFJUN01J-ML5 Juniper Networks, Inc. 2

Slide 2
2015 Juniper Networks, Inc. All rights reserved. | www.juniper.net | Proprietary and Confidential
Welcome to Juniper Networks Junos Operating System Highlights eLearning module.

Slide 3
Navigation
Throughout this module, you will find slides with valuable detailed information. You can stop any slide with the Pause
button to study the details. You can also read the notes by using the Notes tab. You can click the Feedback link at any
time to submit suggestions or corrections directly to the Juniper Networks eLearning team.

Slide 4
Course Objectives
After successfully completing this course, you will be

able to:
Provide an overview of the Junos OS and its benefits
Explore Junos OS architecture and design
Describe the Juniper platforms running the Junos OS
Explore routing using the Junos OS
Discuss the tools and resources available to help customer
transition to the Junos OS
After successfully completing this course, you will be able to:

Provide an overview of the Junos OS and its benefits;
Explore Junos OS architecture and design;
Describe the Juniper platforms running the Junos OS;
Explore routing using the Junos OS; and
Discuss the tools and resources available to help customer transition to the Junos OS.

Slide 5
Agenda: Junos Operating System Highlights
An Introduction to the Junos OS

The Command-line Interface
Configuration Commands and Process
Junos OS Routing
Junos OS Adoption
This course consists of five sections. The five main sections are as follows:
An Introduction to the Junos OS;
The Command-line Interface;
Configuration Commands and Process;
Junos OS Routing; and
Junos OS Adoption.

Slide 6

Slide 7
Section Objectives
After successfully completing this section, you will be

able to:
Provide an overview of the Junos OS
Describe the Junos OS architecture
Describe the Juniper platforms running the Junos OS
After successfully completing this section, you will be able to:

Provide an overview of the Junos OS;
Describe the Junos OS architecture; and
Describe the Juniper platforms running the Junos OS.

Slide 8
Junos OS Overview
A common language across Junipers routing,

switching, and security devices
Reduces complexity, increases availability, lowers TCO
Routing Switching Security

Junos OS Overview
Juniper Networks Junos OS provides a common language across Junipers routing, switching and security devices.
The power of one Junos OS reduces complexity in high-performance networks to increase availability and deploy
services faster with lower TCO.
The consistent user experience and automated toolsets of the Junos OS makes planning and training easier, day-to-
day operations more efficient, and changes in the network faster. Furthermore, one operating system integrating new
functionality in software protects customer investment, not only in hardware, but also in internal systems, practices,
and knowledge. That means not only lower TCO, but also greater flexibility in meeting the new needs and
opportunities of the business.

Slide 9
Increasing Demands on
High-Performance Networks
The network runs the operations of high-performance
enterprise and service provider businesses
Legacy network software carries limitations:
Complex, error-prone administration tasks
Multiple release trains and software versions
Monolithic software architectures
The solution begins with greater confidence in the
underlying network foundation
Increasing Demands on High-Performance Networks
The network fundamentally runs the operations of high-performance enterprise and service provider businesses.
Complex networks that require extensive rework to scale and change can slow down marketplace response and new
business initiatives.
While old hardware and outdated or poorly integrated technologies present challenges, it is the software running in IP
networks that consumes the most operational time, causes the majority of operational headaches, and creates
obstacles to change. Largely based on source code initially built decades ago, legacy network software carries a
number of limitations, including the following:
Complex, error-prone administration tasks, which not only add time and effort to routine activities, but also multiply
the risk of human error that can lead to outages or create security vulnerabilities.
Multiple release trains and software versions, which slow down network upgrades with requirements for extensive
testing, qualification, and training, while impacting the predictable delivery of new service features and fixes.
Monolithic software architectures, which impact network stability, performance, and security with comingled
operating system processes vying for the same shared computing resources, and where even a small problem in
one process can cascade to affect many others.
So, how can you develop a network that cost-effectively scales with traffic growth, adapts along with changing
business needs, and delivers new services, all while maintaining the operational stability of your infrastructure?
The solution begins with greater confidence in the underlying network foundation. If you can trust the software
supporting your infrastructure, particularly in its most strategic and distributed components, your team can focus more
of its time and effort keeping up with traffic demand as well as new application and business requirements.

Slide 10
Junos OS: The Foundation of

High-Performance Networks
The Junos OS reduces the complexity of network
design and operation
Key Advantages
One OS across all types and sizes of platforms
A single software train with a steady release cadence
Modular architecture
Junos OS: The Foundation of High-Performance Networks
The Junos OS provides a common language across Junipers routing, switching, and security devices, and that
reduces the complexity of not only the network design, but also its operation.
The following key advantages of the Junos OS are derived primarily from how it is built:
Having one operating system across all types and sizes of platforms reduces the time and effort to plan, deploy,
and operate network and security infrastructure;
A single software release train with a steady release cadence meets changing needs in software with stable
delivery of new functionality in a steady, time-tested cadence; and
A modular software architecture provides highly available, secure and scalable software that is open to
automation and partner innovation.

Slide 11
Modular Architecture
Modular
Independent operation for resiliency
Extensible design for new innovation
Management
Interfaces
Module n
Scalable
Control Plane
Routing
Up: distributed hardware
Down: flexible packaging for small
systems
...
Open Kernel
Automation APIs for on-box control
and integration to off-box systems
Junos SDK for application
development
SDK = software development kit
2015 Juniper Networks, Inc. All rights reserved. CONFIDENTIAL SSFJUN01J-ML5 www.juniper.net 36
| 11
Modular Architecture
Lets take a look at some of the architecture highlights of the Junos OS.
First, the architecture is modular. So, if you are not a software engineer, why do you care about this? Well, the bottom
line is this: dedicated resources means high resiliency, which gives you the high availability that carriers rely on. Small
problems do not become big ones, and are easier to find. Carrier class resiliency is what the Junos OS provides,
along with flexibility for innovation. Juniper can roll out new functionality by building a new module and putting it into
this same model, as shown on this slide.
Additionally, the software has been designed from the beginning for scalability. System designers can provide
dedicated hardware for different functions where neededwhether its for control, forwarding, or servicesand it still
all works as one system. Not only does the architecture scale up, but it also scales down with flexible packaging for
small systems.
A third highlight is the open interfaces for automation and applications development which lets our partners customize
and extend the deployment of the Junos OS to each of their customers unique environments.

Slide 12
A Single Software Release Train
Disciplined process for development

New versions build upon the prior, so features remain
Each new release supports each product family
Code set optimized for role and application in the network
When ready to upgrade, simply choose and qualify a
higher release number
11.4 12.3 13.2 13.3
2015 Juniper Networks, Inc. All rights reserved. CONFIDENTIAL SSFJUN01J-ML5 www.juniper.net 35
| 12
A Single Software Release Train
In significant contrast to its primary competitors, Juniper extends the Junos OS in a single software release train under
a disciplined process of development. New releases build upon the prior, creating a single train delivered in a series of
numbered versions.
Each new release supports each product family with the code set optimized for its role and application in the network.
Whenever customers are ready to upgrade, they simply choose and qualify a higher release number than their current
version.

Slide 13
X Releases (1 of 2)
Allows for the rapid introduction of new security

capabilities
Ensures that new security services are introduced
rapidly
While maintaining the quality and stability on the Junos OS
12.1 13 14
12.1X44 12.1X45 12.1X46
X Releases: Part 1
For certain platforms, (in particular the SRX Series) Juniper has adopted a software release model that allows for the
rapid introduction of new security capabilities. At the same time, the security services will leverage the architectural
underpinnings of the Junos OS including the CLI, scripting, and core capabilities. This release model ensures that new
security services are introduced rapidly, while quality and stability on the Junos OS is maintained.
Juniper is using a Junos OS base that is updated at a slower pace to release new security features at a faster
cadence, using special security-focused releases called X releases. The first security release train was X44. The
specific release number for X44 is D10, and the Junos base version is 12.1. The release is therefore referred to as
12.1X44-D10.
It is planned to continue the security X releases, with two X releases planned annually. The Junos OS base version for
the X releases will be updated at a slower regular cadence, and the security X releases will occur at a faster cadence.

Slide 14
X Releases (2 of 2)
X Releases
Time to market
Quality SRX100
One Junos SRX5800
12.1 13 14
12.1X44 12.1X45 12.1X46
X Releases: Part 2
Juniper has adopted the new software release model for security, for several reasons:
Time to market: Accelerate time to market for security services on top of the Junos OS. This X release model
facilitates the fast introduction of new security services, while leveraging the key capabilities of the Junos OS.
Quality: Higher stability and quality of both the Junos OS and the SRX Series as well as other security products. X
releases promote stability and thus higher quality of the layered security services on the Junos OS.
One Junos: Enhance One Junos by leveraging the architectural underpinnings of the Junos OS (such as the CLI,
scripting, and core capabilities) in the security-focused X releases.

Slide 15
Separation of Control and Forwarding
The control plane is where the RE runs

The brains of the system
The data plane is where the PFE runs
The brawn of the system
Control Plane
Benefits: Routing
Provides superior performance Engine
Highly reliable
Data Plane
Packet Forwarding
Engine
Separation of Control and Forwarding
From the beginning, Juniper engineers decided to separate the functions of control and forwarding. The diagram on
the slide shows a very basic illustration of the architecture. The control plane, shown above the dotted line, runs the
Routing Engine (RE). The data plane, shown below the dotted line, is the Packet Forwarding Engine (PFE).
Think of the control plane (RE) as the brains of the system. It is responsible for performing protocol updates and
system management. The routing table, bridging table, and primary forwarding table are maintained by the RE which
connects to the PFE through an internal link. The forwarding plane (PFE) is responsible for forwarding transit traffic
through the device and usually runs on separate hardware. Think of this as the brawn of the system. The forwarding
plane is responsible for the high throughputit takes the packets it receives, inspects them, and moves them through
the network quickly.
The primary benefit is that, because this architecture separates control operations from forwarding operations,
platforms running the Junos OS can deliver superior performance and highly reliable deterministic operation.

Slide 16
Routing Engine and

Packet Forwarding Engine Routing protocol and
control processes
System management
User access
CLI and J-Web GUI
Routing Engine
RT FT
Junos
OS
Control Plane Internal link
Data Plane
FT
frames/packets in frames/packets out
Packet Forwarding Engine

Copy of the FT
Layer 2 bridging information
Forwards packets and frames
Routing Engine and Packet Forwarding Engine
Lets look at the architecture in more detail.
The Routing Engine is the portion of the device that handles all routing protocol processes as well as other software
processes that control the routers interfaces, some of the chassis components, system management, and user
access to the router. The RE provides the CLI as well as the J-Web GUI.
The routing table (RT) is stored and maintained on the RE. The routing table is used to build the forwarding table (FT).
The PFE receives a synchronized copy of the forwarding table from the RE by means of the internal link. Storing and
using a local copy of the forwarding table allows the PFE to forward traffic more efficiently and eliminates the need to
check with the RE every time a packet needs to be processed. Using this local copy of the forwarding table also
allows devices running the Junos OS to continue forwarding traffic during control plane instabilities. The PFE also
maintains Layer 2 bridging information.
Because the RE is the brains and the PFE is the brawn, the PFE can simply perform as it is instructedforwarding
frames and packets with a high degree of stability and performance. This architectural design also makes it possible to
incorporate high availability features such as graceful Routing Engine switchover (GRES), nonstop active routing
(NSR), and unified in-service software upgrades (ISSUs).

Slide 17
Junos OS Platforms
Routing
Switching
Security
Virtual
Junos OS Platforms
Juniper Networks drives Junos OS innovation through its disciplined development as one network operating system.
Juniper solutions provide consistency and reliability with routing, switching, security, and virtual platforms run by the
same operating system across the high-performance network infrastructure. Junipers extensive portfolio connects
branch and regional offices, central sites and data centers, along with the metro, edge, and core sites of service
provider networks. Juniper is leveraging its heritage of best-in-class services and security technology by delivering a
broad set of intelligent and dynamic services in the Junos OS for security, broadband, voice, and video.

Slide 18
Routing Platforms
ACX Series LN Series M Series
MX Series PTX Series T Series
Routing Platforms
The following Juniper routing platforms run the Junos OS.
ACX Series: Powered by Juniper Networks Junos OS, the ACX Series routers complement Junipers universal edge
solutions through a flexible and scalable service provider and enterprise branch routing portfolio optimized to support
rapidly growing mobile, video, and cloud computing applications. The ACX Series introduces Junipers proven
IP/MPLS leadership from the core and edge into the access layers of the network.
LN Series: The LN Series Secure Routers provide high-performance network routing, next-generation firewall, and
unified threat management capabilities in a single platform. These devices are hardened to provide secure
connectivity to the harshest fixed and mobile environments such as remote substations, industrial manufacturing sites,
and transportation facilities.
M Series: M Series Multiservice Edge Routers combine IP/MPLS capabilities with reliability, security, and service
richness. Enterprises and service providers use the M Series in small core, multiservice edge, collapsed POP routing,
peering, route reflector, as well as campus and WAN gateway applications.
MX Series: MX Series 3D Universal Edge Routers are a portfolio of high-performance, software-centric physical and
virtual routers that support a broad set of applications in service provider, enterprise and cloud networks. With
powerful routing, switching, and services capabilities, the MX Series delivers unmatched flexibility and investment
protection.
PTX Series: The PTX Series Packet Transport Routers are the core router of choice for very high volume networks.
PTX Series Converged Supercore platforms are built for superior performance, transport integration, and elegant
deployment, supporting high-density 100-Gigabit Ethernet environments while delivering industry-leading energy
efficiency of up to 0.57 watts per Gbps.
T Series: T Series Core Routers include the features, functionality, scale, flexibility and availability requirements for a
multiservice core. The T Series platform with the TX Matrix Plus provides unparalleled investment protection and an
incremental in-service upgrade path to deliver system scale from a 640 Gbps single chassis system to up to 22 Tbps
multichassis system.

Slide 19
Switching Platforms
EX Series QFX Series
OCX Series
Switching Platforms
Junipers three switching platforms also run the Junos OS.
EX Series: These carrier-class switching solutions are for converged enterprise branch offices, campuses, and data
centers, as well as for service provider deployments. They address escalating demands for high availability, unified
communications, mobility, and virtualization within enterprise networks. Virtual Chassis and Virtual Chassis Fabric
technologies on select models enable multiple interconnected EX Series switches to operate as a single device,
reducing operational expense and management complexity.
QFX Series: QFX Series switches are high-performance, high-density platforms that satisfy the needs of todays most
demanding enterprise and service provider environments. Designed for top-of-rack, end-of-row, and spine-and-core
aggregation deployments in modern data centers, QFX Series switches can be deployed as 10-Gigabit Ethernet, 40-
Gigabit Ethernet, or 100-Gigabit Ethernet access, spine, core, or aggregation devices in Virtual Chassis, Virtual
Chassis Fabric, Multi-Chassis LAG and Junos Fusion architectures.
OCX Series: The currently available model in this series is the OCX1100. The OCX1100 is an open networking switch
based on hardware specifications ratified by the Open Compute Project (OCP). Combining a cloud-optimized OCP-
submitted hardware design with the industry-proven and feature-rich Junos OS, the OCX1100 gives customers all of
the benefits of an open source hardware design with none of the compromises.

Slide 20
Security Platforms
SRX Series
Security Platforms
The SRX Series Services Gateways are the Juniper Networks security platform running the Junos OS.
SRX Series: The SRX Series are next-generation firewalls offering high-performance security with advanced,
integrated threat intelligence, delivered on the industry's most scalable and resilient platform. The SRX Series offers a
broad range of options, from all-in-one, integrated physical and virtual security networking devices, to highly scalable,
chassis-based data center solutions that can defend enterprise data centers and service providers of any size.

Slide 21
The Junos OS on Virtual Platforms
Virtual SRX (vSRX)

Based on the SRX Series
vSRX
Virtual MX (vMX)
Based on the MX Series
vMX
The Junos OS on Virtual Platforms
The Junos OS can also run as a virtual machine (VM) using either VMware or KVM as the host software. Two
products are currently availablevirtual SRX (vSRX) and virtual MX (vMX).
vSRX Services Gateway (formerly known as Firefly Perimeter) delivers a complete virtual firewall solution, including
advanced security, robust networking, and automated VM life-cycle management capabilities for service providers and
enterprises. vSRX empowers security professionals to deploy and scale firewall protection in highly dynamic
environments. Based on the SRX Series Services Gateways, vSRX extends the SRX Series capabilities to virtualized
and cloud environments.
The vSRXs automated provisioning capabilities, enabled through Junos Space Virtual Director, allow network and
security administrators to quickly and efficiently provision and scale firewall protection to meet the dynamic needs of
virtualized and cloud environments. By combining the vSRXs provisioning application with the power of Junos Space
Security Director, administrators can significantly improve policy configuration, management, and visibility into both
physical and virtual assets from a common, centralized platform.
vMX is a virtual MX Series 3D Universal Edge Router that extends over 15 years of Juniper Networks edge routing
expertise to the virtual realm. The vMX is a full-featured, carrier-grade router with complete control, forwarding, and
management planes. It runs the Junos OS, and supports vTrio packet handling and forwarding by compiling the
programmable Junos Trio chipset microcode for x86 chipsets.
With its granular, pay as you grow licensing model, the vMX reduces the risk associated with new market entry and
service innovation and allows you to start small, move fast, and stay profitable. Not only is it an ideal platform for
markets and applications that are difficult to serve with traditional hardware routers, it is also a great option for proof of
concept validation, lab testing, and feature and release certification.

Slide 22
Section Summary
In this section, we:

Provided an overview of the Junos OS
Described the Junos OS architecture
Described the Juniper platforms running the Junos OS

Provided an overview of the Junos OS;
Described the Junos OS architecture; and
Described the Juniper platforms running the Junos OS.

Slide 23
Learning Activity 1: Question 1
The Junos OS provides a common language across

which three of Junipers networking platforms?
(Choose three.)
A. Security
B. Switching
C. Routing
D. Wireless

Slide 23
True or false: Using a local copy of the forwarding

table on the PFE allows devices running the Junos OS
to continue forwarding traffic during control plane
instabilities.
A. True
B. False


Slide 24
The Command-Line Interface
The Command-Line Interface

Slide 25
Section Objectives
After completing this section, you will be able to:

Introduce the Junos OS CLI
Understand the difference between operational mode and
configuration mode
Navigate the command hierarchy
Use command-line shortcuts and get help

Introduce the Junos CLI;
Understand the difference between operational mode and configuration mode;
Navigate the command hierarchy; and
Use command-line shortcuts and get help.

Slide 26
CLI Login
Log in with your username and password
Type cli at the root

The command prompt will command prompt to
change to a > to show you start the CLI
are in operational mode
username @ symbol hostname prompt symbol
CLI Login
The Junos OS CLI is the software interface you use to access a device running the Junos OSwhether from the
console or through a network connection. By leveraging industry-standard tools and utilities, the CLI provides a
powerful set of commands that you can use to monitor and configure devices running the Junos OS.
To access the CLI, you need to connect and log in. If you are using a brand new device, rather than one that has
already been configured with your username and password, you would log in with a username of root, leave the
password blank, and press enter. The root login account has superuser privileges, with access to all commands and
statements. When you log in as root, the command prompt will end with a percentage symbol. At this point, you are in
a command shell. To enter the CLI you need to type cli and press enter. The command prompt will change to a
greater-than symbol, as shown in the example on this slide. This new command prompt indicates that you are now in
operational mode of the CLI. On a brand new device, you should always create a secure password for the root user,
then create other user accounts as needed. In fact, you are required to set a root password the first time you commit a
configuration.
When you log in with your username and password (instead of the root username), you will be taken directly into the
CLI operational mode, as shown in the second example on this slide where a username of lab was used. Note that
the default CLI prompt is comprised of the username, then an at symbol, the device host name, and then the prompt
symbol. The prompt symbol indicates whether you are in the shell, operational mode, or configuration mode.

Slide 27
CLI Modes
Operational mode
Monitor and manage device operations
The > character identifies
mike@jnpr1> operational mode
Configuration mode
Configure the device and its interfaces
[edit]
The # character identifies
mike@jnpr1# configuration mode
CLI Modes
The Junos CLI organizes its commands into two groups, known as modes:
Operational mode is for managing and monitoring device operations. For example, monitor the status of the device
interfaces, check chassis alarms, and upgrade or downgrade the device's operating system.
Configuration mode is for configuring the device and its interfaces. This includes configuring the management
console with its network settings, setting up user accounts for access to the device, specifying the security
measures used to protect the device and the network, and setting up routing and switching protocols.
The prompt following the device name indicates the mode you are currently in, as illustrated on this slide.

Slide 28
Hierarchical Command Structure
Logical structure organizes device features and

functions
Deeper levels are more and more specific
Know where you are at, find what you want, quickly
move around the interface, efficiently enter commands
Top Level
2nd Level
... ... ...
3rd Level
... ... ... ...
... ... ... ...
... ... ... ...
Hierarchical Command Structure
The Junos CLI structures the activities of each mode into hierarchies. The hierarchy of each mode is made up of
cascading branches of related functions commonly used together.
The structured hierarchy of the CLI is among the first of many preferred differences that new users discover about the
Junos CLI. By logically grouping activities, the Junos CLI provides a regular, consistent syntax that is helpful to
knowing where you are, finding what you want, quickly moving around the interface, and efficiently entering
commands. The hierarchy of commands makes learning and using the Junos CLI easier. New users regularly
comment on just how logical the command-line is.

Slide 29
Operational Mode: Key Functions
Common Administrative Tasks

Monitor and troubleshoot the device
Connect to other network systems
Restart software processes
Enter configuration mode and exit the CLI
Display the configuration
Control the CLI environment
Perform system-level operations such as stopping
and rebooting the device and loading Junos images
Operational Mode: Key Functions
This slide shows some of the common administrative tasks that can be performed in operational mode. The Junos OS
provides an extensive set of on-board instrumentation capabilities for gathering critical operational status, statistics,
and other information. These tools deliver advance notification of issues and speed problem-solving during events.
As part of your configuration setup you can specify the types of events to track, the event severity, and the files in
which to store the data, among other options. You can then access this information in operational mode. Juniper
devices come with sufficient processing power to collect and store critical operational data, including SNMP
management, system logging, and traceoptions (or debugging) that help you to understand how the device operates
in normal conditions and where, when, and why changes occur.

Slide 30
Operational Mode CLI Tree

mike@jnpr1> show ospf neighbor
top
Less Specific
clear configure file help monitor set show ...
chassis configuration interfaces ospf route version ...
database interface neighbor route statistics ...

More Specific
Operational Mode CLI Tree
When you first log in to the CLI, you are at the top level of the CLI's operational mode.
This slide shows a view of the CLI's tree structure from the top of operational mode, with an example of its cascading
hierarchy through a show command. The show command is one of the most commonly used because it displays
information ranging from interfaces (show interface), to hardware (show chassis), to protocols (show ospf neighbor).
The tree structure cascades from less specific to more specific as you get deeper into the hierarchy.
For the student with experience using IOS, a basic difference of the Junos OS is that it does not use the keyword IP.
So, many of the show commands you already know from IOS will work in the Junos OS if you drop that part of the
command. For example, the IOS command show ip route simply becomes show route in the Junos OS.

Slide 31
Specifying Output
mike@jnpr1> show interfaces fe-1/1/1 ?

Possible completions:
<[Enter]> Execute this command
brief Display brief output
descriptions Display interface description strings
detail Display detailed output
extensive Display extensive output
media Display media information
snmp-index SNMP index of interface
statistics Display statistics and detailed output
terse Display terse output
Specifying Output
The show command includes other arguments to modify the output. This slide displays the available arguments for
the show interfaces command for the fe-1/1/1 Fast Ethernet interface. The question mark (?) helps you to complete
commands by showing a list of possible completions available for that command at that level, without you needing to
reference a CLI manual. The question mark will become your best friend while operating or configuring a Junos OS
device.

Slide 32
Output Options
mike@jnpr1> show interfaces fe-1/1/1 brief
Physical interface: fe-1/1/1 Enabled, Physic link is Down
Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Loopback:
Disabled, Source filtering: Disabled
Flow control: Enabled
Device flags: Present Running Down
Interface flags: Hardware-Down SNMP-Traps Internal: Ox4000
Link flags: None
Command output
with brief option
mike@jnpr1> show interfaces fe-1/1/1 terse

Interface Admin Link Proto Local Remote
fe-1/1/1 up up
at-1/3/0.0 up up inet 1.0.0.1 --> 1.0.0.2
iso
Command output
with terse option
Output Options
Junos OS operational mode commands can include brief, detail, extensive, or terse options. You can use these
options to control the amount of information you want to view.
This slide illustrates the results of adding the keywords brief and terse to the show interfaces command.

Slide 33
Switching Between Modes
Enter configuration mode from operational mode

using the configure command
mike@jnpr1> configure
Entering configuration mode
[edit]
mike@jnpr1# The prompt will be > in
operational mode and
# in configuration mode
Enter operational mode from the top of configuration

mode using the exit command
[edit]
mike@jnpr1# exit Use exit from the top of
[edit] indicates that Exiting configuration mode configuration mode to switch
you are at the top of mike@jnpr1> back to operational mode
configuration mode
Switching Between Modes
As you monitor and configure a device, you will need to switch between operational mode and configuration mode.
When you change to configuration mode the command prompt changes from the greater than symbol to the
hashtag symbol, as shown in the examples on this slide.
To switch from operational mode to configuration mode, issue the configure command. The [edit] banner shows your
location at the top level of the configuration hierarchy. To switch back to operational mode, you issue the exit
command.

Slide 34
Configuration Mode CLI Tree

top
Less Specific
access chassis groups interfaces services system ...
accounting license location ports services syslog ...
finger ftp netconf ssh telnet ... More Specific
Two types of statements

Container statements which contain other statements
Leaf statements which do not contain other statements
Configuration Mode CLI Tree
Configuration mode has a hierarchical structure that logically groups related configuration statements. This structure
eases configuration set up, review, and changes, by allowing you to more readily find and view related statements.
The slide illustrates a portion of the configuration mode tree.
The configuration statement hierarchy includes the following two types of statements:
Container statements: This type of statement contains other statements, that is, they have subordinate
configuration levels. Each container statement represents a configuration stanza, which could include other
configuration stanzas. A configuration stanza is represented as the content between curly brackets in the CLI
output.
Leaf statements: This type of statement does not contain other statements, that is, they are at the end of a
particular hierarchical path. Each leaf statement is located within a configuration stanza. A semicolon identifies a
leaf statement at a configuration hierarchy level.

Slide 35
Configuration Mode Syntax
system {
services {
ftp;
}
}
Indentation of subordinate levels

Container statements are indicated with open and close
curly brackets { }
In the example, system and services are cascading container
statements
Leaf statements are indicated with a semicolon ;
In the example, ftp; is a leaf statement
Configuration Mode Syntax
The CLI displays the hierarchy of the configuration mode through the following syntax:
The hierarchy levels are indicated by indenting each subordinate level. In the example shown on this slide,
services is a subordinate of system, and ftp is a subordinate of services.
Container statements are indicated between open and close curly brackets. In the example, system and services
are cascading container statements.
Leaf statements are indicated with a semicolon at the end. In the example, ftp; is a leaf statement.

Slide 36
Hierarchy Flexibility
View from the top of configuration mode:

Configuration mode banner [edit]
system {
services {
ftp;
}
}
View from a sublevel of configuration mode:

Configuration mode banner [edit system services]
ftp;
Refer to the configuration command banner before

entering configuration commands
Hierarchy Flexibility
The flexibility to work at a specific sublevel or stanza in the hierarchy is helpful when users want to focus on just a
small portion of the configuration.
Looking at the examples on this slide, the two configuration statements shown for the FTP service are equal. In the
top example, you are looking at the statement from the root level of the hierarchy, and thus the ftp; statement is shown
in this listing within the system and services container statements.
In the bottom example, you are viewing the same ftp; statement from deeper level within the hierarchy. When you are
in deeper levels of the hierarchy, the [edit] banner displays the entire hierarchical path. In this example, the banner
[edit system services] indicates a place in the hierarchy lying within services (the 3rd level), system (the 2nd level),
and [edit] (the root or 1st level).In this example, as you are deeper within the hierarchy. At this level, whenever you
view the configuration, the command-line only displays the ftp; statement.
To determine where you are in the configuration hierarchy, refer to the configuration mode banner before entering
configuration commands. While you can edit the configuration from the root directory, often it is easier to navigate to
the area within the configuration you are changing prior to adding and removing commands.

Slide 37
Navigating the Configuration Mode Tree
Commands
edit
The user must know the full hierarchical path
This command will create new intermediate hierarchy levels if they do not
yet exist in your configuration
up
Moves you up one level in the hierarchy
To move up multiple levels, add an optional count (up 2, for example)
top
Moves you to the top level in the hierarchy
exit
Leaves the current level of the configuration hierarchy, returning to the
level prior to the last edit command
If you enter exit from the top level of the configuration hierarchy, you exit
configuration mode and enter operational mode
Navigating the Configuration Mode Tree
The edit, up, top, and exit commands let you navigate the configuration tree.
Use the edit command to jump to a specific location within the candidate configuration. The configuration mode
banner changes to indicate your new location in the hierarchy. You must know the full hierarchical path. If you
navigate to a hierarchy location that does not exist in your configuration yet, the CLI will create that hierarchy level.
The up command allows you to move up levels in the hierarchy. By default, you move one level. You can add a
number after the command to specify how many levels to move up.
The top command takes you to the first hierarchy level.
The exit command returns you to the hierarchy location prior to the last edit command. If you use the exit command at
the top level of the configuration hierarchy, you exit configuration mode and go back to operational mode.
The organized structure of the command hierarchy eases movement from one level to another within the Junos CLI.

Slide 38
CLI Shortcut Keys

Go to next in command history Down arrow or Ctrl+n
Go to previous in command history Up arrow or Ctrl+p
Go to beginning of line Ctrl+a
Go to end of line Ctrl+e
Go left one character Ctrl+b
Go right one character Ctrl+f
Go forward one word Esc+f
Go backward one word Esc+b
Delete character over cursor Ctrl+d
Delete word after cursor Esc+d
Delete word before cursor Esc+backspace
Delete text from the cursor to end of the line Ctrl+k
Delete the line Ctrl+u
Paste the deleted text at cursor Ctrl+y
CLI Shortcut Keys
Fortunately, for new users, and even experienced users, the Junos CLI includes lots of shortcuts and ways to get
help.
Both configuration mode and operational mode offer options to shorten keystrokes. All standard UNIX keyboard
shortcuts are available to you when you are logged on to the Junos OS device. It might take some repetition for these
to become second nature, but once they are, these shortcuts can save you a lot of typing time.
For example, the CLI stores every entered command in its command history. At any command prompt, the up and
down arrow keys let you scroll through this history. This allows you to re-use commands that you previously entered,
or modify them as needed.
Keyboard shortcut sequences can save you much time, for example, when you are configuring similar items on the
device, or you are repeating operational commands.

Slide 39
Command and Variable Completion
The spacebar completes commands

[edit]
mike@jnpr1# show i<space>
i is ambiguous
igmp Show Internet Group Management Protocol
ike Show Interface Key Exchange Information
interfaces Show Interface Information
ipsec Show IP Security Information
isis Show Intermediate System-to Intermediate
The tab key completes commands, filenames, and

user defined variables
[edit policy-options]
mike@jnpr1# show policy-statement t<tab>his-is-my-policy
then accept;
Command and Variable Completion
The CLI provides command completion to further speed your typing in both modes. Command completion
automatically finishes partially typed commands, filenames, usernames, and so forth, so you do not need to recall the
exact syntax of the desired input string. Command completion is a big help to new users, especially when they are first
learning the Junos OS CLI.
The spacebar completes most CLI commands. The tab key not only completes CLI commands, but also filenames
and user-defined variables such as policy names, community names, and IP addresses. When the completion of the
command or argument is ambiguous, hitting space or tab lists the possible completions, as shown in the top example
on this slide.

Slide 40
Getting Help
[edit system]
mike@jnpr1# set s?
saved-core-context Save context information for core files
saved-core-files Number of saved core files per executable
(1..64)
> services System services
> static-host-mapping Static hostname database mapping
> syslog System logging facility
Getting Help
You can query the command-line with the question mark character at any level of the operational or configuration
hierarchies for a list of available commands and a short description of each. Typing a partial command followed by a
question mark provides a list of all the valid ways to complete your command, as shown in the example on this slide.
Using the question mark in this way is known as context-sensitive help in Junos OS lingo. For commands that require
a filename as an argument, the question mark lists the files in the working directory.

Slide 41
More Help
help apropos
Displays help about a text string contained in a statement or
command name
help reference
Provides assistance with configuration syntax by displaying
summary information for the statement
help syslog
Displays information on specific syslog events
help tip
Provides random tips for using the CLI
help topic
Displays usage guidelines for configuration statements
More Help
When you want more information than provided by context-sensitive help, you can turn to the Junos OS technical
documentation included on your device by using the help commands. When requesting help, follow each of these help
commands with the string or topic for which you are seeking information.
The help files are divided into major categories. You can access these files in operational mode. You can use:
help apropos to display help about a text string contained in a statement or command name;
help reference to provide assistance with configuration syntax by displaying summary information for the
statement ;
help syslog to display information on specific syslog events;
help tip to provide random tips for using the CLI; and
help topic to display usage guidelines for configuration statements.

Slide 42
Logging Out
[edit protocols ospf]

mike@jnpr1# exit configuration-mode
Exiting configuration mode
mike@jnpr1> exit
jnpr1 (ttyu0)
login:
Logging Out
You must be in operational mode to log out completely from the device. If you are in configuration mode, use the exit
configuration-mode command to enter operational mode. If you are at the top of the configuration mode hierarchy, you
only need to use the exit command. From operational mode, you can completely exit the CLI by entering the exit
command and hitting enter.

Slide 43
Lab 1: Introduction to the Junos OS CLI

Log into the Junos CLI Explore the Junos OS CLI
operational mode
https://virtuallabs.juniper.net/
Click Enter to access the

virtual lab.
Upon completing the lab, return to this presentation

and click the Play button ( ) to proceed.
Lab 1: Introduction to the Junos OS CLI
In this lab, you will:

Log into the Junos CLI; and
Explore the Junos OS CLI operational mode.
At this point, you should pause this presentation, follow the link to Junipers Virtual Lab environment, open the Lab
Guide, and complete the lab portion of this section. When you are finished, return to this presentation and click Play to
continue.
Enter Virtual Lab


Slide 44
Section Summary
In this section, you have learned how to:

Introduce the Junos OS CLI
Describe the differences between operational mode and
configuration mode
Navigate the command hierarchy
Use command-line shortcuts and get help
In this section, you have learned how to:

Introduce the Junos CLI;
Describe the differences between operational mode and configuration mode;
Navigate the command hierarchy; and
Use command-line shortcuts and get help.

Slide 45
Operational mode is identified by which prompt?
A. # (hashtag symbol)
B. } (curly bracket symbol)
C. > (greater-than symbol)
D. ~ (tilde symbol)

Slide 45
Configuration mode is identified by which prompt?
A. # (hashtag symbol)
B. } (curly bracket symbol)
C. ~ (tilde symbol)
D. % (percentage symbol)


Slide 46

Slide 47
Section Objectives

Present and demonstrate the Junos OS configuration
process and its multiple safeguards
Highlight some key Junos OS CLI commands
Discuss features and commands of the Junos OS CLI that
can be used to save time, automate operations, and monitor
the network

Present and demonstrate the Junos OS configuration process and its multiple safeguards;
Highlight some key Junos OS CLI commands; and
Discuss features and commands of the Junos OS CLI that can be used to save time, automate operations, and
monitor the network.

Slide 48
The Junos OS Configuration Process (1 of 2)
Separation of configuration edit and activation

Validation checks
Version control
Automated rollback
Convenient deployment of standard configurations
and policy language across the network
commit
candidate validated active
Load configuration configuration configuration
commit
confirmed commit commit
scripts validations
The Junos OS Configuration Process: Part 1
The graphic at the bottom of this slide outlines the basic steps of the Junos OS configuration process. One of the
foremost differences between the Junos OS and other operating systems is that Junos OS configuration changes do
not become active until the user is ready to make them active. The Junos OS configuration approach provides multiple
safety nets that can save users hours of troubleshooting on those bad days when their configuration changes do not
go quite as planned, potentially resulting in network issues.
Once they understand these safety nets, new users of the Junos OS typically recognize the Junos OS CLI as much
more user-friendly than other operating systems that have line-by-line entry and instant activation of configuration
changes. Have you ever had to make line-by-line changes in other systems, knowing that you were creating
intermediate risks, such as removing a firewall on an interface? Perhaps you have entered a single-line change that
created unwanted or unexpected results that you could not easily revert. The Junos OS CLI protects you from these
and other configuration headaches.
To operate a device, the Junos OS uses the active configuration file. When a user wants to make changes to the
configuration file, they work with a candidate configuration file, which is a copy of the active configuration. In order for
configuration changes made to the candidate configuration to become active, the user must commit the candidate
configuration file.

Slide 49
The Junos OS Configuration Process (2 of 2)
commit
candidate validated active
Load
rollback
configuration configuration configuration
commit
confirmed
commit commit 1
scripts validations 49
Basic steps in the configuration process:

1. Enter changes in the candidate
2. Commit the candidate
3. Candidate becomes active
The Junos OS Configuration Process: Part 2
Lets take a look at the basic steps of the multi-stage Junos OS configuration process, which are as follows:
First, the user makes changes to the candidate configuration.
The candidate configuration is a copy of the active configuration. You can enter configuration changes to the
candidate configuration through the CLI by using cut-and-paste, loading or merging a text file with the
updated configuration changes, or entering the changes manually through the CLI interface. After making all
your candidate changes, you can review your work, including comparing the candidate to the active running
file.
Second, you will commit your changes, which will make the candidate configuration the active configuration.
Before finalizing the changeover, the software checks for certain statements within the candidate
configuration and performs other context validations. If the device includes pre-loaded commit scripts, these
scripts will also check for errors and possibly correct errors within the candidate configuration. If there are
any issues, the user will be notified and the configuration will not become active.
Third, once everything checks out, the candidate configuration becomes the active configuration.
The candidate configuration you were working on becomes the active configuration and the device places
the previous active configuration into an archive of up to 49 of the past active configurations, which you can
access through the rollback command if needed.
We will explore each of these steps in more detail on the upcoming slides.

Slide 50
The configure private, configure

exclusive Commands
Use configure private for your own copy of the
candidate configuration
mike@jnpr1> configure private
warning: uncommitted changes will be discarded on exit
Use configure exclusive when you want to

prohibit others from also making changes while you
are in configuration mode
mike@jnpr1> configure exclusive
warning: uncommitted changes will be discarded on exit
The configure private, configure exclusive Commands
To enter configuration mode, the Junos OS provides several options. These options give users different ways to
manage who is making changes and when.
If users enter configuration mode with the command: configure, then they are in standard configuration mode.
Standard mode allows any number of users to edit the candidate configuration simultaneously, and changes made by
a single user are visibly shared by all users, any of whom will activate all changes if they enter a commit command.
Alternatively, the Junos OS offers the options to configure private or configure exclusive. These prevent one user from
inadvertently activating another users changes before they are ready.
In configure private mode, the device keeps a separate candidate copy, which holds only the changes made by the
private user. In configure exclusive mode, the CLI locks all other users out of configuration mode until the exclusive
user closes the exclusive state. These two configuration options are very handy when multiple users can change the
candidate configuration of a device.

Slide 51
The show Command

List the complete candidate List a specific subset of the
configuration from the top of candidate configuration from a
configuration mode deeper level of the hierarchy
[edit] [edit interfaces ge-5/0/0]

mike@juniper1# show mike@jnpr# show
version "9.2R1.3"; gigether-options {
groups flow-control;
{ auto-negotiation;
re0 { }
system { unit 0 {
jnpr1-name jnpr1; family inet {
} address
} 1.2.3.4/28;
} }
}
The show Command
Initially, before any changes are entered, the candidate configuration is the same as the active running configuration.
To display the candidate configuration, use the show command in configuration mode. When entered from the top of
the configuration hierarchy, the CLI displays the entire candidate configuration, as shown in the abbreviated example
on the left of this slide.
Deeper in the hierarchy, the show command displays the configuration from the current hierarchy level and below, as
show in the example on the right of this slide.
You might have noticed that configuration mode uses the show command in a different way than operational mode.
The commands of each mode are independent of each other, and thus the show command represents different
actions in each mode.

Slide 52
The set Command
From the top of configuration mode:

[edit]
mike@jnpr1# set system services finger
mike@jnpr1# set system services ftp
mike@jnpr1# set system services ssh [edit]
mike@jnpr1# set system services telnet system {
services {
finger;
Either ftp;
ssh;
From a sublevel: adds }

telnet;
}
[edit system services]
mike@jnpr1# set finger
mike@jnpr1# set ftp
mike@jnpr1# set ssh
mike@jnpr1# set telnet
The set Command
You can create or change the candidate configuration by entering a series of commands, including those to add and
remove configuration statements. The set command inserts a statement and values into the candidate configuration.
While you can edit the candidate from the root directory, as shown in the top example on this slide, often it is easier to
navigate to the area within the configuration you are changing prior to adding and removing commands. This is shown
in the second example on this slide where changes are entered in the [edit system services] sublevel of the hierarchy.
Either approach provides the same results, as shown in the example on the right of this slide.

Slide 53
The delete Command
Remove a statement along with any subordinate

statements
Deleting a statement effectively returns the device, protocol,
or service to an un-configured state
Deleting a container statement removes everything under
that level of the hierarchy
[edit] [edit]
mike@jnpr1# delete system services system {
Result }
The delete Command
The delete command removes statements from the candidate configuration. In the example shown on this slide, we
delete what we had just added in the prior slide, which was system services.
Deleting a statement effectively returns the device, protocol, or service to an un-configured state. Deleting a container
statement removes everything under that level of the hierarchy. Proceed with caution. Remember, the delete
command removes all subordinate statements and identifiers. For example, if you entered the simple command:
delete protocols from the top of the CLI hierarchy, you would remove all the protocols configured in your candidate file.
You need to be aware of where you are within the hierarchy and what you are removing when you issue a delete
statement.

Slide 54
The compare Command
Used to display the differences between the

candidate and active configurations
[edit system services]
mike@jnpr1# show | compare
- ssh;
+ telnet;
- web-management {
- http {
- port 8080;
- }
- }
Options are also available for comparing any

configuration file to the candidate configuration file
[edit]
mike@jnpr1# show | compare (filename| rollback n)
The compare Command
In configuration mode only, when you have made changes to the configuration and want to compare the candidate
configuration with a prior version, you can use the compare command to display the differences. The compare
command compares the candidate configuration with either the current active configuration or another configuration
file and displays the differences between the two configurations. The CLI indicates new lines in the candidate with a
plus (+) sign and those removed with a minus (-) sign. In the example shown at the top of this slide, the user has
enabled telnet within system services and also removed ssh and web-management.
To compare configurations, specify the compare command after the pipe symbol, as shown in the examples on this
slide. If you do not specify any arguments after the compare command, then the candidate configuration is compared
against the active configuration file, as shown in the top example on this slide. If you want to specify a file other than
the active configuration file for comparison, then you would specify the filename after the compare command, as
shown in the bottom example on this slide. You can also do a comparison to a previously active configuration by using
rollback n, where n is the index into the list of previously committed configurations. The most recently saved
configuration (which is the active configuration) is number 0, and the oldest saved configuration is number 49.

Slide 55
Using commit check
Check that the device will accept your candidate

configuration
Validates the logic and completeness of the candidate
configuration without activating the changes
[edit]
mike@jnpr1# commit check
[edit interfaces lo0 unit 0 family inet]

'address 192.168.69.1/24'
Loopback addresses' prefix must be 32 bits
error: configuration check-out failed
Using commit check
The CLI also provides a command to check that the system can process your candidate configuration. The commit
check command validates the logic and completeness of the candidate semantics without activating any changes.
These are the same validations which run when you commit a candidate. If the system finds a problem in the
candidate configuration, it lets you know, as the example on this slide illustrates.

Slide 56
The commit Command
Activates the candidate configuration to become the

active configuration of the device
If the validation checks find any errors, you must fix them
before the candidate can become the active file
[edit]
mike@jnpr1# commit
error: Policy error: Policy my-policy referenced but not defined
error: BGP: export list not applied
error: configuration check-out failed
The commit complete message tells you that the

new configuration is now active
[edit]
mike@jnpr1# commit
commit complete
The commit Command
The candidate configuration file is only the proposed configuration, and your device does not use any of this
configuration until a commit command activates the configuration. After you have entered all desired changes, and
you have double checked your work, you are ready to activate your candidate as the active running configuration. To
activate the candidate configuration, enter the commit command.
Before actually activating the candidate configuration, the Junos OS checks basic syntax and semantics. For example,
the software makes sure that a policy has been defined before it is referenced. If any syntax or semantic problems are
found, the commit command returns an error and the configuration is not activated, as shown in the first example on
this slide.
You must fix all errors before the candidate can become active. The commit complete message tells you that the new
configuration is up and running on the device.

Slide 57
The commit confirmed Command
Automate rollback in remote devices

Commit a candidate configuration for a limited time:
[edit]
mike@jnpr1# commit confirmed
commit confirmed will be automatically rolled back in 10
minutes unless confirmed commit complete
Finalize the commit, by entering a 2nd commit command:

[edit]
mike@jnpr1# commit
commit complete
Or, wait for rollback to your previous configuration:

Broadcast Message from root@jnpr1
(no tty) at 08:10:17 UTC
Commit was not confirmed; automatic rollback complete.
The commit confirmed Command
Are you among those of us who have made the mistake of adding security to a remote device, only to discover that
the security configuration changes you made locked you out of the very interface that you were using to access the
device? Do you have a story about the time you accidently isolated a remote device and then had to jump in the car
and drive two-and-a-half hours in the middle of the night just to reset it? The commit confirmed command can prevent
costly configuration mistakes by automatically rolling back problematic configurations.
The commit confirmed command commits a candidate configuration for 10 minutes (this is the default time setting).
Then if you do not follow up with a second commit within that time period, the device automatically rolls back to the
previous configuration. You can use the commit confirmed command anytime you want a safety net against potential
configuration problems.
If you do not confirm the configuration by entering a second commit command, the CLI will roll back the device to the
previous active configuration at the end of the 10 minutes (or an interval you specify). In this way, if you have
accidently isolated the device, you simply need to wait for the rollback instead of agonizing over how you are going to
otherwise undo your mistake.

Slide 58
The rollback Command
Use rollback (or rollback 0 ) to reset the

candidate configuration to the currently active
configuration
rollback 1 loads the previously active configuration
rollback n loads the nth previous active configuration
rollback rescue loads the previously created rescue file
rollback only modifies the candidate configuration
Dont forget to commit the changes!
[edit]
mike@host# rollback
load complete
[edit]
mike@host# commit
commit complete
The rollback Command
Whenever you commit the candidate as the new active configuration, the Junos OS automatically saves a copy of the
active configuration file that is being replaced. As you store each newly replaced configuration, all the prior
configuration files move back one version number further in the configuration archive. Each device can store up to 50
of the most recently active versions. This number includes the current active configuration (also known as rollback 0).
You can access this configuration archive using the rollback command.
You can reset your candidate configuration to match the active running configuration by entering rollback or rollback 0.
You can also return to the most recent previous active configuration file by using the rollback 1 command, or use any
other number between 2 and 49 to go back to any of the previous configurations.
The rollback command loads the requested archive as the candidate file. You can also create a rescue configuration
of a known working configuration so that you can rollback to it when all else fails.
If you want to use a rollback file you will need to commit the configuration. First, use the show command to view the
file so you can be sure it is what you want. Then activate the file with the commit command. This is a very important
stepto complete a rollback for the active configuration of the device, you must run the commit command to activate
it.

Slide 59
Preparing Changes in Advance
Prepare for hardware being installed at a later date:

[edit]
mike@jnpr1# edit interfaces fe-3/0/0 unit 0
[edit interfaces fe-3/0/0 unit 0]

mike@jnpr1# set family inet address 192.168.1.254/24
Make changes during a maintenance window:

[edit]
mike@jnpr1# commit at 02:00:00
commit check succeeds
commit will be executed at 2009-02-02 02:00:00 UTC
Exiting configuration mode
mike@jnpr1>
Preparing Changes in Advance
Unlike other systems, the Junos OS lets you prepare for an installation before actually installing the hardware. The
software simply ignores the areas of the running configuration which are irrelevant to the existing hardware
installation. Those areas of the running configuration will become active once the hardware becomes available.
The option to set up a configuration prior to hardware installation is quite useful, especially when the person installing
the hardware is different than the person configuring the device, a common occurrence for remote devices. At the top
of this slide we show a configuration for fe-3/0/0, which will be installed at a later date. Nevertheless, the configuration
statement is the same. The settings will simply be ignored until the hardware is installed. Then the setting will become
active.
You can also schedule when you want your candidate configuration to become active. To save Junos OS
configuration changes and activate the configuration on the device at a future time or upon reboot, use the commit at
configuration mode command, specifying reboot or a future time at the [edit] hierarchy level, as shown in the example
at the bottom of this slide.

Slide 60
Commands That Save Time

copy defines a new element by duplicating a
selected configuration statement and its subordinate
elements
[edit interfaces]
mike@jnpr1# copy se-0/0/2 to se-0/0/1
edit interfaces]
mike@jnpr1# delete se-0/0/1 unit 0 family inet address 10.0.22.1/24
Then make any changes to the new element (if needed)

[edit interfaces]
mike@jnpr1# set se-0/0/1 unit 0 family inet address 10.0.36.2/24
rename changes the value of a user-defined variable

or the name to a user-defined element
[edit interfaces]
mike@jnpr1# rename se-0/0/1 unit 0 family inet address 10.0.22.1/24 to
address 10.0.36.2/24
Commands That Save Time
A typical configuration includes many similar elements named and defined by the user, such as interface names,
policy statements, and firewall filters. The Junos CLI includes commands to duplicate and quickly change the
configurations of these user-defined variables.
The copy command duplicates a configuration statement along with all the subordinate statements configured
underneath it. In using the copy command, you copy the configuration associated with one user-defined element to a
new, similarly configured element. You can then modify that second element with any needed changes. Copying
statements is useful when you are configuring many physical or logical interfaces
of the same type.
The rename command is a convenient shortcut when you need to alter the value of a user-defined variablesuch as
policy names, filter names, and IP addressesor to change the name of a user-defined element.
The examples on this slide illustrate a very useful technique for configuring similar interfaces, where only IP addresses
are different. First, you create an identical configuration of se-0/0/1 based on the se-0/0/2 interface using the copy
command. Then, you change the IP address of the newly created se-0/0/1 interface by deleting the IP address of the
copied se-0/0/2 interface and setting the IP address for the se-0/0/1 interface, which is 10.0.36.2/24 in the example
shown on this slide. You could also use the rename command to change the IP address of the newly created
interface, thereby achieving the same result, as shown in the bottom example on this slide.

Slide 61
Using the Pipe Symbol
Use the pipe symbol | to filter output in both

operational and configuration mode
Sends output of one command as input to another
Examples:
Use pipe to redirect output of a command to a file
Useful for re-using sections of configurations across many devices
mike@jnpr1> request support information | save <filename>
Wrote 1143 lines of output to filename
| count: gives the number of lines in the output

mike@jnpr1> show interfaces terse | count
Count: 22 lines
Using the Pipe Symbol
The pipe symbol lets you filter output in both operational and configuration modes. Pipe makes it possible to achieve
results such as: displaying specific information in a single command step, sending the output of one command as
input to another, or redirecting the output to a file, to name a few examples. The output of the command to the left of
the pipe symbol serves as input to the command or file to the right of the pipe.
The first example shown on this slide creates a file that stores the output of the request support information command
entered in operational mode by piping its output to a filename specified by the user.
In the second example on this slide, the pipe symbol, followed by count, counts the number of lines in the output.
These are only a few of the examples of what the pipe symbol can do.

Slide 62
The run Command
Issue operational mode commands while in

configuration mode using run
[edit]
mike@jnpr1# run show interfaces
Physical interface: fe-4/0/2, Enabled, Physical link is Up
Interface index: 137, SNMP ifIndex: 29
Link-level type: Ethernet, MTU: 1514, Speed: 100mbps,
Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled
Device flags : Present Running
Interface flags: SNMP-Traps 16384
Link flags : 4
CoS queues : 8 supported
<...OUTPUT TRIMMED...>
The run Command
The run command lets you issue CLI operational mode commands while in configuration mode. Just add the keyword
run before any operational mode command that you want to execute while you are inside configuration mode.
As shown in the example on the slide, entering the run show interfaces command displays the output as if show
interfaces had been entered from operational mode. The example on this slide shows an abbreviated listing of the
output.

Slide 63
Junos OS System Health: Monitoring
Real-time Performance Monitoring (RPM)

Active probes to monitor performance
Per-destination and per-application basis
Flow accounting
cflowd and rich filtering
Active monitoring, passive monitoring,
port mirroring
Health monitor
Extends the Remote Network Monitoring
alarm infrastructure with minimum user configuration
Junos OS System Health: Monitoring
Juniper devices provide extensive on-board instrumentation that enables customers to proactively gather status
information. Self-monitoring allows continuous feedback and lets administrators capture information network-wide,
down to highly granular perspectives on the operations of the network. Junos OS-based platforms come with sufficient
processing power to collect and store critical operational data that help you to understand how a device operates in
normal conditions and where, when, and why changes occur.
Available tools for automating network monitoring include the following:

Real-time performance monitoring (RPM) measures the performance of traffic as it travels between network
devices. The RPM probes can collect round-trip time minimums, averages, maximums, jitter, and other data on
both a per-destination and per-application basis.
Flow accounting provides a method for collecting traffic flow statistics, enabling operations teams to track link
utilization for capacity planning, security analysis, fault isolation, internal billing, and more. You can gather
statistics on an individual physical device, logical device, interface, or sub-interface.
Health monitor notifies your network management system (NMS) when something requires attention. Health
monitor extends the Remote Network Monitoring (RMON) alarm infrastructure of the Junos OS with minimum user
configuration requirements by providing predefined monitoring of the operating system processes and device
hardwarefor example: file system usage, CPU usage, and memory usage.

Slide 64
Junos OS System Health: Diagnostics
System logging to record device events

Hardware events
Operating system events
Trace logging (traceoptions) to flag
events specific to operations
Protocol operations
SNMP operations
Other device operations
Junos OS System Health: Diagnostics
The logging and tracing operations of the Junos OS allow administrators to find out about events that occur in the
devicenormal operations, as well as error conditions.
You can use the following tools to discover, trace, and analyze the sequence of events leading to network or device
issues for fast resolution:
System logging generates system log messages (syslog messages) for recording events that occur on the device,
including hardware and within the processes of the operating system. A few examples, among the thousands that
we can cite: an interface starting up, login failure, or hardware failure conditions.
Trace logging (also called traceoptions) provides a wide range of variables for observing network and system
events specific to operations, such as protocol operations. Note that traceoptions is similar to the debug function in
IOS. Examples of trace logging include BGP state changes, graceful restart events, and even tracking SNMP
operations and statistics. Trace logging is a valuable tool when you need to find out what is going on in your
device.

Slide 65
Junos Automates the Network

Automation API Service Automation Application Automation
Junos Automation Juniper Care Junos Space
Actions
XML
ACTIVE
Configuration
Service Insight:
Proactive bug Network Director:
notifications and enables Management of campus and
data center switches/routers
On-Box Automation: thorough automated end-
of-life/end-of-support
Commit/Op/Event Scripts/Macros
impact analysis
Security Director:
scalable and responsive security
Off-Box Automation: management application that
Puppet Service Now: improves security policy
Chef Automated administration
Ansible troubleshooting client
Python that enables Juniper and many other easy-to-use
Ruby Juniper applications to optimize network
to quickly identify and
Perl JSS management for various domains
resolve a problem in
Java the customer's in service provider and enterprise
SLAX (Juise) network environments
Junos Automates the Network
Junos automation consists of a suite of tools used to automate operational and configuration tasks on network devices
running the Junos OS. The Junos automation tool kit is part of the standard Junos OS available on all switches,
routers, and security devices running Junos OS. Junos automation tools for on-box automation, which leverage the
native XML capabilities of the Junos OS, include commit scripts, operational scripts (op scripts), event policies and
scripts, and macros.
Junos automation simplifies complex configurations and reduces potential configuration errors. It saves time by
automating operational and configuration tasks. It also speeds troubleshooting and maximizes network uptime by
warning of potential problems and automatically responding to system events.
Junos automation can capture the knowledge and expertise of experienced network operators and administrators and
allow a business to leverage this combined expertise across the organization.
Where a Juniper Networks product does not provide an essential functionality in the creation or monitoring of a robust
automated network service, the Junos OS enables an interface, protocol, or API, or adds a third-party client to
integrate with a best-in-class product.

Slide 66
Lab 2: Configuring the Junos OS Using

the CLI
Explore the Junos OS CLI Save, view, and use a rescue
configuration mode configuration

Lab 2: Configuring the Junos OS Using the CLI

Explore the Junos OS CLI configuration mode; and
Save, view, and use a rescue configuration.
At this point, you should return to the Virtual Lab session you opened previously and complete the lab portion of this
section. When you are finished, return to this presentation and continue.
Enter Virtual Lab:


Slide 67
Section Summary

Presented and demonstrated the Junos OS configuration
process and its multiple safeguards
Highlighted some key Junos OS CLI commands
Discussed features and commands of the Junos OS CLI that
can be used to save time, automate operations, and monitor
the network

Presented and demonstrated the Junos OS configuration process and its multiple safeguards;
Highlighted some key Junos OS CLI commands; and
Discussed features and commands of the Junos OS CLI that can be used to save time, automate operations, and
monitor the network.

Slide 68
True or False: As soon as you edit the configuration

file and press Enter the changes are implemented
on your Junos OS device.
A. True
B. False

Slide 68
What is the purpose of configure private mode?
A. Limits the impact of the configuration changes to the local

system
B. Creates your own copy of the candidate configuration
C. Prohibits others from making changes to the configuration
D. Produces a second copy of the configuration for testing
purposes


Slide 69
Junos OS Routing
Junos OS Routing

Slide 70
Section Objectives

Discuss routing and forwarding tables
Describe routing instances
Explore static routing and its configuration using the
Junos OS
Describe dynamic routing

Discuss routing and forwarding tables;
Describe routing instances;
Explore static routing and its configuration using the Junos OS; and
Describe dynamic routing.

Slide 71
A Basic Definition of Routing
The process of moving data between Layer 3 networks
Server Server
A B
Internet
User A
Router
User B Data Center
Switch
A Basic Definition of Routing
Routing, in its most basic form, is the process of moving data between Layer 3 networks. The sample topology on
shown on this slide consists of several Layer 3 networks, all connected by routers. Although routers are the most
common devices for performing routing operations, note that many switches and security devices also perform routing
operations. Note also that the Internet is actually a collection of many networks rather than a single network.
In this section, we will look at the required components of routing, and how devices running the Junos OS make
routing decisions.

Slide 72
The Components of Routing
For a device to communicate with another device in a

remote network, the following requirements exist:
End-to-end communications path
Routing information on participating Layer 3 devices
Internet
Network 1
Network 2
User A
Router
gateway Data Center
User B
device
Switch
The Components of Routing
There are several components and concerns you need to consider to effectively implement routing between remote
networks. However, you can classify the various components and considerations into two primary requirementsan
end-to-end communications path and ensuring all Layer 3 devices within the communications path have the required
routing information.
In the example shown on this slide, you can see that a physical path exists between the two networks and the
Internet. As long as the physical path is configured and functioning correctly, the first requirement is satisfied.
For the second requirement, all Layer 3 devices participating in the communications path must have the necessary
routing information. The devices within the networks must have the proper gateway configured (the router that
connects to those networks as well as the Internet). The gateway device must determine the proper next hop for each
destination prefix for the transit traffic it receives. Devices running the Junos OS use the forwarding table, which is a
subset of information found in the routing table, to make this determination.
We discuss the routing and forwarding tables next.

Slide 73
The Routing Table
Compiles information learned from routing protocols

and other routing information sources
Selects an active route to each destination
Populates the forwarding table
Main unicast routing tables are inet.0, for IPv4
routing, and inet6.0, for IPv6 routing
Routing
protocol OSPF
databases Routing Forwarding
table table
Other routing
information Direct Static
sources
The Routing Table
The Junos OS routing table consolidates prefixes from multiple routing information sources including various routing
protocols, static routes, and directly connected routes.
Active Route Selection

When a device running the Junos OS receives multiple routes for a given prefix, it selects a single route as the active
route. With additional configuration, the Junos OS can support multiple, equal-cost routes.
Forwarding Table
The router uses the active route for each destination prefix to populate the forwarding table. The forwarding table
determines the outgoing interface and Layer 2 rewrite information for each packet forwarded by a device running the
Junos OS.
Multiple Routing Tables

Devices running the Junos OS can accommodate multiple routing tables. The primary routing table, inet.0, stores IPv4
unicast routes. Additional predefined routing tables exist, such as inet6.0, which the Junos OS creates when required
by the configuration.

Slide 74
Predefined Routing Tables
The following is a summary of the common predefined

routing tables you might see on a device running the
Junos OS:
inet.0: Used for IPv4 unicast routes
inet.1: Used for the multicast forwarding cache
inet.2: Used for MBGP routes to provide reverse path
forwarding (RPF) checks
inet.3: Used for MPLS path information
inet.4: Used for MSDP route entries
inet6.0: Used for IPv6 unicast routes
mpls.0: Used for MPLS next hops
Predefined Routing Tables
The slide provides a summary of the common predefined routing tables you might see on a device running the Junos
OS.

Slide 75
Route Preference
Ranks routes received from different sources

Used as the primary criterion for selecting the
active route
Used as a tiebreaker when same destination prefix is
available through multiple sources
Route Preference Values
Routing Information Source Default Preference
Direct 0 More Preferred
Local 0
Static 5
OSPF internal 10
RIP 100
OSPF AS external 150
BGP (both EBGP and IBGP) 170 Less Preferred
Route Preference
The Junos OS uses route preference to differentiate routes received from different routing protocols or routing
information sources. Route preference is equivalent to administrative distance on equipment from other vendors such
as Cisco.
Selecting the Active Route

The Junos OS uses route preference to rank routes received through the various route information sources and as the
primary criterion for selecting the active route. The table at the bottom of this slide shows the default preference
values for a selected set of routing information sources. Any of these default values can be changed.

Slide 76
Viewing the Routing Table

Use show route to display routing table contents
user@host> show route
inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
10.1.1.0/24 *[Static/5] 00:10:24

Route source and preference
> to 172.29.30.253 via ge-0/0/10.0
[OSPF/10] 00:03:38, metric 2
> to 172.18.25.2 via ge-0/0/13.0
172.18.25.0/30 *[Direct/0] 00:11:05
> via ge-0/0/13.0
172.18.25.1/32 *[Local/0] 00:11:05
Local via ge-0/0/13.0
172.29.30.0/24 *[Direct/0] 00:11:05
> via ge-0/0/10.0
172.29.30.1/32 *[Local/0] 00:11:05
Local via ge-0/0/10.0 Asterisk (*) indicates that the
route is selected as active
Route table name
Viewing the Routing Table
This slide shows the use of the show route command, which displays all route entries in the routing table. As identified
on the slide, all active routes are marked with an asterisk (*) next to the selected entry. Each route entry displays the
source from which the device learned the route, along with the route preference for that source.
The show route command displays a summary of active, holddown, and hidden routes. Active routes are the routes
the system uses to forward traffic. Holddown routes are routes that are in a pending state before the system declares
them as inactive. Hidden routes are routes that the system cannot use for reasons such as an invalid next-hop and
route policy.
You can also filter the output by destination prefix, protocol type, and other distinguishing attributes.

Slide 77
The Forwarding Table
Stores required information for packet forwarding

operation
Contents include the destination prefixes and the
associated outgoing interfaces
Use show route forwarding-table to view contents
Routing
protocol OSPF
databases
Routing Forwarding
table table
Other routing
information Direct Static
sources
The Forwarding Table
The forwarding table stores a subset of information from the routing table. Within the forwarding table, you can find the
details used by a device running the Junos OS to forward packets such as the learned destination prefixes and the
outgoing interfaces associated with each destination prefix. You use the show route forwarding-table CLI command to
view the forwarding table contents.
Note that the Junos OS kernel adds some forwarding entries and considers them permanent in nature. One such
example is the default forwarding entry, which matches all packets when no other matching entry exists. When a
packet matches this default forwarding entry, the device discards the packet and sends an ICMP destination
unreachable message back to the sender. If you configured a user-defined default route, it will be used by the device
instead of the permanent default forwarding entry.
The following are some examples of forwarding entries:

Remote addresses directly reachable through an interface;
Routes installed by the kernel when the routing table initializes;
Routes installed by the routing protocol process or as a result of the configuration; and
The local address on an interface.

Slide 78
Determining the Next Hop
Device compares incoming packets against

forwarding table entries to determine appropriate
next hop
If multiple matches exist, it uses the most specific entry
(longest match) to forward packet toward destination
If no matching entry exists, it sends a destination
unreachable notification back to source device
Forwarding Plane
FT
Packets in Packets out
Determining the Next Hop
When a packet enters a device running the Junos OS, it compares that packet against the entries within the
forwarding table to determine the proper next hop. If the packet is destined to the local device, the Junos OS
processes the packet locally. If the packet is destined to a remote device and a valid entry exists, the device running
the Junos OS forwards the packet out the next-hop interface associated with the forwarding table entry.
If multiple destination prefixes match the packets destination, the Junos OS uses the most specific entry (also called
longest match) when forwarding the packet to its destination.
In situations where no matching entry exists, the device running the Junos OS responds to the source device with a
destination unreachable notification.

Slide 79
Overview of Routing Instances
A routing instance is a unique collection of routing

tables, interfaces, and routing protocol parameters
A single device can effectively imitate multiple devices
Device Running the Junos OS
Routing instance (master) Routing instance (cust-A) Routing instance (cust-B)
inet.0 cust-A.inet.0 cust-B.inet.0
inet6.0 cust-A.inet6.0 cust-B.inet6.0
ge-0/0/0.0 ge-0/0/3.0 ge-1/0/0.0
ge-0/0/1.0 ge-0/0/4.0 ge-1/0/1.0
lo0.0 lo0.1 lo0.2
Default Route Default Route Default Route
OSPF OSPF OSPF
Overview of Routing Instances
The Junos OS logically groups routing tables, interfaces, and routing protocol parameters to form unique routing
instances. The device logically keeps the routing information in one routing instance apart from all other routing
instances. The use of routing instances introduces great flexibility because a single device can effectively imitate
multiple devices.

Slide 80
Default Routing Instance
The master routing instance is the primary instance

for all devices running Junos OS and includes
inet.0 route table
Might include other route tables, such as inet6.0
user@host> show route instance
Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.0 3/0/1
inet6.0 4/0/0

Participating route tables; the presence of
Routing instance name
inet6.0 table indicates IPv6 is in use
Default Routing Instance
The Junos OS creates a default unicast routing instance called the master routing instance. By default, the master
routing instance includes the inet.0 route table, which the device uses for IPv4 unicast routing. The software creates
other route tables, such as inet6.0, adds them to their respective routing instance, and displays them when required
by the configuration.
The Junos OS also creates private routing instances, which the device uses for internal communications between
hardware components. You can safely ignore these instances and their related information when planning your
network.

Slide 81
User-Defined Routing Instances
You configure user-defined routing instances at the

[edit routing-instances] hierarchy level
Typically used for filter-based forwarding, VPN services, and
system virtualization
Routing instance types include:
[edit routing-instances <instance-name>]
user@host# set instance-type ?
forwarding Forwarding instance
l2vpn Layer 2 VPN routing instance
no-forwarding Nonforwarding instance
virtual-router Virtual routing instance
vpls VPLS routing instance
vrf Virtual routing forwarding instance
Note: Actual routing instance types vary between platforms running the
Junos OS; Check product documentation for actual support
User-Defined Routing Instances
For added flexibility, the Junos OS allows you to configure additional routing instances under the [edit routing-
instances] hierarchy. User-defined routing instances can be used for a variety of different situations and provide users
a great amount of flexibility in their respective environments.
We also commonly refer to filter-based forwarding (FBF) as policy-based routing (PBR). Some typical uses for user-
defined routing instances include filter-based forwarding (FBF), Layer 2 and Layer 3 VPN services, and system
virtualization.
The following are some of the common routing instance types:

forwarding: Used to implement filter-based forwarding for common Access Layer applications;
l2vpn: Used in Layer 2 VPN implementations;
no-forwarding: Used to separate large networks into smaller administrative entities;
virtual-router: Used for non-VPN-related applications such as system virtualization;
vpls: Used for point-to-multipoint LAN implementations between a set of sites in a VPN; and
vrf: Used in Layer 3 VPN implementations.
Note that the actual routing instance types vary between platforms running the Junos OS. Be sure to check the
technical documentation for your specific product.

Slide 82
Routing Instances Configuration Example
Routing instance configuration example:

[edit routing-instances new-instance] Routing instance name is user-defined
user@host# show
instance-type virtual-router; Routing instance type
interface ge-0/0/0.0;
interface ge-0/0/1.0; Define interfaces under the [edit
interface lo0.1; interfaces] hierarchy and reference
routing-options { them under the routing instance
static {
route 0.0.0.0/0 next-hop 172.26.25.1;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.1;
}
}
}
Routing Instances Configuration Example
This slide illustrates a basic routing instance configuration example and points out some of the highlights. Note that
the routing instance name is user-defined.

Slide 83
Working with Routing Instances (1 of 2)
Reference the corresponding IP unicast table for a

given instance to view the route table contents:
user@host> show route table new-instance.inet.0
new-instance.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

0.0.0.0/0 *[Static/5] 02:06:18

> to 172.26.25.1 via ge-0/0/0.0
172.25.182.0/24 *[Direct/0] 02:06:18
> via ge-0/0/1.0 The software automatically creates
172.25.182.5/32 *[Local/0] 02:06:18 the IP unicast table when you
Local via ge-0/0/1.0 configure the corresponding
172.26.25.0/24 *[Direct/0] 02:06:18 routing instance
> via ge-0/0/0.0
172.26.25.5/32 *[Local/0] 02:06:18
Local via ge-0/0/0.0
192.168.100.52/32 *[Direct/0] 02:06:18
> via lo0.1

Working with Routing Instances: Part 1
Once you configure a routing instance and the device learns routing information within the instance, the Junos OS
automatically generates a route table. If you use IPv4 routing, the software creates an IPv4 unicast routing table. The
name of the IPv4 unicast route table uses the format instance-name.inet.0, where instance-name is the name of the
routing instance within the configuration. Likewise, if you use IPv6 within the instance, the software creates an IPv6
unicast routing table and it follows the format instance-name.inet6.0.
As illustrated on this slide, to view a routing table associated with a specific routing instance, you simply use the show
route table table-name CLI command.

Slide 84
Working with Routing Instances (2 of 2)
Reference the routing instance name when viewing

information for a given instance or sourcing traffic
from a given instance
user@host> show interfaces terse routing-instance new-instance
Interface Admin Link Proto Local Remote
ge-0/0/0.0 up up inet 172.26.25.5/24
ge-0/0/1.0 up up inet 172.25.182.5/24
lo0.1 up up inet 192.168.100.52 --> 0/0
user@host> ping 172.26.25.1 rapid count 25 routing-instance new-instance

PING 172.26.25.1 (172.26.25.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.26.25.1 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.014/1.875/2.073/0.285 ms
user@host> traceroute 192.168.100.25 routing-instance new-instance

traceroute to 192.168.100.25 (192.168.100.25), 30 hops max, 40 byte packets
1 192.168.100.25 (192.168.100.25) 4.536 ms 4.503 ms 2.209 ms
Working with Routing Instances: Part 2
You can filter many of the common outputs generated through CLI show commands by referencing the name of a
given routing instance. The first example shown on this slide shows a practical way of viewing interfaces that belong
to a specific routing instance.
You can also source traffic from a specific routing instance by referencing the name of the desired routing instance.
The last two examples on this slide show this option in action with the ping and traceroute utilities.

Slide 85
Static Routes
Manually configured routes added to routing table

Defined under [edit routing-options] hierarchy
Require a valid next hop
Typically the IP address of a directly connected device; other
options exist such as the bit bucket (discard or reject)
ge-0/0/1
Network A 192.168.63.14
.1 .2 .1 Internet
172.29.100.0/24
172.30.25.0/30
user@host> show route 192.168.63.14

0.0.0.0/0 *[Static/5] 01:09:34 Default static route

> to 172.30.25.1 via ge-0/0/1.0
Static Routes
Static routes are used in a networking environment for multiple purposes, including a default route for the autonomous
system (AS) and as routes to customer networks. Unlike dynamic routing protocols, you manually configure the
routing information provided by static routes on each router or multilayer switch in the network. All configuration for
static routes occurs at the [edit routing-options] level of the hierarchy.
Static routes must have a valid next-hop defined. Often, that next-hop value is the IP address of the neighboring router
headed toward the ultimate destination. On point-to-point interfaces, you can specify the egress interface name rather
than the IP address of the remote device. Another possibility is that the next-hop value is the bit bucket. This phrase is
analogous to dropping the packet off the network. Within the Junos OS, the way to represent the dropping of packets
is with the keywords reject or discard. Both options drop the packet from the network. The difference between them is
in the action the device running the Junos OS takes after the drop action. If you specify reject as the next-hop value,
the system sends an ICMP message (the network unreachable message) back to the source of the IP packet. If you
specify discard as the next-hop value, the system does not send back an ICMP message, the system just drops the
packet silently.
By default, the next-hop IP address of static routes configured in the Junos OS must be reachable using a direct route.
Unlike with software from other vendors, the Junos OS does not perform recursive lookups of next hops by default.
Static routes remain in the routing table until you remove them or until they become inactive. One possible scenario in
which a static route becomes inactive is when the IP address used as the next hop becomes unreachable.

Slide 86
Configuring Static Routing
Static route configuration example:

[edit routing-options]
user@host# show
rib inet6.0 {
static {
route 0::/0 next-hop 3001::1; IPv6 default static route
}
}
static {
route 0.0.0.0/0 next-hop 172.30.25.1; IPv4 default static route
route 172.28.102.0/24 {
next-hop 10.210.11.190;
no-readvertise;
}
}
no-readvertize: Restricts route from being
advertised into a routing protocol through routing
policy, highly suggested for static routes used for
management traffic
Configuring Static Routing
This slide illustrates the basic configuration syntax for IPv4 and IPv6 static routes. The slide also highlights the no-
readvertise option which prohibits the redistribution of the associated route through routing policy into a dynamic
routing protocol such as OSPF. We highly suggest that you use the no-readvertise option on static routes that direct
traffic out the management Ethernet interface and through the management network.
Note that IPv6 support varies between Junos OS platforms. Be sure to check the technical documentation for your
specific product for support information.

Slide 87
Monitoring Static Routing
Monitoring
Use show route protocol static to display
static routes
user@host> show route protocol static

Route source and preference
0.0.0.0/0 *[Static/5] 00:41:59
> to 172.30.25.1 via ge-0/0/1.0
Default static route Next-hop interface and IP address

Use the ping utility to verify end-to-end reachability:

user@host> ping 192.168.63.14 rapid count 25
PING 192.168.63.14 (192.168.63.14): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!! Test confirms reachability
--- 192.168.63.14 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.027/0.057/0.145/0.032 ms
Monitoring Static Routing
This slide shows the basic verification steps when determining proper operation of static routing. Use the show route
protocol static command to display static routes. The ping utility can be used to verify reachability.

Slide 88
Next-Hop Resolution
Resolving indirect next hops:

By default, the software can resolve only directly connected
next hops
Use the resolve option to allow resolution of indirectly
connected next-hops:
Host-A Host-B Host-C
.1 .2 .5 .6 .1
172.25.1.0/30 172.25.1.4/30 172.20.3.0/24
user@Host-A# show Indirect next-hop
static {
route 172.20.3.0/24 {
next-hop 172.25.1.6;
resolve; resolve option required
}
}
Next-Hop Resolution
By default, the Junos OS requires that the next-hop IP address of static routes be reachable using a direct route.
Unlike software from other vendors, the Junos OS does not perform recursive lookups of next hops by default.
As illustrated on this slide, you can alter the default next-hop resolution behavior using the resolve CLI option. In
addition to the resolve CLI option, a route to the indirect next-hop is also required. Indirect next-hops can be resolved
through another static route or through a dynamic routing protocol. We recommend, whenever possible, that you use
a dynamic routing protocol as your method of resolution. Using a dynamic routing protocol rather than a static route to
resolve indirect next-hops, dynamically removes the static route if the indirect next-hop becomes unavailable.

Slide 89
Qualified Next-Hops
Use qualified-next-hop to allow independent
preference for static routes to the same destination
172.30.25.0/30
ge-0/0/1
.2 primary .1
Network A
172.29.100.0/24 Internet
.1 .6 secondary .5
se-1/0/0
172.30.25.4/30
user@host# show Primary next-hop due to
static { default route preference (5)
route 0.0.0.0/0 {
next-hop 172.30.25.1;
qualified-next-hop 172.30.25.5 {
preference 7;
} Secondary next-hop due to
} configured route preference (7)
}
Qualified Next-Hops
The qualified-next-hop option allows independent preferences for static routes to the same destination. This slide
shows an example using the qualified-next-hop option.
In the example configuration shown on this slide, the 172.30.25.1 next-hop assumes the default static route
preference of 5, whereas the qualified 172.30.25.5 next-hop, uses the defined route preference of 7. All traffic using
this static route uses the 172.30.25.1 next-hop unless it becomes unavailable. If the 172.30.25.1 next-hop becomes
unavailable, the device uses the 172.30.25.5 next-hop. Some vendors refer to this implementation as a floating static
route.

Slide 90
Dynamic Routing
A method of dynamically learning routing information

Dynamic routing has the following benefits:
Lower administrative overhead
Increased network availability
Greater network scalability
Static routing Dynamic routing
Dynamic Routing
Static routing is ideal in small networks where only a few routes exist, or in networks where absolute control of routing
is required. However, static routing has certain drawbacks that might make it cumbersome and hard to manage in
large environments where growth and change are constant. For large networks or networks that change regularly,
dynamic routing might be the best option.
With dynamic routing, you simply configure the network interfaces to participate in a routing protocol. Devices running
routing protocols can dynamically learn routing information from each other. When a device adds or removes routing
information for a participating device, all other devices automatically update.
Dynamic routing resolves many of the limitations and drawbacks of static routing. Some of the general benefits of
dynamic routing include the following:
Lower administrative overhead: The device learns routing information automatically, which eliminates the need for
manual route definition;
Increased network availability: During failure situations, dynamic routing can reroute traffic around the failure
automatically (the ability to react to failures when they occur can provide increased network uptime); and
Greater network scalability: The device easily manages network growth by dynamically learning routes and
calculating the best paths through a network.

Slide 91
Dynamic Routing Protocols
A summary of dynamic routing protocols:

IGPs operate within a single autonomous system
Single network administration that provides for unique routing
policy and flexible use of network resources
Examples include RIP, OSPF, and IS-IS
EGPs operate among different autonomous systems
Independent administrative entities that communicate between
independent network infrastructures
Current EGP in use today is BGP
AS 64513
IGP IGP
IGP
IBGP
AS 64512 AS 65535
AS = Autonomous system
EBGP = External BGP
Dynamic Routing Protocols
Although there are many types of routing protocols, two major categories are in widespread use in todays IP
networkinterior gateway protocols (IGPs) and exterior gateway protocols (EGPs).
IGPs distribute routing information to routers within an autonomous system (AS). Examples include RIP, OSPF, and
IS-IS.
EGPs distribute routing information to routers that connect separate autonomous systems. BGP is the current EGP in
use today.

Slide 92
OSPF Protocol
OSPF is a link-state IGP that:

Reliably floods link-state information to neighbors
Creates a complete database of network
Calculates best path to each destination
Uses areas to incorporate hierarchy and allow for scalability
AS 64512
Area 0.0.0.1 Area 0.0.0.0 Area 0.0.0.2
OSPF Protocol
OSPF is a link-state routing protocol designed for use within an AS. OSPF is an IGP. Link-state protocols allow for
faster reconvergence, support larger internetworks, and are less susceptible to bad routing information than distance-
vector protocols. It is common to refer to distance-vector protocols learning as learning by rumor, where a router
learns about prefixes from neighboring routers perspectives. Routers using link-state routing protocols learn network
topology by propaganda, where they learn the topology from all the routers directly.
Devices running OSPF send out information about their network links and the state of those links to other routers in
the AS. This information transmits reliably to all other routers in the AS by means of link-state advertisements (LSAs).
The other routers receive this information, and each router stores it locally. This total set of information now contains
all possible links in the network.
In addition to flooding LSAs and discovering neighbors, a third major task of the link-state routing protocol is
establishing the link-state database. The link-state (or topological) database stores the LSAs as a series of records.
The important information for the shortest path determination process is the advertising routers ID, its attached
networks and neighboring routers, and the cost associated with those networks or neighbors.
OSPF uses the shortest-path-first (SPF) algorithm (also called the Dijkstra algorithm) to calculate the shortest paths to
all destinations. It does this calculation by calculating a tree of shortest paths incrementally and picking the best
candidate from that tree.
OSPF uses areas to allow for a hierarchical organization and facilitate scalability. An OSPF area is a logical group of
routers. The software can summarize the routing information from an OSPF area and the device can pass it to the rest
of the network. Areas can reduce the size of the link-state database on an individual router. Each OSPF router
maintains a separate link-state database for each area to which it is connected. The link-state database for a given
area is identical for all participating routers within that area.
To ensure correct routing knowledge and connectivity, OSPF maintains a special area called the backbone area.
OSPF designates the backbone area as Area 0.0.0.0. All other OSPF areas must connect themselves to the
backbone for connectivity. All data traffic between OSPF areas must transit the backbone.

Slide 93
Case Study: Objective and Topology
Use a single OSPF area to provide connectivity among

all connected subnets and loopback addresses;
ensure that no adjacencies are formed on interfaces
connecting to the 172.20.x.0/24 subnets
Host-A OSPF Area 0 Host-B
lo0: 192.168.100.1/32 lo0: 192.168.100.2/32
ge-0/0/2
.1 .1 .2 .1
172.20.1.0/24 172.20.2.0/24
ge-0/0/3 172.25.1.0/30
.10 .5
ge-0/0/1
.9 .6
Host-C
lo0: 192.168.100.3/32 .1
172.20.3.0/24
Case Study: Objective and Topology
Over the next several slides, we will take a look at a case study example. This slide provides the objective and sample
topology used in this case study.
Course SSFJUN01J-ML5 Juniper Networks, Inc.

100
Slide 94
Case Study: Configuring OSPF
Sample OSPF configuration taken from Host-A:

user@Host-A# set area 0 interface ge-0/0/1.0
Specify the logical interface. If
unit is not referenced, the
user@Host-A# set area 0 interface ge-0/0/2.0
Junos OS assumes unit 0
user@Host-A# set area 0 interface ge-0/0/3.0 passive Use passive option to
prohibit adjacency
[edit protocols ospf] formation
user@Host-A# set area 0 interface lo0.0

user@Host-A# show The Junos OS converts area 0 to its
area 0.0.0.0 { proper dotted decimal notation (0.0.0.0)
interface ge-0/0/3.0 {
passive;
}
interface lo0.0;
}
Case Study: Configuring OSPF
Note that you must include the lo0 interface if you want the associated IP address (or IP addresses) advertised into
OSPF. Prior to Junos OS Release 8.5, the IP address associated with the lo0 interface was automatically advertised
into OSPF as a router link-state advertisement (LSA).
This slide illustrates the required OSPF configuration for Host-A. Although not shown, Host-B and Host-C require a
similar OSPF configuration to establish adjacencies and share routing information.

101
Slide 95
Case Study: Verifying OSPF Neighbor State

Use show ospf neighbor to display adjacencies
Use detail or extensive options for added information
user@Host-A> show ospf neighbor
Address Interface State ID Pri Dead
172.25.1.9 ge-0/0/1.0 Full 192.168.100.3 128 38
172.25.1.2 ge-0/0/2.0 Full 192.168.100.2 128 35
The state of the adjacencies shows Full,

which means neighbors can exchange
routing information
Case Study: Verifying OSPF Neighbor State
This slide shows the CLI command used to determine OSPF adjacencies. In the sample output on this slide, you can
see that Host-A has formed adjacencies with both Host-B and Host-C.
The following is a description of the fields displayed in the output:

Address: The address of the neighbor.
Interface: The interface through which the neighbor is reachable.
State: The state of the neighbor, which can be Attempt, Down, Exchange, ExStart, Full, Init, Loading, or 2-Way.
ID: The router ID of the neighbor.
Pri: The priority of the neighbor to become the designated router, only used on broadcast networks during
designated router elections. By default, this value is set to 128, indicating the highest priority, and therefore the
most likely router to be elected designated router.
Dead: The number of seconds until the neighbor becomes unreachable.

102
Slide 96
Case Study: Viewing OSPF Routes

Use show route protocol ospf to display
OSPF routes
user@Host-A> show route protocol ospf

172.20.2.0/24 *[OSPF/10] 00:03:55, metric 2

> to 172.25.1.2 via ge-0/0/2.0
172.20.3.0/24 *[OSPF/10] 00:00:04, metric 2
> to 172.25.1.9 via ge-0/0/1.0
172.25.1.4/30 *[OSPF/10] 00:03:46, metric 2
> to 172.25.1.9 via ge-0/0/1.0
to 172.25.1.2 via ge-0/0/2.0
192.168.100.2/32 *[OSPF/10] 00:03:55, metric 1
> to 172.25.1.2 via ge-0/0/2.0
192.168.100.3/32 *[OSPF/10] 00:03:46, metric 1
> to 172.25.1.9 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 00:16:13, metric 1
MultiRecv
Case Study: Viewing OSPF Routes
The slide illustrates the show route protocol ospf command, which displays OSPF routes learned by Host-A. Note that
Host-A does not actually install its directly connected subnets in its route table as OSPF routesit installs them as
direct routes.

103
Slide 97
Lab 3: Configuring OSPF on Junos OS

Devices
Configure and monitor static Configure and monitor OSPF
routing

Lab 3: Configuring OSPF on Junos OS Devices

Configure and monitor static routing; and
Configure and monitor OSPF.
At this point, you should return to the Virtual Lab session you opened previously and complete the lab portion of this
section. When you are finished, return to this presentation and continue.
Enter Virtual Lab:


104
Slide 98
Section Summary

Discussed routing and forwarding tables
Described routing instances
Explored static routing and its configuration using the Junos
OS
Described dynamic routing

Discussed routing and forwarding tables;
Described routing instances;
Explored static routing and its configuration using the Junos OS; and
Described dynamic routing.

105
Slide 99
In the Junos OS, route preference is similar to what

Cisco concept?
A. Administrative distance
B. Route hierarchy
C. Destination table
D. Routing table

106
Slide 99
What are three benefits of dynamic routing? (Choose

three.)
A. Most useful for small networks

B. Lower administrative overhead
C. Increased network availability
D. Greater network scalability

107

108
Slide 100
Junos OS Adoption
Junos OS Adoption

109
Slide 101
Section Objectives
In this section, you will be able to:

Discuss how the Junos OS interoperates with other devices
and integrates to other systems
Present ways in which Juniper eases Junos OS adoption for
new customers
In this section, you will be able to:

Discuss how the Junos OS interoperates with other devices and integrates to other systems; and
Present ways in which Juniper eases Junos OS adoption for new customers.

110
Slide 102
Time Tested Interoperability

Commitment to standards
Involved in industry standards
organization
Support for an extensive set of
networking protocols
Pragmatic approach
Vendor interoperability tests
Focus on interoperability versus
by the letter implementation
of standards
Extensive field experience
Largely deployed in mixed
environments
Years of interoperability
Time Tested Interoperability
Do any of your customers have only one vendor in their network? Most likely, they use multiple vendors. Just as most
of your customers likely have multiple vendors for servers, storage, and other IT systems, they want the flexibility to
use multiple vendors in the network. It is likely that their migration to Juniper solutions will occur over time. So the
ease in which the Junos OS interoperates and integrates into existing infrastructure is essential.
Juniper engineers have long been involved with industry organizations in building open standards for interoperability.
For example, Junos developers have been at the forefront of defining and implementing MPLS applications, next-
generation multicast VPN architectures, and high-availability features such as non-stop active routing and in-service
software upgrades.
Junos supports hundreds of networking protocolsstandards such as spanning tree, LLDP, OSPF, BGP, IPv6, and
MPLS, to name just a few. Nonetheless, the practicalities of interoperability require that Juniper goes beyond simply
implementing the standards. For example, filling in gaps in cases of differences in interpretation or where de-facto
standards are used. This practical approach is necessary to support the thousands of Junos OS customers.
Interoperability between Juniper and other large networking vendors has been proven several times over, in the best
possible way, with live network implementations in the largest networks over many years.

111
Slide 103
What Doesnt Work?
Proprietary Legacy
EIGRP IPX
PVST and PVST+ Appletalk
HSRP And so on...
WCCP
And so on...
What Doesnt Work?
A few organizations might still be running proprietary or legacy protocols within their network. In these cases, the
customer will either have to transition to modern standards or adopt one of the available methods of supporting these
protocols over a standards-based infrastructure. For example, there are various approaches to simultaneously running
EIGRP and OSPF in legacy routers to support a long term transition to OSPF. By moving to open standards,
organizations benefit from the collective innovation of the industry. Open standards generally offer a broader set of
capabilities than protocols developed exclusively by one vendor.

112
Slide 104
Standards-Based Integration to Systems

Integration to NMS and other
operations tools
Retrieve operational and
configuration information
Efficiently search, modify, and upload full
or partial device configuration information
Standardized system logging messages
and SNMP interfaces
NETCONF XML Interface
NETCONF XML
Defines an XML-based data encoding for
configuration data as well as the protocol
messages
Enables other systems to request and
change configuration information in a
standard way
Standards-Based Integration to Systems
Operations teams use tens, sometimes hundreds, of different tools to manage their networks, for examples tools for
inventory, configuration, provisioning, monitoring, and managing faults. Many are home grown while others are
purchased from one of the many independent software vendors who develop network management products. Juniper
works in close partnership with these vendors to integrate management of Junos into their solutions.
Juniper streamlines integration of partner and customer systems by providing a number of open, standard interfaces
in the Junos OS. In addition to the CLI, standardized system logging messages, SNMP interfaces, and on-board
instrumentation systems, the Junos OS also provides an XML (eXtensible Markup Language) interface. All these open
options let network management tools interact with the Junos OS in a reliable and predictable way.

113
Slide 105
IOS to Junos Translator
Customers migrating
from Cisco to Juniper?
ScreenOS to Junos OS?
Convert from other operating system to Junos OS

IOS routing and switching https://i2j.juniper.net/release/index.jsp
ScreenOS to Junos OS https://i2j.juniper.net/s2j
Available on the Juniper support site:
https://www.juniper.net/customers/support/#tools
IOS to Junos Translator
Are your customers migrating from Cisco to Juniper? Ease the transition with the I2J translator tool, a configuration
translator that converts Cisco IOS software configurations to Junos OS configurations. Juniper also provides tools for
ScreenOS to JunosOS translation and many other resources on the Juniper support site at the links shown on the
slide. A login is required.

114
Slide 106
Getting Started with the Junos OS

https://www.juniper.net/us/en/training/
Training /certification
New user to expert
Fast Track
Offers significant time
and cost savings
Books
Day One books
OReilly Technical Library
https://www.juniper.net/us/
en/training/jnbooks/
Getting Started with the Junos OS
There are a number of ways to get started using the Junos OS. Information on presales and post sales training and
certifications are available in the Partner Center. Certification training is available, from new user level to the expert
level. We also offer a Fast Track program for those who are already familiar with other vendors products. This
program will offer the student discounts and time savings in certifying on the Junos OS.
Juniper also offers several publications including Day One downloads (available for e-readers as well as in PDF
format), and a full technical library of books from the publisher OReilly.
Training materials can be found at the links shown on the slide. A login will be needed for some of these resources.

115
Slide 107
Section Summary

Discussed how the Junos OS interoperates with other
devices and integrates to other systems
Presented ways in which Juniper eases Junos OS adoption
for new customers

Discussed how the Junos OS interoperates with other devices and integrates to other systems; and
Presented ways in which Juniper eases Junos OS adoption for new customers.

116
Slide 108
True or false: Devices running the Junos OS can only

interoperate with other devices running the Junos OS.
A. True
B. False

117
Slide 109
Course Summary
In this course, we:

Provided an overview of the Junos OS and its benefits
Explored Junos OS architecture and design
Described the Juniper platforms running the Junos OS
Explored routing using the Junos OS
Discussed the tools and resources available to help
customer transition to the Junos OS
In this course, we:

Provided an overview of the Junos OS and its benefits;
Explored Junos OS architecture and design;
Described the Juniper platforms running the Junos OS;
Explored routing using the Junos OS; and
Discussed the tools and resources available to help customer transition to the Junos OS.

118
Slide 110
Additional Resources
Education Services training classes

http://www.juniper.net/training/technical_education/
Juniper Networks Certification Program Web site
www.juniper.net/certification
Juniper Networks documentation and white papers
www.juniper.net/techpubs
To submit errata or for general questions
elearning@juniper.net
For additional resources or to contact the Juniper Networks eLearning team, click the links on the screen.

119
Slide 111
Evaluation and Survey
You have reached the end of this Juniper Networks

eLearning module
You should now return to your Juniper Learning
Center to take the assessment and the student
survey
After successfully completing the assessment, you will earn
credits that will be recognized through certificates and non-
monetary rewards
The survey will allow you to give feedback on the quality and
usefulness of the course
You have reached the end of this Juniper Networks eLearning module. You should now return to your Juniper
Learning Center to take the assessment and the student survey. After successfully completing the assessment, you
will earn credits that will be recognized through certificates and non-monetary rewards. The survey will allow you to
give feedback on the quality and usefulness of the course.

120
Slide 112
Copyright 2015 Juniper Networks, Inc.
All rights reserved. JUNIPER NETWORKS, the Juniper Networks logo,

JUNOS, QFABRIC, NETSCREEN, and SCREENOS are registered
trademarks of Juniper Networks, Inc. in the United States and other
countries. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their
respective owners.
Copyright 2015 Juniper Networks, Inc.
All rights reserved. JUNIPER NETWORKS, the Juniper Networks logo, JUNOS, QFABRIC, NETSCREEN, and
SCREENOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective
owners. Juniper Networks reserves the right to change, modify, transfer or otherwise revise this publication without
notice.

121
Slide 113
CONFIDENTIAL

122
e d u c a t io n se r v ic e s c o u rse w a re
Co rp o rat e and Sales Head q uart ers APAC Head q uart ers EM EA Head q ua rt ers Copyright 20 10 Junip er Net w orks, Inc.
All right s reserved. Junip er Net w o rks,
Junip er Net w orks, Inc. Junip er Net w orks ( Ho ng Kong) Junip er Net w orks Ireland t he Junip er Net w orks lo go, Juno s,
119 4 Nort h Mat hild a Avenue 26 / F, Cit yp laza One Airsid e Business Park Net Screen, and ScreenOS are regist ered
Sunnyvale, CA 9 4 0 8 9 USA 1111 Kings Ro ad Sw ord s, Co unt y Dub l in, Ireland t rad em arks of Junip er Net w o rks, Inc. in
Phone: 8 8 8 .JUNIPER Taikoo Shing, Ho ng Kong Phone: 35 .31.8 9 0 3.6 0 0 t he Unit ed St at es and ot her count ries.
( 8 8 8 .5 8 6 .4737) Phone: 8 5 2.2332.36 36 EMEA Sales: 0 0 8 0 0 .4 58 6 .4737 All o t her t rad em arks, service m arks,
or 4 0 8 .74 5 .20 0 0 Fax: 8 5 2.2574 .78 0 3 Fax: 35 .31.8 9 0 3.6 0 1 regist ered m arks, or regist ered service
Fax: 4 0 8 .74 5.210 0 m arks are t he p ro p ert y of t heir
w w w.junip er.net resp ect ive ow ners. Junip er Net w orks
assum es no resp o nsib ilit y f or any
inaccuracies in t his d o cum ent . Junip er
Net w orks reserves t he right t o change,
m o d if y, t ransf er, o r ot herw ise revise t his
p ub l icat ion w it hout not ice.

Ssfjun01j ML5

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ssfjun01j ML5

Încărcat de

Drepturi de autor:

Formate disponibile

e d u c a t io n se rv ic e s c o u rse w a re

Junos Operating System

Build the Best

Course SSFJUN01J-ML5 Juniper Networks, Inc. 2

Junos Operating System Highlights

Welcome to Juniper Networks Junos Operating System Highlights eLearning module.

Course SSFJUN01J-ML5 Juniper Networks, Inc. 3

Course SSFJUN01J-ML5 Juniper Networks, Inc. 4

After successfully completing this course, you will be

After successfully completing this course, you will be able to:

Course SSFJUN01J-ML5 Juniper Networks, Inc. 5

Agenda: Junos Operating System Highlights

An Introduction to the Junos OS

Course SSFJUN01J-ML5 Juniper Networks, Inc. 6

Junos Operating System Highlights

An Introduction to the Junos OS

An Introduction to the Junos OS

Course SSFJUN01J-ML5 Juniper Networks, Inc. 7

After successfully completing this section, you will be

After successfully completing this section, you will be able to:

Course SSFJUN01J-ML5 Juniper Networks, Inc. 8

A common language across Junipers routing,

Routing Switching Security

Course SSFJUN01J-ML5 Juniper Networks, Inc. 9

Increasing Demands on High-Performance Networks

Course SSFJUN01J-ML5 Juniper Networks, Inc. 10

Junos OS: The Foundation of

Junos OS: The Foundation of High-Performance Networks

Course SSFJUN01J-ML5 Juniper Networks, Inc. 11

SDK = software development kit

Course SSFJUN01J-ML5 Juniper Networks, Inc. 12

A Single Software Release Train

Disciplined process for development

11.4 12.3 13.2 13.3

A Single Software Release Train

Course SSFJUN01J-ML5 Juniper Networks, Inc. 13

Allows for the rapid introduction of new security

12.1X44 12.1X45 12.1X46

Course SSFJUN01J-ML5 Juniper Networks, Inc. 14

One Junos SRX5800

12.1X44 12.1X45 12.1X46

Course SSFJUN01J-ML5 Juniper Networks, Inc. 15

Separation of Control and Forwarding

The control plane is where the RE runs

Separation of Control and Forwarding

Course SSFJUN01J-ML5 Juniper Networks, Inc. 16

Routing Engine and

Control Plane Internal link

Packet Forwarding Engine

Routing Engine and Packet Forwarding Engine

Lets look at the architecture in more detail.

Course SSFJUN01J-ML5 Juniper Networks, Inc. 17

Course SSFJUN01J-ML5 Juniper Networks, Inc. 18

ACX Series LN Series M Series

MX Series PTX Series T Series

The following Juniper routing platforms run the Junos OS.

Course SSFJUN01J-ML5 Juniper Networks, Inc. 19

EX Series QFX Series

Junipers three switching platforms also run the Junos OS.

Course SSFJUN01J-ML5 Juniper Networks, Inc. 20

Course SSFJUN01J-ML5 Juniper Networks, Inc. 21

The Junos OS on Virtual Platforms

Virtual SRX (vSRX)