O'Reilly logo

JUNOS Cookbook by Aviva Garrett

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 1. Router Configuration and File Management

Introduction

Juniper Networks routers are specialized network devices that run network operating system software, which is called JUNOS software. In this book, we talk about JUNOS features that run on the J-series, M-series, and T-series router platforms. The M-series and T-series platforms are larger routers typically used by network service providers, telephone companies, large enterprise companies, and universities. The J-series routers are smaller routers designed for use by businesses and other organizations to connect multiple sites or to connect to the Internet. The JUNOS software is pre-installed on a new Juniper Networks routers: when you turn the router on, the software automatically starts running. The first task you have to perform is configuring the router.

JUNOS software is distributed as a set of modular software packages that contain the various components of the software. A given JUNOS software release runs on all J-series, M-series, and T-series routers. The examples in this book are based on the JUNOS 7.4 release of the software on either M20 routers or J2300 routers, but all are applicable for the most recent JUNOS releases and for future releases on the M-, T-, and J-series families of routers.

This chapter discusses basic router configuration, including how to configure the router for the first time, configuring from the command-line interface ( CLI), loading and saving configuration files, and working with the filesystems and files used by the JUNOS software. It also discusses how to upgrade the JUNOS software and how to gather hardware and software inventory information.

When you first start a router, you must configure basic network information, such as the router name, IP address, and domain name, so that the router is reachable on the network. You then configure the desired software features. To configure the router, you generally log in to the router and use the JUNOS CLI. Some routers, including the J-series, also have a web-based interface called J-Web. From the CLI, you specify the configuration in a plain-text (ASCII) configuration file, which you can read from the CLI (on the router) or by using any ASCII text editor (on a server). From J-Web, the configuration is saved in an ASCII file that you can read using J-Web, the CLI, or an ASCII text editor.

JUNOS CLI Modes

Throughout this book, we’ll show you how to use the JUNOS CLI to configure and monitor the router. While it is beyond the scope of this book to describe the design of the CLI and all its capabilities, this section gives an overview of the CLI modes and describes a few of the basic features. Throughout the rest of this chapter, we’ll give more examples of CLI features. For complete information about the JUNOS CLI, refer to the JUNOS product documentation on the Juniper Networks web site, http://www.juniper.net/techpubs.

The underlying operating system for the JUNOS software is FreeBSD. As we talk about the various CLI commands, if a command is derived from FreeBSD or a standard Unix utility, or is simply the FreeBSD or Unix command packaged with a JUNOS name, we will mention the command it is based on. If you are already familiar with the FreeBSD or Unix equivalent, this will help you understand the JUNOS command.

The CLI has two modes: operational mode and configuration mode. Both modes have distinct commands. In operational mode, you monitor everything about the router’s hardware and software and check on network operation. In configuration mode, the commands let you define the behavior of the router, such as indicating what network addresses to use and protocols to run. It is important for you to understand the differences between these two modes, what types of actions you can take in which mode, and how to keep track of which mode you are working in. Throughout the rest of this book, we’ll show you how to work in both modes as you configure the router and verify its operation.

On the router, you can identify which mode you are in by looking at the CLI prompt. The base prompt has the format . When you are in operational mode, the prompt ends with a >; when you are in configuration mode, the prompt ends with a #. We follow this same convention throughout this book, so by paying attention to the prompt that precedes each command, you can determine whether you issue the command in operational or configuration mode.

When you first log in to a JUNOS router, you are in operational mode. The commands available in operational mode let you monitor router and network operations. For example, you can get information about the router’s hardware and software, the network traffic that is coming to the router, and configured routing protocols. Throughout this book, we’ll show you how to use operational mode commands to check what is happening on the router.

You can use a number of operational mode commands, grouped together into related commands, to monitor your router and network. On the router, you can find out what the commands are by typing a question mark ( ?) to activate the online help. If you type a ? at the top level of operational mode, you see the broad types of commands you can use to monitor the router and perform operations not related to configuring the router:

	aviva@router1> ?
	Possible completions:
	   
clear                Clear  information in the system 	   
configure            Manipulate software configuration information  
file                 Perform file operations
help                 Provide help information
monitor              Show real-time debugging information  
mtrace               Trace multicast path from source to receiver
ping                 Ping remote target   
quit                 Exit the management session    
request              Make system-level requests    
restart              Restart software process  
set                  Set CLI properties, date/time, craft interface message
show                 Show system information   
ssh                  Start secure shell on another host
start                Start shell  
telnet               Telnet to another host  
test                 Perform diagnostic debugging
traceroute           Trace route to remote host

For example, you use the various show commands to display information about the router, router interfaces, and protocol software, and you use the various request commands to perform operations on the router, such as rebooting and downloading and installing software upgrades.

Two commands in operational mode are not designed to monitor the router or the network:

quit

Use to log out of the CLI and the router

configure

Use to enter configuration mode so you can configure the router

When you enter configuration mode, the prompt changes from to , and a line before the prompt, [ edit], indicates that you are in configuration mode. Specifically, [edit] indicates that you are at the top of the configuration hierarchy, which is similar to being at the top of a Unix filesystem (/). A synonym for the configure command is edit. (edit is a hidden command, so you won’t see it in the list of possible completions.)

Configuration mode has two basic components:

commands

Use to perform actions within the router’s configuration

statements

The actual keywords that define the configuration

To create or modify the router’s configuration, use the commands that are available in configuration mode to add statements to the configuration that define the behavior of the router. If you type a ? at the top level of configuration mode, you see the broad types of commands you can use while configuring the router:

	[edit]
	aviva@router1# ?
	Possible completions:
	  <[Enter]>      Execute this command
	  activate             Remove the inactive tag from a statement
	  annotate             Annotate the statement with a comment
	  commit               Commit current set of changes
	  copy                 Copy a statement
	  deactivate           Add the inactive tag to a statement
	  delete               Delete a data element
	  edit                 Edit a sub-element
	  exit                 Exit from this level
	  help                 Provide help information
	  insert               Insert a new ordered data element
	  load                 Load configuration from ASCII file
	  quit                 Quit from this level
	  rename               Rename a statement
	  rollback             Roll back to previous committed configuration
	  run                  Run an operational-mode command
	  save                 Save configuration to ASCII file
	  set                  Set a parameter
	  show                 Show a parameter
	  status               Show users currently editing configuration
	  top                  Exit to top level of configuration   
	  up	               Exit one level of configuration
	  wildcard             Wildcard operations

When creating or modifying a configuration, you primarily use the edit and set commands to control which configuration statement to include. Use the edit command to move to the portion of the configuration you want to modify (this is similar to using the Unix cd command to move to a different directory) and use the set command to configure a specific item. The up command moves up one hierarchy level, and the top command returns to the top of the hierarchy, [edit] (this command is similar to the Unix cd / command). At the top level, use the exit or quit command to return to operational mode.

The show command displays the items in the configuration, starting at the current hierarchy level. If you start at the [edit] level, you see the entire configuration:

	[edit]
	aviva@router1# show
	version "7.4R1.7";
	groups  
{
	    re0 {
	        system {
	            host-name router1;
	        }
	        interfaces {
	            fxp0 {
	                unit 0 {
	                    family inet {
	…

If you are at a lower level, you see just that portion of the configuration. The following example starts in the OSPF portion of the configuration:

	[edit protocols ospf]
	aviva@router1# show
	export export-statics;
	area 0.0.0.0 {
	    interface fe-0/0/1.0;
	    interface fe-1/0/1.0;
	}

Why are there curly braces here? The JUNOS software uses curly braces to represent the structure of the configuration file, delineating related sections of configuration parameters. If you are a C-language programmer, you will be very familiar with them.

The opposite of the set command is delete, which removes an item from the configuration. You can delete an individual item from the configuration (such as delete interface fe-1/0/1.0 from the OSPF configuration above), or you can delete an entire section—here the area 0.0.0.0 section from the OSPF configuration:

	[edit protocols ospf]
	aviva@router1# delete area 0.0.0.0
	aviva@router1# show
	export export-statics;

Another time-saving command is run, which allows you to issue an operational command from within configuration mode. For example, the run show route command from configuration mode is the same as the show route command from operational mode:

	[edit]
	aviva@router1# run show route <-- # in prompt indicates configuration mode
	inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0          *[Static/5] 07:36:18
	                      Discard
	…
	aviva@router> show route <-- > in prompt indicates operational mode
	inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
	+ = Active Route, - = Last Active, * = Both

	0.0.0.0/0          *[Static/5] 07:36:18
	                      Discard
	…

What does it mean to move to a portion of the configuration? You can think of the JUNOS configuration as a hierarchy of configuration statements and containers, delimited by braces ({}) that define the scope in which those statements apply. This hierarchy provides a way to organize the large number of features and functions that you can configure on the router, grouping related functions together so that you can locate them when configuring the router and when reviewing the configuration. When you first enter configuration mode, you are at the top of the hierarchy. You see your location in the hierarchy in the line that precedes the configuration mode prompt. The line [edit] indicates that you are at the top of the hierarchy. The edit command allows you to move within the configuration hierarchy so that all configuration commands take place within the current container. As you move through the hierarchy, the text in square brackets changes to indicate your location in the hierarchy.

The configuration statements that you use to set the router’s behavior are also arranged in a hierarchical fashion. If you type edit ? at the top level of the configuration hierarchy, you see the broad functional JUNOS software areas that you can control through the configuration:

	[edit]
	aviva@router1# edit ?
	Possible completions:
	> access            Network access configuration
	>                   accounting-options Accounting data configuration
	>                   applications Define applications by protocol characteristics
	>                   chassis Chassis configuration
	>                   class-of-service Class-of-service configuration
	>                   firewall Define a firewall configuration
	>                   forwarding-options Configure options to control packet sampling
	>                   groups Configuration groups
	>                   interfaces Interface configuration
	>                   logical-routers Logical routers
	>                   policy-options Routing policy option configuration
	>                   protocols Routing protocol configuration
	>                   routing-instances Routing instance configuration
	>                   routing-options Protocol-independent routing option configuration
	>                   security Security configuration
	>                   services Service PIC applications settings
	>                   snmp Simple Network Management Protocol configuration
	>                   system System parameters

Each listed completion is the configuration statement at the top of a particular configuration hierarchy. For example, the statement protocols is at the top of the hierarchy in which you configure all JUNOS routing protocols:

	[edit]
	aviva@router1# edit protocols  
?
	Possible completions:
	  <[Enter]>            Execute this  command
	> bfd                  Bidirectional Forwarding Detection (BFD) options
	> bgp                  BGP options
	> connections          Circuit cross-connect configuration
	> dvmrp                DVMRP options
	> igmp                 IGMP options
	> isis                 IS-IS options
	> l2circuit            Configuration for Layer 2 circuits over MPLS
	> ldp                  LDP options
	> link-management      LMP options
	> mld                  MLD options
	> mpls                 Multiprotocol Label Switching options
	> msdp                 MSDP configuration
	> ospf                 OSPF configuration
	> ospf3                OSPFv3 configuration
	> pgm                  PGM options
	> pim                  PIM configuration
	> rip                  RIP options
	> ripng                RIPng options
	> router-advertisement IPv6 router advertisement options
	> router-discovery     ICMP router discovery options
	> rsvp                 RSVP options
	> sap                  Session Advertisement Protocol options
	> vrrp                 VRRP options
	  |                    Pipe through a command

If you move down through the hierarchy—for example, into the protocols portion—the prompt changes to [edit protocols] to show you where you are:

	[edit]
	aviva@router1# edit protocols
	[edit protocols]
	aviva@router1#

Learning About the CLI While on the Router

In some of the command lines in the previous section, we showed how to use the ? to get context-sensitive help about the CLI and the software. This feature is part of the CLI’s built-in help, and you will find yourself using it regularly. When you type a ? at a prompt, the CLI shows a list of commands or statements you can use, along with a short description of the command or statement. If you partially type a command or configuration statement name and then type a ?, you see a subset of the available commands or statements.

For example, in operational mode, you can find a subset of the show commands:

	aviva@router1> show r?
	Possible completions:
	  rip                   Show Routing Information Protocol information
	  ripng                 Show Routing Information Protocol for IPv6 information
	  route                 Show routing table information
	  rsvp                  Show Resource Reservation Protocol information
	aviva@router1> show r

The CLI displays the list of available commands and then redisplays the portion of the command you already typed so you do not have to retype it. For example, to show the contents of the routing table, you would now just type oute:

	aviva@router1> show r?
	Possible completions:
	  rip                   Show Routing Information Protocol information
	  ripng                 Show Routing Information Protocol for IPv6 information
	  route                 Show routing table information
	  rsvp                  Show Resource Reservation Protocol information
	aviva@router1> show r
	aviva@router1> show route

In configuration mode, you can list the subset of available configuration statements:

	[edit system]
	aviva@router1# set s?
	Possible completions:
	  saved-core-context     Save context information for core files
	  saved-core-files       Number of saved core files per executable (1..64)
	> services            System services
	> static-host-mapping Static hostname database mapping
	> syslog              System logging facility
	aviva@router1# set s^

To minimize the amount of typing you have to do, press the spacebar or Tab key to have the CLI complete a nonambiguous command or statement name. This is similar to how some Unix shells operate.

	aviva@router1# commit a<space>
	Possible completions:
	  and-quit               Quit configuration mode if commit succeeds
	  at                     Time at which to activate configuration changes
	aviva@router1# commit an<space>
	aviva@router1# command and-quit

The first command above is ambiguous because there are two possible completions. The second command is unique, so when you press the spacebar key (or Tab key), the CLI automatically completes the command. Press the Enter key to execute the command.

After you have typed a complete command (but before pressing Enter), another set of commands becomes available to allow you to control the format of the output. To access these commands, you first type a | (pipe), which directs the output from the command on the left side of the pipe into the command on the right side of the pipe, in exactly the same way that a Unix pipe works. The following commands are available:

	aviva@router1> show route | ?
	Possible completions:
	  count                Count occurrences
	  display              Show additional kinds of information
	  except               Show only text that does not match a pattern
	  find                 Search for first occurrence of pattern
	  hold                 Hold text without exiting the --More-- prompt
	  last                 Display end of output only
	  match                Show only text that matches a pattern
	  no-more              Don't paginate output
	  request              Make system-level requests
	  resolve              Resolve IP addresses
	  save                 Save output text to file
	  trim                 Trim specified number of columns from start of line

Another way to minimize typing is to use keyboard sequences. The simplest are the up and down arrows, which scroll through the most recent commands you typed. (The JUNOS software maintains a command history similar to Unix shell history.) If you want to modify rather than retype a command, you can use the left and right arrows and the Backspace and Delete keys. There are also a number of keyboard sequences that are similar or identical to Emacs commands that you can use to move around on a command line and edit it. Table 1-1 lists some common keystrokes.

Table 1-1. Keystroke sequences

Keystroke sequence

Action

Ctrl-p

Display previous command history line

Ctrl-n

Display next command history line

Ctrl-a

Move to beginning of line

Ctrl-e

Move to end of line

Ctrl-b

Move back one character

Ctrl-f

Move forward one character

Esc-b

Move back one word

Esc-f

Move forward one word

Ctrl-k

Delete everything from cursor to end of line

Esc-d

Delete one word forward (the word after the cursor)

Esc-Backspace

Delete one word backward (the word before the cursor)

Ctrl-y

Paste the deleted word or text at the cursor

Another aspect of the CLI help is online documentation, which is installed on the router’s hard disk. This documentation is taken from the JUNOS product configuration guides. You can use the online documentation to get information about configuration statements while you are logged in to the router. To get high-level information about a configuration statement, you can use the help topic command. The following example shows how to get high-level help about configuring the domain name on the router:

	aviva@router1> help topic system domain-name
	Configuring the Router's Domain Name
	   For each router, you should configure the name of the domain in which the
	   router is located. This is the default domain name that is appended to
	   hostnames that are not fully qualified. To configure the domain name,
	   include the domain-name statement at the [edit system] hierarchy level:
	     [edit system]
	     domain-name domain-name;
	Example: Configuring the Router's Domain Name
	 Configure the router's domain name:
	   [edit]
	   user@host# set system domain-name company.net
	   [edit]
	   user@host# show
	   system {
	       domain-name company.net;
	   }

Use the help reference command to get help about the syntax and options of a configuration statement, similar to Unix manpages. The following shows the reference help that is displayed for the domain-name configuration statement:

	aviva@router1> help reference system domain-name
	domain-name
	 Syntax
	  domain-name domain-name;
	 Hierarchy Level
	  [edit system]
	 Description
	  Configure the name of the domain in which the router is located. This is
	  the default domain name that is appended to hostnames that are not fully
	  qualified.
	 Options
	  domain-name--Name of the domain.
	 Usage Guidelines
	  See "Configuring the Router's Domain Name".
	 Required Privilege Level
	  system--To view this statement in the configuration.
	  system-control--To add this statement to the configuration.

How We Show Commands and Configurations in This Book

In the explanation of the JUNOS CLI so far, we have described the different types of commands and illustrated what they look like when you type them on the router. Because it can be a bit confusing for newcomers, this section summarizes how we show the commands in this book.

Here is an operational mode command:

	aviva@router1> show route table inet.0

The > tells you that you are in operational mode, and the bold font shows what you type. The command is show route. The word table is an option for this command, and inet.0 is a variable (the name of a specific routing table) that is required to complete the table option. The table name is italicized because you can substitute the desired routing-table name.

Here are two configuration mode commands:

	[edit]
	aviva@router1 
# edit system
	[edit system]
	aviva@router1#  
set login user aviva class operator

You know you are in configuration mode because of the # after the prompt and because the CLI shows your location in the hierarchy of configuration statements by displaying the [edit] and [edit system] lines. edit and set are configuration mode commands. system, login, user, and class are configuration statements. aviva is a variable required for the user statement, and operator is an option required for the class statement. Again, what you type is shown in bold. The commands and statements, which you have to type exactly as shown, are in bold, and the variables, which you substitute with the proper values for your network, are italicized.

In this book, when we show how to configure the router, we generally show just the commands that you type and the configuration hierarchy level at which you type them, as shown above. Sometimes, however, if you have to type several commands to configure a feature or if you type a command that results in a multilevel hierarchy, we’ll show you what the resulting configuration looks like. The configuration commands that we typed above result in the following configuration:

	[edit system]
	aviva@router1# show
	login {
	    user aviva {
	        class operator;
	    }
	}

When viewed from the top level of the statement hierarchy, it looks like this:

	[edit]
	aviva@router1# show
	system {
	    login {
	        user aviva {
	            class operator;
	        }
	    }
	}

We show this format for a couple of reasons. When you are on the router and configuring it, you might get lost or forget what you have already configured. The text in square brackets above the prompt (here, [edit]) is your road map to your location in the configuration statement hierarchy, and the show command displays what’s already in the configuration. Another reason is that a JUNOS configuration is, in reality, just a text file. The format of the file is the same as what you see when you type the show command. The indentions indicate the configuration hierarchy levels, the curly braces ({ and }) indicate related groups of configuration statements, and a semicolon marks the end of an individual statement. In the book, we’ll sometimes use this format as a way to summarize all the statements you need to include to configure a particular feature. You can compare what’s in the book with what you have configured on the router to make sure that you have included everything.

1.1. Configuring the Router for the First Time

Problem

You have just installed and turned on a router and are configuring the JUNOS software for the first time.

Solution

Use the following commands to configure the router:

	root# cli
	root@>
	cli> configure
	[edit]
	root@# set system host-name router1
	root@# set system domain-name mynetwork.com
	root@# set interfaces fxp0 unit 0 family inet address 192.168.15.1/24
	root@# set system backup-router 192.168.15.2
	root@# set system name-server 192.168.15.3
	root@# set system root-authentication plain-text-password
	New password:
	Retype password:
	root@ show
	system {
	    host-name router1 
;
	    domain-name mynetwork.com;
	    backup-router 192.168.15.2;
	    root-authentication {
	         encrypted-password "$1$ZUlES4dp$OUwWo1g7cLoV/aMWpHUnC/"; ## SECRET-DATA;
	    }
	    name-server {
	         192.168.15.3;
	}
	interfaces {
	    fxp0 {
	        unit 0 {
	            family inet {
	                address 192.168.15.1/24;
	            }
	        }
	    }
	}
	root@# commit
	root@router1# exit
	root@router1>

Discussion

On most JUNOS routers, the JUNOS software is installed in two places: the flash drive and the hard disk. When you first turn on the router, it runs the version of the software that is installed on the flash drive. The copy on the hard disk is a backup. Another backup copy of the software is provided on removable media, typically a PC card or a compact Flash card.

When you turn on your router for the first time, the JUNOS software automatically boots and starts. On some routers, a script prompts you for basic information about the router. On other routers, you use the J-Web browser to perform the initial configuration. At this point, you need to enter enough basic configuration information so that the router can be on the network and others can log in over the network. To work on the router to perform the initial configuration, you need to connect a terminal or laptop computer to the router through the console port, which is a serial port on the front of the router.

When you first connect to the router’s console, you must log in as the user root. The root user is similar to the Unix superuser and has complete access to all functions on the router. Initially, the root account has no password. You can see that you are root because the prompt on the router shows the username root#. Start the JUNOS CLI using the command cli. The prompt root@> shows that you are the user root and that you are in operational mode. Once you have started the CLI, type the command configure to enter configuration mode. The prompt root@# indicates that you are now in configuration mode. If you look at the end of the previous example, you see that after you have activated the configuration with the commit command, the hostname that you configured is added to the end of the prompt, so the prompts become root@ router1# in configuration mode and root@ router1> in operational mode.

When you first configure the router, you set a number of basic properties for the router:

  • Name of the router (the router’s hostname), with the set system host-name command.

  • Your domain name, with the set system domain command.

  • IP address of the router’s fxp0 interface, with the set interfaces fxp0 command. fxp0 is an Ethernet management interface that provides a separate out-of-band management network on the router. (The J-series routers do not have a dedicated management interface. You use one of the built-in Fast Ethernet interfaces, fe-0/0/0 or fe-0/0/1, instead.) Juniper Networks recommends that you manage all M-series and T-series routers using the fxp0 interface, which is reserved for managing the router, so no traffic is forwarded through it. As part of the physical setup for the router, you should connect fxp0 to an Ethernet network over which you can perform management tasks. Optimally, the router should also be able to reach its DNS and NTP servers through this network. If you prefer, you can use any other interface router as a management interface. For the remainder of this book, we assume that fxp0 (or fe-0/0/0 on J-series routers) is configured as the management interface.

  • IP address of a backup router, with the set system backup-router command. Choose a router that is directly connected to the local router. Your router uses this backup router only when it is booting and only if the JUNOS routing software (called the routing protocol process, or RPD) does not start. If RPD does not start, the router will have no static or default routes, so you will not be able to access it directly but will have to go through the backup router. When the router is booting, it creates a static route to the backup router. This route is removed from the routing table as soon as the routing software starts.

    For routers with two Routing Engines, the backup Routing Engine, RE1, still uses the backup router as a default gateway after the router has booted, so you can use the backup router to log in to RE1.(RE0 is the primary, or master, Routing Engine. See Recipe 1.30.)

  • IP address of one or more DNS name servers on your network, with the set system name-server command. The router uses the DNS name server to translate hostnames into IP addresses.

  • Password for the root account. When you initially start a new router, the root account has no password. To protect the security of the router and your network, it is critical that you configure a root password. The easiest way to configure this is by entering a plain-text (ASCII) password using the plain-text-password statement to configure a password. After you press Enter, the CLI prompts you for the password and then asks you to retype it but does not display what you type. The password you use cannot be all lowercase letters, all uppercase letters, or all numbers. There must be a mixture of cases, letters, digits, and punctuation. If you choose a password that doesn’t meet these criteria, you see an error message:

    	error: require change of case, digits or punctuation

    When you display the password with the show command, the CLI never shows the actual text that you type. It immediately encrypts the password string using MD5 and displays the encrypted version in the show command output. The section “Strategies for Choosing Passwords” in the Introduction to Chapter 2 discusses ways to choose secure passwords. Recipe 2.2 explains how to use SSH authentication for the root user.

For the initial router configuration to take effect—and in fact for any router configuration or configuration changes to take effect—you use the commit command. This command verifies that there are no syntax errors in the configuration and then activates it.

	root@# commit
	root@router1#

It’s worthwhile to take a moment to comment on the style you use to type configuration statements on JUNOS routers. In this recipe, you are at the [edit] configuration hierarchy level, which is the very top level of the hierarchy, so you have to type the full hierarchy to the statement as well as the statement itself. This hierarchy is fairly shallow, so there is not too much extra typing. When you are working in deeper hierarchies, you may find it easier to move to that hierarchy level, both so you have less typing to do and have a better sense of where you are in the configuration. For this recipe, you could type most of the configuration commands from the [edit system] hierarchy level:

	root# cli
	root@>
	cli> configure
	[edit]
	root@# edit system
	[edit system]
	root@# set host-name router1
	root@# set domain-name mynetwork.com
	root@# set backup-router 192.168.15.2
	root@# set name-server 192.168.15.3
	root@# set root-authentication plain-text-password
	New password: $123poppI
	Retype password: $123poppI

Then when you use the show command, you see only the statements at the [edit system] level:

	[edit system]
	root@#show
	host-name router1;
	domain-name mynetwork.com;
	backup-router 192.168.15.2;
	root-authentication {
	    encrypted-password "$1$ZUlES4dp$OUwWo1g7cLoV/aMWpHUnC/"; ## SECRET-DATA;
	}
	name-server {
	     192.168.15.3;
	}

In portions of the configuration where you are using the same configuration command repeatedly with only minor variations, it is handy to use the keystroke sequences listed in Table 1-1.

While the configuration shown in this recipe provides the minimum needed to access the router from another system on the network, you should add a few other settings to the configuration to provide a more robust level of basic network connectivity:

	[edit]
	root@router1#  
set system ntp server 192.168.2.100
	root@router1# set system time-zone America/Los_Angeles
	root@router1#  
set system services ssh
	root@router1# set interfaces lo0 unit 0 family inet address 207.17.139.42/32
	root@router1# set system login user aviva class superuser
	root@router1# set system log user aviva authentication plain-text-password
	New password:
	Retype new password:
	root@router1# commit

The first command, set system ntp server, configures the IP address of an NTP server so that the router can set its time properly. Because we have already configured DNS on the router, you could specify the name of the time server instead of an IP address and it will be translated to an IP address. To have the router obtain accurate time from the servers, it is good practice to configure a minimum of four NTP servers. You can also optionally configure the time zone in which the router is located (see Recipe 6.2); by default, the time zone is UTC.

To be able to log in to the router over the network using SSH, enable SSH services on the router with the set system services ssh command. For this to work, SSH must also be configured on the network servers. SSH is also used to copy files to and from the router.(The JUNOS SSH uses the Unix scp command.) Note that you can also copy files with FTP or HTTP (see Recipe 2.1), but these are less secure than SSH. On routers with two Routing Engines, you can copy files between the two (see Recipe 1.30).

The set interfaces command sets the router’s IP address by configuring an address on the loopback interface (see Recipe 7.3). The last two commands set up a non-root user account so an individual user can log in to the router (see Recipe 2.5).

If your router has two Routing Engines, you also need to configure a hostname and IP address for the second Routing Engine (see Recipe 1.30).

Again, issue the commit command for the configuration changes to take effect:

	root@router1# commit

Recipes 1.7, 1.15, and 1.16 explain how the commit operation works, including how to provisionally commit configuration changes.

At this point, you are logged in to the router as the user root, so you have complete control over the router. As root, you can perform operational actions that shut down the router or make it inaccessible to the network. While there are times when you want to legitimately perform these types of operations, you generally want to make sure that the router continues to operate normally, and you want to minimize the chance of accidentally interfering with the router’s operation.

At this point in configuring the router, you should either load an existing router configuration file, as described in Recipe 1.12, or add user accounts to the configuration (see Recipe 2.5), including one for yourself, and then log out and log back in to the router using your user ID.

See Also

Recipes 1.7, 1.12, 1.15, 1.16, 1.17, 1.30, 2.1, 2.2, 2.5, 6.2, and 7.3

1.2. Configuring the Router from the CLI

Problem

You need to modify the router’s configuration using the JUNOS CLI.

Solution

You need to be in configuration mode to configure the router:

	aviva@router1> configure
	Entering configuration mode
	[edit]
	aviva@router1#

Discussion

When you want to modify the router’s configuration, log in to the router, enter configuration mode as shown in this example, and then create a hierarchy of configuration statements that define the desired router operation. There are other ways to configure the router, which are discussed later in the chapter, including loading a configuration file from a remote server or from the local router and loading a previous router configuration.

When you want the configuration to take effect, you must activate, or commit, it.

See Also

Recipe 1.7

1.3. Getting Exclusive Access to Configure the Router

Problem

More than one person can log in to the router and modify the configuration at one time; you want to prevent someone from overwriting your configuration changes.

Solution

Use the following version of the configure command to enter configuration mode:

	aviva@router1> configure  
exclusive
	warning: uncommitted changes will be discarded on exit
	Entering configuration mode
	[edit]
	aviva@router1#

Discussion

Because more than one person can log in to the router at the same time, several people may be modifying the configuration simultaneously. You will know that another person is editing the configuration when you enter configuration mode:

	aviva@router1> configure
	Entering configuration mode
	Users currently editing the configuration:
	    mike terminal p3 (pid 1088) on since 2005-02-30 19:47:58 PST, idle 00:00:44
	[edit]
	aviva@router1#

Here you can see that mike is also logged in, is working in configuration mode, and has not typed anything for 44 seconds. However, if someone enters configuration mode after you do, the CLI does not display any message, so you will not be notified. Instead, you need to check:

	[edit]
	aviva@router1#  
status
	Users currently editing the configuration:
	  aviva terminal p0 (pid 3358) on since 2005-06-09 11:22:18 PDT
	      [edit]
	  mike terminal p1 (pid 3768) on since 2005-06-09 11:48:31 PDT
	      [edit]

If you need to ensure that no one else can change the configuration while you are modifying it, use the configure exclusive command to enter configuration mode. With this option, no other users can change the configuration as long as you are in configuration mode. If you do not commit the changes you make, they are lost when you exit from configuration mode.

If another user has locked the configuration, you can forcibly log him out:

	aviva@router1> request system logout user mike

You get the username from the message displayed when you enter configuration mode or from the status command.

1.4. Displaying the Commands to Recreate a Configuration

Problem

You have a copy of a JUNOS router configuration or you need to duplicate a router configuration on another router and you want to know the commands to use to create the configuration.

Solution

Use the following command to list the commands for creating a configuration:

	[edit]
	aviva@RouterA# show |  
display set

Discussion

The show | display set command is a handy way to reverse-engineer a router configuration when you are trying to duplicate portions of a configuration on many routers or when you need to write up configuration, monitoring, or troubleshooting procedures for your network operations staff. This command is especially useful if the configuration is complex and when setting it up involves many long commands and lots of typing.

When you pipe the output of the configuration mode show command into the display set command, the JUNOS CLI prints a list of the commands you need to issue from that hierarchy level to create the existing configuration. When you use the command at the top level of the configuration (at the [edit] level), the CLI shows all the commands necessary to configure the router, which for most routers is a lot of commands. By way of illustration, here’s a sample of the output for four interfaces on the router from the [edit interfaces] level:

	[edit interfaces]
	aviva@RouterA# show | display set
	set interfaces fe-0/0/1 unit 0 family inet address 10.0.15.2/24
	set interfaces se-0/0/2 unit 0 family inet address 10.0.21.1/24
	set interfaces se-0/0/3 serial-options clocking-mode dce
	set interfaces se-0/0/3 unit 0 family inet address 10.0.16.1/24
	set interfaces lo0 unit 0 family inet address 192.168.13.1/32

You can cut and paste these commands individually or all at once. They produce the following configuration:

	[edit interfaces]
	aviva@RouterA# show
	fe-0/0/1 {
	    unit 0 {
	        family inet {
	            address 10.0.15.2/24;
	        }
	    }
	}
	se-0/0/2 {
	    unit 0 {
	         family inet {
	             address 10.0.21.1/24;
	         }
	    }
	}
	se-0/0/3 {
	    serial-options {
	        clocking-mode dce;
	    }
	    unit 0 {
	         family inet {
	              address 10.0.16.1/24;
	         }
	    }
	}
	lo0 {
	    unit 0 {
	         family inet {
	              address 192.168.13.1/32;
	         }
	    }
	}

See Also

Recipe 1.13

1.5. Including Comments in the Configuration

Problem

You want to add comments to the router configuration file to help other people reading the file understand how the router is configured.

Solution

Use the annotate command to add a comment:

	[edit protocols ospf]
	aviva@router1# set area 0.0.0.0 interface fe-0/0/0
	aviva@router1# annotate area 0.0.0.0 "backbone routers"
	aviva@router1# show
	/* backbone routers */
	area 0.0.0.0 {
	     interface fe-0/0/0.0;
	}

Discussion

It is generally good practice to include comments in the configuration to clarify what is included for others who read the configuration. You can add comments for statements at the current hierarchy level in the configuration. In this recipe, we add a comment for the area statement at the [edit protocols ospf] level. The comment appears immediately before the statement.

To delete a comment, use the annotate command with an empty string:

	[edit protocols ospf]
	aviva@router1# annotate area 0.0.0.0 ""

1.6. Checking the Syntax of the Configuration

Problem

You want to check the syntax of your configuration to make sure there are no errors or missing statements.

Solution

Check the syntax of the configuration:

	[edit]
	aviva@router1# commit check
	configuration check succeeds
	[edit]
	aviva@router1#

Discussion

As you are configuring the router, if you mistype a JUNOS configuration statement or command, the CLI gives you immediate feedback and pesters you until you type it correctly. However, this does not guarantee that you have spelled all variable names correctly or that you haven’t omitted any required statements. Use the commit check command from time to time to check the syntax of the configuration. This command only checks the syntax; it does not activate the configuration.

If the syntax has no errors, you see the message configuration check succeeds.

If you have made any mistakes in the configuration, a message reports where in the configuration hierarchy the mistake is and describes the problem. The following example shows that a RIP neighbor router has been incorrectly configured in two RIP groups:

	[edit]
	aviva@router1# commit check
	[edit protocols rip group alpha-rip-group]
	  'neighbor fe-0/0/0.0'
	     Failed to configure neighbor fe-0/0/0.0: already in group alpha-rip-group
	error: configuration check-out failed

This is a mistake because a RIP neighbor can be in only one group. You can see from the output that the mistake is at the [edit protocols rip group alpha-rip-group] hierarchy level of the configuration.

Even if the syntax of the configuration is correct, that is no guarantee that the configuration will work as expected.

1.7. Activating the Router Configuration

Problem

You have created or modified the router’s configuration using the CLI and you want to put the configuration into effect.

Solution

Use the following command to activate a router configuration:

	[edit]
	aviva@router1# commit
	commit complete
	[edit]
	aviva@router1#

Discussion

When you modify the configuration on the router, you are editing a copy of the router’s configuration. This copy is called the candidate configuration. Any modifications that you make to the configuration are recorded only in the copy of the configuration and have no impact on the operation of the router. When you want the configuration to take effect, you must activate, or commit, it. When you do this, your configuration file is checked to make sure the syntax is correct. It is then activated, becoming the running configuration.

The commit process is a batch mode operation. While you are in configuration mode, you can make any number of changes, but these appear only in the candidate configuration and have no effect on the running configuration. You can even verify the syntax without activating the changes (with the commit check command; see Recipe 1.6). The commit command batches up all your changes (as well as changes made by anyone else who is also in configuration mode) and activates them all at once. This means that interdependent configuration segments take effect at the same time, so you don’t have to worry about the order in which you add statements to the configuration.

When you activate a configuration, the JUNOS software saves a copy of it on the router. This is discussed further in Recipe 1.14.

It bears repeating that you must activate a configuration using the commit command for it to take effect. It is a common mistake to forget to commit your changes, so this is often the first thing to check when debugging an operational problem on the router. It’s very easy to see how this might happen. You might make a change in the configuration and then immediately use the run command to issue an operational mode command to verify that the router behavior matches the changed configuration, or you might get interrupted or distracted while configuring and issue a run command without committing.

If you have not committed your changes, you are warned when you try to exit configuration mode and return to operational mode:

	aviva@router1# exit
	The configuration has been changed but not committed
	Exit with uncommitted changes? [yes,no] (yes)

If you choose to exit without committing the changes by pressing Enter or typing yes, the changes are retained in the candidate configuration but are not activated. When you again enter configuration mode, you are reminded of the uncommitted changes:

	aviva@router1> configure
	Entering configuration mode
	The configuration has been changed but not committed
	[edit]
	aviva@router1#

If you decide not to exit configuration mode just yet, you can find out what changes you (and anyone else in configuration mode) made by comparing the candidate configuration to the one that is active and running:

	[edit]
	aviva@router1# exit
	The configuration has been changed but not committed
	Exit with uncommitted changes? [yes,no] (yes) no
	Exit aborted
	[edit]
	aviva@router1# show | compare
	[edit system services]
	+    telnet;

Use the following command if you are not at the top of the configuration:

	[edit system services]
	aviva@router1# top show | compare
	[edit system services]
	+    telnet;

For routers with two Routing Engines, use the commit synchronize command to commit the configuration simultaneously on both Routing Engines (see Recipe 1.30).

See Also

Recipes 1.6, 1.11, 1.14, 1.15, 1.17, and 1.30

1.8. Debugging a Failed Commit

Problem

You are trying to activate a configuration and the commit command continues to fail.

Solution

Watch each step of the commit operation:

	[edit]
	aviva@router1# commit | display detail
	2005-02-24 11:49:49 PST: exporting juniper.conf
	2005-02-24 11:49:49 PST: expanding groups
	2005-02-24 11:49:49 PST: finished expanding groups
	2005-02-24 11:49:49 PST: setup foreign files
	2005-02-24 11:49:49 PST: propagating foreign files
	2005-02-24 11:49:49 PST: complete foreign files
	2005-02-24 11:49:50 PST: dropping unchanged foreign files
	2005-02-24 11:49:50 PST: daemons checking new configuration
	2005-02-24 11:49:50 PST: commit wrapup…
	2005-02-24 11:49:50 PST: updating '/var/etc/filters/filter-define.conf'
	2005-02-24 11:49:50 PST: activating '/var/etc/keyadmin.conf'
	2005-02-24 11:49:50 PST: activating '/var/etc/gtpcd.conf'
	2005-02-24 11:49:50 PST: activating '/var/etc/certs'
	2005-02-24 11:49:50 PST: executing foreign_commands
	2005-02-24 11:49:50 PST: /bin/sh /etc/rc.ui ui_setup_users (sh)
	2005-02-24 11:49:50 PST: executing ui_commit in rc.ui
	2005-02-24 11:49:51 PST: copying configuration to juniper.save
	2005-02-24 11:49:51 PST: activating '/var/run/db/juniper.data'
	2005-02-24 11:49:51 PST: notifying daemons of new configuration
	2005-02-24 11:49:51 PST: signaling 'Routing protocol daemon', pid 2884, signal 1,
	status 0 with notification errors enabled
	commit complete

Discussion

The previous output shows the results of a successful commit operation. If the configuration contains a mistake, the output indicates where the mistake is:

	[edit]
	aviva@router1# commit | display detail
	2005-02-24 13:46:03 PST: exporting juniper.conf
	2005-02-24 13:46:03 PST: expanding groups
	2005-02-24 13:46:03 PST: finished expanding groups
	2005-02-24 13:46:03 PST: setup foreign files
	2005-02-24 13:46:03 PST: propagating foreign files
	2005-02-24 13:46:03 PST: complete foreign files
	2005-02-24 13:46:03 PST: dropping unchanged foreign files
	2005-02-24 13:46:03 PST: daemons checking new configuration
	[edit protocols rip group alpha-rip-group]
	  'neighbor fe-0/0/0.0'
	     Failed to configure neighbor fe-0/0/0.0: already in group alpha-rip-group
	error: configuration check-out failed

In this example, the error is in the RIP routing protocol, and this error is flagged by the software process (the JUNOS term for a Unix daemon) that checks the configuration.

1.9. Exiting Configuration Mode

Problem

After you have completed making changes to the configuration, you want to activate the configuration and return to operational mode.

Solution

From the top hierarchy level, activate the configuration and exit configuration mode:

	[edit]
	aviva@router1# commit
	aviva@router1#  
quit
	aviva@router1>

From a lower level in the hierarchy, commit and exit configuration mode:

	[edit system]
	aviva@router1# commit
	aviva@router1# top
	[edit]
	aviva@router1# quit
	aviva@router1>

The following command is a quicker variation:

	[edit system]
	aviva@router1# commit
	aviva@router1# exit configuration-mode
	aviva@router1>

From any hierarchy level, activate the configuration and exit configuration mode with a single command:

	[edit system]
	aviva@router1# commit and-quit
	aviva@router1>

Discussion

The commands in this recipe show several variations of quitting configuration mode after you have committed a configuration. If you issue separate commit and quit (or exit) commands, you must be at the top level of the hierarchy (at the [edit] level) for the exit command to quit configuration mode. From a lower level, use the top command to return quickly to the [edit] level. If you use the exit command at a lower level, it returns you to the highest hierarchy from which you previously issued an edit command.

Here’s an example sequence of edit and exit commands to illustrate this:

	[edit]
	aviva@router1# edit protocols
	[edit protocols]
	aviva@router1# edit ospf
	[edit protocols ospf]
	aviva@router1# edit area 0.0.0.1
	[edit protocols ospf area 0.0.0.1]
	aviva@router1# exit
	[edit protocols ospf]
	aviva@router1# exit
	[edit protocols]
	aviva@router1# exit
	[edit]
	aviva@router1# exit
	 
Exiting configuration mode
	aviva@router1>

A quicker way to commit and then exit configuration mode from a lower level in the hierarchy is to use the commit command followed by the exit configuration-mode command.

Perhaps the quickest way to commit and get back to operational mode is to use the commit and-quit command. You can use this command at any hierarchy level. One caveat is that this command succeeds only if there are no mistakes or syntax errors in the configuration. If the commit fails, the CLI shows an error message, and you remain in configuration mode.

See Also

Recipe 1.7

1.10. Keeping a Record of Configuration Changes

Problem

When you activate a configuration, you want to include a short message that describes the changes you made.

Solution

Include a comment when you activate the configuration:

	aviva@router1# commit comment "turned on telnet"

Discussion

It’s good practice to include a short description of the changes you made to each version of a configuration file so you can keep a history of configuration changes. You do this by using the comment option with the commit command.

To track down what changed in the configuration and when, you can review the comments:

	aviva@router1> show system commit
	0   2005-03-31 20:26:16 UTC by aviva via cli
	    turned on telnet
	1   2005-03-31 11:12:28 UTC by aviva via cli
	    set host gildor facility-override local4

See Also

Recipe 1.17

1.11. Determining What Changes You Have Made to the Configuration

Problem

You want to check what changes you have already made when editing a configuration.

Solution

To find out what changes were made during the current configuration session, use the following command:

	[edit]
	aviva@RouterG# show | compare
	[edit interfaces]
	-    fe-1/0/1 {
	-         unit 0 {
	-              family inet {
	-                  address 10.0.1.2/24;
	-              }
	-          }
	-    }

To compare the current configuration to the previous one, use the following command:

	[edit]
	aviva@RouterG# show | compare rollback 1
	[edit protocols ospf]
	-   export send-direct;

Discussion

When you are working in a small portion or hierarchy of the configuration, you can issue the show command from time to time to see the configuration statements that were added or deleted so you can confirm the configuration. However, when making changes throughout the configuration hierarchy, you generally just want a summary of all the changes so you don’t have to dig through the entire router configuration. The easiest way to see all the changes is to move to the top of the configuration hierarchy with the top command and then use the show | compare command, which is equivalent to the show | compare rollback 0 command. This is actually two commands: the show command displays the entire configuration, and the output is piped to the compare command, which lists only the differences between the two commands (just like the Unix diff command).

The output shown in the “Solution” indicates that you have deleted the fe-1/0/1 interface from the [edit interfaces] configuration hierarchy. The first line of the output shows the hierarchy level, and the minus signs indicate the deletions. Plus signs are used when you have added statements, as in this example:

	[edit]
	aviva@RouterG#  
show | compare
	[edit interfaces lo0 unit 0 family inet]
	        address 192.168.19.1/32 { … }
	 
+       address 127.0.0.1/32;

You can also compare the current configuration with a previously committed one. The second command shows how to do this. rollback 1 is the version of the configuration you committed immediately before committing the current one. The output shown above indicates that the export send-direct statement was present at the [edit protocols ospf] hierarchy in the previous configuration but has been removed.

You can also use a filename with the compare command to compare the candidate configuration to a saved file. This supports URLs and scp-style filenames, so you can use commands such as the following:

	[edit]
	aviva@RouterG# show | compare aviva@archives:nightly/my-rtr/2005-12-01.conf
	[edit system login user testuser]
	-    class operator;
	+    class read-only;

See Also

Recipe 1.17

1.12. Configuring the Router by Copying a File from a Server

Problem

You have a router configuration file on a server and you want to copy it to the router and activate it.

Solution

Use the following command to copy the configuration to the router:

	aviva@router1> file copy server1:router- 
base-configuration  
.
	aviva@router1's password:
	router-base-configuration              100%   10KB   10.0KB/s   00:00

Verify that the file has been copied to the router:

	aviva@router1> file list
	/var/home/aviva/:
	.ssh/
	router-base-configuration

Then load the file into the JUNOS CLI:

	[edit]
	aviva@router1#  
load override router-base-configuration
	load complete

You should use the show command to review the loaded configuration and make sure it’s what you expect:

	aviva@router1# show

Then activate the configuration:

	[edit]
	aviva@router1# commit
	commit complete

Discussion

JUNOS configuration files are simply formatted text files, so you can create a configuration file on a server and then load it onto the router. Use the file copy command on the router to copy the file from the server to the router. This command is similar to the Unix scp command. In this example, the file is copied from the user’s home directory on the server to her home directory on the router. The home directory is effectively the current directory, so you can type a dot (.) for the directory name, just as in Unix. The explicit path is /var/home/aviva. No text is shown here for the password because the CLI does not echo what you type when you enter the password.

Because the file copy command uses SSH, the server must also be running SSH. (You can use the file copy command because you enabled SSH when you initially configured the router [see Recipe 1.1].)

If the file on the server is not in your home directory, you can specify the full path to the directory. In this example, the file you want to copy is in the /tmp/config directory:

	aviva@router1> file copy server1:/tmp/config/router-base-configuration .

Including the override option with the load command replaces the entire candidate configuration with the contents of the file you are loading.

If you are just adding a new section to the configuration, use the load merge command instead. For instance, if you are setting up router access for a new user, you can create a file that contains the configuration information. For example, if you create the file router-config-new-user that contains the following:

	system {
	    login {
	        user mike {
	             class superuser;
	        }
	    }
	}

after you copy this file to the router, use the load merge command to incorporate only this section of the configuration into the candidate configuration:

	[edit]
	aviva@router1# show system
	host-name router1;
	domain-name mynetwork.com;
	backup-router 192.168.600.1;
	time-zone America/Los_Angeles
	root-authentication {
	    encrypted-password "$1$ZUlES4dp$OUwWo1g7cLoV/aMWpHUnC/"; ## SECRET-DATA;
	}
	name-server {
	     192.168.400.1;
	}
	login {
	     class superuser-local {
	         permissions all;
	     }
	     user aviva {
	          class superuser;
	     }
	}
	aviva@router1# load merge router-config-new-user
	aviva@router1# show system
	host-name router1;
	domain-name mynetwork.com;
	backup-router 192.168.600.1;
	time-zone America/Los_Angeles;
	root-authentication {
	     encrypted-password "$1$ZUlES4dp$OUwWo1g7cLoV/aMWpHUnC/"; ## SECRET-DATA;
	}
	name-server {
	     192.168.400.1;
	}
	login {
	     class superuser-local {
	         permissions all;
	     }
	     user aviva {
	          class superuser;
	     }
	     user mike {
	          class superuser;
	     }
	}

You can see from this output that the user mike is now in the [edit system] section of the candidate configuration. Again, remember to use the commit command to activate these changes.

If the file containing the configuration for the new users is on a server, you can load and merge it directly into the configuration:

	[edit]
	aviva@router1# show system login
	class superuser-local {
	    permissions all;
	}
	user aviva {
	     class superuser;
	}
	aviva@router1#  
load merge relative server1:/tmp/router-config-new-user
	aviva@server1's password:
	router-config-new-users               100%    54    0.1KB/s    00:00
	load complete
	[edit]
	aviva@router1# show system login
	class superuser-local {
	    permissions all;
	}
	user aviva {
	     class superuser;
	}
	user mike {
	class superuser;
	}

The relative option in the load merge command performs the operation without needing the full hierarchy level. To use this option, the hierarchy level in the file must be clear and unambiguous.

If the file containing the configuration of the new users is on another router, you can use the same command to copy it to your router. Specify the router name instead of the server name.

1.13. Configuring the Router by Copying Text from a Terminal Window

Problem

You have a portion of a router configuration displayed in another window on your terminal or computer and you want to copy it to another router and activate it.

Solution

Use the load merge terminal command:

	aviva@router1> configure
	Entering configuration mode
	[edit]
	aviva@router1# load merge terminal
	[Type ^D at a new line to end input]

Then, cut the configuration snippet and paste it here. When you are done, type Ctrl-d.

Discussion

A time-saver when configuring the router is to cut the configuration text from one window on your computer and paste it into the router’s terminal window with the load merge terminal command. This is a great technique when you are copying configuration text from a browser or email window or when you are propagating identical or similar configurations from one router to another. To illustrate with a simple example, suppose you are configuring PIM-SM on all routers and are copying the configuration from a browser window. Here’s the configuration in the browser:

	protocols {
	    pim {
	        interface all {
	            mode sparse;
	            version 2;
	        }
	        interface fxp0.0 {
	             disable;
	        }
	    }
	}

Copy the text from the browser window; then, in the router’s configuration window, go into configuration mode, move to the correct configuration hierarchy level, and paste the text.

If PIM is not yet configured, merge it into the existing configuration:

	aviva@router1> configure
	Entering configuration mode
	[edit]
	aviva@router1#  
load merge terminal
	[Type ^D at a new line to end input]
	cut and paste here to add the lines shown below
	protocols  
{
	    pim {
	        interface all {
	            mode sparse;
	            version 2;
	        }
	        interface fxp0.0 {
	             disable;
	        }
	    }
	}
	^D
	load complete

First type the load merge terminal command and press Enter. Then paste the copied text and press Ctrl-d when done. This snippet starts at the top level of the configuration, [edit protocol], so you can drop it in with no typing. If the snippet is at a lower level, you either need to move down to that hierarchy level in the configuration (using the edit configuration mode command) or type in the opening hierarchy statements and closing braces yourself. If the PIM configuration you have is just the two interface commands and you are at the [edit] level, you need to type opening lines for protocols { and pim { and two lines of closing braces:

	[edit]
	aviva@router1# load merge terminal
	[Type ^D at a new line to end input]
	protocols {
	pim {
	type your paste command here to paste the lines shown below
	interface all {
	    mode sparse;
	    version 2;
	}
	interface fxp0.0 {
	    disable;
	}
	}
	}
	^D
	load complete

If you forget to include the proper number of closing braces, the CLI displays an error.

Here, the first line of the error shows that one closing brace was omitted, and the second line indicates the hierarchy level:

	terminal:9:(0) syntax error: }
	  [edit protocols pim]
	    ''
	      syntax error
	load complete (1 errors)

However, for a simple syntactical error like this, the CLI adds the remaining closing brace. You can verify this by checking the configuration:

	[edit]
	aviva@router1# show protocols
	pim {
	    interface all {
	        mode sparse;
	        version 2;
	    }
	    interface fxp0.0 {
	        disable;
	    }
	} <-- CLI added this last brace

	[edit]
	aviva@router1# commit check
	configuration check succeeds

You see that the CLI added the final brace. The commit check command confirms this correction, indicating that there are no syntax errors in the configuration file.

1.14. Backing Up the Router’s Configuration

Problem

You want to back up the router’s configuration to a remote server.

Solution

You can use the following command to copy the active configuration file to a server:

	aviva@router1> file copy /config/juniper.conf.gz server1:/homes/aviva/tmp
	aviva@server1's password:
	juniper.conf.gz               100% 2127       2.1KB/s       00:00

From configuration mode, use the save command to copy the candidate configuration to your home directory on a server:

	[edit]
	aviva@router1# save server1:configuration-march02
	aviva@server1's password:
	tempfile                      100%    11KB    11.2KB/s      00:00
	Wrote 433 lines of configuration to 'server1:configuration-march02'

You can also save it to a file in your home directory on the router:

	[edit]
	aviva@router1# save configuration-march02
	Wrote 433 lines of configuration to 'configuration-march02'
	aviva@router1# run file list
	/var/home/aviva:
	.ssh/
	configuration-march02

Another way to back up configuration files is to automatically transfer the file each time you commit the configuration:

	[edit system]
	aviva@router1# set archival configuration transfer-on-commit
	aviva@router1# set archival configuration archive-sites ftp://aviva:password@server1.
	mynetwork.com:/m20-config-archives

Discussion

This recipe shows several ways to save a backup copy of the router’s configuration. Use the first command from operational mode to copy the currently running version of the configuration to a server. The next two commands are configuration mode commands that save the candidate configuration either to a server or to your home directory on the router. If you use the save command after committing the configuration, you are effectively backing up the running configuration. The save command saves the configuration starting at your current hierarchy level. In this recipe, the commands are issued from the top hierarchy level (the [edit] level), so the entire configuration is saved. If you issue the command from a lower level, only that portion of the configuration is saved. The following command saves only the BGP configuration:

	[edit protocols bgp]
	aviva@router1# save configuration-bgp-march02
	Wrote 15 lines of configuration to 'configuration-bgp-march02'

Use the file show command to verify the contents:

	[edit protocols bgp]
	aviva@router1# run file show configuration-bgp-march02
	protocols {
	replace:
	    bgp {
	        export send-statics;
	        group internal {
	            type internal;
	            local-address 10.0.0.1;
	            neighbor 10.0.0.2;
	            neighbor 10.0.0.3;
	            neighbor 10.0.0.5;
	            neighbor 10.0.0.4;
	            neighbor 10.0.0.6;
	        }
	    }
	}

Notice that the CLI inserts the replace: tag into the file. If you later load this file into the configuration with the load replace configuration-bgp-march02 command, the CLI replaces the entire [edit protocols bgp] portion of the configuration with the contents of the file you are loading.

The last command in this recipe automatically transfers the configuration file each time you commit the configuration, in this case saving all files in the server’s directory m20-config-archives. The file is saved in a compressed ( .gz) format with a name that includes the router name and the date and time of the commit operation, as in this example:

	router1_juniper.conf.gz_20050627_190538

The numbers at the end of the filename are the date (27 June 2005) and the time (1905 hours, or 7:05 p.m., and 38 seconds). One thing to pay attention to is that the time is always in UTC, even if your router is set to run local time. A variation is to use the set archival command to save the configuration at specific time intervals—here, every 1,440 minutes (24 hours):

	[edit system]
	aviva@router1# set archival configuration transfer-interval 1440
	aviva@router1# set archival configuration archive-sites ftp://aviva:password@server1.
	mynetwork.com:/m20-config-archives

You can specify any interval from 15 minutes up to 2,880 minutes (48 hours).

One disadvantage of the set archival command is that the password is not encrypted in the configuration file but is shown in ASCII (clear text).

The JUNOS software also saves a copy of a configuration each time you activate it with any version of the commit command. The JUNOS software saves the last 50 versions of the configuration: the currently active configuration and the last 49 committed ones. The active (currently running) configuration (juniper.conf.gz) and the three most recent previous configurations (juniper.conf.1.gz, juniper.conf.2.gz, and juniper.conf.3.gz) are in the /config directory, which is on the router’s flash disk. Because space is limited on the flash disk, the files are stored in a compressed format (.gz).

	aviva@router1> file list /config
	/config:
	juniper.conf.1.gz
	juniper.conf.2.gz
	juniper.conf.3.gz
	juniper.conf.gz
	license/
	rescue.conf.gz

The remaining configurations—named juniper.conf.4.gz through juniper.conf.49.gz— are in the /var/db/config directory on the router’s hard disk.

These files are also compressed.

	aviva@router1> file list /var/db/config
	/var/db/config:
	juniper.conf++
	juniper.conf.10.gz
	juniper.conf.11.gz
	juniper.conf.12.gz
	juniper.conf.13.gz
	juniper.conf.14.gz
	juniper.conf.15.gz
	…
	juniper.conf.49.gz
	juniper.conf.5.gz
	juniper.conf.6.gz
	juniper.conf.7.gz
	juniper.conf.8.gz
	juniper.conf.9.gz

Each time you commit a configuration, that configuration is named juniper.conf.gz, the existing juniper.conf.gz file is renamed juniper.conf.1.gz, and all the remaining numbered configurations from before are renumbered. This means that the JUNOS backup configuration files are continually renamed. This behavior points out one advantage of using the save command: it allows you to store the configuration in a file with a fixed name.

A publicly available software tool for archiving and monitoring router hardware and software configuration is RANCID (http://www.shurbbery.net/rancid). You can also use this tool to track configuration changes.

See Also

Recipe 1.18

1.15. Scheduling the Activation of a Configuration

Problem

You want to activate a new or modified router configuration at a later time.

Solution

You schedule when the software should activate a configuration:

	[edit]
	aviva@router1# commit at 10:45
	configuration check succeeds
	commit at will be executed at 2005-02-25 10:45:00 PST
	Exiting configuration mode

The time is in 24-hour (military) format, so to specify a time after 12 p.m., use the following command:

	[edit]
	aviva@router1#  
commit at 22:45
	configuration check succeeds
	commit at will be executed at 2005-02-25 22:45:00 PST
	Exiting configuration mode

To schedule the activation of a configuration to occur on another day, use the full date and time:

	[edit]
	aviva@router1# commit at "2005-02-26 10:45"
	configuration check succeeds
	commit at will be executed at 2005-02-26 10:45:00 PST
	Exiting configuration mode

To cancel a commit operation scheduled with the commit at command, use the following command:

	aviva@router1>  
clear system commit
	Pending commit cleared

Discussion

Sometimes you want to delay the activation of a configuration, scheduling it to occur at some later time. For example, if you are a network provider and have a service window in which network changes are made, you want the new configuration to take effect during that window. Or, if you are making changes on a number of routers, you might want the changes to take effect on all the routers at the same time or within the same time window, especially if you are making changes to routing protocols that might affect routing and route convergence across the network.

One way to schedule the activation of a configuration is to use the commit at command. The first two commands in this recipe commit the configuration at a specific time on the current day, one at 10:45 a.m. and the second at 10:45 p.m. The third command schedules the commit at 10:45 a.m. on another day.

Verify that the commit command has actually executed by looking at the timestamp on the currently running configuration file:

	aviva@router1>  
file list detail /config

	/config:
	total 34
	-rw-r----- 1 root  wheel          2127 Feb 25 03:10 juniper.conf.1.gz
	-rw-r----- 1 root  wheel          2127 Feb 25 03:00 juniper.conf.2.gz
	-rw-r----- 1 root  wheel          2127 Feb 24 12:56 juniper.conf.3.gz
	-rw-r----- 1 root  wheel          2127 Feb 25 10:45 juniper.conf.gz
	drwxr-xr-x 2 root  wheel           512 Jan 18 2004 license/

You see that the running configuration file, juniper.conf.gz, was activated February 25 at 10:45 a.m.

When you use the commit at command, you must be at the [edit] hierarchy level in the configuration. The time and date that you specify are interpreted based on the router’s time clock. Use the show system uptime command to determine the current date and time as set on the router:

	aviva@router1> show system uptime
	Current time: 2005-02-25 10:59:09 PST
	System booted: 2005-02-25 03:07:42 PST (07:51:27 ago)
	Protocols started: 2005-02-25 03:10:07 PST (07:49:02 ago)
	Last configured: 2005-02-25 10:45:12 PST (00:13:57 ago) by aviva
	10:59AM PST up 7:51, 1 user, load averages: 0.01, 0.02, 0.00

To determine whether and when a configuration activation has been scheduled, use the show system commit command:

	aviva@router1> show system commit
	commit requested by aviva via cli at 2005-02-26 10:00:00 PST
	0   2005-02-25 10:45:12 PST by aviva via cli commit at
	1   2005-02-25 03:10:21 PST by aviva via cli
	2   2005-02-25 03:01:01 PST by aviva via cli

The first line shows that a configuration activation has been requested, who requested it, and when it will occur. This command also lists the history of all the commit operations that have occurred on the router and who activated them, and provides you with a history of configuration changes.

Another way you know that a configuration activation has been scheduled is that you see a message when you enter configuration mode:

	aviva@router1> configure
	Entering configuration mode
	Users currently editing the configuration:
	  aviva terminal p0 (pid 6231) on since 2005-02-25 11:55:07 PST, idle 00:15:54
	      commit-at

Note that when a delayed configuration activation is scheduled, you cannot commit any changes to the configuration:

	[edit]
	aviva@router1# commit
	error: Another commit is pending

To cancel a scheduled commit, use the clear system commit command.

1.16. Provisionally Activating a Configuration

Problem

You want to activate a new or modified router configuration but you are not sure whether the configuration will somehow disable the router.

Solution

Use the following command to commit the configuration changes provisionally:

	[edit]
	aviva@router1#  
commit confirmed
	commit confirmed will be automatically rolled back in 10 minutes unless confirmed
	commit complete

To make the provisional activation permanent, issue the following command:

	[edit]
	aviva@router1# commit
	commit complete

Discussion

When you need to verify that a new or modified configuration is working properly—and especially if the changes might lock you out of the router—you can provisionally commit it using the commit confirmed command.

By default, the commit confirmed command activates the configuration for 10 minutes. Within this time, you must explicitly confirm that the configuration is acceptable—either by issuing another commit command or by entering the commit check command—to make the provisional activation permanent. If you do not, the router loads and activates the previous configuration when 10 minutes have passed. You have to keep track of the time yourself, because the CLI doesn’t warn you when it is expiring. The CLI displays a message if you do not confirm the commit when returning to the previous configuration:

	Broadcast Message from root@router1
	        (no tty) at 15:05 PDT…
	Commit was not confirmed; automatic rollback complete.

When working on a production router, if you are concerned that the change you are making might not go as expected, specify an interval of less than 10 minutes. If you are quite worried, one minute might be as long as you want to wait:

	[edit]
	aviva@router1# commit confirmed 1
	commit confirmed will be automatically rolled back in 1 minutes unless confirmed
	commit complete

1.17. Loading a Previous Router Configuration

Problem

You need to undo the active router configuration and return to a previous configuration.

Solution

The rollback configuration mode command loads a previous router configuration as the candidate configuration:

	[edit]
	aviva@router1# rollback 1
	load complete
	[edit]
	aviva@router1# show
	[edit]
	aviva@router1# commit
	commit complete

Discussion

You can reload any of the previously committed versions of the configuration file. You identify the version by the number, which is the number in the filename. In this example, we reload the last saved configuration file, /config/juniper.conf.1.gz. The rollback command only loads the configuration, making it the candidate configuration, but does not activate it. The commit command activates the retrieved configuration. While using the show command here is optional, it’s good practice to verify that the configuration you loaded is what you expect.

To figure out which previous configuration you want to retrieve, you can use a few commands that we have already discussed, including show system commit and file list detail /config. You can use the file list detail /var/db/config command to find out when the older configuration files were activated and by whom. You can also see this information when you issue the rollback command by using the router’s built-in help:

	[edit]
	aviva@router1# rollback ?
	Possible completions:
	  <[Enter]>            Execute this command
	  0                          2005-02-25 12:31:52 PST by aviva via cli
	  1                          2005-02-25 10:45:12 PST by aviva via cli commit at
	  2                          2005-02-25 03:10:21 PST by root via cli
	…
	  48                         2005-02-19 03:01:04 PST by root via cli
	  49                         2005-02-18 18:24:21 PST by aviva via cli
	  |                          Pipe through a command

See Also

Recipes 1.10, 1.14, and 1.18

1.18. Creating an Emergency Rescue Configuration

Problem

You want to store a copy of a known good and working configuration that you can load in case of an emergency without having to remember which rollback number to use.

Solution

When a known stable and working configuration is loaded and running on the router, save it as the rescue configuration:

	aviva@router1> request system configuration rescue save

You can also save it directly from configuration mode:

	aviva@router1# run request system configuration rescue save

Discussion

You create a rescue configuration to define a known working configuration or a configuration with a known state that you can roll back to at any time. This alleviates having to know the rollback number when you use the rollback command. You use the rescue configuration when you need to roll back to a known configuration or as a last resort if your router configuration and the backup configuration files become damaged beyond repair. The JUNOS software does not provide a default rescue configuration.

To return to the rescue configuration, load it with the following command:

	[edit]
	aviva@router1# rollback rescue
	[edit]
	aviva@router1# commit
	commit complete

The JUNOS software stores the rescue configuration in the /config directory:

	aviva@router1> file list /config
	/config:
	juniper.conf.1.gz
	juniper.conf.2.gz
	juniper.conf.3.gz
	juniper.conf.gz
	rescue.conf.gz

To save a different configuration as the rescue configuration, just use the request system configuration rescue save command to overwrite the existing file. If you discover that the existing rescue configuration is not correct, but you don’t have something to replace it with, delete the rescue configuration so no one accidentally uses it:

	aviva@router1> request system configuration rescue delete

See Also

Recipe 1.17

1.19. Backing Up Filesystems on M-Series and T-Series Routers

Problem

You are preparing to load a different release of the JUNOS software or reload the current release and you want to save the files that are already on the router.

Solution

On M-series and T-series routers, use the following command to back up the files in the router’s filesystems:

	aviva@router1>  
request system snapshot

Discussion

Before you install any JUNOS software, either upgrading, downgrading, or reinstalling the current software version, you should always back up the files in the router’s filesystem. This operation is sometimes called taking a snapshot of the software. The request system snapshot command copies the files and filesystems from the current running active partitions to standby partitions. Specifically, it copies the / (root) filesystem to /altroot, and the /config filesystem to /altconfig. You see information about the copying as the command is running:

	aviva@router1> request system snapshot
	Copying '/' to '/altroot' .. (this may take a few minutes)
	Copying '/config' to '/altconfig' .. (this may take a few minutes)
	The following filesystems were archived: / /config

You can take a snapshot of the software at any time, but you should always do so before installing a new JUNOS software version so that you can recover to a known, stable environment in case something goes wrong when you load the software. You should also always run it after you have successfully loaded a new version of the software.

Why do you need to back up the JUNOS filesystems? One seasoned administrator has said that the less you know about the JUNOS filesystems, the more sane you will be—but still, you have to know at least a little bit. Routers have two internal storage areas, the flash drive (by default, the primary boot device) and the hard disk (the secondary boot device). A copy of the JUNOS software is stored in both. The flash drive has two filesystems (or partitions): /config, which contains the active and most recent backup configurations, the rescue configuration, and software licenses, and /, which contains the JUNOS software (everything installed by the jinstall or jbundle command), the router’s SSH keys, and a few other files generated from the configuration. The hard disk has one filesystem, /var, which is a large partition that contains system logfiles, diagnostic dump files, archived configuration files, and user home directories.(Also on the hard disk are the /altroot and /altconfig partitions, which contain a copy of the JUNOS software and related files and a swap partition.) When booting from the flash drive, the router uses the software and files on the flash drive. If the boot fails, it automatically tries the software and files on the hard disk. For the boot failover process to work, you must have already created a snapshot from a working version of the software.

There is one additional filesystem on the router, /tmp, which is a RAM disk (a memory filesystem).

To verify that the snapshot was successful, you might want to list the contents of the filesystems (with the file list command). However, the /altroot and /altconfig filesystems are not mounted, so they are not visible even though the underlying directories are still present:

	aviva@router1> show system storage
	Filesystem     Size       Used      Avail    Capacity    Mounted on
	/dev/ 
ad0s1a     77M        39M        32M         55%   /devfs
	                16K        16K         0B        100%   /dev/
	/dev/vn0        13M        13M         0B        100%   /packages/mnt/jbase
	/dev/vn1        37M        37M         0B        100%   /packages/mnt/jkernel-7.4R1.7
	/dev/vn2        12M        12M         0B        100%   /packages/mnt/jpfe-M40-7.4R1.7
	/dev/vn3       2.3M       2.3M         0B        100%   /packages/mnt/jdocs-7.4R1.7
	/dev/vn4        14M        14M         0B        100%   /packages/mnt/jroute-7.4R1.7
	/dev/vn5       5.1M       5.1M         0B        100%   /packages/mnt/jcrypto-7.4R1.7
	/dev/ad0s1e     12M        16K        11M          0%   /config
	procfs         4.0K       4.0K         0B        100%   /proc
	/dev/ 
ad1s1f    9.4G       1.2G       7.4G         14%   /var

How do you know from the output of this command which partition is where? /dev/ad0s1a refers to a portion of a disk. It is drive ad0 (the storage device) slice 1 (the first “slice,” and there’s generally just one slice), partition a (which is the first partition on a disk and always refers to the root partition). Similarly, /dev/ad1s1f refers to drive ad1, slice 1, partition f.

On most M-and T-series routers, ad0 is the flash disk. In the case of router1, an M20 router that has an RE-2.0, ad0 is the flash disk and ad1 is the hard disk:

	aviva@router1> show chassis hardware detail
	Hardware inventory:
	Item             Version      Part number   Serial number    Description
	Chassis                                     25708            M20
	Backplane        REV 03       710-002334    BB9738           M20 Backplane
	Power  
Supply A   REV 06       740-001465    005234           AC Power Supply
	Display          REV 04       710-001519    BA4681           M20 FPM Board
	Routing Engine 0 REV 06       740-003239    1000224893       RE-2.0
	Routing Engine 0                            58000007348d9a01 RE-2.0
	  ad0      91 MB  SanDisk     SDCFB-96      i3238140903      Compact Flash
	  ad1   11513 MB IBM-DARA-212000            AH0AHGN1017      Hard Disk
	Routing Engine 1 REV 06 740-003239          9000022146       RE-2.0
	Routing Engine 1                            d800000734745701 RE-2.0
	  ad0      91 MB  SanDisk SDCFB-96          ggbsc410020      Compact Flash
	  ad1    8063 MB  TOSHIBA MK2016GAP         Y0T39909T        Hard Disk

The output of this command also shows the manufacturer of the disks.

Use the show system storage command to find out the drive names:

	aviva@router1> show system storage
	Filesystem              Size        Used     Avail  Capacity    Mounted on
	/dev/ad0s1a              77M         40M       31M       56%   /
	devfs                    16K         16K        0B      100%   /dev/
	/dev/vn0                 13M         13M        0B      100%   /packages/mnt/jbase
	/dev/vn1                 37M         37M        0B      100%   /packages/mnt/jkernel-
	7.3-20050504.0
	/dev/vn2                 12M         12M        0B      100%   /packages/mnt/jpfe-M40-
	7.3-20050504.0
	/dev/vn3                2.3M        2.3M        0B      100%   /packages/mnt/jdocs-7.
	3-20050504.0
	/dev/vn4                 14M         14M        0B      100%   /packages/mnt/jroute-7.
	3-20050504.0
	/dev/vn5                5.1M        5.1M        0B      100%   /packages/mnt/jcrypto-
	7.3-20050504.0
	mfs:102                 1.5G         12K      1.4G        0%   /tmp
	/dev/ad0s1e              12M         24K       11M        0%   /config
	procfs                  4.0K        4.0K        0B      100%   /proc
	/dev/ad1s1f             9.4G        2.4G      6.2G       28%   /var

You see that /dev/ad0s1a is mounted at /, and you know that’s the flash disk. /config is also on ad0 (the flash disk again) but on a different partition, and /var is on ad1 (the hard disk). The /dev/vn0 devices refer to the software installed on the router. All these partitions are stored on / (and /altroot).

The show system storage command output is cluttered and contains more information than you normally care about. You can shorten by filtering out the installed software devices:

	aviva@router1> show system storage | except /dev/vn
	Filesystem               Size         Used      Avail   Capacity    Mounted on
	/dev/ad0s1a               77M          39M        32M        55%   /
	devfs                     16K          16K         0B       100%   /dev/
	mfs:102                  1.5G         8.0K       1.4G         0%   /tmp
	/dev/ad0s1e               12M          16K        11M         0%   /config
	procfs                   4.0K         4.0K         0B       100%   /proc
	/dev/ad1s1f              9.4G        1013M       7.6G        11%   /var

or even more:

	aviva@router1> show system storage | match ad
	/dev/ad0s1a               77M          39M        32M        55%   /
	/dev/ad0s1e               12M          16K        11M         0%   /config
	/dev/ad1s1f              9.4G        1013M       7.6G        11%   /var

If the router boots from the hard disk or if you manually reboot from the hard disk (take a fresh snapshot first, though), you’ll notice that ad0 is still the flash disk and ad1 is still the hard disk, but the root filesystem is now on the hard disk because you’re running on alternate media:

	aviva@router1> request system reboot media disk
	aviva@router1> show system storage
	Filesystem                 Size       Used      Avail   Capacity    Mounted on
	/dev/ad1s1a                107M        37M        61M        38%   /
	.
	.
	.
	mfs:172                    1.9G       4.0K       1.8G         0%   /tmp
	/dev/ad1s1e                 12M        21K        11M         0%   /config
	procfs                     4.0K       4.0K         0B       100%   /proc
	/dev/ad1s1f                 25G       3.5G        19G        15%   /var

The request system reboot media disk command takes a fairly long time to complete, and you need to log back in to the router when it completes.

See Also

Recipe 1.20

1.20. Backing Up Filesystems on J-Series Routers

Problem

You are preparing to load a different release of the JUNOS software or reload the current release on a J-series router and you want to save the files that are already on the router.

Solution

On any J-series router, back up the filesystem to a device that is connected to the router’s USB port:

	aviva@RouterA> request system snapshot media usb

On J4300 and J6300 routers, you can also back up the files in the router’s filesystem to a removable compact flash disk:

	aviva@RouterA> request system snapshot media removable-compact-flash

Before installing the software upgrade, delete old log- and crashfiles:

	aviva@RouterA> request system storage cleanup

Discussion

The snapshot process on J-series routers differs from the process for M-series and T-series routers because of hardware differences. You can place a snapshot of the J-series filesystems on a device connected to the router’s USB port or, for J4300 and J6300 routers, on a removable compact flash disk.

You can take a snapshot of the software at any time, but you should always do so before installing a new JUNOS software version so that you can recover to a known, stable environment in case something goes wrong when you load the software. You should also always take a snapshot after you have successfully loaded a new version of the software.

Before installing a new software package, you can use the request system storage cleanup command to remove older files to free up space in the filesystem. This command deletes any rotating logfiles in /cf/var/log that are not current files in /cf/var/tmp that have not been modified in the last two days and all crashfiles in /cf/var/crash. Before you delete files in the directories, you can use the file list command to check what they contain:

	aviva@RouterA> file list detail /cf/var/tmp
	/cf/var/tmp:
	total 28
	-rw-r--r--  1  root  wheel        6379 Nov 3 00:10 cleanup-pkgs.log
	drwxrwxrwx  2  root  wheel         512 Apr 15 2005 install/
	-rw-r-----  1  root  wheel        2492 Nov 3 00:10 sampled.pkts

	aviva@RouterA> file list detail /cf/var/log/messages*
	-rw-rw-r--  1  root  wheel          65 Nov 3 00:06 /cf/var/log/messages
	-rw-rw----  1  root  wheel        2587 Nov 3 00:06 /cf/var/log/messages.0.gz
	-rw-rw-r--  1  root  wheel       21746 Apr 16 2005 /cf/var/log/messages.1.gz
	-rw-rw----  1  root  wheel       12381 Dec 9  2004 /cf/var/log/messages.10.gz
	-rw-rw-r--  1  root  wheel       11066 Apr 9  2005 /cf/var/log/messages.2.gz
	-rw-rw-r--  1  root  wheel       12844 Feb 24 2005 /cf/var/log/messages.3.gz
	-rw-rw-r--  1  root  wheel        8751 Feb 18 2005 /cf/var/log/messages.4.gz
	-rw-rw----  1  root  wheel       12280 Feb 17 2005 /cf/var/log/messages.5.gz
	-rw-rw----  1  root  wheel       11486 Feb 10 2005 /cf/var/log/messages.6.gz
	-rw-rw----  1  root  wheel       44407 Feb 8  2005 /cf/var/log/messages.7.gz
	-rw-rw----  1  root  wheel       22260 Dec 10 2004 /cf/var/log/messages.8.gz
	-rw-rw----  1  root  wheel       18618 Dec 9  2004 /cf/var/log/messages.9.gz
	total 12

The show log command is another way to find out when logfiles were last modified:

	aiva@RouterA> show log
	  messages                 Size: 65, Last changed: Nov 03 00:06:10
	  messages.0.gz            Size: 2587, Last changed: Nov 03 00:06:10
	  messages.1.gz            Size: 21746, Last changed: Apr 16 2005
	  messages.10.gz           Size: 12381, Last changed: Dec 09 2004
	  messages.2.gz            Size: 11066, Last changed: Apr 09 2005
	  messages.3.gz            Size: 12844, Last changed: Feb 24 2005
	  messages.4.gz            Size: 8751, Last changed: Feb 18 2005
	  messages.5.gz            Size: 12280, Last changed: Feb 17 2005
	  messages.6.gz            Size: 11486, Last changed: Feb 10 2005
	  messages.7.gz            Size: 44407, Last changed: Feb 08 2005
	  messages.8.gz            Size: 22260, Last changed: Dec 10 2004
	  messages.9.gz            Size: 18618, Last changed: Dec 09 2004

See Also

Recipe 1.19

1.21. Restoring a Backed-Up Filesystem

Problem

You want to restore a filesystem that you backed up by taking a snapshot.

Solution

First, reboot the router from the alternate boot media to which you saved the snapshot. On M-series and T-series routers, this is the hard disk:

aviva@RouterA> request system software reboot media disk

On J-series routers, this is either a removable compact flash card or a device connected to the router’s USB port:

	aviva@RouterA> request system software reboot media removable-compact-flash
	or
	aviva@RouterA> request system software reboot media usb

Then, retake the snapshot to copy the filesystem to the media from which you didn’t boot:

	aviva@router1>  
request system snapshot

or

	aviva@RouterA> request system snapshot media removable-compact-flash

Discussion

The procedure for returning to a snapshot filesystem backup is very straightforward. You boot the router from the alternate media and then run the snapshot command again, which copies the filesystem from the alternate media to the media from which you didn’t boot.M-series and T-series routers normally boot from the internal flash drive, and the hard disk is the alternate boot media. J-series routers also normally boot from an internal flash drive, and the alternate boot media is a compact flash card that is either installed in the router’s compact flash drive or in a USB device connected to the router.

See Also

Recipes 1.19 and 1.20

1.22. Installing a Different Software Release on M-Series and T-Series Routers

Problem

You want to install a different release of JUNOS software on an M-series or T-series router.

Solution

First, retrieve the JUNOS install package, jinstall, from the Juniper Networks web site (http://www.juniper.net/support) and place it on a local server. You can install the software directly from the server:

	aviva@router1> request system software add validate server1:jinstall-7.4R1.7-domestic
-signed. Tgz

If you want to have a copy of the software on the router, copy it to the router. You can use SSH:

	aviva@router1> file copy server1:jinstall-7.4R1.7-domestic-signed.tgz /var/tmp
	aviva@server1's password:
	jinstall-7.4R1.7-domestic-signed.tgz         100% 64MB 774.5KB/s 01:24
	aviva@router1> file list /var/tmp
	/var/tmp:
	cores/
	install/
	jbundle-7.4jbundle-7.4R1.7-domestic-signed.tgz

You can also use FTP to install the software directly from a server:

	aviva@router1> request system software add validate ftp://aviva:prompt@
server1.mynetwork.com/jinstall-7.4R1.7-domestic-signed.tgz

If you are using anonymous FTP, just specify the name of the server:

	aviva@router1> request system software add validate ftp://server1.mynetwork.com/jinstall-
7.4R1.7-domestic-signed.tgz

If you want a copy of the software on the router, you can also copy it over with FTP:

	avive@router1> file copy ftp://aviva:prompt@
server1.mynetwork.com/jinstall-7.4R1.7-domestic
-signed.tgz /var/tmp/jinstall-
7.4R1.7-domestic-signed
	Password for aviva@server1.mynetwork.com:
	/var/home/aviva/…transferring.file.........YoE4Qe/
jinstall-7.4R1.7-domestic-signed.
	tgz100% of 63 MB 794 kBps 00m00s

After copying the software to the router, install it:

	aviva@router1> request system software add validate /var/tmp/jinstall-
7.4R1.7-domestic-signed.tgz

Once you have installed the new software version, reboot the router to activate it:

	aviva@router1> request system reboot

You can reboot directly as part of the software download process:

	aviva@router1> request system software add validate /var/tmp/ 
jinstall-
7.4R1.7-domestic-signed.tgz reboot

Discussion

JUNOS software is distributed as a set of modular software packages that contain the various components of the software. The packages include the base JUNOS operating system software, the routing software, and the forwarding software. These packages are bundled together in the jinstall package, which you use to install the software when you are upgrading. There is a domestic version for use in the United States and Canada (domestic) and a worldwide version (export) of each package. A given JUNOS software release runs on all J-series, M-series, and T-series routers, and you use the same jinstall package to upgrade the software on M-series and T-series router products.

Upgrade to a newer software release or downgrade to an older one by loading a different version of JUNOS software. You generally never downgrade except when you receive a new router that is running a more recent version than those of your other routers. Retrieve the JUNOS install package, jinstall, from the Juniper Networks web site (http://www.juniper.net/support) and copy it to a local server. The install package is a large file, so you can either install it directly from the server or, if you copy it to the router, put it on the hard disk, which has a large filesystem. A good place is /var/tmp.

When copying files to the router, you normally use SSH because SSH connections are encrypted, so your password and files are secure. FTP connections are not encrypted and hence are not secure. However, you can use FTP if you want, because all JUNOS software packages are signed and the JUNOS software validates the signature to ensure that the package has not been altered in any way. To use the router as an FTP server to transfer the files to the router when you are logged in to the server, enable FTP on the router:

	[edit]
	aviva@router1# set system services ftp
	aviva@router1# commit

You need to enable FTP only if you want to FTP something to the router—that is, when the router is the FTP server. If the router is the FTP client and you are copying a file from an FTP server, you do not need to enable FTP on the router. The FTP client on the router is always present and running.

If you enable the FTP server, disable it after you have copied the file to the router:

	[edit]
	aviva@router1# delete system services ftp
	aviva@router1# commit

Use the request system software add command to install the new software. During the installation, the filesystem on the router’s flash disk is rebuilt and all components of the JUNOS software are completely reinstalled. Configuration information from the previous software installation is retained, but the contents of logfiles might be erased. This is why you take a snapshot of the software using the request system snapshot command before you load a new version of the software (see Recipe 1.19).

In the request system software add command, include the validate option to check that the new software is compatible with your current router configuration file. When you are updating to a different release of the JUNOS software, the validation check is performed automatically.

In all these commands, the password is not displayed when you type it.

After you have installed the new software version and rebooted the router, verify that the software is operating properly. Then take another snapshot of the software.

If you don’t want to rebuild the entire filesystem each time you upgrade software, you can install the software using the jbundle package:

	aviva@router1> request system software add validate /var/tmp/jbundle-
7.4R1.7-domestic-signed.tgz

jbundle installs the new software components and modifies the smallest number of files needed to move the new software version.

See Also

Juniper Networks web site (http://www.juniper.net/support); Recipes 1.19, 1.23, and 1.31

1.23. Installing a Different Software Release on J-Series Routers

Problem

You want to install a different release of JUNOS software on a J-series router.

Solution

First, retrieve the JUNOS install package, junos-jseries, from the Juniper Networks web site (http://www.juniper.net/support) and copy it to a local server. You can install the software directly from the server:

	aviva@RouterA> request system software add validate unlink reboot server1
:junos-jseries-
7.4R1.7-export-cf256.gz

You can also copy the software to the router and then install that copy:

	aviva@RouterA> file copy server1: 
junos-jseries-
7.4R1.7-export-cf256.gz /cf/var/tmp
	aviva@server1's password:
	junos-jseries-7.4R1.7-export-cf256.gz        100%   64MB 774.5KB/s    01:24
	aviva@RouterA>  
request system software add validate unlink  

reboot /cf/var/tmp/junos-jseries-7.4R1.7-export-cf256.gz

Discussion

To upgrade to a newer software release, first download the J-series install package, junos-jseries, from the Juniper Networks web site (http://www.juniper.net/support) and copy it to a local server and then to the router. When moving the package to the router, a good place to put it is /cf/var/tmp.

The request system software command includes a few options. The validate option checks that the new software is compatible with your current router configuration file. When you are updating to a different release of the JUNOS software, the validation check is performed automatically. The unlink option removes the software package from the router as soon as possible to make more room on the hard disk for the installation to complete. The final option reboots the router after the validation and the installation complete and if the upgrade is successful. When the reboot is complete, you see the login prompt.

Use the request system software add command to install the new software. During the installation, the filesystem on the router’s flash disk is rebuilt and all components of the JUNOS software are completely reinstalled. Configuration information from the previous software installation is retained, but the contents of logfiles might be erased. This is why you take a snapshot of the software using the request system snapshot command before you load a new version of the software (see Recipe 1.19).

See Also

Juniper Networks web site (http://www.juniper.net/support); Recipes 1.19, 1.20, and

1.24. Creating an Emergency Boot Disk

Problem

You want to create a boot disk to use in an emergency if the software and filesystems on the router become so damaged that you just want to reconfigure the router from scratch.

Solution

Create a PCMCIA boot flash card that contains the JUNOS install media. First, copy the install media from the JUNOS software download page on the Juniper Networks support site (http://www.juniper.net/support). On M-series and T-series routers, copy this file to the router’s /var/tmp directory. Then, insert a PC card into the router’s drive and copy the install media to the PC card:

	aviva@router1> start shell
	aviva@router1% cd /var/tmp
	aviva@router1% su
	root@router1%  
dd if=/dev/zero of=/dev/rad3 count=20
	root@router1% dd if=install-media-7.4R1.7-domestic of=/dev/rad3 bs=64k

To create a boot flash card for a J-series router, copy the install media to a Windows or Unix PC and uncompress it with gzip or WinZip. Connect a PCMCIA adapter or USB card reader to the PC and insert a compact flash card into the device. On a Unix PC, use the following commands to copy the image to the compact flash:

	root@RouterJ# dd if=junos-jseries-7.4R1.7-export-cf256. of=/dev/hde
	250368+0 records in
	250368+0 records out

On a Windows XP or Windows 2000 PC, use either the Norton Ghost utility or the dd command shown previously.

Discussion

One of the tasks you can do to prepare for router disaster recovery is to create an emergency PCMCIA boot media. This is a bootable media that contains an image of a specific JUNOS software release. When you boot the router from this media, it installs the complete router from scratch, first doing a full reformat of the hard disk and flash, then completing a full new install of all the JUNOS software.

Use the PCMCIA boot media in disaster recovery when a router is hosed and you need to execute a complete reinstall from scratch. To boot from this media, the PCMCIA must first be inserted into the slot on the Routing Engine. When the router boots, the first thing it looks for is a PCMCIA in the slot. If it’s not there, it moves on to the flash drive. If the PCMCIA is there, the router stops and waits for a user with console access to the router to press Enter to continue. The router does not automatically execute the reformat and reinstallation; you must tell it to do so. That way, if someone inserts the PCMCIA in the slot by mistake, the router doesn’t format and reinstall when you didn’t plan for it to do so.

The J-series router follows the same procedure but uses a compact flash card instead of a PCMCIA card. This recipe shows the commands to use for a 256-MB compact flash.J-series install media are also available for other sizes, including 128, 512, and 1,024 MB.

See Also

Juniper Networks web site (http://www.juniper.net/support)

1.25. Gathering Software Version Information

Problem

You want to determine which software version is running on the router.

Solution

The following command shows the software version and lists all the software components that are running on the router:

	aviva@router1>  
show version
	Hostname: router1
	Model: m20
	JUNOS Base OS boot [7.4-20051024.0]
	JUNOS Base OS Software Suite [7.4-20051024.0]
	JUNOS Kernel Software Suite [7.4R1.7]
	JUNOS Packet Forwarding Engine Support (M20/M40) [7.4R1.7]
	JUNOS Routing Software Suite [7.4R1.7]
	JUNOS Online Documentation [7.4R1.7]
	JUNOS Crypto Software Suite [7.4R1.7]

On the J-series routers, the software ships as a single package:

	aviva@RouterA> show version
	Hostname: RouterA
	Model: j2300
	JUNOS Software Release [7.4R1.7] (Export edition)

Discussion

The show version command tells you which software version is running on the router. The first two lines show the name of the router and its type. This is followed by a list of the software packages that are running. The text in square brackets is the software version. Here, the complete software version number is 7.4R1.7. The software release number is 7.4. When the release-naming scheme was devised, the first number was supposed to indicate the major release and the second number the minor release, but, in practice, this never came to be. The JUNOS software releases do not distinguish between major and minor releases. Each release of software, be it 7.4, 7.5, or whatever, is considered an equivalent collection of new software and hardware features.

From a historical point of view, the initial JUNOS release was 3.0. The first digit in the release number increments from time to time, typically as a consequence of a new ASIC family, a new hardware platform family, or an upgrade to the underlying FreeBSD software. The second digit in the release number starts at 0 and increments with each software release. A new version of JUNOS software is released quarterly. So, for example, JUNOS releases 6.0 through 6.4 were released quarterly, from July 2003 through July 2004 (third quarter 2003 through third quarter 2004), and JUNOS 7.0 was released in the fourth quarter of 2004. In this case, the first digit in the release changed from 6 to 7 to correspond with the introduction of a new platform family, the TX Matrix.

The letter in the version number indicates the type of release. As a customer, you generally see R, for released software. If you are a beta customer, you receive B (beta) versions during the beta test period—for example, 7.4B1 and 7.4B2. If you are working with customer support to resolve a problem, you may also see I (internal) versions of the software or daily builds, which are named with the software version and a numeric string that includes the build date and time.

The digits following the letter are the maintenance release number and the build, or spin, of that maintenance. The first maintenance release number is always 1, and the first spin that is released is generally a number greater than 1. In the case of the show version command output in this recipe, the spin number is 7. The names of the JUNOS Base OS Software Suite and the Support Tools Package include the date that they were created rather than a maintenance release number, because these packages do not change as often as the others.

When checking the software version, make sure the versions of all the packages are the same. In this example, the packages are all 7.4. If they are not the same, the router will likely have operational issues.

The previous output shows all the standard JUNOS packages, which consist of five basic components:

Operating system

The JUNOS Base OS Software Suite, the JUNOS Kernel Software Suite, and the JUNOS Support Tools Package comprise the JUNOS operating system. The base OS is the underlying operating system software, which is based on FreeBSD, and the kernel is the software that runs on the various hardware boards, including the networking cards (the Flexible PIC Concentrators, or FPCs, and the Physical Interface Cards, or PICs).

Forwarding software

The JUNOS Packet Forwarding Engine Support package is the forwarding software, which runs on the forwarding board and is responsible for receiving and forwarding network traffic.

Routing software

The JUNOS Routing Software Suite is the routing software. It runs on the Routing Engine, which you can think of as a separate computer within the router dedicated to handling all routing functions, such as calculating the best routes to network destinations and managing the routing tables.

Security software

The crypto (security) software is provided only with JUNOS software shipped within the United States and Canada.

Online documenation

Online documentation is installed on the hard disk and is available while you are logged in to the router.

If you are debugging a problem with the JUNOS software and suspect that one of the software components is not running, use the show version detail command to list all the software processes that are installed:

	aviva@router1> show version detail
	…
	KERNEL 7.4R1.7 #0 built by builder on 2005-10-24 02:03:37 UTC
	MGD release 7.4R1.7 built by builder on 2005-10-24 02:03:58 UTC
	CLI release 7.4R1.7 built by builder on 2005-10-24 02:03:44 UTC
	CHASSISD release 7.4R1.7 built by builder on 2005-10-24 01:50:01 UTC
	DFWD release 7.4R1.7 built by builder on 2005-10-24 01:52:13 UTC
	DCD release 7.4R1.7 built by builder on 2005-10-24 01:48:04 UTC
	RPD release 7.4R1.7 built by builder on 2005-10-24 02:04:09 UTC
	SNMPD release 7.4R1.7 built by builder on 2005-10-24 01:56:24 UTC
	MIB2D release 7.4R1.7 built by builder on 2005-10-24 01:54:12 UTC
	APSD release 7.4R1.7 built by builder on 2005-10-24 01:49:52 UTC
	VRRPD release 7.4R1.7 built by builder on 2005-10-24 01:57:05 UTC
	ALARMD release 7.4R1.7 built by builder on 2005-10-24 01:49:44 UTC
	PFED release 7.4R1.7 built by builder on 2005-10-24 01:55:25 UTC
	CRAFTD release 7.4R1.7 built by builder on 2005-10-24 01:52:01 UTC
	SAMPLED release 7.4R1.7 built by builder on 2005-10-24 01:56:04 UTC
	ILMID release 7.4R1.7 built by builder on 2005-10-24 01:53:34 UTC
	RMOPD release 7.4R1.7 built by builder on 2005-10-24 01:55:47 UTC
	COSD release 7.4R1.7 built by builder on 2005-10-24 01:51:46 UTC
	KMD release 7.4R1.7 built by builder on 2005-10-24 01:45:24 UTC
	FSAD release 7.4R1.7 built by builder on 2005-10-24 01:52:24 UTC
	SERVICED release 7.4R1.7 built by builder on 2005-10-24 01:56:16 UTC
	IRSD release 7.4R1.7 built by builder on 2005-10-24 01:53:39 UTC
	NASD release 7.4R1.7 built by builder on 2005-10-24 01:55:20 UTC
	FUD release 7.4R1.7 built by builder on 2005-10-24 01:52:27 UTC
	PPMD release 7.4R1.7 built by builder on 2005-10-24 02:04:06 UTC
	LMPD release 7.4R1.7 built by builder on 2005-10-24 02:03:51 UTC
	RTSPD release 7.4R1.7 built by builder on 2005-10-24 01:56:01 UTC
	SMARTD release 7.4R1.7 built by builder on 2005-10-24 01:47:34 UTC
	KSYNCD release 7.4R1.7 built by builder on 2005-10-24 01:53:50 UTC
	LRMUXD release 7.4R1.7 built by builder on 2005-10-24 02:03:54 UTC
	SPD release 7.4R1.7 built by builder on 2005-10-24 01:56:46 UTC
	ECCD release 7.4R1.7 built by builder on 2005-10-24 01:52:23 UTC
	PGMD release 7.4R1.7 built by builder on 2005-10-24 02:04:03 UTC
	BFDD release 7.4R1.7 built by builder on 2005-10-24 02:03:42 UTC
	L2TPD release 7.4R1.7 built by builder on 2005-10-24 01:57:17 UTC
	SDXD release 7.4R1.7 built by builder on 2005-10-24 02:08:36 UTC
	PPPOED release 7.4R1.7 built by builder on 2005-10-24 01:55:39 UTC
	GCDRD release 7.4R1.7 built by builder on 2005-10-24 01:52:33 UTC
	RDD release 7.4R1.7 built by builder on 2005-10-24 01:55:44 UTC
	jkernel-dd release 7.4R1.7 built by builder on 2005-10-24 01:42:10 UTC
	jroute-dd release 7.4R1.7 built by builder on 2005-10-24 01:42:36 UTC
	jcrypto-dd release 7.4R1.7 built by builder on 2005-10-24 01:42:50 UTC

Some of the main processes are MGD, the management process, which communicates between the CLI and all the other processes; RPD, the routing protocol process; SNMPD, the SNMP process; MIB2D, the SNMP MIB II process; and PFED, the packet- forwarding software process. The JUNOS processes are the equivalent of Unix daemons, which is why their names end with the letter d. It is worth pointing out that all the software processes running on the router are separate and modular, so if one of them fails, the other processes that make up the router software continue to run.

The show system processes command, which is a repackaged version of the Unix ps command, also lists the running processes:

	aviva@router1> show system processes
	PID  TT  STAT         TIME COMMAND
	…
	 2630  ??  I         0:00.07 /usr/sbin/tnetd -N
	 2632  ??  S         5:27.60 /usr/sbin/chassisd -N
	 2633  ??  S         0:06.00 /usr/sbin/alarmd -N
	 2634  ??  I         0:00.16 /usr/sbin/craftd -N
	 2635  ??  I         0:00.32 /usr/sbin/mgd -N
	 2636  ??  I         0:00.14 /usr/sbin/inetd -N
	 2637  ??  S         0:00.29 /usr/sbin/tnp.sntpd -N
	 2641  ??  I         0:00.05 /usr/sbin/smartd -N
	 2645  ??  S         0:00.09 /usr/sbin/eccd -N
	 2727  ??  S         0:03.54 /usr/sbin/xntpd -j -N (ntpd)
	 2728  ??  S         0:07.88 /usr/sbin/snmpd -N
	 2729  ??  I         0:10.81 /usr/sbin/mib2d -N
	 2730  ??  S         0:03.87 /usr/sbin/rpd -N
	 2731  ??  I<     0:00.39 /usr/sbin/apsd -N
	 2732  ??  I         0:00.41 /usr/sbin/vrrpd -N
	 2733  ??  IN        0:00.51 /usr/sbin/sampled -N
	 2734  ??  I         0:00.22 /usr/sbin/ilmid -N
	 2735  ??  I         0:00.46 /usr/sbin/rmopd -N
	 2736  ??  I         0:00.55 /usr/sbin/cosd
	 2737  ??  I         0:00.29 /usr/sbin/nasd -N
	 2738  ??  I         0:00.17 /usr/sbin/fud -N
	 2739  ??  S         0:01.39 /usr/sbin/ppmd -N
	 2740  ??  I         0:00.25 /usr/sbin/lmpd
	 2741  ??  I         0:00.22 /usr/sbin/rtspd -N
	 2742  ??  S         0:00.76 /usr/sbin/fsad -N
	 2743  ??  I         0:00.40 /usr/sbin/spd -N
	 2744  ??  I         0:00.14 /usr/sbin/pgmd -N
	 2745  ??  I         0:00.86 /usr/sbin/bfdd -N
	 2746  ??  I         0:00.14 /usr/sbin/sdxd -N
	 2747  ??  I         0:00.20 /usr/sbin/rdd -N
	 2749  ??  S         0:00.47 /usr/sbin/dfwd -N
	 2751  ??  I         0:01.00 /usr/sbin/kmd -N
	 2752  ??  S         0:08.86 /sbin/dcd -N
	 2753  ??  I         0:01.03 /usr/sbin/pfed -N
	 2754  ??  S         0:06.14 /usr/sbin/irsd -N
	 …

If you suspect that an installed software process is not running, you can check the process. Here, we check for RPD, the routing-protocol process:

	aviva@router1> show system processes | match /rpd

We see that RPD is not running. Because the Routing Engine and the forwarding plane in JUNOS routers are separate processes, even when RPD is not up, the router continues to operate and forward traffic. However, it cannot perform any routing operations, such as sending routing-protocol updates and maintaining the routing table.

See Also

Recipe 4.7

1.26. Gathering Hardware Inventory Information

Problem

You are taking a hardware inventory to track which hardware components are installed in which router, along with serial numbers.

Solution

The following command lists all the hardware components installed in the router:

	aviva@router1> show chassis hardware
	Hardware inventory:
	Item             Version  Part number   Serial number   Description
	Chassis                                 25688           M20
	Backplane        REV 03   710-002334    BB9683          M20 Backplane
	Power Supply A   REV 06   740-001465    005169          AC Power Supply
	Display          REV 04   710-001519    BA4667          M20 FPM Board
	Routing Engine 0 REV 06   740-003239    9000016755      RE-2.0
	Routing Engine 1 REV 06   740-003239    9001018324      RE-2.0
	SSB slot 0       REV 02   710-001951    AZ8025          Internet Processor IIv1
	SSB slot 1       N/A      N/A           N/A             Backup
	FPC 0            REV 03   710-003308    BB5185          E-FPC
	  PIC 0          REV 08   750-002303    BB5887          4x F/E, 100 BASE-TX
	  PIC 1          REV 07   750-004745    BC9318          2x CT3-NxDS0
	  PIC 2
	FPC 1            REV 03   710-003308    BF7478          E-FPC
	  PIC 0          REV 03   750-002914    BC0119          2x OC-3 ATM, MM

Discussion

When you need to find out what hardware is installed in the router, use the show chassis hardware command. The first column of the output lists each hardware component installed in the router, starting with the chassis, which is the router itself. This router, an M20 system, has one power supply, two Routing Engines, one switching board (the SSB), and two FPCs with a total of four PICs. PICs are the network interface cards in the router. All these items are field-replaceable units (FRUs), so you or a service technician can replace them in the field.

The next three columns list the revision number, the Juniper Networks manufacturing part number, and the serial number. This information is very useful if you are tracking what router hardware you have and if you need to replace or return a defective piece of hardware.

The last column has a brief description of each hardware component. This is especially useful for finding out which PICs are installed on which FPC and in which location on the FPC. You need this information when you are configuring the router’s interfaces because you must specify the FPC number and the PIC location to identify the interface (see Chapter 7). Most M-series and T-series routers have either four or eight slots for FPCs, and each FPC typically has four locations for PICs. The FPCs are numbered 0 through 7 (or 0 through 3), and the PICs are numbered 0 through 3. The numbering is always indicated on the router chassis itself, but if your routers are in a secured room, you likely don’t have physical access to them.

The J-series router is a smaller router and has fewer hardware components:

	aviva@RouterA> show chassis hardware
	Hardware inventory:
	Item             Version  Part number   Serial number    Description
	Chassis                                 JN002648AA       J2300
	Routing Engine   REV 07   750-009992    AA04451163       RE-J.1
	FPC 0            REV 04   750-010739    AC04430335       FPC
	  PIC 0                                                  2x FE, 2x Serial

You can also get information about the memory storage areas on the router:

	aviva@router1> show chassis hardware detail
	Hardware inventory:
	Item             Version  Part number    Serial number    Description
	Chassis                                  25708            M20
	Backplane        REV 03   710-002334     BB9738           M20 Backplane
	Power Supply A   REV 06   740-001465     005234           AC Power Supply
	Display          REV 04   710-001519     BA4681           M20 FPM Board
	Routing Engine 0 REV 06   740-003239     1000224893       RE-2.0
	Routing Engine 0                         58000007348d9a01 RE-2.0
	  ad0      91 MB SanDisk SDCFB-96        i3238140903      Compact Flash
	  ad1   11513 MB IBM-DARA-212000         AH0AHGN1017      Hard Disk
	Routing Engine 1 REV 06 740-003239       9000022146       RE-2.0
	Routing Engine 1                         d800000734745701 RE-2.0
	  ad0      91 MB SanDisk SDCFB-96        ggbsc410020      Compact Flash
	  ad1    8063 MB TOSHIBA MK2016GAP       Y0T39909T        Hard Disk
	SSB slot 0       REV 02   710-001951     AZ8112           Internet Processor IIv1
	  SSRAM bank 0   REV 02   710-001385     242525           2 Mbytes
	  SSRAM bank 1   REV 02   710-001385     242741           2 Mbytes
	  SSRAM bank 2   REV 02   710-001385     242886           2 Mbytes
	  SSRAM bank 3   REV 02   710-001385     242482           2 Mbytes
	SSB slot 1       N/A      N/A            N/A              Backup
	FPC 0            REV 03   710-003308     BD8455           E-FPC
	  SSRAM          REV 02   710-001385     241669           2 Mbytes
	  SDRAM bank 0   REV 01   710-000099     0003409          64 Mbytes
	  SDRAM bank 1   REV 01   710-000099     0003408          64 Mbytes
	  PIC 0          REV 08   750-002303     AZ5310           4x F/E, 100 BASE-TX
	  PIC 1          REV 07   750-004745     BC9368           2x CT3-NxDS0
	  PIC 2          REV 03   750-002965     HC9279           4x CT3
	FPC 1            REV 03   710-003308     BB9032           E-FPC
	  SSRAM          REV 01   710-001385     V00818           2 Mbytes
	  SDRAM bank 0   REV 01   710-000099     0003803          64 Mbytes
	  SDRAM bank 1   REV 01   710-000099     0003847          64 Mbytes
	  PIC 0          REV 03   750-002914     BC0131           2x OC-3 ATM, MM

See Also

Recipe 4.8

1.27. Finding Out How Long the Router Has Been Up

Problem

You want to know how long the router has been up and running.

Solution

Use the following command to find out how long the router has been up:

	aviva@router1>  
show system uptime
	Current time:
	2005-03-15 19:05:08 UTC
	System booted:
	2005-03-15 11:09:57 UTC (07:55:11 ago)
	Protocols started:
	2005-03-15 11:11:31 UTC (07:53:37 ago)
	Last configured:
	2005-03-15 19:05:04 UTC (00:00:04 ago) by aviva
	 7:05PM up 7:55, 1 user, load averages: 0.07, 0.02, 0.01

Discussion

The show system uptime command is similar to the Unix uptime utility. The first line of output shows the current time on the router. The second line shows when the router was last booted and how long it has been up (here, 7 hours, 55 minutes, 11 seconds). The last line also shows how long the router has been up. The third line shows when the protocol software started, and the last line tells when the configuration was last changed and by whom.

See Also

Recipe 6.1

1.28. Gathering Information Before Contacting Support

Problem

A problem has occurred on the router and you need to gather basic information before contacting support.

Solution

Use the following command to gather information about the router:

	aviva@router1>  
request support information | save support-file

Discussion

The request support information command actually runs a number of JUNOS commands that provide detailed information and status about the running hardware and software, boot and log messages, the configuration itself, and the router’s interfaces. The output of this command is quite extensive, so you should always save it to a file. Then copy the file to a server for further analysis or to send to technical support.

If a problem is occurring on your router, you should check for core dumps, which are files that contain information about the start of the router or of particular processes just before they crashed. Core dumps are placed in the /var/tmp directory, and the software also saves a compressed version of the file that you can provide to support:

	aviva@router1> file list detail /var/tmp
	/var/tmp:
	total 505330
	-rw-------1 root field 185309 Apr 26 00:32 snmpd.core-tarball.0.tgz
	-rw-rw----1 root field 1314816 Apr 26 00:32 snmpd.core.0

If you suspect that faulty hardware is causing or contributing to a problem, use the show chassis hardware command, or its detail version, to get the serial number, version, and part number for that component.

See Also

Recipe 1.26

1.29. Managing Routers with Similar Configurations

Problem

Some of the configuration sections for many of the routers in your network are identical, and you want to propagate the common information to all routers so your network operations center (NOC) staff never has to set it.

Solution

Define the common information in a configuration group:

	[edit]
	aviva@router1# edit groups global
	[edit groups global]
	aviva@router1# set system domain-name mynetwork.com
	aviva@router1# set system backup-router 192.168.15.2
	aviva@router1# set system name-server 192.168.15.3
	aviva@router1# set system root-authentication encrypted-password $123 
poppI
	aviva@router1# set system ntp server 192.168.2.100
	aviva@router1# set system services ssh
	aviva@router1# set snmp location "JUNOS cookbook lab"
	aviva@router1# set snmp contact cookbook-lab-admin
	aviva@router1# set snmp interface fxp0.0
	aviva@router1# set snmp community public authorization read-only

Then apply the group to the configuration:

	[edit]
	aviva@router1# set apply-groups global

Discussion

JUNOS configuration groups define common configuration snippets in one part of the router configuration, which you then import, or apply, in other parts of the configuration. This allows you to define common portions of the configuration once and have them apply in many places in the configuration, thus minimizing or eliminating the risk of configuration inconsistencies or errors. If you are a network designer who develops router configurations that are then distributed to a number of routers in a point of presence (POP) or NOC, configuration groups are a good tool for propagating common configuration snippets across a number of routers. Having this information in a separate part of the configuration also lessens the possibility that others might inadvertently modify it. Use configuration groups for network-wide information, such as the domain name, addresses of name and authentication servers, router login accounts, and static routes (as we have done in this recipe) and to make it easier to configure items that have multiple instances, such as all channels on channelized interfaces.

Create the configuration groups under the [edit groups] hierarchy. The structure of the statements in the configuration group mirrors that of the complete JUNOS configuration.

In this recipe, we create one configuration group named global that defines the basic router information discussed in Recipe 1.1, along with pointers to our SNMP NMS system. You can create any number of group configurations, each with a distinct name.

The apply-groups statement causes the statements in a group be inherited by the proper location in the configuration. This recipe applies the global group at the top level ([edit] level) of the configuration because the group includes statements that affect a number of different top-level hierarchies ([edit system], [edit snmp], and [edit routing-options]).

You can include the configuration group statements in the configuration file of each router or in a template file that you use when configuring new routers. An easy way to add the information to existing configurations is to copy the configuration snippet using the load merge terminal command (see Recipe 1.13).

When you issue a plain show command in configuration mode, you see the statements only where you actually typed them. This means that you see the configuration group statements in the [edit groups] portion, not in the hierarchies where they are applied. If you pipe the show output to the display inheritance command, you see the statements in the hierarchy that inherited them:

	[edit system]
	aviva@router1# show | display inheritance
	host-name router1;
	domain-name mynetwork.com;
	##
	## 'backup-router' was inherited from group 'global'
	## '192.168.71.254' was inherited from group 'global'
	##
	backup-router 192.168.15.2;
	##
	## 'root-authentication' was inherited from group 'global'
	##
	root-authentication {
	    ##
	    ## '$1$ZUlES4dp$OUwWo1g7cLoV/aMWpHUnC/' was inherited from group 'global'
	    ##
	    encrypted-password "$1$ZUlES4dp$OUwWo1g7cLoV/aMWpHUnC/"; ## SECRET-DATA
	}
	name-server {
	     ##
	    ## '192.168.15.3' was inherited from group 'global'
	    ##
	    192.168.15.3;
	}
	services {
	    ##
	     ## 'ssh' was inherited from group 'global'
	    ##
	    ssh;
	    ##
	}
	##
	## 'ntp' was inherited from group 'global'
	##
	ntp {
	    ##
	     ## '192.168.2.100' was inherited from group 'global'
	    ##
	    server 192.168.2.100;
	    ##
	}

Although this recipe shows how to apply a group at the top level of the configuration, you can apply a group anywhere in the configuration. For example, if all the serial interfaces on your router act as data terminal equipment (DCE), you can use groups to configure the common serial options:

	[edit groups serial-dte-options]
	aviva@RouterA# set interfaces <se-*> serial-options clocking-mode  
dce
	aviva@RouterA# set interfaces <se-*> serial-options clock-rate 125.0khz

Here, the group is called serial-dte-options. The angle brackets enclose the wildcard se-* to apply the statements to all serial interfaces. You can then apply the group in the interfaces portion of the configuration:

	[edit interfaces}
	aviva@routerA# set apply-groups serial-dte-options

Look at the group configuration to verify it:

	[edit groups]
	aviva@RouterA# show
	serial-dte-options {
	    interfaces {
	        <se-*> {
	            serial-options {
	                clocking-mode dce;
	                clock-rate 125.0khz;
	            }
	        }
	    }
	}

In the interfaces section, set up the basic configuration of the serial interfaces and verify it:

	[edit interfaces]
	aviva@RouterA# show
	se-0/0/2 {
	    unit 0 {
	         family inet {
	             address 10.0.21.1/24;
	         }
	    }
	}
	se-0/0/3 {
	    unit 0 {
	        family inet {
	            address 10.0.16.1/24;
	        }
	    }
	}

Finally, check that the DCE configuration is inherited:

	[edit interfaces]
	aviva@RouterA#  
show | display inheritance
	se-0/0/2 {
	    ##
	    ## 'serial-options' was inherited from group 'serial-dte-options'
	    ##
	    serial-options {
	        ##
	        ## 'dce' was inherited from group 'serial-dte-options'
	        ##
	        clocking-mode dce;
	        ##
	        ## '125.0khz' was inherited from group 'serial-dte-options'
	        ##
	        clock-rate 125.0khz;
	    }
	    unit 0 {
	        family inet {
	              address 10.0.21.1/24;
	        }
	    }
	}
	se-0/0/3 {
	     ##
	     ## 'serial-options' was inherited from group 'serial-dte-options'
	     ##
	     serial-options {
	         ##
	         ## 'dce' was inherited from group 'serial-dte-options'
	         ##
	         clocking-mode dce;
	         ##
	         ## '125.0khz' was inherited from group 'serial-dte-options'
	         ##
	         clock-rate 125.0khz;
	     }
	     unit 0 {
	          family inet {
	               address 10.0.16.1/24;
	          }
	     }
	}

The output confirms that both serial interfaces inherited the serial-options statement into the configurations.

See Also

Recipe 1.13

1.30. Managing Redundant Routing Engines

Problem

Your router has two Routing Engines, and you want them both to have the same configuration.

Solution

Configure a hostname for each Routing Engine and an IP address for each fxp0 interface:

	[edit groups]
	aviva@router1# set re0 system host-name router1
	aviva@router1# set re0 interfaces fxp0 unit 0 family inet address 192.168.15.1/24
	aviva@router1# set re1 system host-name router1-a
	aviva@router1# set re1 interfaces fxp0 unit 0 family inet address 192.168.15.2/24
	[edit]
	aviva@router1# set apply-groups [re0 re1]

Commit the same configuration on both Routing Engines:

	aviva@router1# commit synchronize
	re0:
	configuration check succeeds
	re1:
	configuration check succeeds

Discussion

Most routers, especially those used by network providers, have redundant hardware components, such as fans, power supplies, and Routing Engines, so that if one of them fails, a backup component takes over immediately and router operation continues. You can replace most redundant components without having to power down the router; this is called hot swapping. For most hardware components, no software configuration is required. They are simply present in the router, which you can verify with the show chassis hardware command, and if any problems occur, a message or alarm is logged by the system logging facility (described in Chapter 5). Redundant Routing Engines, however, require some configuration.

By default, the Routing Engine in slot 0 is the master (RE0) and is used when the router boots. The one Routing Engine in slot 1 (RE1) is the backup. You configure hostnames and addresses for the two Routing Engines using configuration groups (in the [edit groups] hierarchy level). Specifically, you must use the special configuration group re0 (for the Routing Engine in slot 0) and re1 (for the Routing Engine in slot 1) to define properties specific to the individual Routing Engines. Configuring the re0 and re1 groups lets both Routing Engines use the same configuration file. Then use the apply-groups statement to propagate the configuration group information to the main part of the configuration.

The commit synchronize command commits the same configuration on both Routing Engines. This command makes the active or applied configuration for both Routing Engines the same with the exception of the groups, re0 being applied only to RE0 and re1 being applied only to RE1. If you don’t synchronize the configurations between the two Routing Engines and one of them fails, the router may end up in a very crippled state if the backup Routing Engine has a different configuration.

If the configuration on the other Routing Engine has been modified but not committed, the commit synchronize operation fails:

	[edit]
	aviva@router1# commit synchronize
	re0:
	error: configuration database modified
	re1:
	error: remote lock-configuration failed on re1

If you use the show | display inheritance command to see the statements that are inherited from the re0 and re1 groups, you see only what is inherited from the master Routing Engine, re0; you won’t see anything inherited from the backup:

	[edit]
	aviva@router1# show | display inheritance | match re0
	    ## 'router1' was inherited from group 're0'
	    ## 'fxp0' was inherited from group 're0'
	        ## '0' was inherited from group 're0'
	            ## 'inet' was inherited from group 're0'
	                ## '192.168.15.1/24' was inherited from group 're0'
	[edit system]
	aviva@router1# show | display inheritance | match re1
	[edit system]
	aviva@router1#

Use the following command to see which Routing Engine is the master and which is the backup:

	aviva@router1>  
show chassis routing-engine
	Routing Engine status:
	Slot 0:
	  Current state                    Master
	  Election priority                Backup
	  Temperature                   33 degrees C / 91 degrees F
	  CPU temperature               38 degrees C / 100 degrees F
	  DRAM                         768 MB
	  Memory utilization            20 percent
	  CPU utilization:
	    User                        11 percent
	    Background                   0 percent
	    Kernel                      19 percent
	    Interrupt                    1 percent
	    Idle                        69 percent
	  Model                            RE-2.0
	  Serial ID                        58000007348d9a01
	  Start time                       2005-04-26 22:31:45 UTC
	  Uptime                          3 minutes, 13 seconds
	  Load averages:                   1 minute   5 minute  15 minute
	                                       0.86       0.65       0.28
	Routing Engine status:
	  Slot 1:
	    Current state                  Backup
	    Election priority              Backup (default)
	    Temperature                 30 degrees C / 86 degrees F
	    CPU temperature             30 degrees C / 86 degrees F
	    DRAM                       768 MB
	    Memory utilization          15 percent
	    CPU utilization:
	      User                       0 percent
	      Background                 0 percent
	      Kernel                     0 percent
	      Interrupt                  0 percent
	      Idle                     100 percent
	    Model                          RE-2.0
	    Serial ID                      d800000734745701
	    Start time                     2005-02-18 07:48:14 UTC
	    Uptime                        67 days, 14 hours, 46 minutes, 37 seconds

The highlighted lines show the master and backup information, and the remainder of the output shows Routing Engine status information.

To find out which software version is running on the backup Routing Engine or to edit its configuration file, log in to that Routing Engine:

	aviva@router1> request routing-engine login re1
	--- JUNOS 7.4-R1.7
	aviva@router1a>

The prompt shows the hostname you configured for RE1.

Both Routing Engines have an identical filesystem layout, and the filesystems are distinguished by the identifiers re0 and re1. When you list files, you see the ones on the Routing Engine you are logged in to. To list files on the other Routing Engine, include the identifier:

	aviva@router1> file list re1:/
	re1:
	/:
	COPYRIGHT
	altconfig/
	altroot/
	bin/
	boot/
	config/
	data/
	dev/
	etc/
	kernel@ -> /packages/jkernel
	mnt/
	modules/
	packages/
	proc/
	root/
	sbin/
	tmp/
	usr/
	var/

The master and backup Routing Engines exchange keepalive messages to detect that each is alive and well. You can protect the operation of the router by automatically switching from the master to the backup Routing Engine if the backup has not received keepalives from the master for five minutes:

	[edit chassis redundancy]
	aviva@router1# set failover on-loss-of-keepalives

The problem with this type of failover—and with manually resetting the master-ship—is that the router stops forwarding packets during the time it takes to start the routing protocol software on the other Routing Engine. A way to automate the failure without packet loss is to use graceful switchover:

	[edit chassis redundancy]
	aviva@router1#  
set graceful-switchover enable

The CLI prompt then changes to indicate which Routing Engine you are using:

	{master}[edit]
	aviva@router1a#
	{backup}
	aviva@router1>

With graceful switchover, the backup Routing Engine regularly synchronizes its configuration and state with the master Routing Engine. The master Routing Engine sends keepalives to the backup every two seconds by default.(You can change this value with the set chassis redundancy keepalive-time command.) If the backup Routing Engine stops receiving these messages, it assumes mastership and the router’s Packet Forwarding Engine (PFE) breaks its connection with the routing tables on the old master and connects to the new master. From the point of view of packet forwarding, the switching of the PFE connection from one router to the next happens immediately, so no packet loss occurs. One caveat about graceful switchover is that both Routing Engines must be running the same version of the JUNOS soft-ware. If you are using the backup Routing Engine to upgrade to a different software release, you need to disable graceful switchover.

If you are using graceful switchover, you can automatically switch to the backup Routing Engine if it receives a hard disk failure error from the master:

	[edit chassis redundancy]
	aviva@router1# set failover on-disk-failure

By default, when you reboot the router, RE0 is the master. Use the following commands to have RE1 permanently be the master even after a reboot:

	[edit chassis]
	aviva@router1# set  
redundancy routing-engine 0 backup
	aviva@router1# set redundancy routing-engine 1 master
	aviva@router1# commit synchronize

See Also

Recipe 8.12

1.31. Using the Second Routing Engine to Upgrade to a New Software Version

Problem

You want to upgrade the JUNOS software version on the router incrementally to protect against something going wrong during the upgrade.

Solution

If your M-series or T-series router has two Routing Engines and you have configured Routing Engine redundancy (see Recipe 1.30), place the new software version on the second Routing Engine while keeping the currently running version on the first Routing Engine.

First, log in to RE0 and enter configuration mode:

	{master}
	aviva@router1> configure

Disable Routing Engine redundancy:

	{master} [edit]
	aviva@router1>  
delete chassis redundancy

Save the configuration changes on both Routing Engines:

	{master} [edit]
	aviva@router1> commit synchronize and-quit

Upgrade the JUNOS software version on the backup Routing Engine:

	{master}
	aviva@router1> request routing-engine login other-routing-engine
	aviva@router1-backup> request system software add validate /var/tmp/jinstall-
7.4R1.7-domestic-signed.tgz reboot

When the reboot of the backup Routing Engine begins, you are logged out of this Routing Engine and return to the master Routing Engine. Wait a few minutes for the backup Routing Engine to reboot. Then log back in to RE1 and verify that the software is running properly.

At this point, you can also upgrade the JUNOS software version on the master Routing Engine:

	{master}
	aviva@router1> request system software add validate /var/tmp/jinstall-
7.4R1.7-domestic-signed.tgz reboot

This time, you are logged out of the router. Log back in a few minutes after the reboot and reconfigure redundancy:

{master}
	aviva@router1> configure
	[edit]
	aviva@router1# set chassis redundancy routing-engine 0 master
	aviva@router1# set chassis redundancy routing-engine 1 backup
	aviva@router1# set chassis redundancy routing-engine graceful-switchover enable
	aviva@router1# set chassis redundancy routing-engine 0 master
	aviva@router1# commit synchronize and-quit

Then verify that the router is running properly and that RE0 is again the master.

Discussion

In the upgrade procedure described in Recipe 1.22, you overwrite the existing version of JUNOS software with the newer version. If something goes wrong during the upgrade process or if the image you load is damaged in some way, you might not be able to access the router, so you might not be able to reload the previous working version of the software.

Most M-series or T-series routers have two Routing Engines, and you can take advantage of this when you are upgrading software releases. You can install the new software release on the backup Routing Engine while keeping the currently running version on the master Routing Engine. Then make sure that the new software version is running correctly on the backup Routing Engine before upgrading the software on the master Routing Engine.

See Also

Recipes 1.22 and 1.30

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required