of 21 /21
Junos ® Learning Sphere Whether you are new to Junos or just want to improve your configuration skills, this Junosphere lab will boost your mastery of the Junos OS. by Antonio Sánchez-Monge vDAY ONE: MASTERING JUNOS CONFIGURATION This vDay One book is all about Junos and the magic behind the curly brackets. Log onto Junosphere, load the topology file, watch the book’s videos, and then sim- ply copy and paste from the PDF book’s 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. Virtual Day One - Learn by Doing! n Experience the Junos CLI in both videos and real hands-on training modules n Learn how to navigate through the Junos hierarchies n Master basic and advanced configuration techniques n Unveil the mysteries of rollback and commit internals n Understand how Junos handles simultaneous configurations n And much more in this 3 hour lab prepared just for you. 1 VM - 3+ hrs Try the Challenge at the End of the Book!

vDay One: Mastering Junos Configuration€¦ · mastering JUnOs COnfigUratiOn tis h vDay One book is all about Junos and ... Juniper Networks, the Juniper Networks logo, Junos, NetScreen,

Embed Size (px)

Text of vDay One: Mastering Junos Configuration€¦ · mastering JUnOs COnfigUratiOn tis h vDay One book...

  • Junos Learning Sphere

    Whether you are new to Junos or just

    want to improve your configuration

    skills, this Junosphere lab will boost

    your mastery of the Junos OS.

    by Antonio Snchez-Monge

    vDay One: mastering JUnOs COnfigUratiOn

    this vDay One book is all about Junos and the magic behind the curly brackets. Log onto Junosphere, load the topology file, 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.

    Virtual Day One - Learn by Doing! n experience the Junos CLi in both videos and

    real hands-on training modules

    n Learn how to navigate through the Junos

    hierarchies

    n master basic and advanced configuration

    techniques

    n Unveil the mysteries of rollback and commit

    internals

    n Understand how Junos handles simultaneous

    configurations

    n and much more in this 3 hour lab prepared

    just for you.

    1 Vm - 3+ hrs

    Try the Challenge at the End of the Book!

  • Juniper 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

    settings

    n Only firefox 19 and higher, and internet explorer 9 and higher, are supported

    n enable pop-ups for junosphere.net

    n allow downloads from junosphere.net

    n install latest Java plug-in

    recommended

    Downloads

    n RealVNC - Remote access to the CentOS server

    n PuTTY - ssH/telnet client to access device consoles

    n Notepad++ - reader of configuration files

    n FileZilla - ftP client to access device consoles

    n 7zip - Creates compressed topology filesets

    n VmWare Player - to run the connector

    Client Hardware Recommendations

    CPU: 1 gHz or higher is recommended for Windows; for mac, 1 gHz g4 or intel processor is recommended.

    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.

    ISBN 978-1936779796

    9 781936 779796

    5 0 9 0 0

  • 1h 2h 3h

    3

    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/booksAuthor and Video Editor: Antonio Sanchez-MongeVideo Narration: Dave DugalEditor in Chief: Patrick AmesCopyeditor and Proofer: Nancy KoerbelJ-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

    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

    q

    http://www.juniper.net/bookshttp://www.vervante.com

  • vDayOne:MasteringJunosConfiguration 4

    1h 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.

    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.

    q

    https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735

  • vDayOne:MasteringJunosConfiguration 5

    1h 2h 3h

    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.

    Figure1 TheVMPhysicalTopology

    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 named vDay One: Mastering Junos Configuration. You can find it in the Public Library called Day One Books within Junosphere.

    Video 1 also shows you how to download a file called Master-ing_Junos_Configuration.zip, that you can examine if you are curious and want to understand some of the magic behind Junosphere. This zip file contains the following files:

    topology.vmm which specifies the way the Junos OS device - or Virtual Machine - is physically connected.

    myJunos.conf which is a simple Junos OS configura-tion that youll load later in Section 2 of this book.

    ge-mtu.slax which is a sample Commit Script that you 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.

    Video1 StartingtheVMTopology(clickontheimageabovetolaunch)

    IMPORTANT In Sections 2 and 3, and at the beginning of Section 4, you need to connect to the console of the Junos OS device. In the remaining sections, you are expected to access the device using plain telnet.

    TIP If you lose connectivity to the Junosphere topology, don't worry! As long as the reservation doesn't expire, it will stay running in the background. You just need to reconnect.

    MORE? For more information about the concepts behind Junosphere and its GUI, check out the videos at https://learn-ingportal.juniper.net/juniper/user_activity_info.aspx?id=5735.

    q

    https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735http://youtu.be/fu7DUe3e5Ds

  • vDayOne:MasteringJunosConfiguration 6

    1h 2h 3h

    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

    The address and the 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";

    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).

    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.

    Video2 NavigatingtheJunosOSConfiguration

    q

    http://www.juniper.net/dayonehttp://www.juniper.net/dayonehttp://youtu.be/7YYKdunSD3s

  • vDayOne:MasteringJunosConfiguration 7

    1h 2h 3h

    Have a look at the active configuration from operational mode (prompt >):

    > show configuration

    > show configuration interfaces

    > show configuration interfaces ge-0/0/1

    > show configuration interfaces ge-0/0/1 unit 1

    > show configuration interfaces ge-0/0/1 unit 1 vlan-id

    How is this configuration actually applied? Lets see:

    > show interfaces terse lo0.0

    > show interfaces terse ge-0/0/1

    > show interfaces terse ge-0/0/1 routing-instance default

    > show interfaces ge-0/0/1.1 | match vlan

    MORE? You can ignore the interface ge-0/0/1.32767, which is automatically created for internal communication between control plane components in the internal routing-instance __juniper_private1__ . These components are typically in different physical cards. Not this time though, as you are in a virtual environment.

    NOTEYou 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.

    Now lets get into configuration mode (prompt #). In this mode, you could modify the configuration, although for the moment you are only going to view it:

    > configure

    # show

    # show interfaces

    # run show interfaces terse ge-0/0/1.1

    QUESTION#1 What is the run command used for?

    Now, follow the remaining steps in Video 2:

    # show interfaces ge-0/0/1 unit 1

    # show interfaces ge-0/0/1.1

    # edit interfaces ge-0/0/1

    # show

    # show unit 1 vlan-id

    # top

    # edit interfaces lo0 unit 0

    # show

    # up

    # show

    # top show system

    # top edit interfaces ge-0/0/1 unit 1

    # edit vlan-id

    Its normal to see an error in the last command, as edit is designed to enter branches, not leaves. Two more commands and youll be ready for the next section.

    # up 2

    # top

    TRYTHISYou can exit the configuration mode with exit or quit. These commands do the same thing when you execute them from the root of the tree, but not if you call them from a branch.

    3. Editing the Candidate Configuration

    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. As their names suggest, these commands are used to modify the configuration, however, they do not act upon the active configuration. Instead, they make changes to a draft that is commonly called a candidate configuration or candidate database As an example, you can add a new logical interface with the command set, but this new interface is not actually created into the device until you commit the changes to the active configura-tion. This Section focuses on these basic commands that you can use to edit a configuration draft, and the details of commit are left to Section 4.

    Its time to watch Video 3.

    q

  • vDayOne:MasteringJunosConfiguration 8

    1h 2h 3h

    Video3 EditingtheCandidateConfiguration

    Lets touch base with set and delete. Execute the following sequence, which does not result in any net change on the candidate configuration, because the delete command reverts to the initial changes:

    # show interfaces ge-0/0/1

    # set interfaces ge-0/0/1 unit 2 vlan-id 2

    # show interfaces ge-0/0/1

    # edit interfaces ge-0/0/1

    # show

    # set unit 2 vlan-id 102

    # show

    # set unit 2 family inet address 10.2.2.1/30

    # show

    # set unit 2 family inet address 10.102.2.1/30

    # show

    # run show configuration interfaces ge-0/0/1

    # delete unit 2

    # show

    QUESTION#2 What is the difference between the show command in configuration mode, and the show configuration command in operational mode?

    As you can check, the following command sequence introduc-ing copy and rename does not result in any net change on the

    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

    # set family inet address 10.200.1.1/32

    # show

    # delete family inet address 10.100.1.1/32

    # show

    # run show interfaces lo0.0 terse

    QUESTION#3 Does the information provided by the last two commands match? Why? Lets call these two commands #1 (# show) and #2 (# run show interfaces lo0.0 terse), respectively.

    Now exit configuration mode, and verify that there has been no change to the active configuration yet:

    # exit

    The configuration has been changed but not committed

    Exit with uncommitted changes? [yes,no] (yes) yes

    > show configuration interfaces lo0

    None of the changes performed so far has resulted in a change of the active configuration. So, lets go back to configuration mode and revert the changes performed in the candidate configura-tion:

    > configure

    # edit interfaces lo0 unit 0

    # rename family inet address 10.200.1.1/32 to address 10.100.1.1/32

    # show

    q

    http://youtu.be/egXrNoJ15dM

  • vDayOne:MasteringJunosConfiguration 9

    1h 2h 3h

    Lets now face the risks of the powerful command replace. The following sequence does not result in any net candidate configuration changes:

    # top

    # edit interfaces

    # show

    # replace pattern 1 with 2

    # show

    # replace pattern 2 with 1

    # show

    # show | compare

    # replace pattern 10.100.1.1/31 with 10.100.1.1/32

    # show

    # show | compare

    QUESTION#4What 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 routing policy. However, it is good to illustrate the technique here:

    # top

    # edit interfaces lo0 unit 0

    # show

    # set family inet address 10.200.1.1/32

    # show

    # insert family inet address 10.200.1.1/32 before address 10.100.1.1/32

    # show

    REMEMBER The tab key can make your life easier!

    TRYTHIS The edit command also exists in operational mode. Its similar to configure and it can optionally take you to the branch you specify.

    4. Committing Configuration Changes

    Its time to introduce two of the most important and differenti-ating commands in Junos OS configuration: rollback and commit. The terms are inherited from relational databases, and are based on opposite concepts. With rollback, you discard the pending configuration changes. The candidate database becomes identical to the active configu-ration, which in turn does not change at all. With commit, you activate the configuration changes by copying the candidate database into the active configuration.

    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

    # show | compare

    # exit

    The last show | compare should be empty. Now, write down the IPv4 address of the ge-0/0/0 management interface (but dont try to configure because its reserved to Junosphere):

    > file show /var/tmp/original.conf | match address

    > file show /config/mgmt.ipaddress

    And configure your device for incoming telnet access. In Junos 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 user. This is the full procedure:

    > configure

    # set system services telnet

    # 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

  • vDayOne:MasteringJunosConfiguration 10

    1h 2h 3h

    Now, from another terminal, try to telnet to the device using the address you wrote down, and the user and password just configured:

    telnet

    Username: vdayone

    Password: Clouds

    Have a look at Video 4 for a graphical illustration of a configu-ration commit.

    Video4 CommittingConfigurationChanges

    Now, lets see a commit in action:

    # set system host-name EVEREST# show | compare# commit

    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-

    cerned by the configuration change. In this way, the routing protocol daemon (rpd), the firewall daemon (dfwd), the Class of Service daemon (cosd), the interface daemon (dcd), etc., may be requested to read the configuration and perform a validation check.

    NOTE A daemon is the common name of any background process in freeBSD and other UNIX-like operating systems.

    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 validation error.

    At this point, if the validation is successful and the check option is not used, mgd activates the candidate configuration, rotates the configuration files as shown in next section, sends a SIGHUP signal to the relevant background processes, and returns the prompt.

    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

    http://youtu.be/bmoZ1YtRxlA

  • vDayOne:MasteringJunosConfiguration 11

    1h 2h 3h

    5. The Junos OS Commit History

    Junos OS is an advanced operating system. It keeps the last 50 committed configurations, numbered #0 to #49, where #0 stands for the currently active configuration, while #49 stands for the configuration that was active 49 commit operations ago. This section shows you how to take advantage of this feature. Watch video 5 to learn the theory about Commit History before moving on to its practice.

    Video5 TheJunosOSCommitHistory

    Lets start by discarding any potential changes in the candidate database, so that it becomes identical to the active configura-tion:

    # rollback

    # show | compare /* It should be empty */

    # show

    Now its time to see the commit history in action:

    # show | compare

    # show | compare rollback 1

    # set system host-name K2

    # show | compare

    # commit

    # set system host-name MAKALU

    # show | compare

    # commit

    # set system host-name ANNAPURNA

    # show | compare

    # commit

    # set system host-name CHO-OYU

    # 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

    > show system rollback 4 compare 0

    > configure

    # rollback 1

    # show | compare

    # commit

    # rollback 1

    # show | compare

    # commit

    # rollback ?

    # show | compare rollback 1

    # show | compare rollback 2

    # show | compare rollback 3

    q

    http://youtu.be/oJP0KR9J9Lg

  • vDayOne:MasteringJunosConfiguration 12

    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.

    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.

    TRYTHIS 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

    http://www.juniper.net/techpubs

  • vDayOne:MasteringJunosConfiguration 13

    1h 2h 3h

    6. Other Views of Junos OS Configuration

    The classical view of the Junos OS configuration, with all its magic curly brackets, is practical to display and read. However, for certain applications, other formats are more convenient. Watch Video 6 to see one of the most typically used formats:

    Video6 ViewingtheConfigurationinSetFormat

    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

    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 Automation feature set, including Commit, Event, and Op Scripts:

    # 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.

    q

    http://www.juniper.net/dayonehttp://youtu.be/IyOV3ocpaqg

  • vDayOne:MasteringJunosConfiguration 14

    1h 2h 3h

    7. Backing Up and Loading Configuration Blocks and Patches

    There are many instances when youll need to deal with blocks of configuration in an efficient way. For example, if you have a complete or partial configuration of a device, you may want to port it (conveniently adapted in a text editor) to another device. Or you may need to undo, or redo, a given configuration change that was done at commit #33. Not to mention the configuration backup and restore applications. Junos OS is particularly powerful and flexible in this aspect: configuring large networks is not such a big deal with Junos OS!

    Lets watch Video 7 just to see a sample of the different applica-tions:

    Video7 HandlingConfigurationBlocksandPatches

    In the first example, you will save all of the active configuration to a local file that can optionally be transferred via FTP/SCP to an external server. Then you will delete the whole candidate configuration and load it again, but this time without using the rollback command:

    # exit

    > show configuration | save myFile1

    > file show myFile1

    > configure

    # delete

    This will delete the entire configuration

    Delete everything under this level? [yes,no] (no) yes

    # show

    # show | compare myFile1

    # load override myFile1

    # show

    # show | compare myFile1

    The last command output should be empty, since there are no differences between the candidate configuration and myFile1.

    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 */

    # show interfaces lo0

    # edit interfaces lo0

    # load merge myFile2

    /* An error is expected here */

    # show

    # load merge myFile2 relative

    # show

    # top

    q

    http://youtu.be/ZZDr1YAav2w

  • vDayOne:MasteringJunosConfiguration 15

    1h 2h 3h

    Copy the output of the following command in a text document (use any external text editor for this), and keep the document open:

    # show interfaces lo0

    Now, delete the configuration of the lo0 interface and apply it in 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:

    # show

    NOTE All the load options discussed here allow both for terminal and file input

    One more variant:

    # top

    # show interfaces lo0 | display set | save myFile2-bis

    # delete interfaces lo0

    # 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

    q

    # rollback

    # show interfaces lo0

    # load patch myFile3

    # show interfaces lo0

    # show | compare

    # rollback

    # exit

    8. Simultaneous Configurations

    Until now, you have been the only user configuring the device! In the real life of lab and production networks, it is very common to have either several people, or even the same person (or provisioning system) in different sessions, accessing the configuration at the same time. Guaranteeing consistency becomes an issue, and there are several strategies to address it. Watch Video 8 to prepare for the practice session.

    Video8SimultaneousRead-WriteAccesstotheConfigurationDatabases

    http://youtu.be/acub02U5wRw

  • vDayOne:MasteringJunosConfiguration 16

    1h 2h 3h

    Open another CLI session to the device:

    telnet

    Username: vdayone

    Password: Clouds

    TIP You can use the operational command show interfaces terse ge-0/0/0 if you dont remember the management IPv4 address.

    Now you have two CLI sessions (#1 and #2) connected to the same device. Both sessions will be in configuration mode at the same time.

    IMPORTANT By default, the configure command provides direct read-write access to the candidate database.

    The candidate database is shared by all the sessions accessing it. Test how it works by following these instructions. Consider the vertical line as the time axis. You should progress to the next line only if both sessions have already executed the current line. Remember you are simulating two users doing things at the same time, so you need to change from one terminal to another very frequently during this practice:

    SESSION#1

    @EVEREST> configure

    @EVEREST# show system host-name

    @EVEREST# set system host-name LHOTSE

    @EVEREST# show system host-name

    @EVEREST# exit

    The configuration has been changed but

    not committed

    Exit with uncommitted changes? yes

    @EVEREST> configure

    @EVEREST# show system host-name

    @EVEREST#

    @EVEREST# show system host-name

    @EVEREST# show | compare

    @EVEREST#

    @K2# exit

    @K2>

    TIP If you do a set + delete sequence that results in no pending changes, the candidate database has the modified flag set, even if show | compare output is empty. In this case, just execute rollback and then you can do a clean exit.

    As you saw in the video, the sessions in private mode do not have direct access to the shared configuration database. Try it yourself!

    SESSION#1

    @K2> configure private

    @K2# show system host-name

    @K2# set system host-name ANNAPURNA

    @K2# show system host-name

    @K2# exit

    The configuration has been changed

    but not committed

    Discard uncommitted changes? yes

    @K2> configure private

    @K2# show system host-name

    @K2# set system host-name ANNAPURNA

    @K2# show system host-name

    @K2# show | compare

    @K2# commit

    @ANNAPURNA#

    @ANNAPURNA#

    @ANNAPURNA# show system host-name

    @ANNAPURNA#

    @ANNAPURNA#

    @ANNAPURNA#

    @ANNAPURNA#

    @ANNAPURNA#

    @ANNAPURNA#

    @ANNAPURNA#

    @ANNAPURNA# show system host-name

    @ANNAPURNA#

    @ANNAPURNA#

    @MAKALU# show system host-name

    @MAKALU# exit

    q

    SESSION#2

    @K2> configure private

    @K2# show system host-name

    @K2#

    @K2# show system host-name

    @K2#

    @K2#

    @K2# show system host-name

    @K2#

    @K2# show system host-name

    @K2# show | compare

    @K2#

    @ANNAPURNA# show system host-name

    @ANNAPURNA# set system host-name MAKALU

    @ANNAPURNA# show system host-name

    @ANNAPURNA# show | compare

    @ANNAPURNA# commit

    [edit system host-name]

    host-name ANNAPURNA

    statement does not match patch:

    ANNAPURNA != K2

    @ANNAPURNA# show system host-name

    @ANNAPURNA# show | compare

    @ANNAPURNA# commit

    @MAKALU# show system host-name

    @MAKALU# exit

    SESSION#2

    @EVEREST> configure

    @EVEREST# show system host-name

    @EVEREST#

    @EVEREST# show system host-name

    @EVEREST# exit

    The configuration has been changed

    but not committed

    Exit with uncommitted changes? yes

    @EVEREST> configure

    @EVEREST# show system host-name

    @EVEREST# set system host-name K2

    @EVEREST# show system host-name

    @EVEREST# show | compare

    @EVEREST# commit

    @K2# exit

    @K2>

  • vDayOne:MasteringJunosConfiguration 17

    1h 2h 3h

    You can now experience the exclusive mode:

    SESSION#1

    @MAKALU> configure

    @MAKALU# set system host-name ANNAPURNA

    error: configuration database locked

    @MAKALU# exit

    And finally, the interaction between a session in default con-figuration mode (accessing the shared configuration database) with another session in private mode:

    SESSION#1

    @MAKALU> configure private

    @MAKALU# set system host-name ANNAPURNA

    @MAKALU#

    @MAKALU# exit

    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.

    9. Hierarchy in Action

    Junos OS configuration is far from being a monolithic text file. In fact, there is a pre-inheritance and a post-inheritance view. When you display the configuration, you typically see the pre-inheritance view. But when you do a commit, Junos builds the post-inheritance view. Different pre-inheritance views can result in the same post-inheritance view. So whats the inheritance about? Imagine you want to tempo-rarily remove an interface from the configuration. You can 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 only make a difference in the pre-inheritance view. Once the post-inheritance view is calculated, the interface is no longer there. You also have the possibility of defining certain structures called groups, that can be applied in a hierarchical manner to several parts of the configuration at the same time. In this 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:

    Video9 TheRoleofInheritanceinJunosOSConfiguration

    q

    SESSION#2

    @MAKALU> configure exclusive

    @MAKALU# exit

    SESSION#2

    @MAKALU> configure

    @MAKALU#

    @MAKALU# set system host-name CHO-OYU

    error: private edits in use. Try

    configure private or configure

    exclusive.

    @MAKALU# exit

    http://youtu.be/prVcNhMEqTg

  • vDayOne:MasteringJunosConfiguration 18

    1h 2h 3h

    One of the most useful commands in Junos OS is deactivate. This command allows you to suppress a part of the configura-tion from an operational/functional perspective, but without deleting it. In order to bring that configuration back to life, you just need to activate it. Lets give it a try:

    > configure

    # show interfaces ge-0/0/1

    # show interfaces ge-0/0/1 | display inheritance

    # deactivate interfaces ge-0/0/1

    # show interfaces ge-0/0/1

    # show interfaces ge-0/0/1 | display inheritance

    # run show interfaces ge-0/0/1 terse

    # commit

    # run show interfaces ge-0/0/1 terse

    # activate interfaces ge-0/0/1

    # show interfaces ge-0/0/1

    # show interfaces ge-0/0/1 | display inheritance

    # run show interfaces ge-0/0/1 terse

    # commit

    # run show interfaces ge-0/0/1 terse

    Configuration groups are another widely used technique. Get a feel for them in action, here:

    # set groups myMTU interfaces unit family inet mtu 1600

    If you want to see the latter command as a whole, change the session properties by executing:

    # run set cli screen-width 200

    Lets apply the group you just created at the interfaces hierar-chy:

    # show interfaces | display inheritance

    # set interfaces apply-groups myMTU

    # show interfaces

    # show interfaces | display inheritance

    # show interfaces | display inheritance no-comments

    # show interfaces | display inheritance | display set

    # show | compare

    # commit check

    The configuration validation process detected an error. The logical interface family MTU (Maximum Transmission Unit) can never exceed the physical MTU. Lets clear the error condition:

    # replace pattern 1600 with 1300

    # commit check

    At the end of Section 4, you saw a list of the internal steps associated to a commit operation. Actually, inheritance is performed before Step 1. In other words, mgd starts the validation process once the candidate configuration has been processed via display inheritance.

    During the boot process in Junos OS, a commit is performed in order to activate the configuration file /config/juniper.conf. The validation process may change from one Junos OS version to another. So its possible that a given configuration passes the validation check in release A, but not in release B. In that case, an upgrade from A to B would leave the device in the so-called Amnesiac mode, corresponding to an empty (factory default) active configuration.

    How can you take a device out of Amnesiac mode? By fixing the consistency issue in the candidate database and committing it. However, this is a manual operation.

    How can you prevent a device from entering Amnesiac mode? The request system software add command has the validate option enabled by default. With this option, the current active configuration is checked by the validation routines of the target release, and ensure that it would commit successfully after the upgrade.

    CAUTION From the point of view of the release schedule, if Junos OS version A and B are very far from each other this validation is not guaranteed to work, in the sense that you may get a generic error even if the configuration is perfectly valid for A and B. You would need to skip that step with the no-validate

    q

  • vDayOne:MasteringJunosConfiguration 19

    1h 2h 3h

    option. If this is a production device, try to load in advance the active configuration in a lab device running version B, and see if it passes the commit check.

    MORE? Explore some use cases of the apply-path knob. You can find them at Juniper Techpubs, www.juniper.net/techpubs.

    10. Custom Engineering Rules Commit Scripts

    You already saw in a previous section how an inconsistency in the configuration is typically detected during the validation process (commit check). However, the fact that a configuration is completely consistent and syntactically correct from a Junos OS perspective, does not guarantee that it meets the requirements of the specific service you are deploying. 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:

    # run file show /var/db/scripts/commit/ge-mtu.slax

    # set system scripts commit file ge-mtu.slax

    # commit check

    # rollback

    # exit

    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.

    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 fact, a commit script can even modify the candidate configura-tion before the standard Junos OS validation process starts (step 1).

    MORE? Commit Scripts and Junos Automation are a large and rich feature set. Have a look at the Day One Junos Auto-mation suite of books at www.juniper.net/dayone.

    q

    http://www.juniper.net/techpubshttp://www.juniper.net/dayone

  • vDayOne:MasteringJunosConfiguration 20

    1h 2h 3h

    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.

  • vDayOne:MasteringJunosConfiguration 21

    1h 2h 3h

    Welcome to the vDay One End-of-Book Challenge.

    Now that you have finished vDay One: Mastering Junos Configuration, its time to put your newly learned Junos and Junosphere talents to use. Lets see if you can take on this virtual challenge.

    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:

    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:

    [email protected]> [command #1][email protected]> [command #2][email protected]# [command #3][email protected]# commit

    IMPORTANT There are at least two (very similar, but different) procedures that meet the requirements. The challenge is proposing both of them.

    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 [email protected] 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.

    THEWINNER 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.

    Front CoverBack Cover & Required Settings and HardwareCopyright and Author's AcknowlegementsWelcome to vDay OnePrerequisites1. Loading the Baseline Scenario2. Navigating the Junos OS Configuration3. Editing the Candidate Configuration4. Committing Configuration Changes5. The Junos OS Commit History6. Other Views of Junos OS Configuration7. Backing Up and Loading Configuration Blocks andPatches8. Simultaneous Configurations9. Hierarchy in Action10. Custom Engineering Rules Commit ScriptsAnswers to QuestionsThe vDay One End-of-Book Challenge