5.2 System Administration
| System administration can be interpreted to encompass a very broad range of activities. For the purposes of this chapter, we will focus primarily on the elements of system administration that are typically in the hands of a network engineer and involve securing the router from unauthorized access while providing convenient access to individuals responsible for managing the functions of the device. Unauthorized access can take one of two forms. The first form is the least common but, because of Hollywood, most glamorized and is a situation in which an unauthorized user gains access to the router. The more common and less-dramatized form of unauthorized access is any situation in which an authorized user executes configuration statements beyond his ability or job description. 5.2.1 User Account SetupUser accounts in the Juniper Networks world are handled in a very similar manner to the UNIX strategy of assigning groups and usernames. The terminology is slightly different, but the concept is essentially the same. Login classes are defined and configured first. Each login class will have a predetermined set of permissions and restrictions assigned to it. After the classes are built, each individual user is assigned to a class. In this way the system administrator's job is made easier as it is not necessary to build a unique set of permissions and restrictions for every single user. When new employees are hired or new users added, they will more than likely fit into one of the existing login classes. All usernames configured on a Juniper Networks M-Series router must be in a single login class. JUNOS allows only one login class per user, but multiple users can be assigned to each login class. As was mentioned in the previous paragraph, the login class is associated with a set of permissions and restrictions that control the commands that are accessible to the users assigned to the class. Login classes also permit the administrator to define how long a session can be idle before it times out and the user is logged off. The steps for creating a login class are as follows :
The following sections describe these steps. 5.2.1.1 Defining a Login ClassFrom an administrative perspective, the sensible thing to do is to look at the roles and responsibilities of the people who will be accessing the router, determine which commands each user should be able to execute, then build login classes accordingly . After creating the classes, you would then apply a login class to an individual user account. JUNOS contains four predefined login classes, which cannot be modified. Table 5-1 lists the classes along with the permissions assigned to them. Table 5-1. Predefined Login Classes
Keywords are used to represent a specific command or group of commands that can be typed at the CLI. The keywords can be used to create custom login classes for users with special access needs. When creating custom login classes, it is possible to configure access-privilege levels using keywords. Individual commands can be explicitly denied or allowed within those access privilege levels, and the timeout value for idle sessions can be configured. The configuration sample below shows the syntax of the options available for creating a login class: [edit] lab@Chicago# set system login class bigdogs ? Possible completions: <[Enter]> Execute this command allow-commands Regular expression for commands to allow explicitly + apply-groups Groups from which to inherit configuration data deny-commands Regular expression for commands to deny explicitly idle-timeout Maximum idle time before logout (minutes) + permissions Set of permitted operation categories To define a login class (give it a name ), use the set class command. The configuration sample below shows the definition of a login class bigdogs : [edit system login] lab@Chicago# set class bigdogs [edit system login] lab@Chicago# show class bigdogs; 5.2.1.2 Assigning an idle-timeout IntervalAfter a login class has been defined, it can be assigned an idle-timeout interval, the amount of time in minutes in which the system will tolerate a lack of input from the keyboard. The default idle-timeout interval is eternity; a login session remains established until a user manually logs out of the router. To configure an idle-time limit for a login class, include the set idle-timeout command. The sample below shows the idle-timeout interval set to 30 minutes for bigdogs . [edit system login] lab@Chicago# edit class bigdogs [edit system login class bigdogs] lab@Chicago# set idle-timeout ? Possible completions: <idle-timeout> Maximum idle time before logout (minutes) [edit system login class bigdogs] lab@Chicago# set idle-timeout 30 [edit system login class bigdogs] lab@Chicago# show idle-timeout 30; If a timeout value is configured and the user exceeds the inactivity period, JUNOS generates the following sequence of messages before timing out the idle user. The following messages were pulled from a session that was timed out due to inactivity: lab@Chicago# Session will be closed in 5 minutes if there is no activity Warning: session will be closed in 1 minute if there is no activity Warning: session will be closed in 10 seconds if there is no activity Idle timeout exceeded: closing session Chicago (ttyd0 login: Operational-mode monitor commands are a way to watch a protocol, view traffic crossing an interface, or track a log file as it is being built. If the user is running an operational-mode monitor command, such as monitor traffic or monitor interfaces , the session is immune to the normal idle-timeout rules. This allows users to launch and watch the output from the monitor commands without having to type anything to keep the session alive . Note When a user is logged out due to inactivity, any uncommitted changes he or she has made are neither lost, nor committed. The changes are kept as part of the JUNOS candidate configuration and can be manipulated by any subsequent user. 5.2.1.3 Assigning Access-Privilege LevelsAfter the login class has been named, it is necessary to assign the access-privilege levels that should be associated with it. To assign an access-privilege level, use the set permissions command at the [edit system login class <classname>] level of the JUNOS hierarchy. Proper usage of the set permissions command is shown in the configuration sample below. In this example, login class bigdogs is being given access to all commands and functions within JUNOS. [edit system login class bigdogs] lab@Chicago# set permissions all [edit system login class bigdogs] lab@Chicago# show idle-timeout 30; permissions all; When specifying permissions, use the keywords from the list below. Each of these keywords has a set of commands associated with it. It is important to remember that the permissions keywords are not cumulative. In other words, if a user is assigned permissions that allow him to change the configuration at the interfaces level of the JUNOS hierarchy, he most also be given the ability to enter the configuration mode to get there. For each class, be sure to include all functions needed. New administrators commonly make the mistake of leaving out essential functions like configure to enter configuration mode and view to display chunks of the configuration. Type a question mark to view all command completion options. The result generates both a list of the keywords and a brief description of each, as is shown in the CLI output below: [edit system login class bigdogs] lab@Chicago# set permissions ? Possible completions: [ Open a set of values admin Can view user accounts admin-control Can modify user accounts all All permission bits turned on clear Can clear learned network information configure Can enter configuration mode control Can modify any configuration values edit Can edit full files field Special for field (debug) support firewall Can view firewall configuration firewall-control Can modify firewall configuration floppy Can read and write the floppy drive interface Can view interface configuration interface-control Can modify interface configuration maintenance Can perform system maintenance (as wheel) network Can access the network reset Can reset and restart interfaces and processes rollback Can rollback for depth greater than zero routing Can view routing configuration routing-control Can modify routing configuration secret Can view secret configuration secret-control Can modify secret configuration security Can view security configuration security-control Can modify security configuration shell Can start a local shell snmp Can view SNMP configuration snmp-control Can modify SNMP configuration system Can view system configuration system-control Can modify system configuration trace Can view trace file settings trace-control Can modify trace file settings view Can view current values and statistics 5.2.1.4 Setting allow-commands and deny-commandsIn some cases, after defining the login class and setting the permissions, it is necessary to explicitly deny or allow commands within the predefined access-privilege level. This can be accomplished using the allow-commands or the deny-commands statement. To deny a command that would otherwise be permitted by the permissions keywords, include the set deny-commands <commands to be denied> command at the [edit system login class <class-name>] level in the JUNOS hierarchy. To allow commands that would otherwise be denied by the permissions keywords, use set allow-commands . [edit system login class bigdogs] lab@Chicago# set deny-commands ? Possible completions: <deny-commands> Regular expression for commands to deny explicitly JUNOS allows the inclusion of only one deny-commands and only one allow-commands statement for each defined login class. If it is necessary to have multiple commands listed in either the allow or deny category, then it is possible to use what is known as a regular expression to build the configuration. Regular expressions contain wild cards, known as operators, that have special meaning when used within this command context. The most frequently used operator is (the pipe). It is used to separate multiple commands within a single allow-commands or deny-commands statement. Table 5-2 identifies and other regular expression operators. Table 5-2. Regular Expression Operators
The configuration fragment below demonstrates the use of the operator within a regular expression that is being used for the allow-commands . The login class that is defined in the sample below would be appropriate for employees responsible for software maintenance on the Juniper Networks router. The permissions settings deny access to all commands except show , but the allow-commands setting explicitly permits the user to upgrade software. Remember that in order for a software update to take effect, the router must be rebooted. [edit system login class admin-trainee] lab@Chicago# set permissions view [edit system login class admin-trainee] lab@Chicago# set allow-commands "request system software add request system reboot" [edit system login class admin-trainee] lab@Chicago# show permissions view; allow-commands "request system software add request system reboot"; The next example shows the layout of a login class that will give all users assigned to it the normal administrative assistant privileges as defined by keywords clear , network , reset , trace , and view , plus the ability to reboot or halt the router as needed: [edit system login class orin-admin] lab@Chicago# set permissions [clear network reset trace view] [edit system login class orin-admin] lab@Chicago# set allow-commands "request system halt request system reboot" [edit system login class orin-admin] lab@Chicago# show permissions [ clear network reset trace view ]; allow-commands "request system halt request system reboot"; The login class that is defined in the sample below has some administrative assistant privileges, but is explicitly denied the usage of any commands that begin with set , clear , or delete : [edit system login class russell-admin] lab@Chicago# set permissions [network reset trace view] [edit system login class russell-admin] lab@Chicago# set deny-commands "^set^delete^clear" [edit system login class russell-admin] lab@Chicago# show permissions [ network reset trace view ]; deny-commands "^set^delete^clear"; 5.2.2 Defining User AccountsAfter the login classes have been completed, it is necessary to define a user account for each user that will be accessing the router. For each of the accounts, the administrator should define a unique login name for the user. In versions of JUNOS up to and including 4.4, the username is limited to eight characters. After JUNOS 5.0, the username is limited to 16 characters. There are also options available for adding more detailed information to help identify the user. The options available are shown in the following example: [edit system login user gsondere] lab@Chicago# set ? Possible completions: + apply-groups Groups from which to inherit configuration data > authentication Authentication method class Login class full-name Full name uid User identifier (uid) (100..64000) Note As soon as the account has been built and the configuration committed, JUNOS constructs a home directory for the user. The home directory is located under /var/home/<username> in the UNIX directory structure. 5.2.2.1 Specifying a Login ClassThe configuration example below shows how to specify a login class for a user. This configuration point is not optional. Executing this specific command will both define the user's login name and identify a class to be associated with the user. See Section 5.2.1.1 for a complete description of the login-class concept. [edit system login] lab@Chicago# set user gsondere class admin-trainee [edit system login] lab@Chicago# edit user gsondere [edit system login user gsondere] lab@Chicago# show class admin-trainee; Once a username has been specified, adding the user's full name to the user configuration is a handy option. If the full name contains spaces then it must be enclosed in quotation marks as is shown in the command string below: [edit system login user gsondere] lab@Chicago# set full-name "Gordon Sonderegger" [edit system login user gsondere] lab@Chicago# show full-name "Gordon Sonderegger"; class admin-trainee; 5.2.2.2 Setting the User IdentifierThe user identifier (UID) is an optional attribute that can be added to the user's configuration. It is used for tracking user activity by some processes in JUNOS software and is a simple numeric identifier associated with the username. The identifier must fall within the range of 1,000 to 64,000 and must be unique within the router. If no UID is assigned to a username, JUNOS assigns one when the configuration is successfully committed. The sample below shows the addition of a valid UID to the configuration for user gsondere . [edit system login user gsondere ] lab@Chicago# set uid 1001 [edit system login user gsondere] lab@Chicago# show full-name "Gordon Sonderegger"; uid 1001; class admin-trainee; 5.2.2.3 Setting Local AuthenticationSetting local authentication is optional, and if it is not specified, then the user will not be prompted for a password when entering the router. The authors recommend that every user have some form of authentication configured. There are several authentication options available, including plain-text password and encrypted password. The plain-text-password option assumes that the user will be typing in a password that will need to be put through the Message Digest 5 (MD5) encryption algorithm before being placed into the configuration. The encrypted-password option assumes that the user will paste in a password that has already been put through the MD5 algorithm. In either case the configuration will always show the password as an encrypted password and will never contain an account password in a plain-text format. For each method, specify the user's password. If the plain-text-password option is used, then the password must be typed in twice, exactly the same way, to allow the operating system to confirm it. In the sample below, a plain-text password is being set for user gsondere : [edit system login user gsondere] lab@Chicago# set authentication plain-text-password New password: <password> Retype new password: <retype password> After password authentication has been added, it will appear in the user's configuration as shown in the sample below. Notice that the password has been encrypted and is identified by the software as such. [edit system login user gsondere] lab@Chicago# show full-name "Gordon Sonderegger"; uid 1001; class superuser; authentication { encrypted-password "$oA5MLkba$g6j.laUNOl8EV2kK1QjXK0"; # SECRET-DATA } An account for the user root is by default built into the configuration and by default has no password. However, it is highly recommended that one immediately set up password protection for the root account. The password for account root is configured using the root-authentication statement at the [edit system] hierarchy level. This is a critical task in the responsibilities of a system administrator and should not be overlooked. [edit system] lab@Chicago# set root-authentication plain-text-password New password: Retype new password: [edit system] lab@Chicago# show host-name Chicago; root-authentication { encrypted-password "$ccZHntfP$TcMEHnZp04/FfpVYJbnPX/"; # SECRET-DATA } login { class admin-trainee { permissions view; allow-commands "request system software add request system reboot"; } class bigdogs { idle-timeout 30; permissions all; } class orin-admin { permissions [ clear network reset trace view ]; allow-commands "request system halt request system reboot"; } class russell-admin { permissions [ network reset trace view ]; deny-commands "^set^delete^clear"; } user gsondere { full-name "Gordon Sonderegger"; uid 1001; class admin-trainee; } } In the configuration samples below, four user accounts are shown. For each of the users, a full name was added for clarity. The first two users were given a password using the plain-text option. The third was given a password using the encrypted option. These samples demonstrate some of the settings combinations available when adding users to the system. [edit system login] lab@Chicago# show user branimir { full-name "Branimir Maric"; uid 1001; class superuser; authentication { encrypted-password "awertcawexwer54gfwe"; # SECRET-DATA } } user mario { full-name "Mario Jurcevic"; uid 1002; class admin-trainee; authentication { encrypted-password "786fvo8jo7674cd6u744*%&vo"; # SECRET-DATA } } user drazen{ full-name "Drazen Kedmenec"; uid 1003; class admin-trainee; authentication { encrypted-password "iuycrbqewrts123654vuqwuq" # SECRET-DATA } } user ladislov { full-name "Ladislov Topic"; uid 1004; class unauthorized; } As was mentioned previously, the unauthorized login class may seem ridiculous at first. Why would an administrator want to build an account for a user and then give him no permissions? In truth, there could be several valid reasons for adding this configuration element. First, there may be future plans for allowing the user to execute commands on the router, at which time the user's login class will be updated to reflect the new responsibilities. A second possible reason could be a system administrator's desire to see what the user will attempt to access. This could be tracked by turning on the logging features that are built into JUNOS. Logging features are described in Section 5.2.8. 5.2.3 Password RecoveryRegardless of the ability and experience of the system administrator, organizational changes can sometimes make password recovery a necessity. For those who have never encountered the term , password recovery is a means of gaining access to a router when a valid password is unknown. Obviously, having a built-in back door such as this puts the entire network at risk for a security breach. Therefore, measures must be taken to secure the Juniper Networks router from this type of unauthorized access. The measures should include placing all critical network devices behind a locked door. This simple measure is an often-overlooked administrative duty. Having explained the need for locked-door security, we present the steps below. They describe one possible method of gaining access to the router without a valid password. These steps should only be used as a last resort and certainly at off-peak times in a production network as they do require a reboot of the router.
In the configuration sample below user jsclass is an administrator and has forgotten his password. He followed the steps listed above to gain access to the CLI as root . He will now delete and rebuild his username, making sure to add a more memorable password. root@Chicago> edit Entering configuration mode [edit] root@Chicago# delete system login user jsclass [edit] root@Chicago# set system login user jsclass class superuser authentication plain-text-password New password: Retype new password: Once the changes are complete, it is necessary to commit. Once the commit completes, a request system reboot command is necessary to get out of single-user mode. The sample below shows execution of the reboot command: [edit] root@Chicago# commit Commit complete root@Chicago# exit Exiting Configuration mode root@Chicago> request system reboot Reboot the system ? [yes,no] (no) yes Following the reboot, it is possible to login as needed, using the new password. Note Juniper Networks' Technical Documentation Set version 5.1 includes a few other steps as part of the password-recovery process. These steps involve manually mounting specific software processes while in the UNIX shell. Once started, these processes will permit the M-Series router to forward traffic while the password-recovery steps are being executed. For a complete list of the processes to be mounted, see Juniper Networks' Technical Documentation Set. 5.2.4 Authentication MethodsRADIUS and Terminal Access Controller Access Control System + (TACACS+) are authentication methods that rely on network connectivity as opposed to local machine login/password authentication. The Juniper Networks router can be configured to authenticate access attempts through Telnet using RADIUS or TACACS+, or both. In situations where both have been configured, it is also possible to specify which method to try first. NTP should also be configured for either of the authentication methods to work. Both TACACS+ and RADIUS rely on a timestamp to keep people from sniffing packets and using them again to gain access, so if the clocks are not synchronized, then authorization will fail. NTP configuration is described in detail in Section 5.2.9. The following sections introduce a bit of operational theory for the two authentication methods and then the statements that will be used to configure each on the router. 5.2.4.1 RADIUSRADIUS uses the transport protocol UDP to move requests for access from the Juniper Networks router to the RADIUS server for authentication. The password keyed in by the user is included in the request. At the RADIUS server, the password is checked against the database to determine the legitimacy of the login attempt. If the username and password are valid according to the RADIUS server, then access to the router is granted. If the username or password is invalid, then access to the router is not granted, and a denial message is returned to the user. The paragraphs that follow include examples and descriptions of the commands used to configure RADIUS authentication on the Juniper Networks M-Series routers. RADIUS authentication is enabled on the router by configuring the location of a RADIUS server. To do this, use the radius-server statement at the [edit system] hierarchy level. In the example below, the RADIUS server is located at IP address 192.168.100.1 . For the sake of clarity, only output pertinent to the RADIUS configuration is listed under the show command below: [edit system] lab@Chicago# set radius-server 192.168.100.1 [edit system] lab@Chicago# show radius-server { 192.168.100.1; } As is specified in RFC 2138, when a RADIUS server is contacted, port 1812 is used for the connection. It is possible to override this default by using the set port <port#> command at the [edit system radius-server <address>] hierarchy level in the configuration. In the example below, the default port number is overridden and set to 1492, although in most situations such a change is not necessary: [edit system radius-server 192.168.100.1] lab@Chicago# set port 1492 [edit system radius-server 192.168.100.1] lab@Chicago# show 192.168.100.1 port 1492; For RADIUS authentication to function, it is necessary to specify a password that the Juniper Networks router can pass to the RADIUS server. This is used to confirm the identity of the device that is requesting authentication of a potential user. The password must be configured on both the router and the RADIUS server. On the router it is configured using the secret statement at the [edit system radius-server <address>] hierarchy level. In the configuration sample below, we used Gabby as the password for RADIUS-client authentication. [edit system radius-server 192.168.100.1] lab@Chicago# set secret gabby As is shown in the configuration sample below, when the show command is used to view the password, the password has been encrypted within the configuration: [edit system radius-server 192.168.100.1] lab@Chicago# show 192.168.100.1 { port 1492; secret "$kP5Fn6Au0IUjBE"; # SECRET-DATA } It is also possible to configure RADIUS to attempt to authenticate users multiple times. This is accomplished by using the set retry command as shown below. In this example, the RADIUS server will attempt to authenticate the identity of the user three times. [edit system radius-server 192.168.100.1 { lab@Chicago# set retry 3 [edit system radius-server 192.168.100.1] lab@Chicago# show 192.168.100.1 { port 1492; secret "$kP5Fn6Au0IUjBE"; # SECRET-DATA retry 3; } In some situations it may also be necessary to configure a higher timeout interval. By default, the router will wait three seconds for a response from the server. Changing the default would be necessary in situations where network latency is expected or when there will be a high number of users attempting to authenticate through the same server simultaneously . This situation is commonly experienced in most businesses at around 8:00 A.M. every morning. The timeout interval is set using the set timeout command as is shown below. In this example, there will be three attempts at authentication, each with a timeout interval of 90 seconds. [edit system radius-server 192.168.100.1] lab@Chicago# set timeout 90 [edit system radius-server 192.168.100.1] lab@Chicago# show 192.168.100.1 { port 1492; secret "$kP5Fn6Au0IUjBE"; # SECRET-DATA timeout 90; retry 3; } 5.2.4.2 Juniper NetworksSpecific RADIUSThe Juniper Networks implementation of RADIUS supports some unique attributes. These are known as vendor-specific attributes (VSAs) and are loosely described in RFC 2138. Juniper Networks VSAs are identified by vendor ID 2636 in the packets sent to the RADIUS server. This is the vendor ID assigned to Juniper Networks, Inc. The following attributes are unique to Juniper Networks:
Note Because it uses UDP, RADIUS authentication has less overhead than TACACS+ and is therefore used more frequently in high-traffic situations. This in no way implies that RADIUS authentication is less secure. It is simply based on a different transport method. 5.2.5 TACACS+TACACS+ uses a TCP connection for the transport of the encrypted password and access request. This method of authentication is used less frequently in high-traffic situations as the TCP connection, by nature, has more overhead and burns up more bandwidth. This section shows the commands used to configure TACACS+ authentication on Juniper Networks routers. In the first configuration sample, we enable TACACS+ authentication by specifying the IP address of a TACACS+ server. In the following example, the server is located at 192.168.100.2 . For the sake of clarity, only output pertinent to the TACACS+ configuration is listed under the show command. [edit system] lab@Chicago# set tacplus-server 192.168.100.2 [edit system] lab@Chicago# show tacplus-server { 192.168.100.2; } As with RADIUS, with TACACS+ we must first specify a password to be sent to the server to authenticate the identity of the router that is requesting authentication of a potential user. This step is necessary in order for TACACS+ authentication to function. We specify a password using the secret statement as shown below. In this example, we use zappa as the password, but again, when the password is viewed in the configuration, it is in an encrypted format: [edit system tacplus-server 192.168.100.2] lab@Chicago# set secret zappa [edit system tacplus-server 192.168.100.2] lab@Chicago# show 192.168.100.2 { secret "$AJL/uEyleW8xdSreW"; # SECRET-DATA } It is also possible to change the default timeout interval for connection attempts by the router to the TACACS+ server. The default interval is three seconds. To change this interval, use the timeout statement at the [edit system tacplus-server <address>] hierarchy level as is shown below. In this example, we anticipate some network delay and want to allow the TACACS+ server 45 seconds to respond to our authentication request. The maximum allowable limit for the timeout value is 90 seconds. [edit system tacplus-server 192.168.100.2] lab@Chicago# set timeout 45 [edit system tacplus-server 192.168.100.2] lab@Chicago# show 192.168.100.2 { secret "$AJL/uEyleW8xdSreW"; # SECRET-DATA timeout 45; } It is also possible to configure the router to order the server to permit only one open TCP connection for multiple requests. This reduces the burden on bandwidth resources that would be caused by having an individual TCP connection open for every authentication attempt. It is possible to configure the router to enforce the single-connection rule by using the set single-connection command at the level of hierarchy shown below: [edit system tacplus-server 192.168.100.2] lab@Chicago# set single-connection [edit system tacplus-server 192.168.100.2] lab@Chicago# show 192.168.100.2 { secret "$AJL/uEyleW8xdSreW"; # SECRET-DATA timeout 45; single-connection; } To configure multiple TACACS+ servers, simply include multiple set tacplus-server commands while at the [edit system] hierarchy level as is shown in the configuration sample below. It really is just that simple. In this example, we want to configure three authentication servers residing at addresses 192.168.100.1 through 192.168.100.3 . All should be configured with the same router authentication password, enforce a single TCP connection, and have a timeout value of 45 seconds. This is how it would be done with minimal keystrokes: [edit] lab@Chicago# edit system tacplus-server 192.168.100.2 [edit system tacplus-server 192.168.100.2] lab@Chicago# set secret zappa [edit system tacplus-server 192.168.100.2] lab@Chicago# set timeout 45 [edit system tacplus-server 192.168.100.2] lab@Chicago# set single-connection [edit system tacplus-server 192.168.100.2] lab@Chicago# up [edit system tacplus-server] lab@Chicago# copy 192.168.100.2 to 192.168.100.1 [edit system tacplus-server] lab@Chicago# copy 192.168.100.2 to 192.168.100.3 [edit system tacplus-server] lab@Chicago# show 192.168.100.2 { secret "$.fnCtpB1godEy9ApB"; # SECRET-DATA timeout 45; single-connection; } 192.168.100.1 { secret "$.fnCtpB1godEy9ApB"; # SECRET-DATA timeout 45; single-connection; } 192.168.100.3 { secret "$.fnCtpB1godEy9ApB"; # SECRET-DATA timeout 45; single-connection; } 5.2.5.1 Shared User AccountsWhen using JUNOS software for local authentication, it is a good idea to create a private account for every individual who will be accessing the router. It is possible, however, to create only a small number of user accounts and allow many users to utilize them. Both RADIUS and TACACS+ authentication methods support shared accounts. Once a shared account is configured, any user who knows the password can make use of it. To create a shared user account, build the account as normal and name it remote. The remote account is recognized by both RADIUS and TACACS+ as a shared user account, and either server will allow multiple users to authenticate simultaneously using this account. The sample below shows the remote user account. We have chosen to give it a user ID number of 5555. We have also used a custom login class named custom-restricted. We gave the account a full name of Remote Access Shared Account as a reminder of what this user account was designed for. Configuration of an account named remote does not automatically enable remote authentication. It is still necessary to configure a reachable authentication server. [edit system login user remote] lab@Chicago# show full-name "Remote Access Shared Account"; uid 5555; class custom-restricted; 5.2.6 Dynamic Host Configuration Protocol RelayThe Juniper Networks router can be configured to function as a Dynamic Host Configuration Protocol (DHCP) relay agent. What this means is that a local host can request DHCP information, such as an IP address, subnet mask, and default gateway, and if no DHCP server resides on the local network, the router will forward the request to a preconfigured DHCP server on a different network or subnet. It is only necessary to configure the router to be a DHCP relay agent if there are locally attached hosts that rely on DHCP information from a remote server. If there are no local hosts that require DHCP information, then this configuration step is not recommended by the authors and is definitely not necessary. To configure the router to function as a DHCP relay agent, use the set server <ip-address of server> command at the [edit system dhcp-relay] level of hierarchy. In the example below, the router has local hosts relying on a remote DHCP server that is located at IP address 40.10.10.5 : [edit system dhcp-relay] lab@Chicago# set server 40.10.10.5 [edit system dhcp-relay] lab@Chicago# show server 40.10.10.5; Note The Juniper Networks M-Series router, itself, cannot function as a DHCP server. It can only forward requests for DHCP information. 5.2.7 System ServicesBy default, the server functionality of common services that would permit remote access is disabled on the Juniper Networks router. While the client side is enabled by default, the server functionality for Telnet, SSH, and FTP must be enabled under the [edit system services] level of the JUNOS hierarchy. The following sections describe how to configure the server functionality of these services. Note Configuration of the management Ethernet ( fxp0 ) connection is a prerequisite for functioning as a server for Telnet sessions, SSH, or FTP across the management LAN. 5.2.7.1 TelnetThe Telnet service is the workhorse of the remote-access world. Through Telnet, it is possible to establish a connection to a device and generate a screen that looks and functions as if the user had logged directly into the device. In the Juniper Networks world, and in most other implementations , the Telnet service requires that the user issuing the Telnet request have a valid user account and password on the target device. The Telnet service is enabled using the set telnet command as shown below. Keep in mind that enabling Telnet does not open Telnet sessions; it simply allows sessions to be opened as needed. [edit system services] lab@Chicago# set telnet JUNOS software includes provisions that make it possible to limit the number of simultaneous Telnet connections and set a limit on the number of connection attempts per minute. The configuration example below shows Telnet enabled with a maximum of three simultaneous connections and a maximum of ten connection attempts per minute. In these examples, the help feature is used to see the maximum allowable settings for both the number of simultaneous connections and the number of connection attempts per minute. [edit system services telnet] lab@Chicago# set connection-limit ? Possible completions: <connection-limit> Maximum number of allowed connections (1..250) [edit system services telnet] lab@Chicago# set connection-limit 3 [edit system services telnet] lab@Chicago# set rate-limit ? Possible completions: <rate-limit> Maximum number of connections per minute (1..250) [edit system services telnet] lab@Chicago# set rate-limit 10 [edit system services telnet] lab@Chicago# show connection-limit 3; rate-limit 10; After the Telnet service has been configured, it can be used to connect to other devices on which Telnet is also enabled. The syntax for making a Telnet connection from a Juniper Networks router is shown on the following page. The command is launched from operational mode or can be launched from configuration mode if the run command is used. This example shows Telnet being launched from operational mode to connect to a router with an IP address of 192.168.151.3 : lab@Chicago> telnet 192.168.151.3 Trying 192.168.151.3... Connected to 192.168.151.3. Escape character is '^]'. Denver (ttyp0) login: The string shown below demonstrates the telnet command being executed from within configuration mode, using the run command: [edit protocols ospf area 0] lab@Chicago# run telnet 192.168.161.27 Trying 192.168.161.27... Connected to 192.168.161.27. Escape character is '^]'. Melbourne (ttyp0) login: bonnie Password: Last login: Thu Mar 7 08:43:31 from 192.168.161.10 --- JUNOS 5.1R1.4 built 2001-11-01 19:09:34 UTC bonnie@Melbourne> The telnet command was successful and user bonnie was prompted for a username and password to access the Melbourne router. User bonnie was able to establish this connection because her UID and password had already been configured on the Melbourne router. Note The Juniper Networks implementation of Telnet does not permit Telnet connections to be established by user root . This is a built in safety feature of the operating system. 5.2.7.2 SSHSSH is capable of accomplishing most, if not all, of the tasks that up until a few years ago were traditionally carried out using Telnet. Because of its encryption features, it is now in common use by both ISP and enterprise network engineers . However, due to U.S. government restrictions on encryption software, the SSH service is available only on the domestic version of the software. The SSH service is used first to open a connection to a remote router, then to execute individual commands on the remote router. The service must be running on both Juniper Networks devices involved in SSH communication. To start the SSH service on the Juniper Networks router, use the set ssh command from the [edit system services] level of hierarchy as is shown in the sample below: [edit system services] lab@Chicago# set ssh As with Telnet, with SSH it is also possible to limit the number of simultaneous SSH connections and set a limit on the number of connection attempts per minute. The configuration example below shows SSH enabled with a maximum of five simultaneous connections and a maximum of ten connection attempts per minute. The help function is used to demonstrate the allowable parameters for these options: [edit system services ssh] lab@Chicago# set connection-limit ? Possible completions: <connection-limit> Maximum number of allowed connections (1..250) [edit system services ssh] lab@Chicago# set connection-limit 5 [edit system services ssh] lab@Chicago# set rate-limit ? Possible completions: <rate-limit> Maximum number of connections per minute (1..250) [edit system services ssh] lab@Chicago# set rate-limit 10 [edit system services ssh] lab@Chicago# show connection-limit 5; rate-limit 10; After the SSH service has been configured, it can be used from operational mode to establish a connection with another device and run commands on the device. To establish a connection with a Juniper Networks M-Series router with an IP address of 192.168.161.17 and then run a show chassis hardware command, use the following syntax: lab@Chicago> ssh 192.168.161.17 RSA key fingerprint is 7d:c7:5c:26:2d:90:12:fe:76:6b:35:3c:ca:b2:87:ea. Are you sure you want to continue connecting (yes/no)? yes lab@192.168.161.17's password: Last login: Sun Mar 31 20:38:50 2002 --- JUNOS 5.2R1.4 built 2002-01-30 17:03:27 UTC --- --- NOTICE: System is running on alternate media device (/dev/ad1s1a). --- lab@HongKong> show chassis hardware Hardware inventory: Item Version Part number Serial number Description Chassis 21009 M20 Backplane REV 07 710-001517 AB7116 Power Supply A REV 03 740-001465 001221 AC Power Supply B REV 03 740-001465 001214 AC Display REV 04 710-001519 AF3244 Host 0 dd00000792cf3401 teknor SSB slot 0 REV 01 710-001951 AF1358 Internet Processor II SSB slot 1 N/A N/A N/A backup FPC 1 REV 01 710-001292 AC5929 PIC 1 REV 07 750-002303 AF7216 4x F/E, 100 BASE-TX PIC 2 REV 03 750-000603 AA4506 4x OC-3 SONET, SMIR PIC 3 REV 04 750-000611 AA4272 4x OC-3 SONET, MM FPC 2 REV 01 710-001292 AF3526 PIC 1 REV 06 750-000616 AA6698 1x OC-12 ATM, MM FPC 3 REV 01 710-001292 AB2174 PIC 0 REV 08 750-001072 AG4470 1x G/E, 1000 BASE-SX PIC 1 REV 08 750-001072 AC4777 1x G/E, 1000 BASE-SX lab@HongKong> The command string below shows user lab closing his SSH session to the Hong Kong router and returning to the Chicago CLI: lab@HongKong> exit Connection to 192.168.161.17 closed. [edit] lab@Chicago# 5.2.7.3 FTPJUNOS also contains provisions that allow FTP to be enabled. FTP, for those unfamiliar with the protocol, does exactly what the name implies: It gives the ability to copy files efficiently from file system locations on one device to file system locations on another device over an IP network connection. FTP uses TCP ports 20 and 21 to make the transfer. In order for FTP to function, it must be enabled on both Juniper Networks devices involved in the transfer. The syntax for enabling FTP on a Juniper Networks M-Series router is comparable to what we have seen for Telnet and SSH. [edit system services] lab@Chicago# set ftp [edit system services] lab@Chicago# show ftp; As with the other services, limitations on the number of simultaneous connections and number of connection attempts can be placed on FTP. The configuration sample below shows FTP enabled with a maximum of one connection and a maximum of five connection attempts per minute. Again, the help feature is used to display the maximum allowable parameters for these options. [edit system services ftp] lab@Chicago# set connection-limit ? Possible completions: <connection-limit> Maximum number of allowed connections (1..250) [edit system services ftp] lab@Chicago# set connection-limit 1 [edit system services ftp] lab@Chicago# set rate-limit ? Possible completions: <rate-limit> Maximum number of connections per minute (1..250) [edit system services ftp] lab@Chicago# set rate-limit 5 [edit system services ftp] lab@Chicago# show connection-limit 1; rate-limit 5; Enabling the FTP service does not open any FTP connections. To establish an FTP connection, it is necessary to launch an FTP session. Once an FTP session is launched, the Juniper Networks implementation supports the full range of standard FTP commands, as well as all FreeBSD UNIX commands. An FTP session is launched either from operational mode or from a UNIX shell. The syntax for launching FTP from a shell is shown next: lab@Chicago> startshell %ftp 192.168.161.14 Connected to 192.168.161.17. 220 HongKong FTP server (Version 6.00LS) ready. Name (192.168.161.17:lab): 331 Password required for lab. Password: 230 User lab logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> In the command string below, a file called baseline is being pulled through FTP from the Hong Kong router back to the Chicago router. This file will be placed in the /var/home/lab directory under the filename baseline on the Chicago router. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for '/bin/ls'. total 54 drwxr-xr-x 2 lab staff 512 Mar 21 15:40 .ssh -rw-r---r--- 1 lab staff 5295 Mar 24 19:43 L2_vpn -rw-r---r--- 1 lab staff 4806 Mar 24 13:13 L3_vpn -rw-r---r--- 1 lab staff 1110 Mar 21 15:44 baseline -rw-r---r--- 1 lab staff 3588 Mar 22 20:26 bgp_core -rw-r---r--- 1 lab staff 5238 Mar 25 18:40 inter_prov_vpn -rw-r---r--- 1 lab staff 2427 Mar 22 15:42 interfaces 226 Transfer complete. ftp> mget baseline mget baseline? 200 PORT command successful. 150 Opening BINARY mode data connection for 'baseline' (1110 bytes). 100% 1110 00:00 ETA 226 Transfer complete. 1110 bytes received in 0.00 seconds (608.30 KB/s) To end the FTP connection, use the bye command. This will return the cursor to a UNIX shell prompt. From within the UNIX shell, use the exit command to get back to the CLI. ftp> bye 221 Goodbye. % exit lab@Chicago> While the protocol is useful in training-lab environments, Juniper Networks does not officially support FTP on the M-Series routers, and it highly recommends that this service not be enabled on routers used in a production network. FTP is extremely useful in some situations, such as when passing a new software release from router to router, but it could be exploited in negative ways. Because of its encryption capabilities, a safer alternative to FTP is the Secure Copy Protocol (SCP). 5.2.7.4 SCPSCP accomplishes the same functions as the FTP protocol, but operates through an SSH connection. Therefore, to run SCP, the SSH service must be enabled on the router that is receiving the connection. See Section 5.2.7.2 for an explanation of how to configure SSH. The example below shows the command string used to launch an SCP connection from the Chicago router to the Hong Kong router and push a file called baseline from Chicago to Hong Kong. In this example, the Hong Kong router will function as an SSH server; therefore, the SSH service must be enabled on Hong Kong. lab@Chicago> file list .ssh/ baseline jinstall-5.0R1.4-domestic.tgz lab@Chicago> file copy baseline scp://192.168.161.17/var/home/lab/. lab@192.168.161.17's password: baseline 100% ***************************** 1666 00:00 To confirm that the file has been copied to the Hong Kong router, we can establish an SSH connection and check the home directory of user lab as is shown in the example below: lab@Chicago> ssh 192.168.161.17 lab@192.168.161.17's password: Last login: Sun Mar 31 20:40:43 2002 from 192.168.161.30 --- JUNOS 5.2R1.4 built 2002-01-30 17:03:27 UTC --- --- NOTICE: System is running on alternate media device (/dev/ad1s1a). --- lab@HongKong> file list .ssh/ baseline ed-hongkong-032602 mplslab.conf reset rsvp.conf venulab.conf lab@HongKong> exit Connection to 192.168.161.17 closed. lab@Chicago> 5.2.8 System LoggingSystem logging is a way to build files that store a record of activity within the router. This feature can track alarms, warning messages, instances of users logging on and off, specific commands executed by users, and virtually any other event that takes place on the router. System logging operations are enabled by default and record events that would be of importance to the system administrator, such as component failure. System logging can be configured to catch more trivial events, such as execution of commands or user login attempts. To configure system-logging parameters and control how much information the system archives, use the set syslog <syslog options> command at the [edit system] level of the JUNOS hierarchy as is shown in the example below. By default, the data collected will be placed in 128K files. Up to ten of these files will be created as data is collected. Also by default, the only user who can read the files is the user who created them, the root user, and users with a login class of super-user. In the example below, some of the default syslog settings are overridden. The files option is used to specify the number of files, up to five, to be used for the syslog data. The size option allows us to specify the maximum size, up to 5MB, for each of the syslog files. We have designated these files as world-readable, which will permit all other users to view them. [edit system syslog] lab@Chicago# set archive files 5 size 5m world-readable [edit system syslog] lab@Chicago# show archive size 5m files 5 world-readable; The maximum allowable number of syslog files is 1,000. The minimum allowable syslog file size is 64K. The maximum size allowable per syslog file is 1GB. The syslog files will be stored in the /var/log/ directory. Using CLI commands, it is also possible to create other files in which to store syslog information or to redirect syslog data to the console port or even a specific host. Examples of these configurations are shown below: [edit system syslog] lab@Chicago# show archive size 5m files 5 world-readable; host 124.35.35.14 { any emergency; } console { any critical; } As was mentioned previously, it is possible to change the default class of messages (type of information being stored) and the severity level within these classes. To change the class and severity level, it is necessary to use the keywords. The keyword options available are listed in the command completion example below. This list shows the options for selecting a class of messages. [edit system syslog] lab@Chicago# set console ? Possible completions: any Matches any facility authorization The authorization system change-log Configuration change log cron The cron daemon daemon Various system daemons ftp The file transfer protocol daemon interactive-commands Commands executed by the UI kernel Messages generated by the kernel pfe Messages generated by the packet forwarding engine (PFE) user Messages from random user processes Table 5-3 gives a more detailed description of the different classes of messages available. Table 5-3. Message Class for System Logging
Once a message class is determined, it is combined with a severity level to pinpoint the exact type of information to be stored in the syslog files. Severity levels and their descriptions are shown in the command completion example below: [edit system syslog] lab@Chicago# set console any ? Possible completions: alert Conditions that should be corrected immediately any Matches any level critical Critical conditions emergency Panic conditions error Error conditions info Informational messages notice Conditions that should be handled specially warning Warning messages Table 5-4 offers a more concise definition of the severity levels supported in descending order from most to least severe. Using combinations of class and severity level, it is possible to gather the exact data sought by the system administrator. The syntax for building a syslog archive using variations of these settings is shown in the next example, which uses a frequently employed combination of class and severity level to track users who log into the system and attempt to configure the router. This is done by specifying class interactive-commands and severity-level information. Table 5-4. Severity Levels for System Logging
[edit system syslog] lab@Chicago# set file bigbrother interactive-commands info [edit system syslog] lab@Chicago# set file bigbrother archive files 5 size 5m no-world-readable [edit system syslog] lab@Chicago# show file bigbrother { interactive-commands; info; archive size 5m files 5 no-world-readable; } 5.2.9 Other Administrative ResponsibilitiesThis section delves into some of the other tasks for which a system administrator is normally responsible. These tasks include setting a name and the location of the router itself, specifying a DNS, and setting the time. 5.2.9.1 Setting a Host Name and DomainAlthough it is not necessary, for organizational purposes every router should have a name. The router is assigned a name using the set host-name <name of the router> command at the [edit system] level of hierarchy in JUNOS. In the following example, the router's name is changed from Tokyo to Chicago. Remember that all of the changes made through the CLI are made to a candidate configuration. These changes do not go into effect until the candidate is committed. [edit] lab@Tokyo# set system host-name Chicago [edit] lab@Tokyo# commit commit complete [edit] lab@Chicago# The domain name in which the router is logically positioned can be defined on the router and, if configured, the domain name will be appended to host names in some domain-name lookup situations. To configure the domain name, use the set domain-name command as has been done in the sample below. For the sake of clarity only the output pertinent to the configuration tasks in this section of the chapter are included in the example below. [edit system] lab@Chicago# set domain-name TPIndustries.net [edit system] lab@Chicago# show host-name Chicago; domain-name TPIndustries.net; 5.2.9.2 Setting LocationIt is sometimes convenient to be able to learn the physical location of a router by reading its configuration, especially in remote access situations. The options listed below allow a high degree of precision when defining the location of the device: [edit system] lab@Chicago# set location ? Possible completions: altitude Feet above (or below) sea level + apply-groups Groups from which to inherit configuration data country-code Two-letter country code hcoord Bellcore horizontal coordinate lata Long-distance service area latitude Latitude in degree format longitude Longitude in degree format npa-nxx First 6 digits of phone number (area code plus exchange) postal-code Zip code or postal code vcoord Bellcore vertical coordinate [edit system location] lab@Chicago# set country-code DK [edit system location] lab@Chicago# show country-code DK; Note The output from the CLI above mentions Bellcore several times. Bellcore is short for Bell Communications Research. Among the many things, they have divided the world up into zones based on the magnitude of earthquakes possible in any given area. Those areas with the potential for the strongest earthquakes, 7.18.3 on the Richter scale, are given a Bellcore Zone rating of 4. Areas that are not subject to earthquakes, south Florida for example, are given a Bellcore Zone rating of 0. 5.2.9.3 Setting Time and DateBy default, all Juniper Networks routers are shipped set to Greenwich Mean Time (GMT). They are preconfigured to the correct time and date per the GMT time zone. A small battery within the chassis, similar to that used in a standard personal computer, maintains a running clock. Once the router has been installed, it may be necessary, or at least convenient, to change the time-zone setting. This is accomplished by using the set time-zone < continent >/<major-city> command as is shown below: [edit system] lab@Chicago# set time-zone America/Guyana [edit system] lab@Chicago# show host-name Chicago; domain-name TPIndustries.net; time-zone America/Guyana; location country-code DK; It will more than likely be necessary to use the set time-zone ? command to view the list of valid continent and city combinations. The list is rather lengthy. A small portion of it is shown next: [edit system] lab@Chicago# set time-zone ? Possible completions: Africa/Abidjan Time zone for Africa/Abidjan Africa/Accra Time zone for Africa/Accra Africa/Addis_Ababa Time zone for Africa/Addis_Ababa Africa/Algiers Time zone for Africa/Algiers Africa/Asmera Time zone for Africa/Asmera Africa/Bamako Time zone for southwest Mali Africa/Bangui Time zone for Africa/Bangui Africa/Banjul Time zone for Africa/Banjul Africa/Bissau Time zone for Africa/Bissau Africa/Blantyre Time zone for Africa/Blantyre Africa/Brazzaville Time zone for Africa/Brazzaville Africa/Bujumbura Time zone for Africa/Bujumbura Africa/Cairo Time zone for Africa/Cairo Africa/Casablanca Time zone for Africa/Casablanca Africa/Ceuta Time zone for Ceuta & Melilla Africa/Conakry Time zone for Africa/Conakry Africa/Dakar Time zone for Africa/Dakar Africa/Dar_es_Salaam Time zone for Africa/Dar_es_Salaam Africa/Djibouti Time zone for Africa/Djibouti Africa/Douala Time zone for Africa/Douala Africa/El_Aaiun Time zone for Africa/El_Aaiun Africa/Freetown Time zone for Africa/Freetown Africa/Gaborone Time zone for Africa/Gaborone Africa/Harare Time zone for Africa/Harare As with personal computers, it may occasionally be necessary to make an adjustment to the date or time on a Juniper Networks router. This is accomplished by using the set date command in the operational mode. Table 5-5 shows the format for the dates. Table 5-5. Date and Time Format for Routers
The configuration sample below demonstrates the syntax of the command as it is typed in the operational mode. In this example, the date and time have been set to reflect 15 seconds past 7:45 P.M. , January 9, 2003. lab@Chicago> set date 200301091945.15 Thu Jan 9 19:45:15 UTC 2003 lab@Chicago> show system uptime Current time: 2003-01-09 19:45:54 UTC System booted: 2003-01-04 08:20:41 UTC (5d 11:25 ago) Protocols started: 2003-01-04 08:22:01 UTC (5d 11:23 ago) Last configured: 2002-04-01 02:27:32 UTC (40w3d 17:18 ago) by lab 7:45PM up 5 days, 11:25, 1 user, load averages: 0.00, 0.00, 0.00 5.2.9.4 Using the NTPIn large-scale networks, it may be necessary to enable a means of synchronizing the routers. This is accomplished using NTP. NTP uses a subnetwork of time servers organized and operating in a hierarchical manner. Within the group of servers, there are master and slave relationships established based on the reliability of the clock within the time server. The master time server synchronizes its internal clock to national time standards through radio connections. Once the master is synchronized, the slave servers on the subnetwork synchronize to the master. The servers are then capable of distributing reference time to switches, routers, and other devices within the network. All Juniper Networks M-Series routers are capable of functioning as NTP servers with no degradation of performance or throughput. The statements needed to configure a router to be an NTP server are detailed in later paragraphs. The sample below shows the range of options available when configuring NTP. We will look in detail at some of the more commonly used options. [edit system ntp] lab@Chicago# set ? Possible completions: + apply-groups Groups from which to inherit configuration data > authentication-key Authentication key information boot-server Server to query during boot sequence > broadcast Broadcast parameters broadcast-client Listen to broadcast NTP > multicast-client Listen to multicast NTP > peer Peer parameters > server Server parameters + trusted-key List of trusted authentication The first step in configuring NTP on a Juniper Networks router is to specify the IP address of a boot server. The boot server is the NTP server that will be contacted by the router at initial boot to help the router synchronize with the time settings on all devices on the rest of the network. To specify a boot server, use the set boot-server command at the [edit system ntp] hierarchy. The example below shows the setting that would be used for an NTP server with an IP address of 192.168.151.5 : [edit system ntp] lab@Chicago# set boot-server 192.168.151.5 [edit system ntp] lab@Chicago# show boot-server 192.168.151.5; Following the specification of a boot server, it is necessary to decide what type of role the Juniper Networks router will play with regard to determining time in the network. There are three modes defined in JUNOS that relate to this role: client mode, broadcast mode, and symmetric active mode.
To configure the router to operate in client mode, use the set server command at the [edit system ntp] level of hierarchy. This will specify the NTP server to which the router will be a client. In the example below, we are designating our router as a client to an NTP server located at IP address 192.168.10.5 . [edit system ntp] lab@Chicago# set server 192.168.10.5 [edit system ntp] lab@Chicago# show server 192.168.10.5; To configure the router to operate as an NTP server, use the set broadcast command: [edit system ntp] lab@Chicago# set broadcast 192.168.0.0 [edit system ntp] lab@Chicago# show broadcast 192.168.0.0; To configure the router to function as a backup or potential NTP server, use the set peer command. In the example shown below, the router being configured is one of three capable of handling NTP responsibilities. The other two devices are found at IP addresses 192.168.5.5 and 192.168.5.6 . The latter will be used as the master in this case, which is indicated by the prefer statement, and will also function as a boot server. [edit system ntp] lab@Chicago# set peer 192.168.5.6 prefer [edit system ntp] lab@Chicago# set peer 192.168.5.5 [edit system ntp] lab@Chicago# show peer 192.168.5.6 prefer; peer 192.168.5.5; Note NTP adjustments are only made in situations where the router's internal clock is set to more than 128 ms or less than 128 seconds different from the NTP master clock. If the router's internal time is less than 128 ms different, the time is slowly stepped into sequence with the NTP clock. If the time is more than 128 seconds different from the master, then it is necessary to use the set date command to bring the time to within 128 seconds of the NTP clock before synchronization will take place. 5.2.9.5 Designating a DNS ServerTo have the router resolve host names into IP addresses it is necessary to designate one or more DNSs. This is accomplished by using the set name-server command. For the sake of clarity, only the elements pertinent to this example are included in the output of the show command as follows: [edit system] lab@Chicago# set name-server 192.168.50.50 [edit system] lab@Chicago# show name-server { 192.168.50.50; }  |
EAN: 2147483647
Pages: 176