04-06-2009 08:01 AM
I generated the following Basic Compliance Template:
<?xml version="1.0" encoding="UTF-8"?>
<ConfigTemplate Name="admin_NoSann01" DeviceFamily="268437899,268437717,268438038" Version="1"><Commandlet Name="Commands" ControlStmt="false" Parent="none" Submode="false" Condition="false" Ordered="false"><CommandInfo CheckType="2"><Command> no spanning-tree vlan [#.*#]</Command></CommandInfo><ContextModeCommand></ContextModeCommand><PreCondition></PreCondition></Commandlet></ConfigTemplate>
which is in short:
Compliance Block
Global: yes
Use the SubMode of above condition
SubMode: no
Cli Commands
- no spanning-tree vlan [#.*#]
The compliance report successfully classified the devices as non-compliant that have a spanning-tree config like the following:
[...]
Spanning Tree
spanning-tree mode rapid-pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
no spanning-tree vlan 510 <== this is non-compliant;
[...]
But when deploying the config to make the non-compliant devices compliant, it seems the command will not be interpreted correctly:
when setting up the job this is what I get as a summary:
================
General Info
Owner: admin
Job Description: deploy:NoSpanning
Schedule Type: Immediate
Compliance job ID: 1400
----------------------------------------------
Job Policies:
-----------------------
Copy Running Config to Startup : false
E-mail Notification: Disabled
Job password: Disabled
Compliance Block
Global: yes
Use the SubMode of above condition
SubMode: no
Cli Commands
- no spanning-tree vlan [#.*#]
Job Approval: Disabled
----------------------------------------------
Device Details
Device Name:10.18.200.109
Commands:
-
Device Name:10.18.200.108
Commands:
-
==================
there is no command listed that will be deployed but it should be
spanning-tree vlan 510
for the device above
I cannot do the complete test (setup the deploy job and let it run) because I do not have test equipment on site only productive devices.
But from what I see it seems to be faulty...
Solved! Go to Solution.
04-06-2009 12:16 PM
In principle, just applying the command without the "no" should work. I imagine they ran into some issues with that which is why they chose not to support it. Maybe the issue dealt with the fact that some commands which are "no" may require additional arguments to make them fully effective.
04-06-2009 09:40 AM
This is expected behavior. "no" commands cannot be negated. This was documented way before RME 4.0 came out in CSCsa29347. Essentially the bug was closed with:
"Negate Commands will be generated only for Normal commands and not for No commands."
Now, I see value in what you are doing, so I suggest you pursue the PERS route for this.
04-06-2009 12:06 PM
I cannot find this in the documentation and CSCsa29347 is (currently) not available in the BugTool. So many thanks for this information!
I will see if I go the PERS route ..
I thought about the principles of the workflow. Isn't it that any command appearing in the config of an IOS device and starting with the string 'no' reverts to the same command without 'no' when it is negated? Is it that "simple" that negating 'no' just let it disappear or do I forget something?
04-06-2009 12:16 PM
In principle, just applying the command without the "no" should work. I imagine they ran into some issues with that which is why they chose not to support it. Maybe the issue dealt with the fact that some commands which are "no" may require additional arguments to make them fully effective.
04-06-2009 12:25 PM
I see, this would be indeed an argument. Thanks.
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