Using the CPD Editor

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.

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

.*