SL-ENTITY-MIB
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.
Main OID:
slmEntity.1.3.6.1.4.1.4515.1.3.6
25
Objects
Active
Status
5
Dependencies
Imported Objects
Objects
25 total| Object Name |
|---|
slmEntityThe 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 .1.3.6.1.4.1.4515.1.3.6 |
slEntityPhysical OBJECT IDENTIFIER .1.3.6.1.4.1.4515.1.3.6.1 |
slEntPhysicalTableThis table contains one row per physical entity. There is
always at least one row for an 'overall' physical entity. SEQUENCE OF SlEntPhysicalEntry .1.3.6.1.4.1.4515.1.3.6.1.1 |
slEntPhysicalEntryInformation about a particular physical entity. SlEntPhysicalEntry .1.3.6.1.4.1.4515.1.3.6.1.1.1 |
slEntPhysicalIndexThe Slot number of the entity.ro InterfaceIndex (IF-MIB) .1.3.6.1.4.1.4515.1.3.6.1.1.1.1 |
slEntPhysicalDescrA 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.ro SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.4515.1.3.6.1.1.1.2 |
slEntPhysicalClassAn 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.ro PhysicalClass .1.3.6.1.4.1.4515.1.3.6.1.1.1.3 |
slEntPhysicalHardwareRevThe 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.ro SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.4515.1.3.6.1.1.1.4 |
slEntPhysicalFirmwareRevThe 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.ro SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.4515.1.3.6.1.1.1.5 |
slEntPhysicalSoftwareRevThe 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.ro SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.4515.1.3.6.1.1.1.6 |
slEntPhysicalSerialNumThe 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.ro SnmpAdminString .1.3.6.1.4.1.4515.1.3.6.1.1.1.7 |
slEntPhysicalProtectionEntityThe 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.ro PhysicalIndex .1.3.6.1.4.1.4515.1.3.6.1.1.1.8 |
slEntPhysicalProtectStateThe 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)ro Enumeration .1.3.6.1.4.1.4515.1.3.6.1.1.1.9 |
slEntPhysicalProtectModeThe 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.rw Enumeration .1.3.6.1.4.1.4515.1.3.6.1.1.1.14 |
slEntPhysicalStatusThe 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 portsro INTEGER .1.3.6.1.4.1.4515.1.3.6.1.1.1.15 |
slEntPhysicalFailureDescriptionText that describes the last entity failure.ro SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.4515.1.3.6.1.1.1.16 |
slEntPhysicalAdminStatusThe 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.rw Enumeration .1.3.6.1.4.1.4515.1.3.6.1.1.1.17 |
slEntPhysicalOperStatusThe 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.ro Enumeration .1.3.6.1.4.1.4515.1.3.6.1.1.1.18 |
slEntPhysicalSysUptimeThe number of timer ticks since the last reboot of the module.ro TimeTicks (SNMPv2-SMI) .1.3.6.1.4.1.4515.1.3.6.1.1.1.19 |
slEntPhysicalTypeThe type of the physical module.ro PhysicalType .1.3.6.1.4.1.4515.1.3.6.1.1.1.20 |
slEntPhysicalCleiCodeThe Clei Code resides in the SEEP of each card.ro CleiCode .1.3.6.1.4.1.4515.1.3.6.1.1.1.21 |
slEntPhysicalPartNumberThe card part number. This is a string of upto 12 characters.ro SnmpAdminString .1.3.6.1.4.1.4515.1.3.6.1.1.1.22 |
slEntPhysicalOemSerialNumThe 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.ro SnmpAdminString .1.3.6.1.4.1.4515.1.3.6.1.1.1.23 |
slEntPhysicalProductionDateThe entity production date in the format YYYY-WW.rw SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.4515.1.3.6.1.1.1.24 |
slEntityNotification OBJECT IDENTIFIER .1.3.6.1.4.1.4515.1.3.6.2 |