Try the Challenge at the End of the Book!

Junos Learning Sphere

This vDay One book is all about Junos and

vDay One: the magic behind the curly brackets. Log
onto Junosphere, load the topology file,

mastering JUNOS Configuration watch the books videos, and then sim-
ply copy and paste from the PDF books
prompts to configure the Junosphere virtual
machine online. Learn by doing, not reading.

Junosphere provides a cost-effective and

flexible environment where you can create
and run networks in the cloud. These net-
works can be used for the same exercises
you perform today in your physical lab and
more, including network design, modeling,
troubleshooting, testing, and training.

1 VM - 3+ hrs
Virtual Day One - Learn by Doing!
n n Experience the Junos CLI in both videos and
real hands-on training modules
Whether you are new to Junos or just n n Learn how to navigate through the Junos
want to improve your configuration hierarchies
n n Master basic and advanced configuration
skills, this Junosphere lab will boost techniques
your mastery of the Junos OS. n n Unveil the mysteries of rollback and commit
internals
n n Understand how Junos handles simultaneous
configurations
n n And much more in this 3 hour lab prepared
just for you.
by Antonio Snchez-Monge
J
uniper Networks Junosphere cloud-based services allow networking professionals to perform network
testing, design, and training exercises in a risk-free virtual environment that uses real network operating
systems. Junosphere allows you to closely replicate physical networks consisting of Junos OS-based devices
and ecosystem tools without the cost, complexity, or limitations of a physical lab.

To ensure you have the best possible experience with Junosphere, check that you have the required settings.
Consider these recommendations for optional freeware programs to facilitate Junosphere usage.

Required n nOnly Firefox 19 and higher, and Internet Explorer 9 and higher, are supported
Settings n nEnable pop-ups for junosphere.net
n nAllow downloads from junosphere.net
n nInstall latest Java plug-in

Recommended n nRealVNC - Remote access to the CentOS server

Downloads n nPuTTY - SSH/telnet client to access device consoles
n nNotepad++ - Reader of configuration files
n nFileZilla - FTP client to access device consoles
n n7zip - Creates compressed topology filesets
n nVMWare Player - To run the connector

ISBN 978-1936779796
50900

Client Hardware Recommendations

CPU: 1 GHz or higher is recommended for Windows; for Mac, 1 GHz G4 or Intel processor is recommended.
9 781936 779796
Memory: Minimum of 256 MB of available RAM is recommended.

Color quality: For best results, use 16-bit (8-bit, 24-bit, and 32-bit are also supported).

Monitor resolutions: 1,024 x 768 pixels is recommended; up to 2,048 x 2,048 pixels is supported.

PDF Recommendations
Use Acrobat Reader to copy and paste this books config files into the terminal for the best results.

Check for the most recent updates and specifications at www.juniper.net/junosphere.


2013 by Juniper Networks, Inc. All rights reserved.
Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered
trademarks of Juniper Networks, Inc. in the United States and other countries. Junosphere is a
trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective 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 publication without notice.
Products made or sold by Juniper Networks or components thereof might be covered by one or more
of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos.
5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706,
6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
Published by Juniper Networks Books: http://www.juniper.net/books
Author and Video Editor: Antonio Sanchez-Monge
Video Narration: Dave Dugal
Editor in Chief: Patrick Ames
Copyeditor and Proofer: Nancy Koerbel
J-Net Community Manager: Julie Wider
ISBN: 978-1-936779-79-6 (print)
Printed in the USA by Vervante Corporation, www.vervante.com
Version History: v1 September 2013
2 3 4 5 6 7 8 9 10
q
1h
3
Acknowledgements
I would like to first thank my wife Eva, and my sons Manuel
and Lucas, for their love and patience despite all the extra
hours I dedicated to this project. Patrick Ames for his endless
positive energy and creativity. Dave Dugal for the voice
narration and his ability to make me smile. Aleksey Mints for
the very timely and collaborative integration of vDay One in
my favorite (by far) network lab environment: Junosphere.
Julie Wider for the kind help organizing the beta testing and for
promoting the program inside the J-Net Community. Diogo
Montagner for the technical review and for his involvement in
vDay One. Pilar Somohano and Pablo Mosteiro for their
honest support and global vision. Levent Ogut for the commit
history tip. My father for the effort he always puts in to make
complex things look simple: I wish I learned it from him!
Special thanks to the beta testers who went through the
material and provided feedback. All of them are from the
Juniper Ambassador Team: Kevin Barker, Martin Brown, Nick
Ryce, Steve Puluka and Victor Gonzalez. Pilar Somohano and
Aleksey Mints provided useful feedback on the Junosphere
setup video. Finally, I would also like to acknowledge all my
customers and colleagues in Juniper Networks in Spain, who
promoted this material and did the alpha testing of the proto-
type, especially: David Soriano (Telefonica), Rubn Daz
(Acuntia), Alfredo Pelaez (NSN), Jose Maroto (Tecnocom),
Daniel Toro, Rocio Benavente, Miguel Angel Rodriguez a.k.a.
Miguelon, Iria Varela, Jose Cid, Manuel Cornejo, Francisco
Sanchez, Manuel de Miguel, Oscar Diaz Poveda, Estefania
Rodriguez, and Laura Serrano.
-- Antonio Snchez-Monge, September 2013
2h 3h

Welcome to vDay One
This vDay One book provides a virtual hands-on workshop
with the following components:
Videos: Each chapter contains a link to a YouTube
video explaining the methodology or the relevant
concepts in detail.
A Real Junos OS Device: The single-device topology
used in this workshop is ready for you to start and it is
in the Public Library of Junosphere. The term device
refers to a router, or a switch, or a firewall, etc. In this
case, the device is a VJX, but the principles of Junos OS
configuration that you learn here apply to all the
physical and virtual platforms.
This Book: In order to keep you focused on the practi-
cal tasks, this book simply contains a step-by-step lab
procedure, together with the links to videos describing
each lab practice.
This vDay One book covers the most important aspects of
Junos Configuration. It targets readers who are either new to
Junos OS CLI or who want to improve their configuration
skills. The techniques covered range from very basic configura-
tion to relatively advanced administration techniques. With the
toolbox covered in this book, you will boost your mastery of
the Junos OS configuration database.
Prerequisites
The 3h00m of net time needed to go through the material on
Junosphere is an estimate. It is suggested that you book more
time to take breaks, though, as you may be curious enough to
check out other commands, or you may need to spend addi-
tional time if you are new to Junos OS or to Junosphere. The
current reservation model in Junosphere works on a per-day
basis, so its flexible in that sense.
q
1h
vDay One: Mastering Junos Configuration 4
The prerequisites for this virtual workshop are:
A valid Junosphere account (http://www.junosphere.
net). To order Junosphere with a special discount, go
to https://learningportal.juniper.net/juniper/user_ac-
tivity_info.aspx?id=5735 and enter promo code
jun3928 , valid for Junosphere CLASSROOM only
(not for LAB).
You need to have administration rights on your
computer to install the Network Connect software.
Note that although installation typically works fine in
the first attempt, some users had to retry once or twice,
and finally got it working.
It is not possible to run two simultaneous instances of
Network Connect, so if you are already have a
Network Connect instance running for a corporate
VPN, you will need to stop that first.
Network Connect works best without web proxies,
and it works fine with static proxy configuration as
well. However, it doesnt work if the browser is
configured with a PAC (Proxy Auto-Configuration)
file.
IMPORTANT The beginning of this book (you can see the
back cover page) lists the web browser, system and application
recommendations for Junosphere. Save yourself time and read
through the browser, system, and application requirements.
TIP If youll be cutting and pasting commands and con-
figuration blocks directly from this PDF into the terminal, tests
have shown using Acrobat Reader works better than other
apps with PDF capabilities these other apps can run lines of
code together.
2h 3h
 vDay One: Mastering Junos Configuration 5

1. Loading the Baseline Scenario

Start your Junos OS device using the instructions in Video 1,

and verify that the topology.vmm file corresponds to Figure 1.

Figure 1 The VM Physical Topology

Video 1 shows you how to start a 7 VM topology from another

vDay One book. The process to start this books topology is
very similar. Just make sure you load the 1 VM topology
Video 1 Starting the VM Topology (click on the image above to launch)
named vDay One: Mastering Junos Configuration. You can
find it in the Public Library called Day One Books within
Junosphere. IMPORTANT In Sections 2 and 3, and at the beginning of
Section 4, you need to connect to the console of the Junos OS
Video 1 also shows you how to download a file called Master- device. In the remaining sections, you are expected to access the
ing_Junos_Configuration.zip, that you can examine if you are device using plain telnet.
curious and want to understand some of the magic behind
Junosphere. This zip file contains the following files: TIP If you lose connectivity to the Junosphere topology,
don't worry! As long as the reservation doesn't expire, it will
topology.vmm which specifies the way the Junos OS stay running in the background. You just need to reconnect.
device - or Virtual Machine - is physically connected.
myJunos.conf which is a simple Junos OS configura- MORE? For more information about the concepts behind
tion that youll load later in Section 2 of this book. Junosphere and its GUI, check out the videos at https://learn-
ge-mtu.slax which is a sample Commit Script that you ingportal.juniper.net/juniper/user_activity_info.aspx?id=5735.
will use in Section 10 of this book.

TIP Lab vs. Classroom? There are two types of sandbox: Lab
or Classroom. The vDay One topologies are available for both
of them make sure you choose the right one for your sand-
box. Note that the promotional code is only available for
Classroom.

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 6

2. Navigating the Junos OS Configuration
Lets start by loading a simple Junos OS configuration. Then,
you will examine it without modifying it using different CLI
modes.
First connect to the console of the device, using a telnet client:
telnet <IP> <port>
The <IP> address and the <port> are indicated in the column
labeled Console, in the Virtual Machines tab of the Junosphere
GUI. The username is root and the password is Clouds. Why the
console and why the username root? Because you will soon
erase most of the configuration, leaving root as the only valid
user, and the console as the only valid access method. The goal
is to obtain a very short and simple configuration, that can ease
your learning process. When you log in as root, the prompt is %,
corresponding to the freeBSD shell. This is not an officially sup-
ported mode, so you need to start a Junos OS CLI session,
changing the prompt to >.
% cli
>
In Junospheres VJX, the initial configuration would be
specified inside the topology.vmm file as follows:
install "ENV(HOME)/active/configset/juniper.conf" "/root/olive.conf";
You are about to replace the currently active configuration
with a simpler one. The following command simply displays
the contents of a file:
> file show /var/tmp/myJunos.conf
Later in this book, you will see the configure, load, save and
commit commands explained in detail. The following procedure
saves a backup of the current configuration into a file called
original.conf, and then activates a completely new configura-
tion based on the contents of myJunos.conf:
> configure
# save /var/tmp/original.conf
# load override /var/tmp/myJunos.conf
# commit and-quit
CAUTION Currently Junosphere does not support a method
to reset console connections. If for whatever reason you lose
connectivity to the console before the middle of Section 4, and
you fail to reconnect, you will need to restart the topology.
Its time to watch Video 2. But its important to watch the video
in its entirety, then tackle the hands-on tasks. If you execute
commands before the video finishes (pausing and resuming it),
testers have found the experience much less helpful, not to
mention encountering slight differences between the video and
the practice. This advice is valid for all the videos in this book.

This line is not present in your topology.vmm file, thats why

the device initially booted with factory defaults configuration.
Lets take a quick look at the configuration (you dont really
need to understand it, yet):
> show configuration

TIP Press or double-press the tab key often. It allows you to

autocomplete more words than you would expect! And, of
course, the question mark can help you to find your way.

MORE? If you feel like you need an introduction to the Junos

OS CLI in general, have a look at Day One: Exploring the
Junos CLI. You can find it in the Day One landing page (http://
www.juniper.net/dayone). Video 2 Navigating the Junos OS Configuration

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 7

Have a look at the active configuration from operational mode # top

(prompt >): # edit interfaces lo0 unit 0

# show
> show configuration # up
> show configuration interfaces # show
> show configuration interfaces ge-0/0/1 # top show system
> show configuration interfaces ge-0/0/1 unit 1 # top edit interfaces ge-0/0/1 unit 1
> show configuration interfaces ge-0/0/1 unit 1 vlan-id # edit vlan-id

How is this configuration actually applied? Lets see: Its normal to see an error in the last command, as edit is
designed to enter branches, not leaves. Two more commands
> show interfaces terse lo0.0
and youll be ready for the next section.
> show interfaces terse ge-0/0/1
> show interfaces terse ge-0/0/1 routing-instance default # up 2
> show interfaces ge-0/0/1.1 | match vlan # top

MORE? You can ignore the interface ge-0/0/1.32767, which is

automatically created for internal communication between TRY THIS You can exit the configuration mode with exit or
control plane components in the internal routing-instance quit. These commands do the same thing when you execute
__juniper_private1__ . These components are typically in them from the root of the tree, but not if you call them from a
different physical cards. Not this time though, as you are in a branch.
virtual environment.
3. Editing the Candidate Configuration
NOTE You may still see an IP address assigned to ge-0/0/0,
even though its not configured. You can think of it as part of
the Junosphere infrastructure, and move on. You already know the commands: show, edit, up, top and run.
Lets get familiar with the power commands: set, delete, copy,
rename, replace, and insert.
Now lets get into configuration mode (prompt #). In this
mode, you could modify the configuration, although for the As their names suggest, these commands are used to modify the
moment you are only going to view it: configuration, however, they do not act upon the active
> configure
configuration. Instead, they make changes to a draft that is
# show commonly called a candidate configuration or candidate
# show interfaces database
# run show interfaces terse ge-0/0/1.1
As an example, you can add a new logical interface with the
QUESTION #1 What is the run command used for? command set, but this new interface is not actually created into
the device until you commit the changes to the active configura-
Now, follow the remaining steps in Video 2: tion. This Section focuses on these basic commands that you
can use to edit a configuration draft, and the details of commit
# show interfaces ge-0/0/1 unit 1 are left to Section 4.
# show interfaces ge-0/0/1.1
# edit interfaces ge-0/0/1
# show Its time to watch Video 3.
# show unit 1 vlan-id

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 8

candidate configuration either: the initial and the final states are
identical.
# top
# copy interfaces ge-0/0/1 to ge-0/0/2
# show interfaces
# delete interfaces ge-0/0/1
# show interfaces
# rename interfaces ge-0/0/2 to ge-0/0/1
# show interfaces

Now execute the following block, which this time results in a

net change of the candidate configuration database. A key point
here is that a logical interface supports several IPv4 addresses:
# top
# edit interfaces lo0 unit 0
# show
Video 3 Editing the Candidate Configuration # set family inet address 10.200.1.1/32
# show
Lets touch base with set and delete. Execute the following # delete family inet address 10.100.1.1/32
sequence, which does not result in any net change on the # show
candidate configuration, because the delete command reverts to # run show interfaces lo0.0 terse

the initial changes:

QUESTION #3 Does the information provided by the last two
# show interfaces ge-0/0/1 commands match? Why? Lets call these two commands #1 (#
# set interfaces ge-0/0/1 unit 2 vlan-id 2 show) and #2 (# run show interfaces lo0.0 terse), respectively.
# show interfaces ge-0/0/1
# edit interfaces ge-0/0/1
# show
Now exit configuration mode, and verify that there has been no
# set unit 2 vlan-id 102 change to the active configuration yet:
# show
# exit
# set unit 2 family inet address 10.2.2.1/30
The configuration has been changed but not committed
# show
Exit with uncommitted changes? [yes,no] (yes) yes
# set unit 2 family inet address 10.102.2.1/30
# show
> show configuration interfaces lo0
# run show configuration interfaces ge-0/0/1
# delete unit 2
None of the changes performed so far has resulted in a change of
# show
the active configuration. So, lets go back to configuration mode
QUESTION #2 What is the difference between the show and revert the changes performed in the candidate configura-
command in configuration mode, and the show configuration tion:
command in operational mode? > configure
# edit interfaces lo0 unit 0
As you can check, the following command sequence introduc- # rename family inet address 10.200.1.1/32 to address 10.100.1.1/32

ing copy and rename does not result in any net change on the # show

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 9

Lets now face the risks of the powerful command replace. The 4. Committing Configuration Changes
following sequence does not result in any net candidate
configuration changes:
Its time to introduce two of the most important and differenti-
# top ating commands in Junos OS configuration: rollback and commit.
# edit interfaces The terms are inherited from relational databases, and are
# show based on opposite concepts.
# replace pattern 1 with 2
# show
With rollback, you discard the pending configuration changes.
# replace pattern 2 with 1
# show
The candidate database becomes identical to the active configu-
# show | compare ration, which in turn does not change at all.
# replace pattern 10.100.1.1/31 with 10.100.1.1/32
# show With commit, you activate the configuration changes by copying
# show | compare the candidate database into the active configuration.

QUESTION #4 What is the show | compare command doing?

You are not expected to know the answer right now, but its
good to start getting used to it.
Finally, use the insert command. Changing the order of IPv4
addresses is not the most natural application of insert , as
compared to reordering terms inside a firewall filter or a
Up to now, you have been using the console connection. Lets
make some practical changes to the configuration, so that
regular IPv4-based telnet connections are also possible. You can
start by discarding all the pending configuration changes:
# top
# rollback

routing policy. However, it is good to illustrate the technique # show | compare

# exit
here:
# top The last show | compare should be empty. Now, write down the
# edit interfaces lo0 unit 0 IPv4 address of the ge-0/0/0 management interface (but dont
# show try to configure because its reserved to Junosphere):
# set family inet address 10.200.1.1/32
# show > file show /var/tmp/original.conf | match address
# insert family inet address 10.200.1.1/32 before address 10.100.1.1/32 > file show /config/mgmt.ipaddress
# show
And configure your device for incoming telnet access. In Junos
REMEMBER The tab key can make your life easier! OS, the root user can access the device via SSH, but not via
telnet. For this reason, you also need to configure a non-root
TRY THIS The edit command also exists in operational user. This is the full procedure:
> configure
mode. Its similar to configure and it can optionally take you to # set system services telnet
the branch you specify. # set system login user vdayone class super-user authentication plain-text-password
New password: Clouds
Retype new password: Clouds
# show | compare
# commit and-quit

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 10

Now, from another terminal, try to telnet to the device using cerned by the configuration change. In this way, the
the address you wrote down, and the user and password just routing protocol daemon (rpd), the firewall daemon
configured: (dfwd), the Class of Service daemon (cosd), the
interface daemon (dcd), etc., may be requested to read
telnet <address>
the configuration and perform a validation check.
Username: vdayone
Password: Clouds
NOTE A daemon is the common name of any background
Have a look at Video 4 for a graphical illustration of a configu- process in freeBSD and other UNIX-like operating systems.
ration commit.
Each background daemon does fork() a child daemon
that will be in charge of the validation task, while the
parent daemon keeps focused on its usual job. Each
child daemon inspects the part of the configuration
that considers relevant, and checks its consistency
for example, an interface can not have a filter applied
if the filter is not globally defined. The child processes
return their validation results to mgd, and they expire.
The validation check only succeeds if all the child
daemons report a successful result of their validation
to mgd. If the command commit was launched with the
check option, it would just provide the validation
results and exit without committing any changes.
Likewise, a regular commit (without the check option)
would stop here if any of the daemons reported a
Video 4 Committing Configuration Changes
validation error.
At this point, if the validation is successful and the
Now, lets see a commit in action: check option is not used, mgd activates the candidate

# set system host-name EVEREST configuration, rotates the configuration files as shown
# show | compare in next section, sends a SIGHUP signal to the relevant
# commit background processes, and returns the prompt.

The prompt should have changed to EVEREST!

So what happens exactly during a commit operation? The
sequence in a device with no control plane redundancy (just
one Routing Engine) is:
First, the management daemon (mgd) responsible for
the CLI session where the commit is being performed,
calls all the background daemons that may be con-
The relevant backgroup processes (by themselves, not a child
of them) read the configuration changes and execute reconfigu-
ration routines. These routines can take significant time in
highly provisioned devices. For example, you can see the status
of rpd reconfiguration by executing the command show task
jobs after the commit, and looking for reconfig tasks.

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 11

5. The Junos OS Commit History

# set system host-name MAKALU
# show | compare
Junos OS is an advanced operating system. It keeps the last 50 # commit
committed configurations, numbered #0 to #49, where #0
# set system host-name ANNAPURNA
stands for the currently active configuration, while #49 stands
# show | compare
for the configuration that was active 49 commit operations
# commit
ago. This section shows you how to take advantage of this
feature. Watch video 5 to learn the theory about Commit # set system host-name CHO-OYU
History before moving on to its practice. # show | compare
# rollback
# show | compare
# set system host-name CHO-OYU
# commit comment "I like mountains"
# exit

> show system commit

> show system rollback 0
> show system rollback 1

> show configuration | compare rollback 1

> show system rollback 0 compare 1
> show system rollback 1 compare 2
> show system rollback 2 compare 1
> show system rollback 0 compare 2
> show system rollback 0 compare 3
> show system rollback 0 compare 4
Video 5 The Junos OS Commit History > show system rollback 4 compare 0

> configure
Lets start by discarding any potential changes in the candidate # rollback 1

database, so that it becomes identical to the active configura- # show | compare

# commit
tion:
# rollback 1
# rollback # show | compare
# show | compare /* It should be empty */ # commit
# show # rollback ?
# show | compare rollback 1
Now its time to see the commit history in action: # show | compare rollback 2
# show | compare rollback 3
# show | compare
# show | compare rollback 1

# set system host-name K2

# show | compare
# commit

q
1h 2h 3h

QUESTION #5 How could you go back to the configuration
that contained host-name Everest, without configuring the
host-name explicitly?
QUESTION #6 What would be the outcome of executing
the sequence: rollback 1 + commit, 999 times? And 1000 times?
There are several useful commit options. For example, you
already tested the comment option. Lets look at two other useful
options:
# set system host-name NANGA-PARBAT
# show | compare
# commit check
QUESTION #7 What does the check option do?
# show | compare
# commit confirmed 1
Wait for a couple of minutes. What happened?
The confirmed option is essential for safer operation when risky
configuration changes need to be completed. Any engineer with
hands-on experience has seen how a CLI session suddenly
becomes unresponsive after a configuration change. The trigger
can be something obvious (like disabling the management port)
or something more sophisticated. In any case, if you are about
to apply a configuration change that may affect your session at
some point, the confirmed option is your ally. The changes are
only active for the specified amount of minutes (10, by default),
and if during that time there have been no further commits, the
device automatically rolls back to the previous configuration,
getting your CLI session to a responsive state again.
1h
vDay One: Mastering Junos Configuration 12
CAUTION In devices with control plane redundancy (more
than one Routing Engine), the commit synchronize option is key,
as it allows to keep both planes synchronized in case there is a
switchover. You can configure set system commit synchronize so
that this option is automatically added upon commit.
Finally, set the hostname to the highest peak on Earth:
# set system host-name EVEREST
# commit and-quit
Execute these two commands to find the actual location of
whole commit history:
> file list /config/juniper* detail
> file list /var/db/config/ detail
Use the file show command to display the uncompressed
contents of one of the files listed above. Also have a look at the
/var/db/commits file, where the first column contains the
commit time in UTC format.
TRY THIS List the directory /var/run/db and spot two binary
files called juniper.data and juniper.db . These are the real
configuration databases. Don't try to show their contents, since
they are in binary format. However, if you play with configura-
tion commands and look at the modification dates of these two
files, you will be able to find out which one is the candidate,
and which one is the active configuration database.
MORE? Batch commits allow for queuing the commit
operations and grouping them all together in a single commit
operation. This can be useful in highly provisioned systems.
For more about the feature, see Juniper Techpubs documenta-
tion, www.juniper.net/techpubs.
MORE? In devices with control plane redundancy, or with
multi-chassis architecture, another interesting optimization is
fast-synchronize.
q
2h 3h
 vDay One: Mastering Junos Configuration 13

6. Other Views of Junos OS Configuration Finally, the XML format may not be the nicest to read, but its
an open standard format. It works fine with all the XML
libraries in the industry, and its essential for the whole Junos
The classical view of the Junos OS configuration, with all its Automation feature set, including Commit, Event, and Op
magic curly brackets, is practical to display and read. However, Scripts:
for certain applications, other formats are more convenient.
Watch Video 6 to see one of the most typically used formats:
# show interfaces | display xml

MORE? See Day One: Navigating The Junos XML Hierar-

chy at www.juniper.net/dayone.

Coffee Break!

Its time to take a break. Get some coffee, water, or stretch

while thinking about those magic curly brackets.

Video 6 Viewing the Configuration in Set Format

Now try it yourself:

> configure
# show interfaces lo0 | display set
# exit

> show configuration interfaces lo0 | display set

QUESTION #8 Are displaying the loopback configuration

in operational and configuration mode equivalent?

One interesting application of the set format is the following:

> configure
# show interfaces | match address
# show | display set | match address
# show | match address | display set

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 14

7. Backing Up and Loading Configuration Blocks and # exit

Patches > show configuration | save myFile1

> file show myFile1

There are many instances when youll need to deal with blocks of
> configure
configuration in an efficient way. For example, if you have a # delete
complete or partial configuration of a device, you may want to This will delete the entire configuration
port it (conveniently adapted in a text editor) to another device. Delete everything under this level? [yes,no] (no) yes
Or you may need to undo, or redo, a given configuration change
that was done at commit #33. Not to mention the configuration # show
backup and restore applications. # show | compare myFile1
# load override myFile1
# show
Junos OS is particularly powerful and flexible in this aspect:
# show | compare myFile1
configuring large networks is not such a big deal with Junos OS!
The last command output should be empty, since there are no
Lets watch Video 7 just to see a sample of the different applica- differences between the candidate configuration and myFile1.
tions:
NOTE So far we only acted on the candidate database, as no
commit was performed.

Now lets play with a specific part of the configuration. This

time you will use the merge option instead of override, as you
just want to add more configuration without destroying the
existing one. In the following procedure youll end up undoing
the original changes, so the end result matches the original
configuration:
# show interfaces lo0
# show interfaces lo0 | save myFile2
# run file show myFile2
# delete interfaces lo0
# load merge myFile2
/* An error is expected here */

Video 7 Handling Configuration Blocks and Patches # show interfaces lo0

# edit interfaces lo0
# load merge myFile2
In the first example, you will save all of the active configuration /* An error is expected here */
to a local file that can optionally be transferred via FTP/SCP to
an external server. Then you will delete the whole candidate # show
# load merge myFile2 relative
configuration and load it again, but this time without using the
# show
rollback command:
# top

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 15

Copy the output of the following command in a text document # rollback

(use any external text editor for this), and keep the document # show interfaces lo0
# load patch myFile3
open:
# show interfaces lo0
# show interfaces lo0 # show | compare
# rollback
Now, delete the configuration of the lo0 interface and apply it in # exit
curly bracket format:
# delete interfaces lo0
# edit interfaces lo0
# show
# load merge terminal relative

Paste the (original or slightly modified) contents of the text

document into the terminal, and type ctrl-D. The lo0 configura-
tion should be in place again:
8. Simultaneous Configurations
# show
NOTE All the load options discussed here allow both for Until now, you have been the only user configuring the device!
terminal and file input In the real life of lab and production networks, it is very
common to have either several people, or even the same person
One more variant: (or provisioning system) in different sessions, accessing the
# top
configuration at the same time. Guaranteeing consistency
# show interfaces lo0 | display set | save myFile2-bis becomes an issue, and there are several strategies to address it.
# delete interfaces lo0 Watch Video 8 to prepare for the practice session.
# show interfaces lo0
# load set myFile2-bis
# show interfaces lo0

And, finally, the most powerful option of them all (patch).

Strange as it may seem at the beginning, this option is by far the
most useful when it comes to incrementally configuring or
evolving a network with the interactive CLI.
# show interfaces lo0
# replace pattern 10.100.1.1 with 10.200.1.1
# show interfaces lo0
# show | compare
# show | compare | save myFile3
# run file show myFile3

Video 8 Simultaneous Read-Write Access to the Configuration Databases

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 16

Open another CLI session to the device: TIP If you do a set + delete sequence that results in no
pending changes, the candidate database has the modified flag
telnet <address>
Username: vdayone
set, even if show | compare output is empty. In this case, just
Password: Clouds execute rollback and then you can do a clean exit.

TIP You can use the operational command show interfaces As you saw in the video, the sessions in private mode do not
terse ge-0/0/0if you dont remember the management IPv4 have direct access to the shared configuration database. Try it
address. yourself!

Now you have two CLI sessions (#1 and #2) connected to the
SESSION #1 SESSION #2
same device. Both sessions will be in configuration mode at the
same time. @K2> configure private @K2> configure private
@K2# show system host-name @K2# show system host-name
@K2# set system host-name ANNAPURNA @K2#
IMPORTANT By default, the configure command provides @K2# show system host-name @K2# show system host-name
direct read-write access to the candidate database. @K2# exit @K2#
The configuration has been changed
The candidate database is shared by all the sessions accessing but not committed
it. Test how it works by following these instructions. Consider Discard uncommitted changes? yes
the vertical line as the time axis. You should progress to the @K2> configure private @K2#
next line only if both sessions have already executed the current @K2# show system host-name @K2# show system host-name
line. Remember you are simulating two users doing things at @K2# set system host-name ANNAPURNA @K2#
the same time, so you need to change from one terminal to @K2# show system host-name @K2# show system host-name
another very frequently during this practice: @K2# show | compare @K2# show | compare
@K2# commit @K2#
@ANNAPURNA# @ANNAPURNA# show system host-name
SESSION #1 SESSION #2 @ANNAPURNA# @ANNAPURNA# set system host-name MAKALU
@ANNAPURNA# show system host-name @ANNAPURNA# show system host-name
@EVEREST> configure @EVEREST> configure @ANNAPURNA# @ANNAPURNA# show | compare
@EVEREST# show system host-name @EVEREST# show system host-name @ANNAPURNA# @ANNAPURNA# commit
@EVEREST# set system host-name LHOTSE @EVEREST# @ANNAPURNA# [edit system host-name]
@EVEREST# show system host-name @EVEREST# show system host-name @ANNAPURNA# host-name ANNAPURNA
@EVEREST# exit @EVEREST# exit @ANNAPURNA# statement does not match patch:
The configuration has been changed but The configuration has been changed @ANNAPURNA# ANNAPURNA != K2
not committed but not committed @ANNAPURNA#
Exit with uncommitted changes? yes Exit with uncommitted changes? yes @ANNAPURNA# show system host-name @ANNAPURNA# show system host-name
@EVEREST> configure @EVEREST> configure @ANNAPURNA# @ANNAPURNA# show | compare
@EVEREST# show system host-name @EVEREST# show system host-name @ANNAPURNA# @ANNAPURNA# commit
@EVEREST# @EVEREST# set system host-name K2 @MAKALU# show system host-name @MAKALU# show system host-name
@EVEREST# show system host-name @EVEREST# show system host-name @MAKALU# exit @MAKALU# exit
@EVEREST# show | compare @EVEREST# show | compare
@EVEREST# @EVEREST# commit
@K2# exit @K2# exit
@K2> @K2>

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 17

You can now experience the exclusive mode: 9. Hierarchy in Action

SESSION #1 SESSION #2 Junos OS configuration is far from being a monolithic text file.
In fact, there is a pre-inheritance and a post-inheritance view.
@MAKALU> configure @MAKALU> configure exclusive
When you display the configuration, you typically see the
@MAKALU# set system host-name ANNAPURNA
error: configuration database locked
pre-inheritance view. But when you do a commit, Junos builds
@MAKALU# exit @MAKALU# exit the post-inheritance view. Different pre-inheritance views can
result in the same post-inheritance view.

And finally, the interaction between a session in default con- So whats the inheritance about? Imagine you want to tempo-
figuration mode (accessing the shared configuration database) rarily remove an interface from the configuration. You can
with another session in private mode: delete it, so that the interface is no longer in the configuration.
But you can also deactivate it, and leave it in the configuration
with an inactive flag. The two commands delete and deactivate
SESSION #1 SESSION #2 only make a difference in the pre-inheritance view. Once the
@MAKALU> configure private @MAKALU> configure post-inheritance view is calculated, the interface is no longer
@MAKALU# set system host-name ANNAPURNA @MAKALU# there.
@MAKALU# @MAKALU# set system host-name CHO-OYU
error: private edits in use. Try You also have the possibility of defining certain structures
configure private or configure called groups, that can be applied in a hierarchical manner to
exclusive.
several parts of the configuration at the same time. In this
@MAKALU# exit @MAKALU# exit
sense, the pre-inheritance and post-inheritance stages of the
configuration come before and after applying the groups.

Watch Video 9 to see these concepts in action:

TIP If you enter configuration mode and simply commit with
no pending changes, one of two things can happen. In default
configuration mode, the full commit process takes place (just that
a minimal number of daemons get signaled) including a
configuration file rotation. However, in private mode nothing
happens and the session gets the prompt immediately.

Video 9 The Role of Inheritance in Junos OS Configuration

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 18

One of the most useful commands in Junos OS is deactivate. The configuration validation process detected an error. The
This command allows you to suppress a part of the configura- logical interface family MTU (Maximum Transmission Unit)
tion from an operational/functional perspective, but without can never exceed the physical MTU. Lets clear the error
deleting it. In order to bring that configuration back to life, condition:
you just need to activate it. Lets give it a try:
# replace pattern 1600 with 1300
> configure # commit check
# show interfaces ge-0/0/1
# show interfaces ge-0/0/1 | display inheritance At the end of Section 4, you saw a list of the internal steps
# deactivate interfaces ge-0/0/1 associated to a commit operation. Actually, inheritance is
# show interfaces ge-0/0/1 performed before Step 1. In other words, mgd starts the
# show interfaces ge-0/0/1 | display inheritance validation process once the candidate configuration has been
# run show interfaces ge-0/0/1 terse processed via display inheritance.
# commit
# run show interfaces ge-0/0/1 terse
During the boot process in Junos OS, a commit is performed in
order to activate the configuration file /config/juniper.conf. The
# activate interfaces ge-0/0/1 validation process may change from one Junos OS version to
# show interfaces ge-0/0/1
another. So its possible that a given configuration passes the
# show interfaces ge-0/0/1 | display inheritance
validation check in release A, but not in release B. In that case,
# run show interfaces ge-0/0/1 terse
# commit
an upgrade from A to B would leave the device in the so-called
# run show interfaces ge-0/0/1 terse
Amnesiac mode, corresponding to an empty (factory default)
active configuration.
Configuration groups are another widely used technique. Get
a feel for them in action, here: How can you take a device out of Amnesiac mode? By fixing
# set groups myMTU interfaces <ge-*> unit <*> family inet mtu 1600 the consistency issue in the candidate database and committing
it. However, this is a manual operation.
If you want to see the latter command as a whole, change the
session properties by executing:
How can you prevent a device from entering Amnesiac mode?
# run set cli screen-width 200 The request system software add command has the validate
option enabled by default. With this option, the current active
Lets apply the group you just created at the interfaces hierar- configuration is checked by the validation routines of the target
chy: release, and ensure that it would commit successfully after the
upgrade.
# show interfaces | display inheritance
# set interfaces apply-groups myMTU
# show interfaces CAUTION From the point of view of the release schedule, if
# show interfaces | display inheritance Junos OS version A and B are very far from each other this
# show interfaces | display inheritance no-comments validation is not guaranteed to work, in the sense that you may
# show interfaces | display inheritance | display set
get a generic error even if the configuration is perfectly valid for
# show | compare
A and B. You would need to skip that step with the no-validate
# commit check

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 19

option. If this is a production device, try to load in advance the # run file show /var/db/scripts/commit/ge-mtu.slax

active configuration in a lab device running version B, and see if # set system scripts commit file ge-mtu.slax
# commit check
it passes the commit check.
# rollback
# exit
MORE? Explore some use cases of the apply-path knob. You
can find them at Juniper Techpubs, www.juniper.net/techpubs. Even though the configuration is syntactically correct from the
perspective of Junos OS, it fails the validation process because
it doesnt match a customized engineering rule that you have
defined.

10. Custom Engineering Rules Commit Scripts Going back to the list at the end of Section 5, commit scripts
process the post-inheritance view, before Step 1 in the list. In
You already saw in a previous section how an inconsistency in fact, a commit script can even modify the candidate configura-
the configuration is typically detected during the validation tion before the standard Junos OS validation process starts
process (commit check). However, the fact that a configuration is (step 1).
completely consistent and syntactically correct from a Junos OS
perspective, does not guarantee that it meets the requirements MORE? Commit Scripts and Junos Automation are a large
of the specific service you are deploying. and rich feature set. Have a look at the Day One Junos Auto-
mation suite of books at www.juniper.net/dayone.
For example, Junos OS definitely allows an interface to be
configured in IS-IS, even if its not configured in MPLS. But in
your network, it may be mandatory from a design perspective,
to enable MPLS on all the IS-IS interfaces. These kinds of
custom engineering rules can be defined and applied by using a
key element of the Junos Automation feature set: commit
scripts. As a network administrator or designer, you decide
which conditions a candidate configuration must meet before
submitting it to the standard Junos OS validation.

Lets lookat a simple example. From a Junos OS perspective,

setting the physical MTU of the ge-0/0/1 interface to 1400 is
perfectly valid, since the family inet MTU applied via the
configuration groups is lower (1300):
# set interfaces ge-0/0/1 mtu 1400
# commit check

However, you decide to apply a customized engineering rule

that prevents a physical MTU from having a value below 1500
bytes:

q
1h 2h 3h
 vDay One: Mastering Junos Configuration 20

Answers to Questions

ANSWER #1 The run knob allows you to execute operational

commands without leaving the configuration mode.

ANSWER #2 The show command in configuration mode

displays the candidate configuration, and the show configuration
command in operational mode displays the active configuration.

ANSWER #3 No, they do not match. Command #1 displays

the candidate configuration, while command #2 displays the
outcome of the active configuration.

ANSWER #4 The show | compare compares the candidate

configuration to the active configuration. It basically tells you
what would actually change in the device if you commit.

ANSWER #5 With the following command sequence:

> configure
# rollback 6
# show | compare
# commit
# rollback
# exit

ANSWER #6 Executing several times: rollback 1 + commit,

makes the configuration alternate between the current active
and the last active one. So 999 times is equivalent to one time.
And 1000 times is equivalent to zero times, provided that no
other user or session performed any configuration changes or
commits in the meantime.

ANSWER #7 With commit check you just verify if the configu-

ration is syntactically valid, but do not activate (commit) the
changes. If you see errors with commit check, then a regular commit
would fail and not proceed.

ANSWER #8 No, in configuration mode you are looking at

the candidate database, while in operational mode you check
the active configuration.

1h 2h 3h
 vDay One: Mastering Junos Configuration 21

Welcome to the vDay One End-of-Book Challenge. user@device>

user@device>
[command #1]
[command #2]
user@device# [command #3]
user@device# commit
Now that you have finished vDay One: Mastering Junos
Configuration, its time to put your newly learned Junos and IMPORTANT There are at least two (very similar, but
Junosphere talents to use. Lets see if you can take on this virtual different) procedures that meet the requirements. The challenge
challenge. is proposing both of them.

The challenge consists of a Virtual Machine running Junos, in
Junosphere. All you need to do is stop your current topology,
and start another topology called vDay One Challenge 1,
which is also in the Junosphere Public Library. Once you join
this single-VM topology, try to figure out the answer to the
following challenge.
The Challenge
Someone has deleted the interface ge-0/0/1 units 2, 4, 6, and 8
from the configuration. Your task is to come up with a proce-
dure to recover the original configuration of these units. Your
procedure must not change any other configuration on the
device.
During your research phase, try to figure out the right proce-
dure.You are allowed to do one thing only: type show commands,
as many as you want, but dont use the pipe ( | ) at this stage.
Your research should conclude with the proposal of a procedure
that fulfills the following conditions:
CAUTION This is not a hacking challenge. You must
execute only established Junos CLI commands!
Check if the solution is already posted, either online on this
books landing page at www.juniper.net/dayone, or in the latest
version of this vDay One book. If the solution is not posted yet,
send your own answer to vday-one-demo@juniper.net and if it
is correct, you will be awarded free time on your Junosphere
account or other prizes.
NOTE Dont worry if some of the rollbacks are missing. The
rest of the commit history is fine.
THE WINNER The contest starts as soon as this book is
released. The first person who solves the challenge will be
recognized in J-Net as the winner of the contest.

You should only use your telnet/ssh terminal. The usage

of additional connections or external programs like text
editors is not allowed. However, using the clipboard to
copy-paste within the telnet/ssh application is allowed.
The user applying this procedure should press the
keyboard less than 100 times. Auto-completing with
tab or space is not allowed. A copy/paste operation
counts as 20 keystrokes
The procedure must only contain four commands (or
less) and should look like this:

1h 2h 3h