PI 3.4 Compliance policy check subblock (policy-maps)

[mario.jost]

We have a hard time checking any blocks that have subblocks like routing (EIGRP named mode), policy-maps and crypto pki certificates. Let me show one example. We want to check following code:

policy-map QOS_OUT_CHILD
 class QOS_ROUTING
  set dscp cs6
  priority percent 5
 class class-default
  fair-queue
!
policy-map QOS_OUT
 class class-default
  shape average 2000000   
   service-policy QOS_OUT_CHILD

 We have tried following rule set A:

Rule1:
Condition Scope: Configuration
Parse as Blocks: Yes (setting start expression only)
Condition match criteria: Matches the expression policy-map QOS_OUT_CHILD

Rule2:
Condition Scope: Previously Matched Blocks
Parse as Blocks: Yes (setting start expression only)
Condition match criteria: Matches the expression class QOS_ROUTING

Rule3:
Condition Scope: Previously Matched Blocks
Parse as Blocks: No
Condition match criteria: Matches the expression set dscp cs6

Rule4:
Condition Scope: Previously Matched Blocks
Parse as Blocks: No
Condition match criteria: Matches the expression priority percent 5

Rule5:
Condition Scope: Configuration
Parse as Blocks: Yes (setting start expression only)
Condition match criteria: Matches the expression policy-map QOS_OUT_CHILD

Rule6:
Condition Scope: Previously Matched Blocks
Parse as Blocks: Yes (setting start expression only)
Condition match criteria: Matches the expression class class-default

Rule7:
Condition Scope: Previously Matched Blocks
Parse as Blocks: No
Condition match criteria: Matches the expression fair-queue

With this ruleset, there is no violation even if we delete the fair-queue part in the configuration. It finishes with all green. We have done some two level block verification in our switch configuration (archive command) where we used following approach:

Rule1:
Condition Scope: Configuration
Parse as Blocks: No
Condition match criteria: Matches the expression policy-map QOS_OUT_CHILD

Rule2:
Condition Scope: Configuration
Parse as Blocks: Yes (setting start expression only)
Condition match criteria: Matches the expression class QOS_ROUTING

Rule3:
Condition Scope: Previously Matched Blocks
Parse as Blocks: No
Condition match criteria: Matches the expression set dscp cs6

Rule4:
Condition Scope: Previously Matched Blocks
Parse as Blocks: No
Condition match criteria: Matches the expression priority percent 5

Rule5:
Condition Scope: Configuration
Parse as Blocks: Yes (setting start expression only)
Condition match criteria: Matches the expression class class-default

Rule6:
Condition Scope: Previously Matched Blocks
Parse as Blocks: No
Condition match criteria: Matches the expression fair-queue

This works great, if the commands you want to check are unique in the configuration. The problem with policy-maps is, that we have multiple class-default classes, so prime builds multiple blocks and there is always a violation to be found because the fair-queue command is not present in the policy-map QOS_OUT. I couldnt find anything in the cisco prime documentary and the examples do not cover such a scenario. To check EIGRP in named mode, it is more complicated, as you have 4 levels down if you go into the af-interface mode. How do you get prime to check blocks within blocks to make sure the configuration is complete?

[mario.jost · Accepted solution]

To answer my own question in case someone else comes accross the same problem some day. We couldnt find a solution for 3 or 4 level configuration blocks. Especially if there are keywords that are present multiple times in a configuration. We ended up using regex to check this configuration. So if you wanna check following code:

policy-map type inspect SELF2WAN
 class type inspect SELF2WANPASS
  pass
 class type inspect SELF2WAN
  inspect 
 class class-default
  drop
policy-map type inspect WAN2SELF
 class type inspect WAN2SELFPASS
  pass
 class type inspect WAN2SELF
  inspect 
 class class-default
  drop

We use following 2 rules to check this:

Condition Scope Details

Condition Scope: Device Command Outputs

Show Commands: show running-config | section policy-map type inspect SELF2WAN

Condition Match Criteria

Operator: Matches the expression

Value: (policy-map type inspect SELF2WAN)\n( class type inspect SELF2WANPASS)\n(  pass)\n( class type inspect SELF2WAN)\n(  inspect )\n( class class-default)\n(  drop)

Condition Scope Details

Condition Scope: Device Command Outputs

Show Commands: show running-config | section policy-map type inspect WAN2SELF

Condition Match Criteria

Operator: Matches the expression

Value: (policy-map type inspect WAN2SELF)\n( class type inspect WAN2SELFPASS)\n(  pass)\n( class type inspect WAN2SELF)\n(  inspect )\n( class class-default)\n(  drop)

So this regex only matches if these entries are found in the same order. This works great and is the best solution for us right now.