Do we expect to see duplicates of profiling policies on the policy export list ?

[bhaguntu]

Customer has some administrator modified and created policies on the profiling policies on ise. When we export the profiling policy list, we see some duplicates of the policies. Importing the same list back on ise does not reflect the duplicates on the ise. Would this be a database issue or a bug to be filed ? If its a bug, do we open it as an enhancement bug or a document bug. Please suggest.

Thanks,

Bhavana.

[kthiruve]

Are you saying that you see duplicate entries in the XML, can you copy/paste it if possible?

Just wondering what happens if you export to a new ISE server where there are no policies?

-Krishnan

[Craig Hyps]

There may be duplicate profiler policy conditions and rules, but you should not see duplicate policy names (MyCustomDevice in example below).  As Krishnan suggested, maybe you can share snippet here that shows duplicate policy names.

<Policy description="My Custom Profiler Policy" isEnabled="true" matchingIdentityGroup="false" minimumCertaintyMetric="30" name="MyCustomDevice" version="4">

<PolicyRules>

<PolicyRule certaintyFactor="30" name="CustomDevice-Rule1"/>

</PolicyRules>

</Policy>

[bhaguntu]

Hi Krishnan and chyps,

Yes, we see the duplicates on the exported xml file -

<Policy description="Policy for Cisco-AP-Aironet-1532" isEnabled="true" matchingIdentityGroup="false" minimumCertaintyMetric="30" name="Cisco-AP-Aironet-1532" parentFQN="Cisco-Device:Cisco-Access-Point_PHX08503002" version="2">

<PolicyRules>

<PolicyRule certaintyFactor="30" name="Cisco-AP-Aironet-2800Rule5f7d37ac-acad-4425-87a3-4799c482ed1b_copy_copy_copy"/>

<PolicyRule certaintyFactor="30" name="Cisco-AP-Aironet-3800Rule0b38fb2f-7789-48ca-ad42-ac328a6cb261_copy_copy"/>

</PolicyRules>

</Policy>

There are a couple more like that.

[Craig Hyps · Accepted solution]

Ok. That is not a copy of the Policy itself, but duplication of the rules/conditions.  This will likely happen if duplicate a policy before making changes.  Rather than referencing the original rules and subordinate conditions, it creates a new rule (a copy of original) and also duplicates the conditions.  I will raise issue with engineering, but also recommend opening TAC case to have defect filed.

I suppose the idea is to provide a true duplicate and not impact original policy if make changes to constituent rules and conditions, but in my own experience, I prefer to reference original objects.

[bhaguntu]

Thank you Chyps for the clarity. I will proceed to opening a bug, but should this be a doc bug or an enhancement bug ?

[Craig Hyps]

It is certainly not a doc bug.  And we do require that each policy reference unique rule names.  The naming may look odd in an export since it is based on _copy appendage rather than a completely different id value, but it does let you know it is a copy of another.   What I am suggesting to engineering is that we remove any rule and condition copies that were unused at point of submit.  When click duplicate, the rules and conditions are automatically created, but if you swap any of them out, the copied objects are not deleted if unused in new policy.

In short, the duplicates are not going to harm anything.   Also, an export should only show ones actually being used in policies.  I think the issue is more of general maintenance and clean up of unused artifacts.  By the way, rule names are only revealed in raw xml, so not something you see in UI, but conditions are exposed.

Craig