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:
[edit]jeff@Juniper5# set chassis |
If I hit return at this point, JUNOS tells me it doesn't have enough information:
[edit]jeff@Juniper5# set chassis ^ missing argument. |
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:
<font size="-4" face="Courier">[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 </font>
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:
|
Okay, I want the craft-lockout command. But I mistype it (typical of me):
|
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:
|
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:
|
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:
|
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:
|
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.