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.
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 username@router-name. 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 hostFor 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:
When you enter configuration mode, the prompt changes from username@router-name> to username@router-name#, 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 operationsWhen 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.0aviva@router1#showexport 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 parametersEach 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 commandIf 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#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 rThe 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> showroute
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 lineAnother 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 |
|---|---|
|
Display previous command history line | |
|
Display next command history line | |
|
Move to beginning of line | |
|
Move to end of line | |
|
Move back one character | |
|
Move forward one character | |
|
Move back one word | |
|
Move forward one word | |
|
Delete everything from cursor to end of line | |
|
Delete one word forward (the word after the cursor) | |
|
Delete one word backward (the word before the cursor) | |
|
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.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.0The > 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.
You have just installed and turned on a router and are configuring the JUNOS software for the first time.
Use the following commands to configure the router:
root#cliroot@> cli>configure[edit] root@#set system host-name router1root@#set system domain-name mynetwork.comroot@#set interfaces fxp0 unit 0 family inet address 192.168.15.1/24root@#set system backup-router 192.168.15.2root@#set system name-server 192.168.15.3root@#set system root-authentication plain-text-passwordNew password: Retype password: root@showsystem { host-name router1 ; domain-namemynetwork.com;backup-router192.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@#commitroot@router1#exitroot@router1>
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-namecommand.IP address of the router’s
fxp0interface, with theset interfaces fxp0command.fxp0is 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/0orfe-0/0/1, instead.) Juniper Networks recommends that you manage all M-series and T-series routers using thefxp0interface, 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 connectfxp0to 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 thatfxp0(orfe-0/0/0on J-series routers) is configured as the management interface.IP address of a backup router, with the
set system backup-routercommand. 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 therouting 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-servercommand. 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-passwordstatement 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
showcommand, the CLI never shows the actual text that you type. It immediately encrypts the password string using MD5 and displays the encrypted version in theshowcommand 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@#commitroot@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#cliroot@> cli>configure[edit] root@#edit system[edit system] root@#set host-namerouter1root@#set domain-namemynetwork.comroot@#set backup-router192.168.15.2root@#set name-server192.168.15.3root@#set root-authentication plain-text-passwordNew password:$123poppIRetype 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 server192.168.2.100root@router1#set system time-zoneAmerica/Los_Angelesroot@router1#set system services sshroot@router1#set interfaces lo0 unit 0 family inet address207.17.139.42/32root@router1#set system login useravivaclass superuserroot@router1#set system log user aviva authentication plain-text-passwordNew 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# commitRecipes 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.
You need to be in configuration mode to configure the router:
aviva@router1> configure
Entering configuration mode
[edit]
aviva@router1#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.
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.
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#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 usermike
You get the username from the message displayed when you enter configuration mode or from the status command.
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.
Use the following command to list the commands for creating a configuration:
[edit]
aviva@RouterA# show |
display setThe
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/32You 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;
}
}
}You want to add comments to the router configuration file to help other people reading the file understand how the router is configured.
Use the annotate command to add a comment:
[edit protocols ospf] aviva@router1#set area0.0.0.0 interface fe-0/0/0aviva@router1#annotate area0.0.0.0 "backbone routers"aviva@router1#show/* backbone routers */ area 0.0.0.0 { interface fe-0/0/0.0; }
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 area0.0.0.0 ""
You want to check the syntax of your configuration to make sure there are no errors or missing statements.
Check the syntax of the configuration:
[edit]
aviva@router1# commit check
configuration check succeeds
[edit]
aviva@router1#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 groupalpha-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.
You have created or modified the router’s configuration using the CLI and you want to put the configuration into effect.
Use the following command to activate a router configuration:
[edit]
aviva@router1# commit
commit complete
[edit]
aviva@router1#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#exitThe configuration has been changed but not committed Exit with uncommitted changes? [yes,no] (yes)noExit 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).
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 completeThe 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 failedIn 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.
After you have completed making changes to the configuration, you want to activate the configuration and return to operational mode.
From the top hierarchy level, activate the configuration and exit configuration mode:
[edit] aviva@router1#commitaviva@router1#quitaviva@router1>
From a lower level in the hierarchy, commit and exit configuration mode:
[edit system] aviva@router1#commitaviva@router1#top[edit] aviva@router1#quitaviva@router1>
The following command is a quicker variation:
[edit system] aviva@router1#commitaviva@router1#exit configuration-modeaviva@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>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#exitExiting 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.
When you activate a configuration, you want to include a short message that describes the changes you made.
Include a comment when you activate the configuration:
aviva@router1# commit comment "turned on telnet"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 local4To 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;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 | compareaviva@archives:nightly/my-rtr/2005-12-01.conf[edit system login user testuser] - class operator; + class read-only;
You have a router configuration file on a server and you want to copy it to the router and activate it.
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-configurationThen load the file into the JUNOS CLI:
[edit] aviva@router1#load overriderouter-base-configurationload complete
You should use the show command to review the loaded configuration and make sure it’s what you expect:
aviva@router1# showThen activate the configuration:
[edit]
aviva@router1# commit
commit completeJUNOS 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 copyserver1:/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 systemhost-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 mergerouter-config-new-useraviva@router1#show systemhost-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 loginclass superuser-local { permissions all; } user aviva { class superuser; } aviva@router1#load merge relativeserver1:/tmp/router-config-new-useraviva@server1's password: router-config-new-users 100% 54 0.1KB/s 00:00 load complete [edit] aviva@router1#show system loginclass 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.
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.
Use the
load merge terminal command:
aviva@router1>configureEntering 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.
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>configureEntering 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 belowprotocols { pim { interface all { mode sparse; version 2; } interface fxp0.0 { disable; } } }^Dload 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 belowinterface all { mode sparse; version 2; } interface fxp0.0 { disable; }} } ^Dload 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 protocolspim { interface all { mode sparse; version 2; } interface fxp0.0 { disable; } } <-- CLI added this last brace [edit] aviva@router1#commit checkconfiguration 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.
You can use the following command to copy the active configuration file to a server:
aviva@router1>file copy /config/juniper.conf.gzserver1:/homes/aviva/tmpaviva@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#saveconfiguration-march02Wrote 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-commitaviva@router1#set archival configuration archive-sites ftp://aviva:password@server1. mynetwork.com:/m20-config-archives
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#saveconfiguration-bgp-march02Wrote 15 lines of configuration to 'configuration-bgp-march02'
Use the file show command to verify the contents:
[edit protocols bgp] aviva@router1#run file showconfiguration-bgp-march02protocols {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-interval1440aviva@router1#set archival configuration archive-sitesftp://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.gzThe 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.gzEach 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.
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 modeTo 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 modeTo cancel a commit operation scheduled with the commit at command, use the following command:
aviva@router1>
clear system commit
Pending commit clearedSometimes 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.00To 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 cliThe 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-atNote that when a delayed configuration activation is scheduled, you cannot commit any changes to the configuration:
[edit]
aviva@router1# commit
error: Another commit is pendingTo cancel a scheduled commit, use the
clear system commit command.
You want to activate a new or modified router configuration but you are not sure whether the configuration will somehow disable the router.
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 completeTo make the provisional activation permanent, issue the following command:
[edit]
aviva@router1# commit
commit completeWhen 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 completeThe
rollback configuration mode command loads a previous router configuration as the candidate configuration:
[edit] aviva@router1#rollback 1load complete [edit] aviva@router1#show[edit] aviva@router1#commitcommit complete
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 commandYou 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.
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 saveYou can also save it directly from configuration mode:
aviva@router1# run request system configuration rescue saveYou 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#commitcommit 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.gzTo 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 deleteYou 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.
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 snapshotBefore 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: / /configYou 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% /varHow 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 detailHardware 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.0Routing Engine 0 58000007348d9a01 RE-2.0 ad0 91 MB SanDisk SDCFB-96 i3238140903 Compact Flash ad1 11513 MB IBM-DARA-212000 AH0AHGN1017 Hard DiskRouting Engine 1 REV 06 740-003239 9000022146 RE-2.0Routing 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% /varYou 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% /varor 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% /varIf 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 diskaviva@router1>show system storageFilesystem 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.
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.
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 usbOn 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-flashBefore installing the software upgrade, delete old log- and crashfiles:
aviva@RouterA> request system storage cleanupThe 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
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 diskOn 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-flashor 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 snapshotor
aviva@RouterA> request system snapshot media removable-compact-flashThe 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.
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. TgzIf you want to have a copy of the software on the router, copy it to the router. You can use SSH:
aviva@router1>file copyaviva@server1's password: jinstall-7.4R1.7-domestic-signed.tgz 100% 64MB 774.5KB/s 01:24 aviva@router1>server1:jinstall-7.4R1.7-domestic-signed.tgz /var/tmpfile 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.tgzIf 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.tgzIf 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 00m00sAfter copying the software to the router, install it:
aviva@router1> request system software add validate /var/tmp/jinstall-
7.4R1.7-domestic-signed.tgzOnce you have installed the new software version, reboot the router to activate it:
aviva@router1> request system rebootYou 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 rebootJUNOS 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 ftpaviva@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 ftpaviva@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.tgzjbundle installs the new software components and modifies the smallest number of files needed to move the new software version.
Juniper Networks web site (http://www.juniper.net/support); Recipes 1.19, 1.23, and 1.31
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.gzYou can also copy the software to the router and then install that copy:
aviva@RouterA>file copyaviva@server1's password: junos-jseries-7.4R1.7-export-cf256.gz 100% 64MB 774.5KB/s 01:24 aviva@RouterA>server1: junos-jseries-7.4R1.7-export-cf256.gz /cf/var/tmprequest system software add validate unlink reboot /cf/var/tmp/junos-jseries-7.4R1.7-export-cf256.gz
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).
Juniper Networks web site (http://www.juniper.net/support); Recipes 1.19, 1.20, and
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.
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 shellaviva@router1%cd /var/tmpaviva@router1%suroot@router1%dd if=/dev/zero of=/dev/rad3 count=20root@router1%dd if=install-media-7.4R1.7-domesticof=/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 outOn a Windows XP or Windows 2000 PC, use either the
Norton Ghost utility or the dd command shown previously.
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.
Juniper Networks web site (http://www.juniper.net/support)
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)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 UTCSome 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 /rpdWe 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.
You are taking a hardware inventory to track which hardware components are installed in which router, along with serial numbers.
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, MMWhen 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 SerialYou 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, MMUse 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.01The 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.
A problem has occurred on the router and you need to gather basic information before contacting support.
Use the following command to gather information about the router:
aviva@router1>
request support information | save support-fileThe 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.0If 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.
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.
Define the common information in a configuration group:
[edit] aviva@router1#edit groups global[edit groupsglobal] aviva@router1#set system domain-nameaviva@router1#mynetwork.comset system backup-routeraviva@router1#192.168.15.2set system name-serveraviva@router1#192.168.15.3set system root-authentication encrypted-passwordaviva@router1#$123 poppIset system ntp serveraviva@router1#192.168.2.100set system services sshaviva@router1#set snmp location "aviva@router1#JUNOS cookbook lab"set snmp contactaviva@router1#cookbook-lab-adminset snmp interface fxp0.0aviva@router1#set snmp community public authorization read-only
Then apply the group to the configuration:
[edit]
aviva@router1# set apply-groups globalJUNOS 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-modeaviva@RouterA#dceset interfaces <se-*> serial-options clock-rate125.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-optionsLook 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.
Configure a hostname for each Routing Engine and an IP address for each fxp0 interface:
[edit groups] aviva@router1#set re0 system host-nameaviva@router1#router1set re0 interfaces fxp0 unit 0 family inet addressaviva@router1#192.168.15.1/24set re1 system host-nameaviva@router1#router1-aset re1 interfaces fxp0 unit 0 family inet address[edit] aviva@router1#192.168.15.2/24set apply-groups [re0 re1]
Commit the same configuration on both Routing Engines:
aviva@router1# commit synchronize
re0:
configuration check succeeds
re1:
configuration check succeedsMost 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 re1If 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-engineRouting Engine status:Slot 0: Current state MasterElection 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 BackupElection 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-keepalivesThe 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 enableThe 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-failureBy 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 backupaviva@router1#set redundancy routing-engine 1 masteraviva@router1#commit synchronize
You want to upgrade the JUNOS software version on the router incrementally to protect against something going wrong during the upgrade.
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> configureDisable Routing Engine redundancy:
{master} [edit]
aviva@router1>
delete chassis redundancySave the configuration changes on both Routing Engines:
{master} [edit]
aviva@router1> commit synchronize and-quitUpgrade 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 rebootWhen 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 rebootThis 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-quitThen verify that the router is running properly and that RE0 is again the master.
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.
Get JUNOS Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
