===== Config Parsing templates =====

> <color orange>This function is temporarily disabled </color>


/*
These templates parse a config from a node, and extract variables from that config, to be used in Scenarios. 

==== Config Parsing Template Syntax ====

A config consists out of a number of blocks of lines, which can differ vastly in shape, syntax and size. Each block can be captured in a context in a parsing template. A context contains code lines and  variables. These variables can be requested in a scenario through the [[menu:operate:scenarios:commands#parse_run|parse_run]] and [[menu:operate:scenarios:commands#parse_nccm|parse_nccm]] scenario commands. The parse_run command parses the config that is retrieved directly from the active node. The parse_nccm will parse against the node's config saved in the NCCM (note that if there is no config present in the NCCM, the error flag will be set).

For more information, see: [[menu:operate:scenarios:commands|commands_details]]

Note: both parse_run and parse_nccm can only pull **one** variable out of a config each time.
If you need multiple variables from a config, you will need to call the function multiple times.

While you may require multiple parse_run commands in your scenario, the actual configuration is only retrieved once. 

=== Scenario command ===

The config parsing function is called from the scenario like this:

<code>
<var> := parse_run -n <node> -t template -c "template context" -v tpl_variable
</code>

or:

<code>
<var> := parse_nccm -n <node> -t template -c "template context" -v tpl_variable
</code>

parse_run runs config parsing on the active config of the node. parse_nccm compares to the config known in the nccm. If no config can be found in the NCCM, it will not parse anything and set the <error> variable. 

Like all commands, parameters can be either scenario variables, or plain text. Do note the quotes around the -c context parameter. This is to allow contexts containing spaces and non-alphanumeric characters. Omitting quotes with strings that lack spaces will work, however this won't work if there are spaces in your variable. 

=== Basic Syntax ===

A basic parsing template syntax is:

<code>
[interface]
interface <if_name>
</code>

**[interface]** is the context (-c). \\
**<if_name>** is the variable (-v).

When the config parser parses a config, it looks out for blocks whose first line starts with this header. It only looks at the first line of this block, and headers can be made more specific. For example, the above header matches with all blocks that start with interface. However, the following template will only match the block headed by "interface Ethernet0/1".

<code>
[interface Ethernet0/1]
interface <if_name>
</code>

Below the header follows a number of pattern lines. This can be any number. The config parser will match all lines of its block with all lines of its pattern. It requires an exact match. (NOTE: if a pattern matches a line, but at the end of the line there are a number of extra words that are not in the pattern, that means no match!). The syntax for special words is as follows:

|<string>             |A variable; replace with positional word |
|<string:end>         |Replace positional words until (but not including) 'end' |
|<string:>            |Replace positional words until end of line for '<string>' |
|<nowiki>|*|</nowiki> |Ignore all following words |

In a scenario, parse_run and parse_nccm can be used to retrieve the positional words of these variables. If a variable matches multiple times in a config, a list is returned containing all these values.

Headers can also be consecutive, for example

<code>
[interface Ethernet0/1]
[interface Ethernet 0/1]
interface <if_name>
</code>

What this means is that this block matches for both "interface Ethernet0/1" and "interface Ethernet 0/1".

In general words will be parsed as separated by spaces. However the following is also possible:

<code>
snmp-server chassis-id <hostname>.<dns_domain> 

route-target export <vrf_as>:<vrf_id>
</code>

=== General ===
If you do not want to specify a specific header, use general. This will be used on all blocks that can't be matched to a context. For example

<code>
[general]
version <version>, Release <release>
sysname <sysname>
clock <clock:>
</code>

=== Hierarchy ===
Blocks can contain sub blocks, which look different depending on vendor. To define a sub context in a template to match this block, you need to indent it. For example

<code>
[interfaces]
 [ge-5/0/0]
  description <if_description:>
</code>

This also means that to get the variable if_description, you need to submit 2 contexts (-c) with the parse_run and parse_nccm scenario commands: 'interfaces' and 'ge-5/0/0', in that order. It is also possible to go down more levels. For that, the same rules apply. 

=== Wildcards ===

Consider the following parsing template:

<code>
[interface <>]
interface <if_name>
</code>

If you specify the context as "interface Ethernet0/1", it will treat this block as:

<code>
[interface Ethernet0/1]
interface <if_name>
</code>

This way you can have customizable parsing templates. This also works in sub contexts. You can also specify a wildcard like this:

<code>
[<>]
interface <if_name>
</code>

In this case the header will match any context that is given. This wildcard can now also be used in a pattern:

<code>
[interface <>]
vlan ports <> pvid <vlan_port>
</code>

With the context "interface Ethernet0/1" the config parser will treat this block as:

<code>
[interface Ethernet0/1]
vlan ports Ethernet0/1 pvid <vlan_port>
</code>

In configs where headers are more generic and you want to use a wildcard that does not appear in a header:

<code>
[interface]
interface <>
</code>

If you specify the context and subcontext as "interface" and "Ethernet0/1", it will treat this block as:

<code>
[interface]
interface Ethernet0/1
</code>

Note that with complex hierarchies, this will only work if the wildcard is specified as the last sub-context to be sent along with the parse_run and parse_nccm commands.

=== Indentation ===
Some vendors have indented blocks, others do not. For the ones that do, the patterns need to be specified with the correct indentation. For example

<code>
[interface]
interface <if_name>
 description <if_description:>
</code>

"interface <if_name>" is the header and the first line of this block, but it can also be parsed, so it will also have its own pattern in this context. This line is not indented in the config, while the pattern " description <if_description:>" is. If this is the case in your config, this syntax is required.

Indentation is always in steps of a number of spaces. It doesn't matter whether these steps are 1, 2 or 4 spaces, as long as within one block or context, the step size is consistent.

==== Vendor Specific Syntax ====

=== Avaya_SW ===
Avaya SW configs contain port and vlan ranges. Since these ranges can take the form of "1/1-25,2/1-25,3/ALL,4/ALL,5/ALL,6/ALL", the config parser before parsing expands all these lines for each port, and collects them together in one block. Any line containing a port, port range, vlan or vlan range needs to be accessed this way, and not in the way you would expect from its config. 

Every port will be found under the "Interface Ethernet 1/1" context (where 1/1 is the port in question). Every vlan will be found under the "Vlan 1234" context (where 1234 is the vlan in question). For example:

<code>
[Interface Ethernet 1/11]
vlan ports 1/11 pvid <port_vlan>
name port 1/11 <port_name>
</code>

<code>
[Vlan 1234]
vlan create 1234 type port <vlan_create>
vlan name 1234 <vlan_name>
</code>

Indentation is not needed for patterns, only for headers in sub contexts. For example:

<code>
[OSPF]
 [router ospf]
router-id <router_ospf>
</code>

Avaya block headers are of the form:

<code>
! *** IP Manager ***
!
</code>

Closed by another '!'. Headers and contexts in parsing templates will ignore all special characters and and trim all leading and trailing spaces, so you can just use "[IP Manager]" or even "[IP]" as a context.

=== CI6 & CI8 ===
Ciena blocks consist out of a header, followed by a non-hierarchical set of lines, so indentations for patterns is not needed, and there also is no hierarchy present for contexts. 

CI6 en CI8 block headers are of the form:

<code>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! SYSLOG CONFIG:
!
</code>

Closed by another '!'. Headers and contexts in parsing templates will ignore all special characters and and trim all leading and trailing spaces, so you can just use "[SYSLOG CONFIG]" or even "[SYSLOG]" as a context.

Ciena configs rely heavily on port names and aliases, so it is advisable to use a lot of wildcards and multiple scenario calls to parse_run and parse_nccm to get all the correct data on all ports. NetYCE provides a number of sample parsing templates in order to help you get started.

On top of that, CI6 configs also have vlan ranges that go like:

<code>
vlan create vlan 9-12,24-25
</code>

Lines like these will be expanded and converted in the config parser to:

<code>
vlan create vlan 9
vlan create vlan 10
vlan create vlan 11
vlan create vlan 12
vlan create vlan 24
vlan create vlan 25
</code>


=== Cisco_IOS & Cisco_Nexus & Cisco_XR ===
Cisco configs have many different types of blocks, indented and not indented, so indentation is necessary in its parsing templates. Generally, lines that all start with the same keywords are considered in one context, even if these lines are prepended by "no" (for example the line: "no mmi auto-configure". 

Banners, blocks ending with a delimiter can be simply defined as:

<code>
[banner motd]
banner motd <motd>
</code>

And the variable <motd> will contain the entire multi line banner.

On top of that, Cisco IOS configs also have vlan ranges that go like:

<code>
switchport trunk allowed vlan 775-777,3322
</code>

Lines like these will be expanded and converted in the config parser to:

<code>
switchport trunk allowed vlan 775
switchport trunk allowed vlan 776
switchport trunk allowed vlan 777
switchport trunk allowed vlan 3322
</code>


=== HP_C5 & HP_C7 ===
HP_C5 has two types of blocks: hierarchical blocks that are properly indented, and blocks that follow lyne-by-line that are always one space indented. In parsing templates, indentation is needed for the first type, but not for the second. For example:

<code>
[clock]
clock <clock:>

[vlan]
vlan <vlan>
 name <vlan_name>
</code>

An exception to this is the header statement. This is treated as just one line and can be retrieved as:

<code>
[header]
header legal <header_legal>
</code>

On top of that, HP C7 configs also have vlan ranges that go like:

<code>
port trunk permit vlan 500 540 to 545 570
</code>

Lines like these will be expanded and converted in the config parser to:

<code>
port trunk permit vlan 500
port trunk permit vlan 540
port trunk permit vlan 541
port trunk permit vlan 542
port trunk permit vlan 543
port trunk permit vlan 544
port trunk permit vlan 545
port trunk permit vlan 570
</code>


=== Huawei_CE & Huawei_S ===
Cisco configs have many different types of blocks, indented and not indented, so indentation is necessary in its parsing templates. Generally, lines that all start with the same keywords are considered in one context, even if these lines are prepended by "no" (for example the line: "no mmi auto-configure". 

On top of that, Huawei configs also have vlan ranges that go like:

<code>
port trunk allow-pass vlan 4 1115 1200 1450 to 1453 2905 3993 to 3994
</code>

Lines like these will be expanded and converted in the config parser to:

<code>
port trunk allow-pass vlan 4 
port trunk allow-pass vlan 1115
port trunk allow-pass vlan 1200
port trunk allow-pass vlan 1450
port trunk allow-pass vlan 1451
port trunk allow-pass vlan 1452
port trunk allow-pass vlan 1453
port trunk allow-pass vlan 2905
port trunk allow-pass vlan 3993
port trunk allow-pass vlan 3994
</code>

=== Junos ===
Junos configs are very hierarchical. Indentation for patterns is not necessary, For headers it is. Any comments in the config between '/*' and '* /' will be ignored.

NOTE: every line in a juniper config that ends with a ';': this semicolon is not needed in its pattern


*/