As per our IMMS model; Configuration Management defines the relationships between the network administrator exercised control over resources, events, and/or service levels on the network elements, and the actual resultant network operations performed by each of the network elements at the different defined levels referred to above. In simpler terms Configuration Management is the relationship between the User’s inputs to the network through the network elements and the resultant –production- outputs that defines network operations in additions to the levels of performance of those network operations.
This relationship could either be derived directly from mapping a particular level on the element from the command line interface to a corresponding MIB Object or set of MIB Objects, or indirectly through measuring certain relevant Security, Accounting, Performance and/or Fault metrics.
Configuration changes have other important aspects that are ignored; such as:
- Running, versus Start-up, versus Working configuration changes.
- Running versus Start-up configuration changes ‘save times’.
- Information about configuration events such as the event time, command source, configuration data source, configuration source terminal type and number as well as terminal user and location.
- Information about the host name and configuration source server that caused the change and the configuration file name at the storage file servers.
- Configuration files copying operations data and management to and from the network device(s).
Hence; The goal of Configuration management is NOT -ONLY- to track and maintain the network Device’s configuration through detecting then collecting and archiving latest configurations and configuration changes; but to also expand and drive the concept of device configuration archival into other types of network configurations. Similarly the goal of Change management is NOT limited in scope ONLY to detecting changes in those archived configuration files! Ultimately the main goal that this solution attempts to achieve is to build a ‘Network Configuration Management’ service concept to be tackled and considered along side the current industry popular trend of ‘Device Configuration Management’.
Configuration management and Change management; while related, they are however completely separate issues, and are not to be confused in terms of functionality or procedure.
Many Faults are NOT necessarily related to configurations or even changes, while many other Faults are the result of delayed responses as a result of changes both on the configurations and on the operational performance levels along of course Security issues!
How to achieve *true* and *functional* Network Configuration management. This could be achieved by doing the following:
- Listening to configuration Change Trap and Notification events.
- Monitoring and accounting for the SNMP SET-Requests received on the network Element.
- Monitoring and accounting for the Telnet and XML type TCP sessions opened against the network Element, reporting on the source addresses and times that those sources connected to each network Element.
- Monitoring basic configuration information such as the System information details such as the System Hostname, the Elements configured interface IP addresses and corresponding Administrative statuses and description Aliases. Tracking any changes on the reported data.
- Monitoring and tracking Hardware Chasses and Modules inventory across the network and on each of the Elements. This should be done while tracking the Host name (System name) for each Element to detect any changes to the network Hardware.
- Polling SNMP MIB Objects based Configuration information particularly those that are not available from the managed Element’s command line interfaces.