Juniper Tips from the JNCIA-Junos Study Guides

I’ve been a network engineer for well over a decade now. I’ve spent much of that time working on Juniper Networks devices. I even have a certification stating that I’m an expert. You might think that means I know it all by now. In fact it’s the opposite. As with anything, the more I learn, the more I realize how much more there is to know. And, after several years doing in-depth R&D and full-time Internet evangelism, I know that I’ve forgotten a bunch of stuff too. I even let my JNCIE expire. The horror.

So I’ve decided to rectify the situation, start at the bottom, and earn back my full-fledged net-geek status (and certifications). An expired JNCIE is worthless, and requires that I start over completely, testing wise. That means a hard charge through the JNCIA, JNCIS, JNCIP, and, finally, the JNCIE exams. Never willing to face the embarrassment of failing, I also decided to study; and not leave things to chance.

First up is the JNCIA-Junos certification test. Back in 2007, when I earned my first Juniper cert, the JNCIA was optional. Today it is a required prerequisite for all three Junos tracks.

Luckily, the “Fast Track” program provides some great resources, including a two-part study guide for this test (JN0-102). To my surprise, I found a number of useful tidbits that I had either missed or forgotten over the years among the roughly 200 pages of info. Here are some highlights that might help those new to Juniper and even those who just need a refresher after all these years:

Help

• ? – Your go-to “help” command in the Junos CLI is the question mark. It provides context sensitive help in both operational and configuration modes. Just type a question mark and the CLI immediately lists all available commands and options (including user-defined variables), and provides a brief description of each.
• help reference – This command displays “summary information for the referenced configuration statement.” This includes “a complete list of related configuration options along with several other details specific to the referenced command statement.” Use it by typing ‘help reference <statement>‘ onto the CLI.
• help topic – Provides usage guidelines. This command is handy when you’re looking for a bit more information and instruction on a particular command. Use it by typing ‘help topic <statement>‘ onto the CLI.
• help apropos – This one displays all the relevant “contexts” that reference a specified variable. Contexts are typically set commands, which are followed in the CLI output with a brief description of what they do. Similar to the previous two help commands, you use this one by typing ‘help apropos <variable>‘ onto the CLI.
• help syslog – Use this command to help interpret syslog message codes. A serious time saver in many situations! Issue the help command followed by the code you want to investigate, ‘help syslog <message_code>‘. Hint: The message codes are all caps, with underscores between words, such as: SNMPD_AUTH_FAILURE.

Don’t forget: You can use “?” for help with the other help commands too!

Navigation

Junos uses a VT100 terminal type by default, so you can use the keyboard arrow keys to navigate the CLI. You can also use the Delete and Backspace keys to delete the character before the cursor. When you need a bit more control, Emacs-style keyboard sequences are also available to you. Here’s a quick list of the supported sequences:

• Ctrl+b – Moves the cursor left one character
• Ctrl+a – Moves the cursor to the beginning of the command line
• Ctrl+f – Moves the cursor right one character
• Ctrl+e – Moves the cursor to the end of the command line
• Ctrl+d – Deletes the character over the cursor
• Ctrl+k – Deletes from the cursor to the end of the line
• Ctrl+u – Deletes all characters and negates the current command
• Ctrl+w – Deletes the entire word to the left of the cursor
• Ctrl+l – Redraws the current line
• Ctrl+p – Repeats the previous command in the command history
• Ctrl+n – Repeats the next command in the command history
• Esc+d – Deletes the word to the right
• Esc+b – Moves the cursor back one word with no delete
• Esc+f – Moves the cursor forward one word with no delete

Note: You must release the Esc key each time but you can hold the Ctrl key down for multiple commands.

In addition to moving your cursor around the command line, most folks using a Junos powered device will also need to navigate the configuration hierarchy. Moving between levels in a Junos configuration is a lot like changing directories on other systems. The commands are unique however, and a summary is laid out in the JNCIA-Junos study guide:

• edit – Functions like a “cd” command, moving you to the specified level within the configuration. For example, entering ‘edit protocols bgp‘ will take you to the BGP section within the Protocols section of the configuration.
• up – This command does exactly what it says; it moves you up one level. You can also move up multiple levels at once by issuing ‘up n‘ where n is the number of levels to move.
• top – Takes you directly to the top, or root, of the configuration hierarchy.
• exit – This command serves double duty, depending on where you issue it. If you are at the top of the hierarchy, ‘exit‘ will exit configuration mode. At any other configuration level, it acts as a “back” command, taking you to the previous, higher level.

Pipe

You’re probably familiar with the | (pipe) character. On many CLIs it allows you to filter command output, and Junos is no different. Instead of grep or sed or awk, you can use compare, count, match, and except, among others. Rather than give you a full rundown of all the options here, I’ll leave you with a few of my favorite use-cases:

• show | compare – When issued from configuration mode, this command sequence shows you exactly what you are about to change. I use this every time I make a configuration change to a Junos device. You can also use ‘show configuration | compare rollback n‘ from operational mode to see the differences between the current configuration and one of the available rollbacks (“n” indicating which of the 50 config versions to compare).
• show configuration | display set | match <string> – This command searches the configuration for any string and returns the full “set” statements. If you are already in configuration mode you simply omit the word “configuration”, like this: ‘show | display set | match <string>‘. I use this often for tracking down IP addresses, which can show up on interfaces, in firewall filters, policy statements, static routes, and more. You can search for longer strings by enclosing multiple words in quotation marks and using regular expressions.
•  show log messages | match <string1> | except <string2> – Stacking pipes can be helpful to get more granular when searching large log files, etc. You could even add a ‘| count‘ to the end of this to find the number of occurrences.

Configuration

The thing that really drew me to Junos first was the power of its configuration tools. These days there are more routers and switches on the market than ever, and more OS’s as well. Even so, when I have to build configurations on a CLI, I prefer to do it in Junos. This section provides a quick run through of many of the best configuration tools available in Junos, which may give you some idea why that is.

Configuration Modes

You could just type ‘configure‘ on the CLI and dive into making changes, but that would probably be a mistake. Here’s a couple configuration modes that will help you step up your Juniper game:

• configure private – Private mode basically forks the configuration for each user making changes. This allows multiple engineers to make simultaneous changes to the same device without interfering with each other. An additional benefit is that it discards all uncommitted changes when you exit. In comparison, “regular” configure mode puts all users changes together (so if one user commits, all users changes are committed – with potentially interesting results) and leaves “hanging” configuration changes on exit (so the next person may inadvertently commit those changes along with their own). Private mode also allows you to issue a ‘commit confirmed‘, which can be a life saver, and is covered below.
• configure exclusive – Exclusive mode allows only one person to make changes at a time by locking everyone else out until they exit. Like private mode, all uncommitted changes are discarded when you exit; you can use ‘commit confirmed‘ in exclusive mode as well.

I always recommend using one of these two configuration modes. Likewise, I highly discourage everyone from using plain old ‘configure‘.

Configuration Manipulation

Once you are in configure mode, you’ll want to make some changes to the configuration – that’s the point isn’t it? This section touches on a number of the tools that make that easier and more efficient in Junos.

• wildcard delete – You know that “set” commands are typically how you add configuration statements on the Junos CLI, and that you can “delete” all those same statements. But did you know that you can ‘wildcard delete‘ too? Let’s say you just removed the FPC/MPC from slot 0 and need to remove all of the related 1G interface configs. Just enter ‘wildcard delete interfaces ge-0/*‘ and BOOM, they’re all gone in one shot.
• rename – Simply rename an existing configuration statement or identifier. This is often handy if you mistyped something, or if you need to make a move. For example, you can remove interface ge-0/1/1 and apply the exact same configuration to interface xe-1/0/0 with ‘rename interfaces ge-0/1/1 to xe-1/0/0‘.
• replace pattern – Many configuration statements reference other statements. When this is the case, ‘replace pattern‘ may be the best way to make an efficient change. Using the above example, the command ‘replace pattern ge-0/1/1 with xe-1/0/0‘ would change every instance of “ge-0/1/1” in the configuration to “xe-1/0/0”.
• insert – This command moves (inserts) a given configuration statement to a specific place in the existing configuration. This is particularly helpful when editing firewall filters and policy statements. For example, ‘insert policy-options policy-statement policy1 term newterm before term oldterm‘ ensures that “newterm” is evaluated before “oldterm” in the policy “policy1”.
• copy – Use this command to duplicate entire configuration stanzas. As a demonstration, issuing ‘copy interfaces ge-0/1/1 to xe-1/0/0‘ would leave ge-0/1/1 in place but add an identical configuration for xe-1/0/0.
• deactivate – Tells Junos to ignore the affected configuration statement. Use ‘activate <statement>‘ to undo.
• annotate – Leave a comment in the configuration with this command.

Load

The load command is particularly powerful, and it provides a large number of options. The JNCIA-Junos study guide does a fine job of describing each:

• factory-default – Replaces the full current configuration with the factory-default configuration.
• merge – Combines the current configuration with the configuration you load.
• override – Completely overwrites the current configuration with the configuration you load. You must perform override operations at the root of the configuration hierarchy.
• patch – Adds or deletes variables from the configuration based on the contents of a specified patch file. The patch file used in this operation uses the contextual diff format. The file generated from a ‘show | compare | save‘ operation creates such a file.
• replace – Looks for a replace tag in the configuration you load. The software replaces existing statements of the same name with those in the loaded configuration for stanzas1 marked with the replace tag.
• set – Allows users to load set commands from the terminal or from a saved file that consists of set configuration statements.
• update – Updates the existing configuration with the configuration you load. When using the update option, the Junos OS attempts to tell only those processes affected by the configuration changes. When the override option is used, the Junos OS makes no such attempt. You can use the update option from any hierarchy, but you can use the override option only from the top level hierarchy.
• terminal – Uses the text you type at the terminal as input to the configuration. Type Ctrl+d to end terminal input. This option is usually used in conjunction with a terminal emulation program’s copy-and-paste functionality to copy and paste configuration data from one system to another.
• relative – Normally, a ‘load merge‘ or ‘load replace‘ operation requires that the data you load contains a full path to the related configuration hierarchy. The relative option negates this need by telling the device to add the data you load relative to the current configuration hierarchy.

I use ‘load patch‘ and ‘load set‘ most often. Load patch is a great shortcut when manually adding the same changes to more than one device. You just configure the first one, issue a ‘show | compare‘, and then copy that to all the remaining devices using ‘load patch terminal‘. Use ‘load set‘ when pre-staging larger configuration changes and is also great for using with basic configuration scripts, but that’s a whole different blog post!

Configuration Groups

One more handy trick to make configuring Junos devices more efficient is configuration groups. Use configuration groups to apply repetitive chunks of configuration. This is often super helpful for interfaces, or anywhere else you find yourself using the same configuration statements over and over. An added benefit to using configuration groups is that it makes changing those statements easier too. For example, you may want to configure all of your 1G interfaces for an MTU of 1524. If you do this manually and later want to increase the MTU, you may have to manually change every interface. If you had used a configuration group, you could just change the group config and all associated interfaces would be automatically updated.

Commit

In Junos, you have to ‘commit‘ your configuration changes before they become active. This fact alone provides a lot of peace of mind and flexibility when working on the CLI, but did you know that the commit command provides more options? Here’s a few that are often useful:

• commit check – This command does not activate your configuration changes, but it does validate them. I use this command, along with ‘show | compare‘ every time I make changes. The combination greatly lowers the risk of making ignorant mistakes.
• commit confirmed – The holy grail of CLI life savers. When you issue ‘commit confirmed‘ on a Junos device, your configuration changes are activated, but with a timer. By default the timer is set for 10 minutes. If you do not confirm your commit (by issuing ‘commit‘ again) before the timer runs out they are undone. This is a great fail safe against locking yourself out of a device – if you lose connectivity, the device “rolls back” your changes on its own.
• commit at – Use this command to schedule the activation of your changes. You can specify a timer, a specific date and time, or at the next reboot. This is handy for synchronizing changes on multiple devices.
• commit comment – Sometimes you need to annotate your changes, this command lets you.

Configuration Files

The last bit of Junos magic we’ll look at regarding configuration is a few tricks relating to whole configuration files.

• rollback – Junos automatically saves the previous version of your configuration every time you issue a ‘commit‘. Juniper devices save a maximum of 50 configuration files, including the currently active config. You can use the ‘rollback‘ command to load a previous version of the configuration (or to view a diff using ‘| compare‘, as discussed above).
• rescue configuration – You can define a “rescue” configuration as a fail safe. It is an additional configuration file saved by Junos that can be loaded with the ‘rollback rescue‘ command. This configuration should have basic network connectivity covered, and is required to have a root password. Use ‘request system configuration rescue save‘ to create or update the rescue config.
• automated configuration backup – You can use the ‘transfer-interval‘ or ‘transfer-on-commit‘ commands to store a copy of your Junos device’s config on a separate device. This is a solid hedge against storage failure and/or can be used as part of a more comprehensive configuration management scheme.

Troubleshooting

The final couple of items that jumped out at me in the JNCIA-Junos study guides are related to troubleshooting:

• traceoptions – “Tracing is the Junos term for what other vendors sometimes call debug. In most cases, when you enable tracing (through configuration), you create a trace file that is used to store decoded protocol information received or sent by the routing engine.” Tracing works with most (if not all) protocols and is an invaluable tool for more advanced troubleshooting.
• monitor traffic – This command basically provides an on-box traffic capture. It gives you access to the tcpdump utility. Direct it at a specific interface with ‘monitor traffic interface <interface>‘ and be sure to check out the other command options.

WARNING: Both traceoptions and monitor traffic commands can be very resource intensive and should be used with caution. You never want your troubleshooting efforts to cause more harm!

JNCIA-Junos

In case it wasn’t clear, this post is not meant to be a replacement for any recommended exam preparation. The above are just a few tips that I thought would be useful for lots of folks using Junos. If you plan to pursue a JNCIA-Junos certification I urge you to read the study guides, attend the recommended classes, or both.

---

Did you find this post helpful? Don’t forget to share it with your colleagues!