RFC 8038
Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol
Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol ✨
Bestie, let's start with the header 🎀
- Who wrote it: P. Aitken, Ed. (Brocade), B. Claise (Cisco Systems, Inc.), S. B S (Mojo Networks, Inc.), C. McDowall (Brocade), and J. Schoenwaelder (Jacobs University Bremen) 👑
- Published by: the Internet Engineering Task Force (IETF) 🌈
- Request for Comments: 8038 🦋
- Category: Standards Track 💜
- Date: May 2017 📅
- ISSN: 2070-1721 ⭐
- Obsoletes and updates: the header doesn't list any RFCs that this one obsoletes or updates 🧚
Abstract 🌸
okay so this document explains how to add Management Information Base (MIB) objects onto IP Flow Information Export (IPFIX) Data Records 🫶 The big win is that you don't have to invent brand new IPFIX Information Elements for MIB objects that are already fully specified. no duplicate work, periodt 💅
It also defines two IPFIX Options Templates, plus a method for building more IPFIX Options Templates. Those templates carry the extra data you need to fully describe Simple Network Management Protocol (SNMP) MIB objects inside IPFIX 🔥
Status of This Memo 📜
This is an Internet Standards Track document 💖
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has gotten public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 ✨
Info about this document's current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc8038 🍓
Copyright Notice 💅
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these documents carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶
Table of Contents 🗺️
1. Introduction ....................................................4
2. Motivation ......................................................5
3. Terminology .....................................................7
4. High-Level Solution Overview ....................................8
5. MIB Object Value Information Elements and the MIB Field
Options Template ...............................................10
5.1. MIB Field Options Architecture ............................11
5.2. IPFIX and MIB Data Model ..................................13
5.3. MIB Field Options - Specifications and Required Fields ....15
5.3.1. MIB Field Options Template .........................16
5.3.2. MIB Type Options Template ..........................16
5.4. MIB Field Options Template Formats ........................17
5.4.1. Data Template Containing a mibObjectValue Field ....17
5.4.2. MIB Field Options Template .........................19
5.4.3. MIB Field Options Data Records .....................20
5.4.4. Options Template Containing a
mibObjectValue Field ...............................21
5.4.5. MIB Field Options Template with Semantics Fields ...23
5.4.6. MIB Field Options Template with Extra MIB
Object Details .....................................24
5.5. Use of Field Order in the MIB Field Options Template ......27
5.6. Identifying the SNMP Context ..............................27
5.7. Template Management .......................................28
5.7.1. Large Messages .....................................28
5.7.2. Template Withdrawal and Reuse ......................29
5.8. Exporting Conceptual Rows and Tables ......................29
5.8.1. Exporting Conceptual Rows - Indexing ...............30
5.8.2. Exporting Conceptual Rows - mibObjectValueRow ......30
5.8.3. Exporting Conceptual Rows - AUGMENTS ...............36
5.8.4. Exporting Conceptual Tables - mibObjectValueTable ..37
5.8.5. Exporting Columnar Objects: Using
mibIndexIndicator ..................................38
6. Example Use Cases ..............................................39
6.1. Non-columnar MIB Object: Established TCP Connections ......39
6.2. Enterprise-Specific MIB Object: Detailing CPU Load
History ...................................................42
6.3. Exporting a Conceptual Row: The OSPF Neighbor Row .........45
6.4. Exporting Augmented Conceptual Row: Mapping IF-MIB
ID to Name ................................................49
6.5. Exporting a Columnar Object: ipIfStatsInForwDatagrams .....55
6.6. Exporting a Columnar Object Indexed by Information
Elements: ifOutQLen .......................................58
6.7. Exporting with Multiple Contexts: The OSPF
Neighbor Row Revisited ....................................62
7. Configuration Considerations ...................................65
8. The Collecting Process's Side ..................................66
9. Applicability ..................................................66
10. Security Considerations .......................................67
11. IANA Considerations ...........................................68
11.1. New IPFIX Semantics ......................................68
11.1.1. snmpCounter .......................................68
11.1.2. snmpGauge .........................................68
11.2. New IPFIX Information Elements ...........................69
11.2.1. New MIB Object Value Information Elements .........69
11.2.2. New MIB Field Options Information Elements ........75
11.2.3. New MIB Type Information Elements .................79
12. References ....................................................81
12.1. Normative References .....................................81
12.2. Informative References ...................................82
Acknowledgments ...................................................84
Authors' Addresses ................................................841. Introduction 🦋
okay so there's a growing crowd that wants to use IPFIX as a push mechanism for exporting management information 💜 Compare that to a polling protocol like SNMP, where the collector asks for the data. Pushing with something like IPFIX is especially appealing when big chunks of repetitive data need to go out on a regular schedule 📈
IPFIX and SNMP came from different starting points, but there's a huge overlap in what they carry 🫶 Some MIB objects are also super relevant to Flows the way we understand them today. For example, the IPFIX Information Model [IANA-IPFIX] already has Information Elements that come from the SNMP world. ingressInterface and egressInterface both point to the ifIndex object defined in [RFC2863] ✨
The Management Information Base was designed as its own separate set of definitions. That means there's a real possibility of exporting MIB objects over other protocols too 🌸
Instead of mapping MIB objects to IPFIX Information Elements one by one, it would be way better to let any existing or future MIB object be exported as part of an IPFIX Data Record 🧚 That way, you don't end up duplicating the same Data Model [RFC3444] as both SMIv2 MIB objects and IPFIX Information Elements, when both come out of the same Information Model [RFC3444] ✨ Duplicates are not it 🙅♀️
So the main goals of this document are:
- to specify a way to complement IPFIX Data Records with MIB objects 🎀
- to avoid defining new IPFIX Information Elements for existing MIB objects that are already fully specified 💅
- to allow the correlation of SNMP and IPFIX sourced data by exporting them together 🔗
- to allow SNMP push data from SNMP-only devices to be more easily integrated into IPFIX-based collection infrastructures 🌈
More parts are coming, so stay tuned 🥹✨
2. Motivation 💅
okay so the whole point here is adding MIB variables into IPFIX Information Elements inside Data Records 🎀 so the records come with extra info that's already standardized 🧠. the special focus is when a Template Record already exists and needs MIB variables tacked on, but its index is already sitting in that Template Record as an IPFIX Information Element. like, picture a 7-tuple Data Record with an ingressInterface, which then gets interface counters from [RFC2863] indexed by the ingressInterface values already in the records. see Section 3 for the terminology defs 📚
Lots of Data Records have an ingressInterface and/or an egressInterface. those Information Elements carry an ifIndex value, which is a MIB object defined in [RFC2863]. so to get more deets about the interface, a Collector could just poll the relevant objects from the device running the Exporter over SNMP 🤔 but that approach is kinda messy, bestie:
- it needs a mediation function between two Data Models, MIB objects and IPFIX Information Elements 😵💫
- checking that simple mappings (like ifIndex to ifName) are still valid means either regularly checking that the Exporter's network management system didn't reload, or forcing ifIndex persistence across an Exporter's reload 🙃
- synchronization problems 💀: counters in Data Records and counters in SNMP messages get pulled from the Exporter at different points in time, so they can't be correlated. in the best case, with a super tight integration of an IPFIX Collector and an SNMP polling engine, the SNMP data gets retrieved shortly after the Data Records arrive. that still means a delay of the sum of the active or idle timeouts (if not null) plus the time to export the Data Record to the Collector. and if the SNMP data is pulled by a generic Network Management Station (NMS) polling interface statistics, the time lag between IPFIX counters and SNMP counters can be way higher. see [RFC5102] for the details on active and idle timeouts ⏰
This document does not specify how to carry SNMP notifications in IPFIX 🙅♀️, even though the specs in here could potentially allow it.
Since IPFIX is a push mechanism, started from the Exporter with no acknowledgment method, this specification does not give you the ability to execute configuration changes 🚫⚙️.
The Distributed Management Expression MIB [RFC2982] is a mechanism for creating new MIB variables based on the content of existing ones, and it could also be a big help here 🙌. newly created MIB objects (like a link utilization MIB variable) made with the Distributed Management Expression MIB [RFC2982] could nicely complement Data Records 💖.
exporting MIB objects over IPFIX has another perk: IPFIX gets an extended series of types to export 🌈. the simple and application-wide data types from SMIv2 [RFC2578], along with new textual conventions, can be exported within IPFIX and then decoded in the Collector. but since a textual convention can contain almost any name, this document does not extend the existing "IPFIX Information Elements" subregistry [IANA-IPFIX] that contains informationElementDataType 🫶.
Here's the overall architectural model, shown in Figure 1 ✨. the IPFIX Exporter accesses the device's instrumentation, which follows the specs in MIB modules. other management interfaces, like the Network Configuration Protocol (NETCONF) or the device's Command Line Interface (CLI), may also get access to the same instrumentation 🧚.
+------+ +-------+ +.........+ +.....+
| SNMP | | IPFIX | : NETCONF : : CLI :
+------+ +-------+ +.........+ +.....+
| | | |
+--------------------------------------------+
| Instrumentation (specified in MIB modules) |
+--------------------------------------------+
Figure 1: Architectural Model3. Terminology 📖
okay the IPFIX-specific terms (Information Element, Template, Template Record, Options Template Record, Template Set, Collector, Exporter, Data Record, Transport Session, Exporting Process, Collecting Process, etc.) are all defined in Section 2 of [RFC7011] 🎀. like in [RFC7011], these IPFIX-specific terms have the first letter of each word capitalized 🔠.
this document prefers the more generic term "Data Record" (instead of "Flow Record") when talking about exporting MIB objects 💅.
Object Identifier (MIB OID)
An Object Identifier value is an ordered list of non-negative numbers 🔢. for SMIv2, each number in the list is called a sub-identifier. there are at most 128 sub-identifiers in a value, and each sub-identifier has a max value of 2^32 - 1 (4294967295 decimal). see Section 3.5 of [RFC2578] 📚.
MIB Object Identifier Information Element
an IPFIX Information Element ("mibObjectIdentifier") that shows a MIB Object Identifier (MIB OID) is exported in the (Options) Data Record. see Section 11.2.2.1 🧩.
SMIv2 Terminology
the key words "MIB module", "MIB object", "INDEX", "AUGMENTS", "textual convention", "columnar object", "conceptual row", and "conceptual table" in this document are to be interpreted as described in SMIv2 [RFC2578] 🧠.
SMIv2 SYNTAX
the SYNTAX key words "INTEGER", "Integer32", "OCTET STRING", "OBJECT IDENTIFIER", "BITS", "IpAddress", "Counter32", "Gauge32", "TimeTicks", "Opaque", "Counter64", "Unsigned32", "SEQUENCE", and "SEQUENCE OF" in this document are to be interpreted as described in SMIv2 [RFC2578] 🌸.
SNMP Context Terminology
the key words "snmpEngineID", "contextEngineID", and "contextName" in this document are to be interpreted as described in [RFC3411] 🦋.
mibObjectValue Information Elements
"mibObjectValue Information Elements" refers to any and all of the mibObjectValue Information Elements generically 🫧. any restriction or requirement in this document that mentions "mibObjectValue" applies to the following Information Elements as defined in Section 11.2.1: mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBits, mibObjectValueIPAddress, mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTimeTicks, mibObjectValueUnsigned, mibObjectValueTable, and mibObjectValueRow 💜.
Abstract Data Type
Abstract Data Types for IPFIX are defined in Section 3.1 of [RFC7012] 🍓. this specification uses the Abstract Data Types "unsigned8", "unsigned32", "unsigned64", "signed32", "octetArray", "string", "ipv4Address", and "subTemplateList" ✨.
IE
shorthand for "Information Element" [RFC7011], used in the figures 🎀.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 👑.
4. High-Level Solution Overview ✨
this document lays out a method for creating IPFIX Options Templates, which are used to export the extra data needed to describe MIB variables (see Section 5.1) 🧁.
this lets IPFIX Templates hold any combination of fields defined by traditional IPFIX Information Element(s) and/or MIB Object Identifier(s) 🌷. the MIB Object Identifiers can reference either non-columnar or columnar MIB object(s). enterprise-specific MIB Object Identifiers are supported too 💅.
this document also defines two standard IPFIX Options Templates (see Section 5.3) that are part of the mechanism for exporting MIB object metadata 🫶:
- MIB Field Options Template (Section 5.3.1)
- MIB Type Options Template (Section 5.3.2)
this document defines three classes of new IPFIX Information Elements 🌈. they're used to export values from the MIB, export required Object Identifier information, and optionally export type data from a MIB module:
- MIB Object Value Information Elements (Section 11.2.1)
- MIB Field Options Information Elements (Section 11.2.2)
- MIB Type Information Elements (Section 11.2.3)
and this document defines two new IPFIX semantics that the new Information Elements need 🔥:
- snmpCounter (Section 11.1.1)
- snmpGauge (Section 11.1.2)
two common types from SMIv2 are conceptual rows and conceptual tables 🍰. it's desirable for exporting a complete or partial conceptual row to be simple and efficient 💖. that's done by using IPFIX Structured Data [RFC6313] to cut down on repeating Object Identifier and indexing data 🧚.
to let you use individual columnar objects that make up a conceptual row, there's also a method for saying that a MIB object is indexed by other fields in the same Data Flow 🔍. for an individually indexed mibObjectValue, the index fields are sent the same way as any of the other fields in the same Data Record, and they may be mibObjectValue Information Element(s) or other existing Information Element(s) 🎀.
also, in some cases Exporters may not want (or be able) to export the full info on how the MIB objects being exported are indexed 🤷♀️. this could be because the MIB object is only being used as type information, or because the Exporting Process may not know the indexing required. so providing index information for columnar objects is optional 💫.
5. MIB Object Value Information Elements and the MIB Field Options Template ✨
Okay bestie, this section is where the magic happens 🔮. This doc defines new mibObjectValue Information Elements (check Section 11.2.1 🫶). They're how MIB objects get exported as part of standard IPFIX Templates, and they carry the actual data values 💖.
The Metering Process or Exporting Process can grab those data values from a Process on the same device, or capture or create the data needed to match the MIB object's definition 🧚. Here's the lowkey important bit: exporting a value of a MIB object from some MIB module does not mean the SNMP process on that device supports that MIB module 🙈.
The main problem with exporting MIB object values in IPFIX is that MIB Object Identifiers don't fit into the standard IPFIX Template format [RFC7011]. That format only gives you a 16-bit Information Element identifier 💀.
You could export the values using a MIB-specific Information Element and skip the Object Identifiers entirely. But without the actual MIB OID, nobody knows the full type of the data, and every field holding MIB data would look exactly the same 😭. If the Collector doesn't know which OID each field maps to, the data is basically gibberish to it 🌀.
So the mibObjectValue Information Elements need extra meta-information sent along with the IPFIX export to make sense. The minimum info needed to understand each exported field is in Section 5.3.1 🎀.
One way to fix this would be to extend IPFIX so Field Specifiers can be extended and metadata about fields can live in Data Templates. Honest tea though, that would need a new version of IPFIX that might not be backward compatible 🙃. Future IPFIX versions might export the required MIB metadata as part of newly defined IPFIX Set versions instead ✨.
This document defines a MIB Field Options Template to export that extra meta-information. It's a standard IPFIX Options Template Set with a minimum set of required fields (see Section 5.3.1), and it may include extra fields for more meta-information about one of the mibObjectValue Information Elements 🦋.
The MIB Field Options export tells the Collecting Process the OID for the MIB object type definition for the following (Template, field) combo 💜.
5.1. MIB Field Options Architecture
Four IPFIX Sets work together to export a Flow that contains mibObjectValue Information Elements 🌈. They are:
- A Template Set that includes the mibObjectValue Information Element. This tells the Collector that a MIB object value of length N is coming. This Set may also be an Options Template Set.
- A MIB Field Options Template Set. The MIB Field Options Template describes which metadata gets sent for each mibObjectValue Information Element being exported 📋.
- A MIB Field Options Data Set. This includes the metadata for each MIB object (that's the mibObjectIdentifier or mibSubIdentifier). The metadata about the mibObjectValue Information Elements only needs to be resent as part of normal Template refreshes or resends 🔁.
- A Data Set. This one holds only the actual data pulled from the MIB or described by the MIB module 💅.
Figure 2 shows the IPFIX Message structure for a MIB field in a Template Set 👀.
+-------------------------------------------------------+
| IPFIX Message Header |
+-------------------------------------------------------+
| Template Set (A) |
+-------------------------------------------------------+
| Options Template Set (B) (MIB Field Options Template) |
+-------------------------------------------------------+
| Data Set (B) (MIB Field Options Data) |
+-------------------------------------------------------+
| Data Set (A) |
+-------------------------------------------------------+
Figure 2: IPFIX Message Structure for a MIB Field in a Template SetThe MIB Field Options Template defines MIB Field Options Data Records 🧩. Those records annotate the Data Template with mibObjectValue metadata. Together, the Data Template and the MIB Field Options Data Records define the Data Records that will be exported 💖.
The Data Records (A) depend on the two Templates and the MIB Field Options Data Records 🔗.
More Data Sets that use the same mibObjectValue Information Element can be sent in later packets 🚀.
Figure 3 shows how all these Sets relate to each other 🌸.
+------------------------------+
|MIB Field Options Template (B)|
+------------------------------+
|(templateId, elementIndex) |
+------------------------------+
| mibOID |
+------------------------------+
|
| Defines
V
+------------------------+ +--------------------------+
| Data Template (A) | |MIB Field Options Data (B)|
+------------------------+ +--------------------------+
|Field 0 - regular IE | | |
+------------------------+ +--------------------------+
|Field 1-mibObjectValue | <----------- | (X,1) = OID |
+------------------------+ Annotates +--------------------------+
|Field 2-mibObjectValue | <----------- | (X,2) = OID |
+------------------------+ +--------------------------+
| |
|------------------------------------/
|
| Defines
|
V
+------------------------+
| Data Records (A) |
|------------------------|
| Field 0 data |
+------------------------+
| Field 1 data |
+------------------------+
| Field 2 data |
+------------------------+
Figure 3: Relationships between Sets5.2. IPFIX and MIB Data Model
Okay, so [RFC2578], Section 7.1 says the SYNTAX clause for a MIB object defines the object's abstract data structure and what it has to contain 📚:
"The data structure must be one of the following: a base type, BITS, or a textual convention. (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, see section 7.1.12)."
This document specifies exactly which mibObjectValue Information Element to use for each of the SYNTAX clause options 🎯.
If the MIB object you're exporting is a textual convention, you have to check its definition and use the SYNTAX clause to find the right base type 🔍. This can recurse if the textual convention is defined in terms of another textual convention, but it should end at a base type 🌀.
If the SYNTAX clause has a textual convention or sub-typing (like integerSubType or octetStringSubType) [RFC2578], the mibObjectSyntax Information Element SHOULD be used to export that detail to the Collecting Process ✨.
The SYNTAX clause options map like this 🗺️:
+-------------+-------------------+---------------------------------+
| Section in | SYNTAX | mibObjectValue Information |
| RFC 2578 | | Element |
+-------------+-------------------+---------------------------------+
| 7.1.1 | INTEGER/Integer32 | mibObjectValueInteger |
| 7.1.2 | OCTET STRING | mibObjectValueOctetString |
| 7.1.3 | OBJECT IDENTIFIER | mibObjectValueOID |
| 7.1.4 | BITS | mibObjectValueBits |
| 7.1.5 | IpAddress | mibObjectValueIPAddress |
| 7.1.6 | Counter32 | mibObjectValueCounter |
| 7.1.7 | Gauge32 | mibObjectValueGauge |
| 7.1.8 | TimeTicks | mibObjectValueTimeTicks |
| 7.1.9 | Opaque | mibObjectValueOctetString |
| 7.1.10 | Counter64 | mibObjectValueCounter |
| 7.1.11 | Unsigned32 | mibObjectValueUnsigned |
| 7.1.12 | SEQUENCE | mibObjectValueRow |
| 7.1.12 | SEQUENCE OF | mibObjectValueTable |
+-------------+-------------------+---------------------------------+
Table 1: SMIv2 SYNTAX to mibObjectValue TypesValues are encoded using the standard IPFIX encoding of Abstract Data Types 🫧. The only new encoding reference in this doc is that Object Identifiers (OIDs) get encoded as per ASN.1/BER [X.690] in an octetArray 🧁.
The mibObjectValue and mibObjectIdentifier Information Elements are standard IPFIX fields 💅. So the E bit of those Information Elements is set to 0 🔢.
The MIB object being exported might be defined in an enterprise-specific MIB module, but the Information Elements defined here still get exported with the E bit set to 0 💜. The OID being exported is what shows the object came from an enterprise-specific MIB module 🌈.
5.3. MIB Field Options - Specifications and Required Fields
For each mibObjectValue Information Element defined in an IPFIX Template, a MIB Field Options Data Record gets exported 📦. It provides the required minimum info to define the MIB object being exported (see Section 5.3.1).
The MIB Field Options Data Records are defined in a Template that this document calls a MIB Field Options Template, using the format in Section 5.4 🧾.
The MIB Field Options Template and the MIB Field Options Data Records MUST be exported in the same IPFIX Message as any Template using a mibObjectValue Information Element 🚨. Heads up, this puts an implicit size constraint on the export 👀.
The whole set of Templates and MIB Field Options Data Records MUST all be exported before the Data Records that depend on them 🫶. So the export order MUST be:
- Data Template for mibObjectValue Information Elements (Set ID 2)
- MIB Field Options Template (Set ID 3)
- MIB Field Options Data Records (Set ID >= 256)
- MIB Object Value Data Records (Set ID >= 256)
Note that the ID of an identical MIB Field Options Template that has already been exported MAY be reused without exporting the Template again ♻️.
IPFIX Set IDs are defined in Section 3.3.2 of [RFC7011] 🆔. A value of 2 means a Template Set, a value of 3 means an Options Template Set, and values 256 and above mean Data Sets 💖.
5.3.1. MIB Field Options Template ✨
okay bestie, so three fields are REQUIRED to unambiguously export a standalone mibObjectValue Information Element with a MIB Field Options Template 🎀
- (scope)
templateId[IANA-IPFIX] - (scope)
informationElementIndex[IANA-IPFIX] mibObjectIdentifier(Section 11.2.2.1) ormibSubIdentifier(Section 11.2.2.2)
these are the minimum fields required in a MIB Field Options Template (see Section 5.4.2) 💅
the mibObjectIdentifier gives the OID for all the mibObjectValue Information Elements being exported, except when IPFIX Structured Data [RFC6313] is being used to export a conceptual row (see Section 5.8.2) 🦋
the next ones are optional, but they are nevertheless RECOMMENDED in certain circumstances, as described in the referenced sections 🌸
mibCaptureTimeSemantics(discussed in Section 5.4.5; Information Element defined in Section 11.2.2.4)mibIndexIndicator(discussed in Section 5.8.5; Information Element defined in Section 11.2.2.3)mibContextEngineID(discussed in Section 5.6; Information Element defined in Section 11.2.2.5)mibContextName(discussed in Section 5.6; Information Element defined in Section 11.2.2.6)
5.3.2. MIB Type Options Template 🧚
there are also fields that carry type information from a MIB object definition, and these MAY be exported to a Collecting Process 💜
type info is statically defined in a MIB module and it's not expected to change. but the extra info about the MIB object can really help a Collecting Process that doesn't have access to the MIB module 🙈
so to export a MIB Type Options Template, the mibObjectIdentifier is RECOMMENDED as a Scope Field so that it matches the MIB Field Options Template. any combination of the other MIB Type fields may be included 🍓
- (scope)
mibObjectIdentifier(see Section 11.2.2.1) mibObjectName(see Section 11.2.3.1)mibObjectDescription(see Section 11.2.3.2)mibObjectSyntax(see Section 11.2.3.3)mibModuleName(see Section 11.2.3.4)
5.4. MIB Field Options Template Formats 🌈
5.4.1. Data Template Containing a mibObjectValue Field 🎀
the Template Record format for a Template that uses a mibObjectValue Information Element is identical to the standard IPFIX format defined in [RFC7011]. so a field using a mibObjectValue Information Element is specified with standard IPFIX Field Specifiers per [RFC7011] 🫶
the only extra thing a Template Record with one or more mibObjectValue Information Elements needs is that it MUST export the required metadata from Section 5.3.1 for EACH mibObjectValue Information Element 🔥
if multiple MIB Field Options Data Records that refer to a mibObjectValue are received, the latest MUST be used. this matches the expected behavior of IPFIX Templates 💖
there's a one-to-one mapping between each mibObjectValue Information Element and a MIB Field Options Data Record ✨
a MIB Field Options Template and its corresponding Data Record MUST be exported to provide the minimum required metadata 👑
Figure 4 shows an IPFIX Template Set using a mibObjectValue Information Element 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = Existing IPFIX Field | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = <mibObjectValue> | Field Length (MIB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: IPFIX Template Set Using mibObjectValue Information Element
where:
<mibObjectValue>
this is one of the mibObjectValue IPFIX Information Elements that says MIB object data (i.e., the value of a MIB object) will be exported in the (Options) Data Record 🌸
it could be any one of the mibObjectValue Information Elements defined in Section 11.2.1: mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBits, mibObjectValueIPAddress, mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTimeTicks, mibObjectValueUnsigned, mibObjectValueTable, and mibObjectValueRow 🧚
when a mibObjectValue Information Element is used, the MIB Object Identifier ("mibObjectIdentifier") MUST be exported via a MIB Field Options Template and MIB Field Options Data Record. see Section 5.3.1 💅
Field Length (MIB)
this is the length of the encoded MIB object data in the corresponding Data Records, in octets. see [RFC7011] for a detailed definition. the Field Length can be expressed using reduced-size encoding per [RFC7011], and it may be encoded using variable-length encoding per [RFC7011] 🦋
5.4.2. MIB Field Options Template 🌈
the MIB Field Options Template is a standard Options Template that defines the fields to be exported so the Collector has enough metadata about a mibObjectValue Information Element to tie the data values back to the definition of the MIB object. it's giving detective energy 🕵️♀️💜
all MIB Field Options Templates contain the fields specified in Section 5.3.1 🎀
Figure 5 shows the required fields for exporting a mibObjectIdentifier in the MIB Field Options Template format 🫶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: MIB Field Options Template Format - Required Fields
where:
templateId
this is the first Scope Field, an IPFIX Information Element that says a Template Identifier will be exported as part of the MIB Field Options Data Record. this Template Identifier, paired with an index into that Template (the "informationElementIndex" field), uniquely references one mibObjectValue Information Element being exported 🌸
informationElementIndex
this is the second Scope Field, an IPFIX Information Element that denotes a zero-based index into the fields defined by a Template. when paired with a "templateId", it uniquely references one mibObjectValue Information Element being exported 💖
mibObjectIdentifier
this is an IPFIX Information Element that denotes the MIB Object Identifier for the mibObjectValue Information Element exported in the (Options) Template Record 🧚
when a MIB Object Value Information Element is used, the MIB Object Identifier MUST be specified in the MIB Field Options Template Record or specified by other means 🔥
the Object Identifier is encoded in the IPFIX Data Record in ASN.1/BER [X.690] format 🦋
variable-length encoding SHOULD be used with the mibObjectIdentifier so that multiple MIB OIDs of different lengths can be exported efficiently. this also allows reuse of the MIB Field Options Template ✨
variable-length encoding is indicated by the Field Length value of 65535, per Sections 3.2 and 7 of [RFC7011]. the RECOMMENDED use of variable-length encoding for mibObjectIdentifier fields is indicated in the subsequent figures by placing 65535 in the relevant length fields 👑
5.4.3. MIB Field Options Data Records 💅
MIB Field Options Data Records conform to the Template Specification in the MIB Field Options Template. there may be multiple MIB Field Options Data Records exported 🍓
the Collecting Process MUST store all received MIB Field Options Data information for the duration of each Transport Session, because it will need that extra meta-information to fully decode each mibObjectValue Information Element 😭
Figure 6 shows the format of the exported MIB Field Options Data Record, detailing the metadata that will be exported to match the Template in Figure 5 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | Length = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier (continued) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier (continued) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Format of MIB Field Options Data Record
VLEN contains the variable length of the mibObjectIdentifier per Section 7 of [RFC7011] 🧚
5.4.4. Options Template Containing a mibObjectValue Field ✨
okay bestie, so the Options Template Record format for a Template that uses a mibObjectValue Information Element is literally identical to the standard format in [RFC7011] 💅 no new format to learn, yay! The mibObjectValue Information Element is specified with standard Field Specifiers per [RFC7011] 🎀
A mibObjectValue Information Element can be either a Scope Field or a non-Scope Field in an Options Template Record 🦋
The only extra requirement on an Options Template Record using one or more mibObjectValue Information Elements is that it MUST export the required metadata specified in Section 5.3.1 for EACH mibObjectValue Information Element. this is the main rule, so don't skip it 😭
An IPFIX Options Template Record MUST export a MIB Field Options Template and Data Record to provide the minimum required metadata for each mibObjectValue Information Element 🫶
Figure 7 shows an IPFIX Options Template Set using an existing IPFIX field as a Scope Field and with a mibObjectValueInteger Information Element as a non-Scope Field, while Figure 8 shows an IPFIX Options Template Set using a mibObjectValueInteger Information Element as a Scope Field with an existing IPFIX field as a non-Scope Field. these two are mirror images of each other, iconic 🪞
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = Existing IPFIX Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IPFIX Options Template Set Using a Non-Scope
mibObjectValueInteger Field
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = Existing IPFIX Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IPFIX Options Template Set Using a Scope
mibObjectValueInteger Field5.4.5. MIB Field Options Template with Semantics Fields 🌈
A MIB Field Options Template MAY specify that extra Information Elements will be exported to record how the mibObjectValue was collected 📝
Alternatively, one of the existing IPFIX observationTime* elements [IANA-IPFIX] may be exported to specify exactly when the value was collected ⏰
Figure 9 shows the MIB Field Options Template for a non-columnar field with Semantic Data 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibCaptureTimeSemantics|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: MIB Field Options Template for a Non-columnar Field
with Semantic DataWhere:
mibObjectIdentifier- Note the use of variable-length encoding for this field. 🧐
mibCaptureTimeSemantics- The MIB Capture Time Semantics IPFIX Information Element, as defined in Section 11.2.2.4.
- It is RECOMMENDED to include this field when exporting a mibObjectValue Information Element that specifies counters or statistics, particularly for situations with long-lived Flows. this one is a big deal for long-running stuff 👑
5.4.6. MIB Field Options Template with Extra MIB Object Details 🧚
The OID exported within the mibObjectIdentifier IPFIX Information Element provides an OID reference to a MIB object type definition that will fully describe the MIB object data being exported 🔍
However, an Exporting Process MAY decide to include some extra fields to more fully describe the MIB object that is being exported with a mibObjectValue Information Element 🌸
This can be helpful if the Collecting Process may not have access to the MIB module 🙈
The Exporting Process can either include the fields with extra object details as part of the MIB Field Options Template or export a separate Options Template and a Data Record that maps MIB OIDs in mibObjectIdentifier fields to the object details. Two valid routes, pick your fighter 🥊
If only a few fields are being exported, then including extra type data in the MIB Field Options export will be more efficient ✨
The MIB Field Options Template for a non-columnar field with extra MIB object details is shown in Figure 10 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 38 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectSyntax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectName |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectDescription |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibModuleName |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: MIB Field Options Template for a Non-columnar Field
with Extra MIB Object DetailsWhere:
mibObjectSyntax- The MIB object syntax string as defined in Section 11.2.3.3.
- Note that a separate mibObjectSyntax Information Element is required (rather than extend the existing "IPFIX Information Elements" subregistry [IANA-IPFIX] that contains informationElementDataType) because the SYNTAX clause could contain almost any name. 🤓
mibObjectName- The textual name of a mibObjectIdentifier object.
mibObjectDescription- The textual description for a mibObjectIdentifier.
mibModuleName- The textual name of the MIB module that defines a MIB object.
Note the use of variable-length encoding for the mibObjectIdentifier, mibObjectSyntax, mibObjectName, mibObjectDescription, and mibModuleName, since these are all string fields. Strings, strings everywhere 🧶
The MIB details can be exported in Data Records specified using a regular IPFIX Options Template Record [RFC7011], as shown in Figure 11. This may be more efficient, as the bulk of this data is text based and SHOULD be exported only once to the Collecting Process if there are many MIB objects being exported. This prevents this large textual data from being included for every use of a mibObjectValue Information Element. no repeating the big text blob over and over, that's the whole vibe 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectSyntax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectName |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectDescription |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibModuleName |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Alternative mibObjectIdentifier Options Template Set
with Object Details5.5. Use of Field Order in the MIB Field Options Template ✨
okay so the MIB Field Options Template export uses the informationElementIndex [IANA-IPFIX] to say which field in the Template the metadata is about 🎯 which means the Data Template doesn't have to worry about ordering 🙌 The mibObjectValue Information Elements in an IPFIX export can show up in any order in the export packet 💅 BUT fields used as an INDEX MUST be in the same order as the INDEX clause of the conceptual row MIB object 😤
The informationElementIndex tells you which field in the Template the extra info is for 💖
this is giving standard IPFIX Template Sets vibes 🦋 those also tell you the order of the fields and give their type and size 🌸
if the Template changes so the order is different, the MIB Field Options Data MUST be resent to match the new ordering 📨 and a new Template ID MUST be used to show the ordering changed 🔁 older MIB Field Options Data may point at the wrong field, so keep that in mind 🙈
a templateId [IANA-IPFIX] is only locally unique within a combo of an Observation Domain and Transport Session 🧚 so each MIB Field Options Data Record can only refer to templateIds in the same Observation Domain and session 🎀
5.6. Identifying the SNMP Context 🌈
each MIB OID gets looked up in a specific context, usually the default context 🏠 if you're exporting a MIB OID value that isn't in the default context, the context MUST be identified by including the mibContextEngineID (see Section 11.2.2.5) and mibContextName (see Section 11.2.2.6) fields in the MIB Field Options Template and the associated MIB Field Options Data Records, or be included in the same Template as the mibObjectValue field 📦
this context data MUST be included for each field that is not in the default context 🫶
the context info MAY be exported as part of the Template that includes the mibObjectValue Information Element, or the context info MAY be exported in the MIB Field Options Data Record that refers to the field 💜 context fields exported in the same Template MUST take precedence over the ones that refer to the Template 👑 context fields MUST apply to all mibObjectValue Information Elements in the same Template, and there MUST NOT be duplicates of mibContextName or mibContextEngineID in a Template 🙅♀️
so a MIB Field Options Template MAY specify no context information, just the context engine ID, or both the context engine and context name 🍓 this lets the Exporter send the bulk of the data in the default context and only tag the items that need it ✨
since the MIB Field Options Template applies to all the Data Records of a Template, using context fields in the MIB Field Options Data Template means each mibContextEngineID / mibContextName pair needs its own Template 🧩
5.7. Template Management 🗂️
Templates are managed as per Section 8 of [RFC7011], with an extra constraint: the MIB Field Options Template and MIB Field Options Data Records MUST be exported in the same IPFIX Message as any (Options) Template Record that uses a mibObjectValue Information Element 📬
when exporting over a Stream Control Transmission Protocol (SCTP) transport [RFC4960], the MIB Field Options Data Records MUST be exported reliably and in the same SCTP stream as their associated Templates per [RFC6526] 🌊
if a Template using a mibObjectValue Information Element gets resent for any reason, the Data Records it depends on MUST be sent as well 🔄
if a Template is replaced with a new (Options) Template, then a new MIB Field Options Data Record MUST be sent with the replacement, referencing the new Template ID 🆕
an Exporting Process SHOULD reuse MIB Field Options Template IDs when the Templates are identical ♻️ each (Options) Template Record MUST still be accompanied by a copy of the MIB Field Options Template 💅
5.7.1. Large Messages 🐘
the requirement to export the MIB Field Options Template and MIB Field Options Data Records in the same IPFIX Message as any (Options) Template Record that uses a mibObjectValue Information Element may result in very large IPFIX Messages 😭
in environments with restricted Message sizes, and only when a reliable SCTP transport is being used, the MIB Field Options Template, MIB Field Options Data, Data Template, and Data Records MAY be exported in separate Messages in the same SCTP stream, as long as their order is maintained 🦢
5.7.2. Template Withdrawal and Reuse 🚫
Data Records containing mibObjectValue Information Elements MUST NOT be exported if their corresponding Data Template or MIB Field Options Template has been withdrawn 🙅♀️ that's because the MIB Field Options Template MUST be exported in the same IPFIX Message as the Data Template it annotates, except as allowed by the caveat in Section 5.7.1 💀
MIB Field Options Template IDs MUST NOT be reused while they are required by any existing Data Templates 🔒
5.8. Exporting Conceptual Rows and Tables 🧁
there are three approaches for an IPFIX Exporting Process to export the values of columnar objects 👀
- Ignoring the indexing of columnar objects
- Exporting conceptual rows / table objects using IPFIX Structured Data [RFC6313]
- Exporting individual indexed columnar objects
first up, a subordinate columnar object may be used purely as a data type 🧸 in this case there's no index info or relation to a conceptual row object provided by the Exporting Process 🫠
second, mibObjectValueRow or mibObjectValueTable can export partial or complete conceptual rows, using IPFIX Structured Data [RFC6313] 🌟
third, in a mixed option/data IPFIX/MIB Template, the mibObjectValue Information Element can have the values of the INDEX clause of the conceptual row provided by other fields in the Data Record 🧩 in this case, each mibObjectValue Information Element must specify which other field(s) in the Template are providing the index information 💫
5.8.1. Exporting Conceptual Rows - Indexing 🔍
this document defines two forms of indexing that can be used for conceptual row MIB objects 🦋
indexing based on IPFIX Structured Data [RFC6313] is used solely by the mibObjectValueRow Information Element 💖 each conceptual row of the MIB object corresponds to a single Data Record exported 📝 the index fields defined in the INDEX clause of the MIB object MUST all be present in the same order as the Scope Fields 🎯 this allows a simple table export of a conceptual row MIB object without any extra fields needed to show which fields make up the conceptual row INDEX ✨
field-based indexing is used by giving each mibObjectValue Information Element a mibIndexIndicator to flag the required index fields 🚩 this allows complex indexing, or mixing of existing IPFIX Information Elements with MIB fields, with minimum overhead 🪶 it also allows multiple columnar MIB objects from different conceptual rows to be exported with complete indexing in one IPFIX Template 🌈
5.8.2. Exporting Conceptual Rows - mibObjectValueRow 💎
the simplest approach to exporting a complete or partial conceptual row object is the mibObjectValueRow Information Element 👑
this is an IPFIX Structured Data subTemplateList Information Element as detailed in [RFC6313] 🎀 the Template specified MUST be an Options Template 🙌 it also MUST have the fields specified in the INDEX clause of the conceptual row object as the Scope Fields in the MIB Field Options Template and Data Set 📋
Figure 12 gives an overview of this architecture 🗺️ it shows that the full MIB object type definition OID is exported for the mibObjectValueRow conceptual row field, but the individual columnar objects only need the sub-identifier exported 🧠 to keep the diagram clearer, the Templates for the MIB Field Options Templates aren't shown 🫧
+---------------------------+ +------------------------+
| Data Template | | MIB Field Options Data |
| | | |
| mibObjectValueRow |<---| OID |
+---------------------------+ +------------------------+
|
| +-----------------------+ +------------------------+
| | Options Template | | MIB Field Options Data |
| | | | |
| | Scope mibObjectValue* |<---| mibSubIdentifier |
| | mibObjectValue* |<---| mibSubIdentifier |
| +-----------------------+ +------------------------+
| |
V V
+---------------------------+
| Data Flows |
| |
| subTemplateList (1 entry) |
+---------------------------+
Figure 12: Architecture for Exporting Conceptual Rows
with mibObjectValueRowthe mibIndexIndicator isn't required for each individual mibObjectValue Information Element, because mibObjectValueRow already provides a structure that includes the index details 🙆♀️
when indexing based on IPFIX Structured Data [RFC6313] is used, all Scope Fields MUST be the INDEX objects, in the same order as defined in the INDEX clause of the conceptual row being exported 🔢
each conceptual table MIB object has two related OIDs 👯 there's an OID that refers to the table with the syntax of SEQUENCE OF, and an OID that refers to each entry, or conceptual row, with the syntax of SEQUENCE 🧾 the OID for the SEQUENCE of a conceptual row MUST be exported 💅
for example, in the IF-MIB [RFC2863], the OID for ifEntry should be exported rather than the OID for ifTable 🌷 the OID for the table (in this case, ifTable) can be derived by removing one sub-identifier from the ifEntry OID 🪄
the full OID for the conceptual row MIB object type definition being exported with the mibObjectValueRow Information Element MUST be exported 🫶 however, the fields that are members of the conceptual row don't need the full OID of their MIB object type definition exported 🙃 instead, the mibSubIdentifier Information Element can be used to document which entry in the conceptual row the field is 🍬
in this case, the exported Flow will contain a single complete or partial row from a table inside a single field of the Data Record 💜
there may be MIB objects that are specified in the INDEX of the conceptual row but aren't columnar objects of the same conceptual row 🤔 for these, the Exporter MUST provide the full OID in a mibObjectIdentifier field 🧚
so, for a conceptual row object with the OID 1.2.3.4.5.6, the OIDs of the type definitions for columnar objects 1.2.3.4.5.6.1 and 1.2.3.4.5.6.2 can be exported with just a mibSubIdentifier of 1 and 2, respectively 🦋
the mibObjectValue Information Elements exported using the mibObjectValueRow export MUST all either be objects defined in the INDEX clause, columnar objects of the same conceptual row object, or columnar objects that augment the same conceptual row 🍓
the IPFIX Structured Data [RFC6313] subTemplateList format requires the Structured Data Type Semantics to be specified 🎀 unless there's a more appropriate option in the "IPFIX Structured Data Types Semantics" subregistry [IANA-IPFIX], the "undefined" Structured Data Type Semantics can be used 🌈
Okay bestie, we're picking up right where 5.8.2 left off, so let's get into the templates 🎀✨
Figure 13 is an IPFIX Template for an IPFIX Structured Data [RFC6313] export of a conceptual row. Figure 14 is an IPFIX Options Template for a complete conceptual row with five columns and two index fields. Figure 15 is the MIB Field Options Template for a conceptual row field, and Figure 16 is the MIB Field Options Template for the columns inside the conceptual row. Figure 17 is the OID Data for the conceptual row that gets exported 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 300 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueRow | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPFIX Template for a Conceptual Row 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 301 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = mibObjectValue INDEX1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValue INDEX2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValue COLUMN3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValue COLUMN4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValue COLUMN5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: IPFIX Options Template for a mibObjectValueRow
with Five Columns and Two Index Fields 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 302 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: MIB Field Options Template for a Conceptual Row ObjectWhere:
templateId: The templateId for the MIB option that will be exported.mibObjectIdentifier: The MIB OID for the conceptual row that is being exported. Note the use of variable-length encoding for this field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 303 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: MIB Field Options Template for Columnar Objects
of a Conceptual TableWhere:
templateId: The templateId used will be for the Template referred to in the subTemplateList of the mibObjectValueRow that will be exported.mibSubIdentifier: The sub-identifier that specifies the columnar object's ID within the conceptual row.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 302 | Length = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 300 | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier (continued) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 303 | Length = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 301 | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier | templateId = 301 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex | mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 301 | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier | templateId = 301 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex | mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 301 | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: mibOption Data Record for the Conceptual RowWhere:
mibObjectIdentifier: Will contain the OID for the conceptual row as a whole.mibSubIdentifier: The mibSubIdentifier fields will contain the extra sub-identifier that, when added to the OID for the conceptual row, gives the full OID for the object.
5.8.3. Exporting Conceptual Rows - AUGMENTS ✨
SMIv2 says conceptual rows have either an INDEX clause or an AUGMENTS clause 🦋 An AUGMENTS clause extends an existing base conceptual row that has an INDEX clause. In SMIv2 you can't augment a conceptual row that itself has an AUGMENTS clause, and the base table and the augmentation have an identical INDEX.
Augmentations let you add extra columns to existing tables, so it's really useful to support them easily in IPFIX exports of conceptual rows 💅
The mibObjectValueRow OID MAY refer to either the base table with the INDEX clause or a conceptual row with an AUGMENTS clause. The mibSubIdentifier in any MIB Field Options Data Record MUST always refer to the OID exported for the mibObjectValueRow Information Element 🫶
If the mibObjectValueRow OID refers to a base table, then any extra columns from conceptual rows with an AUGMENTS clause MUST have their full OID exported.
If the mibObjectValueRow OID refers to a conceptual row that augments another conceptual row using the AUGMENTS clause, then any MIB fields from the original table's INDEX or columnar objects MUST NOT use the mibSubIdentifier and MUST instead export the full OID in a mibObjectIdentifier. Main character energy, no shortcuts 👑
If the mibObjectValueRow refers to an augmenting conceptual row, the Scope Fields of the Template used in the subTemplateList MUST have the index fields from the base table, in the same order as its scope. This is identical to the Scope Field requirements for conceptual rows with an INDEX clause 🌸
This flexibility exists so the conceptual rows with the most columns can be exported using the more efficient mibSubIdentifier. For example, exporting a complete set of augmentation columns would only require the full OIDs for the MIB objects in the INDEX 🧚
It's possible to export MIB object columns from multiple augmenting conceptual rows. If you do that, the base table SHOULD be used as the main OID for the mibObjectValueRow 💜
5.8.4. Exporting Conceptual Tables - mibObjectValueTable 🦋
Okay bestie, this is where you can export a whole bunch of rows from one conceptual table in a single mibObjectValueTable Information Element (Section 11.2.1.10) 💖. The entire set of rows gets packed into one field, so you can drop that field into a Template alongside other Information Elements. And yes, several complete conceptual tables could all ride in one packet 📦🔥.
Same deal as mibObjectValueRow over in Section 5.8.2: the more specific (i.e., full) OID of the SEQUENCE entity MUST be exported 🫶.
The layout is basically identical to mibObjectValueRow 🧚, with one difference: the subTemplateList can hold zero or more entries.
Everything else that isn't about length, from mibObjectValueRow in Section 5.8.2, applies to mibObjectValueTable too 🌸.
Here's the big picture in Figure 18 🍓. It's pretty similar to Figure 12, so it's giving déjà vu in the best way.
+---------------------------+ +------------------------+
| Data Template | | MIB Field Options Data |
| | | |
| mibObjectValueTable |<---| OID |
+---------------------------+ +------------------------+
|
| +-----------------------+ +------------------------+
| | Options Template | | MIB Field Options Data |
| | | | |
| | Scope mibObjectValue* |<---| mibSubIdentifier |
| | mibObjectValue* |<---| mibSubIdentifier |
| +-----------------------+ +------------------------+
| |
V V
+-----------------------------+
| Data Flows |
| |
| subTemplateList (n entries) |
| row 1 |
| ... |
| row n |
+-----------------------------+
Figure 18: Architecture for Exporting Conceptual Tables
with mibObjectValueTable5.8.5. Exporting Columnar Objects: Using mibIndexIndicator 🔍
The other way to index a columnar object (the kind that belongs to a conceptual table) is explicit indexing. Here, the Options Template Set scope can hold either non-index fields or columnar MIB objects from multiple conceptual rows being exported. So every mibObjectValue Information Element needs the mibIndexIndicator, with the bits set for the fields that index that particular columnar object 💅.
The index fields MUST be in the "correct" order, the one defined in the conceptual row that each columnar object is a member of 📋.
If a mibObjectValue Information Element that's being indexed using mibIndexIndicator is used as an Options Template Scope Field, then all the fields used to index it MUST also be Scope Fields 🙈.
Figure 19 shows the MIB Field Options Template for an indexed MIB columnar object 👑.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibIndexIndicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: MIB Field Options Template for an Indexed
MIB Columnar ObjectWhere:
mibIndexIndicator 🎀
This is the MIB Index Indicator IPFIX Information Element, and it marks which fields in the Data Record act as INDEX values for the exported MIB object.
The index data for a mibObjectValue comes from other fields in the same Data Record. The mibIndexIndicator marks the fields whose value(s) get added to the OID for the MIB object type definition (the one exported in mibObjectIdentifier) to form the OID for the instance of the MIB object 🌈.
Elements used to index MIB objects MUST be exported in the same order as they are specified in the index field of the conceptual table they belong to 💜.
mibObjectIdentifier 🧶
Heads up: this field uses variable-length encoding.
6. Example Use Cases ✨
6.1. Non-columnar MIB Object: Established TCP Connections ✨
okay bestie, picture this 🦋 you wanna keep an eye on how many established TCP connections a remote network device has. The lowkey genius move is to set it up so it periodically sends that count to a centralized Collector. In this example, the Exporter sends an IPFIX Message every 30 minutes, and each one carries Data Records that spell out the number of established TCP connections 💅
Here's the table of data that's getting exported (iconic 🌸):
+-------------------------+-----------------------+
| TIMESTAMP | ESTABLISHED TCP CONN. |
+-------------------------+-----------------------+
| StartTime + 0 seconds | 10 |
| StartTime + 60 seconds | 14 |
| StartTime + 120 seconds | 19 |
| StartTime + 180 seconds | 16 |
| StartTime + 240 seconds | 23 |
| StartTime + 300 seconds | 29 |
+-------------------------+-----------------------+Table 2: Established TCP Connections
Now the Template Record for each of these Data Records gives the details for these two Information Elements 🧚
flowStartSecondsfrom [IANA-IPFIX], Information Element 150: The absolute timestamp of the first packet of this Flow.tcpCurrEstabfrom [RFC4022], Object ID"1.3.6.1.2.1.6.9": The number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT.
Figure 20 shows the exported Template Set with that Template Record for exporting the number of established TCP connections. It's giving clean and simple 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 400 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = flowStartSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueGauge | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 20: Example of tcpCurrEstab Template Set
Figure 21 shows the exported MIB Field Options Template Set, which holds the metadata that gets exported about the mibObjectValueGauge Information Element in Template 400 in the Template Record 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 401 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 21: Example of tcpCurrEstab MIB Field Options Template Set
Figure 22 shows the exported MIB Field Options Data Set, which holds the metadata that gets exported about the mibObjectValueGauge Information Element in Template 400 in the Template Record. Slay 👑
The OID for the MIB object tcpCurrEstab from [RFC4022], Object ID "1.3.6.1.2.1.6.9", gets encoded in ASN.1/BER [X.690] as "06072B060102010609" in the Data Record, and that takes 9 octets 🤓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 401 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 400 | informationElementIndex = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN = 9 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier = "1.3.6.1.2.1.6.9" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 06072B060102010609 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 22: Example of tcpCurrEstab MIB Field Options Data Set
Figure 23 shows the start of the Data Set for exporting the number of established TCP connections (see Section 6.1). This is where the actual numbers finally show up 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 400 | Length = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 0 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 60 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 120 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 180 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 240 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 300 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 23: Example of tcpCurrEstab Data Set
6.2. Enterprise-Specific MIB Object: Detailing CPU Load History ✨
okay so for the demo we're grabbing an enterprise-specific MIB object from the CISCO-PROCESS-MIB [CISCO-PROCESS-MIB] 🖥️ but honestly this works with ANY enterprise-specific MIB module, so don't get stuck on the Cisco part bestie 💅
picture a remote network device with one CPU. you set it up to periodically export its CPU usage info, aka the cpmCPUTotal1minRev from that proprietary CISCO-PROCESS-MIB (Object ID "1.3.6.1.4.1.9.9.109.1.1.1.1.7") to a centralized Collector. it's giving centralized control 🎀
here's the lowkey clever part: cpmCPUTotal1minRev is a columnar object inside a conceptual row, BUT if there's only one CPU, the index field doesn't tell you anything new. so it's totally fine to skip exporting the cpmCPUTotalIndex MIB object 🙈 if there were multiple CPUs though, you'd want to include cpmCPUTotalIndex and spell out the relationship. no cap, that's the difference between one CPU and many ✨
so in this setup the Exporter sends an IPFIX Message every 30 minutes 🕧. each one holds Data Records with the CPU 1-minute busy average, sampled at 1-minute intervals. the table of data we're exporting looks like this:
+-------------------------+---------------------+
| TIMESTAMP | CPU BUSY PERCENTAGE |
+-------------------------+---------------------+
| StartTime + 0 seconds | 10% |
| StartTime + 60 seconds | 14% |
| StartTime + 120 seconds | 19% |
| StartTime + 180 seconds | 16% |
| StartTime + 240 seconds | 23% |
| StartTime + 300 seconds | 29% |
+-------------------------+---------------------+
Table 3: CPU Usage Datathe Template Record for these Data Records describes two Information Elements 🧚:
- flowStartSeconds from [IANA-IPFIX], Information Element 150: the absolute timestamp of the first packet of this Flow. bestie this is the time anchor 🕰️
- A mibObjectValueGauge for cpmCPUTotal1minRev, which is the overall CPU busy percentage over the last 1-minute period. this is the actual vibe check 📊
Figure 24 shows the exported Template Set for the CPU Load Template Record (see Section 6.2) 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 402 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = flowStartSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueGauge | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Example of CPU Load Template SetFigure 25 shows the exported Template Set for the MIB Field Options Template covering CPU Load (see Section 6.2). quick side note: this is identical to the MIB Field Options Template from Figure 21, so honestly we could have just reused that one 🔁
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 403 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Example of CPU Load MIB Field Options Template SetFigure 26 shows the exported MIB Field Options Data Set, which holds the metadata for the mibObjectValueGauge Information Element in Template 402 in the Template Record (see Section 6.2) 🫶
the OID for cpmCPUTotal1minRev has been encoded with ASN.1/BER as "060D2B0601040109096D0101010107", which is 15 octets long 🔢
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 403 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 402 | informationElementIndex = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN = 15 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.4.1.9.9.109.1.1.1.1.7" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060D2B0601040109096D0101010107 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Example of CPU Load MIB Field Options Data Setplot twist: cpmCPUTotal1minRev is 32 bits long, but reduced-size encoding [RFC7011] lets us squish it into a single octet 🤏 we get this by setting the length for the mibObjectValueGauge field to 1 octet in the main Data Template (see Figure 24). it's literally giving efficiency 💜
this example really hammers home one thing: even though the OID cpmCPUTotal1minRev is enterprise-specific, the E bit for both mibObjectValueGauge and mibObjectIdentifier is set to 0. why? because those two Information Elements are not enterprise-specific themselves 🙌 the fact that this data comes from an Enterprise MIB is carried inside the OID, which includes an Enterprise ID. iykyk 🦋
the corresponding Data Set doesn't add any new value for this example, so we're not displaying it 🌸
6.3. Exporting a Conceptual Row: The OSPF Neighbor Row
Okay bestie, this is where we get to the really satisfying stuff 🦋✨ Lots of conceptual tables already exist in standard and proprietary MIBs, and the good news is you can export them with barely any overhead by using the mibObjectValueRow 💅 It lets the Exporting Process pin down the INDEX for the whole conceptual row by using the Scope Fields of an Options Template Set 🎀 And when you pair a MIB Field Options Template with mibSubIdentifier, each columnar object doesn't need its OID exported to the Collector. Iconic, no cap 👑
The ospfNbrTable, which is defined in the OSPF MIB [RFC4750], is made up of ospfNbrEntry, whose OID is "1.3.6.1.2.1.14.10.1" 🌸 So every mibObjectValueRow Data Record is going to line up with one ospfNbrEntry. Literally that simple 🫶
Here's what gets exported:
+------------------+----------------+-------------------------+-----+
| Object | ID | mibObjectValue | Len |
+------------------+----------------+-------------------------+-----+
| ospfNbrIpAddr | ospfNbrEntry 1 | mibObjectValueIPAddress | 4 |
| ospfNbrAddress- | ospfNbrEntry 2 | mibObjectValueInteger | 4 |
| -LessIndex | | | |
| ospfNbrRtrId | ospfNbrEntry 3 | mibObjectValueIPAddress | 4 |
| ospfNbrState | ospfNbrEntry 6 | mibObjectValueInteger | 1 |
+------------------+----------------+-------------------------+-----+Table 4: OSPF Neighbor Entry Objects
And these are the OIDs used to export the table, shown in Table 5 🧚
+------------------+-----------------------+---------------------+
| Entity | Full OID | Exported as |
+------------------+-----------------------+---------------------+
| ospfNbrEntry | 1.3.6.1.2.1.14.10.1 | 1.3.6.1.2.1.14.10.1 |
| ospfNbrIpAddr | 1.3.6.1.2.1.14.10.1.1 | 1 |
| ospfNbrAddress- | 1.3.6.1.2.1.14.10.1.2 | 2 |
| -LessIndex | | |
| ospfNbrRtrId | 1.3.6.1.2.1.14.10.1.3 | 3 |
| ospfNbrState | 1.3.6.1.2.1.14.10.1.6 | 6 |
+------------------+-----------------------+---------------------+Table 5: OSPF OIDs
Figure 27 shows the Templates exported to support the mibObjectValueRow 📦 Figure 28 shows the example OID Data for the conceptual row exported in mibObjectValueRow 💖 Figure 29 shows the example data export for a few neighbors in the table, and it also shows a Data Record formatted as per IPFIX Structured Data [RFC6313] and using the "undefined" (= 0xFF) semantic from the "IPFIX Structured Data Types Semantics" subregistry [IANA-IPFIX] 🌈 Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to "06082B060102010E0A01" at 10 octets long 🙈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 500 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueRow | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 501 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = mibObjectValueIPAddress|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueIPAddress|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 22 | Template ID = 502 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 3 | Scope Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = templateId | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = informationElementIndex| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectIdentifier | Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 503 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 27: Example of ospfNbrEntry Template and Options Template Sets
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 502 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 500 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN = 10 | mibObjectIdentifier = "1.3.6.1.2.1.14.10.1" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06082B060102010E0A01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 503 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 501 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 1 | templateId = 501 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 1 | mibSubIdentifier = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 501 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 3 | templateId = 501 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 3 | mibSubIdentifier = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 28: Example of ospfNbrEntry OID Data Export
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 500 | Length = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 501 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 501 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.2 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 501 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 3.3.3.3 |ospfNbrState=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 29: Example of Data Export for ospfNbrEntry
6.4. Exporting Augmented Conceptual Row: Mapping IF-MIB ID to Name ✨
okay so this one is giving augmentation, bestie 💅 The ifTable, defined in the IF-MIB [RFC2863], gets augmented by the ifXTable, which lives in that same MIB module 🦋
The OID of the ifEntry is 1.3.6.1.2.1.2.2.1. Encoded with ASN.1/BER, that becomes "06082B06010201020201", and it's 10 octets long 🌸 The augmenting ifXEntry has OID 1.3.6.1.2.1.31.1.1.1, which encodes to "060A2B060102011F01010101" and comes in at 12 octets long 💜
This example shows how columnar objects from the base conceptual row and the augmenting row can both get exported in one single mibObjectValueRow Information Element. main character energy 👑
Table 6 shows the fields that will be exported 🎀
+---------+------------------+-------+-------------------+
| ifIndex | ifType | ifMtu | ifName |
+---------+------------------+-------+-------------------+
| 1 | ethernetCsmacd:6 | 1500 | Ethernet 10 |
| 2 | ethernetCsmacd:6 | 1500 | Ethernet 20 |
| 3 | ethernetCsmacd:6 | 1500 | FastEthernet 30 |
+---------+------------------+-------+-------------------+
Table 6: IF-MIB DataThe OIDs used to export this table are listed in Table 7 🧚
+---------+------------------------+--------------------------------+
| Entity | Full OID | Exported as |
+---------+------------------------+--------------------------------+
| ifEntry | 1.3.6.1.2.1.2.2.1 | OID = 1.3.6.1.2.1.2.2.1 |
| ifIndex | 1.3.6.1.2.1.2.2.1.1 | subID = 1 |
| ifType | 1.3.6.1.2.1.2.2.1.3 | subID = 3 |
| ifMtu | 1.3.6.1.2.1.2.2.1.4 | subID = 4 |
| ifName | 1.3.6.1.2.1.31.1.1.1.1 | OID = 1.3.6.1.2.1.31.1.1.1.1 |
+---------+------------------------+--------------------------------+
Table 7: IF-MIB OIDsNow for the visuals 🦋 Figure 30 shows the Templates exported to support the mibObjectValueRow Information Element. Figure 31 shows the example OID Data for the conceptual row exported in mibObjectValueRow to match Table 7. Figure 32 shows the example data export as per Table 6. iykyk, it's a whole lot of bits, but it's so pretty 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 600 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueRow | Field Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 601 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|IE =mibObjectValueOctetString|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 22 | Template ID = 602 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 3 | Scope Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = templateId | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = informationElementIndex| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectIdentifier | Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 603 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Example of Augmented ifEntry Template and
Options Template Sets 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 602 | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 600 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN = 10 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifEntry = 1.3.6.1.2.1.2.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06082B06010201020201 | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 601 | informationElementIndex = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN = 12 | mibObjectIdentifier ifName ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifName = 1.3.6.1.2.1.31.1.1.1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060A2B060102011F01010101 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 603 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 601 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 1 | templateId = 601 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 1 | mibSubIdentifier = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 601 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: Example of Augmented ifEntry OID Data Export 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 600 | Length = 68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 601 | ifIndex = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifType = 6 | ifMtu = 1500 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 11 | ifName = Ethernet 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 601 | ifIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifType = 6 | ifMtu = 1500 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 11 | ifName = Ethernet 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 601 | ifIndex = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifType = 6 | ifMtu = 1500 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 15 | ifName = FastEthernet 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Example of Data Export for Augmented ifEntry6.5. Exporting a Columnar Object: ipIfStatsInForwDatagrams 🦋
okay so bestie, sometimes you don't need to export EVERY single column a conceptual row supports 💅 and that's totally fine! Instead of going full IPFIX Structured Data [RFC6313] energy, you can use the mibIndexIndicator method to show how the fields relate to each other ✨ it's giving efficiency, no cap.
Here's the vibe. The MIB objects that make up the INDEX of the conceptual row get exported first, in the correct order, and then the columnar object gets referred back to them using mibIndexIndicator 🎀
This example exports ipIfStatsInForwDatagrams from the IP-MIB [RFC4293] 🌸 It's a columnar object in the ipIfStatsTable conceptual table, and that table is made up of ipIfStatsEntry conceptual rows. The ipIfStatsTable is indexed by ipIfStatsIPVersion and ipIfStatsIfIndex, so those two are the stars of the index show 👑
The Options Template Record for the example Data Record contains these Information Elements:
- ipIfStatsIPVersion (1.3.6.1.2.1.4.31.3.1.1) (Scope Field) (encoded using ASN.1/BER to "060A2B06010201041F030101" at 12 octets long)
- ipIfStatsIfIndex (1.3.6.1.2.1.4.31.3.1.2) (Scope Field) (encoded using ASN.1/BER to "060A2B06010201041F030102" at 12 octets long)
- ipIfStatsInForwDatagrams (1.3.6.1.2.1.4.31.3.1.12) (non-Scope Field) (encoded using ASN.1/BER to "060A2B06010201041F03010C" at 12 octets long)
Quick heads up 🙈 ipIfStatsIfIndex has been reduced-size encoded to 2 octets in this example. An exporting device with more interfaces would use the full length, so don't copy this blindly!
Figure 33 shows the exported Options Template Set 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 701 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0|Scope 1=mibObjectValueInteger|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field 1 Length = 1 |0|Scope 2=mibObjectValueInteger|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field 1 Length = 2 |0| IE = mibObjectValueCounter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: Example of an Options Template for an Indexed MIB Object
with Two Index ObjectsFigure 34 shows the exported MIB Field Options Template used to export the required mibObjectValue Information Element metadata 💜 This example includes the mibIndexIndicator to show which of the other fields in the Data Records are index objects. Main character energy 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 702 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibIndexIndicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Example of a MIB Field Options Template for an Indexed
MIB Object with Two Index ObjectsFigure 35 shows the exported MIB Field Options Data used to export the required mibObjectValue Information Element metadata 🍓 Notice that the first two Data Records have all their mibIndexIndicator bits set to 0. The third mibIndexIndicator has the value "00000011", which shows that the first two fields in the Data Record are the INDEXes for this columnar object. iykyk 😭
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 702 | Length = 58 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 701 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index 00000000 | VLEN = 12 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.4.31.3.1.1" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060A2B06010201041F030101 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | templateId = 701 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 1 |Index 00000000 | VLEN = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibObjectIdentifier = "1.3.6.1.2.1.4.31.3.1.2" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060A2B06010201041F030102 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 701 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index 00000011 | VLEN = 12 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.4.31.3.1.12" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060A2B06010201041F03010C ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: Example of a MIB Field Options Data Set for an Indexed
MIB Object with Two Index ObjectsFigure 36 shows the Data Records that export the values of the three mibObjectValue Information Elements 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 701 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipVer = 1 | ifIndex = 10 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InForwDatagrams = 10000 | ipVer = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifIndex = 10 | InForwDatagrams = 20000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36: Example of a MIB Data Set for an Indexed MIB Object
with Two Index Objects6.6. Exporting a Columnar Object Indexed by Information Elements: ifOutQLen ✨
okay so, say a PSAMP Packet Report [RFC5476] got generated on some dropped packets on an interface 💀. Then it's lowkey really useful to know if the send queue on the output interface was full 👀. You can find that out by exporting the size of the send queue (ifOutQLen) in the same Data Record as the PSAMP Packet Report 🫶.
Here's how the exported data looks 💅:
+-----------+-----------+---------+--------------+------------------+
| SRC ADDR | DST ADDR | PKT LEN | OUTPUT | OUTPUT QUEUE LEN |
| | | | INTERFACE | (ifOutQLen) |
+-----------+-----------+---------+--------------+------------------+
| 192.0.2.1 | 192.0.2.3 | 150 | Eth 1/0 (15) | 45 |
| 192.0.2.4 | 192.0.2.9 | 350 | Eth 1/0 (15) | 45 |
| 192.0.2.3 | 192.0.2.9 | 650 | Eth 1/0 (15) | 23 |
| 192.0.2.4 | 192.0.2.6 | 350 | Eth 1/1 (16) | 0 |
+-----------+-----------+---------+--------------+------------------+
Table 8: Packet Report with Interface Output Queue Length
(ifOutQLen) DataThe ifOutQLen MIB object, defined in the IF-MIB [RFC2863], gives you the length of the output packet queue 📦. This columnar object is part of the ifEntry conceptual row and is indexed by the interface index (ifIndex) 🧚.
This relationship between the ifOutQLen field and the index field gets exported using mibIndexIndicator in the MIB Field Options Template. The value 00001000 flags the index fields concisely 🎀.
The Template Record for the example Data Record contains these Information Elements:
- sourceIPv4Address
- destinationIPv4Address
- totalLengthIPv4
- egressInterface
- ifOutQLen (indexed by egressInterface)
Figure 37 shows the exported Template Set with the Template for exporting a PSAMP Report with ifOutQLen. Figures 38 and 39 show the MIB Field Options Template and Data Record 🌸.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 703 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = sourceIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = destinationIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = totalLengthIPv4 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = egressInterface | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueGauge | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: Example of Template for a PSAMP Report with ifOutQLen
Indexed by egressInterface 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 704 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibIndexIndicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38: Example of MIB Field Options Template for a PSAMP Report
with ifOutQLen Indexed by egressInterface 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 704 | Length = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 703 | informationElementIndex = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index 00001000 | VLEN = 11 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.2.2.1.21" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06092B0601020102020115 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 39: Example of MIB Field Options Data Record for a PSAMP
Report with ifOutQLen Indexed by egressInterfaceThe corresponding IPFIX Data Record is shown in Figure 40 👑. For the sake of the example, the interface index of "Eth 1/0" is 15 and the interface index of "Eth 1/1" is 16 🦋.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 703 | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 150 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 (Eth 1/0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 350 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 (Eth 1/0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 650 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 (Eth 1/0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 350 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 (Eth 1/1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: Example of PSAMP Packet Report with ifOutQLen
Indexed by egressInterface6.7. Exporting with Multiple Contexts: The OSPF Neighbor Row Revisited 🎀
okay so bestie, this one is the sequel to Section 6.3 and it's giving "what if there's more than one of the same thing" 👀✨ If the context used to export the MIB objects is the default one, you don't need any extra context fields. Easy! 💅 But this example shows what to do when the context does need to be specified. It's built on the previous example (Section 6.3), so go check that one first if you need a refresher 🧚
Here's the deal: the OSPF details from Section 6.3 would be totally fine if there was only one OSPF process running at the Observation Point. 💖 But if there are multiple OSPF processes, you need a way to tell them apart. The fix is to also export the mibContextEngineID and mibContextName, and that's the whole plot twist 😭🫶
So these are the fields that get exported:
+------------------+----------------+-------------------------+-----+
| Object | ID | mibObjectValue | Len |
+------------------+----------------+-------------------------+-----+
| ospfNbrIpAddr | ospfNbrEntry 1 | mibObjectValueIPAddress | 4 |
| ospfNbrAddress- | ospfNbrEntry 2 | mibObjectValueInteger | 4 |
| -LessIndex | | | |
| ospfNbrRtrId | ospfNbrEntry 3 | mibObjectValueIPAddress | 4 |
| ospfNbrState | ospfNbrEntry 6 | mibObjectValueInteger | 1 |
+------------------+----------------+-------------------------+-----+Table 9: OSPF Neighbor Entry Objects 🌸
The example contextEngineID matches the one from [RFC3411] for Acme Networks: '800002B804616263'H (enterprise 696, string "abc") 🍓
Now, Figure 41 shows the Templates that get exported to support a mibObjectValueRow defined within a context. Figure 42 shows the example OID Data for the conceptual row in mibObjectValueRow. Both of these are unchanged from the previous example (Section 6.3), so no need to panic 🙈 Figure 43 is where the fun is: it shows the example data for two OSPF neighbors. Even though they have identical INDEX/scope values, the context info tells you they come from different OSPF processes. Iconic. 👑
Quick note: the OID for ospfNbrEntry gets encoded using ASN.1/BER as 06082B060102010E0A01, which is 10 octets long 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 800 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibContextEngineID | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibContextName | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueRow | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 801 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = mibObjectValueIPAddress|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueIPAddress|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 22 | Template ID = 802 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 3 | Scope Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = templateId | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = informationElementIndex| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectIdentifier | Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 803 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Example of ospfNbrEntry Template and Options Template Sets
with Context 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 802 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 800 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN = 10 | mibObjectIdentifier = "1.3.6.1.2.1.14.10.1" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06082B060102010E0A01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 803 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 801 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 1 | templateId = 801 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 1 | mibSubIdentifier = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 801 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 3 | templateId = 801 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 3 | mibSubIdentifier = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42: Example of ospfNbrEntry OID Data Export with Context 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 800 | Length = 60 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibContextEngineID = 800002B804616263 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibContextEngineID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibContextName = con1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 801 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibContextEngineID = 800002B804616263 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibContextEngineID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibContextName = con2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 801 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.2 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 43: Example of Data Export for ospfNbrEntry with Context7. Configuration Considerations ⚙️
okay so when you're setting up a MIB OID for export, you should think about whether the SNMP context should be configurable too 🧠 If you end up using a non-default context, it should be associated with the fields as per Section 5.6 💅
8. The Collecting Process's Side 📥
bestie, the specifications in Section 9 of [RFC7011] also apply to Collectors that implement this spec 🫶 On top of that, here are the extra things to note:
- A Collecting Process that implements this specification MUST store the Data Records containing the OID object type definitions with the same retention policy as Templates. 🔒
- A Collecting Process that implements this specification SHOULD have access to MIB modules so it can look up the received MIB Object Identifiers and find the full type definition and name of MIB OID fields used in received Templates. 🔍
- It should be noted that, because reduced-size encoding MAY be used by the Exporting Process, the Collecting Process cannot assume that a received size for a field is the maximum size it should expect for that field. 🙃
- If a Collecting Process receives a MIB Object Identifier that it cannot decode, it MAY log a warning. 📝
- A Collecting Process MUST support the three options for handling columnar objects detailed in Section 5.8. 💖
9. Applicability ✨
Okay so, making all those MIB goodies available opens up SO many possible uses for IPFIX 🦋, and some of them are totally different from the usual Flow info. No cap 💅
Some monitoring apps periodically export a mapping of interface ID to interface name using IPFIX Options Templates 🌸. This could be expanded to include the ifInUcastPkts MIB object, as defined in the IF-MIB [RFC2863], indexed using the ingressInterface Information Element. That gives you the input stats for each interface ✨. You can compare those stats to the Flow info to check that the sampling rate is what you expect, or, if there's no sampling, to make sure all the packets you expected are actually being monitored 🫶.
10. Security Considerations 🔒
Bestie, this extension is basically IPFIX, so the same security considerations as IPFIX itself apply [RFC7011]. Main point, don't forget it 💀.
If the Exporter is making the field values itself (like, it's only borrowing the MIB objects as an encoding or type mechanism), there are no extra security considerations beyond standard IPFIX 🧚.
🚨 However, if the Exporter is implemented as an SNMP manager accessing an SNMP agent, it MUST authenticate itself to the SNMP agent [RFC3414] [RFC5591] [RFC5592] [RFC6353], and the SNMP agent MUST enforce SNMP access control rules [RFC3415] as required by the SNMP architecture [RFC3411].
Access to particular MIB objects is controlled by how the IPFIX Exporter is configured. This matches the way IPFIX controls access to other Information Elements in general 🎀.
The Exporter's configuration decides which MIB objects get included in IPFIX Data Records sent to certain Collectors. Network operators should take care that the only MIB objects included in IPFIX Data Records are objects the receiving Collector is allowed to receive. Also, note that multiple users may have access to the data from the Collector 👀.
When exporting MIB objects that may be considered sensitive or vulnerable in some network environments (as mentioned in the Security Considerations section of the RFC containing the MIB module), the Exporter should consider using anonymization techniques per [RFC6235] if the information is anonymizable. So consumers of exported data should be able to handle the kinds of data modifications described in [RFC6235] 🥹.
11. IANA Considerations 🎀
11.1. New IPFIX Semantics
New IPFIX semantics have been allocated in IANA's IPFIX registry [IANA-IPFIX] per Section 6 of [RFC7012]. They're defined in the subsections below 🍓.
11.1.1. snmpCounter
snmpCounter is an integral value that reports the value of a counter. It's identical to the Counter32 and Counter64 semantics in [RFC2578], and which one applies is determined by the Field Length 🔢.
This is similar to IPFIX's totalCounter semantic, with one difference: total counters have an initial value of 0, but SNMP counters do not 🙈.
IANA has assigned value 7 to snmpCounter.
11.1.2. snmpGauge
snmpGauge is an integral value identical to the Gauge32 semantic in [RFC2578] and the Gauge64 semantic in [RFC2856]. Which one applies is determined by the Field Length 📏.
IANA has assigned value 8 to snmpGauge.
11.2. New IPFIX Information Elements
The new Information Elements in Table 10 have been allocated in IANA's IPFIX registry [IANA-IPFIX], as defined in the subsections below 🌈. In each case, the "Units" and "Range" have been left blank, since these don't apply.
+-----------+---------------------------+
| ElementId | Name |
+-----------+---------------------------+
| 434 | mibObjectValueInteger |
| 435 | mibObjectValueOctetString |
| 436 | mibObjectValueOID |
| 437 | mibObjectValueBits |
| 438 | mibObjectValueIPAddress |
| 439 | mibObjectValueCounter |
| 440 | mibObjectValueGauge |
| 441 | mibObjectValueTimeTicks |
| 442 | mibObjectValueUnsigned |
| 443 | mibObjectValueTable |
| 444 | mibObjectValueRow |
| 445 | mibObjectIdentifier |
| 446 | mibSubIdentifier |
| 447 | mibIndexIndicator |
| 448 | mibCaptureTimeSemantics |
| 449 | mibContextEngineID |
| 450 | mibContextName |
| 451 | mibObjectName |
| 452 | mibObjectDescription |
| 453 | mibObjectSyntax |
| 454 | mibModuleName |
+-----------+---------------------------+Table 10: New Information Elements
11.2.1. New MIB Object Value Information Elements
11.2.1.1. mibObjectValueInteger
IANA's IPFIX registry [IANA-IPFIX] now has a brand-new Information Element called mibObjectValueInteger 💖. Here's its entry:
Description: An IPFIX Information Element that denotes that the
integer value of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base syntax of Integer32
and INTEGER with IPFIX reduced-size encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type
of signed32.
Abstract Data Type: signed32
Data Type Semantics: quantity
ElementId: 434
Status: current
Reference: RFC 803811.2.1.2. mibObjectValueOctetString
Next up is mibObjectValueOctetString, which joins the registry with its own definition 🧃:
Description: An IPFIX Information Element that denotes that an
Octet String or Opaque value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field
MUST be exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base syntax
of OCTET STRING and Opaque. The value is encoded as per the
standard IPFIX Abstract Data Type of octetArray.
Abstract Data Type: octetArray
Data Type Semantics: default
ElementId: 435
Status: current
Reference: RFC 803811.2.1.3. mibObjectValueOID
Now mibObjectValueOID gets its moment ✨:
Description: An IPFIX Information Element that denotes that an
Object Identifier or OID value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field
MUST be exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base syntax
of OBJECT IDENTIFIER. Note: In this case, the
"mibObjectIdentifier" defines which MIB object is being exported,
and the "mibObjectValueOID" field will contain the OID value of
that MIB object. The mibObjectValueOID Information Element is
encoded as ASN.1/BER [X.690] in an octetArray.
Abstract Data Type: octetArray
Data Type Semantics: default
ElementId: 436
Status: current
Reference: RFC 803811.2.1.4. mibObjectValueBits
Then there's mibObjectValueBits, which is for sets of flags 🚩:
Description: An IPFIX Information Element that denotes that a set
of Enumerated flags or bits from a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field
MUST be exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base syntax
of BITS. The flags or bits are encoded as per the standard IPFIX
Abstract Data Type of octetArray, with sufficient length to
accommodate the required number of bits. If the number of bits is
not an integer multiple of octets, then the most significant bits
at the end of the octetArray MUST be set to 0.
Abstract Data Type: octetArray
Data Type Semantics: flags
ElementId: 437
Status: current
Reference: RFC 803811.2.1.5. mibObjectValueIPAddress
Next, mibObjectValueIPAddress shows up for IPv4 address values 🌐:
Description: An IPFIX Information Element that denotes that the
IPv4 address value of a MIB object will be exported. The MIB
Object Identifier ("mibObjectIdentifier") for this field MUST be
exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base syntax
of IpAddress. The value is encoded as per the standard IPFIX
Abstract Data Type of ipv4Address.
Abstract Data Type: ipv4Address
Data Type Semantics: default
ElementId: 438
Status: current
Reference: RFC 803811.2.1.6. mibObjectValueCounter
mibObjectValueCounter is up next, for counter values 🔥:
Description: An IPFIX Information Element that denotes that the
counter value of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base syntax of Counter32
or Counter64 with IPFIX reduced-size encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type
of unsigned64.
Abstract Data Type: unsigned64
Data Type Semantics: snmpCounter
ElementId: 439
Status: current
Reference: RFC 803811.2.1.7. mibObjectValueGauge
And last but not least for this bit, mibObjectValueGauge for Gauge32 objects 📊:
Description: An IPFIX Information Element that denotes that the
Gauge value of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base syntax of Gauge32.
The value is encoded as per the standard IPFIX Abstract Data Type
of unsigned32. This value represents a non-negative integer that
may increase or decrease but that shall never exceed a maximum
value or fall below a minimum value.
Abstract Data Type: unsigned32
Data Type Semantics: snmpGauge
ElementId: 440
Status: current
Reference: RFC 803811.2.1.8. mibObjectValueTimeTicks ⏱️
Okay so IANA added a brand-new Information Element called mibObjectValueTimeTicks 💖 to the IPFIX registry [IANA-IPFIX], and it's giving exactly what you'd want for TimeTicks values 🦋:
Description: An IPFIX Information Element that denotes that the
TimeTicks value of a MIB object will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with the Base syntax of TimeTicks.
The value is encoded as per the standard IPFIX Abstract Data Type
of unsigned32.
Abstract Data Type: unsigned32
Data Type Semantics: quantity
ElementId: 441
Status: current
Reference: RFC 8038So the MIB OID rides along in a MIB Field Option (or another way), it's for MIB objects whose Base syntax is TimeTicks, and the value gets encoded as a plain IPFIX unsigned32 🌸.
11.2.1.9. mibObjectValueUnsigned 🎀
Next up is mibObjectValueUnsigned 💅, which is the unsigned-integer sibling:
Description: An IPFIX Information Element that denotes that an
unsigned integer value of a MIB object will be exported. The MIB
Object Identifier ("mibObjectIdentifier") for this field MUST be
exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with the Base syntax
of unsigned32 with IPFIX reduced-size encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type
of unsigned32.
Abstract Data Type: unsigned32
Data Type Semantics: quantity
ElementId: 442
Status: current
Reference: RFC 8038It's for MIB objects with a Base syntax of unsigned32, and it uses IPFIX reduced-size encoding where that's required. Same OID rule applies too 🫶.
11.2.1.10. mibObjectValueTable 🌈
Now we get to tables, and this one's iconic 👑. mibObjectValueTable is for a complete or partial conceptual table, and it's for MIB objects with a SEQUENCE OF syntax:
Description: An IPFIX Information Element that denotes that a
complete or partial conceptual table will be exported. The MIB
Object Identifier ("mibObjectIdentifier") for this field MUST be
exported in a MIB Field Option or via another means. This
Information Element is used for MIB objects with a syntax of
SEQUENCE OF. This is encoded as a subTemplateList of
mibObjectValue Information Elements. The Template specified in
the subTemplateList MUST be an Options Template and MUST include
all the objects listed in the INDEX clause as Scope Fields.
Abstract Data Type: subTemplateList
Data Type Semantics: list
ElementId: 443
Status: current
Reference: RFC 8038The table comes through as a subTemplateList of mibObjectValue Information Elements, and the Template inside has to be an Options Template that carries every INDEX object as a Scope Field 🧚.
11.2.1.11. mibObjectValueRow 🍓
mibObjectValueRow is the single-row version 🙈, for MIB objects with a SEQUENCE syntax:
Description: An IPFIX Information Element that denotes that a
single row of a conceptual table will be exported. The MIB Object
Identifier ("mibObjectIdentifier") for this field MUST be exported
in a MIB Field Option or via another means. This Information
Element is used for MIB objects with a syntax of SEQUENCE. This
is encoded as a subTemplateList of mibObjectValue Information
Elements. The subTemplateList exported MUST contain exactly one
row (i.e., one instance of the subTemplate). The Template
specified in the subTemplateList MUST be an Options Template and
MUST include all the objects listed in the INDEX clause as Scope
Fields.
Abstract Data Type: subTemplateList
Data Type Semantics: list
ElementId: 444
Status: current
Reference: RFC 8038Same subTemplateList idea as the table, but this time the export holds exactly one row, and the Options Template still needs all the INDEX objects as Scope Fields 💜.
11.2.2. New MIB Field Options Information Elements ✨
11.2.2.1. mibObjectIdentifier 🦋
mibObjectIdentifier is the one that tells the Collector which MIB OID is sitting in the (Options) Template Record. The OID is encoded as ASN.1/BER [X.690]:
Description: An IPFIX Information Element that denotes that a MIB
Object Identifier (MIB OID) is exported in the (Options)
Template Record. The mibObjectIdentifier Information Element
contains the OID assigned to the MIB object type definition
encoded as ASN.1/BER [X.690].
Abstract Data Type: octetArray
Data Type Semantics: default
ElementId: 445
Status: current
Reference: RFC 803811.2.2.2. mibSubIdentifier 🌸
mibSubIdentifier is a single non-negative sub-identifier of an OID, so think of it as one little piece of the bigger OID puzzle 🧩:
Description: A non-negative sub-identifier of an Object Identifier
(OID).
Abstract Data Type: unsigned32
Data Type Semantics: identifier
ElementId: 446
Status: current
Reference: RFC 803811.2.2.3. mibIndexIndicator 🔥
This one is a bit of a bitfield moment 😭. mibIndexIndicator marks which Information Elements in a Data Record are the INDEX MIB objects for an indexed columnar MIB object:
Description: A set of bit fields that is used for marking the
Information Elements of a Data Record that serve as INDEX MIB
objects for an indexed columnar MIB object. Each bit represents
an Information Element in the Data Record, with the n-th least
significant bit representing the n-th Information Element. A bit
set to 1 indicates that the corresponding Information Element is
an index of the columnar object represented by the mibObjectValue.
A bit set to 0 indicates that this is not the case.
If the Data Record contains more than 64 Information Elements, the
corresponding Template SHOULD be designed such that all index
fields are among the first 64 Information Elements, because the
mibIndexIndicator only contains 64 bits. If the Data Record
contains less than 64 Information Elements, then the extra bits in
the mibIndexIndicator for which no corresponding Information
Element exists MUST have the value 0 and must be disregarded by
the Collector. This Information Element may be exported with
IPFIX reduced-size encoding.
Abstract Data Type: unsigned64
Data Type Semantics: flags
ElementId: 447
Status: current
Reference: RFC 8038So each bit lines up with one Information Element, least significant bit first. A 1 means that element is an index, and a 0 means it isn't. The bit-count limit of 64 is the part to watch out for, so if your Data Record has more than 64 Information Elements, the template should be built with the index fields up front 🌈.
11.2.2.4. mibCaptureTimeSemantics ⭐
This one tells you when in the Flow's life the MIB value was grabbed 💅. It's really useful for counters and statistics, so it SHOULD be used there:
Description: Indicates when in the lifetime of the Flow the MIB
value was retrieved from the MIB for a mibObjectIdentifier. This
is used to indicate if the value exported was collected from the
MIB closer to Flow creation or Flow export time and refers to the
Timestamp fields included in the same Data Record. This field
SHOULD be used when exporting a mibObjectValue that specifies
counters or statistics.
If the MIB value was sampled by SNMP prior to the IPFIX Metering
Process or Exporting Process retrieving the value (i.e., the data
is already stale) and it is important to know the exact sampling
time, then an additional observationTime* element should be paired
with the OID using IPFIX Structured Data [RFC6313]. Similarly, if
different MIB capture times apply to different mibObjectValue
elements within the Data Record, then individual
mibCaptureTimeSemantics Information Elements should be paired with
each OID using IPFIX Structured Data.
Values:
0 undefined
1 begin - The value for the MIB object is captured from the
MIB when the Flow is first observed
2 end - The value for the MIB object is captured from the MIB
when the Flow ends
3 export - The value for the MIB object is captured from the
MIB at export time
4 average - The value for the MIB object is an average of
multiple captures from the MIB over the observed life of
the Flow
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 448
Status: current
Reference: RFC 8038If the SNMP sample is already stale by the time IPFIX grabs it and the exact sampling time matters, you pair an observationTime* element with the OID using IPFIX Structured Data [RFC6313]. If different objects in one Data Record have different capture times, each OID gets its own mibCaptureTimeSemantics paired up the same way ✨. The four values are 0 (undefined), 1 (begin), 2 (end), 3 (export), and 4 (average), so pick the one that matches your story 🎀.
11.2.2.5. mibContextEngineID 🦋
mibContextEngineID carries the SNMP engine ID for a MIB field being exported over IPFIX 🧚. It's defined in [RFC3411], Section 3.3:
Description: A mibContextEngineID that specifies the SNMP
engine ID for a MIB field being exported over IPFIX. Definition
as per [RFC3411], Section 3.3.
Abstract Data Type: octetArray
Data Type Semantics: default
ElementId: 449
Status: current
Reference: RFC 803811.2.2.6. mibContextName 💜
mibContextName is the MIB context name for a MIB field being exported over IPFIX. Same home base, [RFC3411], Section 3.3 🌸:
Description: An Information Element that denotes that a MIB
context name is specified for a MIB field being exported over
IPFIX. Reference [RFC3411], Section 3.3.
Abstract Data Type: string
Data Type Semantics: default
ElementId: 450
Status: current
Reference: RFC 803811.2.3. New MIB Type Information Elements 💖
11.2.3.1. mibObjectName 🍓
mibObjectName is the name of an object type definition. In [RFC2578] it's called a descriptor 🫶:
Description: The name (called a descriptor in [RFC2578]) of an
object type definition.
Abstract Data Type: string
Data Type Semantics: default
ElementId: 451
Status: current
Reference: RFC 803811.2.3.2. mibObjectDescription 🌈
mibObjectDescription holds the value of the DESCRIPTION clause from a MIB object type definition 📝:
Description: The value of the DESCRIPTION clause of a MIB object
type definition.
Abstract Data Type: string
Data Type Semantics: default
ElementId: 452
Status: current
Reference: RFC 803811.2.3.3. mibObjectSyntax ⭐
mibObjectSyntax is the SYNTAX clause from a MIB object type definition, and that can include a textual convention or sub-typing. Check out [RFC2578] for the details 👑:
Description: The value of the SYNTAX clause of a MIB object type
definition, which may include a textual convention or sub-typing.
See [RFC2578].
Abstract Data Type: string
Data Type Semantics: default
ElementId: 453
Status: current
Reference: RFC 803811.2.3.4. mibModuleName 🦋
Last one in this batch: mibModuleName is the textual name of the MIB module that defines a MIB object 🎀:
Description: The textual name of the MIB module that defines a MIB
object.
Abstract Data Type: string
Data Type Semantics: default
ElementId: 454
Status: current
Reference: RFC 803812. References 📚
12.1. Normative References
Okay bestie, these are the must-reads 📚✨ Everything below is the stuff the spec leans on hard, so it's giving foundation 🏛️
[IANA-IPFIX]IANA, "IP Flow Information Export (IPFIX) Entities",<http://www.iana.org/assignments/ipfix/>. 🌸[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<http://www.rfc-editor.org/info/rfc2119>. 🔑[RFC2578]McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999,<http://www.rfc-editor.org/info/rfc2578>. 🧩[RFC2856]Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, DOI 10.17487/RFC2856, June 2000,<http://www.rfc-editor.org/info/rfc2856>. 💜[RFC3411]Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002,<http://www.rfc-editor.org/info/rfc3411>. 🏗️[RFC6526]Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream", RFC 6526, DOI 10.17487/RFC6526, March 2012,<http://www.rfc-editor.org/info/rfc6526>. 🦋[RFC7011]Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013,<http://www.rfc-editor.org/info/rfc7011>. 👑[RFC7012]Claise, B., Ed., and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013,<http://www.rfc-editor.org/info/rfc7012>. 🎀[X.690]International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015,<https://www.itu.int/rec/T-REC-X.690>. 🧚
12.2. Informative References
Now the extra-credit reading, the stuff that's helpful but not required 🍓 Lowkey my favourite section to browse 🙈
[CISCO-PROCESS-MIB]Cisco Systems Inc., "CISCO-PROCESS-MIB.my: MIB for CPU and process statistics",<ftp://ftp.cisco.com/pub/mibs/v2/CISCO-PROCESS-MIB.my>. 🖥️[RFC2863]McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,<http://www.rfc-editor.org/info/rfc2863>. 🔌[RFC2982]Kavasseri, R., Ed., "Distributed Management Expression MIB", RFC 2982, DOI 10.17487/RFC2982, October 2000,<http://www.rfc-editor.org/info/rfc2982>. 🧮[RFC3414]Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, DOI 10.17487/RFC3414, December 2002,<http://www.rfc-editor.org/info/rfc3414>. 🔐[RFC3415]Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, DOI 10.17487/RFC3415, December 2002,<http://www.rfc-editor.org/info/rfc3415>. 🚪[RFC3444]Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003,<http://www.rfc-editor.org/info/rfc3444>. 🤓[RFC4022]Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, DOI 10.17487/RFC4022, March 2005,<http://www.rfc-editor.org/info/rfc4022>. 🌊[RFC4293]Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, April 2006,<http://www.rfc-editor.org/info/rfc4293>. 🌐[RFC4750]Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, DOI 10.17487/RFC4750, December 2006,<http://www.rfc-editor.org/info/rfc4750>. 🗺️[RFC4960]Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007,<http://www.rfc-editor.org/info/rfc4960>. 🚿[RFC5102]Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, DOI 10.17487/RFC5102, January 2008,<http://www.rfc-editor.org/info/rfc5102>. 📊[RFC5476]Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, DOI 10.17487/RFC5476, March 2009,<http://www.rfc-editor.org/info/rfc5476>. 🎯[RFC5591]Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,<http://www.rfc-editor.org/info/rfc5591>. 🛡️[RFC5592]Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June 2009,<http://www.rfc-editor.org/info/rfc5592>. 🐚[RFC6235]Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,<http://www.rfc-editor.org/info/rfc6235>. 🫥[RFC6313]Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011,<http://www.rfc-editor.org/info/rfc6313>. 📦[RFC6353]Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,<http://www.rfc-editor.org/info/rfc6353>. 🔒
Acknowledgments 🫶
The authors gave a huge shoutout to Andrew Johnson for collaborating on the first draft version of this document, and thanked Andrew Feren and Brian Trammell for their detailed reviews. Iconic behaviour from the whole review squad 👑
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme. Funding that's giving main character energy 🦩✨
Authors' Addresses 📇
Paul Aitken (editor)
Brocade Communications Systems, Inc.
19a Canning Street, Level 3
Edinburgh, Scotland EH3 8EG
United Kingdom
Phone: +44 203 005 0731
Email: paitken@brocade.comBenoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.comSrikar B S
Mojo Networks, Inc.
S. No. 7, Pinnac House II
Kothrud, Pune 411038
India
Phone: +91 94 4847 6672
Email: srikarbs@gmail.comColin McDowall
Brocade Communications Systems, Inc.
19a Canning Street, Level 3
Edinburgh, Scotland EH3 8EG
United Kingdom
Phone: +44 203 005 0687
Email: cmcdowal@brocade.comJuergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1
Bremen 28725
Germany
Phone: +49 421 200 3587
Email: j.schoenwaelder@jacobs-university.de📦 where this page comes from
- ietf: rfc8038 2017-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms