SL-ENTITY-MIB

File: SL-ENTITY-MIB.mib (25705 bytes)

Imported modules

SNMPv2-SMI SNMPv2-TC SNMP-FRAMEWORK-MIB
IF-MIB SL-MAIN-MIB

Imported symbols

MODULE-IDENTITY OBJECT-TYPE mib-2
NOTIFICATION-TYPE TimeTicks TDomain
TAddress TEXTUAL-CONVENTION DisplayString
AutonomousType RowStatus TimeStamp
TruthValue PhysAddress SnmpAdminString
InterfaceIndex slMain

Defined Types

PhysicalIndex  
An arbitrary value which uniquely identifies the physical entity. The value should be a small positive integer; index values for different physical entities are not necessarily contiguous. The index 0 is for the Shelf. The indices 1..100 are for the Cards. The indices 101..102 are reserved for the Power-Supply. The indices 103..110 are reserved for the Fans.
TEXTUAL-CONVENTION    
  INTEGER 0..255  

PhysicalClass  
An enumerated value which provides an indication of the general hardware type of a particular physical entity. There are no restrictions as to the number of slEntPhysicalEntries of each slEntPhysicalClass, which must be instantiated by an agent. The enumeration 'other' is applicable if the physical entity class is known, but does not match any of the supported values. The enumeration 'unknown' is applicable if the physical entity class is unknown to the agent. The enumeration 'chassis' is applicable if the physical entity class is an overall container for networking equipment. Any class of physical entity except a stack may be contained within a chassis, and a chassis may only be contained within a stack. The enumeration 'backplane' is applicable if the physical entity class is some sort of device for aggregating and forwarding networking traffic, such as a shared backplane in a modular ethernet switch. Note that an agent may model a backplane as a single physical entity, which is actually implemented as multiple discrete physical components (within a chassis or stack). The enumeration 'container' is applicable if the physical entity class is capable of containing one or more removable physical entities, possibly of different types. For example, each (empty or full) slot in a chassis will be modeled as a container. Note that all removable physical entities should be modeled within a container entity, such as field- replaceable modules, fans, or power supplies. Note that all known containers should be modeled by the agent, including empty containers. The enumeration 'powerSupply' is applicable if the physical entity class is a power-supplying component. The enumeration 'fan' is applicable if the physical entity class is a fan or other heat-reduction component. The enumeration 'sensor' is applicable if the physical entity class is some sort of sensor, such as a temperature sensor within a router chassis. The enumeration 'module' is applicable if the physical entity class is some sort of self-contained sub-system. If it is removable, then it should be modeled within a container entity, otherwise it should be modeled directly within another physical entity (e.g., a chassis or another module). The enumeration 'port' is applicable if the physical entity class is some sort of networking port, capable of receiving and/or transmitting networking traffic. The enumeration 'stack' is applicable if the physical entity class is some sort of super-container (possibly virtual), intended to group together multiple chassis entities. A stack may be realized by a 'virtual' cable, a real interconnect cable, attached to multiple chassis, or may in fact be comprised of multiple interconnect cables. A stack should not be modeled within any other physical entities, but a stack may be contained within another stack. Only chassis entities should be contained within a stack.
TEXTUAL-CONVENTION    
  INTEGER other(1), unknown(2), chassis(3), backplane(4), container(5), powerSupply(6), fan(7), sensor(8), module(9), port(10), stack(11)  

PhysicalType  
An enumerated value which provides an indication of the general card type of a particular physical entity. There are no restrictions as to the number of slEntPhysicalEntries of each PhysicalType, which must be instantiated by an agent.
TEXTUAL-CONVENTION    
  INTEGER powerModule(1), fanModule(2), switchModule(3), trunkModule(4), oc12Module(5), gbeModule(6), fcModule(7), passiveModule(8), trunkModuleTransponding(9), oc3Module(10), ds3Module(11), oc48tdmModule(12), transpondingModule(13), edfaModule(14), transponding10GModule(15), trunk10GModule(16), esconModule(17), gbeAggModule(18), esconTrunkModule(19), fc2gModule(20), pl16000(90), pl10(91), pl20(92), pl100(93), pl400PmPiggy(94), pl400MuxPiggy(95), pl400(96), pl1000(97), pl200(98), pl400E(99), unknown(100), pl800(800)  

CleiCode  
COMMON LANGUAGE Equipment Code. The CLEI code contains an intelligent ten-character code that identifies the telecommunications equipment.
TEXTUAL-CONVENTION    
  DisplayString Size(10)  

SlEntPhysicalEntry  
SEQUENCE    
  slEntPhysicalIndex InterfaceIndex
  slEntPhysicalDescr SnmpAdminString
  slEntPhysicalClass PhysicalClass
  slEntPhysicalHardwareRev SnmpAdminString
  slEntPhysicalFirmwareRev SnmpAdminString
  slEntPhysicalSoftwareRev SnmpAdminString
  slEntPhysicalSerialNum SnmpAdminString
  slEntPhysicalProtectionEntity PhysicalIndex
  slEntPhysicalProtectState INTEGER
  slEntPhysicalProtectMode INTEGER
  slEntPhysicalStatus INTEGER
  slEntPhysicalFailureDescription SnmpAdminString
  slEntPhysicalAdminStatus INTEGER
  slEntPhysicalOperStatus INTEGER
  slEntPhysicalSysUptime TimeTicks
  slEntPhysicalType PhysicalType
  slEntPhysicalCleiCode CleiCode
  slEntPhysicalPartNumber SnmpAdminString
  slEntPhysicalOemSerialNum SnmpAdminString
  slEntPhysicalProductionDate SnmpAdminString

Defined Values

slmEntity 1.3.6.1.4.1.4515.1.3.6
The MIB module for representing multiple physical entities supported by a single SNMP agent. The MIB is based on the standard RFC-2737 entity-mib.
MODULE-IDENTITY    

slEntityPhysical 1.3.6.1.4.1.4515.1.3.6.1
OBJECT IDENTIFIER    

slEntityNotification 1.3.6.1.4.1.4515.1.3.6.2
OBJECT IDENTIFIER    

slEntPhysicalTable 1.3.6.1.4.1.4515.1.3.6.1.1
This table contains one row per physical entity. There is always at least one row for an 'overall' physical entity.
Status: current Access: not-accessible
OBJECT-TYPE    
  SEQUENCE OF  
    SlEntPhysicalEntry

slEntPhysicalEntry 1.3.6.1.4.1.4515.1.3.6.1.1.1
Information about a particular physical entity.
Status: current Access: not-accessible
OBJECT-TYPE    
  SlEntPhysicalEntry  

slEntPhysicalIndex 1.3.6.1.4.1.4515.1.3.6.1.1.1.1
The Slot number of the entity.
Status: current Access: read-only
OBJECT-TYPE    
  InterfaceIndex  

slEntPhysicalDescr 1.3.6.1.4.1.4515.1.3.6.1.1.1.2
A textual description of physical entity. This object should contain a string which identifies the manufacturer's name for the physical entity, and should be set to a distinct value for each version or model of the physical entity. Example: Smartoptics-Oc, Smartoptics-Ethernet, ... The actual value should be taken from the E2prom.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString  

slEntPhysicalClass 1.3.6.1.4.1.4515.1.3.6.1.1.1.3
An indication of the general hardware type of the physical entity. An agent should set this object to the standard enumeration value which most accurately indicates the general class of the physical entity, or the primary class if there is more than one. If no appropriate standard registration identifier exists for this physical entity, then the value 'other(1)' is returned. If the value is unknown by this agent, then the value 'unknown(2)' is returned.
Status: current Access: read-only
OBJECT-TYPE    
  PhysicalClass  

slEntPhysicalHardwareRev 1.3.6.1.4.1.4515.1.3.6.1.1.1.4
The vendor-specific hardware revision string for the physical entity. The preferred value is the hardware revision identifier actually printed on the component itself (if present). Note that if revision information is stored internally in a non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific hardware revision string is associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString  

slEntPhysicalFirmwareRev 1.3.6.1.4.1.4515.1.3.6.1.1.1.5
The vendor-specific firmware revision string for the physical entity (normally the boot-revision). Note that if revision information is stored internally in a non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific firmware programs are associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString  

slEntPhysicalSoftwareRev 1.3.6.1.4.1.4515.1.3.6.1.1.1.6
The vendor-specific software revision string for the physical entity. Note that if revision information is stored internally in a non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific software programs are associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString  

slEntPhysicalSerialNum 1.3.6.1.4.1.4515.1.3.6.1.1.1.7
The vendor-specific serial number string for the physical entity. The preferred value is the serial number string actually printed on the component itself (if present). On the first instantiation of an physical entity, the value of slEntPhysicalSerialNum associated with that entity is set to the correct vendor-assigned serial number, if this information is available to the agent. If a serial number is unknown or non-existent, the slEntPhysicalSerialNum will be set to a zero-length string instead. Note that implementations which can correctly identify the serial numbers of all installed physical entities do not need to provide write access to the slEntPhysicalSerialNum object. Agents which cannot provide non-volatile storage for the slEntPhysicalSerialNum strings are not required to implement write access for this object. Not every physical component will have a serial number, or even need one. Physical entities for which the associated value of the slEntPhysicalIsFRU object is equal to 'false(2)' (e.g., the repeater ports within a repeater module), do not need their own unique serial number. An agent does not have to provide write access for such entities, and may return a zero-length string. If write access is implemented for an instance of slEntPhysicalSerialNum, and a value is written into the instance, the agent must retain the supplied value in the slEntPhysicalSerialNum instance associated with the same physical entity for as long as that entity remains instantiated. This includes instantiations across all re- initializations/reboots of the network management system, including those which result in a change of the physical entity's slEntPhysicalIndex value.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString Size(0..32)  

slEntPhysicalProtectionEntity 1.3.6.1.4.1.4515.1.3.6.1.1.1.8
The value of slEntPhysicalIndex for the physical entity which 'protects' this physical entity. A value of zero indicates this physical entity has no protecting physical entity. This object is not applicable should the protection be done on a per-port basis.
Status: current Access: read-only
OBJECT-TYPE    
  PhysicalIndex  

slEntPhysicalProtectState 1.3.6.1.4.1.4515.1.3.6.1.1.1.9
The protection state of physical entity. This object is not applicable should the protection be done on a per-port basis. In the case of Switch protection the following logic should be used: 1. If there is only one card is present - noProtection(3) 2. If the standby card is not ready - the active card should have the value noProtection(3), and the standby card should have the value protecting(2) 3. If the protecting card is ready - the active card should have the value working(1) and the standby card should have the value protecting(2)
Status: current Access: read-only
OBJECT-TYPE    
  INTEGER working(1), protecting(2), noProtection(3)  

slEntPhysicalProtectMode 1.3.6.1.4.1.4515.1.3.6.1.1.1.14
The protection mode of physical entity. The default value is automatic(3) This object is not applicable should the protection be done on a per-port basis.
Status: current Access: read-write
OBJECT-TYPE    
  INTEGER lock(1), force(2), automatic(3)  

slEntPhysicalStatus 1.3.6.1.4.1.4515.1.3.6.1.1.1.15
The physical entity status bitmap: 1 - Card is removed from the slot 2 - Communication Fault 4 - Major alarm inherited from the ports 8 - Card or port HW failure 16 - An internal SW failure detected 32 - SW version mismatch detected 64 - Power A Failure 128 - Power B Failure 256 - HW version mismatch detected 512 - Minor alarm inherited from the ports
Status: current Access: read-only
OBJECT-TYPE    
  INTEGER 0..1023  

slEntPhysicalFailureDescription 1.3.6.1.4.1.4515.1.3.6.1.1.1.16
Text that describes the last entity failure.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString  

slEntPhysicalAdminStatus 1.3.6.1.4.1.4515.1.3.6.1.1.1.17
The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with ifAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, ifAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state). State warmBoot(4) cause the card a Warm Start. The state coldBoot(5)has two meanings. If the card is present it means to reinitialize it with the factory defaults. This is equivalent to Cold Start. Setting the object to the value hotBoot(7) cause the card to reboot in a non service affecting manner. If the card is not present it means that the former configuration of this slot is not longer kept in the system. In this case the slot is ready for insertion of a new card of any type.
Status: current Access: read-write
OBJECT-TYPE    
  INTEGER up(1), down(2), testing(3), warmBoot(4), coldBoot(5), hotBoot(7)  

slEntPhysicalOperStatus 1.3.6.1.4.1.4515.1.3.6.1.1.1.18
The current operational state of the interface. If slEntPhysicalAdminStatus is down(2) then slEntPhysicalOperStatus should be down(2). If slEntPhysicalAdminStatus is changed to up(1) then slEntPhysicalOperStatus should change to up(1) if the interface is ready to transmit and receive network traffic It should remain in the down(2) state if and only if there is a fault that prevents it from going to the up(1) state; it should remain in the notPresent(6) state if the interface has missing (typically, hardware) components.
Status: current Access: read-only
OBJECT-TYPE    
  INTEGER up(1), down(2), testing(3), notPresent(6)  

slEntPhysicalSysUptime 1.3.6.1.4.1.4515.1.3.6.1.1.1.19
The number of timer ticks since the last reboot of the module.
Status: current Access: read-only
OBJECT-TYPE    
  TimeTicks  

slEntPhysicalType 1.3.6.1.4.1.4515.1.3.6.1.1.1.20
The type of the physical module.
Status: current Access: read-only
OBJECT-TYPE    
  PhysicalType  

slEntPhysicalCleiCode 1.3.6.1.4.1.4515.1.3.6.1.1.1.21
The Clei Code resides in the SEEP of each card.
Status: current Access: read-only
OBJECT-TYPE    
  CleiCode  

slEntPhysicalPartNumber 1.3.6.1.4.1.4515.1.3.6.1.1.1.22
The card part number. This is a string of upto 12 characters.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString Size(0..12)  

slEntPhysicalOemSerialNum 1.3.6.1.4.1.4515.1.3.6.1.1.1.23
The oem-specific serial number string for the physical entity. The preferred value is the serial number string actually printed on the component itself (if present). On the first instantiation of an physical entity, the value of slEntPhysicalSerialNum associated with that entity is set to the correct vendor-assigned serial number, if this information is available to the agent. If a serial number is unknown or non-existent, the slEntPhysicalSerialNum will be set to a zero-length string instead. Note that implementations which can correctly identify the serial numbers of all installed physical entities do not need to provide write access to the slEntPhysicalSerialNum object. Agents which cannot provide non-volatile storage for the slEntPhysicalSerialNum strings are not required to implement write access for this object. Not every physical component will have a serial number, or even need one. Physical entities for which the associated value of the slEntPhysicalIsFRU object is equal to 'false(2)' (e.g., the repeater ports within a repeater module), do not need their own unique serial number. An agent does not have to provide write access for such entities, and may return a zero-length string. If write access is implemented for an instance of slEntPhysicalSerialNum, and a value is written into the instance, the agent must retain the supplied value in the slEntPhysicalSerialNum instance associated with the same physical entity for as long as that entity remains instantiated. This includes instantiations across all re- initializations/reboots of the network management system, including those which result in a change of the physical entity's slEntPhysicalIndex value.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString Size(0..32)  

slEntPhysicalProductionDate 1.3.6.1.4.1.4515.1.3.6.1.1.1.24
The entity production date in the format YYYY-WW.
Status: current Access: read-write
OBJECT-TYPE    
  SnmpAdminString