Policies are used to verify network device configurations and to enforce consistency of configurations across the network. NetMRI can perform analysis when it detects device configuration changes, or on an ad hoc basis for past, present or future configuration files. Policies drive a key feature of NetMRI— called Policy Compliance.

A configuration Policy consists of one or more rules. Rules use different forms of XML-based regular expression pattern matching against configuration files — and tests of other data NetMRI has collected — to verify that the configuration of the device meets the rule(s). Each rule has a severity level, and can define a device filter to limit the types of devices to which it applies. You may freely re-use rules in different policies.

NetMRI provides a library containing numerous pre-packaged policies. As an example, DISA policies provide the top-level overview of the network's adherence to security and network infrastructure mandates from the Department of Defense. Because networks managed by NetMRI are normally enterprise or data center, Defense Information Systems Agency (DISA)-based Policy Compliance is advisory in nature; DISA guidelines provide a baseline framework for establishing a secure network. NetMRI bases many policies upon published DISA implementation guides. Other policy sets include the use of PCI 3.0 rules to help NetMRI users in commercial businesses to support a baseline of technical and operational security requirements for payment card transactions.

The main vehicle for creating and maintaining Policies is called the Policy Design Center.

Note: The Policy Design Center uses an XML Schema (XSD) to validate all rules before any rules are deployed and used for policy enforcement. This feature reduces chances of errors that lead to an "invalid" result for a rule evaluation. You can immediately download the schema XSD file by creating a new rule, choosing the Raw XML editor, and clicking Download XML Schema. You can also select any admin-defined XML rule from the left pane of the Config Management –> Policy Design Center –> Rules page, clicking the Edit button and then clicking Download XML Schema.

How Policies Work

Policies are defined in the Policy Design Center, then deployed against specific device groups. As NetMRI collects configuration files, SNMP data and other data from devices, it validates through policies deployed against devices for which configuration changes are detected.

Results of policy-based analysis are listed in the Network Analysis –> Policy Compliance tab.

Policy analysis results are also available in two reports:

• The Policy Compliance Summary report provides an overview of the compliance status for all policies and the network devices against which they are deployed.
• The Policy Compliance Details report lists all policies and policy rules, with the devices passing and failing, and the specific reasons for policy violations.

Note: Although only the last running configuration collected from each network device is analyzed during routine policy checks, you can perform an ad hoc analysis of any archived configuration file (or even a future configuration file) for a device by using the test function at Config Management –> Policy Design Center side tab –> Policies.

When a configuration policy violation is detected during routine policy checks, an issue unique to that policy is generated. This issue lists all the devices that experienced policy failures, and provides hyperlinks to open the Device Viewer for individual devices. The Config Files section in the Device Viewer will help you determine which configuration files are causing the failures.

Policies Terminology

• A configuration command is any line found in a device configuration file. Such commands comply with the syntax supported by the specific operating system version found in each device.
• A config file match is a logical test that can be performed on a device's configuration file and/or other collected device data. NetMRI provides several mechanisms for defining config file matches, as described in the following sections. A config file match may include a device filter to limit the devices to which the rule applies. A rule can be included in multiple policies.
• A rule consists of one or more configuration file command matches and/or device attribute checks. Policy rules provide significant capabilities, including searching of data tables (called lists when referred to by policy rules), which allows tighter integration of Perl and CCS scripts with policies.
• A policy consists of one or more rules. A policy may include a device filter to limit the devices to which the policy applies.
• A device filter specifies the devices to which a rule or policy applies. A filter can include one or more config file matches and or one or more device attribute checks. When a device's configuration is being analyzed, criteria in the device filter determine whether the policy should be enforced for that device. If the device matches the criteria, the configuration are verified against the rule or policy. Otherwise, the system performs no analysis for that device against the rule or policy.
• Policy deployment associates policies with device groups. Once deployed, a policy is checked for a device whenever a change is detected in that device's configuration. Deployed policies are checked for each applicable device at least one per day, even if no changes are detected for the device.

A General Approach to Policy Development

Developing Policies is straightforward. In the Config Management –> Policy Design Center tab, you can take the following broad steps to create and use Policies:

1. In the Rules tab, create rules and assign device filters. You can also test rules in this tab.
2. In the Policies tab, create the policy by selecting rules and assigning device filters. You can also test the policy in this tab.
3. In the Policy Deployment tab, choose the device groups to run the policy against.
4. After NetMRI performs the analysis, you can view the results in the Network Analysis –> Policy Compliance tab. After a policy is deployed it will take five to ten minutes to begin seeing results in this tab. You can also review results in the Policy Compliance Summary and Policy Compliance Details reports.

The following sections describe further details about policy development.

Built-In Policies

NetMRI provides a set of sample policies for developing new policies based on organization, industry or government best practice guidelines or from local expertise. In all cases, you can refine the templates to suit your deployment.

The sample policies are read-only. This prevents any changes you make from being lost when Infoblox releases newer policy versions. Before making changes, copy policies or rules using the Copy button, then modify the copy. When you copy a policy, it still references the same rules as the original policy (copying a policy doesn't copy the rules it references). This allows you to copy the policy, then change only those rules that require them, or add new ones.

Rule Editors

If you wish to create custom rules, you can use different methods of editing to create them. You can use graphical blocks of rule logic to perform mixing-and-matching of rule components, or define rules through a full XML code editor backed by a dedicated XML schema. All rules are based on defining the device configuration strings, or entire sections of device configurations, that the rule will match against to perform policy operations.

Four rule editors are provided in the Rules tab:

• Simple Rule Editor enables you to define a configuration file based rule by specifying certain configuration file lines that MUST be present, and by specifying other lines that MAY NOT be present. Several options define how the lines are processed. Normally, each line entered in this editor is considered to be a regular expression that is matched against the configuration file. If you select one of the BLOCK options, the entire contents of the text box are considered a single regular expression. (For more information, see Using the Simple Rule Editor .)
• CPD Editor enables you to specify rules in the legacy NetMRI CPD format. (For more information, see Using the CPD Editor . This editor is provided for compatibility with older releases; Infoblox recommends using other editor types.) For better performance and more understandable logic, use the ConfigBlockCheck element in the Raw XML editor in preference to the CPD editor. For more information, see Using Configuration Block Checks .
• Rule Logic Builder enables you to define individual logical tests, then combine them with AND, OR, parentheses and IF-THEN-ELSE logic. (For more information, see Using the Rule Logic Builder .)
• Raw XML Editor allows modification of a rule's XML representation. When the user saves a new rule in the Raw XML Editor, the XML schema for the policy engine validates the rule, and highlights any problems in the rule when the user attempts to save their work. The XML Editor is the most powerful rule creation tool but also the most technically demanding. (For more information, see Using the Raw XML Editor .)

Note: All four editors are available only for creating new policy rules or editing rules you previously created.

Once you save a new rule, and it was not created in the Raw XML Editor, you can change the rule's editor to the Raw XML Editor. If you create a rule from, for example, the Rule Logic Builder, will see the XML generated by the previous rule editor when you open it in the Raw XML editor. The reverse is not true: If you create a new rule in the Raw XML Editor, and decide to open it in another editor type, the results will not be the same and changes will be lost, because XML code is likely to differ from the output of the other editor types.

You can gain a better understanding of how to formulate rules by examining the example rules included with your appliance.

Using the Raw XML Editor

The Raw XML editor enables creation of more sophisticated Rule logic than is possible through other Editor types such as the Simple Rule Editor.
Effective use of the Raw XML editor requires some basic programming knowledge, particularly for the XML language. You write Raw XML rules in a procedural programming language dubbed ScriptXML. In Script XML, all Raw XML policy rules consist of an XML tree with a root <PolicyRuleLogic> element:

<PolicyRuleLogic editor='raw-xml'>
   <next_element.../>

Several examples are given in the sections Using List Searches and Using Configuration Block Checks .
The root PolicyRuleLogic element is considered a statement block, with all of its child elements representing statements. Each statement has a result value; the result value of the PolicyRuleLogic statement block is either the value of an executed Return statement, or the value of the last executed statement in the block.
The value returned by a root PolicyRuleLogic element must be either a <PolicyRulePass> or <PolicyRuleFail> element. These are the two possible values output by any policy rule.
Raw XML rules are primarily used for configuration file checks, and can contain numerous elements such as complex regular expressions, objects, variables and flow control directives. We describe all of these elements in this section.
An example listed below shows the basic <PolicyRuleLogic> element in a definition that will always match:

<PolicyRuleLogic editor='raw-xml'>
  <PolicyRulePass/>
</PolicyRuleLogic>

A second <PolicyRuleLogic> element example matches all devices named "foo:

<PolicyRuleLogic editor='raw-xml'>
  <If>
   <Expr op='=='>
      <Expr field='DeviceName'/>
     <Expr value='foo'/>
   </Expr>
   <Then>
     <PolicyRulePass/>
   </Then>
   <Else>
     <PolicyRuleFail/>
   </Else>
  </If>
</PolicyRuleLogic>

Note the use of subordinate elements <if>-<then>-<else> and <Expr op>.

Note: Several elements are defined as expression types, including <ConfigBlockCheck>, <ListSearch>, <Expr>, <ConfigFileCheck> and <CPDCheck>.

Note: If a global variable _message is set at the time of a PolicyRulePass or PolicyRuleFail that does not define a message, then that value will be used as the rule message.

Policy Rule XML Capabilities

You can perform the following operations and use the following features in policy rules:

• Searches within Lists (defined in the Configuration Management –> Job Management –> Lists page) of comma-delimited values to enforce consistency and reduce the number of rules needed to perform similar tasks. Enables better integration of scripts and policies (for an example, see Using List Searches );
• Calling a Policy Rule from within another Rule –The new PolicyRuleCall element may be used to call one rule from within another. This enables improved re-use of rule logic, and works something like a function call. The caller may override the severity of the called rule;
• Configuration block checks – supplements or replaces the CPD functionality used in the CPD editor. It allows you to break a configuration file into blocks, and then perform analysis on each of those blocks. These may be nested as desired by the administrator writing the rule. For more information, see Using Configuration Block Checks ;
• Use expressions to perform logical and mathematical operations, and for reading variables. You use the Expr element to perform these and other actions (for more information, see Regular Expressions in Policy Rules and the section Using the Expression <Expr> Element );
• Support for arrays. Array indices begin at Zero. In XML rules, the Expr element can use the following operators to work with arrays:

• Looping. The Raw XML Editor supports two types of looping, including:
  • ForEach, which loops through an array, executing the Do code block once in each array element until the condition is met. It takes the form:

<ForEach>
  expression
   <Do>
    statements
    ...
   </Do>
 </ForEach>

• • While, which loops until a condition is met. It takes the form:

<While>
  expression
   <Do>
    statements
    ...
   </Do>
</While>

• A new Map element enables a transformation of all elements in an array, by executing a block of statements for each element in the array, returning a rewritten array as the result. It takes the form:

<Map>
  expression
   <Do>
    statements
    ...
   </Do>
</Map>

The expression is evaluated as an array; for each element, a variable (using the default name _map_value) is automatically set and the rule executes the Do code block.
Map and ForEach differ because the return value of ForEach is the value of the last executed statement in the Do block; the return value of the Map element is an array, with each entry being the return value of the Do block for the corresponding entry in the input array. For example, the following code block produces a variable called newarray that contains the values 1, 2, 3, and 4:

<Map output="newarray">
  <Expr op="array">
   <Expr value="0"/>
   <Expr value="1"/>
   <Expr value="2"/>
   <Expr value="3"/>
  </Expr>
  <Do>
  <Expr op="+">
    <Expr variable="_map_value"/>
    <Expr value="1"/>
   </Expr>
  </Do>
</Map>

An example of this type can be useful in combination with methods accessible on an object. The following code block produces an array of interface names:

<Map output="interface_names">
  <Expr field="interfaces"/>
  <Do>
    <Expr object="_map_value" field="ifName"/>
  </Do>
</Map>

Using List Searches

You can search for values in a NetMRI list from inside a policy rule. This allows better integration of policies and scripting (for more information, see Job Scripting ). Using this feature, you can also manage a single list and avoid using large collections of similar rules.
A basic list search appears as:

<ListSearch list-name="list-name" search-columns="search1, search2, ..." result-columns="result1,result2, ..." >
    expression for search1 expression for search2
    ...
    expression for searchX
</ListSearch>

List-name is the name of the list shown on the Configuration Management –> Job Management –> Lists page; search1, search2,... is a comma-delimited list of column names to search; result1, result2,... is a comma-delimited list of result columns to retrieve. (If any column names contain commas, you may use a delimiter attribute to change the comma to another character.)
The rule evaluates each expression, and matches them with the search columns, in the defined order. Then, the rule creates variables, names them for the result columns and sets them to contain the values found in those columns. By default, the rule returns the first matching row; instead, you may use the result-mode attribute (set to all) to retrieve all matching rows. In that case, the variables will contain arrays of the values, with one entry per row.
Consider a policy in which device names must begin with a three-letter site code followed by a hyphen "-" character.
In NetMRI, you define a list titled Site Details with two columns: 'Site Code' and 'Location.' A sample list could appear as follows:

The following rule is defined in the Raw XML Editor. The rule parses the site code from the device name, and the rule uses it to look up the ‘Location.’ The rule then uses it to check that the SNMP location ends with that city name:

<PolicyRuleLogic editor="raw-xml"

xmlns="http://www.infoblox.com/NetworkAutomation/1.0/ScriptXml">

<If>

<Expr op="matches">

<Expr field="DeviceName"/>

<Expr value="^([a-z]{3})-"/>

<!--This is the regex used to match against the Device Name field --!>

</Expr>

<Then>

<!--

The device name appears to be the correct format, so we look up the location via the parsed site code. Here, we rely on the fact that the return value of the ListSearch is the count of the matching rows, and that 0 is considered false.

We evaluate the ListSearch first; if no result is returned, the ConfigFileCheck will not execute due to the short-circuiting of the boolean expression (Expr). If a result is returned, the ListSearch call will set a variable named "Location" containing the result of the first match to "Site Code".

Then, we do a ConfigFileCheck to see if the config file contains exactly one line that starts with "snmp-server location" and ends with the location. To do this, we construct a result expression using the Location variable.

We can construct a more descriptive message for the PolicyRuleFail, that includes the current site code and location, as well as the intended location, but did not for simplicity here.

-->

<If>

<Expr op="and">

<ListSearch list-name="Site Details" search-columns="Site Code" result-columns="Location">

<Expr variable="_match_1"/>

</ListSearch>

<ConfigFileCheck op="contains-one">

<Expr op="concat"><Expr value="^snmp-server location .*"/>

<Expr variable="Location"/></Expr>

</ConfigFileCheck>

</Expr>

<Then><PolicyRulePass/></Then>

<Else><PolicyRuleFail>The incorrect location, or none at all, is

configured.</PolicyRuleFail>

</Else>

</If>

</Then>

<Else>

<!--

The device name did not match the correct format, so fail the rule.

-->

<PolicyRuleFail>The device name does not begin with a three-letter site code.

</PolicyRuleFail>

</Else>

</If>

</PolicyRuleLogic>

Configuration File Check Elements

Raw XML rules can use method calls running_config_text and saved_config_text to directly analyze configuration files. They may also use the same constructs used by the Simple Rule and CPD Rule editors (the <ConfigFileCheck> and <CPDCheck> elements, respectively).
<ConfigFileCheck> and <CPDCheck> elements also count as "expressions." They may be used anywhere an <Expr> element can be used. These elements can validate running configuration files and saved configuration files.

<ConfigFileCheck>

Contents of this element will be treated as one or more regular expressions, and validated against the configuration file. When a match is found, the variables "_message" and "_lineno" will be set, appropriate to the type of check being performed.
The ConfigFileCheck element supports the following attributes:

Configuration Policy Definition Checks (<CPDCheck>)

Statements encapsulated in the <CPDCheck> element are treated by the RAW XML Editor as a simple configuration policy definition (CPD).
Definition of CPDs is discussed further in the topic Using the CPD Editor .

Using Configuration Block Checks

Configuration block checks allow you to specify sections of configuration files to perform matches against. A basic ConfigBlockCheck XML object looks like the following:

<ConfigBlockCheck boundary-method="boundary-method" block-start="regular expression" method-specific attributes>
   <statements...>
</ConfigBlockCheck>

A configuration block always starts based upon a regular expression. Examples appear in the following subsections.
Configuration block checks also support four different boundary-method values, each of which provides a mechanism to determine the end of the block. Some methods are simpler than others and have specific limitations. Two additional options (end-on-block-start and end-on-eof) apply to all four methods.
Some additional attributes are used to work with configuration block check routines, including the following:

The four boundary-method types, which are used to determine the boundaries for a configuration block to check against, are described in the following subsections.

Boundary Type: Regular Expression (regexp) method

With this method, you specify another regular expression that is used to identify the end of the block, via the block-end attribute. An example of text from a configuration file:

line con 0
   exec-timeout 60 0

line vty 0 4
   access-class 155 in
   exec-timeout 15 0

  authorization commands 15 AUTHO

  accounting commands 15 ACCOU_TACACS

  logging synchronous
  login authentication AUTHE_TACACS

line vty 5 15
  access-class 155 in
  exec-timeout 15 0
   authorization commands 15 AUTHO

  accounting commands 15 ACCOU_TACACS

  logging synchronous
   login authentication AUTHE_TACACS
!

For example, you want to check each line vty block for correct authorization and accounting. For the rule's XML to work in this case, you use the end-on-block-start directive, which is set to True by default. This prevents the entire set of config file lines between the first line vty statement and the ending "!" from being seen as a single block. Using the indent method also is avoided because it will not work with the blank-un-indented lines between the exec-timeout and authorization commands in the example:

<PolicyRuleLogic editor='raw-xml'

xmlns='http://www.infoblox.com/NetworkAutomation/1.0/ScriptXml'>

   <Assign variable='pass-count'><Expr value='0'/></Assign>
   <Assign variable='fail-count'><Expr value='0'/></Assign>

<!-- end-on-block-start defaults to true, but we make it explicit here just for clarity.
-->
<ConfigBlockCheck block-end='^!$' block-start='^line vty' boundary-method='regexp' end-on-block-start='true'>
   <If>

   <!-- Note that there are no spaces or newlines between the ConfigFileCheck open and close tags and the element text. This is important since we do not want to look for those spaces/blank lines as part of the ConfigFileCheck. -->
   <ConfigFileCheck op='contains-all-ordered'>authorization commands 15 AUTHO accounting commands 15 ACCOU_TACACS
logging synchronous
login authentication AUTHE_TACACS</ConfigFileCheck>
   <Then>
    <Assign variable='pass-count'>
     <Expr op='+'>
      <Expr variable='pass-count'/>
      <Expr value='1'/>
     </Expr>
    </Assign>
   </Then>
  <Else>
   <Assign variable='fail-count'>
    <Expr op='+'>
     <Expr variable='fail-count'/>
     <Expr value='1'/>
    </Expr>
   </Assign>
  </Else>
 </If>
</ConfigBlockCheck>

<If>
  <Expr variable='fail-count'/>
    <Then><PolicyRuleFail/></Then>
   <Else><PolicyRulePass/></Else>
</If>

</PolicyRuleLogic>

Boundary Type: Indent method

With this straightforward method, a config block is considered ended when the indent level falls to the same indentation level as the starting line of the config block. By default, spaces and tabs are considered indent characters; you may change that by using the indent-chars attribute. An example of text from a configuration file:

...
vrf definition green

 rd 100:1
  route-target export 100:1
  route-target import 100:1
  !
  address-family ipv4 exit-address-family
!
vrf definition shared

 rd 66:1
 !
 address-family ipv4

 exit-address-family
!

The following ConfigCheckBlock statement results in the specified statements being executed once for each vrf-definition block:

<ConfigBlockCheck boundary-method="indent" block-start="^vrf definition">
  statements
</ConfigBlockCheck>

See a later subsection, Configuration Block Check Nesting , for another example using this same configuration.

Boundary Type: Balanced Delimiters method

This boundary method determines the block end when a balanced closing delimiter character is found (for example, "{" and "}"). You specify open-delim and close-delim attributes in the XML rule, along with the regular expression to specify the string match. A sample section from a configuration file:

interfaces {
    ge-0/0/0 {
        description "TO P-C3750 Router G0/5";

        vlan-tagging;
        unit 0 {
            vlan-id 120;

            family inet {
               address 54.10.30.1/29;
            }
        }
     }
     ge-0/0/1 {
        description "TO CE1-2 Router G0/1"; 

        unit 0 {
          family inet {
               address 88.125.40.1/30;
          }
        }
     }
     vlan {
        unit 0 {
          family inet {
              address 192.168.1.1/24;
          }
       }
    }

An associated ConfigBlockCheck could read as follows:

<ConfigBlockCheck boundary-method="balanced-delimiters" open-delim="{" close-delim="}" block-start="\s*ge-.*">
   statements
</ConfigBlockCheck>

The configuration block check executes against all instances for Gigabit Ethernet blocks ("\s*ge-.*").

Boundary Type: Line Count method

This boundary method simply specifies the number of lines that must be in the block. The result is a configuration block ending by finding the correct number of lines, and not from the start of the next block or an EOF. A line_count variable contains the value for the number of lines in the resulting block. Though the line count method may not be commonly used to break a config file into blocks, one possible use is to iterate through individual lines matching an expression, setting the appropriate block-start and using a line-count of 1. A sample section from a configuration file:

interface fc2/1

interface fc2/4

interface fc2/5

interface fc2/6
logging server 172.23.27.156
logging server 10.120.25.197
logging server 172.23.27.146

no logging monitor

The following will cause the statements to be executed once per "logging server" line:

<ConfigBlockCheck boundary-method="line-count" block-start="^logging server" line-count="1">
  statements
</ConfigBlockCheck>

Configuration Block Check Nesting

Configuration block checks support nesting. The ConfigBlockCheck has children statements, which include the possibility of other ConfigBlockCheck elements. Looking at the previous example of configuration text for the indent boundary method (see Boundary Type: Indent method), you can extend the example to process the "address-family" blocks within each VRF:

<ConfigBlockCheck boundary-method="indent" block-start="^vrf definition">

 <!-- Figure out which RD this is -->

 <Expr op="matches"><Expr variable="_block"/><Expr value="^\s*rd (.*)"/></Expr>

 <Assign variable="rd"><Expr variable="_match_1"/></Assign>

 <!--Here is the nested block check --!>

  <ConfigBlockCheck boundary-method="regexp" block-start="^\s*address-family

  (ipv[46])" block-end="^\s*exit-address-family">

  <!-- statements that may do something (say, a list lookup), based on RD and address

  family IP version -->

  </ConfigBlockCheck>

 <!-- note that the _block variable is scoped - so at this point it is back to the "vrf

 definition" block, even though within the ConfigBlockCheck statement above, _block

 referred to the address-family block -->

</ConfigBlockCheck>

Using the Expression <Expr> Element

You use an <Expr> element to define expressions when performing logical tests or assignments. If you use no attribute for the <Expr> element, the text string contents of the element are used as the value. Thus, the two following expressions are equivalent:

<Expr value="foo"/>
<Expr>foo</Expr>

An <Expr> element may contain other expressions, and may represent its value as a constant, field lookup, or another operation. If no attributes are defined, the <Expr> contents (the element text) will be used as a String. An example appears in the section Expression Attributes and Matching.
The <Expr> tag may have the following attributes.

Expression Attributes and Matching

Two types of Raw XML Editor elements may have an "Expression" attribute:

• PolicyRuleLogic
• SetFilter

An expression attribute is a shorthand method of creating complex Boolean expressions based upon other elements. An expression attribute may consist of integers, parentheses, 'and', 'or', 'if', 'then', and 'else'. The numbers should refer to direct child elements, that in turn must include label attributes matching the numbers. For example, the following <PolicyRuleLogic> element shows three child elements 1, 2 and 3:

<PolicyRuleLogic expression='(1 and 2) or 3'>
   <Expr label='1' field='RoutingInd'/>
   <Expr label='2' field='SwitchingInd'/>
   <Expr label='3' op='='>
    <Expr field='DeviceType'/>
    <Expr value='Switch-Router'/>
   </Expr>
</PolicyRuleLogic>

will pass any Device that has either both its RoutingInd AND SwitchingInd set to true (note the logical AND), or has a DeviceType of 'Switch-Router'. For <PolicyRuleLogic> elements, any device matching the criteria passes the rule, and devices that do not match it will fail the rule.

Variables Usage

In the Raw XML Editor, use the <Assign variable> element to define and set variables. This statement defines a new variable, if it is not already defined, and assigns the value, in the first child expression, to the variable. The primary supported attribute is 'variable' which names the variable to be assigned the value. Examples:

<PolicyRuleLogic editor='raw-xml'>
<Assign variable='access-list'><Expr variable='_match_1'/></Assign>
<Assign variable='access-class'><Expr op='concat'><Expr value='access-list '/><Expr variable='access-list'/></Expr></Assign>
...

You may define variables with a local scope. In the Assign element, specifying scope of parent sets the scoped variable to the parent of the Assign. This means all descendants of that element will read that variable instead of variables of the same name, that are defined at a higher scope. You may explicitly set a global variable with a scope of root. By default, (without a specified scope, or the scope specified to resolve), an assignment moves up the XML tree and sets the first variable it finds that has the specified name, creating one at the root level if none is found.

Note: When using the output attribute on elements, the scope is always equivalent to resolve.

Match Variable Arrays

To complement existing _match_* variables that are set for regular expression matches, an array _match_array is set that contains the values of numbered match variables. This enables more dynamic scripting.

Flow Control with If-Then-Else

You use <If> elements to make logical branching decisions. It must have an <Expr> element for the conditional, followed by a <Then> element (which is statement block), and optionally by an arbitrary number of <ElseIf> statements and an <Else> statement.

<If>
   <Expr op='=='>
     <Expr field='parent_device.DeviceModel'/>
     <Expr value='N7Kc7010'/>
     </Expr>
  <Then><PolicyRulePass/></Then>
  <Else><PolicyRuleFail/></Else>
</If>

In this example, the <Then> and <Else> elements are simple statement blocks, with no supported attributes. ElseIf elements should have an <Expr> for the conditional, followed by a <Then> statement block.

Objects Usage

As described, each statement results in a value. The object type affects the results of various operations. For example, dividing an integer by another integer always results in an integer, whereas dividing a floating-point number by an integer will result in a floating-point number.
Some statements operate on the current object, including <PolicyRuleLogic>, <SetFilter>, <Expr> with a field attribute, <Expr> with in-group, not-in-group, and defined operators, and all the Config Check elements. In the case of the <PolicyRuleLogic>, the "current object" is the device against which the policy rule is evaluated.
Object fields and methods are described in the API documentation, which may be found in the user interface in Tools  –> Network –> API Documentation. The current object at the time of policy rule evaluation will always be an InfraDevice. In the API documentation, go to the API List link, scroll down to the Device section, and click Infrastructure Devices. On the page that results, click the InfraDevice link under Model.
It is possible to change the current object for a statement, by setting the 'object' attribute to the name of a variable containing the new current object. This will apply only for that element. For example, this checks if the parent_device of the current device is a Nexus 7k:

<PolicyRuleLogic editor='raw-xml'>
   <Assign variable='parent'><Expr method='parent_device'/></Assign>
   <If>
     <Expr op='=='>
      <Expr object='parent' field='DeviceModel'/>
      <Expr value='N7Kc7010'/>
     </Expr>
     <Then><PolicyRulePass/></Then>
     <Else><PolicyRuleFail/></Else>
   </If>
</PolicyRuleLogic>

You can also chain the names into the field attribute without declaring the variable first, using a period as the separator:

<PolicyRuleLogic editor='raw-xml'>
   <If>
     <Expr op='=='>
      <Expr field='parent_device.DeviceModel'/>
      <Expr value='N7Kc7010'/>
     </Expr>
     <Then><PolicyRulePass/></Then>
     <Else><PolicyRuleFail/></Else>
   </If>
</PolicyRuleLogic>

In this case, each component in the change can be either a method call that takes no arguments, or a field.

<Return> Elements

A <Return> element is a statement block, and will stop execution of the policy rule, returning the value of the statement block as the value of the policy rule. In a policy rule, the <Return> should evaluate to a <PolicyRulePass> or <PolicyRuleFail> (see the section Pass/Fail Messages below).

<Return>
    <PolicyRulePass><Expr op='concat'><Expr value='VTY access-class '/><Expr variable='access-list'/><Expr value=' is set and defined'/></Expr></PolicyRulePass>
</Return>

<StatementBlock> Elements

This element simply allows grouping of related statements.

Pass/Fail Messages

Policy rules must result in a <PolicyRulePass> or <PolicyRuleFail>, or the policy rule will evaluate as 'invalid'. When using <PolicyRulePass> or <PolicyRuleFail>, you may send a custom message indicating the reason for passing or failing. A static message can be included by simply making it the text of the element:

<PolicyRulePass>This is the pass message.</PolicyRulePass>

You may also put expressions as child elements, enabling dynamic messages:

<PolicyRulePass>
   <Expr op='concat'>
     <Expr value='VTY access-class '/>
     <Expr variable='access-list'/>
     <Expr value=' is set and defined'/>
   </Expr>
</PolicyRulePass>

Long-Form Example

<PolicyRuleLogic editor='raw-xml'>

<Assign variable='device-config'><Expr method='running_config_text'/></Assign>

<If>

<Expr op='matches'>

<Expr variable='device-config'/>

<Expr value='/^line vty \d+ \d+\n(?:\s[^\n]+\n)*(?:\saccess-class (\S+) in\n)/m'/>

</Expr>

<Then>

<Assign variable='access-list'><Expr variable='_match_1'/></Assign>

<Assign variable='access-class'><Expr op='concat'><Expr value='access-list '/><Expr variable='access-list'/></Expr></Assign>

<If>

<Expr op='matches'>

<Expr variable='device-config'/>

<Expr variable='access-class'/>

</Expr>

<Then>

<Return>

<PolicyRulePass><Expr op='concat'><Expr value='VTY access-class '/><Expr variable='access-list'/><Expr value=' is set and defined'/></Expr></PolicyRulePass>

</Return>

</Then>

<Else>

<Return>

<PolicyRuleFail><Expr op='concat'><Expr value='VTY access-class '/><Expr variable='access-list'/><Expr value=' is set but access-list is NOT defined'/></Expr></PolicyRuleFail>

</Return>

</Else>

</If>

</Then>

<Else>

<Return>

</Return>

</Else>

</If>

</PolicyRuleLogic>

Regular Expressions in Policy Rules

NetMRI uses Ruby-style regular expressions, which are similar to perl regular expressions. When entering a regular expression in the Raw XML Editor, the Simple Rule Editor, or the Rule Logic Builder, starting the line with "/" allows you to use the "i" or "m" options for regular expressions. For example,

^banner motd my banner

will fail to match "banner motd MYBANNER" in the configuration file. For a case-sensitive match, enter instead

/^banner motd my banner/i

Config File Matches

For the most part, config file matches look almost exactly like configuration commands, with the possible use of wildcards and regular expressions instead of hard-coded arguments. For example, the following config file match specifies an exact match that requires a specific ACL command to be included in the configuration file:

access-list 10 permit 10.76.4.11

This is the simplest and most common type of config file match, which is typically the result of a cut-and-paste from a correct configuration file.

Note: Config file matches are written using the actual syntax defined for the configuration file for a given type of device and software version. In some cases, the syntax is the same across multiple device types or software versions, but in other cases different syntax is required. The device filter defined for a rule determines which types of devices can be analyzed using that rule.

To allow a given config file match to match multiple configuration lines, rule authors can include regular expressions for one or more of the command arguments. For example, the following wildcard config file match:

access-list 10 permit 10.76.4.[0-9]+

indicates that an ACL entry must exist for any host in the 10.76.4.0 subnet, instead of just the host at 10.76.4.11 as in the previous example.

The regular expression shown above matches more than just “10.76.4.x” because the “.” is a special symbol that matches any single character. In practice, this expression will still match what you want it to match because only dotted decimal notation will appear in this rule.

Multiple Wildcard Terms

Each of the arguments (or tokens) defined in a given config file match can be either a fixed value (e.g., “10”) or a wildcard term (e.g., “[0-9]+”) to match multiple values. By combining multiple wildcard terms in the same config file match, very powerful (and sometimes complex) expressions can be specified. For example, consider the following config file match:

snmp-server communit.* [Pp]ublic (RO|RW)

This config file match would match any top-level command where the first token matches the fixed value snmp-server, the second token matches the wildcard term communit.*, the third token matches the wildcard term [Pp]ublic, and the fourth token matches the wildcard term (RO|RW). In other words, it matches any command that defines the read-only or read-write community to be “Public” or “public”.

Note: Although not strictly forbidden, it is generally prudent to use fixed values for the first token in every config file match to avoid unexpected results when a wildcard term matches a rule you didn’t expect it to match.

Multi-Line Config File Matches

Note: Information in this topic applies only to rules created in the CPD Editor (see Using the CPD Editor).

Many configuration commands can span multiple lines in a configuration file, where each indentation level indicates a different sub-command specification. Similarly, config file matches can be specified as a collection of one or more sub-matches that are applied to the corresponding sub-commands.

For example, the following multi-line config file match:

[Config File Must Contain]

interface Ethernet0\/0

description.*

indicates than an interface command must exist for the Ethernet0/0 interface and that a description must be defined for that interface. Because the description sub-match only specifies the first part of the sub-command, any description will match the sub-match, as long as one has been defined. That is, the rule author doesn’t care exactly what description is defined, only that some description is defined for that device.

As with single-line config file match, you may want to include a wildcard expression as part of the top-level match or sub-matches so that the config file match can be used across a range of commands. In such cases, the multi-line config file match is applied to any configuration command that matches the top-level config file match.

or example, the following multi-line config file match:

[Config File Must Contain]

interface Ethernet.*

description.*

indicates that all interface commands associated with any Ethernet interface must have an interface description defined, whereas the following multi-line config file match:

[Config File Must Contain]

interface.*

description.*

indicates that every interface, regardless of type, must have a defined interface description.

Creating and Managing Rules

You use the Rules tab (Config Management –> Policy Design Center –> Rules tab) to create and manage rules that are referenced in policies. Policies cannot operate without at least one Rule. All factory-defined rules in this page are read-only. You can also define your own custom rules, using your choice of editing tools.
Rules provide substantial extensions in capabilities for XML rule creation. For more information, see the following subsection, Policy Rule XML Capabilities.
Rule editing features are enabled only when creating a new rule. All other Rules are read-only and can be used only to create new Rules.
Rules are the critical element in building all Policies. To build Rules effectively, Infoblox recommends detailed knowledge of the given networking technologies or protocols involved in defining the rule.
Also see Additional Rule Examples for information showing how rules appear in practice.

Note: For a selected rule, check Used in these policies at the bottom of the center panel to see which policies reference the rule.

Creating New Rules

To create a new rule, you choose a severity level for the rule, define any remediation instructions as descriptive text for the rule, and select an editor type. Do the following:

1. In the Rules tab, click Add in the upper left corner. The Add Rule dialog appears.
2. In the Add Rule dialog, enter the Short Name, Name and Author.
3. Select a Severity.
4. Enter a Description.
5. (Optional) Enter Remediation instructions.
6. Click Save.
   The new Rule appears in the left pane of the Rules page, and defaults to the Simple Rule editor.
7. Select a rule editor in the upper right corner: see the respective topics for Using the Simple Rule Editor , Using the CPD Editor , Using the Rule Logic Builder or Using the Raw XML Editor for more information.
8. Enter the config file matches using the selected editor.
9. Click Save in the lower right corner.
10. Test or validate the new rule (for more information, see Testing Policy Rules ).

Filtering for Rules

A rule should not operate on all possible objects, or the rule would never finish executing in a policy or would yield results that don't match the intent of the rule. You use filters to ensure the following:

• Ensure that a policy rule applies only to particular devices that you want the rule to match against;
• Ensure matches against characteristics such as Rank, Assurance level, device model and numerous other criteria.

To specify a filter for a rule, do the following:

Note: Configure rule and policy filters carefully. It is possible to inadvertently specify mutually exclusive filters such that a policy would not apply to any configuration file.

1. In the Rules panel, select the rule.
2. Click the Add device filter hyperlink. The Edit Filters dialog appears.
   To add a config file match filter:
3. Click Add Device Attribute. The Edit Device Attribute dialog appears.
4. (Optional) Enter a Note describing the filter element.
5. Select a device filtering characteristic from the first dropdown (e.g. Assurance, Community, DNS Name, Model, Name or other characteristic (see Adding Device Attributes to a Rule Filter below).
6. Select an operator from the list (e.g., =, =>, in, Contains, Does Not Contain or any other operator).
7. Enter or paste in the text for the configuration file line(s) or the value to match against.
8. If you want to use more than one filtering criterion, click Apply and New.
9. Click OK when the new filter is complete.

When you create new rules, you can also add filters to them. After doing so, they are listed under the Device Filter for Rule section in the center pane. You can do so for any rule, whether it is a new one or a read-only rule bundled with the appliance.
You can also choose a Config File Match for the rule filter. However, while the filter can check for a line or a series of lines in the config file (using Must Contain... or May Not Contain... statements for the matching), the match of this type is used only to determine whether the rule will apply to a given device.

Adding Device Attributes to a Rule Filter

A device attribute is any characteristic of a discovered device that is readable by NetMRI. You can select attributes for addition to a filter through the Rule Logic Builder. Attributes that can be used for rules filtering include the following:

Testing Policy Rules

Rules created in the Raw XML Editor can be validated through the XML schema by simply clicking the Validate button. To test any non-XML rule, do the following:

1. In the Rules panel, select the rule to be tested.
2. Click the Test Rule button in the lower right corner. The Test Rule dialog appears.
3. In the Test Rule dialog, specify what you want to test against:
   1. Click the Test Against Existing Device tab.
   2. Select a Device Group that contains the device of interest.
   3. Select the specific device by clicking on its table row. Note that the IP Address and Network View columns provide links to their respective viewer windows.
      To test against device attributes and/or a configuration file, do the following:
   4. Click the Test Against Attributes/Config File tab.
   5. Enter device attributes (if available) and/or click Browse... to select a configuration file.

Click Test. Results appear in the pop-up Test Results window. (You can click the Debug button to watch rule execution. For more information, see Debugging Rules.)

To import a rule, do the following:

1. Click Import in the upper left corner. The Import Rule dialog appears.
2. Click the Browse... button, then locate and select the file.
3. Click the Import button.

To export a rule, do the following:

1. In the Rules panel, select the rule to be exported.
2. Click Export in the upper left corner
3. Take the appropriate action in the resulting dialog.

To copy a rule, do the following:

1. Click Copy in the upper left corner. The Copy Rule dialog appears.
2. Enter the Short Name, Name and Author.
3. Select a Severity.
4. Edit the Description as needed.
5. Edit the Remediation as needed.
6. Click Save.

To delete a rule, do the following:

1. In the Rules panel, select the rule to be deleted.
2. Click Delete in the upper left corner.
3. Confirm the deletion.

Debugging Rules

When testing a rule, you may now enable debug mode by clicking the Debug button. This produces output that identifies each element, is executed by the system, and shows the return value from that element.
For example, consider the following block of code:

<Expr op='concat'>
  <Expr value='First'/>
  <Expr value='Second'/>
</Expr>

When evaluated in debug mode, it would result in the following output:

<Expr op='concat'>
  <Expr value='First'>
  </Expr> result value <First>
  <Expr value='Second'>
  </Expr> result value <Second>
</Expr> result value <FirstSecond>

Creating and Managing Policies

Build and test policies in the Policies tab (Config Management tab –> Policy Design Center side tab –> Policies tab).

Note: Configure rule and policy filters carefully. It is possible to inadvertently specify mutually exclusive filters so that a policy will not apply to any configuration file.

A policy consists of the following:

• Properties: name, short name, author's name and description.
• Rule(s): one or more rules selected from those available in the Rules tab.
• Device filter: limiting the policy to devices with attributes and/or config files containing certain commands.

Creating Policies

To create a policy, do the following:

1. Click Add in the upper left corner. The Add Policy dialog appears.
2. Enter a Policy Name, Short Name, Author and Description.
3. Click Save.

To add one or more rules to a policy, do the following:

1. In the Policies panel, select the policy.
2. Click the Edit button in the lower right corner. The Select Rules dialog appears.
3. In the Select Rules dialog:
   1. Check the rules you want to include in the policy. Hover over a rule's name to see its full name, description and device filter.
4. Click Save.

To specify a filter for a policy, do the following:

1. In the Policies panel, select the policy.
2. Click the Add a filter hyperlink. The Edit Filters dialog appears.
3. To add a configuration file match filter:
4. Click the Add Config File Match button. The Edit File Match dialog appears.
5. (Optional) Enter a Note describing the filter element.
6. Select an operator (e.g., Must Contain ALL of These Lines in Any Order).
7. Enter the configuration file line(s).
8. Click OK.
9. To add a device attribute filter:
10. Click the Add Device Attribute button. The Edit Device Attribute dialog appears.
11. (Optional) Enter a Note describing the filter element.
12. Select an attribute (left dropdown list).
13. Select an operator (center dropdown list).
14. Enter a value (right field).
15. Click OK.
16. If you create two or more filter elements, you can modify the logic used to apply them in the Enforce This Rule field. Click the icon to the right of the field for details.
17. Click Save.

Testing and Importing Policies

Policies can be tested against devices within device groups, against device attributes and against a configuration file, and tested against a template. New policies can also be written in XML format and then imported into the NetMRI Policy system.

To test a policy, do the following:

1. In the Policies panel, select the policy to be tested.
2. Click Test Policy in the lower right corner. The Test Policy dialog appears.
3. In the Test Policy dialog, select a corresponding tab to specify what you want to test against. See the following procedures for each test tab.
4. Click Test. Results appear in the pop-up Test Results window.

To test against a device group:

1. Click the Test Against Existing Device tab.
2. Select a Device Group that contains the device of interest.
3. Select the specific device.

To test against device attributes and/or a configuration file:

1. Click the Test Against Attributes/Config File tab.
2. Enter device attributes (if available) and/or click Browse... to select a configuration file.

To test against a template:

1. Click the Test Against Template tab.
2. Select the template you want to test against.

Importing and Exporting Policies

You can import policy XML files (as generated by exporting a policy) or legacy NetMRI CPD files. The latter is automatically converted to the newer format.

To import a Policy file, do the following:

1. Click Import in the upper left corner.
2. In the Import Policy dialog, click Browse..., then locate and select the file.
3. Click Import.

To export a policy:

1. In the Policies panel, select the policy to export.
2. Click Export in the upper left corner.
3. Take the appropriate action in the resulting dialog.

To copy a policy:

1. Click Copy in the upper left corner. The Copy Policy dialog appears.
2. Enter a Policy Name, Short Name and Author.
3. Edit the Description as needed.
4. Click Save.

To delete a policy:

1. In the Policies panel, select the policy you want to delete.
2. Click Delete in the upper left corner.
3. Confirm the deletion.

To print a policy:

1. In the Policies panel, select the policy you want to print.
2. Click Print in the upper left corner.
3. In the Print dialog, specify print parameters, then click the Print button.

Deploying Policies

Deploy policies in the Policy Deployment tab (Config Management –> Policy Design Center side tab –> Policy Deployment tab). In this tab, you associate policies with device groups (or vice versa). Policy deployments remain in effect until they are deactivated.

To specify a policy and deploy it against selected device groups:

1. Click the By Policy tab at the bottom left of the page.
2. In the Policies panel, select the policy you want to deploy.
3. In the main table, select the device group(s) you want to run the policy against.
4. Click the Save button in the lower right corner.

To specify a device group and deploy selected policies against it:

1. Click the By Device Groups tab at the bottom left of the page.
2. In the Select Device Groups panel, select the device group.
3. In the main table, select the policy or policies you want to deploy for the device group.
4. Click Save.

Note: To view policy details, click the plus sign at the left end of a policy row.

PCI 3.0 Rule Testing

NetMRI policies support the Payment Card Industry (PCI) 3.0 standard. The defined policies for PCI, including PCI 3.0, consist of the following:

• PCI DSS 1.2 IOS
• PCI DSS 2.0 IOS
• PCI 3.0 IOS/NX-OS

The PCI 3.0 policies support Cisco IOS and Cisco NX-OS devices. For policy execution, devices must be configured to conform to PCI 3.0 standards. NetMRI can use PCI 3.0 policies to test for the following:

• Minimum password length: enforced to be at least 7 characters long.
• Password strength: Password should contain numeric and alphabetic characters or password strength validation should be enabled
• Disabled Small TCP and Small UDP services
• Disabled Finger, BOOTP, and Identd services on Cisco IOS devices
• Disabled CDP, HTTP, NTP on Cisco IOS and Cisco Nexus devices
• Exec-timeout on console port and on VTY port should be set to 15 minutes or less on IOS and Nexus
• Enable login on console port;
• Allow Enable passwords on console port;
• Two factor authorization is activated;
• Enable Logging timestamp;
• Disable MOP on all Ethernet interfaces;
• Disable Packet assembler/disassembler (PAD) on X.25 links on IOS.
• Disable configuration autoloading for IOS devices;
• Disable source routing on IOS and Nexus;
• Inbound access class should be set on VTY ports;
• SSH only transport should be set on VTY ports for IOS;
• AAA authentication should be enabled for VTY ports on IOS;
• Secrets should be used for local users on IOS and Nexus;
• SNMP v1 and v2c should be disabled on IOS and Nexus.

Additional Rule Examples

With some practice, rules can be written by anyone experienced with the underlying configuration files being analyzed. This topic presents several examples of relatively simple, yet effective rules that ensure consistency and correctness across a range of devices.

Note: Rule examples are presented using the CPD Editor format (see Using the CPD Editor ).

The following example demonstrates how to ensure that all network engineers can access a given network device.

Rule: Access List Configuration

Description: These commands specify the hosts that are allowed to access the router’s management interface.

[Config File Must Contain]

access-list 10 permit 10.76.4.[0-9]+

access-list 10 permit 10.48.3.\d+

access-list 10 permit 10.76.15.45

access-list 101 permit ip 10.98.34.0.* any

[Config File Must Contain]

access-list.*

Rule: SNMP Community Configuration

If you are making sure that people can access the systems, do not forget about the management software.

Description: Ensures that all SNMP communities are set to the proper setting.

[Config File Must Contain]

snmp-server community r3adc5 RO

snmp-server community wr1t3c5 RW

[Config File May Not Contain]

snmp-server community.*

Rule: Banner Configuration

The following example shows how to consistently display a proper login banner on all network devices covered by this rule:

Description: Every system is supposed to display the following banner.

[Config File Must Contain]

banner motd ^C

ALL UNAUTHORIZED ACCESS TO THIS SYSTEM WILL BE

PROSECUTED TO THE MAXIMUM EXTENT ALLOWED BY

U.S. FEDERAL AND MARYLAND STATE LAW.

^C

Rule: Clock Synchronization

Clock synchronization problems can cause confusion when troubleshooting problems across the network. This rule detects when a network device is not pointing at the proper NTP servers.

Description: Time is money... treat it accordingly.

[Config File Must Contain]

ntp server 192.168.72.2

[Optional]

ntp server 192.168.72.[3-5]

[Config File May Not Contain]

ntp server.*

Rule: Interface Descriptions

Use the following rule to ensure that every interface has some sort of description defined for it. In this example, we also require the description for all ATM interfaces to include the circuit ID and the provider.

Description: All interfaces should have a description of some sort and ATM interfaces should include the Circuit ID and provider.

[Config File Must Contain]

interface.*

description.*

interface ATM.*

description (ATT|MCI|SBC)-[0-9][0-9][0-9]

Rule: Integrated Access Control

You are free to organize rules as you see fit. The following example combines the access related rules from above into a single rule:

Description: Ensures that only authorized individual and hosts can access our network devices.

[Config File Must Contain]

access-list 10 permit 10.76.4.[0-9]+

access-list 10 permit 10.48.3.[0-9]+

access-list 11 permit 10.76.15.45

access-list 101 permit ip 10.98.34.0.* any

snmp-server community r3adc5 RO 10

snmp-server community wr1t3c5 RW 11

banner motd ^C

ALL UNAUTHORIZED ACCESS TO THIS SYSTEM WILL BE

PROSECUTED TO THE MAXIMUM EXTENT ALLOWED BY

U.S. FEDERAL AND MARYLAND STATE LAW.

^C

[Config File May Not Contain]

access-list.*

snmp-server community.*

Some variables, specifically the $Model and $IPAddress values, cannot be used for building Rules with device attributes:

$Model in ["cat4506", "3725"]

$IPAddress in [10.1.3.56, 10.2.0.0/16]

For Rules in the Policy Design Center, simply use a comma-separated format.

Using the Rule Logic Builder

The Rule Logic Builder provides an environment for creating rules by combining config file matches with logic to produce a result when the rule executes. Rule Logic consists of two primary building blocks:

• Config File Match: a defined section of configuration file text of one or more lines, used during parsing of device configuration files to perform matching. Matching may be positive ('Must Contain') or negative ('May Not Contain');
• Device Attributes: these consist of three smaller elements, including device attributes (see Adding Device Attributes to a Rule Filter for a list of attributes), mathematical and logical operators, and a value to match against.

At the top of the Rule Logic Builder panel, you see an Enforce This Rule field. Here, you use Boolean AND and OR operators to enforce the logic trail employed by the rule. For example, consider a rule that has three elements: two Config File Matches and a device attribute as the third element.

You enter Config File Matches and Device Attributes one at a time, in any order, in the logic builder. You cannot rearrange them after they are added to the block list; each block provides an Action menu through which you edit or delete each block.

To create a new rule using the Rule Logic Builder:

1. Select the rule in the Rules panel.
2. Select Rule Logic Builder in the Editor list in the upper right corner. (This list is inactive if you are editing an existing rule.)
3. To add a config file match for a configuration command:
4. Click Add Config File Match.
5. (Optional) In the Edit File Match dialog, enter a Note describing the config file match.
6. Open the list and select a must contain/may not contain option:
   • ALL of These Lines in Any Order
   • ALL of These Lines in Specified Order
   • AT LEAST ONE of These Lines
   • This BLOCK
   • This BLOCK Only Once
   • ONLY ONE of These Lines
7. In the text field, type or paste in the config file match line or block (see references below for additional information).
8. Click OK.
9. To add a device attribute check, click the Add Device Attribute button.
   1. Choose a device attribute from the left dropdown list (see Adding Device Attributes to a Rule Filter for a list of choices).
   2. Select an operator from the center dropdown list.
   3. Enter a value in the right field.
   4. Click OK or select Apply and New.
10. Click Add Config File Match or Add Device Attribute to add a new element to the block list.
11. Click the Save button at the bottom of the page.

By default, config file matches are combined with logical ANDs; editing the Enforce This Rule field allows for Boolean ORs, NOTs and If-Then-Else logic. Hover the mouse over the Info icon to the right of the field for details.

• To view config file match details, click the (+) icon at the left end of the row.
• To edit a config file match: hover the mouse over the Action icon for the element and choose Edit.
• To delete a config file match: hover the mouse over the Action icon for the element and choose Delete.

Note: When creating a rule to evaluate a block of config in a specified order, note that the “all of these lines in specified order” logic implies that each line is present and in that order, and there can be other lines in between. In this case the rule passes. If you do not want to allow other lines in between, use the “Contains This BLOCK” option. Also, in both the “Config File Must Contain” and “Config File May Not Contain” sections, each entered line is considered a regular expression to be matched against the configuration file. If you select one of the BLOCK options, the entire content of the field is considered a regular expression.

Using the Simple Rule Editor

As its name implies, the Simple Rule Editor provides an easy way to create and edit rules. It establishes a structure in which you can easily add config file matches corresponding to specific configuration commands.

In the Simple Rule Editor, a rule may consist of one or both of the following sections:

• Config File Must Contain section lists config file matches that must be matched in some combination specified in the associated dropdown list (e.g., ALL of These Lines in Any Order or This BLOCK Only Once). You type in or paste in the sequence of configuration file directives to be matched against.
• Config File May Not Contain section lists config file matches that should not be matched as specified in the associated dropdown list (Any of These Lines or This BLOCK).

To add config file matches to a rule using the Simple Editor:

1. Select the rule in the Rules panel.
2. Select Simple in the Editor list in the upper right corner. (This list is inactive if you are editing an existing rule.)
3. Then, specify required config file matches:
4. Open the Config File Must Contain list at the top of the upper panel, then select one of the following options:
   • ALL of These Lines in Any Order
   • ALL of These Lines in Specified Order
   • AT LEAST ONE of These Lines
   • This BLOCK
   • This BLOCK Only Once
   • ONLY ONE of These Lines
5. Type or paste the config file line(s) or block(s) in the large field in the upper panel. To specify invalid config file matches:
6. Open the Config File May Not Contain list at the top of the lower panel, then select one of these options:
   • Any of These Lines
   • This BLOCK
7. Type or paste the config file line(s) or block(s) in the large field in the lower panel. (See references below for additional information.)
   In both the Config File Must Contain and Config File May Not Contain sections, each entered line is considered a regular expression to be matched against the configuration file. If you select one of the BLOCK options, the entire contents of the field are considered a regular expression.
8. Click the Save button at the bottom of the page.

Note: You can move the bar between the Must Contain and May Not Contain panels to adjust the space available in each panel.

Note: When creating a rule to evaluate a block of config in a specified order, note that the “all of these lines in specified order” logic implies that each line is present and in that order, and there can be other lines in between. In this case the rule passes. If you do not want to allow other lines in between, use the “Contains This BLOCK” option. Also, in both the “Config File Must Contain” and “Config File May Not Contain” sections, each entered line is considered a regular expression to be matched against the configuration file. If you select one of the BLOCK options, the entire content of the field is considered a regular expression.

Using the CPD Editor

Note: Infoblox recommends using alternative editing methods for creating new policy rules. The CPD editor is provided for compatibility with older releases of NetMRI.

The CPD Editor provides a legacy rule format using a more free-form rule development environment than the Simple Rule Editor. You use several simple text headers to create sections for the rule to match against; these headers also express the basic logic for the rule. Possible section headers include the following:

• Required: a single line directive for a configuration.
• Required Block: a block of one or more lines of configuration text.
• Optional: An optional single line of configuration text for a follow-on match, if necessary.
• Optional Block: An optional block of configuration text for a follow-on match, if necessary.
• Invalid: a single line directive for a configuration, which if found is considered invalid.
• Invalid Block: a block of one or more lines of configuration text which if found is considered invalid.

In the CPD Editor, a rule can include any or all of the following sections:

Required:
Config file match 1

Required Block:

Config file match 2

Config file match 3

Optional:
Config file match 4
Optional Block:

Config file match 5

Config file match 6

Invalid:
Config file match 7

Invalid Block:

Config file match 8

Config file match 9

General syntax. Although config file matches generally occupy a single line, for formatting purposes they can span multiple lines in the CPD Editor.
Comments. In rules developed in the CPD Editor, any line in which the first non-whitespace character is a "#" is always considered a comment line. For example,

# This is a comment line

denotes a comment that is ignored when processing the file.

Note: As with any definition file, proper use of blank lines, indentation and comments can significantly improve rule readability.

To add config file matches to a rule using the CPD Editor:

1. Select the rule in the Rules panel.
2. Select CPD in the Editor list in the upper right corner. (This list is inactive if editing an existing rule.)
3. Type or paste the config file match line(s) and/or block(s) you want to include in the rule. (See references below for additional information.)
4. Click Save at the bottom of the page.

The CPD Editor supports three types of block config file matches:

• Required block. For a required block to be satisfied, the configuration file must have one block of lines matching its requirements.
• Optional block. Optional blocks are used to prevent a required block from matching commands that may or may not be defined in the configuration file.
• Invalid block. Invalid blocks are identified as many times as the invalid block is matched in the configuration file.

Required blocks are processed at the same time as required config file matches, followed by all optional blocks and optional config file matches, and finally all invalid block rules and invalid config file matches. Normally, config file matches are written in the order they are processed to avoid confusion, Organization is entirely up to the CPD author. One block of config file matches can be specified per block.

This is a valid example:

Required Block:

Config file match 1 of Block 1

Config file match 2 of Block 1

Config file match 3 of Block 1

Required:

Config file match 1

Config file match 2

Config file match 3

Required Block:

Config file match 1 of Block 2

Config file match 2 of Block 2

Config file match 3 of Block 2

This is an invalid example:

Required Block:

Config file match 1 of Block 1

Config file match 2 of Block 1

Config file match 3 of Block 1

Config file match 1 of Block 2

Config file match 2 of Block 2

Config file match 3 of Block 2

Required:

Config file match 1

Config file match 2

Config file match 3

Rule blocks support indentation similar to what is described in Multi-Line Config File Matches.

Because a required block is satisfied by finding just one match in a configuration file, it is best to use the required block with the invalid block. This action takes advantage of the fact that the required blocks are processed first and any consecutive configuration lines that do not match the required blocks are then matched with the invalid block. Below is an example that uses this method.

Required Block:

interface [F|G].*

description T.*

switchport trunk encapsulation dot1q

switchport trunk native vlan 999

switchport mode trunk

Required Block:

interface [F|G].*

description M.*

switchport access vlan.*

switchport mode access

no logging event link-status

no mdix auto

spanning-tree portfast

Optional:

interface [F|G].*

switchport.*

shutdown

Invalid Block:

interface [F|G].*

.*