-
Notifications
You must be signed in to change notification settings - Fork 1
IOS
This guide is based on versions before 0.1.8!
Cisco IOS is one of the oldest and most popular network operation systems. Lots of successors inherit the logic this OS made. The IOS family includes several products: IOS, IOS-XE, IOS-XR, and NX-OS. Thymus supports IOS and IOS-XE as very similar systems. The support of IOS-XR and NX-OS is probable, but not tested.
The IOS configuration's structure is pretty old and not as well-formatted as some other more modern systems. Thymus makes some guessing to parse it which should be noted by users.
Building AST, Thymus splits the config into a hierarchy of sections and finite instructions. There is no clear separation of whether the line is an entrance to a section or an instruction itself, so Thymus heavily depends on the indentation of lines. Take a look at the next example.
aaa accounting update periodic 1
aaa accounting network default
action-type stop-only
group radius
!
Thymus considers the first line as a finite instruction or a stub. The second and third lines have different numbers of spaces in front of them. For this reason, Thymus deduces that the second line is a section and, until Thymus meets a line at the same indentation level (0 spaces in this example, i.e., the line which starts with the "!"), it counts every line as the inner lines of this section. Also, sections could be nested, and the algorithm understands that.
Thymus does not use the "!" symbol as the section's exit flag. The configuration structure is not stringent, and sometimes sections finish without the "!" at the end.
redundancy
main-cpu
auto-sync running-config
mode sso
!
In the above example, there are two sections, "redundancy" and "main-cpu". Thymus decides so by the indentation rule described before. The "redundancy" section has the "!" at the end, but the "main-cpu" does not. Thymus sets the "mode sso" line as a stub of the "redundancy" section but not the "main-cpu".
Another important thing is the accessible flag. The section's names are not atomic. In other words, if a section's name is comprised of at least two words, Thymus will split this name by these words. This is due to the repeating words from left to right united under the same hierarchy levels of a tree. Let's take the section from one of the previous examples: "aaa accounting network default". Thymus creates a branch with the four buds, but a user can not visit or display every one of them. There is no sense in that because "aaa", "aaa accounting", and "aaa accounting network" do not have any stubs or nested sections. All of these buds are marked as not accessible, and Thymus will show an error when a user tries to visit or display one.
Thymus expects that a configuration file's structure is machine formatted. When an engineer alters the file it creates possibilities to change the structure in a way that Thymus cannot understand or, even worst, understand incorrectly. Please, pay attention to existent indentation whenever you edit your IOS-like files!
interface X
..ip address x.x.x.x y.y.y.y
..
..interface Y
....ip address z.z.z.z w.w.w.w
The example above shows one of the possible issues (periods are for convenient reading). Probably, a system's parser can understand this sequence of lines as two separate interface-like sections, but Thymus would see interface Y as an inner section of interface X.
As was previously stated, IOS' structure has some flaws. Thymus tries to address them to increase user experience.
The first step is that some important sections behave differently: "interface" and "route-map". Let's consider the artificial example below.
interface TenGigabitEthernet 0/0
description "TEST"
!
interface TenGigabitEthernet 0/1
!
The algorithm deduces that the first line is a section, but the fourth is not. For this reason, the first line becomes a branch of the tree, and a user can navigate to it, but the fourth does not. The auto-complete mechanism is also absent of any knowledge about the second interface. The same is true for any other sections of the configuration. But for interfaces and route maps, Thymus makes an exception. It understands that these types of sections are too important for a network engineer, and parses them more carefully. So, in the example above the "TenGigabitEthernet 0/1" is also a section, the user can visit it despite its emptiness. It makes sense because the user knows how many interfaces are there, or which parts of a route map really exist.
Moreover, the "interface" and "route-map" sections are clear from inaccessibility. A user can navigate them for more convenience if the user wants to see all interfaces at once, for example.
Users can disable the base heuristics described above.
There were some thoughts also about the "vlan" section. But it requires some further discussion.
The second big step is the improved heuristics for all finite instructions. A lot of stubs at the same level of hierarchy share some number of keywords from left to right. Thymus artificially unites them together by this marker. You can not navigate these new branches, but you can display them.
By default, the improved heuristics mechanism is disabled!
For results, made by the heuristics mechanism there is no support for the piping!
service nagle
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime localtime
service timestamps log datetime localtime
service password-encryption
service linenumber
service internal
service counters max age 10
service unsupported-transceiver
All of these lines are finite instructions (or stubs in terms of the application). Thymus creates a virtual branch where the first bud is the "service". The accessibility rule does not apply here for display purposes. If a user wants to display the "service" from the root section, Thymus will show all these lines. Further, Thymus tries to find what else could be united. Here is the "timestamps" keyword, there is the second bud at the virtual branch. The user can display all lines with the "service timestamps".
A user can just use the show command with the include sub-command for this goal, but this approach has some limitations:
- The filtering requires a PCRE rule, the heuristics mechanism does not.
- This rule should consider the "no" keyword (the second line of the example above), the heuristics mechanism does it by default.
- The latter also understands the concept of levels, and it won't show stubs from any nested sections. To account for it, the PCRE rule must be more sophisticated.
- The auto-complete mechanism works with the virtual branches made by the heuristics algorithm.
The improved heuristics algorithm works under any level of hierarchy.
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 spacescommand overwrites the value received during the bootstrap of the context. It can be only 1, 2, or 4. -
set namecommand 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 encodingcommand sets the encoding for the context. It could be used then as the encoding for thesavesub-command. -
set heuristicscommand overwrites the value received during the bootstrap of the context for the improved heuristics mechanism. It can be only 0, 1, "0", "1", "on", or "off. -
set base_heuristicscommand overwrites the value received during the bootstrap of the context for the base heuristics mechanism. It can be only 0, 1, "0", "1", "on", or "off. -
set cropcommand overwrites the value received during the bootstrap of the context. It can be only 0, 1, "0", "1", "on", or "off. -
set promisccommand overwrites the value received during the bootstrap of the context. It can be only 0, 1, "0", "1", "on", or "off.
Thymus uses the same set of commands that IOS does, and some additional ones.
-
showis 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 interface loopback0from the root, orshow loopback 0from the "interface" 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.
-
gois the next of the most popular commands. It requires a path as its only argument. For example, to reach the BGP section is justgo router bgp 64512from the top. -
endreturns you to the root of the tree. -
-
end showshows the whole configuration from any section.
-
-
-
end show pathshows the section's configuration reachable by the path argument (e.g.,end show interface loopback0).
-
-
-
end go pathallows a user to change the section from any other by the path argument.
-
-
exitcommand 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, theexitworks as theend. -
-
exit showallows a user to do a negative lookahead, but it does not support any additional arguments for theshowpart.
-
The show command supports sub-commands after the "|" symbol. These sub-commands can be stacked into a pipeline. Nested with the end 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: "(end)? 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, "(end)? show (path)? (| leading)? (| passthrough)* (| terminating)?".
The include 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 | include "Ethernet-0/\d/\d{2}"
show router ospf 1 | include "network 10.(?:\d{1,3}.){2}15"
The wildcard 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.
show interface | wildcard ".+\sPort-Channel\d+"
The count is a terminating type. It counts the lines.
show aaa | 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 route-map | save file1.conf
show | include "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 | stubs
The sections is a leading type. It constructs a list of names of all nested sections.
show | sections
show router bgp 64512 | sections
The diff 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 | diff file02
show interface loopback0 | diff file02
The contains is a leading type. This sub-command recursively searches all pattern matches for sections and finite instructions. For example, show | contains "vlan 10" gives you all sections where this pattern lives.
show | contains "vlan 10"
show interfaces | contains "speed 100"
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 include and filter are interchangeable, diff and compare too, and so on.