The DSG CA Vendor Table associates a CA Vendor Index
with the CA Vendor Name and the number of tunnels
that carry the CA Vendor's OOB Messaging.
Parsed from file CISCO-CABLE-DSG-IF-MIB.mib
Module: CISCO-CABLE-DSG-IF-MIB
The DSG CA Vendor Table associates a CA Vendor Index
with the CA Vendor Name and the number of tunnels
that carry the CA Vendor's OOB Messaging.
The DSG CA Vendor Table associates a CA Vendor Index
with the CA Vendor Name and the number of tunnels
that carry the CA Vendor's OOB Messaging.
Parsed from file CISCO-CABLE-DSG-IF-MIB.my.txt
Company: None
Module: CISCO-CABLE-DSG-IF-MIB
This object will be incremented and included in the varbind
list of the cIfMonNotifEvent notification. This object is
guaranteed to increase once per notification originated from
the MIB.
NMSes should track the value of this object received in each
notification. If the difference in the value of this object
across two consecutive notifications is more than one, a
notification has been delayed, dropped, lost or routed out
of sequence. The only reliable way to recover such
notifications is via the NOTIFICATION-LOG-MIB. The NMS should
preferably configure/create a log in the NOTIFICATION-LOG-MIB
to capture cIfMonNotifEvent notifications. If possible, a
named log should be created. When a notification loss is
detected, the NMS can then poll the log to determine which
notification was lost. The reader can look up RFC 3014 for
more information on the NOTIFICATION-LOG-MIB.
In addition to tracking the value of this object in each
notification, the NMS should periodically poll this object.
If the polled value of this object is two or more counts
greater than the value from the last received notification,
a notification has likely been dropped, and the NMS must
use the NOTIFICATION-LOG-MIB to poll for the dropped
notification.
ccdsgIfCaVendorTable OBJECT-TYPE SYNTAX SEQUENCE OF CcdsgIfCaVendorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DSG CA Vendor Table associates a CA Vendor Index with the CA Vendor Name and the number of tunnels that carry the CA Vendor's OOB Messaging." ::= { ccdsgIfCaVendor 1 }
ccdsgIfCaVendorTable OBJECT-TYPE SYNTAX SEQUENCE OF CcdsgIfCaVendorEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The DSG CA Vendor Table associates a CA Vendor Index with the CA Vendor Name and the number of tunnels that carry the CA Vendor's OOB Messaging." ::= { ccdsgIfCaVendor 1 }
Vendor: Cisco
Module: CISCO-CABLE-DSG-IF-MIB
[Automatically extracted from oidview.com]
ccdsgIfCaVendorTable OBJECT-TYPE SYNTAX SEQUENCE OF CcdsgIfCaVendorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DSG CA Vendor Table associates a CA Vendor Index with the CA Vendor Name and the number of tunnels that carry the CA Vendor's OOB Messaging." ::= { ccdsgIfCaVendor 1 }
cIfMonNotifCount OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object will be incremented and included in the varbind list of the cIfMonNotifEvent notification. This object is guaranteed to increase once per notification originated from the MIB. NMSes should track the value of this object received in each notification. If the difference in the value of this object across two consecutive notifications is more than one, a notification has been delayed, dropped, lost or routed out of sequence. The only reliable way to recover such notifications is via the NOTIFICATION-LOG-MIB. The NMS should preferably configure/create a log in the NOTIFICATION-LOG-MIB to capture cIfMonNotifEvent notifications. If possible, a named log should be created. When a notification loss is detected, the NMS can then poll the log to determine which notification was lost. The reader can look up RFC 3014 for more information on the NOTIFICATION-LOG-MIB. In addition to tracking the value of this object in each notification, the NMS should periodically poll this object. If the polled value of this object is two or more counts greater than the value from the last received notification, a notification has likely been dropped, and the NMS must use the NOTIFICATION-LOG-MIB to poll for the dropped notification." ::= { cIfMonNotifMIBObjects 1 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.9.10.999.1.1.0 | cIfMonNotifCount | 0 | 0 | None |
| 1.3.6.1.4.1.9.10.999.1.1.1 | ccdsgIfCaVendorEntry | 4 | 4 | An entry in the CA Vendor Table. Rows are created by an SNMP SET request setting the value of ccdsgifCaVendorRowStatus to 'create… |
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.9.10.999.1.2 | cVrrpNotificationCntl, cIfMonNotifTable | 2 | 8 | This table contains information about the last notification that was sent for a particular interface. |
| 1.3.6.1.4.1.9.10.999.1.7 | cVrrpOperationsTable | 1 | 15 | Unified Operations table for a VRRP router which consists of a sequence (i.e., one or more conceptual rows) of 'vrrpOperationsEnt… |
| 1.3.6.1.4.1.9.10.999.1.8 | cVrrpAssociatedIpAddrTable | 1 | 4 | The table of addresses associated with this virtual router. |
| 1.3.6.1.4.1.9.10.999.1.9 | cVrrpNotificationNewMasterReason | 1 | 1 | This indicates the reason for NewMaster notification. Used by cVrrpNotificationNewMaster notification. |
| 1.3.6.1.4.1.9.10.999.1.10 | cVrrpNotificationProtoErrReason | 1 | 1 | This indicates the reason for protocol error notification. Used by cVrrpNotificationProtoError notification. |