I discussed in the previous post how candidate configurations, explicit commits, and rollbacks greatly increase the reliability of configuration changes in JUNOS and reduce the risk of configuration mistakes. Heaven knows if there is a mistake to be made, I'm likely to make it.

Another nice feature for klutzy typists such as myself is that rather than waiting until you hit return at the end of a configuration statement to check for syntax errors, JUNOS checks syntax word-by-word – that is, every time you enter a word into a line and hit the space bar, it checks the syntax.

It also allows you, like IOS, to type the minimum number of letters for a command word to be uniquely identified. For example, if you want to look at the unicast routing table in IOS you can type:

sh ip rou

IOS understands this to be:

show ip route

JUNOS does the same thing; except each time you hit the space bar, in addition to immediately checking the syntax it completes the command. So for example, the equivalent JUNOS command for displaying the unicast routing table is:

show route

I can type sh, and as soon as I hit the space bar it displays show. Then I type rou, and when I hit the space bar it displays route.

In the following example, I'm in configuration mode. I want to make a change to the chassis configuration, so I type:

When I hit the space bar the command is completed:

If I hit return at this point, JUNOS tells me it doesn't have enough information:

This is pretty much the same behavior that IOS displays when the command line is incomplete. And as with IOS, the question mark in JUNOS is your primary reference tool:

[edit]
jeff@Juniper5# set chassis ?
Possible completions:
> alarm               Global alarm settings
+ apply-groups        Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> config-button       Config button behavior settings
  craft-lockout       Disable craft interface input
> fpc                 Flexible PIC Concentrator parameters
> routing-engine      Routing Engine settings
[edit]
jeff@Juniper5# set chassis     

Notice that at the end of the possible completions, the command line that I typed is again entered, ready for me to choose the next word in the line. I add “c” as an abbreviation of the next word, but JUNOS objects when I hit the space bar because “c” could represent multiple words; JUNOS does not know which I want, and tells me what the possible words are:

[edit]
jeff@Juniper5# set chassis c   
                            ^
'c' is ambiguous.
Possible completions:
> config-button        Config button behavior settings
  craft-lockout        Disable craft interface input
jeff@Juniper5# set chassis c   

Okay, I want the craft-lockout command. But I mistype it (typical of me):

jeff@Juniper5# set chassis crof
                           ^
syntax error.
jeff@Juniper5# set chassis crof

But now I'm hit with a moment of doubt. The brief listing of options says that this command disables craft interface input. What does that mean? Is that what I really want to do? I need some help. It turns out that help is a very useful command.

If I type help reference and specify the command I want to use, a brief reference is displayed:

[edit]
jeff@Juniper5# help reference chassis craft-lockout 
craft-lockout

Syntax

   craft-lockout;

Hierarchy Level

   [edit chassis]

Release Information

   Statement introduced in JUNOS Release 8.1.

Description

   Disable the physical operation of the craft interface front panel.

Usage Guidelines

   See "Disabling Physical Operation of the Craft Interface".

Required Privilege Level
                    
   interface--To view this statement in the configuration.
   interface-control--To add this statement to the configuration.

[edit]
jeff@Juniper5# 

This tells me about the usage, but I really want more of an explanation of what the command does. I can get that by using help topic:

[edit]
jeff@Juniper5# help topic chassis craft-lockout 
              Disabling Physical Operation of the Craft Interface

You can disable the physical operation of the craft interface front panel
on the routing platform. When you disable the operation of the craft
interface, the buttons on the front panel, such as the alarm cutoff
button, no longer function. To disable the craft interface operation,
include the craft-lockout statement at the [edit chassis] hierarchy level:
  [edit chassis]
      craft-lockout;
For more information about how to configure the craft interface, see
Configuring Conditions That Trigger Alarms.

[edit]
jeff@Juniper5# 

That tells me everything I need to know about setting the chassis craft-lockout function. But what if I want to know something more general about the chassis keyword itself? For this, I can use help apropos, which tells me all of the different contexts under which I can refer to the chassis:

[edit]
jeff@Juniper5# help apropos chassis 
set system location lcc 
    Line-card chassis location
set system processes chassis-control 
  Chassis control process
set system processes chassis-control disable 
  Disable chassis control process
set system processes chassis-control failover <failover> 
  How to handle failure of chassis control process
set chassis 
  Chassis configuration
set chassis fpc <slot> pic <slot> shdsl 
  SHDSL chassis configuration
set chassis disable-power-management 
  Disable Power Management in this chassis
set chassis network-services <network-services> 
  Chassis network services configuration
set chassis lcc 
  Line-card chassis configuration
set chassis lcc <lcc-number> fpc <slot> pic <slot> shdsl 
  SHDSL chassis configuration
set snmp trap-group <group-name> categories chassis 
  Chassis or environment notifications
set class-of-service interfaces <interface_name> scheduler-map-chassis <scheduler-map-chassis> 
  Scheduler map applied to chassis queues (not PIC queues)
set class-of-service traceoptions flag hardware-database 
  Trace chassis hardware database related processing

[edit]
jeff@Juniper5#

The help apropos command only displays contexts that are relevant to the level of the configuration hierarchy you are currently at. If I were to enter help apropos interface at the top [edit] level, I would see a very long list of every context in which I could set an interface option. In the following example, I move to the level of the configuration at which I can configure OSPF area 0. Entering help apropos interface at that level shows only the contexts in which I can configure an interface for OSPF area 0:

[edit]
jeff@Juniper5# edit protocols ospf area 0 

[edit protocols ospf area 0.0.0.0]
jeff@Juniper5# help apropos interface 
set virtual-link neighbor-id <neighbor-id> transit-area <transit-area> demand-circuit 
 Interface functions as a demand circuit
set sham-link-remote <address> demand-circuit 
 Interface functions as a demand circuit
set interface 
 Include an interface in this area
set interface <interface_name> 
 Interface name
set interface <interface_name> disable 
 Disable OSPF on this interface
set interface <interface_name> interface-type <interface-type> 
 Type of interface
set interface <interface_name> metric <metric> 
 Interface metric
set interface <interface_name> demand-circuit 
 Interface functions as a demand circuit
set interface <interface_name> dynamic-neighbors 
 Learn neighbors dynamically on a p2mp interface
set interface <interface_name> poll-interval <poll-interval> 
 Poll interval for NBMA interfaces
set label-switched-path <lsp-name> metric <metric> 
 Interface metric
set peer-interface  
 Configuration for peer interface
set peer-interface <peer_interface_name> 
 Name of peer interface
set peer-interface <peer_interface_name> demand-circuit 
 Interface functions as a demand circuit

[edit protocols ospf area 0.0.0.0]
jeff@Juniper5# 

If I have at least a general idea of what I want to accomplish, I can use the question mark and the help commands to make configuration changes in JUNOS without having to go to the configuration manuals – an abbreviated set of manuals are available to the CLI.

We're not done yet, however. I can add some configuration statements that are individually correct but that do not make sense, or are incomplete, within the context of the entire configuration. In the next post I'll describe some of the scripting tools that are available for insuring that your entire configuration is coherent before you commit it.