Trigger sections are optional but can add a lot of flexibility to a CCS script. They are used to process output from CLI commands initially executed by another Action (or possibly another Trigger) section. (The figure to the left shows an Action calling a Trigger section.) Triggers can be used to process the CLI output from the first batch of CLI commands in an Action section, by executing another batch of more-detailed commands on the same device currently being processed. Such detailed commands may be used to extract additional information required for later Actions, Triggers or Issues; among the possibilities is to change the device configuration to actually fix a problem.

Triggers perform "IF –> THEN" logical comparisons of the results of CLI commands, iterating over all occurrences of a given pattern in the output stream. Triggers are the only looping mechanism provided in CCS. They can call other Triggers, allowing multiple levels of logical checks before taking final action.

The primary difference between an Issue section and a Trigger section is that the Trigger executes a set of commands compared to an Issue which generates an Issue for NetMRI to report. They both use variables and templates to define patterns of interest, and they can both use filter expressions to determine if something needs to be done.
Triggers support the following attributes:

*Trigger-Template and/or Trigger-Filter must exist in a Trigger section.

Trigger:

Used In: Trigger sections

Status: Mandatory

Defines the trigger type. The preceding Action sections call the value defined in the Trigger: attribute, using the Output-Trigger attribute. All trigger names must be unique in the current script.

Example

...
Output-Triggers:

Find ACL

########################################################################
Trigger:

Find ACL

Trigger-Description:

Used In: Trigger sections

Status: Optional

Optional attribute to describe the functions for the current trigger.
When CSS detects the Trigger-Description section, the following description is not treated as code and is otherwise ignored.

Example

Trigger-Description:
The following Trigger-Template is applied to the output stream of the previous Action-Commands to determine if the following Trigger-Commands should be executed.

Trigger-Template:

A text snippet that defines the command syntax to match against the output from the device. You can call values from variables in a Trigger-Template to flexibly match multiple instances or to detect a particular value.

When NetMRI's CCS scripting engine receives the output from the executed command sequence, CCS references the first output trigger to process the command output. Within the trigger, a segment of command output, using variables and wildcards if necessary, ranges over the output stream and executes an associated set of Trigger-Commands if necessary (see following section).

Example

Trigger-Template:

username $username password 0 .*

This example shows Cisco but can be for any vendor supported by NetMRI.

The Trigger-Template provides a pattern matching window that is applied across the most recent CLI command output stream. The template matches characters in the command output zero to possibly many times. If no matches occur, the script stops the execution of the trigger. If one or more template matches is found, the trigger continues processing the Trigger-Filter for each match.

Example

Consider the following Trigger-Template which uses declared Trigger-Variables ($ifName and $ifDuplex); note the use of the “+” operator, which matches against 1 to n instances of a set of characters:

Trigger-Template:

[[$ifName]] is.+, line protocol is.+

...

Keepalive.+

[[$ifDuplex]]-duplex.+

and the following output stream:

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

FastEthernet0/1 is up, line protocol is up

Hardware is Fast Ethernet, address is 0002.b9fc.b701

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive not set

Auto-duplex (Half), Auto Speed (10), 100BaseTX/FX

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

The Trigger-Template matches the previous command output stream, because the Template contains several regular expressions and fixed patterns.

Because the Trigger-Template matches at least once, the processing of the Trigger continues. Because the Template uses previously defined Trigger-Variables (within double-brackets “[[ ]]”), the script extracts corresponding values from the command output stream for use in the Trigger-Filter. For example, $ifName now contains the value FastEthernet0/1 and $ifDuplex contains the value Auto.

The pattern matching notation “...” appearing in the above Trigger-Template means “match 0 or more lines” and is used to skip over multiple lines of text while scanning for the next occurrence of a pattern (e.g., the text Keepalive).

Trigger-Commands:

Used In: Trigger sections

Status: Mandatory

The Trigger-Commands attribute enables substantial follow-up actions to be taken by a Trigger section following an Output-Trigger call. The attribute allows the script author to execute a sequence of CLI commands for all template matches that pass the Trigger-Filter criteria. Each command must appear on a new line. You can use Conditional processing with { } notation (similar to Action-Commands in the Action-Commands: topic) in Trigger-Commands as well.

Besides CLI commands, the Trigger-Commands attribute accepts sleep directives, which pause script execution for a specified number of seconds.

sleep: <numberOfSeconds>

Example

Trigger-Commands:

config terminal

interface $ifName

spanning-tree portfast

exit

exit

SET: $updateMade = "yes"

Example

Trigger-Commands: { $priority eq "0" and $state ne "Ready" }

SET: $matchFound = "yes"

...

In both cases, the SET variables are newly declared in the script. It forms a basic IF-THEN loop, in this case where IF the device's priority value is "0" and the device's state is determined to not be READY, the new matchFound variable is set to "yes" and further script directives designed to respond to the state will execute.

That SET variable also can be referenced anywhere else as needed in the script after declaration.

Note: This example is in a Trigger section. A Trigger-Command is the only attribute type that can execute any type of looping or iterative processing in a CCS script. For more, see the Trigger-Commands: section of this Guide.

Trigger-Filters:

Used In: Trigger sections
Status: Optional

The Trigger-Filters attribute is used to determine if Trigger-Commands and Output-Triggers attributes in the Triggers section of the script should run. If no Trigger-Filter exists, the script runs for every match identified by the Trigger-Template.

Trigger-Filters can contain Script, Trigger and SET variables and apply to every template match instance.

Example

Trigger-Filter:

$adminMode ne "trunk" and $operMode ne "trunk"

Example

In this case, a match is made with a boolean OR:

Trigger-Filter:

$ifName eq "FastEthernet0/0" |
$ifName eq "FastEthernet0/1"

Trigger-Prompt:

Used In: Trigger sections

Status: Optional

Use the Trigger-Prompt attribute to override the device prompt when the command(s) executed in the Trigger-Commands attribute change the prompt on the device.

Note: The default CCS scripting engine works for many of the cases.

Example

Trigger: acl test3

Trigger-Template:

ip access-list extended test2

Trigger-Prompt: /(DEVrtr01(config-ext-nacl)#)|(DEVrtr01(config)#)|(DEVrtr01#)/

Trigger-Commands:

conf t

ip access-list extended test3

exit

Trigger-Variables:

Used In: Trigger sections

Status: Optional

CCS scripts use the Trigger-Variables attribute to define "patterns of interest" found within the output generated by CLI commands. Trigger-Variables are used in Trigger-Templates to extract certain values from command output to be used in determining if certain conditions exist on the device. The format of Trigger-Variables is as follows:

<variableName> <extractPattern> <evalType>

<VariableName> can be any name (without blanks) that starts with $. Variable names are case-insensitive and can be accessed anywhere in the script.

<ExtractPattern> can be specified using any of the keywords listed below, or specified as a regular expression.

<evalType> specifies how the variable value should be evaluated when used in a logical filter expression, as a string (this is the default if nothing is specified), a number, or an ipaddr.

For example, to look for interfaces where $ifIndex < 10, specify int as the <evalType> for the $ifIndex variable. By default, all variables are evaluated as strings in filter expressions.

Example

Trigger-Variables:

$ifName String

$ifIndex /\(?\d{3}\)?[ -]?\d{3}-\d{4}/ string

$phoneno Word

Example

Trigger-Variables:

$ifName /FastEthernet.*/

Trigger-Template:

interface [[$ifName]]