HowTo: Start Using NetMRI Policy

Image showing two arrows on a chalkboard. The top arrow points to the left and reads "Insanity" and the bottom arrow points right and reads "Sanity." A hand at the bottom right holds a piece of chalk.Sanity: We in network operations desire it.  Crave it, really.  And it seems tricky to find sometimes in complex network implementations.  When we deploy networks in the real world of mergers and acquisitions, upgrades and new vendors, it can be awfully hard to keep your sanity.  When I work with our customers to deploy Infoblox NetMRI, one of the tools I use to help improve sanity is NetMRI Policy.

What is NetMRI Policy?

Policy is a feature that’s a part of the full NetMRI license. The settings are found in Configuration Management -> Policy Design Center.  NetMRI provides policy as a way to test a managed device’s configuration and attributes.  A policy is a group of one or more rules. Rules test for the presence or absence of values in a device’s config.

Rules come in three flavours:

  • Simple Rule – Looks for config values that either must or must not appear in the config
  • Rule Logic Builder Rule – Combines several Simple Rules together using logical operators (and, or, not, If-Then-Else)
  • XML Rule – NetMRI stores all of its rules as XML, so the third option is to write rules as XML documents (there’s a separate blog post on XML Rules coming soon!)

Sanity Tests in NetMRI Policy

Our Sanity Tests check the most basic configuration items on a device.  We’ll create six to eight rules that test:

  • DNS
  • NTP
  • Time zone settings
  • Banners

There may be certain configuration items that are more important in your environment that you’d add.  Start by making a list of the most important items you’d expect to see on any device in your environment.

Let’s first look at the DNS rule, because it’s a good example of a Simple Rule.

DNS Rule

Image showing a NetMRI Simple Rule from the Policy module checking the configuration of DNS servers on a Cisco device.

It’s pretty simple, right?  We’re looking at the device’s configuration for a match on the configured DNS servers.  If they appear, the rule passes, otherwise it fails.  Notice the “Config File Must Contain” dropdown? That lets us fine-tune the matching.  In this case, we need to find all of the lines, but we don’t care about the order. We can also set this to look for:

Image showing the contents of NetMRI's Simple Rule ordering selector.

Also, notice the bottom section of the rule, “Config File May Not Contain.”  If your environment is like ours, there’ve likely been some changes over time, and you may have old DNS settings stuck in your devices.  Using the May Not list, you can test for these old settings.  The rule will tell you If it finds any.

We Do Regexes Here, Too.

In the DNS example, we’re doing a straight text match: Either the whole line matches or it doesn’t.  But what if we need to match something like an encrypted password?  There’s no way to match that across devices.  Fortunately, all the NetMRI rule types allow for the use of Regular Expressions (regexes) for this kind of match.  Take, for example, matching an NTP authentication key.  You configure an NTP key on a Cisco device like this:

Screen shot of a terminal session to a Cisco device configuring an NTP authentication key.

If you have “service password-encryption” enabled on the device, IOS will hide the key in the configuration, so doing a “show running-config” will show you:

Screen shot of a terminal session to a Cisco device showing the running configuration.

The value after “md5” will be different from device to device.  We can use a rule like this to check that there’s a key present:

Image showing an example of using a regular expression to match dynamic text in a device's configuration.

The “.*” in the first row is a regular expression meaning “any character, repeated endlessly.” Now we can match across many devices.

Regexes are a powerful tool in rule building, but many people find them difficult to master.  I use Regex101 when developing rules to test my expressions are right.

Rule Logic Builder

The next option in rule building is the Rule Logic Builder.  Basically, these rules take a bunch of Simple Rules and combine them together using logical operations (and, or, not and if-then-else).  I generally choose RLB rules when I want to address a single rule theme across several environments.  For instance, you might use RLB rules when there are different settings for a service per datacentre.

Take a look at this example:

This RLB will check the NTP and log server settings, taking into account an East Coast vs. West Coast configuration.  Each of the four rules are Simple Rules like we used above.  The expression in “Enforce This Rule” at the top of the box sets how the rules are combined.  In this case, the East Coast NTP and Syslog rules both need to be true, or the West Coast set need to be true for the overall rule to be true.

XML Rules

The final option for building rules is in native XML.  Under the covers, NetMRI saves all its rules as XML documents and that’s also what the internal parser uses to execute tests.  XML rules can be complex, and they’re not the first tool to reach for.  They do, however, offer some benefits not found in the other rule types:

  • Access to Lists – Lists are a feature in NetMRI Job Management that let you create data structures that work like dictionaries in Python or hashes in Perl
  • Iterators – XML rules can iterate through collections of blocks in device configs and perform an operation on each

There’s a separate post coming soon on XML rules, but here’s an example of one in our Sanity Check Policy.  To enable SSH access to Cisco devices, all of the vty lines must be configured with “transport input ssh.” 

XML rules are perfect for this kind of problem.  Here’s an example:

Image of an example NetMRI XML rule that checks all vty lines on a Cisco device to make sure SSH is enabled.

OK, what does this do?  Lines 3 through 6 set up some variables to hold information as we process the config.  Line 8 breaks the configuration up into blocks, using “line (vty digit digit)” as the start boundary.  The rule feeds each block into a search looking for exactly one instance of “transport input ssh.”  Each match increments the pass-count counter, while each miss increments the fail-count counter.  The name of the vty is also added to a list called interface_names if the block fails to match.

We didn’t find “transport input ssh” on some of the vty’s if fail-count is more than zero. If that’s true, the rule fails, and the output will include a list of vty’s that didn’t match.  Otherwise, the rule passes.

Rules to Policy

After you’ve created your individual rules, you create a policy to contain them on the Policies tab.  The NetMRI docs cover this well, so I won’t go into details here.  Here’s what a finished policy looks like for our network:

Image of our NetMRI sanity check policy showing nine rules as well as the policy description and filter.

Finally, it’s time to deploy the policy on a device group.  Again, the NetMRI docs cover this well, so I won’t go into details.  I will, however, advise that it’s best to try the policy out on a small group before it gets into wide circulation, just to make sure it’s working the way you expect.

How This Helps

The example content that comes with NetMRI: DISA STIG v7 and v8, PCI DSS, SANS, IANA and NSA best practices are pretty large compliance regimes.  PCI DSS v3.0 as an example contains 39 individual rules.  DISA STIG v8 for L2 devices has 71 rules.  In both cases, the rules are meant as a starting place and require some massaging for use in a real-world network.  Starting with such large policies, especially if you don’t have a good sense of how NetMRI rules work just ends up being frustrating.  By starting with a simple set of rules that reflect how your network works, you can quickly learn how to build good rules.  After you’ve got the skills, the sky is the limit.

Happy rule building!