Configuration template

This is a Privilege based feature: The user will be able to access, view, add, edit, delete, execute & export, only if privileges have been given by the administrator. This will be defined under roles and privileges.

This menu is accessible only if the below privilege has been checked.

From “Templates” menu click “Configuration Templates”.

Configuration Template Grid page, lists down all templates created by the user and also the templates which are assigned to the same user by admin or template management full privileged user.

The Access Control List feature in this module lets the admin privileged users to decide who can view, edit or delete any specific templates in NCCM.

Configuration Template Grid shows

• Template ID - To know the creation sequence (recently created or old).
• Name of Template – Name will be unique and will be referred in other features while using the Template.
• Vendor – The Vendor Device where this template can RUN (Vendor Specific).
• OS Type – The Vendor Device OS Type where this Template can only RUN (OS specific).
  • In case the Template can RUN on all OS Type of same Vendor, Input OS Type as ‘ALL TYPE’.
  • Example: Tejas may take different command syntax for same operation.
• Type of Template – NCCM Supports 9 Types of Templates and each of them will be explained in detail, in the following sections.
• Active Status – Enabled/Disabled – During execution, this flag does not impact those Jobs that are set as Disabled (template disabled) but is already assigned to an Upload Job. On the other hand Disabled Templates will not be allowed to be used in New Upload Job Creation.
• Execution ready or Production Status – Should be in Ready State to use in Upload Job for configuration change.
• Approval Required Flag - The value will be always Yes (Approval is always required).

NOTE: When the Template is used in Upload Job by a white listed user or Approver, Approval Process will be by-passed and Job will go for execution directly.

• Created User – User who created the Template.
• Description – Template description which defines the operation purpose.

Configuration changes like “Provisioning”, “OS Upgrade”, “Service Creation”, “Service Deactivation” and “any change” on Networking Devices can be done using Configuration Templates.

Template Execution

• Template is a Collection of commands (one or more) with zero or more variables to be executed on devices for specific operations (like ACL Modification, Route ADD, Interface NAC configuration, Interface IP Change, Interface Enable Disable, SNMP/LLDP/CDP enable or Disabling, OS Upgrade). By substituting different values (to variables) for different Devices, user can reuse the same template for similar operations on multiple devices. Device Credentials, Device Interface Name/IP Address, command inputs will become a variable portion in command template.
• Templates are vendor and OS Type specific, which means, separate templates are required to be built for the same operation on two different vendor devices or for two different OS Types of same vendor. This is due to a difference in the command syntax and command formats for the same operation on two vendor devices.
• Apart from command portion, Templates also contain information of Vendor, OS Type, Series and Model where template can RUN, along with ACL configuration which defines who all can manage the Templates.
• Once the Configuration Template is built, user can execute the Templates on devices using the Upload Job functionality.
• Configuration Template (Network Diagnosis type) can be used in Network Diagnosis functionality for Checking the Device’s operational data and for doing simple configurations like Crypto cache clearing, daily diagnosis check etc., (Which does not affect and is not a part of the Device Configuration).
• Configuration Template command portion should be written in XML format.
• Configuration Template inherits Jinja2 Templating standards where user gets all benefits of Jinja2 Template such as Data Types (Integer, Boolean, List), Control Statement (If – elif – else, For Loop, while Loop), Operator condition (=, != , >, <, >=, <= etc.).
• Same Template framework and fundamental is followed in
  • Configuration Profile - Used by Configuration Download Job to download Configurations, Inventories and Operation Data’s
  • OS Image Download and Upgrade
  • Configuration Triggers
  • CLI (Command Line Interface) Job

User will be given Direct CLI (SSH or Telnet) access to the Devices from NCCM Application (like a Gateway process) for changing configurations.

How to write Command Portion in Template

NCCM supports two ways of writing commands in Template

1. Plain command format (Writing Device Command as it is)
   • In plain command format, user writes the device commands as it is defined by the vendor. This format will be used only inside Command Execution & Network Diagnosis template type but not in Download Job Profiles, OS Upgrade Job, Configuration Trigger
   • Though it is a simple way to write the template, it is not a recommended format, since additional information to command such as command timeout, response prompt, error check condition on response cannot be used.
   • The Timeout for each command using plain command format is always 30 seconds and each command takes the full 30 seconds even if the execution is completed before.
   • Sample command portion for changing Device hostname in plain text format:

     conf t

     hostname newname

     exit

   XML Command Format

In XML command format, each command is enclosed in XML node and additional input to the command like command timeout, prompt, expected pattern, previous match, action will be added in XML node properties.

• XML command format is the recommended format across all features of NCCM including Download, Upload, Upgrade and Diagnosis purpose.
• Sample command portion for changing Device hostname in XML format:

  <command prompt=”#” timeout=”10”>conf t</command>

  <command prompt=”#” timeout=”10”>hostname newname</command>

  <command prompt=”#” timeout=”10” action=”exit”>exit</command>

XML Command Syntax

<command property1=”value” property2=”value”> Device Command </command >

property1=”value” property2=”value” : Command properties

Device Command : Actual command

XML Command Sample

<command prompt=”#” timeout=”10”> hostname newname</command>

The device command for every device will be inside the Data portion of XML Node and the additional properties or information will be inside XML’s property portion. Property value must always be inside Double quotes character.

NCCM supports the following properties

1. timeout - value (in seconds). Every command execution is considered as complete either till the prompt pattern value is matched or till the timeout second count is reached.
2. prompt - is generally the last character of command response that informs the command execution completion of a Device. When the response from Device is not matching the prompt, command execution is considered as COMMAND ERROR.

   prompt=”#”

1. The prompt can be a single character or a word or a line.

   prompt=” #”

   prompt=”Router27#”

   prompt=”[Are you confirm the reboot action]?”

2. The prompt value is always a regex pattern and it can be escaped using \ to make exact match. Below example. (Dot) regex character is escaped with \ to consider it literally as ‘.’ (Dot) and not as regex pattern.

   prompt=”\.”

   Follow the URL https://regex101.com/ to verify or check the regex pattern before saving the template.

3. The prompt also supports multiple patterns (multiple single characters or multiple words) to match the command execution completion

   prompt=”[#,>,\$]”

   prompt=”[Username, login, User]”

4. When the given prompt is not matched within the specified timeout seconds, NCCM will declare it as Command error and stop or continue the execution based on Task IP/Command continuation input from Upload Job task input.

1. “action” property is used to

1. Inform NCCM that exit command is executed and to not wait for prompt.

   action=”exit”

2. Inform NCCM to store the result of command for storing the configuration output of device and also to copy the command output for Trigger parsing.

   action=”output-to-store”

1. “shell” property is used to Inform NCCM to open a remote session (TELNET or SSH) from a Device for further command executions.

   shell=”remote”

   <command shell="remote" prompt="Password"> ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null {{Profile.ssh_loginname}}@{{Device.IPaddress}} -p {{Profile.ssh_port}} </command>

2. “error_pattern” property is used to check the command response; if the pattern values match the command response, command execution is considered as COMMAND ERROR. Similar to prompt property, error_pattern can take multiple values. NOTE: - Prompt property is used to check for command completion however error_pattern property is for checking whether the Response is as per the expectation.

   error_pattern="[Unknown command, Invalid Command]"

   Example: when “copy tftp” command is not supported by a device, response will be %Error opening tftp and the error_pattern to catch the error will be

   error_pattern="[%Error opening tftp]"

   The below properties also follow the same principle as error_pattern .

3. “expected_pattern” property is used to check the command response; if the pattern value does not match the command response, command execution is considered as COMMAND ERROR.

   expected_pattern="[bgp is enabled]"

4. “expected_any_response” property is used to check the command response; if the device does not respond to any data, command execution is considered as COMMAND ERROR. The value of property is not required and hence input can be empty double quotes

   expected_any_response="

5. “expected_empty_response” property is used to check the command response; if the device responds with any data, command execution is considered as COMMAND ERROR. The value of property is not required and hence, input can be empty double quotes

   expected_empty_response=""

6. “expected_count_response” property is used to check the command response; if the device response line is not equal to count value data, command execution is considered as COMMAND ERROR. The value of property is the response line count. The count can be any number

   expected_count_response="5"

   NCCM expects a 5 line response.

7. “expected_count_response” property is used to check the command response; if the device response line is not equal to the count value data, command execution is considered as COMMAND ERROR. The value of property is response line count. The count can be any number.

   expected_count_response="!5"

   NCCM expects the response to be anything other than 5 lines.

8. “expected_count_response” property is used to check the command response; if the device response line is less than 6, command execution is considered as COMMAND ERROR. The value of property is count of line. The count can be any number.

   expected_count_response=">5"

   NCCM expects the response to be greater than 5 lines.

9. “expected_count_response” property is used to check the command response; if the device response line is greater than 4, command execution is considered as COMMAND ERROR. The value of property is count of line. The count can be any number.

   expected_count_response="<5"

   NCCM expects the response to be less than 5 lines.

10. “expected_count_response” property is used to check the command response; if the device response line is less than 5, command execution is considered as COMMAND ERROR. The value of property is count of line. The count can be any number.

    expected_count_response=">=5"

    NCCM expects the response to be more than 4 lines.

11. “expected_count_response” property is used to check the command response; if the device response line is greater than 5, command execution is considered as COMMAND ERROR. The value of property is count of line. The count can be any number.

    expected_count_response="<=5"

    NCCM expects the response to be less than 6 lines

12. “type” property is used to store the command response under property value. NCCM stores the command output in Operation Data store.

    For example:

    If the output of the command, show IP interface brief is required to store in NCCM as Interface Brief, XML command should be written as

    <command prompt=”#” timeout=”5” type=”Interface Brief”> show IP interface brief</command>

Sample command to shut down an interface in plain text and XML format.

Sample command to enable syslog in plain text format and XML format.

Below are some sample commands to replace the Device configuration file from NCCM server.

<command prompt="\]\?">copy tftp: running-config</command>

<command prompt="\]\?">{{Global.managementIP}}</command>

<command prompt="\]\?">{{Job.uploadfilename}}</command>

<command prompt="[\],#]" timeout="300">running-config</command>

<command previous_match="\]" prompt="#" timeout="300">yes</command>

<command action="exit" prompt="">exit</command>

NOTE: Plain text command cannot be written since the timeout of some commands are more than 30 seconds.

NCCM also supports writing of Comments inside the command portion, for better understanding of commands. To define a line as a comment, add # character at the beginning of a line.

Example for writing Comments inside commands:

# Make Terminal Len 0

<command prompt="#" timeout="60">terminal length 0</command>

# Copy the Image to Flash

<command prompt="]\?" timeout="60">copy tftp flash:</command>

# Remove boot system

<command prompt="#" timeout="60">no boot system</command>

NOTE: At the time of execution, NCCM ignores all lines starting with # (comment lines)

NCCM Variable Substitution

NCCM follows Jinja2 Template engine for converting command templates into actual commands. Jinja2 Template engine provides features like

• Variable substitution
  • For substituting specific values for specific Devices
• Variable declaration
• Data structures like Integer, Boolean, List, and Dictionary
• Loop Statements like
  • For
  • While
  • Do while
• Conditional Statements like
  • If
  • If else
  • If elif else
• Conditional operators like
  • =
  • !=
  • in
  • not in
  • > and >=
  • < and <=

Variable Substitution:

Variables are command inputs given by a user dynamically during the execution time.

For example, if the user wants to change the hostname in Cisco devices, the command syntax will be

#hostname <New Hostname>

hostname is the command and <New hostname> is the variable or input portion to hostname command

Through variable substitution, single template is enough to change hostname of all devices same Vendor and OS Type configured in template; else each device requires a separate template.

To substitute a variable, follow the below steps, based on the condition applicable:

• Use “Double Curly Brackets” before and after the variable {{ }}, only if variable is not inside Jinja2 statements

  <command prompt=”#” timeout=“5”>hostname {{Runtime.hostame}} </command>

  Runtime is a substitution object.

• Directly writing variable, if variable is inside Jinja2 expression statement {% %}

  {% if Runtime.hostname. == “router27” %}

NCCM Substitution Objects in Template:

NCCM supports 10 types of substitution objects for Variable substitution within configuration template

1. Runtime object

   Runtime object will be used in Configuration Upload and Network Diagnosis activities. Runtime object variables will be converted into user input form to get values while configuring upload task or Network Diagnosis creation.

   Ex {{Runtime.hostname}}

2. Global object

   All Global parameters configured in NCCM are available through Global object for Variable substitution.

   Ex {{Global.managementIP}}

3. Type object

   Defines the field, based on the variable type specified such as Text Area, Text field, DropDown, Multi DropDown.

   Ex : Type.Speed=DropDown

4. Default object

   The default value for Type Object I defined here.

   Ex: Default.Speed=10,100,1000

5. Remark object

   Displays the Text on mouse hover on the Variable Name.

   Ex: Remark.Speed=enter speed of interface

6. Optional object

   If variable is declared ‘Optional’, the input for the field is not mandatory.

   Ex: Optional.VariableName

7. Check object

   Ensures that the Input format matches the defined format.

   Ex: In Textfield, it should allow only 1 to 255

   ^([1-9]|[1-9][0-9]|[1-2][0-5][0-5])$

8. LOCAL_SHELL object

   LOCAL_SHELL object gets values from LOCAL_ACCOUNT profile, configured in Device credential for Variable substitution.

   Ex {{LOCAL_SHELL.username}}

9. Device object

   Device object gets values from Device database of corresponding Device where command execution takes place.

   Ex {{Device.IPaddress}}

10. Interface object

    Interface object gets values from Device Interface database of the corresponding Device where command execution takes place.

    Ex {{Interface.name}}

    Ex {{Interface.description}}

11. Job object

    Job object gets values from Job Database (Upload or Download Job) of corresponding Device where command execution takes place.

    Ex {{Job.name}}

12. Profile object

    Profile object gets values from Profile Database (Configuration Profile) of corresponding Device where command execution takes place.

    Ex {{Profile.download_profile.user_name}}

13. Trigger object:

    Trigger object gets values from Configuration Trigger Database of corresponding Trigger name used in Configuration Template.

    Ex {{Trigger.triggername}}

    Note: A template can have more than one Trigger variable.

14. Profile object:

    Profile object gets values from Device Credential Database of corresponding Device (Device Credential) where command execution will take place.

    Ex {{Profile.ssh_loginname}}

15. Time object:

    Time object gets values from NCCM server based on current time which is for substituting time values in a template during execution

    Ex {{Time.now}} – Time in unix epoc format

    {{Time.YYYYMMDD}} – Time in YYYY MM DD format

    {{Time.uniquestring}} – Unique string

Conditioning in Template:

NCCM supports condition based Templating using “if”, “if else” and “if elif else” conditional statements

1. ”If” Condition:

   {% if Runtime.interface_name == "GigabitEthernet0/0" %}

   IP address 192.168.1.1 255.0.0.0

   no shutdown

   {% endif %}

2. ”If else” Condition:

   {% if Runtime.interface_name == "GigabitEthernet0/0" %}

   IP address 192.168.1.1 255.0.0.0

   no shutdown

   {% else %}

   IP address 192.168.2.1 255.0.0.0

   no shutdown

   {% endif %}

3. ”If elif else” Condition:

   {% if Runtime.interface_name == "GigabitEthernet0/0" %}

   IP address 192.168.1.1 255.0.0.0

   no shutdown

   {% elif Runtime.interface_name == "GigabitEthernet0/1" %}

   IP address 192.168.1.1 255.0.0.0

   no shutdown

   {% else %}

   IP address 192.168.2.1 255.0.0.0

   no shutdown

   {% endif %}

Looping in Template:

NCCM supports loop based Templating using “for” loop statements

”For Loop” Condition:

{% for interface_name in Runtime.interface_names %}

{% if {{interface_name}} == "GigabitEthernet0/0" %}

IP address 192.168.1.1 255.0.0.0

no shutdown

{% endif %}

{% endfor %}

Guidelines for Configuration Template:

#Substitution, Conditioning, Looping in Template should be in Jinja2 standard. Refer http://jinja.pocoo.org/docs/2.10/ for more tutorials.

Points to Remember

Always enclose the commands within {% %} for "if" and "for", "while" conditional statements

Always enclose the variables inside {{ }} for substitution

Sample Template Configuration

Example 1: Create an Empty List and add values into List and DO a simple ‘For Loop’

# Declaring a string variable to store value from Runtime or user. Default (“”) function will make variable empty string till USER input

{% set myinput = Runtime.interface_list | default(“”) %}

# Converting User Input to a list using Split function

{% set mylist = myinput .split(",") %}

#Doing for Loop or Looping of Each Item

{% for each_interface in mylist %}

<command prompt="#">int {{each_interface}}</command>

<command prompt="#">shutdown</command>

# for requires endfor to close the section

{% endfor %}

Example 2: Conditions (if case elif Case and else case)

{% for each_interface in mylist %}

{% if each_interface == "Gi0/1" %}

<command prompt="#">int {{each_interface}}</command>

<command prompt="#">shutdown</command>

{% elif each_interface == "Gi0/2" %}

<command prompt="#">int {{each_interface}}</command>

<command prompt="#">no shutdown</command>

{% else %}

<command prompt="#">I dont know</command>

{% endif %}

{% endfor %}

Example 3: Taking List Input from a Trigger

#down_interface_list_cisco_ios is a Trigger in Configuration Trigger

{% set mylist1 = Trigger.down_interface_list_cisco_ios | default([]) %}

{% for each_interface in mylist1 %}

<command prompt="#">int {{each_interface}}</command>

<command prompt="#">shutdown</command>

{% endfor %}

Example 4: Disable the Interface named ‘Ether’

# String Manipulation startswith, endswith, find, lower, upper, strip

{% set myinput = Runtime.InterfaceNames | default ("") %}

{% set mylist = myinput.split(",") %}

{% for each_item in mylist %}

{% if each_item.lower().startswith("ether") %}

<command prompt="#">int {{each_item}}</command>

<command prompt="#">shutdown</command>

{% endif %}

{% endfor %}

Example 5: Taking First Element from the Trigger

{% set mylist = Trigger.down_interface_list_cisco_ios | default ([]) %}

{% if mylist %}

<command timeout ="10" prompt ="#" >config t</command>

<command timeout ="10" prompt ="#" >interface {{mylist[0]}} </command>

<command timeout="10" prompt ="#" >IP address 172.17.230.2 255.255.255.252</command>

<command timeout ="10" prompt ="#" >no shut</command>

{% endif %}