10-02-2016 11:36 AM
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
10-04-2016 02:32 AM
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
10-04-2016 11:45 AM
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:
04-11-2017 06:50 AM
Hi Johan!
Did you find a solution to your problem?
I'm encountering the same issue with PI 3.1.5.
Regards,
Thorbjørn
04-13-2017 09:48 AM
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.
04-17-2017 11:53 PM
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
08-22-2019 07:06 AM
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.
01-04-2017 06:58 AM
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>
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide