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 BMC 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. BMC 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. BMC Network Automation includes the device's discovered model in the BNA Device Attributes configuration. For example, the model of a Juniper device might look like the following in the BNA Device Attributes configuration:

Model: SA-2000

Note that the exact format or wording of the model a vendor reports for EOL and what BMC 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 BNA Device Attributes configuration.

Consider the scheduled EOL of the Juniper device as April 15 and the current date as March 1. 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. For example, Juniper SA-2000 End Of Life.

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 Juniper, Juniper SA Series as the device type.

Applicable Models

Select all models.

Minimum OS VersionEnter * for all versions.
Maximum OS Version

Enter * for all versions.

Applicable TrailsSelect BNA Device Attributes.
Violation SeveritySelect Info or your preferred severity.
Activation DateSelect 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 DateSelect blank or empty because once a device is at end of life, it stays that way.
CategorySelect 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 BNA 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

Was this page helpful? Yes No Submitting... Thank you

Comments