Your Initial System Configuration

After performing the configuration tasks outlined in this chapter, you have a configuration that resembles the complete router configuration example shown in Listing 1.4. If you have not already done so, you will now need to replicate the common portions of this configuration in all of the routers that make up your test bed so that this baseline functionality is available throughout your entire network before proceeding to the next chapter. The highlighted redundancy options shown in this example are supported only on the M20, M40e, M160, and T640 platforms.

Listing 1.4: r1's Initial Configuration

[edit] lab@r1# show | no-more system {    host-name r1;    time-zone America/Los_Angeles;    authentication-order [ radius password ]; root-authentication {    encrypted-password "$1$j5nxWQ9r$p6XQ9eKqpgsGe51DYySGI/"; # SECRET-DATA    ssh-rsa "1024 65537  14507521839282798432482521835023055326381401663452058669080886491465544700784392  81114055822376198290722320666268020211763429857348456378696103199986915461962494  35479692894437417780898017483440313841107367122670080439972894195679320796753410  731222833899141869327583231170906047985814682544941905107416839803283 root"; #   SECRET-DATA    }    radius-server {       10.0.1.102 secret "$9$.fQnEhrevL"; # SECRET-DATA    }    login {       class ops {          idle-timeout 5;          permissions network;          allow-commands "show interfaces";          deny-commands "traceroute|telnet|ssh";       }       user lab {          uid 2000;          class superuser;          authentication {             encrypted-password "$1$nNISN$o7OGTEhEF5sOcgjS9p0Lf0"; # SECRET-DATA       }    }    user ops {       uid 2002;       class ops;       authentication {          encrypted-password "$1$SgJQQ$VYXXLPf9/TMOnb2ohWxOJ."; # SECRET-DATA       }    }    user proctor {       uid 2001;       class superuser;    } } services {    ssh;    telnet; }    syslog {       user * {          any emergency;       }    file messages {       any notice;    }    file auth {       authorization info;       archive size 5m files 5;    }  }      processes {       routing failover other-routing-engine;  }  ntp {     authentication-key 101 type md5 value "$9$fQ39SyKM87"; # SECRET-DATA     server 10.0.200.2 key 101;     trusted-key 101;   }  }  chassis {   redundancy {      routing-engine 0 master;    }    alarm {       management-ethernet {          link-down yellow;       }    }  }  interfaces {    fxp0 {       unit 0 {          family inet {             address 10.0.1.1/24;          }       }    }  } snmp {    interface fxp0.0;    community test {       clients {          10.0.200.2/32;       }    }    trap-group interface {       categories link;       targets {          10.0.200.2;       }    }  }  routing-options {    static {       route 10.0.200.0/24 {          next-hop 10.0.1.102;          no-readvertise;       }    }  } 

The Case for Cut and Paste on the Exam

Time is a critical factor in the JNCIP examination, and any technique that can save time is well worth deploying during the lab. Deciding when a configuration is common enough to warrant pasting into the remaining routers is a decision that has to be made by each individual, and should be based on factors such as your familiarity with using load (merge|override) terminal, and the potential time savings that are expected. Cut and paste is a double-edged sword, and as with any such tool, you can cause serious problems by using it incorrectly in an effort to save time. For example, forgetting to change a lo0 address can result in duplicate router IDs (RIDs) in a subsequent OSPF scenario, and this type of problem can be very difficult to diagnose in the heat of battle. Generally speaking, it is advisable to paste configurations (or particular stanzas) into a text editor such as Word Pad, where you can easily edit the variables to suit the router that you plan to paste the configuration into.

Using Cut and Paste

The following commands illustrate how an edited version of the previous configuration can be pasted into r2. In this example, the only fields that required modification between the various routers are the hostname and fxp0 addressing:

root@host> configure Entering configuration mode [edit] lab@host# load override terminal [Type ^D to end input] <select paste in emulation program> system {    host-name r2;    time-zone America/Los_Angeles;    authentication-order [ radius password ];    . . .    route 10.0.200.0/24 {       next-hop 10.0.1.102;       no-readvertise;    }  }  } <carriage return> <control d> load complete [edit] lab@host# commit and-quit commit complete Exiting configuration mode lab@r2>

In the previous capture, operator input that is not echoed back is displayed in italics with '< >' delimiters. The first such occurrence is when the user selects Paste from their terminal emulation program after entering the load override terminal command. At the end of the capture, the operator enters a single carriage return to place a new line after the last curly brace, and then terminates the paste operation with the Ctrl+d key sequence (per the instructions provided at the beginning of the terminal paste operation). Because no errors are reported, the paste operation appears to have been successful. You now commit the new configuration, which results in the router's hostname becoming r2, as highlighted.

Pasting Individual Stanzas or Stanza Components

Using load override is pretty straightforward, but there are many instances when the wholesale replacement of the entire router configuration is not desired. It is also possible to paste in complete stanzas, or components from a particular stanza, though this can be a bit tricky. The following example shows the cut and paste of just the routing-options stanza. We start on r2 where we display the contents of its routing-options stanza:

[edit] lab@r2# show routing-options static {    route 10.0.200.0/24 {       next-hop 10.0.1.102;       no-readvertise;    }  } 

The contents of the stanza, which is highlighted, are then selected and copied into your emulation program's capture buffer. To paste this snippet into r1, we use load merge terminal, and must be careful to include the configuration hierarchy routing-options before performing the paste operation so the router knows where to put the information that is pasted. In this example, we first delete the existing routing-options stanza on r1 to demonstrate that the paste was successful:

[edit] root@r1# delete routing-options [edit] root@r1# show routing-options [edit] root@r1# load merge terminal [Type ^D to end input] routing-options static {    route 10.0.200.0/24 {       next-hop 10.0.1.102;       no-readvertise;    } }-<carriage return> <control-d> load complete [edit] root@r1# show routing-options static {    route 10.0.200.0/24 {       next-hop 10.0.1.102;       no-readvertise;    }  } 

The procedure is similar when the goal is to paste a portion of a stanza, such as an individual static route. In this example, a static route to 1.1.1.1 has been added to r2, and this route will be pasted into r1:

[edit] lab@r2# show routing-options static {    route 10.0.200.0/24 {       next-hop 10.0.1.102;       no-readvertise;    }     route 1.1.1.1/32 discard;  }

After copying the 1.1.1.1 static route into the capture buffer, it is pasted into r1 using the following commands. Note that the operator has correctly specified the destination of the pasted data by manually entering routing-options static before performing the paste:

[edit] root@r1# load merge terminal [Type ^D to end input] routing-options static route 1.1.1.1/32 discard; /<carriage return> <control-d> load complete [edit] root@r1# show routing-options static {    route 10.0.200.0/24 {       next-hop 10.0.1.102;       no-readvertise;    }    route 1.1.1.1/32 discard;  }