I am looking to check that the configuration of interfaces on Cisco devices adhere to some basic standards. The search config block option in the creation of a rule allows me to to this, but it seems to have a flaw - which I think could be corrected in future releases without too much re-engineering. Alternatively, if I am wrong or anyone can suggest a workaround I am all ears.
The flaw is that the policy reporter assumes that a config block MUST exist in a config. This is fine if you start and end the config block with:
interface gigabitethernet (start)
because you can easily predict if your devices have certain types of interfaces. However this logic will only ever let you check interface config lines that apply to ALL gigabit interfaces.
Let me present a scenario: Say I have a particilar type of kit which connects to a Cisco switch - say a number of call loggers - and I want to ensure that the ports are always in vlan 200 (switchport access vlan 200). This is just an example.
I could devise a standard, where all call logger ports have a description of "description Call logger - <name>" and create a rule with a config block of:
description Call logger(start)
I could then add any regexs I like, such as "switchport access vlan 200"
The problem is I would get errors for any Cisco devices which did not contain the above config block. I want to be able to apply the regexs of a config block, ONLY if the config block exists.
Edit: A tick box in the rule definition which says "Alert if config block found" would make the policy reporter tool massively more useful.
Can anybody assist? If I have not made it clear, above, what I mean please ask.
Solved! Go to Solution.
thanks for that. I have voted and posted a comment, but the date of the feature request does not fill me with confidence. I get the impression (from the number of posts about the policy reporter) that it is not of massive importance to most solarwinds users. And while it's great that you respond to user feature requests, I do question the vision of the NCM policy reporter product - it just cannot enforce enough compliance currently to be part of a full compliance strategy. For example, I have written a standards document for the configuration of our Cisco devices, but only about 50% of the standards can be enforced with the policy reporter. It is very nearly a great product.
I'm afraid I must confirm what you are saying. Customers are one of the most important sources of information / priorities for features. As you said, although there definitely is some demand for this enhancements and I fully agree it makes sense, it doesn't seem to be super critical for the majority of NCM users.
if the policy reporter had this feature Solarwinds could shout how good it was from the rooftops and then more people would buy into it. If you build it they will come - maybe.
You know, I was thinking about this earlier and there is one HUGE flaw in the concept of working on things based on the number of votes that a feature gets in the feature request section. The problem is, that if not enough people are seriously using a module, the feature requests for that part of the program never get enough votes to be implemented. Even though the reason they aren't using it is because it is too hard to work with, or doesn't do what they want and they stop using it. While other parts of the program that are more popular get less important things done.
Policy manager I think is one of those. IMHO opinion every IT shop should be using it, but most of them aren't. Why? Because doing some fairly simple things is very difficult. This feature for example, the config block is very powerful but is very limited by what it currently can't do. The "Call Logger" example given is a good one. I have some very similar things I'd like to work on which this feature would enable, but for now I just need to keep track of the number of known configs that don't have the config block but their config is still ok. Another example of a glaring omission is, its really easy to check and see if things like your SNMP communities that should be in the config are there, but its not so easy to check and see if snmp communities that shouldn't be there are in a config. This would also apply to other things such as local usernames.
So, the end result is a very powerful module like Compliance Manager that needs some work to be really useful, might not get the features it needs because the voting doesn't drive it up.
Hopefully SW will recognize this flaw in the voting system and temper it by maybe looking at all different parts of NCM, like the Config Manager and such separately and not only taking the # of votes that a feature gets, but how important the new feature could be to making the product more popular...
Believe me, we are not blindly following the number of votes. The Policy feature is a very good example. Although none of the individual feature requests related to compliance reports is currently in TOP 5, there are a lot of them with decent number of votes. What is the message here for the product manager? NCM Compliance needs attention. And we have many more information sources -- I follow discussions, create polls, talk to customers, sales, support etc.
I'll be updating the What We Are Working On post for NCM soon. Stay tuned and I'm sure you will see this answer makes sense.
I definitely appreciate your detailed answers with use case descriptions. They make my work much easier.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.