Skip to content

JUNOS

Jump to bottom
Igor Malyushkin edited this page Jun 16, 2024 · 6 revisions

This guide is based on versions before 0.1.8!

General Info

Juniper "JunOS" is a really popular platform, especially amid the service provider fellas. It is the first platform Thymus supported. The core logic of the application is built around the navigational principles of this platform. So, engineers who know JunOS are especially beneficial from that fact.

Core Concepts

Thymus does not support the co-called set-view!

JUNOS has a hierarchical configuration structure. This structure is quite similar to the JSON format. The Thymus navigation system defines two important elements: a section, and a stub. Every section ends with the "{" symbol and can be used for navigation. You can use a name of a section or a path constructed with names to reach some place of the configuration (tree). Sections could be considered as branches of a tree. Every stub ends with the ";" symbol and can not be used for navigation. Stubs are leaves of a branch.

Take a look at the next pseudo-configuration:

interfaces {
    xe-0/0/0 {
      description "IFD #1";
    }
}

Here we have the two sections and one stub element (description). Please note that the sections have hierarchical relations: the xe-0/0/0 is inside the interfaces. Each section has a path attribute. The interfaces section has itself as a path because it belongs to the root of the tree. The xe-0/0/0 has a path of interfaces+xe-0/0/0 (the "+" is an example delimiter, Thymus uses another). These paths are used as input for navigation commands that will be described later. The stub does not have a path (i.e., it inherits the parent's path).

Heuristics

Thymus supports some heuristics mechanism for navigation. The application understands two notations for the IFD and IFL pair. You can visit or display either the xe-0/0/0 unit 0 or xe-0/0/0.0 configuration. The auto-complete is also supported for both cases.

Settings

Every context is configured by Thymus immediately after the start. A user can tune the settings for the exact context without saving them to the system configuration file. Also, the altered settings do not influence other contexts of the same type. For this task, there is the command set.

  • set spaces command overwrites the value received during the bootstrap of the context. It can be only 1, 2, or 4.
  • set name command sets the name of the context. By default, all contexts are unnamed. Without this setting, the comparing sub-command will not work. The name must contain between 4 and 16 symbols from the "0-9", and/or "a-z" sets.
  • set encoding command sets the encoding for the context. It could be used then as the encoding for the save sub-command.

Commands

Thymus uses the same set of commands that JUNOS does, and some additional ones.

  • show is one of the most popular commands. It shows a configuration of the current section, or whole the file if the section is root (top). It also supports an argument with the relative path: show interfaces lo0.0 from the root, or show lo0.0 from the "interfaces" section.
    • A special argument for the command is the "version" or "ver". Thymus pays attention to this stub and saves it separately. As a side effect of this, you can display the version of the configuration with one simple command.
  • go is the next of the most popular commands. It requires a path as its only argument. For example, to reach the BGP section is just go protocols bgp from the top.
  • top returns you to the root of the tree.
    • top show shows the whole configuration from any section.
    • top show path shows the configuration of the section reachable by the path argument (e.g., top show interfaces lo0.0).
    • top go path allows a user to change the section from any other by the path argument.
  • up command without any arguments returns a user from the section to its parent. The command supports a number of sections to return. If the number is larger than the possible depth, the up works as the top.
    • up show allows a user to do a negative lookahead, but it does not support any additional arguments for the show part.

Show Sub-Commands

The show command supports sub-commands after the "|" symbol. These sub-commands can be stacked into a pipeline. Nested with the top command, the show command supports all the same sub-commands as without the nesting. We can describe it by the next pseudo-regular expression rule: "(top)? show (path)? (| sub-command)*".

There are three types of sub-commands: leading, passthrough, and terminating. The leading sub-command can be placed only after the first "|" symbol of the pipeline. In other words, this is the first sub-command in the line. The passthrough sub-commands can be placed anywhere, and the terminating sub-command can be placed only at the end of an expression. For example, "(top)? show (path)? (| leading)? (| passthrough)* (| terminating)?".

The filter sub-command is a passthrough type. It compares line by line the output received from the show command before displaying it on the screen. For comparison, the sub-command uses a PCRE rule (Python's search method), and returns a line if and only if this rule is positive for this line. The PCRE rule can be expressed with or without the quotation ("some rule"), but for sophisticated expressions, it's better to use quotes.

show | filter "^xe-1/\d/\d{2}$"

show protocols l2circuit | filter "neighbor 10.(?:\d{1,3}.){2}15"

The wc_filter (wildcard filter) is a passthrough type. This sub-command considers the names of all inner sections and compares a PCRE rule against them. If the rule is positive the sub-command outputs all the respective section's lines. In other words, it allows you to filter sections by their name. The "{" symbol must be omitted in the PCRE rule.

show interfaces | wc_filter "^xe-(?\d{1}/){2}0"

The count is a terminating type. It counts the lines.

show routing-options | count

The save is a terminating type with a mandatory argument that specifies a filename. The encoding of the file is equal to the encoding previously selected in the open dialog.

show routing-instances | save file1.conf

show | filter "address" | save file2.conf

The stubs is a leading type. This sub-command displays only the stubs of the immediate section, where the user's path points. It filters out all nested sections and their content.

show system | stubs

The sections is a leading type. It constructs a list of names of all nested sections.

show | sections

show protocols | sections

The inactive is a leading type. It is useful to find out which sections and/or stubs are marked with the "inactive:" statement.

show | inactive

show routing-options static | inactive

The compare is a leading type. A user can compare a distinct section with all its content from one context with the same section (path) from another. From the top of the context, all sections will be compared between contexts. This sub-command requires both contexts to be named.

show | compare file02

show interfaces lo0 | compare file02

The contains is a leading type. This sub-command recursively searches all pattern matches for sections and finite instructions. For example, show | contains "instance-type vpls;" gives you all sections where this pattern lives.

show | contains "instance-type vpls;"

show interfaces | contains "vlan-tagging"

Misc

If a user got used to working with one platform, it is possible to use the same set of commands for all platforms. In other words, the filter and include are interchangeable, diff and compare too, and so on.

Clone this wiki locally