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.