This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Policy Reporting

We use the Policy Reporting function extensively.

I would however like to see some enhancements to make the feature more powerful.

In particular we have issues when attempting to perform policy compliance on individual interfaces (in our case QOS compliance). Rather than just enabling policy reporting on the configuration files, I would like to be able to generate similar reports on information held within the Cirrus database (particularly the interface table).

When creating a policy currently I only have the option of selecting a node/s to apply the policy. It would be useful to be able to determine criteria based upon both the existing node criteria and interface criteria.

The interface table could also have another field added for the interface configuration (perhapes parsed from the configuration held in the node table). If we could then apply a regex expression against this field, it would enable us to produce Policy Reports down to the interface level.

If/then/else logic within the rule definitions would also be a major benefit.

Dave.

  • Doesn't look like this is a hot topic for anyone else...


    I ended up creating a method for performing these functions outside of the current Policy Reporting function - although I hope in a future release I can bring this back into the core Cirrus product.


    An article showing how I am doing this is here


    Sav.

  • Thanks for posting!   We'll check this out and consider Policy Reporting enhancements based on your suggestions in a future release.  

  • I see policy reporting is getting an update in the next version - has this area of policy reports received any attention?

    Even expanding the node selection criteria when creating a policy to include node interface data would be a great help (beyond just the current node attributes).

    Use case:

    I have a large number of branch devices, but only a subset have IPTEL function. I wish to create a policy just for devices prefixed with a common name and where the device has a particular loop-back defined.

    I can do the first part already - but the second part is not available on the node selection filter.

    Dave.

  • Hi Dave - you'll be able to choose to dynamically select nodes according to custom properties. Would that work for what you're wanting to do? 

    --Christine

  • Hi Christine,

    That would help - I'm using the comments field as a pseudo custom property today (which is already part of the selection criteria).

    It means however that I still need to run external SQL routines to populate the comments (or custom properties) based upon data already available in NCM.

    It would be much better (and more practical for the average user) if this was not required - and the selection criteria expanded beyond the current node data.

    Dave.

  • Hey Dave - I'll add this to the feature request list. 

    --Christine