TABLE-MODIF-TRACKING-MIB: View SNMP OID List / Download MIB

The MIB module to track and store the modifications in data of NMS specified MIB tables implemented in an SNMP command responder (traditionally called an SNMP agent). This MIB allows an NMS to register for change monitoring in the tables it is interested in. This MIB then tracks modifications in those registered tables, allowing the NMS to poll one table to determine if others need to be polled. This MIB keeps track of all modifications, including adding a new row, deletion of a row, and modification of an object in a row. It can also be configured to send change notifications to an NMS.

A table to register the MIB tables for monitoring various modification types e.g addition of new rows, deletion of rows and modification in objects of existing rows. The changes in the registered MIB tables' data will be recorded in tmtHistTableModifTable and tmtHistRowModifTable tables. Only the tables that are present in ctmtSupportedTable can be registered. If an NMS is interested in row modifications in only a few objects in a particular table, it can do that by specifying those objects in tmtRegExcludeObjTable.

Information for tracking changes in data of MIB table specified in this entry. Deleting an entry in tmtRegistrationTable deletes all corresponding entries in tmtHistTableModifTable and tmtHistRowModifTable tables. Entries in this table may not be changed while the corresponding value of tmtRegistrationTrackModifs is 'trackingModifications'.

The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator. The value of this variable could be name of the NMS user.

An arbitrary number that uniquely identifies the entries in this table. To create an entry a management application should pick a random number.

Indicates the type of MIB table data modifications that will be recorded. Any other type of MIB table data modifications will be ignored e.g. if the NMS has asked to process rowCreation(1) type of modification only, then rowDeletion(2) and rowModification(3) will be ignored. By default all types of MIB table data modifications are recorded.

The object identifier of the MIB table of interest. The changes in its data will be recorded in tmtHistTableModifTable and tmtHistRowModifTable tables. This must be the OID of the table-defining SEQUENCE OF registration point. A given tmtRegistrationOwner can register a particular MIB table only once.

The management context from which to obtain changes in tmtRegistrationTableID. This may be wildcarded by leaving characters off the end. For example use 'Repeater' to wildcard to 'Repeater1', 'Repeater2', 'Repeater-999.87b', and so on. To indicate such wildcarding is intended, tmtRegistrationCtxtNameWildcard must be 'true'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Operation of this feature assumes that the local system has a list of available contexts against which to apply the wildcard. If the objects are being read from the local system, this is clearly the system's own list of contexts. For a remote system a local version of such a list is not defined by any current standard and may not be available, so this function MAY not be supported.

Control for whether tmtRegistrationContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard.

The upper limit on the number of entries that the tmtHistRowModifTable may contain for modifications in the MIB table represented by this entry. A value of 0 will prevent any history from being retained. When the number of entries in tmtHistRowModifTable for a MIB table represented by this entry exceeds this value, the oldest entry will be deleted and a new one will be created.

The control to start/stop tracking modifications. The value is 'notActive' as long as tmtRegistrationEntryStatus is not active. When tmtRegistrationEntryStatus becomes active this object goes to 'ready'. This object can be set to 'start' only when its value is 'ready'. Once it is set to 'start', the MIB begins monitoring modifications for the MIB table represented by this entry and this object goes to 'trackingModifications'. This object can be set to 'stop' only when its value is 'trackingModifications'. Once it is set to 'stop', the MIB stops monitoring modifications for the MIB table represented by this entry and this object goes to 'ready'. Enumeration: 'notActive': 1, 'ready': 2, 'stop': 4, 'start': 3, 'trackingModifications': 5.

The control that allows creation, modification, and deletion of entries. For detailed rules see the DESCRIPTION for tmtRegistrationEntry.

A table to specify the objects in a registered MIB table, identified in tmtRegistrationTable, that this MIB WILL NOT monitor for modifications. E.g. if an NMS wants to watch changes in all objects in a MIB table except for a few objects, the NMS can specify those objects in this table indicating this MIB should NOT record changes in these objects. The implementation of this MIB may automatically put fast changing MIB objects e.g. Counters in this table so as to avoid a storm of modification records due to fast changing values of these objects. In this case, those entries will be read-only to the NMS.

Indicates the MIB object the changes in which WILL NOT be recorded by this MIB. If for a registered MIB, identified in tmtRegistrationTable, there are no entries in this table, this MIB will record changes in all the objects in that table. Entries in this table may not be changed, created or deleted while the corresponding value of tmtRegistrationTrackModifs is 'trackingModifications'.

The object identifier of the MIB object, the changes in which, WILL NOT be recorded by this MIB. Please note that this is an implicit wildcard i.e. by specifying a MIB object here, the changes in all its instances will NOT be recorded by this MIB.

The control that allows creation, modification, and deletion of entries. For detailed rules see the DESCRIPTION for tmtRegExcludeObjEntry.

A table to specify the list of MIBs, the modifications in which could be tracked by this MIB. This MIB table is read-only and it is always initialized by the SNMP command responder. If a MIB does not exist in this table, no table in that MIB can be registered in the tmtRegistrationTable.

Indicates the MIB table the changes in which can be tracked by this MIB.

The object identifier of the supported MIB. This must be the OID of the MIB-Module-defining MODULE-IDENTITY registration point.

A table to control the notifications sent by this MIB.

Notifications control information for a tmtRegistrationOwner. A new entry is automatically created in this table as soon as the first entry is created for a tmtRegistrationOwner in tmtRegistrationTable. Deleting all entries in tmtRegistrationTable for a particular tmtRegistrationOwner deletes this entry as well.

Indicates whether tmtTableRowModified notifications will or will not be sent when data in a MIB table registered by the tmtRegistrationOwner is modified in the SNMP command responder on the device. Disabling notifications does not prevent table modified messages from being added to tmtHistTableModifTable and tmtHistRowModifTable tables.

The number of tmtTableRowModified notifications for changes in the MIB tables registered by tmtRegistrationOwner that have been sent. This number may include notifications that were prevented from being transmitted due to reasons such as resource limitations and/or non-connectivity. If one is receiving notifications, one can periodically poll this object to determine if any notifications were missed. If so, a poll of tmtHistTableModifTable and tmtHistRowModifTable might be appropriate.

A table listing the MIB tables from the registered MIB tables in tmtRegistrationTable that had their data modified. There will only be one entry per registered MIB table that had a modification in its data. If a registered MIB table had many modifications, tmtHistTableLastModified of the entry corresponding to that registered table will be updated to the time when the last change occurred. This table allows the NMS to find out, in one operation: - If data in a given MIB table for an owner has changed. - If so, when did the last change occur. - And, the count of changes that occurred in the table. (Each SNMP Set request, CLI command or an internal process state change that causes modification in MIB table data is counted as one change. Although they may affect multiple rows in a MIB table.) Using this info the NMS can choose to: - Do nothing if the last change time is older than the time it polled this table last. - Check if the count of changes in the MIB table data is greater than this value at the previous poll plus any modifications done by this NMS. If this is false, it indicates there have been no modifications done by other managers. So, the NMS does not have to do anything. - Look into the tmtHistRowModifTable to find the rows that have changed since the last poll and only download the newly modified rows. - Or Download the entire table.

An entry for a MIB table registered by an owner that had its data modified.

It represents the number of modifications in the data of the MIB table represented by tmtRegistrationIndex and tmtRegistrationOwner. A single SNMP Set request, CLI command or an internal process state change that caused change in the MIB data is considered ONE modification. Although they may affect multiple rows in a MIB table. This object can be utilized to determine if the NMS will need to poll the tmtHistRowModifTable to find out if anything has changed. E.g., if the value of this object is 15 at the previous poll by the NMS. The NMS then modified the data in the registered MIB table twice. At the next poll, if the value of this object is greater than 17, then the NMS will know that someone else has also modified the data of this MIB table and it should walk the tmtHistRowModifTable to find out rows that have been modified.

The number of entries that have been removed from the tmtHistRowModifTable for a MIB table represented by tmtRegistrationIndex and tmtRegistrationOwner in order to make room for new entries. This object can be utilized to determine whether your polling frequency on tmtHistRowModifTable is fast enough and/or the maximum number of entries allowed in the tmtHistRowModifTable for a MIB table represented by tmtRegistrationIndex and tmtRegistrationOwner is large enough such that you are not missing modification messages.

The time (in thousandth's of a second since the network management portion of the system was last re-initialized) when the last data modification for a MIB table, registered by a particular owner, occurred.

A table listing the rows that have been modified in a registered MIB table for a particular owner. The maximum number of entries in this table is controlled by the tmtRegistrationMaxRowModifHist object in the tmtRegistrationTable.

A modification in a row of a registered MIB table. If a single SNMP Set request, CLI command or an internal process state change caused modifications in multiple objects of a single row, only one entry will be created here. But if multiple SNMP Set requests, CLI commands or internal process state changes modify different objects in one row, multiple entries will be created.

A monotonically increasing integer for the sole purpose of indexing history entries. When it reaches the maximum value the agent the value back to 1.

The The value of sysUpTime when the modification in the row data of a registered MIB table occurred.

The type of modification that has occurred in the row data.

This object represents the instance of the row that has been modified. For example: if a row with '171.69.0.0' instance in ipRouteTable is added/deleted/modified, this variable will be set to '171.69.0.0'.

The source of the command that directly or indirectly caused the modification in the data of the row of a registered MIB table. other(1) - None of the types specified below. commandLine(2) - The ubiquitous Command Line Interface. snmp(3) - The Simple Network Management Protocol interface. internal(4) - The MIB data is changed because of changes in the process state e.g., new entries in ipRouteTable are created due to new routes learned by the routing process. http(5) - The Hyper Text Transfer Protocol interface. xml(6) - The eXtensible Markup Language interface. Enumeration: 'xml': 6, 'http': 5, 'commandLine': 2, 'snmp': 3, 'other': 1, 'internal': 4.

If tmtHistRowModifSource is 'snmp(3)', 'http(5)' or 'xml(6)' this object represents the type of address stored in tmtHistRowModifSourceAddress.

If tmtHistRowModifSource is 'snmp(3)', 'http(5)' or 'xml(6), the internet address of the NMS that did the modification in the data of the row of a registered MIB table. If tmtHistRowModifSource is set to 'commandLine(2)', this object represents the internet address of the VTY terminal. The length is zero if not available or not applicable.

If tmtHistRowModifSource is 'commandLine(2)', 'snmp(3)' with version 3, 'http(5)' or 'xml(6)' this objects records the name of the user. The length is zero if not available or not applicable.

This notification is sent when the data in a registered MIB table implemented in the SNMP command responder on the device is modified. This notification can be enabled/disabled by the value set in the tmtControlNotificationsEnabled object.

The compliance statement for entities which implement the Cisco Table Modification Tracking MIB.

A collection of objects providing the table and MIB objects registration capability.

A collection of objects providing the control (enable/disable) of Table Modification Tracking MIB notifications.

A collection of objects keeping the history of changes in the data of a MIB table.

The notification generated by the Table Modification Tracking MIB.