Case Study: Initial System Configuration | JNCIP: Juniper Networks Certified Internet Professional Study Guide

This section presents a list of initial system-configuration tasks that resemble the examples demonstrated throughout this chapter. For each configuration task, the relevant portions of a typical router configuration are shown and described. The complete configuration from one of the routers is provided at the end, to illustrate a known good solution for the configuration requirements provided in the case study.

Configuration Requirements

To complete this case study, you must configure all seven routers in your test bed to comply with the following criteria. It should take approximately 45 minutes to complete your configuration, and you should start with a factory-fresh JUNOS software install. A reasonable approximation of such an install will result if you load and commit the skeleton configuration found at the following location on routers running a 5.x JUNOS software version: /packages/mnt/jbase/sbin/ install/default-juniper.conf.

Whether you opt to flash your routers, or load the skeleton configuration file, your starting configuration should be similar to the following:

root@r1# show system {    syslog {       user * {          any emergency;       }       file messages {          any notice;          authorization info;       }    }  }

Assign each router a hostname of the form rn, where n is a router number in the range of 1 through 7 inclusive.
Configure the fxp0 network according to Figure 1.1, and ensure that you and the proctor station will have telnet access to all seven routers using the OoB management network.
Modify the syslog parameters to log all interactive CLI commands to a file called rn-cli, where n is equal to the router number. Configure the CLI log to permit four archived copies that will be no larger than 128K, and ensure that CLI-related logging is also sent to 10.0.200.2, which is providing a remote syslog service. All other syslog parameters should be left at their default setting.

Create user accounts and permissions based on Table 1.2.

Table 1.2: Case Study User Accounts
User/Password	Permissions	Notes
lab	superuser	Telnet, SSH version 2 only with password, and console
root	superuser	Console only
noc	View only	Telnet, SSH version 2 only with password, and console

Ensure that all users are first authenticated through RADIUS, and that the local password database is not automatically consulted should the RADIUS server become unreachable. The RADIUS secret is juniper.
Allow SNMP access from all IP addresses, but only allow SNMP request over the fxp0 interface. Use a community value of public for read-only access and private for read/ write access. Send only version 1 authentication-related traps to the SNMP server.
Configure all routers as broadcast NTP clients, and authenticate all messages using MD5, key ID 200, and key value juniper. Ensure that manual clock synchronization steps are not required. For this example, the NTP service is provided by 10.0.1.102.
Ensure that all routers display the correct value for local time. You should assume that you are testing in Sunnyvale, California.
Without using DNS, ensure that you can ping the proctor workstation using the name proctor.
Configure the router to ignore management interface link status and enable the auxiliary console port for vt100 terminals.

Configuration Examples

Each of the case study requirements will now be echoed back along with the configuration commands that would typically be used to correctly meet the operational criteria. Due to the innate flexibility of JUNOS software, multiple solutions to the case study requirements will normally exist; for example, the operator could opt to deploy configuration groups for common configuration elements such as the RADIUS server and authentication order. The examples shown next attempt to show the most common and straightforward solutions to the configuration tasks. An example of configuration group usage to support RADIUS will be provided to demonstrate this flexibility and, indirectly, to demonstrate why a JNCIP candidate is graded on results and not on their particular configuration approach.

Assign each router a hostname of the form rn, where n is a router number in the range of 1 through 7 inclusive:
```
[edit] root@host# set system host-name r2 [edit] root@host# show system host-name host-name r2;
```

Configure the fxp0 network according to Figure 1.1, and ensure that you and the proctor station will have telnet access to all seven routers using the OoB management network:

[edit] root@r2# set system services telnet [edit interfaces] root@r2# set fxp0 unit 0 family inet address 10.0.1.2/24 [edit routing-options] root@r2# set static route 10.0.200.0/24 next-hop 10.0.1.102 no-readvertise

The resulting OoB-related configuration is now as follows:

[edit] root@r2# show system services telnet; [edit] root@r2# show interfaces fxp0 unit 0 {    family inet {       address 10.0.1.2/24;    }  } root@r2# show routing-options static {    route 10.0.200.0/24 {       next-hop 10.0.1.102;       no-readvertise;    }  }

Modify the syslog parameters to log all interactive CLI commands to a file called rn-cli, where n is the router number. Configure the CLI log to permit four archived copies that will be no larger than 128K, and ensure that CLI-related logging is also sent to 10.0.200.2, which is providing a remote syslog service. All other syslog parameters must be left at their default setting:

[edit system syslog] root@r2# set file r2-cli interactive-commands any [edit system syslog] root@r2# set file r2-cli archive files 4 [edit system syslog] lab@r1# set host 10.0.200.2 interactive-commands any

The modified syslog parameters are now displayed:

[edit system syslog] lab@r1# show user * {    any emergency;  }  host 10.0.200.2 {    interactive-commands any;  }  file messages {    any notice;    authorization info;  }  file r2-cli {    interactive-commands any;    archive files 4;  }

Create user accounts and permissions based on Table 1.3.

Table 1.3: Case Study User Accounts
User/pass	permissions	Notes
lab	superuser	Telnet, SSH version 2 only with password, and console
root	superuser	Console only
noc	View only	Telnet, SSH version 2 only with password, and console

The commands used to correctly configure and display user account and permission settings are shown in Listing 1.5.

Listing 1.5: User Account Configuration

[edit system] root@r2# set root-authentication plain-text-password New password: Retype new password: [edit system login] root@r2# set user lab class superuser root@r2# set user lab authentication plain-text-password New password: Retype new password: [edit system login] root@r2# set class noc permissions view [edit system login] root@r2# set user noc class noc [edit system login] root@r2# set user noc authentication plain-text-password New password: Retype new password: [edit] root@r1# set system services ssh protocol-version v2 [edit] lab@r2# set system services ssh root-login deny [edit] lab@r2# show system services ssh {    root-login deny;    protocol-version v2;  }  telnet; [edit] root@r2# show system root-authentication encrypted-password "$1$RTyGDGYG$ukqr37VGRgtohedSlruOk/"; # SECRET-DATA [edit] root@r2# show system login class noc {    permissions view;  }  user lab {    class superuser;    authentication {       encrypted-password "$1$L6ZKKWYI$GxEI/7YzXes2JXDcHJvz7/"; # SECRET-DATA    }  }  user noc {    class noc;       authentication {       encrypted-password "$1$Z5Sb1eVg$R8.iZMCAMAOTdEeS2svvd0"; # SECRET-DATA    }  }

By default, all users except root can log in via console, telnet, or SSH. The root user can log in by using either the console or SSH by default, so to meet the criteria for this case study you must disable root's ability to log in using SSH. The correct SSH version must also be set in this example, because the default JUNOS software behavior will support SSH versions 1 and 2.

Ensure that all users are first authenticated through RADIUS, and that the local password database is not automatically consulted should the RADIUS server become unreachable. The RADIUS secret is juniper.

[edit system] root@r2# set authentication-order radius   [edit system] root@r2# set radius-server 10.0.200.2 secret juniper

The resulting system authentication configuration is now displayed:

[edit system] root@r2# show radius-server 10.0.200.2 secret "$9$-UbYoDi.z39JG39ApREdbs"; # SECRET-DATA [edit system] root@r2# show authentication-order authentication-order radius;

By omitting the password option from the system's authentication order statement, you ensure that the local password database is not automatically consulted when the RADIUS server becomes unreachable, which results in the operator being prompted for a local password in the event of RADIUS connectivity problems.

Configuration Groups

As previously mentioned, JUNOS software is extremely flexible, and this flexibility can translate to the ability to satisfy a configuration requirement using what can appear to be orthogonal approaches. Configuration groups provide excellent proof of this concept in that they allow common elements of a configuration to be specified at the [edit groups] configuration hierarchy. Once configured, these groups can then be applied to the appropriate level of the system's configuration to affect the inheritance of group-related configuration. You can override this group inheritance through explicit configuration where needed. For example, consider the following configuration group called authentication, which will result in the required RADIUS and authentication order behavior when applied as shown:

[edit] lab@r1# show groups authentication {    system {       authentication-order radius;       radius-server {          10.0.1.201 secret "$9$9ftBt0IylMNdsEcds24DjCtu"; # SECRET-DATA      }    }  }     [edit] lab@r1# set system apply-groups authentication

To confirm the correct application of a configuration group, you should pipe configuration output through the inheritance filter as shown here:

[edit] lab@r1# show system | match radius [edit] lab@r1# show system | display inheritance | match radius ## 'radius' was inherited from group 'authentication' authentication-order radius; radius-server {

You should practice with the effects of configuration group usage before deciding to deploy the technique on a live examination. Some candidates have been burned by failing to completely anticipate the effects of configuration group usage. For example, the inadvertent configuration (and operation) of an IGP on your fxp0 OoB management interface (which is never a good idea) can easily result when a configuration group is used to add protocol families to your interfaces in conjunction with a command such as set protocol isis interface all.

Allow SNMP access from all IP addresses, but only allow SNMP request over the fxp0 interface. Use a community value of public for read-only access and private for read/ write access. Send only version 1 authentication-related traps to the SNMP server:

[edit snmp] root@r2# set interface fxp0 [edit snmp] root@r2# set community public [edit snmp] root@r2# set trap-group foo categories authentication [edit snmp] root@r2# set trap-group foo targets 10.0.200.2 [edit snmp] root@r2# set community private authorization read-write

The resulting configuration changes are now confirmed:

[edit snmp] root@r2# show interface fxp0.0; community public; community private {    authorization read-write;  }  trap-group foo {    version v1;    categories authentication;    targets {       10.0.200.2;    }  }

By including interface fxp0, you disallow access from all other interfaces. The lack of a client statement results in the default of access being allowed from all clients. The default for SNMP traps is to send both version 1 and version 2, so version 1 traps must be specified.

Configure your routers as broadcast NTP clients, and authenticate all messages using MD5, key ID 200, key value juniper. Ensure that manual clock synchronization steps are not required. For this example, you may assume that the NTP service is provided by 10.0.1.102:

[edit system ntp] root@r2# set authentication-key 200 type md5 value juniper [edit system ntp] root@r2# set trusted-key 200 [edit system ntp] root@r2# set broadcast-client [edit system ntp] root@r2# set boot-server 10.0.1.102

Once again, the changes to the configuration are confirmed:

[edit system ntp] root@r2# show boot-server 10.0.1.102; authentication-key 200 type md5 value "$9$KoAWX-YgJHqfVwqfTzCAvWL"; # SECRET-DATA broadcast-client; trusted-key 200;

Because manual synchronization is not permitted in this example, you must include the boot-server statement to allow initial clock synchronization at boot. You must also configure your router as a broadcast client to tell it to listen to NTP broadcasts. If all goes according to plan, you should have NTP associations like the following example on all your routers after they are rebooted; it should be noted that the server type (t) is now set to broadcast (b):

root@r1> show ntp associations      remote       refid      st t when poll  reach    delay  offset   jitter ============================================================================== *10.0.1.102    LOCAL(1)      11 b    -   64  377      0.000  39.204   1.045

Ensure that all routers display the correct value for local time. You should assume that you are testing in Sunnyvale, California:
```
[edit system] root@r2# set time-zone America/Los_Angeles 
```
There is no CLI option for America/Sunnyvale, but Los Angeles and the San Francisco Bay Area are both on Pacific Time so this does the trick.
Without using DNS, ensure that you can ping the proctor workstation using the name proctor.

You must configure a static host mapping to accomplish this task because DNS services are not available in this example:
```
[edit system] lab@r2# set static-host-mapping proctor inet 10.0.200.1 
```

Configure the router to ignore management interface link status and enable the auxiliary console port for vt100 terminals.

[edit chassis alarm] lab@r2# set management-ethernet link-down ignore [edit system ports] lab@r2# set auxiliary type vt100

The Completed Case Study Configuration

The configuration of r2 is shown in Listing 1.6. This configuration satisfies all case study requirements.

Listing 1.6: Case Study Configuration for r2

[edit] lab@r2# show | no-more version 5.2R2.3; system {    host-name r2;    time-zone America/Los_Angeles;    authentication-order radius;  ports {   auxiliary type vt100;  }  root-authentication {    encrypted-password "$1$RTyGDGYG$ukqr37VGRgtohedSlruOk/"; # SECRET-DATA  }  radius-server {     10.0.200.2 secret "$9$-UbYoDi.z39JG39ApREdbs"; #  SECRET-DATA  }  login {     class noc {        permissions view;  }  user lab {     uid 2000;     class superuser;     authentication {        encrypted-password "$1$L6ZKKWYI$GxEI/7YzXes2JXDcHJvz7/"; #   SECRET-DATA     }  }  user noc {     uid 2001;     class noc;     authentication {        encrypted-password "$1$Z5Sb1eVg$R8.iZMCAMAOTdEeS2svvd0"; #   SECRET-DATA     }   } } static-host-mapping {    proctor inet 10.0.200.1; } services {    ssh {       root-login deny;       protocol-version v2;    }    telnet; } syslog {    user * {       any emergency;    }    host 10.0.200.2 {       interactive-commands any;    }    file messages {       any notice;       authorization info;    }    file r2-cli {       interactive-commands any;       archive files 4;    }  }  ntp {    boot-server 10.0.1.102;    authentication-key 200 type md5 value "$9$KoAWX-YgJHqfVwqfTzCAvWL"; #   SECRET-DATA    broadcast-client;    trusted-key 200;  }  }  chassis {    alarm {       management-ethernet {          link-down ignore;       }    }  }  interfaces {    fxp0 {       unit 0 {         family inet {            address 10.0.1.2/24;         }       }    }  }  snmp {    interface fxp0.0;    community public;    community private {       authorization read-write;    }    trap-group foo {       version v1;       categories authentication;       targets {          10.0.200.2;       }    }  }  routing-options {    static {       route 10.0.200.0/24 next-hop 10.0.1.102;    }  }

You should now ensure that the remaining routers in your test bed have a similar initial system configuration. The use of cut and paste using load override terminal is recommended as a time-saving technique. You should attempt to validate as much of your initial configuration as possible using the techniques demonstrated in this chapter because "silly" mistakes such as fat- fingering the IP address associated with the proctor subnet are hard to spot when simply viewing the router's configuration.