Prime Infrastructure 3.x - Problems with "Fix CLI" within compliance rules

[jmandersson]

Hi Experts,

I have an interesting problem that makes all of my "Fix jobs" to fail. In short - I make configurations blocks of switchports and then run a number of "match expression" within that block. In case of a violation I have specified "Fix CLI".

The problem occurs when I have violations in more then one switchport in the same switch. The combined configuration that makes the fix job does not have any line breaks. Or to be more precise - sometimes it does and sometime it does not. The below example is from a stack of 2 Catalyst 3650.

Does anyone have an idea why the "fix CLI" works for Gi2/0/1 but misses line breaks for Gi1/0/24?  I have ran the same job on a number of different stacks and one thing they have in common is that line breaks are missed for switch 1 but are there for switch 2. Very frustrating I must say.

Any help appreciated,

Regards

Johan 

[Jimmy Johansson]

Hi Johan,

Interesting problem indeed. I haven't run into it as of yet since I haven't tested compliance tests with stacked switchen yet. Will do this pretty soon though.

Have you tried adding some more line breaks between the interface and command in your fix? I'm guessing your fix is set up something like this:

Interface <match_violating_interface>

storm-control multicast levl pps 100

Can't provide more help than this right now but I am interested in knowing what causes the problem and how to fix it since I probably will run into it myself.

Regards,

Jimmy

[jmandersson]

Hi Jimmy,

Yes, the Fix CLI config is not more advanced then that.

Tried extra line breaks, white spaces and added som "dummy-rows" like this:

interface <x/x/x>

!

storm-control multicast level pps 100

!

But it still ends up on the same row, on switch 1 in the stack.

An export of the policy to a XML show that the Fix configuration is in a CDATA like this:

- <Fix>

- <![CDATA[

interface GigabitEthernet<2.1>
storm-control multicast level pps 100

  ]]>

  </Fix>

[thorbjorn.s]

Hi Johan!

Did you find a solution to your problem?

I'm encountering the same issue with PI 3.1.5.

Regards,

Thorbjørn

[joshelton]

I was having this same issue. I was checking line vty for an access list. It was combining the entries to make the fix:

line vty 0 4access-class VTY in

line vty 5 15 

access-class VTY in

So the first match was all together on one line, and the second was correct. Doing what was mentioned by Brian Taylor in the older post of adding the <1.1> on the violation message resolved the issue. I hope this helps.

[jmandersson]

Hi,

Yes, as joshelton wrote below. It does resolve the issue. But the workaround has a drawback. Every fix means a seperate Fix job, even if the Fix CLI should be sent to the same switch. For my use case, checking Port-Security parameters on host ports, it could be a major issue. If i need to change one parameter on every 48 port on a switch, it would mean 48 Fix jobs.

/

Johan

[amy.l.clay]

I had the same issue when I was using a policy "fix" that required a response to [confirm]. Use Multi-line commands. (Works on 3.2)

https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-1/user/guide/pi_ug/config-temp.html

Adding Multi-line Commands

To enter multi-line commands in the CLI Content area, use the following syntax:

<MLTCMD>First Line of Multiline Command
Second Line of Multiline Command

......

......

Last Line of Multiline Command</MLTCMD>

where:

<MLTCMD> and </MLTCMD> tags are case-sensitive and must be entered as uppercase.

The multi-line commands must be inserted between the <MLTCMD> and </MLTCMD> tags.

Do not start this tag with a space.

Do not use <MLTCMD> and </MLTCMD> in a single line.

[Brian Taylor]

For the VIOLATION MESSAGE try adding <1.1> so it will create separate fix CLI entries.

From => Has ACL1 on interface
* To => Has ACL1 on interface<1.1>