CISCO-WAN-SCT-MGMT-MIB
The CISCO-WAN-SCT-MGMT-MIB enables Network Management Systems to remotely manage Service Class Template (SCT) configuration files on Cisco WAN nodes via FTP, specifically facilitating the addition, deletion, discovery, and monitoring of traffic characteristic definitions for switch class-of-service queues. This module targets unique SCT file instances identified by card type, port type, SCT ID, and version to enforce granular traffic shaping policies across specific hardware cards.
Imported Objects
Objects
20 total| Object Name |
|---|
ciscoWanSctMgmtMIB OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.236 |
RFC1155-SMI Unknown .1.3.6.1.4.1.9.9.236 |
ciscoWanSctMgmtMIBObjects OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.236.1 |
cwSctFileMgmtTableThis MIB defines a SCT file management table in which each row
corresponds to a unique SCT file.
When the NMS needs to add a SCT to a node, it transfers the SCT
file to a transient storage area on the node. The NMS then
performs a SET operation requesting the agent to accept the
transferred file. The agent validates the integrity of the
file and if valid, transfers the file to a secure area. It
would then create a new row in the SCT file management table. This
newly added row is then advertised to all NMS in the network using
appropriate traps (refer CISCO-WAN-SCT-MGMT-TRAPS-MIB).
Once a row is created, the agent keeps track of the operational
status of the corresponding SCT file. The NMS can query the status
of a SCT file by performing a GET operation on the row.
The NMS can delete a SCT file and its corresponding row in the SCT
file management table by performing a SET operation with the
appropriate RowStatus. The agent, upon successful deletion
of the row would advertise this configuration change to all the
NMS using appropriate traps.
The NMS could also perform a GETNEXT operation to discover all the
configured SCTs on a node. SEQUENCE OF CwSctFileMgmtEntry .1.3.6.1.4.1.9.9.236.1.1 |
cwSctFileMgmtEntryAn entry in the SCT file Management Table. This represents a
unique SCT file in the node. Each entry contains the configuration
and status information of a specific SCT in the node. CwSctFileMgmtEntry .1.3.6.1.4.1.9.9.236.1.1.1 |
cwSctCardTypeThis represents service modules in a node that require the
use of a SCT. The content of the SCT varies depending on the
specific hardware used. Hence there is a different SCT for
every type of card. The card types that support SCTs are
listed in the SYNTAX clause Enumeration .1.3.6.1.4.1.9.9.236.1.1.1.1 |
cwSctTypeThere are several types of SCTs. The portSct (1) specifies
traffic parameters that are applicable to a logical port
within a card. The cardSct (2) specifies traffic parameters
that are applicable to the whole card. Enumeration .1.3.6.1.4.1.9.9.236.1.1.1.2 |
cwSctIdEach logical port on a service module could need different
'class of service' characteristics. This can be achieved by
applying different SCTs on different ports. Thus for a given
card type, there could be multiple SCTs of different IDs. Gauge .1.3.6.1.4.1.9.9.236.1.1.1.3 |
cwSctMajorVersionThe SCT file consists of several tables. The number of
tables depend on the service module card type. Both the
contents and the row/column size of a table are subject
to change. The major version is incremented by the manager
whenever there is a change in the row/column size of the
table. Gauge .1.3.6.1.4.1.9.9.236.1.1.1.4 |
cwSctFileNameThis object specifies the absolute path name of the file
corresponding to the SCT indices.
After the agent accepts a SET operation and creates a new
row in the SCT file management table, it transfers the file
from the transient storage area to a secure location on the
disk. This object identifies the absolute path name of the
secure location on disk.
The file name would be in the format:
<CardType>_SCT.<SCTType>.<SCTId>.V<Major version>ro SnmpAdminString .1.3.6.1.4.1.9.9.236.1.1.1.5 |
cwSctFileMinorVersionThe SCT file consists of several tables. The number of
tables depend on the service module card type. Both the
contents and the row/column size of a table are subject
to change. The minor version is incremented by the manager
whenever there is a change in contents of the table.ro Gauge .1.3.6.1.4.1.9.9.236.1.1.1.6 |
cwSctFileChecksumThe manager specifies this checksum when trying to add
a SCT on the node. The agent while acting on the SET
operation would perform a checksum computation on the
FTPed file and compare against this object. If they differ,
the SET operation would be negated. If same, the file is
considered valid and this value is stored in a persistent
database. SCT files across the network with the same
combination of card type, sct type, major and minor versions
would have the same checksum.rw Gauge .1.3.6.1.4.1.9.9.236.1.1.1.7 |
cwSctFileDescriptionA description string can be associated with a specific SCT
index and in turn the SCT file. This may be used for
associating customized filenames.rw SnmpAdminString .1.3.6.1.4.1.9.9.236.1.1.1.8 |
cwSctFileOperStatusReflects the operational status of the SCT file.
The agent sets the value to valid(1) if the computed checksum
of the SCT file matches the provisioned checksum.
The agent sets the value to invalid(2) if the computed checksum
of the SCT file mismatches with the provisioned checksum. This
usually suggests a corrupted SCT file.
The agent sets the value to absent(3) if the file is missing in
the secure area of the disk, while a row exists in the SCT file
management table.ro Enumeration .1.3.6.1.4.1.9.9.236.1.1.1.9 |
cwSctFileRowStatus* To create a row, the manager needs to perform a SET
operations with a 'CreateAndGo' option. The agent would
validate the file specified by the indices if found valid
would create a new row.
* SET operation with 'CreateAndWait' option will be
rejected by the agent.
* SET operations with 'active' option would be treated as
a modify operation. The only objects that can be modified
in a row are the cwSctFileDescription and the
cwSctFileMinorVersion.
* SET operation with a 'Destroy' option would be used for
deleting a row in the cwSctFileMgmtTable and its
associated SCT file in the switch.
* The GET status of this object would always return 'active'.rw RowStatus -- Rsyntax INTEGER { -- active(1), -- notInService(2), -- notReady(3), -- createAndGo(4), -- createAndWait(5), -- destroy(6) -- } .1.3.6.1.4.1.9.9.236.1.1.1.10 |
ciscoWanSctMgmtMIBConformance OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.236.3 |
ciscoWanSctMgmtMIBCompliances OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.236.3.1 |
cwSctFileMgmtMIBCompliance OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.236.3.1.1 |
ciscoWanSctMgmtMIBGroups OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.236.3.2 |
cwSctFileMgmtObjectGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.236.3.2.1 |
More MIBs from Cisco
Browse all CiscoMIBs →The CISCO-ENTITY-VENDORTYPE-OID-MIB maps Cisco-specific hardware component identifiers to the ENTITY-MIB's entPhysicalTable, enabling precise differentiation of physical device types such as line cards, power supplies, and fans within Cisco infrastructure. This mapping ensures that SNMP management systems can accurately correlate physical inventory entries with vendor-specific component definitions for accurate device discovery and monitoring.
The CISCO-UNIFIED-COMPUTING-EQUIPMENT-MIB provides SNMP-based monitoring and management of Cisco Unified Computing System (UCS) hardware components, including chassis, blades, fabric interconnects, and power supplies. It exposes critical operational metrics such as device status, port states, temperature readings, fan speeds, and power consumption data for infrastructure health assessment.
The CISCO-UNIFIED-COMPUTING-ADAPTOR-MIB enables SNMP-based monitoring and management of physical and virtual network adapter interfaces, including link status, traffic counters, error statistics, and port configuration parameters, within the Cisco Unified Computing System (UCS) fabric interconnects and blade servers.
The CISCO-UNIFIED-COMPUTING-TC-MIB module defines standard textual conventions and data type definitions required for monitoring Cisco Unified Computing System (UCS) hardware components, including server blades, fabric interconnects, and chassis resources. These definitions enable consistent interpretation of specific UCS metrics such as power supply status, fan speeds, thermal readings, and port utilization across SNMP management applications.
The CISCO-UNIFIED-COMPUTING-FABRIC-MIB enables SNMP-based monitoring and management of the Cisco UCS Fabric Interconnects and associated fabric switching infrastructure, exposing metrics for port states, link utilization, error counters, and fabric topology status. It facilitates granular visibility into the physical and logical fabric layers, including uplink/downlink interfaces, VLAN configurations, and fabric failover conditions within the unified computing environment.
The STARENT-MIB module provides SNMP management and monitoring capabilities for Cisco ASR 5000 and ASR 5500 multimedia core platforms, specifically exposing metrics related to 2G/3G/4G and WiFi subscriber sessions, inline service states, and carrier-class high-availability status.