Solved: RME 4.2: baseline template - wrong command interpretation for deploy?

Martin Ermel · ‎04-06-2009

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

Joe Clarke · ‎04-06-2009

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.

View solution in original post

Joe Clarke · ‎04-06-2009

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.

Martin Ermel · ‎04-06-2009

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?

Joe Clarke · ‎04-06-2009

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.

Martin Ermel · ‎04-06-2009

I see, this would be indeed an argument. Thanks.