...
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. |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
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.
...
Developing Policies is straightforward. In the Config Management –> > Policy Design Center tab, you can take the following broad steps to create and use Policies:
- In the Rules tab, create rules and assign device filters. You can also test rules in this tab.
- In the Policies tab, create the policy by selecting rules and assigning device filters. You can also test the policy in this tab.
- In the Policy Deployment tab, choose the device groups to run the policy against.
- 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. |
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.
...
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:
...
Note the use of subordinate elements <if>-<then>-<else>
and <Expr op>
.
Note | ||
---|---|---|
|
...
Several elements are defined as expression types, including |
Note | ||
---|---|---|
|
...
If a global |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
- 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 | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
<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.
<Expr> Attribute | Description | |||||||
---|---|---|---|---|---|---|---|---|
| Used for shorthand boolean expressions, has always been available for
| |||||||
| Explicitly sets the return type of the expression. Possible values can be stated as the following:
To create a nil expression, use | |||||||
| Used to set the | |||||||
| The name of a variable holding an object to treat as the current object during evaluation of this expression. Generally this may be omitted as the current object is known as part of the context. | |||||||
| The name of an object attribute or instance method of the current object, such as a data field ( | |||||||
| The name of a method to call on the current object. The arguments to the method will include the values of any attribute types other than
No parameters are returned to the | |||||||
| Allows the value of a regular expression to be the value of a named variable. | |||||||
| In previous releases, the
may now be written as
| |||||||
| Defines an Operator, that converts sub-expressions into a value. When comparing to objects of dissimilar type, the second object will be converted to the same type as the first object before comparison. Operator types include:
For any operators using
| |||||||
| Other operators include the following:
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
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 |
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.
...
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>
...
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:
...
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. |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
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.
Note | ||
---|---|---|
|
...
For a selected rule, check Used in these policies at the bottom of the center panel to see which policies reference the rule. |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
- In the Rules tab, click Add in the upper left corner. The Add Rule dialog appears.
- In the Add Rule dialog, enter the Short Name, Name and Author.
- Select a Severity.
- Enter a Description.
- (Optional) Enter Remediation instructions.
- Click Save.
The new Rule appears in the left pane of the Rules page, and defaults to the Simple Rule editor. - 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.
- Enter the config file matches using the selected editor.
- Click Save in the lower right corner.
- Test or validate the new rule (for more information, see Testing Policy Rules ).
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
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. |
In the Rules panel, select the rule.
- Click the Add device filter hyperlink. The Edit Filters dialog appears.To add a config file match filter:
- Click Add Device Attribute. The Edit Device Attribute dialog box appears.
- (Optional) Enter a Note describing the filter element.
- 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).
- Select an operator from the list (e.g., =, =>, in, Contains, Does Not Contain or any other operator).
- Enter or paste in the text for the configuration file line(s) or the value to match against.
- If you want to use more than one filtering criterion, click Apply and New.
- Click OK when the new filter is complete.
...
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 |
...
such that a policy |
...
would not apply to any configuration file. |
A policy consists of the following:
...
- In the Policies panel, select the policy to export.
- Click Export in the upper left corner.
- Take the appropriate action in the resulting dialog.
To copy a policy:
Click Copy in the upper left corner. The Copy Policy dialog appears.
- Enter a Policy Name, Short Name and Author.
- Edit the Description as needed.
- Click Save.
...
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.
...
- Click the By Device Groups tab at the bottom left of the page.
- In the Select Device Groups panel, select the device group.
- In the main table, select the policy or policies you want to deploy for the device group.
- Click Save.
Note | ||
---|---|---|
|
...
To view policy details, click the plus sign at the left end of a policy row. |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
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.
...
- 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.
...
- Select the rule in the Rules panel.
- Select Rule Logic Builder in the Editor list in the upper right corner. (This list is inactive if you are editing an existing rule.)
- To add a config file match for a configuration command:
- Click Add Config File Match.
- (Optional) In the Edit File Match dialog, enter a Note describing the config file match.
- 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
- In the text field, type or paste in the config file match line or block (see references below for additional information).
- Click OK.
- To add a device attribute check, click the Add Device Attribute button.
- Choose a device attribute from the left dropdown list (see Adding Device Attributes to a Rule Filter for a list of choices).
- Select an operator from the center dropdown list.
- Enter a value in the right field.
- Click OK or select Apply and New.
- Click Add Config File Match or Add Device Attribute to add a new element to the block list.
- Click the Save button at the bottom of the page.
...
- 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. |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
- Select the rule in the Rules panel.
- Select Simple in the Editor list in the upper right corner. (This list is inactive if you are editing an existing rule.)
- Then, specify required config file matches:
- 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
- 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:
- 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
- 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. - 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. |
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
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:
...
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:
...
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.
...