Page Comparison

...

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.

...

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

Policy analysis results are also available in two reports:

...

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.

...

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.

...

• 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.

...

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:

...

• 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:

...

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:

...

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 .

Anchor
Using Configuration Block Checks Using Configuration Block Checks

Anchor
bookmark672 bookmark672

Using Configuration Block Checks

...

<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.

...

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:

...

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.

...

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:

...

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>

...

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.

...

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.

...

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 ).

Anchor
Filtering for Rules Filtering for Rules

Anchor
bookmark694 bookmark694

Filtering for Rules

...

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.

...

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.
4. 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:

...

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.

...

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.

...

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.

...

• 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.

...

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.

...

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.

...