To be more specific.
Without MIB documents, an SNMP tool can only tell the very basic data types defined by the protocol itself,
- INTEGER
- OCTET STRING
- NULL
- OBJECT IDENTIFIER
- IpAddress
- Counter32
- Gauge32
- TimeTicks
- Opaque
- NetAddress
- Counter64
Since data are encoded in ASN.1 BER, the decoding algorithm can extract such data types from raw bytes over the wire.
Thus, when you run NET-SNMP's snmpget
command without MIB documents, it merely decodes the data as OCTET STRING and prints as "ACTIVE"
.
However, MIB documents in SMI v1 or v2 allow customized data types to be defined upon such basic types via the so-called "Textual Conventions". And in your case, MIB document F5-BIGIP-SYSTEM-MIB
defines the object .1.3.6.1.4.1.3375.2.1.14.3.2
as below,
sysCmFailoverStatusStatus OBJECT-TYPE
SYNTAX LongDisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The failover status on the system."
::= { sysCmFailoverStatus 2 }
The actual data type is LongDisplayString
defined in F5-BIGIP-COMMON-MIB
,
LongDisplayString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1024a"
STATUS current
DESCRIPTION "A longer version of SNMPv2-TC::DisplayString."
SYNTAX OCTET STRING (SIZE (0..1024))
Thus, when you ask NET-SNMP snmpget
command to load MIB documents, it is fully aware of the data type of LongDisplayString
and prints ACTIVE
.
So, you see even the only observable change is just the quotes, a lot happens behind the scenes.