The CISCO-CONFIG-MAN-MIB aims for keeping the track of valid configurations that are configured on the device.
Following are the key requirements which are met by this MIB.

• To know which CLI commands were entered during a particular configuration event.
• To notify the NMS when there is any change in running-configuration.
• To keep track of the time stamps when the running config was last changed or saved.
• track other relative information of CLI changes like command source, terminal details etc.

• Multiple users/events to be handled.
• The configuration records are to be maintained per context
• The configuration to be in sync on Active and Standby units in case Failover is configured.
• Old entries to be bumped off when the table is full.

A new configuration infrastructure module named “config history” is introduced which runs as a separate thread and is responsible for generation and maintenance of config events. The config events are registered only through command line (console, ssh and telnet), as currently the device does not support configuration via SNMP. These config events can be triggered through console, SSH and Telnet.

New data structures introduced to hold the various elements in ccmHistoryEventTable and ccmCLIHistoryCommandTable. The instance of these structures are created with context creation.

A linked list stores the CLIs entered per context and a Configuration Event Queue stores the CLIs entered per event but always contain redundant data. In case of event which is raised due to show/copy commands there will be no other entries in the cli table.

The config history event is invoked when an event needs to be registered. The event is validated and added in ccmHistoryEventTable. When the running configuration is changed the command handler gets notified and the current event index is looked-up and CLI data structure is populated which gets en-queued to data structure holding the list of CLISs and its linked to the corresponding Configuration Event.

In failover setup, the configuration done on active system gets copied to the backup system.
To achieve the synchronization between both the systems, following steps needs to be taken

• Any configuration done on the backup system is not recorded in ccmHistoryEventTable.
• Any configuration done on the active system will be recorded in ccmHistoryEventTable entry for the same will be copied to the backup’s event table via message handlers.

When the table is full, the old entries are removed to make room for the new ones. When an event entry is bumped, references from cli table are also removed. This is achieved by fetching the data from Config Event Queue and then removing it from the same and CLI list.

There are times when multiple users register events to ccmHistoryEventTable. When an event is registered in ccmHistoryEventTable, the status of that event is marked with a flag CONFIG_ACTIVE_USED. The ttynum and the above mentioned status variable is used to identify the corresponding event to which a particular cli belongs.

SNMP communicates with this module to poll the ccmHistoryEventTable, ccmCLIHistoryCommandTable and their entries.
It is also be responsible for generating the running-config-changed traps in case the trap is enabled.