vDay One Mastering Junos Configuration 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 O[.]
Try the Challenge at the End of the Book! Junos® Learning Sphere 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 simply 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 networks can be used for the same exercises you perform today in your physical lab and more, including network design, modeling, troubleshooting, testing, and training VM - 3+ hrs Virtual Day One - Learn by Doing! n n Experience the Junos CLI in both videos and 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 real hands-on training modules n n Learn how to navigate through the Junos hierarchies n n Master basic and advanced configuration techniques 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 hour lab prepared by Antonio Sánchez-Monge just for you 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 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 Client Hardware Recommendations CPU: GHz or higher is recommended for Windows; for Mac, GHz G4 or Intel processor is recommended 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 book’s config files into the terminal for the best results Check for the most recent updates and specifications at www.juniper.net/junosphere 50900 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 prototype, especially: David Soriano (Telefonica), Rubén Díaz (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 © 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 Antonio Sánchez-Monge, September 2013 ISBN: 978-1-936779-79-6 (print) Printed in the USA by Vervante Corporation, www.vervante.com Version History: v1 September 2013 10 q 1h 2h 3h vDay One: Mastering Junos Configuration Welcome to vDay One 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_activity_info.aspx?id=5735 and enter promo code jun3928 , valid for Junosphere CLASSROOM only (not for LAB) 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 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 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 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 This Book: In order to keep you focused on the practical tasks, this book simply contains a step-by-step lab procedure, together with the links to videos describing each lab practice Network Connect works best without web proxies, and it works fine with static proxy configuration as well However, it doesn’t work if the browser is configured with a PAC (Proxy Auto-Configuration) file 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 configuration to relatively advanced administration techniques With the toolbox covered in this book, you will boost your mastery of the Junos OS configuration database 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 you’ll be cutting and pasting commands and configuration 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 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 additional time if you are new to Junos OS or to Junosphere The current reservation model in Junosphere works on a per-day basis, so it’s flexible in that sense q 1h 2h 3h vDay One: Mastering Junos Configuration 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 Figure The VM Physical Topology Video shows you how to start a VM topology from another vDay One book The process to start this book’s topology is very similar Just make sure you load the VM topology named vDay One: Mastering Junos Configuration You can find it in the Public Library called Day One Books within Junosphere Video Starting the VM Topology (click on the image above to launch) IMPORTANT In Sections 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 Video also shows you how to download a file called Mastering_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: If you lose connectivity to the Junosphere topology, TIP don't worry! As long as the reservation doesn't expire, it will stay running in the background You just need to reconnect topology.vmm which specifies the way the Junos OS device - or Virtual Machine - is physically connected myJunos.conf which is a simple Junos OS configuration that you’ll load later in Section of this book MORE? For more information about the concepts behind Junosphere and its GUI, check out the videos at https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735 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 sandbox Note that the promotional code is only available for Classroom q 1h 2h 3h vDay One: Mastering Junos Configuration Navigating the Junos OS Configuration Let’s start by loading a simple Junos OS configuration Then, you will examine it – without modifying it – using different CLI modes 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 configuration based on the contents of myJunos.conf: 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 supported mode, so you need to start a Junos OS CLI session, changing the prompt to > > 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 It’s time to watch Video But it’s 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 % cli > In Junosphere’s 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, that’s why the device initially booted with factory defaults configuration Let’s take a quick look at the configuration (you don’t 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 Navigating the Junos OS Configuration q 1h 2h 3h vDay One: Mastering Junos Configuration Have a look at the active configuration from operational mode (prompt >): # top # edit interfaces lo0 unit # 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 # top edit interfaces ge-0/0/1 unit > show configuration interfaces ge-0/0/1 unit vlan-id # edit vlan-id It’s normal to see an error in the last command, as edit is designed to enter branches, not leaves Two more commands and you’ll be ready for the next section How is this configuration actually applied? Let’s see: > show interfaces terse lo0.0 > show interfaces terse ge-0/0/1 > show interfaces terse ge-0/0/1 routing-instance default # up > 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 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 NOTE You may still see an IP address assigned to ge-0/0/0, even though it’s not configured You can think of it as part of the Junosphere infrastructure, and move on TRY THIS You can exit the configuration mode with exit or quit These commands the same thing when you execute them from the root of the tree, but not if you call them from a branch Editing the Candidate Configuration You already know the commands: show, edit, up, top and run Let’s get familiar with the power commands: set, delete, copy, rename, replace, and insert Now let’s get into configuration mode (prompt #) In this mode, you could modify the configuration, although for the moment you are only going to view it: As their names suggest, these commands are used to modify the configuration, however, they not act upon the active configuration Instead, they make changes to a draft that is commonly called a candidate configuration or candidate database > configure # show # show interfaces # run show interfaces terse ge-0/0/1.1 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 configuration 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 QUESTION #1 What is the run command used for? Now, follow the remaining steps in Video 2: # show interfaces ge-0/0/1 unit # show interfaces ge-0/0/1.1 # edit interfaces ge-0/0/1 It’s time to watch Video # show # show unit vlan-id q 1h 2h 3h vDay One: Mastering Junos Configuration 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 Video # show Editing the Candidate Configuration # set family inet address 10.200.1.1/32 # show Let’s 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: # 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? Let’s call these two commands #1 (# show) and #2 (# run show interfaces lo0.0 terse), respectively # show interfaces ge-0/0/1 # set interfaces ge-0/0/1 unit vlan-id # show interfaces ge-0/0/1 # edit interfaces ge-0/0/1 Now exit configuration mode, and verify that there has been no change to the active configuration yet: # show # set unit vlan-id 102 # show # exit # set unit 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 family inet address 10.102.2.1/30 # show > show configuration interfaces lo0 # run show configuration interfaces ge-0/0/1 # delete unit None of the changes performed so far has resulted in a change of the active configuration So, let’s go back to configuration mode and revert the changes performed in the candidate configuration: # show QUESTION #2 What is the difference between the show command in configuration mode, and the show configuration command in operational mode? > configure # edit interfaces lo0 unit As you can check, the following command sequence – introducing copy and rename – does not result in any net change on the # rename family inet address 10.200.1.1/32 to address 10.100.1.1/32 # show q 1h 2h 3h vDay One: Mastering Junos Configuration Let’s now face the risks of the powerful command replace The following sequence does not result in any net candidate configuration changes: Committing Configuration Changes It’s time to introduce two of the most important and differentiating commands in Junos OS configuration: rollback and commit The terms are inherited from relational databases, and are based on opposite concepts # top # edit interfaces # show # replace pattern with # show With rollback, you discard the pending configuration changes The candidate database becomes identical to the active configuration, which in turn does not change at all # replace pattern with # show # show | compare # replace pattern 10.100.1.1/31 with 10.100.1.1/32 With commit, you activate the configuration changes by copying the candidate database into the active configuration # show # show | compare QUESTION #4 What is the show | compare command doing? You are not expected to know the answer right now, but it’s 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: Up to now, you have been using the console connection Let’s 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 don’t try to configure because it’s reserved to Junosphere): # top # edit interfaces lo0 unit # show # 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 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: REMEMBER The tab key can make your life easier! TRY THIS The edit command also exists in operational mode It’s similar to configure and it can optionally take you to the branch you specify > 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 1h 2h 3h vDay One: Mastering Junos Configuration Now, from another terminal, try to telnet to the device using the address you wrote down, and the user and password just configured: 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 telnet Username: vdayone Password: Clouds NOTE A daemon is the common name of any background process in freeBSD and other UNIX-like operating systems Have a look at Video for a graphical illustration of a configuration commit Video 10 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 Committing Configuration Changes 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 Now, let’s see a commit in action: # set system host-name EVEREST # show | compare # commit The prompt should have changed to EVEREST! The relevant backgroup processes (by themselves, not a child of them) read the configuration changes and execute reconfiguration 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 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- q 1h 2h 3h vDay One: Mastering Junos Configuration The Junos OS Commit History # set system host-name MAKALU # show | compare 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 to learn the theory about Commit History before moving on to its practice # 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 > show system rollback > show configuration | compare rollback > show system rollback compare > show system rollback compare > show system rollback compare > show system rollback compare > show system rollback compare > show system rollback compare Video > show system rollback compare The Junos OS Commit History > configure Let’s start by discarding any potential changes in the candidate database, so that it becomes identical to the active configuration: # rollback # show | compare # commit # rollback # show | compare # rollback # show | compare # commit /* It should be empty */ # rollback ? # show # show | compare rollback Now it’s time to see the commit history in action: # show | compare rollback # show | compare rollback # show | compare # show | compare rollback # set system host-name K2 # show | compare # commit q 1h 2h 3h 11 vDay One: Mastering Junos Configuration QUESTION #5 How could you go back to the configuration that contained host-name Everest, without configuring the host-name explicitly? 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 QUESTION #6 What would be the outcome of executing the sequence: rollback + commit, 999 times? And 1000 times? Finally, set the hostname to the highest peak on Earth: There are several useful commit options For example, you already tested the comment option Let’s look at two other useful options: # set system host-name EVEREST # commit and-quit Execute these two commands to find the actual location of whole commit history: # set system host-name NANGA-PARBAT # show | compare # commit check > file list /config/juniper* detail > file list /var/db/config/ detail QUESTION #7 What does the check option do? 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 # show | compare # commit confirmed Wait for a couple of minutes What happened? 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 configuration 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 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 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 documentation, www.juniper.net/techpubs MORE? In devices with control plane redundancy, or with multi-chassis architecture, another interesting optimization is fast-synchronize q 1h 2h 3h vDay One: Mastering Junos Configuration 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 to see one of the most typically used formats: 13 Finally, the XML format may not be the nicest to read, but it’s an open standard format It works fine with all the XML libraries in the industry, and it’s 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 Hierarchy at www.juniper.net/dayone Coffee Break! It’s time to take a break Get some coffee, water, or stretch while thinking about those magic curly brackets Video 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 Backing Up and Loading Configuration Blocks and Patches 14 # exit > show configuration | save myFile1 > file show myFile1 There are many instances when you’ll 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! > 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 Let’s watch Video just to see a sample of the different applications: NOTE So far we only acted on the candidate database, as no commit was performed Now let’s 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 you’ll 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 Video Handling Configuration Blocks and Patches /* An error is expected here */ # show interfaces lo0 # edit interfaces lo0 # load merge myFile2 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: /* An error is expected here */ # show # load merge myFile2 relative # show # top q 1h 2h 3h vDay One: Mastering Junos Configuration Copy the output of the following command in a text document (use any external text editor for this), and keep the document open: 15 # rollback # show interfaces lo0 # load patch myFile3 # show interfaces lo0 # show | compare # show interfaces lo0 # rollback Now, delete the configuration of the lo0 interface and apply it in curly bracket format: # exit # 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 configuration should be in place again: Simultaneous Configurations # show NOTE All the load options discussed here allow both for terminal and file input 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 to prepare for the practice session 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 Video Simultaneous Read-Write Access to the Configuration Databases q 1h 2h 3h vDay One: Mastering Junos Configuration Open another CLI session to the device: TIP If you 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 a clean exit telnet Username: vdayone Password: Clouds TIP You can use the operational command show interfaces if you don’t remember the management IPv4 address As you saw in the video, the sessions in private mode not have direct access to the shared configuration database Try it yourself! terse ge-0/0/0 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 SESSION #1 SESSION #2 @K2> configure private @K2> configure private @K2# show system host-name @K2# show system host-name IMPORTANT By default, the configure command provides direct read-write access to the candidate database @K2# set system host-name ANNAPURNA @K2# @K2# show system host-name @K2# show system host-name @K2# exit @K2# 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: The configuration has been changed SESSION #1 16 SESSION #2 but not committed Discard uncommitted changes? yes @K2> configure private @K2# @K2# show system host-name @K2# show system host-name @K2# set system host-name ANNAPURNA @K2# @K2# show system host-name @K2# show system host-name @K2# show | compare @K2# show | compare @K2# commit @K2# @ANNAPURNA# @ANNAPURNA# show system host-name @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# The configuration has been changed but not committed The configuration has been changed 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# show | compare @EVEREST# show system host-name @ANNAPURNA# @EVEREST# show system host-name @ANNAPURNA# commit @EVEREST# @ANNAPURNA# @EVEREST# set system host-name K2 @MAKALU# show system host-name @EVEREST# show system host-name @MAKALU# show system host-name @EVEREST# show system host-name @MAKALU# exit @EVEREST# show | compare @MAKALU# exit @EVEREST# show | compare @EVEREST# @EVEREST# commit @K2# exit @K2# exit @K2> @K2> statement does not match patch: ’ANNAPURNA’ != ’K2’ @ANNAPURNA# q 1h 2h 3h vDay One: Mastering Junos Configuration Hierarchy in Action You can now experience the exclusive mode: SESSION #1 SESSION #2 @MAKALU> configure @MAKALU> configure exclusive 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 a commit, Junos builds the post-inheritance view Different pre-inheritance views can result in the same post-inheritance view @MAKALU# set system host-name ANNAPURNA error: configuration database locked @MAKALU# exit @MAKALU# exit And finally, the interaction between a session in default configuration mode (accessing the shared configuration database) with another session in private mode: SESSION #1 SESSION #2 @MAKALU> configure private @MAKALU> configure @MAKALU# set system host-name ANNAPURNA @MAKALU# @MAKALU# @MAKALU# set system host-name CHO-OYU So what’s the inheritance about? Imagine you want to temporarily 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 error: private edits in use Try ‘configure private’ or ‘configure exclusive’ @MAKALU# exit 17 @MAKALU# exit Watch Video 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 The Role of Inheritance in Junos OS Configuration q 1h 2h 3h vDay One: Mastering Junos Configuration One of the most useful commands in Junos OS is deactivate This command allows you to suppress a part of the configuration from an operational/functional perspective, but without deleting it In order to bring that configuration back to life, you just need to activate it Let’s give it a try: 18 The configuration validation process detected an error The logical interface family MTU (Maximum Transmission Unit) can never exceed the physical MTU Let’s clear the error condition: # replace pattern 1600 with 1300 # commit check > configure # show interfaces ge-0/0/1 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 In other words, mgd starts the validation process once the candidate configuration has been processed via display inheritance # 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 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 it’s 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 # 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: 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 # 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: 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 # run set cli screen-width 200 Let’s apply the group you just created at the interfaces hierarchy: # show interfaces | display inheritance # set interfaces apply-groups myMTU 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 # show interfaces # show interfaces | display inheritance # show interfaces | display inheritance no-comments # show interfaces | display inheritance | display set # show | compare # commit check q 1h 2h 3h vDay One: Mastering Junos Configuration 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 # run file show /var/db/scripts/commit/ge-mtu.slax # set system scripts commit file ge-mtu.slax # 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 doesn’t 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 in the list In fact, a commit script can even modify the candidate configuration before the standard Junos OS validation process starts (step 1) 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 MORE? Commit Scripts and Junos Automation are a large and rich feature set Have a look at the Day One Junos Automation suite of books at www.juniper.net/dayone For example, Junos OS definitely allows an interface to be configured in IS-IS, even if it’s 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 Let’s 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 19 2h 3h vDay One: Mastering Junos Configuration 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 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 # show | compare # commit # rollback # exitº ANSWER #6 Executing several times: rollback + 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 configuration is syntactically valid, but 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 20 vDay One: Mastering Junos Configuration Welcome to the vDay One End-of-Book Challenge Now that you have finished vDay One: Mastering Junos Configuration, it’s time to put your newly learned Junos and Junosphere talents to use Let’s see if you can take on this virtual challenge user@device> user@device> user@device# user@device# [command #1] [command #2] [command #3] commit IMPORTANT There are at least two (very similar, but different) procedures that meet the requirements The challenge is proposing both of them The challenge consists of a Virtual Machine running Junos, in Junosphere All you need to 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 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 book’s 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 The Challenge Someone has deleted the interface ge-0/0/1 units 2, 4, 6, and from the configuration Your task is to come up with a procedure to recover the original configuration of these units Your procedure must not change any other configuration on the device NOTE Don’t 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 During your research phase, try to figure out the right procedure.You are allowed to one thing only: type show commands, as many as you want, but don’t 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: 1h 21 2h 3h