F5 load balancer - How to create compliance policies

This article is a technical overview of the basics of compliance, and how you can check that a node's config contains the lines you want it to contain.

What you need is a node, modeled in NetYCE (CMDB works as well) that has a configuration stored in the NCCM (Network Configuration and Change Management). It will detail the objects you need in order to perform compliance: policies, rules and conditions.

You can check for a node's compliance with a policy. This policy contains a number of rules, and each rule contains a number of conditions. We first need to make a policy, and then a rule for the vendor type of the node. There are multiple types of rules, but for this example we are interested in Configuration rules, which should be the default. We also support Command rules (based on the output of a command you run on the node) and Multiconfig rules (where you can compare the configs of multiple nodes to each other to see if their configs (or parts of their configs) are equal).

A rule also defines what sections of the configuration its conditions should be run on; you can use the Rule start and Rule end for this. There are many different ways you can use this:

The simplest way is to leave Rule start and Rule end empty. This takes the whole config. When you have a Rule start defined, there are different ways to look at it. You first need to see if you would like to specify the exact lines that you want to check in-between, or whether you want NetYCE to split up the config in logical blocks. To understand logical blocks, take the following section of an F5 BIGIP configuration:

Netyce can automatically split this up into three separate blocks, where you only have to set the Rule start as "ltm node /group1/node1" to only select that section to perform compliance on. Regular expressions are also supported, so a Rule start as "ltm node /group1/node." performs a compliance check on all three blocks separately. In order for the rule to be compliant, all three blocks need to be compliant against its conditions.

If you want to select these blocks based on lines, you simply enter "ltm node /group1/node1 {" as the rule start and "}" as the rule end. Regular expressions also work here, but do note that the Rule end checks the first instance it can find. If Rule start finds more matches, each of them will be counted as a block, so all of them have to be compliant for the rule to be compliant.

We do this, in order to support hierarchical blocks. Juniper and F5 configurations can be quite mean with nested blocks, so a simple block with a rule end of "}" with nested blocks will never work, because every single block is closed off with a closing accolade. Take for example the following section of an F5 config:

In order to reach the member blocks, you can use a Rule start containing the first lines of all their parent blocks, combined together. So in this case: "ltm pool /group1/pool1 { members { /group1/node1 {". The match here needs to be exact (so including the accolades) aside from any multiple spaces, but remember that you can use regular expressions. So to select all three of the members you can use "ltm pool /group1/pool1 { members { /group1/node. {".

When your rule has defined the text for the compliance to be run on, it's time to use the conditions. A condition contains a certain text that has to match the part of the configuration you selected in your rules. You can also set it to compare the complete configuration, or the node's hostname, node model or software version (information NetYCE also retrieves from the node when it pulls a configuration from the NCCM).

You can require the lines to match partially (must contain), to not match (must not contain), match the lines exactly (must contain lines), and match the lines exactly, and not allow any other lines in-between (must contain exactly).

On top of that you can also specify any lines that should not be in the text you're comparing. All can be either in regular expressions or regular text comparison.

Conditions are linked together with logic. You can use if-statements, and 'or' and 'and' statements, nested however you'd like. A rule's condition logic has to be syntactically valid, you can test this with the 'test' button under the rules' grid.

When you have created your policies, it's time to put them to actual use. More on that will follow in a future article.