- 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.
2 comments:
CMS Solutions could really give aide to those people that have more tasks than everybody else. availing this CMS Solutions could get your life run a little smoother.Thanks for this very informative review. This seems to be very interesting, and very helpful for the readers.
Keep on posting!
CMS Solutions
In order to validate and then commit changes, CMS would have complete understanding of the policy config engine.
This article brought up interesting points of how CMS can face challenges with config changes.
I have one more point here:
a) User deletes a policy
b) Adds a new policy
c) Wants to retain old policy as well as new policy.
CMS should be building internal tables from the config and then push the commands to devices.
In such a case, for every above operation, CMS would make changes in its table. CMS would have deleted the old policy,at step-b new policy would have occupied in its place. With user intention to retain old policy as well the old policy would sit at a new index.
With above operations,the devices gets new config with old policy displacing its position.
Also, the sequence of commands pushed to device this way: delete pol-a, add policy-b, add policy-a
I understand the article suggests to eliminate first and last commands but the CMS policy engine would still have issues.
To over come it, one would suggest to block deleted entry and not to make useful for new entries at that commit - But thinking of a such huge policy changes the internal table of CMS would need more than required capacity.
Can you please comment on this?
Post a Comment