Junos® OS
Overview for Junos OS
Published
2024-06-23
Juniper Networks, Inc.
1133 Innovaon Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. All other trademarks, service marks, registered marks, or registered service
marks are the property of their respecve owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right
to change, modify, transfer, or otherwise revise this publicaon without noce.
Junos® OS Overview for Junos OS
Copyright © 2024 Juniper Networks, Inc. All rights reserved.
The informaon in this document is current as of the date on the tle page.
YEAR 2000 NOTICE
Juniper Networks hardware and soware products are Year 2000 compliant. Junos OS has no known me-related
limitaons through the year 2038. However, the NTP applicaon is known to have some diculty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentaon consists of (or is intended for use
with) Juniper Networks soware. Use of such soware is subject to the terms and condions of the End User License
Agreement ("EULA") posted at hps://support.juniper.net/support/eula/. By downloading, installing or using such
soware, you agree to the terms and condions of that EULA.
ii
Table of Contents
About This Guide | vi
1
Understanding Junos OS
Junos OS Soware Overview | 2
About the Overview for Junos OS | 2
Junos OS Overview | 3
Junos OS Architecture Overview | 5
Router Hardware Components | 7
Junos OS Roung Engine Components and Processes | 9
Junos OS Roung Processes | 11
Default Directories for Junos OS File Storage on the Network Device | 22
Junos OS Support for IPv4, IPv6, and MPLS Roung Protocols | 24
Junos OS Roung and Forwarding Tables | 26
Roung Policy Overview | 27
Junos OS Support for VPNs | 28
Conguring FIB Localizaon | 29
FIB Localizaon Overview | 29
Example: Conguring Packet Forwarding Engine FIB Localizaon | 30
Requirements | 31
Overview | 31
Conguraon | 31
Vericaon | 34
Junos OS Security Overview | 38
Junos OS Features for Device Security | 38
Junos OS Default Sengs for Device Security | 43
Junos OS Conguraon Overview | 44
iii
Junos OS Conguraon Basics | 44
Methods for Conguring Junos OS | 45
Junos OS Conguraon from External Devices | 48
The Commit Model for Conguraons | 48
Conguraon Groups Overview | 50
2
Conguring and Administering Junos Devices
Conguring Junos Devices | 52
Inial Router or Switch Conguraon Using Junos OS | 52
Conguring Junos OS for the First Time on a Device with a Single Roung Engine | 53
Conguring Junos OS for the First Time on a Device with Dual Roung Engines | 58
How to Improve Commit Time When Using Conguraon Groups | 64
Creang and Acvang a Candidate Conguraon | 65
Format for Specifying IP Addresses, Network Masks, and Prexes in Junos OS Conguraon
Statements | 65
Format for Specifying Filenames and URLs in Junos OS CLI Commands | 66
Mapping the Name of the Router to IP Addresses | 67
Conguring Automac Mirroring of the CompactFlash Card on the Hard Drive | 68
Using Junos OS to Specify the Number of Conguraons Stored on the CompactFlash Card | 69
Back Up Conguraons to an Archive Site | 70
Congure the Transfer of the Acve Conguraon | 70
Conguring Junos OS to Set Console and Auxiliary Port Properes | 72
Monitoring Junos Devices | 74
Junos OS Tools for Monitoring | 74
Tracing and Logging Junos OS Operaons | 75
Understanding Dropped Packets and Untransmied Trac Using show Commands | 77
Log a User Out of the Device | 81
Managing Junos OS Processes | 82
iv
Saving Core Files from Junos OS Processes | 82
Viewing Core Files from Junos OS Processes | 83
Disabling Junos OS Processes | 84
Conguring Failover to Backup Media If a Junos OS Process Fails | 84
Using Virtual Memory for Process Conguraon Data | 85
3
Conguraon Statements and Operaonal Commands
Junos CLI Reference Overview | 87
v
About This Guide
Use this guide to get familiar with the various funcons of Junos OS devices, and learn how to
congure, monitor, and manage them.
vi
CHAPTER 1
Junos OS Soware Overview
IN THIS CHAPTER
About the Overview for Junos OS | 2
Junos OS Overview | 3
Junos OS Architecture Overview | 5
Router Hardware Components | 7
Junos OS Roung Engine Components and Processes | 9
Junos OS Roung Processes | 11
Default Directories for Junos OS File Storage on the Network Device | 22
Junos OS Support for IPv4, IPv6, and MPLS Roung Protocols | 24
Junos OS Roung and Forwarding Tables | 26
Roung Policy Overview | 27
Junos OS Support for VPNs | 28
Conguring FIB Localizaon | 29
About the Overview for Junos OS
The Overview for Junos OS is intended to provide a technical and detailed exploraon of Junos OS,
explaining both concepts and operaonal principles, as well as how to congure and use Juniper
Networks devices.
In this guide, we cover:
• Understanding Junos OS
• Security management
• Device conguraon
• Device monitoring
• Managing network devices
2
• Using conguraon statements and operaonal commands
For a basic introducon to Junos OS, see the Geng Started Guide for Junos OS. It provides a high-level
descripon of Junos OS, describes how to access devices, and provides simple step-by-step instrucons
for inial device conguraon.
For introductory and overview informaon specic to Junos OS Evolved, see Introducing Junos OS
Evolved. This guide will acquaint you with Junos OS Evolved, the next generaon Junos OS, and explain
its strengths, similaries to, and dierences from Junos OS.
To learn how to use the Junos OS command-line interface (CLI) and understand more advanced Junos
OS topics, see the CLI User Guide. This guide explains how to use the CLI, enter conguraon
statements, manage conguraons, and enter operaonal commands for monitoring Junos OS
networking devices.
RELATED DOCUMENTATION
CLI User Guide
Geng Started Guide for Junos OS
Introducing Junos OS Evolved
Junos OS Overview
Juniper Networks provides high-performance network devices that create a responsive and trusted
environment for accelerang the deployment of services and applicaons over a single network. The
Junos operang system (Junos OS) is the foundaon of these high-performance networks. Unlike other
complex, monolithic soware architectures, Junos OS incorporates key design and developmental
dierences to deliver increased network availability, operaonal eciency, and exibility. These key
advantages are:
• One operang system
• Concurrent soware releases
• Modular soware architecture
One Operang System
Unlike other network operang systems that share a common name but splinter into many dierent
programs, Junos OS is a cohesive operang system that is supported across all devices and product
lines. This enables Juniper Networks engineers to develop soware features once and share the features
across product lines simultaneously. Because features are common to a single source, generally these
3
features are implemented the same way for all of the product lines, reducing the training required to
learn dierent tools and methods for each product.
Concurrent Soware Releases
Each new mainline version of Junos OS is released concurrently for all product lines. Each new Junos OS
release includes working features released in previous versions of the soware and must achieve zero
crical regression errors. Any deprecated features or funcons are not only announced, but any needed
workarounds or soluons are provided. This discipline ensures reliable operaons for the enre release.
Modular Soware Architecture
Although individual architecture modules of Junos OS communicate through well-dened interfaces,
each module runs in its own protected memory space, prevenng one module from disrupng another.
It also enables the independent restart of each module as necessary. This is in contrast to monolithic
operang systems for which a malfuncon in one module can ripple to other modules, possibly causing
a full system crash or restart. This modular Junos OS architecture provides a high level of performance,
high availability, security, and device scalability not found in other operang systems.
Generally, Junos OS is preinstalled on your Juniper Networks device when you receive it from the
factory. When you rst power on the device, all soware starts automacally. You then congure the
soware so that the device can parcipate in your network. However, if needed, you can order Juniper
Networks devices without any soware installed, for addional exibility.
You can upgrade the device soware as new features are added or soware problems are xed. You
obtain new soware by downloading images from the Juniper Networks Support website onto your
device or another system on your local network, then install the soware upgrade on the device.
Juniper Networks devices run only binaries supplied by Juniper Networks. Each Junos OS image
includes a digitally signed manifest of executables, which are registered with the system only if the
signature can be validated. Junos OS will not execute any binary without a registered ngerprint. This
feature protects the system against unauthorized soware and acvity that might compromise the
integrity of your network devices.
RELATED DOCUMENTATION
Junos OS Architecture Overview | 5
Junos OS Commit Model for Conguraons
Junos OS Conguraon Basics | 44
Router Hardware Components | 7
Junos OS Roung and Forwarding Tables | 26
Junos OS Roung Engine Components and Processes | 9
Junos OS Support for IPv4, IPv6, and MPLS Roung Protocols | 24
4
Junos OS Support for VPNs | 28
Roung Policy Overview | 27
Junos OS Architecture Overview
IN THIS SECTION
Roung Process Architecture | 5
This topic provides an overview of the Junos OS
roung process architecture:
Roung Process Architecture
The roung process is handled by the following two components (see Figure 1 on page 6):
•
Roung Engine
•
Packet Forwarding Engine
Because this architecture separates control operaons such as roung updates and system management
from packet forwarding, the router can deliver superior performance and highly reliable Internet
operaon.
5
Figure 1: Product Architecture
Packet Forwarding Engine
The Packet Forwarding Engine uses applicaon-specic integrated circuits (
ASIC
s) to perform Layer 2
and Layer 3 packet switching, route lookups, and packet forwarding. The Packet Forwarding Engine
forwards packets between input and output interfaces.
Roung Engine
The Roung Engine controls the roung updates and the system management. The Roung Engine
consists of roung protocol soware processes running inside a protected memory environment on a
general-purpose computer plaorm. The Roung Engine handles all of the roung protocol processes
6
and other soware processes that control the routers’ interfaces, some of the chassis components,
system management, and user access to the router. These routers and soware processes run on top of
a kernel that interacts with the Packet Forwarding Engine.
The Roung Engine has these features:
• Roung protocol packets processing—All roung protocol packets from the network are directed to
the Roung Engine, and therefore do not unnecessarily delay the Packet Forwarding Engine.
• Soware modularity—Soware funcons are in separate processes, so a failure of one process has
lile or no eect on other soware processes.
• In-depth IP funconality—Each roung protocol is implemented with a complete set of IP features
and provides full exibility for adversing, ltering, and modifying routes. Roung policies are set
according to route parameters, such as
prex
, prex lengths, and Border Gateway Protocol (
BGP
)
aributes.
• Scalability—Junos OS roung tables are designed to hold all the routes used in current and near-
future networks. Addionally, Junos OS can eciently support large numbers of
interfaces
and
virtual circuit
s.
• Storage and change management—Conguraon les, system images, and microcode are held and
maintained in one primary and two secondary storage systems, perming local or remote upgrades.
• Monitoring eciency and exibility—Alarms are generated and packets are counted without
adversely aecng packet forwarding performance.
The Roung Engine constructs and maintains one or more roung tables. From the roung tables, the
Roung Engine derives a table of acve routes, called the
forwarding table
, which is then copied into the
Packet Forwarding Engine. The forwarding table in the Packet Forwarding Engine can be updated
without interrupng the router’s forwarding.
RELATED DOCUMENTATION
Junos OS Overview | 3
Router Hardware Components
Junos OS runs on all Juniper Networks devices, including both routers and switches. This secon
focuses specically on router hardware components.
Table 1 on page 8 lists the major hardware components in each router series.
7
NOTE: The ACX Series router is a single-board router with a built-in Roung Engine and one
Packet Forwarding Engine. The “pseudo” FPCs and PICs are described in
ACX2000 and
ACX2100 Routers Hardware and CLI Terminology Mapping
.
Table 1: Major Router Hardware Components
M Series MX Series T Series PTX Series J Series
Roung Engines X X X X X
Control Board X X X
Switch Interface Board (SIB) X X X
Forwarding Engine Board (FEB) X
Power Supply X X X X X
Cooling System X X X X X
Dense Port Concentrators (DPC) X
Switch Control Board (SCB) X
Flexible PIC Concentrators (FPC) X X X X
Physical Interface Module (PIM) X
Physical Interface Card (PIC) X X X X
Flexible PIC Concentrators (
FPCs
) are each populated by
PICs
for various interface types. On some
routers, the PICs are installed directly in the chassis.
For informaon about specic components in your router, refer to its hardware guide.
8
RELATED DOCUMENTATION
Junos OS Architecture Overview | 5
Junos OS Roung Engine Components and Processes
IN THIS SECTION
Roung Engine Kernel | 9
Inializaon Process | 10
Management Process | 10
Process Limits | 10
Roung Protocol Process | 10
Interface Process | 10
Chassis Process | 11
SNMP and MIB II Processes | 11
Junos OS also runs on the
Roung Engine
. Junos OS consists of soware processes that support
Internet roung
protocols
, control router interfaces and the router chassis, enable router system
management, and much more. Junos OS processes run on top of a
kernel
, which enables communicaon
between processes and provides a direct link to the Packet Forwarding Engine soware. Junos OS can
be used to congure roung protocols and router interface properes, as well as to monitor and
troubleshoot protocol and network connecvity problems.
The Roung Engine soware consists of several soware processes that control router funconality and
a kernel that provides the communicaon among the processes. Following is a lisng of the major
Roung Engine-related processes.
Roung Engine Kernel
The Roung Engine kernel provides the underlying infrastructure for all Junos OS processes, including
providing the link between the roung tables and the Roung Engine’s forwarding table. The kernel is
also responsible for all communicaon with the
Packet Forwarding Engine
, which includes keeping the
Packet Forwarding Engine’s copy of the forwarding table synchronized with the master copy in the
Roung Engine.
9
Inializaon Process
When the device boots, an inializaon process (init) starts and monitors all the other soware
processes.
If a soware process terminates or fails to start when called, the init process aempts to restart it a
limited number of mes and logs any failure informaon for further invesgaon.
Management Process
The management process (mgd) manages the conguraon of the router and all user commands. The
management process is responsible for nofying other processes when a new conguraon is
commied. A dedicated management process handles Junos XML protocol XML requests from its client,
which might be the CLI or any Junos XML protocol client.
Process Limits
There are limits to the total number of Junos OS processes that can run simultaneously on a device.
There are also limits set for the maximum number of iteraons of any single process. The limit for
iteraons of any single process can only be reached if the limit of overall system processes is not
exceeded.
Access methods such as
telnet
and
SSH
spawn mulple system processes for each session created. For
this reason, it might not be possible to simultaneously support the maximum number of access sessions
for mulple services.
Roung Protocol Process
Within Junos OS, the roung protocol process (rpd) controls the roung protocols that run on the
device. The rpd process starts all congured roung protocols and handles all roung messages. It
maintains one or more roung tables, which consolidate the roung informaon learned from all roung
protocols. From this roung informaon, the roung protocol process determines the acve routes to
network desnaons and installs these routes into the Roung Engine’s forwarding table. Finally, rpd
implements roung policy, which enables you to control the roung informaon that is transferred
between the roung protocols and the roung table. Using roung policy, you can lter and limit the
transfer of informaon as well as set properes associated with specic routes.
Interface Process
The Junos OS interface process enables you to congure and control the physical interface devices and
logical interfaces present in a network device. You can congure interface properes such as the
interface locaon, for example, in which slot the Flexible PIC Concentrator (FPC) is installed and in
10
which locaon on the FPC the
Physical Interface Card
(PIC) is installed, as well as the interface
encapsulaon and interface-specic properes. You can congure the interfaces currently present in the
device, as well as interfaces that are not present but that you might add later.
The Junos OS interface process communicates through the Junos OS kernel with the interface process
in the Packet Forwarding Engine, enabling Junos OS to track the status and condion of the network
device’s interfaces.
Chassis Process
The Junos OS chassis process (chassisd) enables you to congure and control the properes of the
device, including condions that trigger alarms. The chassisd on the Roung Engine communicates
directly with its peer processes running on the Packet Forwarding Engine.
SNMP and MIB II Processes
Junos OS supports the Simple Network Management Protocol (
SNMP
), which helps administrators
monitor the state of a device. The soware supports SNMP version 1 (SNMPv1), version 2 (SNMPv2,
also known as version 2c, or v2c), and version 3 (SNMPv3). The Junos OS implementaon of SNMP
does not include any of the security features that were originally included in the
IETF
SNMP dras but
were later dropped. The SNMP soware is controlled by the Junos OS SNMP and Management
Informaon Base II (MIB II) processes, which consist of an SNMP master agent and various subagents.
RELATED DOCUMENTATION
Junos OS Architecture Overview | 5
Junos OS Roung Processes
Junos OS consists of mulple processes that run on dierent plaorms and have unique funcons. The
separaon of funcons provides operaonal stability, because each process accesses its own protected
memory space. This secon provides a brief overview of Junos OS roung-specic processes.
As an example, Table 2 on page 12 describes the processes that run on MX Series 5G Universal
Roung Plaorms.
11
Table 2: Junos OS Processes on MX Series Plaorm
Process Name Descripon
Clksync process (RE) clksyncd Denes the operaon of synchronous Ethernet and
Precision Time Protocol (
PTP
) on a Juniper Networks
MX Series router. The operaon includes
communicaon with the Packet Forwarding Engine
(clock-sync module) to program and process clock
events from the
EEC
clock.
Operates the PTP stack, exchanges packets, and
handles the conguraon changes for the modular
MX Series (MX80).
Controls the conguraon and monitoring of the
overall operaon of the PTP funconality for chassis-
based MX Series plaorms (MX240, MX480, and so
on).
Clock-sync process (PFE) clock-sync Programs and monitors the modular interface card
(MIC), the CPLD, and the EEC clock. Peer of the
clksyncd process module.
Captures all PTP and Synchronous Ethernet stascs
on the Packet Forwarding Engine and provides them
to the Roung Engine.
Interchassis communicaon
process
iccpd Exchanges proprietary Junos OS messages between
two Juniper Networks MX Series routers that take
part in a mulchassis link aggregaon group (
LAG
).
Stascs agent process stats-agentd Acts as a relay process to collect interface stascs
for all soware development kit (
SDK
) applicaons.
Interacts with the pfed process to collect the logical
interface stascs for SDK applicaons.
Table 3 on page 13 lists other processes that are common across Junos OS roung plaorms.
12
Table 3: Junos OS Roung-Specic Processes
Process Name Descripon
Adapve services
process
adapve-services Manages the conguraon for
stateful rewall
,
Network Address Translaon (
NAT
), intrusion
detecon service (
IDS
), and IP Security (
IPsec
)
services on the Adapve Services
PIC
.
Alarm control process alarm-control Congures the system alarm.
Access Node Control
Protocol (
ANCP
)
process
ancpd-service Works with a special Internet Group Management
Protocol (
IGMP
) session to collect outgoing interface
mapping events in a scalable manner.
Applicaon
idencaon process
applicaon-idencaon Idenes an applicaon using intrusion detecon
and prevenon (
IDP
) to allow or deny trac based
on applicaons running on standard or nonstandard
ports.
RADIUS
accounng
process
audit-process Gathers stascal data that can be used for general
network monitoring, analyzing, and tracking usage
paerns, for billing a user based upon the amount of
me or type of services accessed.
Auto-conguraon
process
auto-conguraon Congures interfaces automacally.
Boot process bootp Enables a router, switch, or interface to act as a
Dynamic Host Conguraon Protocol (
DHCP
) or
bootstrap protocol (
BOOTP
) relay agent. DHCP
relaying is disabled.
Capve portal
content delivery
process
capve-portal-content-delivery Species the locaon to which a subscriber's inial
Internet browser session is redirected, enabling
inial provisioning and service selecon for the
subscriber.
13
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
Universal Edge Layer
2 Tunneling Protocol
process
ce-l2tp-service (M10, M10i, M7i, and MX Series routers only)
Establishes L2TP tunnels and Point-to-Point
Protocol (
PPP
) sessions through L2TP tunnels.
Ethernet
OAM
connecvity fault
management process
cfm Monitors the physical link between two switches.
Chassis control
process
chassis-control Manages the chassis.
Class of service
process
class-of-service Controls the network device’s
CoS
conguraon.
Ethernet clock
synchronizaon
process
clksyncd-service Uses Synchronous Ethernet (
SyncE
) for external
clock synchronizaon .
Cra interface
I/O
control process
cra-control Controls the I/O of the cra interface.
Database replicaon
process
database-replicaon (EX Series switches and MX Series routers only)
Manages the replicaon of updates from the
primary to the client in the database management
system.
Datapath trace
process
datapath-trace-service Traces the path taken by the packet through the
network.
Dynamic Host
Conguraon
Protocol process
dhcp-service (EX Series switches and MX Series routers only)
Enables a DHCP server to allocate network IP
addresses and deliver conguraon sengs to client
hosts without user intervenon.
14
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
Diameter process diameter-service Implements the Diameter protocol which uses the
Transmission Control Protocol (
TCP
) and Stream
Control Transmission Protocol (
SCTP
) instead of
User Datagram Protocol (
UDP
), for monitoring the
network.
Disk monitoring
process
disk-monitoring Checks the health of the hard drive on the Roung
Engine.
Dynamic ow
capture (
DFC
)
process
dynamic-ow-capture Controls the DFC conguraons on Monitoring
Services III PICs.
ECC
parity errors
logging process
ecc-error-logging Logs the ECC parity errors into the memory on the
Roung Engine.
Connecvity fault
management (
CFM
)
process
ethernet-connecvity-
fault-management
Provides IEEE 802.1ag OAM CFM database
informaon for CFM maintenance associaon end
points
(MEPs
) in a CFM session.
Ethernet
OAM
Link-
Fault-Management
process
ethernet-link-fault-management (EX Series switches and MX Series routers only)
Provides the OAM link fault management (
LFM
)
informaon for Ethernet interfaces.
Event processing
process
event-processing
or
eventd
Congures the applicaon to handle all generated
events.
Firewall
process rewall Manages the rewall conguraon and enables
accepng or rejecng packets that are transing an
interface on a device.
15
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
General
authencaon
process
general-authencaon-service (EX Series switches and MX Series routers only)
Manages general authencaon of a user.
Inter-Chassis
Communicaon
Protocol (
ICCP
)
process
iccp-service Synchronizes data within a set of two (or more)
PEs
that form a redundancy group (
RG
).
IDP
policy process idp-policy Enables various aack detecon and prevenon
techniques on trac traversing the network.
Integrated Local
Management
Interface process
ilmi Provides bidireconal exchange of management
informaon between two Asynchronous Transfer
Mode (
ATM
) interfaces across a physical connecon.
Inet process inet-process Congures the IP mulcast family.
Init process init Inializes the
USB
modem.
Interface control
process
interface-control Controls the router's or switch’s physical interface
devices and logical interfaces.
Kernel replicaon
process
kernel-replicaon Replicates the state of the backup Roung Engine
when graceful Roung Engine switchover (
GRES
) is
congured.
16
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
Layer 2 address
ooding and learning
process
l2-learning Enables a network device to:
• Learn unicast media access control (
MAC
)
addresses to avoid ooding the packets to all the
ports in a bridge domain.
• Create a source MAC entry in its source and
desnaon MAC tables for each MAC address
learned from packets received on ports that
belong to the bridge domain.
Layer 2 Control
Protocol process
l2cpd-service Enables features such as Layer 2 protocol tunneling
and nonstop bridging.
Link Aggregaon
Control Protocol
process
lacp The process:
• Provides a standardized means for exchanging
informaon between partner systems on a link.
• Allows the link aggregaon control instances to
reach agreement on the identy of the Link
Aggregaon Group (
LAG
) to which the link
belongs, and then to move the link to that LAG.
• Enables the transmission and recepon
processes for the link to funcon in an orderly
manner.
Link management
process
link-management Manages trac engineering links.
Local policy decision
funcon process
local-policy-decision-funcon Regulates the collecon of stascs related to
applicaons and applicaon groups and tracking of
informaon about dynamic subscribers and stac
interfaces.
17
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
Logical system
mulplexer
process
logical-system-mux
or
lrmuxd
Manages mulple instances of the roung protocols
process (rpd) on a machine running logical routers.
MAC validaon
process
mac-validaon Congures MAC address validaon that enables a
network device to validate if received packets
contain a trusted IP source and an Ethernet MAC
source address.
Management
Informaon Base II
process
mib-process Provides the device's
MIB
II agent.
Mobile IP process mobile-ip Congures Junos OS Mobile IP features.
NFS
mount requests
process
mountd-service (Some EX Series switches and MX Series routers
only) Completes internal NFS mount requests for
MS-PIC and MS-MPC.
MPLS Periodic
Traceroute process
mpls-traceroute Enables tracing of forwarding equivalence classes
(
FECs
) for
LDP
Layered Service Providers (
LSPs
).
Mulservice process mspd Congures mulservice edge routers.
Mulcast Snooping
process
mulcast-snooping (EX Series switches and MX Series routers only)
Makes Layer 3 informaon, such as the MAC
addresses of members of a mulcast group, known
to Layer 2 devices, such as
VLAN
switches.
DNS
server process named-service Enables a device to resolve hostnames into
addresses.
18
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
Bidireconal
Forwarding Detecon
(BFD) process
neighbor-liveness Displays the process that species the maximum
length of me that the device waits for its neighbor
to re-establish an LDP session.
Remote
NFS
server
process
nfsd-service Provides remote le access for applicaons that
need NFS-based transport.
Network me
process
ntp Provides the mechanisms to synchronize me and
coordinate me distribuon in a large, diverse
network.
Packet-triggered
dynamic subscribers
and policy control
(PTCP) process
packet-triggered-subscribers Enables the applicaon of policies to dynamic
subscribers that are controlled by a subscriber
terminaon device.
Peer selecon service
process
peer-selecon-service Enables peer selecon.
Periodic packet
management process
periodic-packet-services Processes a variety of me-sensive periodic tasks
so that other processes can more opmally direct
their resources.
Packet Forwarding
Engine process
pfed Gathers and reports Packet Forwarding Engine
stascs.
Packet gateway
service process
pgcp-service
or
pgcpd
Congures the Packet Gateway Control Protocol
(
PGCP
) that is required for the border gateway
funcon (
BGF
) feature.
Pragmac General
Mulcast process
pgm Enables a reliable transport layer for mulcast
applicaons.
19
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
PIC services logging
process
pic-services-logging
or
fsad (the le system access
daemon)
Enables PICs to send special logging informaon to
the Roung Engine for archiving on the hard drive.
Point-to-Point
Protocol (
PPP
)
process
ppp Enables transporng IP trac across point-to-point
links.
Universal edge PPP
process
ppp-service Enables transporng IP trac across universal edge
routers.
Point-to-Point
Protocol over
Ethernet process
pppoe Allows users to connect to a network of hosts over a
bridge or access concentrator.
Process health
monitor process
process-monitor
or
pmond
Extends the SNMP
RMON
alarm infrastructure to
provide predened monitoring for a selected set of
object instances (such as le system usage, CPU
usage, and memory usage) and dynamic object
instances (such as Junos OS processes).
NOTE: The process health monitor process is
enabled by default on the Roung Engines of MX
Series routers, even when no service interfaces are
congured. To disable this process, include the
disable statement at the [edit system processes
process-monitor] hierarchy level.
Redundancy interface
management process
redundancy-interface-process Serves as an acve or backup process of an
applicaon server and can be congured to process
trac for more than one logical applicaon server.
Remote operaons
process
remote-operaons Provides the
ping
and
traceroute
MIBs.
20
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
Resource cleanup
process
resource-cleanup Enables cleaning of resources by enes other than
the applicaon itself.
Roung process roung Directs forwarding on the basis of roung tables,
which maintain a record of the routes to various
network desnaons.
Trac sampling
control process
sampling Performs packet sampling based on parcular input
interfaces and various elds in the packet header.
Session Border
Control (
SBC
)
conguraon process
sbc-conguraon-process Congures the session border controller
funconality that enables delivery of voice, video,
and other mulmedia services with assured quality
and security.
SDK
service process sdk-service Runs on the Roung Engine and enables
communicaon between the SDK applicaon and
Junos OS. Although the SDK service process is
present on the router, it is turned o by default.
Secure Neighbor
Discovery (
SND
)
protocol process
secure-neighbor-discovery
or
send
(EX Series switches and MX Series routers only)
Provides support for protecng
NDP
messages.
Service Deployment
System (
SDX
) process
service-deployment Enables Junos OS to work with the Session and
Resource Control (
SRC
) soware.
Simple Network
Management
Protocol (SNMP)
process
snmp Enables the monitoring of network devices from a
central locaon, and provides the device’s SNMP
primary agent.
21
Table 3: Junos OS Roung-Specic Processes
(Connued)
Process Name Descripon
SONET
Automac
Protecon Switching
(APS) process
sonet-aps Monitors any SONET interface that parcipates in
APS
.
Stac subscribers
process
stac-subscribers Associates subscribers with stacally congured
interfaces, and provides dynamic service acvaon
and acvaon for these subscribers.
Tunnel OAM process tunnel-oamd Enables the Operaons, Administraon, and
Maintenance of Layer 2 tunneled networks.
Virtual Router
Redundancy Protocol
(
VRRP
) process
vrrp (EX Series switches and MX Series routers only)
Enables hosts on a LAN to make use of redundant
roung plaorms on that LAN without requiring
more than the stac conguraon of a single default
route on the hosts.
Watchdog mer
process
watchdog Enables the watchdog mer when Junos OS
encounters a problem.
Default Directories for Junos OS File Storage on the Network Device
IN THIS SECTION
Directories on the Logical System | 23
Generally, Junos OS les are stored in the following directories on the device:
• /altcong—When you back up the currently running and acve le system parons on the device to
standby parons using the request system snapshot command, the /cong directory is backed up to /
22
altcong. Normally, the /cong directory is on the CompactFlash card and /altcong is on the hard
disk.
• /altroot—When you back up the currently running and acve le system parons on the router to
standby parons using the request system snapshot command, the root le system (/) is backed up to /
altroot. Normally, the root directory is on the CompactFlash card and /altroot is on the hard drive.
• /cong—This directory is located on the primary boot device, that is, on the permanent storage from
which the device booted (generally the CompactFlash card (device wd0) or internal ash storage).
This directory contains the current operaonal router or switch conguraon and the last three
commied conguraons, in the les juniper.conf, juniper.conf.1, juniper.conf.2, and juniper.conf.3,
respecvely.
• /var—This directory is located either on the hard drive (device wd2) or internal ash storage. It
contains the following subdirectories:
• /home—Contains users’ home directories, which are created when you create user access
accounts. For users using SSH authencaon, their .ssh le, which contains their SSH key, is
placed in their home directory. When a user saves or loads a conguraon le, that le is loaded
from the user’s home directory unless the user species a full pathname.
• /db/cong—Contains up to 46 addional previous versions of commied conguraons, which
are stored in the les juniper.conf.4.gz through juniper.conf.49.gz.
• /log—Contains system log and tracing les.
• /tmp—Contains core les. The soware saves up to ve core les, numbered from 0 through 4.
File number 0 is the oldest core le and le number 4 is the newest core le. To preserve the
oldest core les, the soware overwrites the newest core le, number 4, with any subsequent
core le.
Each device ships with removable media (device wfd0) that contains a backup copy of Junos OS.
Directories on the Logical System
In addion to saving the conguraon of logical systems in the current juniper.conf le, each logical
system has an individual directory structure created in the /var/logical-systems/
logical-system-name
directory.
The /var/logical-systems/
logical-system-name
directory contains the following subdirectories:
• /cong—Contains the current operaonal conguraon specic to the logical system.
• /log—Contains system log and tracing les specic to the logical system.
23
To maintain backward compability for the log les with previous versions of Junos OS, a symbolic
link (symlink) from the /var/logs/
logical-system-name
directory to the /var/logical-systems/
logical-
system-name
directory is created when a logical system is congured.
• /tmp—Contains temporary les specic to the logical system.
This le system for each logical system enables logical system users to view trace logs and modify logical
system les. Logical system administrators have full access to view and modify all les specic to the
logical system.
Logical system users and administrators can save and load conguraon les at the logical-system
hierarchy level using the save and load conguraon mode commands. In addion, they can also issue the
show log, monitor, and file operaonal mode commands at the logical-system hierarchy level.
RELATED DOCUMENTATION
Format for Specifying Filenames and URLs in Junos OS CLI Commands | 66
Junos OS Support for IPv4, IPv6, and MPLS Roung Protocols
Junos OS implements full IP roung funconality, providing support for IP version 4 and IP version 6
(IPv4 and IPv6, respecvely). The roung protocols are fully interoperable with exisng IP roung
protocols, and they have been developed to provide the scale and control necessary for the Internet
core.
Junos OS supports the following unicast roung protocols:
• BGP—Border Gateway Protocol version 4 is an
EGP
that guarantees loop-free exchange of roung
informaon between roung domains (also called autonomous systems). BGP, in conjuncon with
Junos OS roung policies, provides a system of administrave checks and balances that can be used
to implement peering and transit agreements.
• ICMP—Internet Control Message Protocol router discovery enables hosts to discover the addresses
of operaonal routers on the subnet.
• IS-IS—Intermediate System to Intermediate System is a link-state
IGP
for IP networks that uses the
SPF
algorithm, which also is referred to as the
Dijkstra
algorithm, to determine routes. The Junos OS
supports a new and complete implementaon of the protocol, addressing issues of scale,
convergence, and resilience.
24
• OSPF—Open Shortest Path First is an IGP that was developed for IP networks by the Internet
Engineering Task Force (
IETF
). OSPF is a link-state protocol that makes roung decisions based on
the
SPF
algorithm.
OSPF Version 2 supports IPv4. OSPF Version 3 supports IPv6. The fundamental mechanisms of
OSPF such as ooding, designated router (
DR
) elecon, area-based topologies, and the
SPF
calculaons remain unchanged in OSPF Version 3. Some dierences exist either because of changes
in protocol semancs between IPv4 and IPv6, or because of the need to handle the increased
address size of IPv6.
• RIP—Roung Informaon Protocol version 2 is a distance-vector IGP for IP networks based on the
Bellman-Ford
algorithm. RIP dynamically routes packets between a subscriber and a service provider
without the subscriber having to congure BGP or to parcipate in the service provider’s
IGP
discovery process.
Junos OS also provides the following roung and Mulprotocol Label Switching (
MPLS
) applicaons
protocols:
•
Unicast
roung protocols:
• BGP
• ICMP
• IS-IS
• OSPF Version 2
• RIP Version 2
• Mulcast roung protocols:
• DVMRP—Distance Vector Mulcast Roung Protocol is a
dense-mode
(
ood-and-prune
)
mulcast roung protocol.
• IGMP—Internet Group Management Protocol versions 1 and 2 are used to manage membership in
mulcast groups.
• MSDP—Mulcast Source Discovery Protocol enables mulple Protocol Independent Mulcast
(
PIM
)
sparse mode
domains to be joined. A rendezvous point (
RP
) in a PIM sparse mode domain
has a peer relaonship with an RP in another domain, enabling it to discover mulcast sources
from other domains.
• PIM sparse mode and dense mode—Protocol-Independent Mulcast is a mulcast roung
protocol. PIM sparse mode routes to mulcast groups that might span wide-area and interdomain
internets. PIM dense mode is a ood-and-prune protocol.
25
• SAP/SDP—Session Announcement Protocol and Session Descripon Protocol handle conference
session announcements.
• MPLS applicaons protocols:
• LDP—The Label Distribuon Protocol provides a mechanism for distribung labels in non-trac-
engineered applicaons. LDP enables routers to establish label-switched paths (LSPs) through a
network by mapping network layer roung informaon directly to data-link layer switched paths.
LSPs created by LDP can also traverse LSPs created by the Resource Reservaon Protocol (
RSVP
).
• MPLS—Mulprotocol Label Switching, formerly known as tag switching, enables you to manually
or dynamically congure LSPs through a network. It lets you direct trac through parcular paths
rather than rely on the IGP least-cost algorithm to choose a path.
• RSVP—The Resource Reservaon Protocol version 1 provides a mechanism for engineering
network trac paerns that is independent of the shortest path decided upon by a roung
protocol. RSVP itself is not a roung protocol; it operates with current and future unicast and
mulcast roung protocols. The primary purpose of RSVP is to support dynamic signaling for
MPLS LSPs.
RELATED DOCUMENTATION
Junos OS Overview
Junos OS Roung and Forwarding Tables
A major funcon of the Junos OS roung protocol process is to maintain the Roung Engine’s roung
tables and use these tables to determine the acve routes to network desnaons. The roung protocol
process then installs these routes into the Roung Engine’s forwarding table. The Junos OS kernel then
copies this forwarding table to the Packet Forwarding Engine.
The roung protocol process maintains mulple roung tables. By default, it maintains the following
three roung tables. You can congure addional roung tables to suit your requirements.
•
Unicast
roung table—Stores roung informaon for all unicast roung protocols running on the
router. BGP, IS-IS, OSPF, and RIP all store their roung informaon in this roung table. You can
congure addional routes, such as stac routes, to be included in this roung table. BGP, IS-IS,
OSPF, and RIP use the routes in this roung table when adversing roung informaon to their
neighbors.
26
• Mulcast roung table (cache)—Stores roung informaon for all the running mulcast protocols.
DVMRP
and
PIM
both store their roung informaon in this roung table, and you can congure
addional routes to be included in this roung table.
• MPLS roung table—Stores
MPLS
path and label informaon.
With each roung table, the roung protocol process uses the collected roung informaon to
determine acve routes to network desnaons.
For
unicast
routes, the roung protocol process determines acve routes by choosing the most
preferred route, which is the route with the lowest preference value. By default, the route’s preference
value is simply a funcon of how the roung protocol process learned about the route. You can modify
the default preference value using roung policy and with soware conguraon parameters.
For
mulcast
trac, the roung protocol process determines acve routes based on trac ow and
other parameters specied by the mulcast roung protocol algorithms. The roung protocol process
then installs one or more acve routes to each network desnaon into the Roung Engine’s forwarding
table.
RELATED DOCUMENTATION
Roung Policy Overview | 27
Roung Policy Overview
By default, all roung protocols place their routes into the
roung table
. When adversing routes, the
roung protocols by default adverse only a limited set of routes from the roung table. Specically,
each roung protocol exports only the acve routes that were learned by that protocol. In addion, the
interior gateway protocols (IS-IS, OSPF, and RIP) export the direct (interface) routes for the interfaces on
which they are explicitly congured.
You can control the routes that a protocol places into each table and the routes from that table that the
protocol adverses. You do this by dening one or more roung policies and then applying them to the
specic roung protocol.
Roung policies applied when the roung protocol places routes into the roung table are referred to as
import policies
because the routes are being imported into the roung table. Policies applied when the
roung protocol is adversing routes that are in the roung table are referred to as
export policies
because the routes are being exported from the roung table. In other words, the terms
import
and
export
are used with respect to the roung table.
27
A roung policy enables you to control (lter) which routes a roung protocol imports into the roung
table and which routes a roung protocol exports from the roung table. A roung policy also enables
you to set the informaon associated with a route as it is being imported into or exported from the
roung table. Filtering imported routes enables you to control the routes used to determine acve
routes. Filtering routes being exported from the roung table enables you to control the routes that a
protocol adverses to its neighbors.
A dened roung policy species the condions to use to match a route and the acon to perform on
the route when a match occurs. For example, when a roung table imports roung informaon from a
roung protocol, a roung policy might modify the route’s preference, mark the route with a color to
idenfy it and allow it to be manipulated later, or prevent the route from even being installed in a
roung table. When a roung table exports routes into a roung protocol, a policy might assign metric
values, modify the BGP community informaon, tag the route with addional informaon, or prevent
the route from being exported altogether. You also can dene policies for redistribung the routes
learned from one protocol into another protocol.
RELATED DOCUMENTATION
Junos OS Roung and Forwarding Tables | 26
Junos OS Support for IPv4, IPv6, and MPLS Roung Protocols | 24
Junos OS Support for VPNs
Junos OS supports several types of virtual private networks (
VPNs
), including:
• Layer 2 VPNs link a set of sites that share roung informaon, and whose connecvity is controlled
by a collecon of policies. A Layer 2 VPN is not aware of routes within your network. It simply
provides private links between sites over the service provider’s exisng public Internet
backbone
.
• Layer 3 VPNs are the same as a Layer 2 VPN, but it is aware of routes within your network, requiring
more conguraon on the part of the service provider than a Layer 2 VPN. The sites that make up a
Layer 3 VPN are connected over a service provider’s exisng public Internet backbone.
• An Ethernet VPN (EVPN) enables you to connect dispersed customer sites using a Layer 2 virtual
bridge. As with other types of VPNs, an EVPN consists of customer edge (CE) devices (host, router,
or switch) connected to provider edge (PE) routers. The PE routers can include an MPLS edge switch
(MES) that acts at the edge of the MPLS infrastructure. Either an MX Series 5G Universal Roung
Plaorm or a standalone switch can be congured to act as an MES. You can deploy mulple EVPNs
within a service provider network, each providing network connecvity to a customer while ensuring
that the trac sharing on that network remains private.
28
• Interprovider VPNs supply connecvity between two VPNs in separate autonomous systems (
AS
s).
This funconality can be used by a VPN user with connecons to several Internet service providers
(
ISP
s), or dierent connecons to the same ISP in various geographic regions.
• Carrier-of-carrier VPNs allow a VPN service provider to supply VPN service to a someone who is also
a service provider. The laer service provider supplies Internet or VPN service to an end user.
RELATED DOCUMENTATION
Junos OS Overview | 3
Conguring FIB Localizaon
IN THIS SECTION
FIB Localizaon Overview | 29
Example: Conguring Packet Forwarding Engine FIB Localizaon | 30
FIB Localizaon Overview
On Juniper Networks devices, the forwarding table on the Packet Forwarding Engine, also referred to as
forwarding informaon base (FIB), maintains the complete set of acve IPv4 (inet) and IPv6 (inet6)
routes. In Junos OS Release 11.4 and later, you can congure FIB localizaon for a Packet Forwarding
Engine. FIB-localizaon characterizes Packet Forwarding Engines in a router as either “FIB-remote” or
“FIB-local”.
FIB-local Packet Forwarding Engines install all routes from the default inet and inet6 route tables into
the Packet Forwarding Engine forwarding hardware. FIB-remote Packet Forwarding Engines do not
install all the routes for the inet and inet6 roung tables. However, they do maintain local and mulcast
routes.
FIB-remote Packet Forwarding Engines create a default (0/0) route in the Packet Forwarding Engine
forwarding hardware for the inet and inet6 table. The default route references a next-hop or a unilist of
next-hops that idenfy the FIB-local Packet Forwarding Engines that can perform full IP table lookups
for received packets.
FIB-remote Packet Forwarding Engines forward received packets to the set of FIB-local Packet
Forwarding Engines. The FIB-local Packet Forwarding Engines then perform full IP longest-match lookup
29
on the desnaon address and forward the packet appropriately. The packet might be forwarded out of
an egress interface on the same FIB-local Packet Forwarding Engine that performed the lookup or an
egress interface on a dierent FIB-local or FIB-remote Packet Forwarding Engine. The packet might also
be forwarded out of an FPC where FIB localizaon is not congured. The packet might also be received
locally at the Roung Engine.
When FIB localizaon is congured on a router with some Flexible PIC Concentrators (FPCs) being FIB-
remote and some others being FIB-local, packets arriving on the interface of the FIB-remote FPC are
forwarded to one of the FIB-local FPCs for route lookup and forwarding.
The advantage of conguring FIB localizaon is that it enables upgrading the hardware forwarding table
capacity of FIB-local Packet Forwarding Engines while not requiring upgrades to the FIB-remote Packet
Forwarding Engines. In a typical network deployment, FIB-local Packet Forwarding Engines are core-
facing, while FIB-remote Packet Forwarding Engines are edge-facing. The FIB-remote Packet Forwarding
Engines also load-balance trac over the available set of FIB-local Packet Forwarding Engines.
FIB localizaon is currently supported on specic Junos OS devices, including the T320, T640, T1600,
and MX Series routers. To see if your hardware supports FIB localizaon, see the Juniper Networks
Feature Explorer.
NOTE: On MX Series routers, you can congure mulservices Dense Port Concentrators (DPCs)
as FIB-remote. However, only Modular Port Concentrators (MPCs) can be congured as FIB-
local. FIB-localizaon is supported only for redundant link services intelligent queuing interfaces
that carry Mullink Point-to-Point Protocol (MLPPP) trac.
Example: Conguring Packet Forwarding Engine FIB Localizaon
IN THIS SECTION
Requirements | 31
Overview | 31
Conguraon | 31
Vericaon | 34
This example shows how to congure Packet Forwarding Engine FIB localizaon.
30
Requirements
Before you begin:
1. Congure device interfaces and loopback interface addresses.
2. Congure stac routes.
3. Congure OSPF and OSPFv3 and make sure that OSPF adjacencies and OSPF routes to loopback
addresses are established.
This example uses the following hardware and soware components:
• A T320, T640,T1600, or MX Series router.
• Junos OS Release 11.4 or later running on the router for T-Series routers. Junos OS Release 12.3 or
later running on the router for MX Series routers.
Overview
In this example, you congure the chassis for IPv4 and IPv6 routes and FIB localizaon on Router R0
and then congure the edge-facing Packet Forwarding Engines on FPC0 as fib-remote and the core-facing
Packet Forwarding Engines on FPC1 and FPC2 as fib-local. You then congure a roung policy named
fib-policy with the no-route-localize opon to ensure that all routes from a specied route lter are
installed on the FIB-remote FPC.
Conguraon
IN THIS SECTION
Procedure | 31
Procedure
CLI Quick Conguraon
To quickly congure this example, copy the following commands, paste them into a text le, remove any
line breaks, change any details necessary to match your network conguraon, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
31
NOTE: Conguring FIB local results in a reboot of the related line card to acvate the changes.
R0
set chassis fpc 0 route-localization fib-remote
set chassis fpc 1 route-localization fib-local
set chassis fpc 2 route-localization fib-local
set chassis route-localization inet
set chassis route-localization inet6
set policy-options policy-statement fib-policy term a from route-filter 10.4.4.4/32 exact
set policy-options policy-statement fib-policy term a then no-route-localize
set policy-options policy-statement fib-policy term b from route-filter fec0:4444::4/128 exact
set policy-options policy-statement fib-policy term b then no-route-localize
set policy-options policy-statement fib-policy then accept
set routing-options forwarding-table export fib-policy
Step-by-Step Procedure
The following example requires you to navigate various levels in the conguraon hierarchy. For
informaon about navigang the Junos OS CLI, see the Junos OS CLI User Guide.
To congure Packet Forwarding Engine FIB localizaon:
1. Congure route localizaon or FIB localizaon for IPv4 and IPv6 trac.
[edit chassis]
user@R0# set route-localization inet
user@R0# set route-localization inet6
2. Congure the Packet Forwarding Engine of an FPC as either fib-local or fib-remote.
[edit chassis]
user@R0# set fpc 0 route-localization fib-remote
user@R0# set fpc 1 route-localization fib-local
user@R0# set fpc 2 route-localization fib-local
32
3. Congure the roung policy by including the no-route-localize statement to enable the forwarding
table policy to mark route prexes such that the routes are installed into forwarding hardware on the
FIB-remote Packet Forwarding Engines.
[edit policy-options]
user@R0# set policy-statement fib-policy term a from route-filter 10.4.4.4/32 exact
user@R0# set policy-statement fib-policy term a then no-route-localize
user@R0# set policy-statement fib-policy term b from route-filter fec0:4444::4/128 exact
user@R0# set policy-statement fib-policy term b then no-route-localize
user@R0# set policy-statement fib-policy then accept
4. Enable the roung policy in the forwarding table by conguring the forwarding table with the fib-
policy statement.
[edit routing-options]
user@R0# set forwarding-table export fib-policy
NOTE: At least, one Packet Forwarding Engine must be congured as fib-local for the commit
operaon to be successful. If you do not congure fib-local for the Packet Forwarding Engine,
the CLI displays an appropriate error message and the commit fails.
Results
From conguraon mode, conrm your conguraon by entering the show chassis and show policy-options
commands. If the output does not display the intended conguraon, repeat the instrucons in this
example to correct the conguraon.
user@R0# show chassis
fpc 0 {
route-localization fib-remote;
}
fpc 1 {
route-localization fib-local;
}
fpc 2 {
route-localization fib-local;
}
route-localization {
33
inet;
inet6;
}
user@R0# show policy-options
policy-statement fib-policy {
term a {
from {
route-filter 10.4.4.4/32 exact;
}
then no-route-localize;
}
term b {
from {
route-filter fec0:4444::4/128 exact;
}
then no-route-localize;
}
then accept;
}
}
Vericaon
IN THIS SECTION
Verifying Policy Conguraon | 35
Verifying FIB-Localizaon Conguraon | 35
Verifying Routes Aer the Policy Is Applied | 36
Conrm that the conguraon is working properly.
34
Verifying Policy Conguraon
Purpose
Verify that the congured policy exists.
Acon
Issue the show policy fib-policy command to check that the congured policy fib-policy exists.
user@R0> show policy fib-policy
Policy fib-policy:
Term a:
from
route filter:
10.4.4.4/32 exact
then no-route-localize
Term b:
from
route filter:
fec0:4444::4/128 exact
then no-route-localize
Term unnamed:
then accept
Verifying FIB-Localizaon Conguraon
Purpose
Verify FIB-localizaon conguraon details by using the show route localization and show route localization
detail commands.
Acon
user@R0> show route localization
FIB localization ready FPCs (and FIB-local Forwarding Engine addresses)
FIB-local: FPC2(4,5)
35
FIB-remote: FPC0, FPC1
Normal: FPC3, FPC4, FPC5, FPC6, FPC7
user@R0> show route localization detail
FIB localization ready FPCs (and FIB-local Forwarding Engine addresses)
FIB-local: FPC2(4,5)
FIB-remote: FPC0, FPC1
Normal: FPC3, FPC4, FPC5, FPC6, FPC7
FIB localization configuration
Protocols: inet, inet6
FIB-local: FPC2
FIB-remote: FPC0, FPC1
Forwarding Engine addresses
FPC0: 1
FPC1: 2
FPC2: 4, 5
FPC3: 6
FPC4: 8
FPC5: 11
FPC6: 13
FPC7: 15
Verifying Routes Aer the Policy Is Applied
Purpose
Verify that routes with the no-route-localize policy opon are installed on the fib-remote FPC.
Acon
user@R0> show route 10.4.4.4/32 extensive
inet.0: 30 destinations, 30 routes (29 active, 0 holddown, 1 hidden)
10.4.4.4/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.4.4.4/32 -> {10.130.0.2 Flags no-localize}
^^^^^^^^^^^^^^^^^
36
*Static Preference: 5
Next hop type: Router, Next hop index: 629
Next-hop reference count: 3
Next hop: 10.130.0.2 via ge-1/0/4.0, selected
State: <Active Int="">
Age: 10:33
Task: RT
Announcement bits (1): 0-KRT
AS path: I</Active
>
RELATED DOCUMENTATION
b-local
b-remote
no-route-localize
route-localizaon
37
CHAPTER 2
Junos OS Security Overview
IN THIS CHAPTER
Junos OS Features for Device Security | 38
Junos OS Default Sengs for Device Security | 43
Junos OS Features for Device Security
IN THIS SECTION
Methods of Remote Access for Device Management | 39
Junos OS Supported Protocols and Methods for User Authencaon | 39
Junos OS Plain-Text Password Requirements | 40
Junos OS Support for Roung Protocol Security Features and IPsec | 41
Junos OS Support for Firewall Filters | 41
Junos OS Support Distributed Denial-of-Service Protecon | 42
Junos OS Auding Support for Security | 42
Device security consists of three major elements: Physical security of the hardware, operang system
security, and security that can be aected through conguraon.
Physical security involves restricng access to the device. Exploits that can easily be prevented from
remote locaons are extremely dicult or impossible to prevent if an aacker can gain access to the
device’s management port or console. The inherent security of Junos OS also plays an important role in
router security. Junos OS is extremely stable and robust, and provides features to protect against
aacks, allowing you to congure the device to minimize vulnerabilies.
The following are Junos OS features available to improve device security:
38
Methods of Remote Access for Device Management
When you rst install Junos OS, all remote access to the device is disabled, thereby ensuring that
remote access is possible only if deliberately enabled by an authorized user. You can establish remote
communicaon with a device in one of the following ways:
• Out-of-band management: Enables connecon to the device through an interface dedicated to
device management. Juniper Networks devices support out-of-band management with a dedicated
management Ethernet interface, as well as EIA-232 console and auxiliary ports. On all devices other
than the TX Matrix Plus, T1600, T1600 or T4000 devices connected to a TX Matrix Plus device in a
roung matrix, and PTX Series Packet Transport Routers, the management interface is fxp0. On a TX
Matrix Plus, T1600, T1600 or T4000 devices in a roung matrix, and PTX Series Packet Transport
Routers, the management Ethernet Interface is labeled em0. The management Ethernet interface
connects directly to the Roung Engine. No transit trac is allowed through this interface, providing
complete separaon of customer and management trac and ensuring that congeson or failures in
the transit network do not aect the management of the device.
• Inband management: Enables connecon to the devices using the same interfaces through which
customer trac ows. Although this approach is simple and requires no dedicated management
resources, it has two disadvantages:
• Management ows and transit trac ows are mixed together. Any aack trac that is mixed
with the normal trac can aect the communicaon with the device.
• The links between device components might not be totally trustworthy, leading to the possibility
of wiretapping and replay aacks.
For management access to the device, the standard ways to communicate with the device from a remote
console are with Telnet and SSH. SSH provides secure encrypted communicaons and is therefore
useful for inband device management. Telnet provides unencrypted, and therefore less secure, access to
the device.
Junos OS Supported Protocols and Methods for User Authencaon
On a device, you can create local user login accounts to control who can log in to the device and the
access privileges they have. A password, either an SSH key or a Message Digest 5 (MD5) password, is
associated with each login account. To dene access privileges, you create login classes into which you
group users with similar jobs or job funcons. You use these classes to explicitly dene what commands
their users are and are not allowed to issue while logged in to the device.
The management of mulple devices by many dierent personnel can create a user account
management problem. One soluon is to use a central authencaon service to simplify account
management, creang and deleng user accounts only on a single, central server. A central
authencaon system also simplies the use of one-me password systems such as SecureID, which
39
oer protecon against password sning and password replay aacks (aacks in which someone uses a
captured password to pose as a device administrator).
Junos OS supports two protocols for central authencaon of users on mulple devices:
• Terminal Access Controller Access Control System Plus (TACACS+).
• Remote Authencaon Dial-In User Service (RADIUS), a mulvendor IETF standard whose features
are more widely accepted than those of TACACS+ or other proprietary systems. All one-me-
password system vendors support RADIUS.
Junos OS also supports the following authencaon methods:
• Internet Protocol Security (IPsec). IPsec architecture provides a security suite for the IPv4 and IPv6
network layers. The suite provides such funconality as authencaon of origin, data integrity,
condenality, replay protecon, and nonrepudiaon of source. In addion to IPsec, Junos OS
supports the Internet Key Exchange (IKE), which denes mechanisms for key generaon and
exchange, and manages security associaons (SAs).
• MD5 authencaon of MSDP peering sessions. This authencaon provides protecon against
spoofed packets being introduced into a peering session.
• SNMPv3 authencaon and encrypon. SNMPv3 uses the user-based security model (USM) for
message security and the view-based access control model (VACM) for access control. USM species
authencaon and encrypon. VACM species access-control rules.
Junos OS Plain-Text Password Requirements
Junos OS has special requirements when you create plain-text passwords on a device. The default
requirements for plain-text passwords are as follows:
• The password must be between 6 and 128 characters long.
• You can include uppercase leers, lowercase leers, numbers, punctuaon marks, and any of the
following special characters:
! @ # $ % ^ & * , + = < > : ;
Control characters are not recommended.
• The password must contain at least one change of case or character class.
You can change the requirements for plain-text passwords.
You can include the plain-text-password statement at the following hierarchy levels:
•
[edit system diag-port-authentication]
• [edit system pic-console-authentication]
40
• [edit system root-authentication]
• [edit system login user
username
authentication]
Junos OS Support for Roung Protocol Security Features and IPsec
The main task of a device is to forward user trac toward its intended desnaon based on the
informaon in the device’s roung and forwarding tables. You can congure roung policies that dene
the ows of roung informaon through the network, controlling which routes the roung protocols
place in the roung tables and which routes they adverse from the tables. You can also use roung
policies to change specic route characteriscs, change the BGP route ap-damping values, perform
per-packet load balancing, and enable
class of service
(CoS).
Aackers can send forged protocol packets to a device with the intent of changing or corrupng the
contents of its roung table or other databases, which can degrade the funconality of the device. To
prevent such aacks, you must ensure that devices form roung protocol peering or neighboring
relaonships with trusted peers. One way to do this is by authencang roung protocol messages. The
Junos OS BGP, IS-IS, OSPF, RIP, and RSVP protocols all support HMAC-MD5 authencaon, which uses
a secret key combined with the data being protected to compute a hash. When the protocols send
messages, the computed hash is transmied with the data. The receiver uses the matching key to
validate the message hash.
Junos OS supports the IPsec security suite for the IPv4 and IPv6 network layers. The suite provides such
funconality as authencaon of origin, data integrity, condenality, replay protecon, and
nonrepudiaon of source. Junos OS also supports IKE, which denes mechanisms for key generaon
and exchange, and manages SAs.
Junos OS Support for Firewall Filters
Firewall lters allow you to control packets transing the device to a network desnaon and packets
desned for and sent by the device. You can congure rewall lters to control which data packets are
accepted on and transmied from the physical interfaces, and which local packets are transmied from
the physical interfaces and the Roung Engine. Firewall lters provide a means of protecng your device
from excessive trac. Firewall lters that control local packets can also protect your device from
external aggressions, such as DoS aacks.
To protect the Roung Engine, you can congure a
rewall lter
only on the device’s loopback interface.
Adding or modifying lters for each interface on the device is not necessary. You can design rewall
lters to protect against ICMP and Transmission Control Protocol (TCP) connecon request (SYN) oods
and to rate-limit trac being sent to the Roung Engine.
41
Junos OS Support Distributed Denial-of-Service Protecon
A denial-of-service aack is any aempt to deny valid users access to network or server resources by
using up all the resources of the network element or server. Distributed denial-of-service aacks involve
an aack from mulple sources, enabling a much greater amount of trac to aack the network. The
aacks typically use network protocol control packets to trigger a large number of excepons to the
device’s control plane. This results in an excessive processing load that disrupts normal network
operaons.
Junos OS DDoS protecon enables the device to connue funconing while under an aack. It
idenes and suppresses malicious control packets while enabling legimate control trac to be
processed. A single point of DDoS protecon management enables network administrators to customize
proles for their network control trac. Protecon and monitoring persists across graceful Roung
Engine switchover (GRES) and unied in-service-soware-upgrade (ISSU) switchovers. Protecon is not
diminished as the number of subscribers increases.
To protect against DDoS aacks, you can congure policers for host-bound excepon trac. The
policers specify rate limits for individual types of protocol control packets or for all control packet types
for a protocol. You can monitor policer acons for packet types and protocol groups at the level of the
device, Roung Engine, and line cards. You can also control logging of policer events.
Flow detecon is an enhancement to DDoS protecon that supplements the DDoS policer hierarchies
by using a limited amount of hardware resources to monitor the arrival rate of host-bound ows of
control trac. Flow detecon is much more scalable than a soluon based on lter policers. Filter
policers track all ows, which consumes a considerable amount of resources. In contrast, ow detecon
only tracks ows it idenes as suspicious, using far fewer resources to do so.
The ow detecon applicaon has two interrelated components, detecon and tracking. Detecon is
the process where ows suspected of being improper are idened and subsequently controlled.
Tracking is the process where ows are tracked to determine whether they are truly hosle and when
these ows recover to within acceptable limits.
Junos OS Auding Support for Security
Junos OS logs signicant events that occur on the device and within the network. Although logging itself
does not increase security, you can use the system logs to monitor the eecveness of your security
policies and device conguraons. You can also use the logs when reacng to a connued and
deliberate aack as a means of idenfying the source address, device, or port of the aacker’s trac.
You can congure the logging of dierent levels of events, from only crical events to all events,
including informaonal events. You can then inspect the contents of the system log les either in real
me or later.
Debugging and troubleshoong are much easier when the mestamps in the system log les of all
devices are synchronized, because events that span the network might be correlated with synchronous
42
entries in mulple logs. Junos OS supports the Network Time Protocol (NTP), which you can enable on
the device to synchronize the system clocks of devices and other networking equipment. By default,
NTP operates in an unauthencated mode. You can congure various types of authencaon, including
an HMAC-MD5 scheme.
RELATED DOCUMENTATION
Overview of IPsec
Junos OS System Log Overview
Junos OS Default Sengs for Device Security
Junos OS protects against common network device security weaknesses with the following default
sengs:
• Junos OS does not forward directed broadcast messages. Directed broadcast services send ping
requests from a spoofed source address to a broadcast address and can be used to aack other
Internet users. For example, if broadcast ping messages were allowed on the 200.0.0.0/24 network, a
single ping request could result in up to 254 responses to the supposed source of the ping. The
source would actually become the vicm of a denial-of-service (DoS) aack.
• Generally, by default, only console access to the device is enabled. Remote management access to
the device and all management access protocols, including Telnet, FTP, and SSH (Secure Shell), are
disabled by default, unless the device setup specically includes a factory-installed DHCP
conguraon.
• Junos OS does not support the SNMP set capability for eding conguraon data. Although the
soware supports the SNMP set capability for monitoring and troubleshoong the network, this
support exposes no known security issues. (You can congure the soware to disable this SNMP set
capability.)
• Junos OS ignores maran (intenonally non-routable) IP addresses that contain the following
prexes: 0.0.0.0/8, 127.0.0.0/8, 128.0.0.0/16, 191.255.0.0/16, 192.0.0.0/24, 223.255.55.0/24, and
240.0.0.0/4. Maran addresses are reserved host or network addresses about which all roung
informaon should be ignored.
43
CHAPTER 3
Junos OS Conguraon Overview
IN THIS CHAPTER
Junos OS Conguraon Basics | 44
Methods for Conguring Junos OS | 45
Junos OS Conguraon from External Devices | 48
The Commit Model for Conguraons | 48
Conguraon Groups Overview | 50
Junos OS Conguraon Basics
Usually, your Juniper Networks device comes with Junos OS installed on it, unless you specically order
it without the operang system. When Junos OS is pre-installed, you simply power on the device and all
soware starts automacally. You just need to congure the device so it will be ready to parcipate in
the network.
To congure the Junos OS, you must specify a hierarchy of conguraon statements which dene the
preferred soware properes. You can congure all properes of the Junos OS, including interfaces,
general roung informaon, roung protocols, and user access, as well as some system hardware
properes. Aer you have created a candidate conguraon, you commit the conguraon to be
evaluated and acvated by Junos OS.
RELATED DOCUMENTATION
Junos OS Conguraon from External Devices | 48
Methods for Conguring Junos OS | 45
Inial Router or Switch Conguraon Using Junos OS | 52
44
Methods for Conguring Junos OS
IN THIS SECTION
Junos OS Command-Line Interface | 46
ASCII File | 46
J-Web Package | 46
Junos XML Management Protocol Soware | 47
NETCONF XML Management Protocol Soware | 47
Conguraon Commit Scripts | 47
Depending on specic device support, you can use the methods shown in Table 4 on page 45 to
congure Junos OS. For more informaon, see the Juniper Networks Feature Explorer.
Table 4: Methods for
Conguring Junos OS
Method Descripon
Command-line interface
(CLI)
Create the conguraon for the device using the CLI. You can enter commands from a
single command line, and scroll through recently executed commands.
ASCII le Load an ASCII le containing a conguraon that you created earlier, either on this
system or on another system. You can then acvate and run the conguraon le, or
you can edit it using the CLI and then acvate it.
J-Web graphical user
interface (GUI)
Use the J-Web GUI to congure the device. J-Web enables you to monitor, congure,
troubleshoot, and manage the router on a client by means of a Web browser. The J-
Web GUI is supported on only certain Juniper Networks devices. For more
informaon, see the Juniper Networks Feature Explorer.
Junos XML
management protocol
(API)
Client applicaons use the Junos XML management protocol to monitor and congure
Juniper Networks devices. The Junos XML management protocol is customized for
Junos OS, and operaons in the API are equivalent to those in the CLI.
45
Table 4: Methods for Conguring Junos OS
(Connued)
Method Descripon
NETCONF applicaon
programming interface
(API)
Client applicaons use the NETCONF XML management protocol to monitor and
congure supported devices. The NETCONF XML management protocol includes
features that accommodate the conguraon data models of mulple vendors.
Conguraon commit
scripts
Create scripts that run at commit me to enforce custom conguraon rules. Commit
scripts are wrien in Python, Stylesheet Language Alternave syntaX (SLAX), or
Extensible Stylesheet Language Transformaons (XSLT).
The following
secons describe the methods you can use to congure Junos OS:
Junos OS Command-Line Interface
The Junos OS CLI is a straighorward terminal-based command interface. You use Emacs-style keyboard
sequences to move around on a command line and scroll through a buer that contains recently
executed commands. You type commands on a single line, and the commands are executed when you
press the Enter key. The CLI also provides command help and command compleon.
ASCII File
You can load an ASCII le containing a conguraon that you created earlier, either on this system or
another system. You can then acvate and run the conguraon le as is, or you can edit it using the CLI
and then acvate it.
J-Web Package
As an alternave to entering CLI commands, Junos OS supports the J-Web GUI. The J-Web user
interface enables you to monitor, congure, troubleshoot, and manage the router on a client by means
of a Web browser with Hypertext Transfer Protocol (HTTP) or HTTP over Secure Sockets Layer (HTTPS)
enabled.
The J-Web user interface is an oponal, licensed soware package (jweb package) on M Series and
TSeries routers. The jweb package is not included in jinstall and jbundle soware bundles. It must be
installed separately. To install the package on M Series and T Series routers, follow the procedure
described in the Soware Installaon and Upgrade Guide.
J-Web supports weak (56-bit) encrypon by default. This enables non-US customers to install J-Web
and use HTTPS connecons for J-Web access. US customers can also install the jcrypto strong
encrypon package. This package automacally overrides the weak encrypon.
46
NOTE: Because the J-Web package is bundled separately from other packages, it is possible to
have a version mismatch between J-Web and other Junos OS packages you have installed.
To check for a version mismatch, use the show system alarms CLI command. If the version number
does not match exactly, a system alarm appears.
Junos XML Management Protocol Soware
The Junos XML Management Protocol is an XML-based protocol that client applicaons use to monitor
and congure Juniper Networks devices. It uses an XML-based data encoding for the conguraon data
and remote procedure calls. This API is customized for Junos OS, and operaons in the API are
equivalent to CLI commands.
NETCONF XML Management Protocol Soware
The NETCONF XML management protocol is an XML-based protocol that client applicaons use to
monitor and congure network devices. It uses an XML-based data encoding for the conguraon data
and remote procedure calls. NETCONF includes features that accommodate the conguraon data
models of mulple vendors. Juniper Networks provides a set of Perl modules that enable Perl client
applicaons to communicate with the NETCONF server on Junos devices. The Perl modules enable you
to develop custom applicaons for conguring and monitoring Junos devices.
Conguraon Commit Scripts
You can create and use scripts that run at commit me to enforce custom conguraon rules. If a
conguraon breaks the custom rules, the script can generate acons that the Junos OS performs.
These acons include:
• Generang custom error messages
• Generang custom warning messages
• Generang custom system log messages
• Making changes to the conguraon
Conguraon commit scripts also enable you to create macros, which expand simplied custom aliases
for frequently used conguraon statements into standard Junos OS conguraon statements. Commit
scripts are wrien in Python, Stylesheet Language Alternave syntaX (SLAX), or Extensible Stylesheet
Language Transformaons (XSLT).
47
RELATED DOCUMENTATION
CLI Explorer
CLI User Guide
Junos OS Automaon Scripng User Guide
Junos OS Conguraon from External Devices | 48
NETCONF XML Management Protocol Developer Guide
Soware Installaon and Upgrade Guide
Junos OS Conguraon from External Devices
You can congure Junos OS network device from a
system console
connected to the console port or by
using
Telnet
to access the device remotely. External management hardware can be connected to the
Roung Engine and the Junos OS through these ports:
• Console port
• Auxiliary port
• Ethernet management port
NOTE: See hardware guide for your parcular Junos OS device for instrucons about how to
connect external hardware to the console, auxiliary, and/or Ethernet management ports.
Capabilies and features can vary depending on device model.
RELATED DOCUMENTATION
Methods for Conguring Junos OS | 45
Conguring Junos OS to Set Console and Auxiliary Port Properes | 72
The Commit Model for Conguraons
The device conguraon is saved using a commit model—a candidate conguraon is modied as
desired and then commied to the system. When a conguraon is commied, the device checks the
conguraon for syntax errors, and if no errors are found, the conguraon is saved as juniper.conf.gz
and acvated. The formerly acve conguraon le is saved as the rst rollback conguraon le
48
(juniper.conf.1.gz), and any other rollback conguraon les are incremented by 1. For example,
juniper.conf.1.gz is incremented to juniper.conf.2.gz, making it the second rollback conguraon le.
The device can have a maximum of 49 rollback conguraons (numbered 1 through 49) saved on the
system.
On the device, the current conguraon le and the rst three rollback les (juniper.conf.gz.1,
juniper.conf.gz.2, juniper.conf.gz.3) are located in the /cong directory. (The remaining rollback les, 4
through 49, are located in /var/db/cong.)
If the recovery conguraon le rescue.conf.gz exists, this le is also located in the /cong directory.
The factory default les are located in the /etc/cong directory.
There are two mechanisms used to propagate the conguraons between Roung Engines within a
device:
• Synchronizaon: Propagates a conguraon from one Roung Engine to a second Roung Engine
within the same device chassis.
To synchronize conguraons, use the commit synchronize CLI command. If one of the Roung Engines
is locked, the synchronizaon fails. If synchronizaon fails because of a locked conguraon le, you
can use the commit synchronize force command. This command overrides the lock and synchronizes the
conguraon les.
• Distribuon: Propagates a conguraon across the roung plane on a mulchassis device.
Distribuon occurs automacally. There is no user command available to control the distribuon
process. If a conguraon is locked during a distribuon of a conguraon, the locked conguraon
does not receive the distributed conguraon le, so the synchronizaon fails. You need to clear the
lock before the conguraon and resynchronize the roung planes.
NOTE: When you use the commit synchronize force CLI command on a mulchassis plaorm, the
forced synchronizaon of the conguraon les does not aect the distribuon of the
conguraon le across the roung plane. If a conguraon le is locked on a device remote
from the device where the command was issued, the synchronizaon fails on the remote
device. You need to clear the lock and reissue the synchronization command.
RELATED DOCUMENTATION
Conguring Junos OS for the First Time on a Device with a Single Roung Engine
49
Conguraon Groups Overview
IN THIS SECTION
How Conguraon Groups Work | 50
Inheritance Model | 50
This topic provides an overview of conguraon groups and the inheritance model in the Junos OS CLI.
How Conguraon Groups Work
Conguraon groups enable you to create a group containing conguraon statements and to direct the
inheritance of that group’s statements in the rest of the conguraon. The same group can be applied to
dierent secons of the conguraon. Dierent secons of one group’s conguraon statements can
be inherited in dierent places in the conguraon.
Conguraon groups enable you to create smaller, more logically constructed conguraon les, making
it easier to congure and maintain Juniper Networks devices. For example, you can group statements
that are repeated in many places in the conguraon, such as when conguring interfaces. By grouping
statements, you can limit conguraon updates to just the group.
You can also use wildcards in a conguraon group. Any object that matches the wildcard expression
inherits the group conguraon data.
The conguraon group mechanism is separate from the grouping mechanisms used elsewhere in the
conguraon, such as BGP groups. Conguraon groups provide a generic mechanism that you can use
throughout the conguraon but that are known only to the CLI. The individual soware processes that
perform the acons directed by the conguraon receive the expanded form of the conguraon; they
have no knowledge of conguraon groups.
Inheritance Model
Conguraon groups use true inheritance, which involves a dynamic, ongoing relaonship between the
source of the conguraon data and the target of that data. The target automacally inherits data values
that you change in the conguraon group. The target does not need to contain the inherited
informaon. However, the inherited values can be overridden in the target without aecng the source
from which they were inherited.
This inheritance model enables you to see only the instance-specic informaon without seeing the
inherited details. A command pipe in conguraon mode enables you to display the inherited data.
50
CHAPTER 4
Conguring Junos Devices
IN THIS CHAPTER
Inial Router or Switch Conguraon Using Junos OS | 52
Conguring Junos OS for the First Time on a Device with a Single Roung Engine | 53
Conguring Junos OS for the First Time on a Device with Dual Roung Engines | 58
How to Improve Commit Time When Using Conguraon Groups | 64
Creang and Acvang a Candidate Conguraon | 65
Format for Specifying IP Addresses, Network Masks, and Prexes in Junos OS Conguraon
Statements | 65
Format for Specifying Filenames and URLs in Junos OS CLI Commands | 66
Mapping the Name of the Router to IP Addresses | 67
Conguring Automac Mirroring of the CompactFlash Card on the Hard Drive | 68
Using Junos OS to Specify the Number of Conguraons Stored on the CompactFlash Card | 69
Back Up Conguraons to an Archive Site | 70
Conguring Junos OS to Set Console and Auxiliary Port Properes | 72
Inial Router or Switch Conguraon Using Junos OS
This topic provides an overview of inial network device conguraon tasks using Junos OS.
When you turn on a device for the rst me, Junos OS automacally boots and starts. You must enter
basic conguraon informaon so the device is on the network and you can log in to it over the
network.
To congure the device inially, you must connect through the console port.
When you rst connect to the console of a device that has not yet been congured, log in as the user
root. At rst, the root account requires no password. You can see that you are the user root, because the
command prompt shows the username root@#.
52
You must start the Junos OS command-line interface (CLI) using the command cli. The command
prompt root@> indicates that you are the user root and that you are in Junos OS operaonal mode. Enter
Junos OS conguraon mode by typing the command configure. The command prompt root@# indicates
that you are in the Junos OS conguraon mode.
When you rst congure a device, you should congure the following basic properes:
• Device hostname
• Domain name
• IP address of the device management Ethernet interface. To nd the management Ethernet interface
that you should use for conguraon, see Supported Roung Engines by Router.
• IP address of a backup router
• IP address of one or more DNS name servers on your network
• Password for the root account
RELATED DOCUMENTATION
Conguring Junos OS for the First Time on a Device with a Single Roung Engine | 53
Conguring Junos OS for the First Time on a Device with Dual Roung Engines | 58
Supported Roung Engines by Router
Junos OS Conguraon Using the CLI
Conguring Junos OS for the First Time on a Device with a Single Roung
Engine
To congure the Junos OS for the rst me on a router with a single Roung Engine and no base
conguraon, follow these steps:
1. Connect to the device through the console port.
2. Power on the device and wait for it to boot.
The Junos OS boots automacally. The boot process is complete when you see the login: prompt
on the console.
3.
Log in as the user root.
Inially, the root user account requires no password. You can see that you are the root user, because
the prompt on the device shows the username root@#.
53
4. Start the Junos OS command-line interface (CLI):
root@# cli
root@>
5. Enter Junos OS conguraon mode:
cli> configure
[edit]
root@#
6. Congure the hostname of the device. We do not recommend spaces in the router name. However,
if the name does include spaces, enclose the enre name in quotaon marks (" ").
[edit]
root@# set system host-name
hostname
7. Set the root password, entering either a clear-text password that the system will encrypt, a
password that is already encrypted, or an SSH public key string.
Choose one of the following:
a. To enter a clear-text password, use the following command:
[edit]
root@# set system root-authentication plain-text-password
New password:
type password
Retype new password:
retype password
b. To enter a password that is already encrypted, use the following command:
[edit]
root@# set system root-authentication encrypted-password
encrypted-password
c. To enter an SSH public key, use the following command:
[edit]
root@# set system root-authentication ssh-rsa
key
54
8. Congure the device domain name:
[edit]
root@# set system domain-name
domain-name
NOTE: Before you begin the next step, see Supported Roung Engines by Router to nd the
management Ethernet interface that you should use to perform this conguraon.
9. Congure the IP address and prex length for the device management Ethernet interface. The
management Ethernet interface provides a separate out-of-band management network for the
device.
• For devices that use management Ethernet interface fxp0:
[edit]
root@# set interfaces fxp0 unit 0 family inet address
address
/
prefix-length
• For devices that use management Ethernet interface em0:
[edit]
root@# set interfaces em0 unit 0 family inet address
address
/
prefix-length
10. Congure the IP address of a backup or default network device. Choose a device that is directly
connected to the local router by way of the management interface. This backup is used only when
it is boong and only or when the Junos roung soware (the roung protocol process, rpd) is not
running.
For devices with two Roung Engines, the backup Roung Engine, RE1, uses the backup device as a
default gateway aer the device boots. This enables you to access the backup Roung Engine. (RE0
is the default primary Roung Engine.)
NOTE: The backup Roung Engine does not support more than 16 backup roung
desnaons. If you congure more than 16 desnaons on the backup Roung Engine, the
55
Junos OS ignores any desnaon addresses aer the sixteenth address and displays a
commit-me warning message to this eect.
[edit]
root@# set system backup-router
address
11. Congure the IP address of a DNS server. The router uses the DNS name server to translate
hostnames into IP addresses.
[edit]
root@# set system name-server
address
12. Oponally, display the conguraon statements:
[edit]
root@ show
system {
host-name
hostname
;
domain-name
domain
.
name
;
backup-router
address
;
root-authentication {
(encrypted-password "password" | public-key);
ssh-dsa "
public-key
";
ssh-ecdsa "
public-key
";
ssh-rsa "
public-key
";
}
name-server {
address
;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address
address
;
}
}
}
}
}
56
On devices that use management Ethernet interface em0, you will see em0 in place of fxp0 in the
show command output.
13. Commit the conguraon, which acvates the conguraon on the device:
[edit]
root@# commit
Aer comming the conguraon, you see the newly congured hostname appear aer the
username in the prompt—for example, user@hostname#.
A basic conguraon for Junos OS is now set on the device.
If you want to congure addional Junos OS properes at this me, remain in the CLI conguraon
mode and add the necessary conguraon statements. You need to commit your conguraon
changes to acvate them on the device.
14. Exit from the CLI conguraon mode.
[edit]
root@
hostname
# exit
root@
hostname
>
15. Back up the conguraon.
Aer you have commied the conguraon and are sased that the new conguraon is
successfully running, you should issue the request system snapshot command to back up the new
soware to the /altcong le system. If you do not issue the request system snapshot command, the
conguraon on the alternate boot device will be out of sync with the conguraon on the primary
boot device.
The request system snapshot command causes the root le system to be backed up to /altroot, and /
cong to be backed up to /altcong. The root and /cong le systems are on the device’s
CompactFlash card, and the /altroot and /altcong le systems are on the device’s hard drive.
NOTE: Aer you issue the request system snapshot command, you cannot easily return to the
previous conguraon, because the running copy and the backup copies are idencal.
RELATED DOCUMENTATION
Inial Router or Switch Conguraon Using Junos OS | 52
Supported Roung Engines by Router
57
Format for Specifying IP Addresses, Network Masks, and Prexes in Junos OS Conguraon
Statements | 65
Default Directories for Junos OS File Storage on the Network Device | 22
Conguring Automac Mirroring of the CompactFlash Card on the Hard Drive | 68
Conguring Junos OS for the First Time on a Device with Dual Roung
Engines
If a device has dual Roung Engines, you can create conguraon groups and use the same
conguraon for both Roung Engines. This ensures that the conguraon will not change during a
failover scenario because of the idencal conguraon shared between the Roung Engines.
Congure the hostnames and addresses of the two Roung Engines using conguraon groups at the
[edit groups] hierarchy level. Use the reserved conguraon group re0 for the Roung Engine in slot 0
and re1 for the Roung Engine in slot 1 to dene Roung Engine-specic parameters. Conguring re0
and re1 groups enables both Roung Engines to use the same conguraon le.
Use the apply-groups statement to apply the apply the conguraon to the device.
The commit synchronize command commits the same conguraon on both Roung Engines. The command
makes the acve or applied conguraon the same for both Roung Engines with the excepon of the
groups, re0 being applied to only RE0 and re1 being applied only to RE1. If you do not synchronize the
conguraons between two Roung Engines and one of them fails, the router may not forward trac
correctly, because the backup Roung Engine may have a dierent conguraon.
To inially congure a device with dual Roung Engines that have no base conguraon, follow these
steps:
1. If you have not already done so, refer "Conguring Junos OS for the First Time on a Device with a
Single Roung Engine" on page 53 and follow the steps to inially congure the backup Roung
Engine.
2. Create the conguraon group re0. The re0 group is a special group designator that is only used by
RE0 in a redundant roung plaorm.
[edit]
root@host# set groups re0
58
3. Navigate to the groups re0 level of the conguraon hierarchy.
[edit]
root@host# edit groups re0
4. Specify the device hostname.
[edit groups re0]
root@host# set system host-name
host-name
NOTE: The hostname specied in the device conguraon is not used by the DNS server to
resolve to the correct IP address. This hostname is used to display the name of the Roung
Engine in the CLI. For example, the hostname appears at the command-line prompt when
you are logged in to the CLI:
user-name
@
host-name
>
NOTE: Before you begin the next step, see Supported Roung Engines by Router to nd the
management Ethernet interface that you should use to perform this conguraon.
5. Congure the IP address and prex length for the device management Ethernet interface. The
management Ethernet interface provides a separate out-of-band management network for the
device.
• For devices using the management Ethernet interface fxp0:
[edit groups re0]
root@host# set interfaces fxp0 unit 0 family inet address
address
/
prefix-length
• For devices that use the management Ethernet interface em0:
[edit groups re0]
root@host# set interfaces em0 unit 0 family inet address
address
/
prefix-length
59
6. Set the loopback interface address for the re0 conguraon group:
[edit groups re0]
root@host# set interfaces lo0 unit 0 family inet address
address
/
prefix-length
7. Return to the top level of the hierarchy.
[edit groups re0]
root@host# top
The next steps repeat for re1 the same steps as were done for the re0 conguraon group.
8. Create the conguraon group re1.
[edit]
root@host# set groups re1
9. Navigate to the groups re1 level of the conguraon hierarchy.
[edit]
root@host# edit groups re1
10. Specify the device hostname.
[edit groups re1]
root@host# set system host-name
host-name
NOTE: Before you begin the next step, see Supported Roung Engines by Router to nd the
management Ethernet interface that you should use to perform this conguraon.
11. Congure the IP address and prex length for the device management Ethernet interface.
• For devices that use the management Ethernet interface fxp0:
[edit groups re1]
root@host# set interfaces fxp0 unit 0 family inet address
address
/
prefix-length
60
• For devices that use the management Ethernet interface em0:
[edit groups re1]
root@host# set interfaces em0 unit 0 family inet address
address
/
prefix-length
12. Set the loopback interface address for re1 conguraon group:
[edit groups re1]
root@host# set interfaces lo0 unit 0 family inet address
address
/
prefix-length
13. Once both conguraon groups have been set up, return to the top level of the hierarchy.
[edit groups re1]
root@host# top
14.
Use the apply-groups statement to apply the conguraon to the device.
[edit]
root@host# set apply-groups [ re0 re1 ]
15. Congure Roung Engine redundancy:
[edit]
root@host# set chassis redundancy routing-engine 0 master
root@host# set chassis redundancy routing-engine 1 backup
16. Save the conguraon change on both Roung Engines:
[edit]
user@host> commit synchronize
Aer the conguraon changes are saved, complete the management console conguraon.
1. Set the root password by choosing one of the following:
• To enter a clear-text password, use the following command:
[edit]
root@host# set system root-authentication plain-text-password
61
New password:
type password
Retype new password:
retype password
• To enter a password that is already encrypted, use the following command:
[edit]
root@host# set system root-authentication encrypted-password
encrypted-password
• To enter an SSH public key, use the following command:
[edit]
root@host# set system root-authentication ssh-rsa
key
2. Congure the IP address of the DNS server.
[edit ]
root@host# set system name-server
address
3. Congure the router domain name:
[edit ]
root@host# set system domain-name
domain-name
4. Congure the IP address of a backup or default network device. A backup device is used only while
the roung protocol process is not running. Choose a backup device that is directly connected to the
local device by way of the management interface. The device uses this backup only when it is
boong and or when the Junos roung soware (the roung protocol process, rpd) is not running.
For more informaon, see
Conguring a Backup Router
.
For devices with two Roung Engines, the backup Roung Engine, RE1, uses the backup as a default
gateway aer the device boots. This enables you to access the backup Roung Engine. (RE0 is the
default primary Roung Engine.)
NOTE: The backup router Roung Engine does not support more than 16 backup
desnaons. If you congure more than 16 desnaons on the backup Roung Engine, the
62
Junos OS ignores any desnaon addresses aer the sixteenth address and displays a
commit-me warning message to this eect.
[edit]
root@host# set system backup-router
address
5. Oponally, display the conguraon statements:
[edit]
root@ show
system {
host-name
hostname
;
domain-name
domain
.
name
;
backup-router
address
;
root-authentication {
(encrypted-password "password" | public-key);
ssh-dsa "
public-key
";
ssh-ecdsa "
public-key
";
ssh-rsa "
public-key
";
}
name-server {
address
;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address
address
;
}
}
}
}
}
On devices that use management Ethernet interface em0, you will see em0 in place of fxp0 in the
show command output.
63
6. Aer you are sased that the conguraon is successfully running, issue the request system snapshot
command to back up the new conguraon on both primary and backup Roung Engines.
{master}
user@host> request system snapshot
The root le system is backed up to /altroot, and /cong is backed up to /altcong. The root and /
cong le systems are on the device’s CompactFlash card, and the /altroot and /altcong le
systems are on the device’s hard drive.
NOTE: Aer you issue the request system snapshot command, you cannot return to the previous
conguraon, because the running copy and backup copy are idencal.
For informaon about creang conguraon groups, see Junos OS CLI User Guide.
For informaon about conguring high availability features for redundant Roung Engine systems and
the re0 group, see Junos OS High Availability User Guide.
RELATED DOCUMENTATION
Conguring Automac Mirroring of the CompactFlash Card on the Hard Drive | 68
Conguring Junos OS for the First Time on a Device with a Single Roung Engine | 53
Default Directories for Junos OS File Storage on the Network Device | 22
Format for Specifying IP Addresses, Network Masks, and Prexes in Junos OS Conguraon
Statements | 65
Inial Router or Switch Conguraon Using Junos OS | 52
Supported Roung Engines by Router
How to Improve Commit Time When Using Conguraon Groups
You use conguraon groups to apply conguraons across other hierarchies without re-entering
conguraon data. You can specify every conguraon detail in a conguraon groups. You can also use
wildcards in conguraon groups to congure ranges of data, without detailing each conguraon line.
Another way to use conguraon groups is to create an inheritance path that includes a long string of
conguraons to be applied.
64
When a conguraon that uses conguraon groups is commied, the commit process expands and
reads all the conguraon data of the group into memory to apply the conguraons as intended. The
commit performance can be negavely aected if many conguraon groups are being applied,
especially if the conguraon groups use wildcards extensively.
If your system uses many conguraon groups that use wildcards, you can congure the persist-groups-
inheritance statement at the [edit system commit] hierarchy level to improve commit me performance.
Using this opon enables the system to build the inheritance path for each conguraon group inside
the database rather than in the process memory. This change can improve commit me performance.
However, it can also increase the database size.
Creang and Acvang a Candidate Conguraon
You can enter soware conguraon statements using the CLI to create a candidate conguraon that
contains a hierarchy of statements. To have a candidate conguraon take eect, you commit the
changes. At this point, the candidate le is checked for proper syntax, acvated, and marked as the
current, operaonal soware conguraon le. If mulple users are eding the conguraon, when you
commit the candidate conguraon, all changes made by all the users take eect.
The CLI always maintains a copy of previously commied versions of the soware conguraon. If you
need to return to a previous conguraon, you can do this from within the CLI.
RELATED DOCUMENTATION
Junos OS Commit Model for Conguraons
Format for Specifying IP Addresses, Network Masks, and Prexes in
Junos OS Conguraon Statements
Many statements in the Junos OS conguraon include an opon to specify an IP address or route
prex. This opon is represented as
destination-prefix
/
prefix-length
. Specically, the route prex, followed
by a slash and the desnaon prex length. For example, 192.168.1.10/32.
You enter all IP addresses in classless mode. You can enter the IP address with or without a prex length,
in standard doed notaon (for example, 1.2.3.4), or hexadecimal notaon as a 32-bit number in
network-byte order (for example, 0x01020304). If you omit any octets, they are assumed to be zero.
Specify the prex length as a decimal number from 1 through 32.
65
RELATED DOCUMENTATION
Format for Specifying Filenames and URLs in Junos OS CLI Commands | 66
Format for Specifying Filenames and URLs in Junos OS CLI Commands
In some CLI commands and conguraon statements—including file copy, file archive, load, save, set
system login user
username
authentication
load-key-file
, and request system software add—you can include a
lename. On a roung matrix, you can include chassis informaon (for example, lcc0, lcc0-re0, or lcc0-re1)
as part of the lename.
You can specify a lename or URL in one of the following ways:
•
filename
—A le in the user’s current directory on the local CompactFlash card (not applicable on the
QFX Series). You can use wildcards to specify mulple source les or a single desnaon le.
Wildcards are not supported in FTP.
NOTE: Wildcards are supported only by the file (compare | copy | delete | list | rename | show)
commands. When you issue the file show command with a wildcard, it must resolve to one
lename.
•
path
/
filename
—A le on the local ash drive.
•
filename
or
path
/
filename
—File on the local hard drive. You can also specify a le on a local Roung
Engine for a specic T640 router or a T1600 router in a roung matrix:
user@host> file delete lcc0-re0:/var/tmp/junk
• a:
filename
or a:
path
/
filename
—A le on the local removable media. The default path is / (the root-level
directory). The removable media can be in MS-DOS or UNIX (UFS) format.
•
hostname
:/
path
/
filename
,
hostname
:
filename
,
hostname
:
path
/
filename
, or “scp://
hostname
/
path
/
lename
”—File
on an scp/ssh server. This form is not available in the worldwide version of Junos OS. The default
path is the user’s home directory on the remote system. You can also specify
hostname
as
username
@
hostname
.
• p://
hostname
/
path
/
lename
—File on an FTP server. You can also specify
hostname
as
username
@
hostname
or
username
:
password
@
hostname
. The default path is the user’s home
directory. To specify an absolute path, the path must start with %2F; for example, p://
hostname
/%2F
path
/
lename
. To have the system prompt you for the password, specify prompt in
66
place of the password. If a password is required and you do not specify the password or prompt, an
error message is displayed:
user@host> file copy ftp://[email protected]/filename
file copy ftp.hostname.net: Not logged in.
user@host> file copy ftp://username:[email protected]/filename
Password for [email protected]:
• hp://
hostname
/
path
/
lename
—A le on an HTTP server. You can also specify hostname as
username@hostname or username:password@hostname. If a password is required and you omit it,
you are prompted for it.
NOTE: You cannot specify a HTTP(s) URL for a le as a desnaon, because HTTP(s) URLs are
not writable. However you can specify HTTP(s) URL for a le as a source.
• re0:/
path
/
lename
or re1:/
path
/
lename
—A le on a local Roung Engine. You can also specify a
le on a local Roung Engine for a specic T640 router or a T1600 router in a roung matrix:
user@host> show log lcc0-re1:chassisd
RELATED DOCUMENTATION
Default Directories for Junos OS File Storage on the Network Device | 22
Format for Specifying IP Addresses, Network Masks, and Prexes in Junos OS Conguraon
Statements | 65
Mapping the Name of the Router to IP Addresses
While using the Domain Name System (DNS) is an easier and more scalable way to resolve IP addresses
from hostnames, you might want to manually map the hostname to a stac IP address for the following
reasons:
• You might not have a DNS entry for the device.
• You might not want the computer to contact the DNS server to resolve a parcular IP address—you
might use this parcular IP address frequently, or it might be just for tesng or development
purposes.
67
To map a device’s hostname to one or more IP addresses:
1. Include the inet statement at the [edit system static-host-mapping
hostname
] hierarchy level.
user@host# set system static-host-mapping
hostname
inet <
ip-addresses
>
2. Verify the conguraon with the show command.
[edit system]
user@host# show
static-host-mapping {
hostname
{
inet [
ip-addresses
];
}
}
RELATED DOCUMENTATION
Conguring a Device’s Unique Identy for the Network
Conguring a DNS Name Server for Resolving Hostnames into Addresses
Conguring Automac Mirroring of the CompactFlash Card on the Hard
Drive
You can direct the device hard drive to automacally mirror the contents of the CompactFlash card.
When you include the mirror-flash-on-disk statement, the hard drive maintains a synchronized mirror
copy of the CompactFlash card contents. Data wrien to the CompactFlash card is simultaneously
updated in the mirrored copy of the hard drive. If the CompactFlash card fails to read data, the hard
drive automacally retrieves its mirrored copy of the CompactFlash card.
NOTE: We recommend that you disable ash-to-disk mirroring when you upgrade or downgrade
the router.
You cannot issue the request system snapshot command while ash-to-disk mirroring is enabled.
68
To congure the mirroring of the CompactFlash card to the hard drive, include the mirror-flash-on-disk
statement at the [edit system] hierarchy level:
[edit system]
mirror-flash-on-disk;
NOTE: Aer you have enabled or disabled the mirror-flash-on-disk statement, you must reboot
the device for your changes to take eect. To reboot, issue the request system reboot command.
NOTE: This feature is not supported in Junos OS Release 20.1.
RELATED DOCUMENTATION
Conguring Junos OS for the First Time on a Device with a Single Roung Engine | 53
Using Junos OS to Specify the Number of Conguraons Stored on the CompactFlash Card | 69
Using Junos OS to Specify the Number of Conguraons Stored on the
CompactFlash Card
By default, Junos OS saves the current conguraon and three previous versions of the commied
conguraon on the CompactFlash card, with an addional 46 older versions stored on the hard drive.
The currently operaonal Junos OS conguraon is stored in the le juniper.conf.gz, and the last three
commied conguraons are stored in the les juniper.conf.1.gz, juniper.conf.2.gz, and
juniper.conf.3.gz. These four les are located in the CompactFlash card in the directory /cong.
In addion to saving the current conguraon and the current operaonal version, you can also specify
how many previous versions of the commied conguraons you want stored on the CompactFlash
card in the directory /cong. The remaining previous versions of commied conguraons (4 through
49) are stored in the directory /var/db/cong on the hard disk. This is useful when you have very large
conguraons that might not t on the CompactFlash card.
69
To specify how many previous versions of the commied conguraons you want stored on the
CompactFlash card, include the max-configurations-on-flash statement at the [edit system] hierarchy level:
[edit system]
max-configurations-on-flash
number
;
number
is a value from 0 through 49.
RELATED DOCUMENTATION
Conguring Automac Mirroring of the CompactFlash Card on the Hard Drive | 68
Back Up Conguraons to an Archive Site
IN THIS SECTION
Congure the Transfer of the Acve Conguraon | 70
You can congure a device to transfer its conguraon to an archive le periodically.
Congure the Transfer of the Acve Conguraon
If you want to back up your device’s current conguraon to an archive site, you can congure the
device to transfer its acve conguraon by FTP, HTTP, secure copy (SCP), or SFTP periodically or aer
each commit.
To congure the device to transfer its acve conguraon to an archive site, include statements at the
[edit system archival configuration] hierarchy level:
[edit system archival configuration]
archive-sites {
file:/
path
;
file:///
path
;
ftp://
username
@
host
<:
port
>//
url-path
;
http://
username
@
host
<:
port
>/
url-path
;
scp://
username
@
host
<:
port
>/
url-path
;
70
sftp://
username
@
host
<:
port
>/
url-path
;
}
routing-instance
routing-instance
;
transfer-interval
interval
;
transfer-on-commit;
When you congure the device to transfer its conguraon les, you specify an archive site to which
the les are transferred. If you specify more than one archive site, the device aempts to transfer les to
the rst archive site in the list, moving to the next site only if the transfer fails.
When you use the archive-sites statement, you can specify a desnaon as an FTP URL, HTTP URL,
SCP-style remote le specicaon, or SFTP URL. The URL type le: is also supported. When you specify
the archive site, do not add a forward slash (/) to the end of the URL.
NOTE:
• The URL type le: is supported only for local les.
• When using the FTP opon, specify a double forward slash (//) aer the host:port. For
example: p://username@host<:port>//url-path
le:/path/ is the minimal representaon of a local le with no authority eld and an absolute path that
begins with a slash "/" as dened in RFC 8089.
le:///path is an example for a tradional le URI for a local le with an empty authority as dened in
RFC 8089.
NOTE: When specifying a URL in a statement using an IPv6 host address, you must enclose the
enre URL in quotaon marks ("") and enclose the IPv6 host address in brackets ([ ]). For
example, "p://
username
<:
password
>@[
ipv6-host-address
]<:
port
>//
url-path
"
To congure the device to periodically transfer its acve conguraon to an archive site, include the
transfer-interval statement at the [edit system archival configuration] hierarchy level:
[edit system archival configuration]
transfer-interval
interval
;
The
interval
is a period of me ranging from 15 through 2880 minutes.
71
To congure the device to transfer the conguraon to an archive site each me you commit the
conguraon, include the transfer-on-commit statement at the [edit system archival configuration] hierarchy
level:
[edit system archival configuration]
transfer-on-commit;
If the network device reaches the archive server through a specic roung instance, congure the
routing-instance statement at the [edit system archival configuration] hierarchy level, and specify the
roung instance.
[edit system archival configuration]
routing-instance
routing-instance
;
The desnaon lename is saved in the following format, where
n
corresponds to the number of the
compressed conguraon rollback le that has been archived:
<
router-name
>_
YYYYMMDD_HHMMSS
_juniper.conf.
n
.gz
NOTE: The me included in the desnaon lename is in Coordinated Universal Time (UTC).
Conguring Junos OS to Set Console and Auxiliary Port Properes
Most Juniper Networks devices have a console port and an auxiliary port for connecng terminals to the
router or switch. The console port is enabled by default, and its speed is 9600 baud. The auxiliary port is
disabled by default.
To congure the properes for the console and auxiliary ports, include the ports statement at the [edit
system] hierarchy level:
[edit system]
ports {
auxiliary {
disable;
insecure;
type
terminal-type
;
72
}
console {
authentication-order;
disable;
insecure;
log-out-on-disconnect;
type
terminal-type
;
}
}
By default, the terminal type is set to unknown. To change the terminal type, include the type statement,
specifying a
terminal-type
of ansi, vt100, small-xterm, or xterm. The rst three terminal types set a screen size
of 80 columns by 24 lines. The last type, xterm, sets the size to 80 columns by 65 rows.
By default, the console session is not logged out when the data carrier is lost on the console modem
control lines. To change this default and log out the session automacally when the data carrier on the
console port is lost, include the log-out-on-disconnect statement. You can use the show system users
command to verify the console session is logged out.
By default, terminal connecons to the console and auxiliary ports are secure. When you congure the
console as insecure, root logins are not allowed to establish terminal connecons. In addion,
superusers and anyone with a user idener (UID) of 0 are not allowed to establish terminal connecons
in muluser mode when you congure the console as insecure. To disable root login connecons to the
console and auxiliary ports, include the insecure statement. This opon can be used to prevent someone
from aempng password recovery by boong into single-user mode, if they do not know the root
password.
To disable console login, include the disable statement. By default, console login is enabled.
NOTE: For Common Criteria compliance, the console port must be disabled.
RELATED DOCUMENTATION
Methods for Conguring Junos OS | 45
73
CHAPTER 5
Monitoring Junos Devices
IN THIS CHAPTER
Junos OS Tools for Monitoring | 74
Tracing and Logging Junos OS Operaons | 75
Understanding Dropped Packets and Untransmied Trac Using show Commands | 77
Log a User Out of the Device | 81
Junos OS Tools for Monitoring
The primary method of monitoring and troubleshoong Junos OS, roung protocols, network
connecvity, and the device hardware is to enter commands from the CLI. The CLI enables you to
display informaon in the roung tables and roung protocol-specic data, and to check network
connecvity using ping and traceroute commands.
The J-Web GUI is a Web-based alternave to using CLI commands to monitor, troubleshoot, and
manage the device.
Junos OS includes SNMP soware, which enables you to manage routers. The SNMP soware consists
of an SNMP master agent and a MIB II agent, and supports MIB II SNMP version 1 traps and version 2
nocaons, SNMP version 1 Get and GetNext requests, and version 2 GetBulk requests.
The soware also supports tracing and logging operaons so that you can track events that occur—both
normal device operaons and error condions—and track the packets that are generated by or pass
through the device. Logging operaons use a syslog-like mechanism to record system-wide, high-level
operaons, such as interfaces going up or down and users logging in to or out of the device. Tracing
operaons record more detailed messages about the operaon of roung protocols, such as the various
types of roung protocol packets sent and received, and roung policy acons.
RELATED DOCUMENTATION
Junos OS Features for Device Security | 38
Methods for Conguring Junos OS | 45
74
Tracing and Logging Junos OS Operaons
Tracing and logging operaons allow you to track events that occur in the device—both normal
operaons and error condions—and to track the packets that are generated by or passed through the
device. The results of tracing and logging operaons are placed in les in the /var/log directory.
Remote Tracing
Junos OS provides an opon to do remote tracing for specic processes, which greatly reduces use of
device internal storage for tracing and is analogous to remote system logging. You congure remote
tracing system-wide using the tracing statement at the [edit system] hierarchy level. By default, remote
tracing is not congured. You can disable remote tracing for specic processes using the no-remote-trace
statement at the [edit
process-name
traceoptions] hierarchy level. This feature does not alter local tracing
funconality in any way, and logging les are stored on the device.
Junos OS supports remote tracing for the following processes:
• chassisd—Chassis-control process
• eventd—Event-processing process
• cosd—Class-of-service process
• spd—Adapve-services process
To enable system-wide remote tracing, include the destination-override syslog host statement at the [edit
system tracing] hierarchy level. This species the remote host running the system log process (syslogd),
which collects the traces. Traces are wrien to le(s) on the remote host per the syslogd conguraon
in /etc/syslog.conf. By default remote tracing is
not
congured.
To override the system-wide remote tracing conguraon for a parcular process, include the no-remote-
trace statement at the [edit
process-name
traceoptions] hierarchy. When no-remote-trace is enabled, the
process does local tracing.
NOTE: When remote tracing is congured, traces will go to the remote host.
To collect traces, use the local0 facility as the selector in /etc/syslog.conf on the remote host. To
separate traces from various processes into dierent les, include the process name or trace-le name if
it is specied at the [edit
process-name
traceopons le] hierarchy level, in the Program eld in /etc/
syslog.conf. If your syslog server supports parsing hostname and program name, then you can separate
traces from the various processes.
Logging Operaons
75
Logging operaons use a system logging mechanism similar to the UNIX syslogd ulity to record system-
wide, high-level operaons, such as interfaces going up or down and users logging in to or out of the
device. You congure these operaons by using the syslog statement at the [edit system] hierarchy level,
as described in
Junos OS System Log Overview
, and by using the options statement at the [edit routing-
options] hierarchy level, as described in the Junos OS Roung Protocols Library for Roung Devices.
Tracing Operaons
Tracing operaons record more detailed messages about the operaon of roung protocols, such as the
various types of roung protocol packets sent and received, and roung policy acons. You congure
tracing operaons using the traceoptions statement. You can dene tracing operaons in dierent
porons of the router conguraon:
• Global tracing operaons: Dene tracing for all roung protocols. You dene these tracing operaons
at the [edit routing-options] hierarchy level of the conguraon.
• Protocol-specic tracing operaons: Dene tracing for a specic roung protocol. You dene these
tracing operaons in the [edit protocols] hierarchy when conguring the individual roung protocol.
Protocol-specic tracing operaons override any equivalent operaons that you specify in the global
traceoptions statement. If there are no equivalent operaons, they supplement the global tracing
opons. If you do not specify any protocol-specic tracing, the roung protocol inherits all the global
tracing operaons.
• Tracing operaons within individual roung protocol enes: Some protocols allow you to dene
more granular tracing operaons. For example, in Border Gateway Protocol (BGP), you can congure
peer-specic tracing operaons. These operaons override any equivalent BGP-wide operaons or, if
there are no equivalents, supplement them. If you do not specify any peer-specic tracing
operaons, the peers inherit, rst, all the BGP-wide tracing operaons and, second, the global tracing
operaons.
• Interface tracing operaons: Dene tracing for individual router interfaces and for the interface
process itself. You dene these tracing operaons at the [edit interfaces] hierarchy level of the
conguraon as described in the Junos OS Network Interfaces Library for Roung Devices.
RELATED DOCUMENTATION
Junos OS Network Interfaces Library for Roung Devices
Junos OS Roung Protocols Library for Roung Devices
Junos OS System Log Overview
76
Understanding Dropped Packets and Untransmied Trac Using show
Commands
Starng with Junos OS Release 14.2, packets that need to be forwarded to the adjacent network
element or a neighboring device along a roung path might be dropped by a device owing to several
factors. Some of the causes for such a loss of trac or a block in transmission of data packets include
overloaded system condions, proles and policies that restrict the bandwidth or priority of trac,
network outages, or disrupon with physical cable faults. You can use a number of show commands to
determine and analyze the stascal counters and metrics related to any trac loss and take an
appropriate correcve measure. The elds displayed in the output of the show commands help in
diagnosing and debugging network performance and trac-handling eciency problems.
The following show commands and associated elds applicable for dropped packets enable you to view
and analyze some of the system parameters for errors or disrupon in transmied packets.
show interfaces extensive—Display input and output packet errors or drops. Following are some of the show
interfaces extensive input counters and their denions.
Following are denions for some of the output counters for show interfaces extensive:
Following are denions for some of the Queue counters for show interfaces extensive (both outbound
and inbound). This includes CoS queue number and its associated user-congured forwarding class
name, and is displayed on IQ2 interfaces.
Errors
Sum of the incoming frame terminates and FCS errors.
Drops
Number of packets dropped by the input queue of the I/O Manager ASIC. If the
interface is saturated, this number increments once for every packet that is dropped
by the ASIC's RED mechanism.
Framing errors
Number of packets received with an invalid frame checksum (FCS).
Runts
Number of frames received that are smaller than the runt threshold.
Policed discards
Number of frames that the incoming packet match code discarded because they
were not recognized or not of interest. Usually, this eld reports protocols that the
Junos OS does not handle.
L3 incompletes
Number of incoming packets discarded because they failed Layer 3 (usually IPv4)
sanity checks of the header. For example, a frame with less than 20 bytes of
available IP header is discarded. L3 incomplete errors can be ignored by conguring
the ignore-l3-incompletes statement.
77
L2 channel errors
Number of mes the soware did not nd a valid logical interface for an incoming
frame.
L2 mismatch
meouts
Number of malformed or short packets that caused the incoming packet handler to
discard the frame as unreadable.
FIFO errors
Number of FIFO errors in the receive direcon that are reported by the ASIC on the
PIC. If this value is ever nonzero, the PIC is probably malfunconing.
Resource errors
Error counter specic to the plaorm.
For example on MX series routers, resource errors count PFE oversubscripon
drops.
Carrier
transions
Number of mes the interface has gone from down to up. This number does not
normally increment quickly, increasing only when the cable is unplugged, the far-
end system is powered down and then up, or another problem occurs. If the number
of carrier transions increments quickly (perhaps once every 10 seconds), the cable,
the far-end system, or the PIC or PIM is malfunconing.
Errors
Sum of the outgoing frame terminates and FCS errors.
Drops
Number of packets dropped by the output queue of the I/O Manager ASIC. If the
interface is saturated, this number increments once for every packet that is dropped
by the ASIC's RED mechanism.
Collisions
Number of Ethernet collisions. The Gigabit Ethernet PIC supports only full-duplex
operaon, so for Gigabit Ethernet PICs, this number should always remain 0. If it is
nonzero, there is a soware bug.
Aged packets
Number of packets that remained in shared packet SDRAM so long that the system
automacally purged them. The value in this eld should never increment. If it does,
it is most likely a soware bug or possibly malfunconing hardware.
FIFO errors
Number of FIFO errors in the send direcon as reported by the ASIC on the PIC. If
this value is ever nonzero, the PIC is probably malfunconing.
HS link CRC
errors
Number of errors on the high-speed links between the ASICs responsible for
handling the router interfaces.
MTU errors
Number of packets whose size exceeded the MTU of the interface.
Resource errors
Error counter specic to the plaorm.
Queued packets
Number of queued packets.
78
Transmied
packets
Number of transmied packets.
Dropped packets
Number of packets dropped by the ASIC's RED mechanism.
show interfaces queue—Display class-of-service (CoS) queue informaon for physical interfaces. Following
are some of the show interfaces queue output elds and their denions.
Queued packets
Number of queued packets.
Transmied
packets
Number of transmied packets.
Dropped packets
Number of packets dropped by the ASIC's RED mechanism.
Tail-dropped
packets
Number of packets dropped because of tail drop.
RL-dropped
packets
Number of packets dropped due to rate liming. For rate-limited interfaces hosted
on MICs, MPCs, and Enhanced Queuing DPCs only, this stasc is not included in
the queued trac stascs.
RED-dropped
packets
Number of packets dropped because of random early detecon (RED).
On M320 and M120 routers and most T Series routers, just the total number of
dropped packets is displayed. For other M Series routers, as well as MX Series
routers with enhanced DPCs, T Series routers with enhanced FPCs, and all J Series
routers, the output classies dropped packets into the following catetories:
• Low, non-TCP—Number of low-loss priority non-TCP bytes dropped because of
RED.
• Low, TCP—Number of low-loss priority TCP packets dropped because of RED.
• High, non-TCP—Number of high-loss priority non-TCP packets dropped because of
RED.
• High, TCP—Number of high-loss priority TCP packets dropped because of RED.
show class-of-service fabric statistics summary—Display class-of-service (CoS) switch fabric queue drop
stascs. Following are the fabric queue stascs for dropped trac:
Packets
Dropped packet count for high-priority and low-priority queues.
Bytes
Dropped byte count for high-priority and low-priority queues.
pps
Dropped packets-per-second count for high-priority and low-priority queues.
79
bps
Dropped bits-per-second count for high-priority and low-priority queues.
show pfe statistics traffic fpc—Display packet drops related to the enre FPC. Following are the FPC-
level stascs for Packet Forwarding Engine hardware discards:
The following stascs are related to Packet Forwarding Engine local trac for show pfe statistics traffic
fpc:
Timeout
Number of packets discarded because of meouts.
Truncated key
Number of packets discarded because of truncated keys.
Bits to test
Number of bits to test.
Data error
Number of packets discarded because of data errors.
Stack underow
Number of packets discarded because of stack underows.
Normal discard
Number of packets discarded because of discard routes. Packets are dropped
silently without being further processed by the host. Normal discards are
reported when packets match a rewall lter term that has an acon of discard
or when the nal result of the route look-up is a next hop of discard.
Extended discard
Number of packets discarded because of illegal next hops. Packets are dropped
silently but are also sent to the Roung Engine for further processing. Extended
discards are reported when packets match a rewall lter term that has an
acon of discard and an addional acon that requires Roung Engine
processing, such as log, count, sample, or syslog.
Invalid interface
Number of packets discarded because of invalid incoming interfaces.
Info cell drops
Number of informaon cell drops.
Fabric drops
Number of fabric drops.
Local packets input
Number of incoming packets from the local network.
Local packets output
Number of outgoing packets dispatched to a host in the local network.
Soware input high
drops
Number of incoming soware packets of high-priority, dropped during
transmission.
Soware input
medium drops
Number of incoming soware packets of medium-priority, dropped during
transmission.
80
Soware input low
drops
Number of incoming soware packets of low-priority, dropped during
transmission.
Soware output
drops
Number of outgoing soware packets that were dropped during transmission.
Hardware input
drops
Number of incoming hardware packets that were dropped during transmission.
The preceding commands represent only the main parameters that you can use to idenfy and monitor
trac drops or errors. Depending on your specic deployment scenario and network condions, you
might need to view the output of other relevant show commands to evaluate dierent factors that might
be resulng in trac transmission losses.
Log a User Out of the Device
Somemes you may need to disconnect a user session if it does not terminate aer a user logs out, or
you may otherwise want to log a user out for some other reason.
To log a user out of all terminal sessions on a router, enter the following Junos OS CLI command:
user@host> request system logout
username
user@host> show system users
10:07PM up 13 days, 1:25, 2 users, load averages: 0.17, 0.05, 0.02
USER TTY FROM LOGIN@ IDLE WHAT
harry p0 hpot-lt.cmpy.net 10:07PM - -cli (cl
lisa p1 hpot-lt.cmpy.net 10:06PM - -cli (cl
user@host> request system logout user harry
user@host> show system users
10:07PM up 13 days, 1:25, 1 user, load averages: 0.24, 0.06, 0.02
USER TTY FROM LOGIN@ IDLE WHAT
lisa p1 hpot-lt.cmpy.net 10:06PM - -cli (cl
The sample output for the rst show system users command shows there were two users on the router,
harry and lisa. The request system logout user command was issued to log out user harry. Because there is
no output to indicate that harry was logged out, the show system users command was issued again to
verify that user harry was actually logged out of the router, while the user lisa remains logged in.
81
CHAPTER 6
Managing Junos OS Processes
IN THIS CHAPTER
Saving Core Files from Junos OS Processes | 82
Viewing Core Files from Junos OS Processes | 83
Disabling Junos OS Processes | 84
Conguring Failover to Backup Media If a Junos OS Process Fails | 84
Using Virtual Memory for Process Conguraon Data | 85
Saving Core Files from Junos OS Processes
By default, when an internal Junos OS process generates a core le, the le and associated context
informaon are saved for debugging purposes in a compressed tar le named
process-name
.core.
core-
number
.tgz in the /var/tmp/ and /var/crash/ directories. For Junos OS Evolved, the output is saved in
the /var/core/ directory for Roung Engine core les and /var/lib/p/in/ for FPC core les. The
contextual informaon includes the conguraon and system log message les.
To disable the saving of core les and associated context informaon, include the no-saved-core-context
statement at the [edit system] hierarchy level:
[edit system]
no-saved-core-context;
To save the core les only, include the saved-core-files statement at the [edit system] hierarchy level and
specify the number of les to save:
[edit system]
saved-core-files
number
;
number
is the number of core les to save and can be a value from 1 through 10.
82
To save the core les along with the contextual informaon, include the saved-core-context statement at
the [edit system] hierarchy level:
[edit system]
saved-core-context;
RELATED DOCUMENTATION
saved-core-context
saved-core-les
Viewing Core Files from Junos OS Processes
Viewing Core Files from Junos OS Processes
When an internal Junos OS process generates a core le, you can nd the output at /var/crash/
and /var/tmp/. For Junos OS Evolved, you can nd the output core les at /var/core/ for Roung
Engine core les and /var/lib/p/in/ for FPC core les. Using these directories provides a quick method
of nding core issues across large networks.
Use the CLI command show system core-dumps to view core les.
root@host> show system core-dumps
-rw------- 1 root wheel 268369920 Jun 18 17:59 /var/crash/vmcore.0
-rw-rw---- 1 root field 3371008 Jun 18 17:53 /var/tmp/rpd.core.0
-rw-r--r-- 1 root wheel 27775914 Jun 18 17:59 /var/crash/kernel.0
RELATED DOCUMENTATION
Saving Core Files from Junos OS Processes
83
Disabling Junos OS Processes
CAUTION: Never disable any of the soware processes unless instructed to do so by a
Customer Support engineer.
To disable a soware process, specify the appropriate opon in the processes statement at the [edit
system] hierarchy level:
[edit system]
processes {
process-name
(enable | disable);
}
NOTE: The
process-name
variable is one of the valid process names. You can obtain a complete list
of process names by using the CLI command compleon feature.
RELATED DOCUMENTATION
processes
Conguring Failover to Backup Media If a Junos OS Process Fails | 84
Viewing Core Files from Junos OS Processes
Conguring Failover to Backup Media If a Junos OS Process Fails
For network devices with redundant Roung Engines, you can congure the device to switch to backup
media that contains a version of the system if a soware process fails repeatedly, or to the other
Roung Engine.
To congure automac switchover to backup media if a soware process fails, include the failover
statement at the
[edit system processes
process-name
]
hierarchy level. If this statement is congured for a
84
process, and that process fails four mes within 30 seconds, the device reboots from either the
alternave media or the other Roung Engine.:
[edit system processes]
process-name
failover (alternate-media | other-routing-engine);
The value for
process-name
should be one of the valid process names.
RELATED DOCUMENTATION
Disabling Junos OS Processes | 84
Saving Core Files from Junos OS Processes | 82
Using Virtual Memory for Process Conguraon Data
Conguraon data for each process in Junos OS is stored in memory that is mapped within the address
space of each process, requiring a xed maximum space to be reserved in each process. This scheme
works well unl a process is managing many funcons at commit me and negavely impacts the
commit me, or simply needs more memory than the default allotment. For example, the rpd process
might be managing many routes and require more space to store important informaon about the
routes.
In circumstances that require more than the maximum memory-mapped size, you can use virtual-memory-
mapping at the [edit system configuration-database] hierarchy level to make more memory available for the
conguraon database per process.
You can congure a poron of virtual memory at a xed size for the inial poron of the conguraon
database, and you can specify an amount to be used for page-pooling. Page-pooling uses a small amount
of memory to bring database pages into memory as needed, rather than mapping the enre
conguraon database into the virtual memory space for the process.
85
Junos CLI Reference Overview
We've consolidated all Junos CLI commands and conguraon statements in one place. Learn about the
syntax and opons that make up the statements and commands and understand the contexts in which
you’ll use these CLI elements in your network conguraons and operaons.
• Junos CLI Reference
Click the links to access Junos OS and Junos OS Evolved conguraon statement and command
summary topics.
• Conguraon Statements
• Operaonal Commands
87
