- Ability to configure multiple network elements.
- Ability to collect log information.
- Ability to analyze log and generation of periodic reports.
- Ability to monitor critical events.
- Ability to issue diagnostic commands to network elements and getting the results.
- Ability to allow multiple administrators to use CMS solutions - Role based Management.
- Ability to view the Audits - Who changed what and when.
- UI console: Allows users to configure network elements and also allows users to view the reports/analyze logs.
- Policy Server with Policy repository: Stores the configuration for each network element.
- Element Adapter: Convert configuration information to device understandable format. Sends the configuration information via protocol supported by devices.
- Log Collector and Report Generator: Collects logs from network elements and also can generate reports.
There are some pieces which CMS vendors tend to ignore, but in my view they are very important. One of them is to do with 'Configuration session'. Traditionally, each administrative change in the configuration results to a command for the device. That is, if administrator changes the configuration X number of times, then X different commands are prepared for the device. It is observed, if the administrator changes a rule (let us say firewall rule) and un-modifies the the changes, then two commands are generated. These commands are eventually sent in order of the changes to the device. Many times, this is not a problem. But this could be a problem in some instances where:
- First modification when applied changes the state of the device such as removing some run time states etc.. Second command which unmodifies the previous changes does not bring back the run time states that were destroyed.
- Some times, the first modification might even stop the traffic in network elements.
- Administrator added a rule and changes his mind and deleted the rule before committing. In this case, no command should be generated for this rule.
- Administrator deleted a rule and changed his mind and revoked the configuration change. In this case, no command should be generated for this rule.
- Administrator changed few parameters of a rule and again changed to newer values. Only new values should go to the device.
- Configuration session should have start and End. End can be complete revoke or commit.
- At any time, administrator can check for errors during configuration sessions. CMS solution is expected to provide 'Validate'.
- Checking for duplicate configuration session. At any time, only one configuration session is allowed. Note that multiple user can view the committed configuration. If new configuration session is started, then CMS solution should return warning to the user that configuration session
from 'user' at 'date&time' from 'ipaddress' is already started. It can give options such as 'take over the existing configuration session' or 'start from scratch by revoking previous session'.
- At the time of 'commit', CMS solution can take new version string, which is prepended by date&time.
- At the time of 'commit', CMS solution should generate commands to be sent to the device. It should do this by reading the information from configuration session, but not by the sequence of actions user did.
- New configuration session should be allowed even if commands generated out of previous configuration session were not synchronized with the device.
- Clearly show in the UI of the configuration which is part of current configuration session.
In addition, CMS solution should support:
- Listing down the configuration versions of a particular network element.
- Facility to migrate the network elements to previous versions.
- Facility to remove very old configuration versions to preserve the space in database.