Navigating a JUNOS Configuration

In the previous post on JUNOS I gave you a brief overview of the software architecture, with a particular emphasis on modularity. In this post, we'll have a first look at maneuvering around within a JUNOS configuration file.

The JUNOS configuration file is well organized in a hierarchical structure; once you understand that structure and its various levels, it's easy to navigate the file and find exactly the parts you want to examine or change without being distracted by parts you are not interested in at the moment.

To begin, I log into the router:

The prompt shows the user name (jeff) and the name of the router (Juniper5). The router is now in operational mode, from which you can perform operational tasks such as displaying router states and databases, ping and traceroute, telnet and ssh, restarting system processes – most commands that you need for monitoring and troubleshooting the system. The JUNOS operational mode is equivalent to the IOS user EXEC mode; in fact the prompts of both is a "greater than" (>) sign.

As with IOS, the question mark is your friend; it's the primary informational tool when you can't quite remember the next statement in a command string, or just want to see what options are available to you. I can use the question mark to see all of the commands available in operational mode:

jeff@Juniper5> ?
Possible completions:

    clear           Clear information in the system

    configure       Manipulate software configuration information


    diagnose        Invoke diagnose script|

    file            Perform file operations

    help            Provide help information

    monitor         Show real-time debugging information
    mtrace          Trace multicast path from source to receiver
    ping            Ping remote target
    quit            Exit the management session
    request         Make system-level requests
    restart         Restart software process
    set             Set CLI properties, date/time, craft interface message
    show            Show system information
    ssh             Start secure shell on another host
    start           Start shell
    telnet          Telnet to another host
    test            Perform diagnostic debugging
    traceroute      Trace route to remote host
							  
						

To make configuration changes, I enter configuration mode by entering the configure command:

The JUNOS configuration mode is equivalent to the IOS privileged EXEC or "enabled" mode. Notice that the prompt changed from > to #, again the same way IOS does after you enter the enable command.

Another characteristic of the JUNOS configuration mode is the [edit] banner just above the prompt. You can maneuver around within the configuration hierarchy to observe or change just the part of the file that are of interest to you; the banner indicates precisely where you are within the hierarchy. When the banner just shows [edit], you are at the top of the hierarchy. So for example, if you type show at this level with no modiiers, JUNOS displays the entire configuration.

Using the question mark with the show command, you can see the top levels of the configuration hierarchy:

[edit]
jeff@Juniper5# show ?
Possible completions:
  <[Enter]>            Execute this command

> access               Network access configuration
> accounting-options   Accounting data configuration
> applications         Define applications by protocol characteristics
+ apply-groups         Groups from which to inherit configuration data
> chassis              Chassis configuration
> class-of-service     Class-of-service configuration
> event-options        Event processing configuration
> firewall             Define a firewall configuration
> forwarding-options   Configure options to control packet forwarding
> groups               Configuration groups

> interfaces           Interface configuration
> policy-options       Routing policy option configuration
> protocols            Routing protocol configuration
> routing-instances    Routing instance configuration
> routing-options      Protocol-independent routing option configuration
> security             Security configuration
> services             Service PIC applications settings
> snmp                 Simple Network Management Protocol configuration
> system               System parameters
  |                    Pipe through a command
							

The labels accompanying this list explain the levels pretty well. For example, all interfaces are configured under the interfaces level, all protocols are configured under the protocols level, and all routing policies are configured under the policy-options level.

Below each of these top levels are many sub-levels. For example, under protocols you can find BGP, OSPFv2, OSPFv3, MPLS, RSVP, and so on. And under each of those will find further sub-levels specific to the protocol. Under OSPF, for example, you will find a level for the area configurations and then under each area level you will find a level for specifying the interfaces that are in that area. I'll show you an example of that in a moment.

The hierarchical structure of the configuration allows you to focus on just the part of the configuration in which you are interested. For example, suppose you want to look at just the BGP portion of the configuration. show protocols bgp shows you the entire BGP configuration:

[edit]
jeffr@Juniper5# show protocols bgp 
local-address 192.168.50.10;
local-as 65503;
group CustomerX {
    export XPolicy;
    peer-as 65510;
    neighbor 192.168.1.1 {
        authentication-key "$9$-Ud2aji.5z6qm"; ## SECRET-DATA
    }
    neighbor 192.168.1.5 {
        authentication-key "$9$JiZHmzF/t0I69ev"; ## SECRET-DATA
    }
    neighbor 192.168.1.10 {
        authentication-key "$9$mPF/u0Icrv1Rbs"; ## SECRET-DATA
    }
}
group CustomerY {
    neighbor 192.168.10.20;
    neighbor 192.168.10.30;
    neighbor 192.168.10.40;
}
group CustomerZ {
    neighbor 192.168.20.100;
}
						

You can see in this configuration that there is a local address (192.168.50.10) from which all the BGP TCP sessions originate, the local AS number is 65503, and there are three peer groups: CustomerX, CustomerY, and CustomerZ. CustomerX has an outgoing (export) routing policy I've named XPolicy; and because the AS number for that group (65510) is different from the local AS number, we know these are EBGP peers. There are three neighbors configured under this group, all of which are authenticated with individual passwords. Peer groups CustomerY, with three neighbors, and CustomerZ, with one neighbor, are IBGP because they have no separate AS numbers specified, and no authentication is configured.

Suppose, rather than the entire BGP configuration, you are interested in only the configuration of neighbor 192.168.1.5 under group Customer X. I can tell JUNOS to display just that part of the configuration file simply by being more explicit with the show command:

[edit]
jeff@Juniper5# show protocols bgp group CustomerX neighbor 192.168.1.5    
authentication-key "$9$JiZHmzF/t0I69ev"; ## SECRET-DATA

Of course if you are in configuration mode you probably want to do more than just look at parts of the configuration; you want to make changes. Using the question mark alone while in configuration mode, you can see the different actions you can take:

[edit]
jeff@Juniper5# ?     
Possible completions:
  <[Enter]>            Execute this command
  activate             Remove the inactive tag from a statement
  annotate             Annotate the statement with a comment
  commit               Commit current set of changes
  copy                 Copy a statement
  deactivate           Add the inactive tag to a statement
  delete               Delete a data element
  edit                 Edit a sub-element
  exit                 Exit from this level
  help                 Provide help information
  insert               Insert a new ordered data element
  load                 Load configuration from ASCII file
  quit                 Quit from this level
  rename               Rename a statement
  replace              Replace character string in configuration
  rollback             Roll back to previous committed configuration
  run                  Run an operational-mode command
  save                 Save configuration to ASCII file
  set                  Set a parameter
  show                 Show a parameter
  status               Show users currently editing configuration
  top                  Exit to top level of configuration
  up                   Exit one level of configuration
  wildcard             Wildcard operations
						

The remainder of this post and all of the next post discuss the actions on this list.

I want to add some elements to the configuration, and the command for doing that is set. Lets' say we want to add interface fe-0/0/0 to OSPF area 5. Using set, we specify each level down through the hierarchy until we get to the point – under the area 5 level – where the interface is to be added:

[edit]
jeff@Juniper5# set protocols ospf area 5 interface fe-0/0/0 

By the way, if OSPF was not enabled or area 5 did not yet exist, the same command would enable the protocol and create area 5 in addition to adding the interface to the area.

Another approach is to first move down to the level you want to configure, using the edit command, and then make the changes you want:

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

[edit protocols ospf area 0.0.0.5]
jeff@Juniper5# set interface fe-0/0/1 
						

Notice here that after entering edit protocols ospf area 5, the banner over the prompt changed to show where I am in the hierarchy – I always know where I am. I then used the set command to add interface fe-0/0/1 at that level. I don't need to specify the entire hierarchy this time, because I am already at the level where I want to make a change.

These two approaches give you the flexibility to manage a configuration in the manner most convenient to you. If you are just adding a statement or two to a configuration, it is usually easier to do that from the top level, specifying the full path down to the level you want to change. If you are making extensive changes to a particular level, it is usually easier to move to that level first using the edit command, and then make the changes directly without having to specify the full path with every command.

While edit takes you to the specific level where you want to work, up moves you up one level in the hierarchy. For instance, suppose that from where we are at the OSPF area 5 level, we want to move up to the full OSPF level:

[edit protocols ospf area 0.0.0.5]
jeff@Juniper5# up 

[edit protocols ospf]
jeff@Juniper5# show  
area 0.0.0.5 {
    interface fe-0/0/0.0;
    interface fe-0/0/1.0;
}

You can see that the banner above the prompt changed after issuing the up command, telling you where you are. A show command at any level shows all of the configuration statements under the level – in this case, it shows all of the OSPF config.

If you want to jump back to the top of the hierarchy from any level, you use the top command:

[edit protocols ospf]
jeff@Juniper5# top 

[edit]
jeff@Juniper5# 

In this example, you could also have gotten from the existing level to the top by issuing the up command twice: [edit protocols ospf] => up => [edit protocols] => up => [edit]. Using the edit, up, and top commands together, you can quickly move to wherever you need to be in the configuration file for efficient operations.

In addition to the set command, there are a few more important commands for changing the configuration. In the interests of space I won't demonstrate them, but I want to at least point them out:

• delete is the opposite of set; it removes statements from the configuration.
• replace is used to replace one statement with another statement.
• insert is used when you want to add a statement within an ordered element (such as a filter list) rather to the end, as the set command would do.
• deactivate is used when you want to make a statement inactive but don't want to remove the statement from the config. This is handy for temporarily "turning off" something that you intend to eventually turn back on.
• activate is used to reactivate an inactive statement.
• annotate is used to add a comment to a statement; this is very useful for making a large, complex configuration file easier to interpret.

One of the more significant operational differences between JUNOS and IOS is that unlike IOS, when you enter a new statement into the JUNOS configuration it does not immediately become active on the router. You can make as many changes as you like, inspect your changes, and make them take effect only when you explicitly tell the router to accept them.

That's the topic of the next post: Commits, rollbacks, saves, and loads.