Grammar examples

The following examples assist you in defining a rule grammar:

Cisco IOS banner

The following example addresses a very common application for a rule, the enforcement of login banners. The following example presents the rule grammar necessary to enforce login banners for Cisco IOS devices.

An IOS banner usually looks something like this in the running configuration:

banner motd ^C
Welcome to my company network. Unauthorized access
is strictly prohibited.
^C

The first line in a typical banner begins with a configuration command (banner motd or aaa authentication banner, followed by a control-C to delimit the start. The lines that follow contain the text to be displayed in the login banner. The last line in the banner contains another control-C delimiter.

There are several ways to capture this in the rule grammar. The main trick is to be sensitive to the binary control-C characters. You usually have to display the contents of a running configuration first to copy the special control-C character into your paste buffer. You can then paste this character into the rule edit fields.

The recommended technique is to select a domain of Selected Blocks, as described below. This rule covers correcting an incorrect banner, as well as adding a banner to a configuration that does not have a banner.

To create this Cisco IOS banner rule, the following changes were made from the Grammar tab in the Edit Rule page.

Field	Explanation or Reasoning
Trigger	Select None. The command of interest is a simple command line that you want to appear in every configuration.
Domain	Select Selected Blocks. You want to check the contents inside a range of lines.
Begin	Select Line, Exclusive, and a string of `banner motd ^C`. The example block begins with this exact line, and you do not need to include it in the subject. Cisco IOS does allow the banner text to start on this line, right after the control-C; if your banner did that, you would set this field to Pattern, Inclusive, and a string of `^banner motd .+`. Note: The control-C character is displayed in a different style by different browsers; in this example, it looks like two small lines.
End	Select Line, with a string of `^C`. The example banner ends with the control-C delimiter on a line by itself.
Include blocks containing pattern	Select None. You want to check all banner motd blocks.
Ignore blocks containing pattern	Select None. You want to check all banner motd blocks.
Case Sensitive	Option unselected. It is not necessary to be concerned about any variation in the case of the begin and end strings in this example.
Ignore Comments	Option selected. Ignores comment lines when searching for the domain.
Ignore Line Breaks	Option unselected. You want the banner to be broken up into lines exactly as specified.
Distinct End Lines	Option unselected. The domain is not going to be deleted, so you do not need to be concerned about the end line handling.
Domain Frequency	Select Appears exactly once (1). You want every configuration to have this banner.
Subject	Select Lines and the AND option. You want all of these lines entered exactly as they appear.
Lines	Enter your exact banner text.
Case Sensitive	Option unselected. In this example, you do not need to be concerned about any variations in case; you can accept any banner that contains the right words regardless of their case.
Ordered	Option selected. You want the banner lines presented in the order you entered them.
Contiguous	Option selected. You do not want any extra lines between the lines you entered.
Ignore Whitespace	Option selected. You do not need to be concerned about any variation in spacing.
Subject Frequency	Select Appears exactly once (1). You want the banner to contain the lines you entered.
With no other lines containing pattern	Enter *`.`**, which means anything. You do not want anything else in the banner other than the lines you entered.

Back to top

Cisco IOS interface

The following example presents the grammar necessary to create a rule that will ensure that all shutdown interfaces have no IP address for Cisco IOS devices.

Here is how such an interface block might look in the running configuration:

interface FastEthernet0/0
 ip address 1.2.3.4 255.255.255.0
 shutdown
!

To create a rule that would remove the unwanted IP address lines from Cisco IOS configurations, the following changes were made from the Grammar tab in the Edit Rule page.

Field	Explanation or Reasoning
Trigger	Select None. The blocks of interest will be located using the fields in the Domain section.
Domain	Select Selected Blocks. You are interested in all interfaces, which can be identified using the begin and end boundaries.
Begin	Select Pattern, Exclusive, and a string of `^interface .+`. You are interested in every interface block.
End	Select Pattern and a string of `^\S`. Block contents all start with at least one space, so block ends when a line starts with a non-space.
Include blocks containing pattern	Enter `^\s+shutdown`. You are looking only for interface blocks that have `shutdown` in a line.
Ignore blocks containing pattern	Select None. You are interested in all interface blocks.
Case Sensitive	Option unselected. You do not need to be concerned about any variation in the case of the begin and end strings.
Ignore Comments	Option selected. Ignore comment lines when searching for the domain.
Ignore Line Breaks	Option unselected. You want to search the configuration line by line.
Distinct End Lines	Option unselected. Cisco IOS interface blocks can end with a line that starts the next interface block, which does not actually belong to the preceding interface block.
Remove Emptied Block(s)	Option unselected. Interface blocks can be empty and Cisco IOS can accept it without error; also, most interfaces cannot be deleted anyway.
Domain Frequency	Select Appears any number of times. You want any interface block that exists to be checked, and it is possible that there may be none at all.
Subject	Select Pattern. You want to look for a varying type of line.
Pattern	Enter `^\s+ip address .+`. You want to locate an IP address followed by some address that could vary per interface.
Case Sensitive	Option unselected. You do not need to be concerned about matching the case of the IP address lines.
Subject Frequency	Select Does not appear (0). If the line should appear, the correction would be to remove it.
With no other lines containing pattern	Do not make an entry. The Pattern field has fully expressed what should not appear.

Back to top

Juniper JunOS SNMP

The following example presents the grammar necessary to create a rule that will ensure that all SNMP communities include at least one client system for Juniper JunOS devices.

Here is what such a community might look like in the running configuration:

snmp {
    community public {
        clients {
            1.2.3.4/32;
            4.3.2.1/32;
        }
    }
}

To create a rule that would enforce each community having at least one client address in Juniper JunOS configurations, the following changes were made from the Grammar tab in the Edit Rule page.

Field	Explanation or Reasoning
Trigger	Select None. The blocks of interest will be located using the fields in the Domain section.
Domain	Select Selected Nested Blocks. You are looking for `community` sub-blocks inside the top-level `snmp` block.
Nesting	Enter patterns to match the outermost `snmp` block and its `community` inner blocks. Since there is variation in the community names, you should use patterns.
Innermost block begin	Select Exclusive. You do not need to include the community name line as part of the subject.
Include blocks containing pattern	Do not make an entry. You want to check all `snmp community` blocks.
Ignore blocks containing pattern	Do not make an entry. You want to check all `snmp community` blocks.
Case Sensitive	Option unchecked. You do not need to be concerned about any variation in the case of the begin and end strings.
Ignore Comments	Option selected. Ignore comment lines when searching for the domain. Comments are not relevant for this example.
Ignore Line Breaks	Option unchecked. You want to search the configuration line by line.
Distinct End Lines	Option selected. The close brace always goes with the line with the matching open brace.
Domain Frequency	Select *Appears any number of times (0.. )**. There can be many `snmp community` blocks, or there can be none at all.
Subject	Select Patterns and the AND option. You are looking for any client addresses (not a specific address), so you must use patterns.
Patterns	Enter the `clients` block header, a client IP address line, and the `clients` block end brace. You are looking for the presence of the `clients` block with at least one IP address inside of it.
Case Sensitive	Option unchecked. You do not need to be concerned about matching the case of the `clients` lines.
Ordered	Option selected. You can expect a `clients` header line to be followed by a client IP address line, followed by an end brace.
Contiguous	Option unchecked. You must allow for there being annotation lines inside the `clients` block, so you cannot assume that the `clients` header line will always be immediately followed by a client IP address line. There can also be multiple IP address lines, so you cannot assume the first IP address line is always followed by the closing brace.
Correct Missing	Option selected. If there is no `clients` block, you want to add one.
Corrections	Enter the `clients` block to add when it is missing from the configuration. This block should supply a specific client IP address. You can use a global substitution parameter to plug in your central SNMP server; another option is to enter in the server IP address here.
Ignore Whitespace	Option unchecked. You want the indentation to be preserved (although the device does not really care about it).
Force All Corrections	Option unchecked. Since you know that the `clients` block does not appear unless it contains an IP address, you can safely allow the system to apply the corrections using its line-by-line logic. That is, there is one correction line for each subject pattern, and when a pattern is missing, the TrueSight Network Automation system adds the corresponding correction. Since all the subject patterns are all present or all are missing, the line-by-line correcting comes out right (and never adds just a dangling IP address line).
Subject Frequency	Select *Appears at least once (1... )**. You want each community to have the `clients` block with at least one IP address inside it.
With no other lines containing pattern	Do not make an entry. You do not need to remove anything else from the community block.

Device End of Life

When a vendor reports that a piece of equipment is scheduled to reach the end of its support life (end of life, or EOL), this indicates that you need to replace that equipment within a reasonable time. TrueSight Network Automation can help remind you to do this by flagging such devices as being in violation of an end-of-life rule. You can create the rule in advance of the end-of-life date and have the system start flagging violations once the end-of-life date is reached. The following example shows how to define such a rule.

A vendor usually reports end of life by model. TrueSight Network Automation includes the device's discovered model in the TSNA Device Attributes configuration. For example, the model of a Juniper device might look like the following in the TSNA Device Attributes configuration:

Model: SA-2000

Note that the exact format or wording of the model a vendor reports for EOL and what TrueSight Network Automation discovers as the model from a device might not be exactly the same. You must use the string the system discovers and stores in the TSNA Device Attributes configuration.

Consider the scheduled EOL of the Juniper device as April 15. Create a rule with Activation Date as April 15. Once you save this rule, the system will check daily to see if it is activated (that is, if the current date is April 15). On April 15, the system will flag violations in the devices that match the rule.

While creating the rule, add the details as shown on the Details tab.

Field	Explanation or Reasoning
Name	Enter a name for the rule.
Annotation	Enter the annotation for the rule.
Rule Set	Assign the rule to a rule set. For the automatic rule activation to work, this rule set should be enabled.
Device Type	Select the applicable device type, such as Juniper, Juniper SA Series.
Applicable Models	Select either all or the appropriate individual models. If you select all models, performance might be slightly impacted as more devices will be checked against this rule.
Applicable OS Images	Select Range. Enter * for all versions. Note: This option is available through Minimum OS Version and Maximum OS Version fields in version 8.9.00.
Applicable Trails	Select TSNA Device Attributes.
Violation Severity	Select Info or your preferred severity.
Activation Date	Select the vendor's end-of-life date 04/15/16 as the activation date. Prior to this date, the system will not report this rule as violated.
Deactivation Date	Select blank or empty because once a device is at end of life, it stays that way.
Category	Select Other or your preferred category.

Add the rule grammar as shown on the Grammar tab.

Field	Explanation or Reasoning
Trigger	Select None.
Domain	Select Entire Configuration.
Subject	Select Line. You are looking for a line in the entire configuration.
Line	Enter Model: SA-2000. You are looking for the presence of `Model: SA-2000` in the entire configuration.
Case Sensitive	Leave the option unchecked. You do not need to be concerned about matching the case of the `Model: SA-2000` line.
Ignore Whitespace	Leave the option checked. Whitespace is not important here.
Subject Frequency	Select Does not appear (0). You want to generate a violation when `Model: SA-2000` is found.
With no other lines containing pattern	Leave empty.

If you have many models scheduled for EOL, you might define the rules in one of the following ways:

Define a single rule for each model, whose grammar is a single line
Define a single rule whose grammar includes multiple lines
Define one rule per device type, each with multiple lines

Note that not all device types are capable of discovering the device's model. If you need an EOL rule for such a device, you must find another way to put the device into violation. One option is to add a dynamic field where you enter the model number manually when necessary and leave it blank otherwise. Dynamic field values are also included in the TSNA Device Attributes configuration, and so you can develop rules against those values in the same way as shown for the model value above.

Back to top

Grammar examples

Cisco IOS banner

Cisco IOS interface

Juniper JunOS SNMP

Device End of Life

Comments