RFC 5815
Definitions of Managed Objects for IP Flow Information Export
RFC 5815 🎀 Definitions of Managed Objects for IP Flow Information Export
Okay bestie, let's start with the ID card 🪪✨ This is RFC 5815, and the title is Definitions of Managed Objects for IP Flow Information Export. Yes, it's a mouthful 💀
The authors are T. Dietz, Ed. (NEC Europe, Ltd.), A. Kobayashi (NTT PF Labs.), B. Claise (Cisco Systems, Inc.), and G. Muenz (Technische Universitaet Muenchen). Five-star girl squad 🫶
It's a Standards Track doc, with ISSN 2070-1721, dated April 2010. The title block doesn't have any Obsoletes or Updates lines, so this header doesn't say it replaces or changes any other RFC 🦋
Abstract 🌸
This doc defines managed objects for IP Flow Information eXport (IPFIX). These objects give you info for monitoring IPFIX Exporters and IPFIX Collectors, including the basic configuration info 💜
Status of This Memo 📜
This is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc5815 🔍
Copyright Notice ©️
Copyright (c) 2010 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) in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. Read the fine print, bestie 🙈
Table of Contents 🗂️
1. Introduction ....................................................3
2. IPFIX Documents Overview ........................................3
3. The Internet-Standard Management Framework ......................4
4. Terminology .....................................................4
5. Structure of the IPFIX MIB ......................................4
5.1. The Transport Session Table ................................4
5.2. The Template Table .........................................7
5.3. The Template Definition Table ..............................9
5.4. The Export Table ..........................................11
5.5. The Metering Process Table ................................12
5.6. The Observation Point Table ...............................13
5.7. The Selection Process Table ...............................14
5.8. The Statistical Tables ....................................15
5.8.1. The Transport Session Statistical Table ............15
5.8.2. The Template Statistical Table .....................15
5.8.3. The Metering Process Statistical Table .............15
5.8.4. The Selection Process Statistical Table ............15
6. Structure of the IPFIX SELECTOR MIB ............................15
6.1. The Selector Functions ....................................16
7. Relationship to Other MIB Modules ..............................18
7.1. Relationship to the ENTITY MIB and IF MIB .................18
7.2. MIB Modules Required for IMPORTS ..........................18
8. MIB Definitions ................................................18
8.1. IPFIX MIB Definition ......................................19
8.2. IPFIX SELECTOR MIB Definition .............................56
9. Security Considerations ........................................60
10. IANA Considerations ...........................................61
11. Acknowledgments ...............................................61
12. References ....................................................62
12.1. Normative References .....................................62
12.2. Informative References ...................................631. Introduction ✨
Okay so this doc defines two MIB modules for monitoring IP Flow Information eXport (IPFIX) Devices, which means both Exporters and Collectors 💅
Most of the objects defined by the IPFIX MIB module MUST be implemented. Some objects MAY be implemented, depending on the functionality the equipment actually has. Since the IPFIX architecture [RFC5470] allows for Filtering and/or Sampling functions to reduce the data volume, this doc also gives you the IPFIX SELECTOR MIB module. It holds the standardized selection methods and is controlled by IANA 🧚 The full configuration of the IPFIX Metering Process is out of scope for these MIB modules, so don't go looking for it here 🙅♀️
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Those capitals are doing serious work, so take them seriously 🔥
2. IPFIX Documents Overview 📚
Main character energy: the IPFIX protocol gives network admins access to IP Flow information 👑 The architecture for exporting measured IP Flow info from an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], following the requirements in [RFC3917]. The protocol doc [RFC5101] specifies how IPFIX Data Records and Templates get carried over a congestion-aware transport protocol from Exporting Processes to Collecting Processes. IPFIX also has a formal description of IPFIX Information Elements (their name, type, and extra semantic info), as specified in [RFC5102]. Finally, [RFC5472] describes what kinds of applications can use IPFIX and how they can use the info it provides. It also shows how the IPFIX framework relates to other architectures and frameworks 🦋
It's assumed that Flow metering, export, and collection are done according to the IPFIX architecture in [RFC5470]. The monitored configuration parameters for exporting and collecting Flow Templates and Data Records are modeled according to [RFC5101]. Packet selection methods that may be optionally used by the IPFIX Metering Process are not covered in this MIB module. They're defined in the Packet Sampling (PSAMP) framework [RFC5474] and the Sampling techniques [RFC5475] documents. Still, the basis for defining Sampling and Filtering functions is given with the IPFIX SELECTOR MIB module 🎀 And since the PSAMP export protocol [RFC5476] is based on IPFIX, Sampling and Filtering functions can be added to the IPFIX SELECTOR MIB module as needed 💖
3. The Internet-Standard Management Framework 🧭
For a detailed overview of the docs that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410] 📖
Managed objects are accessed via a virtual information store called the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580] ✨
4. Terminology 💬
The definitions of basic terms like IP Traffic Flow, Exporting Process, Collecting Process, Observation Points, and so on can be found in the IPFIX protocol document [RFC5101]. Go there, babe 🧸
5. Structure of the IPFIX MIB 🧩
Okay, the IPFIX MIB module has seven main tables: the Transport Session table, the Template table and its corresponding Template Definition table, the Export table, the Metering Process table, the Observation Point table, and the Selection Process table 🍓 Since the IPFIX architecture [RFC5470] allows for Filtering and/or Sampling functions to reduce the data volume, the MIB module gives you the basic objects for these functions through the Selection Process table. The IPFIX SELECTOR MIB module, covered in the next section, provides the standard Filtering and Sampling functions that can be referenced in the ipfixSelectionProcessTable 💅
All remaining objects hold statistical values for the different tables in the MIB module 📊
The following subsections describe all tables in the IPFIX MIB module. Let's go 🚀✨
5.1. The Transport Session Table 🦋
okay so the Transport Session is literally the foundation of this whole MIB module 💅 The Transport Session table (ipfixTransportSessionTable) holds every single Transport Session between an Exporter and a Collector. Each row says which transport layer protocol the session uses, and then, depending on that protocol, it stores the extra details it needs. For UDP and TCP, that means the source and destination address plus the source and destination port 🌸 For Stream Control Transmission Protocol (SCTP), the table holds the SCTP Assoc Id, which is the index for the SCTP association in the SCTP MIB module [RFC3873] 🧚 The device's mode of operation (whether the Transport Session is used for collecting or for exporting) lives in the ipfixTransportSessionDeviceMode object. It also keeps the configured refresh parameters for Templates and Options Templates that get used over unreliable connections like UDP 🔥 And last but not least, the table tells you which IPFIX version is being exported or collected by that session, plus the session's status ✨
Let's make this concrete, bestie. Say we have an Exporter on IP address 192.0.2.22 and a Collector on IP address 192.0.2.37. The Exporter uses TCP to export Templates and Data Records 💖 That same Exporter also exports over UDP to a Collector at 192.0.2.44. So the Exporter's Transport Session table ends up looking like this:
ipfixTransportSessionTable (1)
|
+- ipfixTransportSessionEntry (1)
|
+- index (5) (ipfixTransportSessionIndex)
| +- ipfixTransportSessionIndex (1) = 5
| +- ipfixTransportSessionProtocol (2) = 6 (TCP)
| +- ipfixTransportSessionSourceAddressType (3) = 1 (ipv4)
| +- ipfixTransportSessionSourceAddress (4) = 192.0.2.22
| +- ipfixTransportSessionDestinationAddressType (5) = 1 (ipv4)
| +- ipfixTransportSessionDestinationAddress (6) = 192.0.2.37
| +- ipfixTransportSessionSourcePort (7) = 7653
| +- ipfixTransportSessionDestinationPort (8) = 4739
| +- ipfixTransportSessionSctpAssocId (9) = 0
| +- ipfixTransportSessionDeviceMode (10) = exporting(1)
| +- ipfixTransportSessionTemplateRefreshTimeout (11) = 0
| +- ipfixTransportSessionOptionTemplateRefreshTimeout (12) = 0
| +- ipfixTransportSessionTemplateRefreshPacket (13) = 0
| +- ipfixTransportSessionOptionTemplateRefreshPacket (14) = 0
| +- ipfixTransportSessionIpfixVersion (15) = 10
| +- ipfixTransportSessionStatus (16) = 2 (active)
.
.
.
+- index (11) (ipfixTransportSessionIndex)
+- ipfixTransportSessionIndex (1) = 11
+- ipfixTransportSessionProtocol (2) = 17 (UDP)
+- ipfixTransportSessionSourceAddressType (3) = 1 (ipv4)
+- ipfixTransportSessionSourceAddress (4) = 192.0.2.22
+- ipfixTransportSessionDestinationAddressType (5) = 1 (ipv4)
+- ipfixTransportSessionDestinationAddress (6) = 192.0.2.44
+- ipfixTransportSessionSourcePort (7) = 14287
+- ipfixTransportSessionDestinationPort (8) = 4739
+- ipfixTransportSessionSctpAssocId (9) = 0
+- ipfixTransportSessionDeviceMode (10) = exporting(1)
+- ipfixTransportSessionTemplateRefreshTimeout (11) = 100
+- ipfixTransportSessionOptionTemplateRefreshTimeout (12)
| = 100
+- ipfixTransportSessionTemplateRefreshPacket (13) = 10
+- ipfixTransportSessionOptionTemplateRefreshPacket (14) = 10
+- ipfixTransportSessionIpfixVersion (15) = 10
+- ipfixTransportSessionStatus (16) = 2 (active)The values in brackets are the OID numbers 👑 The Collectors would then have the same entry, except the index would most likely be different and the ipfixTransportSessionDeviceMode would be collecting(2) 🎀
5.2. The Template Table 💜
The Template table lists every Template (including Options Templates) that's sent by an Exporter or received by a Collector 🫶 The (Options) Templates are unique per Transport Session, and that also gives you the device mode (Exporter or Collector) and the Observation Domain. So the table is indexed by:
- the Transport Session Index (
ipfixTransportSessionIndex) - and the Observation Domain Id (
ipfixTemplateObservationDomainId).
It also holds the Set Id and an access time, which is the time the (Options) Template was last sent or received ⏰
To pick up where we left off, the Exporter might want to export a Template and an Options Template for each Transport Session we defined above. That gives us this Template table for the Template and Options Template 🍓
ipfixTemplateTable (3)
|
+- ipfixTemplateEntry (1)
|
+- index (5) (ipfixTransportSessionIndex)
| +- index (3) (ipfixTemplateObservationDomainId)
| + index (257) (ipfixTemplateId)
| | +- ipfixTemplateObservationDomainId (1) = 3
| | +- ipfixTemplateId (2) = 257
| | +- ipfixTemplateSetId (3) = 2
| | +- ipfixTemplateAccessTime (4)
| | = 2008-7-1,12:49:11.2,+2:0
| |
| + index (264) (ipfixTemplateId)
| +- ipfixTemplateObservationDomainId (1) = 3
| +- ipfixTemplateId (2) = 264
| +- ipfixTemplateSetId (3) = 3
| +- ipfixTemplateAccessTime (4)
. = 2008-7-1,12:47:04.8,+2:0
.
.
.
+- index (11) (ipfixTransportSessionIndex)
+- index (3) (ipfixTemplateObservationDomainId)
+ index (273) (ipfixTemplateId)
| +- ipfixTemplateObservationDomainId (1) = 3
| +- ipfixTemplateId (2) = 273
| +- ipfixTemplateSetId (3) = 2
| +- ipfixTemplateAccessTime (4)
| = 2008-7-1,12:49:11.2,+2:0
|
+ index (289) (ipfixTemplateId)
+- ipfixTemplateObservationDomainId (1) = 3
+- ipfixTemplateId (2) = 289
+- ipfixTemplateSetId (3) = 3
+- ipfixTemplateAccessTime (4)
= 2008-7-1,12:47:04.8,+2:0Now let's say the Transport Session stored with index 5 in the Exporter's Transport Session table is stored with index 17 in the (corresponding) Collector's Transport Session table 🦋 Then the Collector's Template table would look like this:
ipfixTemplateTable (3)
|
+- ipfixTemplateEntry (1)
|
+- index (17) (ipfixTransportSessionIndex)
+- index (3) (ipfixTemplateObservationDomainId)
+ index (257) (ipfixTemplateId)
| +- ipfixTemplateObservationDomainId (1) = 3
| +- ipfixTemplateId (2) = 257
| +- ipfixTemplateSetId (3) = 2
| +- ipfixTemplateAccessTime (4)
| = 2008-7-1,12:49:11.8,+2:0
|
+ index (264) (ipfixTemplateId)
+- ipfixTemplateObservationDomainId (1) = 3
+- ipfixTemplateId (2) = 264
+- ipfixTemplateSetId (3) = 3
+- ipfixTemplateAccessTime (4)
= 2008-7-1,12:47:05.3,+2:0The table on the second Collector would be analogous to the one shown above ✨
5.3. The Template Definition Table 🌈
The Template Definition table lists all the Information Elements inside a Template or Options Template 💅 So it uses the same indexes as the matching Template table, plus the Template Id. Its own index tells you the order of each Information Element inside the Template. Besides the Information Element Id and the length of the encoded value, the table stores the enterprise number for enterprise-specific Information Elements, plus flags for each Information Element. Those flags show whether the Information Element is used for scoping or as a Flow Key 🔑
Okay, one more time with the example: the Exporter is set up to export the octets received and dropped at the Observation Point since the last export of those values. On top of that, it exports the start and end time of the Flow relative to the timestamp in the IPFIX header 🙈 That leads to this Template Definition table on the Exporter:
ipfixTemplateDefinitionTable (4)
|
+- ipfixTemplateDefinitionEntry (1)
|
+- index (5) (ipfixTransportSessionIndex)
+- index (3) (ipfixTemplateObservationDomainId)
+ index (257) (ipfixTemplateId)
+- index (1) (ipfixTemplateDefinitionIndex)
| +- ipfixTemplateDefinitionIndex (1) = 1
| +- ipfixTemplateDefinitionIeId (2) = 158
| | (flowStartDeltaMicroseconds)
| +- ipfixTemplateDefinitionIeLength (3) = 4
| +- ipfixTemplateDefinitionEnterprise (4) = 0
| +- ipfixTemplateDefinitionFlags (5) = 0
|
+- index (2) (ipfixTemplateDefinitionIndex)
| +- ipfixTemplateDefinitionIndex (1) = 2
| +- ipfixTemplateDefinitionIeId (2) = 159
| | (flowEndDeltaMicroseconds)
| +- ipfixTemplateDefinitionIeLength (3) = 4
| +- ipfixTemplateDefinitionEnterprise (4) = 0
| +- ipfixTemplateDefinitionFlags (5) = 0
|
+- index (3) (ipfixTemplateDefinitionIndex)
| +- ipfixTemplateDefinitionIndex (1) = 3
| +- ipfixTemplateDefinitionIeId (2) = 1
| | (octetDeltaCount)
| +- ipfixTemplateDefinitionIeLength (3) = 8
| +- ipfixTemplateDefinitionEnterprise (4) = 0
| +- ipfixTemplateDefinitionFlags (5) = 0
|
+- index (4) (ipfixTemplateDefinitionIndex)
+- ipfixTemplateDefinitionIndex (1) = 4
+- ipfixTemplateDefinitionIeId (2) = 132
| (droppedOctetDeltaCount)
+- ipfixTemplateDefinitionIeLength (3) = 8
+- ipfixTemplateDefinitionEnterprise (4) = 0
+- ipfixTemplateDefinitionFlags (5) = 0The corresponding table entry on the Collector is the same, except it would have a different ipfixTransportSessionIndex, e.g., 17 as in the previous example 🎀
5.4. The Export Table 🚚
Okay so on Exporters, the Export table (ipfixExportTable) is the thing that unlocks features like failover, load-balancing, and duplicate export to several Collectors. 💅 The table has three indexes that link an entry with:
- the Metering Process table (ipfixMeteringProcessCacheId, see below)
- and the Transport Session table (ipfixTransportSessionIndex).
Entries that share the same ipfixExportIndex and the same ipfixMeteringProcessCacheId form a Transport Session group. ✨ Each group member's member type tells you what that member is doing. Also, every Transport Session referenced in this table MUST have the ipfixTransportSessionDeviceMode exporting(1). That one's not optional, bestie 🙅♀️
If the Exporter doesn't use Transport Session grouping, then each ipfixExportIndex holds a single ipfixMeteringProcessCacheId, which means a single Transport Session (ipfixTransportSessionIndex). In that case, the session MUST have the member type primary(1). 🌸
For failover, a Transport Session group can contain one Transport Session with member type "primary" plus several Transport Sessions with type secondary(2). Other member types aren't allowed for that kind of group, so no sneaking them in 🙈 For load-balancing or parallel export, all Transport Sessions in the group MUST have the same member type, either loadBalancing(4) or parallel(3). 🔥
The algorithms used for failover or load-balancing are out of the scope of this document. That's a whole other story, not this spec 📖
To keep going with the example, we're going to say the Exporter uses the two connections from the examples above as one primary Transport Session protected by a secondary Transport Session. 🦋 The Exporter then ends up with these entries in the ipfixExportTable:
ipfixExportTable (5)
|
+- ipfixExportEntry (1)
|
+- index (7) (ipfixExportIndex)
| +- index (9) (ipfixMeteringProcessCacheId)
| | +- index (5) (ipfixTransportSessionIndex)
| | +- ipfixExportIndex (1) = 7
| | +- ipfixExportMemberType (2) = 1 (primary)
| |
| +- index (11) (ipfixTransportSessionIndex)
| +- ipfixExportIndex (1) = 7
| +- ipfixExportMemberType (2) = 2 (secondary)
|
+- index (8) (ipfixExportIndex)
+- index (9) (ipfixMeteringProcessCacheId)
+- index (5) (ipfixTransportSessionIndex)
| +- ipfixExportIndex (1) = 8
| +- ipfixExportMemberType (2) = 2 (secondary)
+- index (11) (ipfixTransportSessionIndex)
+- ipfixExportIndex (1) = 8
+- ipfixExportMemberType (2) = 1 (primary)So this shows the Exporter using Metering Process Cache 9 (explained below) to export IPFIX Data Records for Transport Sessions 5 and 11. 🧚 Templates 257 and 264 (defined above) get exported within Transport Session 5, and Templates 273 and 289 get exported within Transport Session 11. If we assume Templates 257 and 264 are identical, then the Collector receiving Transport Session 11 is a backup for the Collector of Transport Session 5. It's giving redundancy 💖
5.5. The Metering Process Table ⏱️
The Metering Process, as defined in [RFC5101], is a set of functions. ✨ Maintaining the Flow Records is one of them. This function passes the Flow Records to the Exporting Process and also detects Flow expiration. The Flow Records maintained by the Metering Process can be grouped by the Observation Points where they're observed. The instance that maintains a group like that is a kind of cache, so the Metering Process table (ipfixMeteringProcessTable) is indexed by cache Ids (ipfixMeteringProcessCacheId). Each cache can be maintained by a separate instance of the Metering Process. 🎀
To say where the Flow Records are gathered, the ipfixMeteringProcessObservationPointGroupRef may contain an ipfixObservationPointGroupId from the Observation Point table (ipfixObservationPointTable), which we'll get to in the next section. If no Observation Point is specified for the Flow Records, the ipfixMeteringProcessObservationPointGroupRef MUST be zero(0). 🙅♀️ The timeouts (ipfixMeteringProcessCacheActiveTimeout and ipfixMeteringProcessCacheInactiveTimeout) are what decide when Flows expire. ⏳
ipfixMeteringProcessTable (6)
|
+- ipfixMeteringProcessEntry (1)
|
+- index (9) (ipfixMeteringProcessCacheId)
+- ipfixMeteringProcessCacheId (1) = 9
+- ipfixMeteringProcessObservationPointGroupRef (2) = 17
+- ipfixMeteringProcessCacheActiveTimeout (3) = 100
+- ipfixMeteringProcessCacheInactiveTimeout (4) = 1005.6. The Observation Point Table 👀
The Observation Point table (ipfixObservationPointTable) groups Observation Points by ipfixObservationPointGroupId. 💜 Each entry holds the Observation Domain Id where the Observation Point lives, plus a reference to either the ENTITY MIB module [RFC4133] or the IF MIB module [RFC2863]. The objects in the ENTITY MIB module referenced by ipfixObservationPointPhysicalEntity (or the IF MIB module object referenced by ipfixObservationPointPhysicalInterface) are what denote the Observation Point. If no such index can be given in those modules, the references MUST be 0. 🙈
If a reference is given in both ipfixObservationPointPhysicalEntity and ipfixObservationPointPhysicalInterface, then both MUST point to the same physical interface. No mixing it up! 😤 On top of that, a direction can be given to specify more precisely which Flow to monitor. 🧭
ipfixObservationPointTable (7)
|
+- ipfixObservationPointEntry (1)
|
+- index (17) (ipfixObservationPointGroupId)
+- index (1) (ipfixObservationPointIndex)
| +- ipfixObservationPointGroupId (1) = 17
| +- ipfixObservationPointIndex (2) = 1
| +- ipfixObservationPointObservationDomainId (3) = 3
| +- ipfixObservationPointPhysicalEntity (4) = 6
| +- ipfixObservationPointPhysicalInterface(5) = 0
| +- ipfixObservationPointPhysicalEntityDirection (6)
= 3 (both)
|
+- index (2) (ipfixObservationPointIndex)
+- ipfixObservationPointGroupId (1) = 17
+- ipfixObservationPointIndex (2) = 2
+- ipfixObservationPointObservationDomainId (3) = 3
+- ipfixObservationPointPhysicalEntity (4) = 0
+- ipfixObservationPointPhysicalInterface (5) = 0
+- ipfixObservationPointPhysicalEntityDirection (6)
= 1 (ingress)5.7. The Selection Process Table 🎯
This table supports the Filtering and Sampling functions described in [RFC5470]. ✨ It holds lists of functions per Metering Process cache (ipfixMeteringProcessCacheId). The selection process index (ipfixSelectionProcessIndex) forms groups of selection methods that get applied to an observed packet stream. 🌊 The selection process selector index (ipfixSelectionProcessSelectorIndex) tells you the order the functions run in, for packets observed at the Observation Points tied to the Metering Process cache.
The selection methods are applied in increasing order, so a selection method with a lower ipfixSelectionProcessSelectorIndex goes first. 🥇 The functions are referenced by object identifiers that point to the function along with its parameters. If the selection method doesn't use parameters, then it MUST point to the root of the function subtree (see also Section 6). If the function does use parameters, then it MUST point to an entry in the parameter table of the selection method. 💅 And if no Filtering or Sampling function is used for a Metering Process, then an entry for that Metering Process SHOULD be created, pointing to the Select All function (ipfixFuncSelectAll).
5.8. The Statistical Tables 📊
The ipfixTransportSessionTable, the ipfixTemplateTable, the ipfixMeteringProcessTable, and the ipfixSelectionProcessTable each get statistical tables that augment them. 🧁 All the statistical tables contain a discontinuity object, which holds a timestamp for when a discontinuity event happened. That timestamp is there to tell the management system that the counters in those tables might not be continuous anymore. Plot twist, the numbers might have a gap in them 😭
5.8.1. The Transport Session Statistical Table 📨
The Transport Session Statistical table (ipfixTransportSessionStatsTable) augments the ipfixTransportSessionTable with statistical values. It tracks the rate (in bytes per second) at which IPFIX Messages are received or sent out, plus the number of bytes, packets, messages, Records, Templates, and Options Templates received or sent, and the number of messages that got discarded. 📈
5.8.2. The Template Statistical Table 📋
This table contains a statistical value for each Template. It augments the Template table (ipfixTemplateTable) and specifies the number of Data Records exported or collected for the Template. 🙌
5.8.3. The Metering Process Statistical Table ⚙️
This table augments the Metering Process table (ipfixMeteringProcessTable). It holds the statistical values for the exported Data Records and the number of unused cache entries. 🗂️
5.8.4. The Selection Process Statistical Table 🔍
This table augments the Selection Process table (ipfixSelectionProcessTable) and introduces two generic statistical values: the number of packets observed and the number of packets dropped by the selection method. 🫶
6. Structure of the IPFIX SELECTOR MIB 🧩
The IPFIX SELECTOR MIB module defined in this section provides the standard Filtering and Sampling functions that can be referenced in the ipfixSelectionProcessTable. ✨ The subtree ipfixSelectorFunctions is a placeholder where all the standard Filtering and Sampling functions should be located. Right now it only has the Select All function (ipfixFuncSelectAll). 🌈
The IPFIX SELECTOR MIB module is maintained by IANA and can be extended through Expert Review [RFC5226], which means review by one of a group of experts designated by an IETF Area Director. 👑 That group of experts MUST check the requested MIB objects for completeness and accuracy of the description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. 🙅♀️ The smallest available OID SHOULD be assigned to a new MIB object. The specification of new MIB objects SHOULD follow the structure specified in the next Section, and MUST be published using a well-established and persistent publication medium. 📚 The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups.
6.1. The Selector Functions ✨
okay so this is what the MIB tree usually should look like 🌸 It already has the ipfixFuncSelectAll in it, and the ipfixFuncF2 subtree shows the basic structure that every selection method SHOULD follow 💅
ipfixSelectorFunctions
|
+- ipfixFuncSelectAll
| |
| +- ipfixFuncSelectAllAvail (is the function available?)
|
+- ipfixFuncF2
| |
| +- ipfixFuncF2Avail (is the function F2 available?)
| |
| +- ipfixFuncF2Parameters (a table with parameters)
...
|
+- ipfixFunFn...so the selection method SHOULD be designed as a MIB subtree that starts with an object named ipfixFunc plus the function name 🦋 The objects in that subtree SHOULD be prefixed by that same name. If the function is called Fx, you start a subtree with an OID named ipfixFuncFx. This subtree should contain an object called ipfixFuncFxAvail, and its type is TruthValue. If the selection method takes parameters, the MIB should contain a table called ipfixFuncFxParameters, and it should hold every parameter the selection method specifies. The IPFIX MIB module references an entry in this table whenever the selection method with parameters is used 🎀
here's an example to make it click! 🧚 We have a function called MyFunc with three integer parameters, Param1, Param2, and Param3. In this example there are two instances of the parameter set, with indexes 1 and 4.
ipfixSelectorFunctions (1)
|
+- ipfixFuncMyFunc (?)
|
+- ipfixFuncMyFuncAvail (1) = true
+- ipfixFuncMyFuncParameters (2)
|
+- ipfixFuncMyFuncParametersEntry (1)
|
+- index (1) (ipfixFuncMyFuncParametersIndex)
| +- ipfixFuncMyFuncParam1 (1) = 47
| +- ipfixFuncMyFuncParam2 (2) = -128
| +- ipficFuncMyFuncParam3 (3) = 19
|
+- index(4) (ipfixFuncMyFuncParametersIndex)
+- ipfixFuncMyFuncParam1 (1) = 19
+- ipfixFuncMyFuncParam2 (2) = -1
+- ipficFuncMyFuncParam3 (3) = 728if MyFunc is referenced in the IPFIX MIB module, the ipfixSelectionProcessTable ends up looking like this 👑
ipfixSelectionProcessTable (8)
|
+- ipfixSelectionProcessEntry (1)
|
+- index (9) (ipfixMeteringProcessCacheId)
+- index (1) (ipfixSelectionProcessIndex)
+- index (1) (ipfixSelectionProcessSelectorIndex)
| +- ipfixSelectionProcessSelectorFunction (3)
| = ipfixSelectorFunctions.?.2.1.4
+- index (2) (ipfixSelectionProcessSelectorIndex)
+- ipfixSelectionProcessSelectorFunction (3)
= ipfixSelectorFunctions.?.2.1.1so for ipfixMeteringProcessCacheId(9), a Selection Process with index 1 gets created, and it applies the same function twice with two different parameter sets 🍓 First MyFunc runs with the parameters from set 4, and then it runs again with the parameters from set 1 💜
7. Relationship to Other MIB Modules ✨
besides the usual imports from the SNMP Standards [RFC2578], [RFC2579], and [RFC2580], the IPFIX MIB module also references the ENTITY MIB module [RFC4133] and the IF MIB module [RFC2863] 🌈
7.1. Relationship to the ENTITY MIB and IF MIB
the Observation Point table (ipfixObservationPointTable) has a reference to the ENTITY MIB module[RFC4133] (ipfixObservationPointPhysicalEntity) or to the IF MIB module [RFC2863] (ipfixObservationPointPhysicalInterface). if the implementors want to specify the physical entity where Flows get observed, then they SHOULD also implement the ENTITY MIB and/or the IF MIB module 🔥 Implementing the ENTITY MIB and/or IF MIB module is OPTIONAL, though 🙈 If one of them isn't implemented, then every value in the matching column, ipfixObservationPointPhysicalEntity or ipfixObservationPointPhysicalInterface in the Observation Point table, is zero. And the values in the ipfixObservationPointPhysicalEntityDirection columns are unknown(0), as long as none of them are defined 💀
7.2. MIB Modules Required for IMPORTS
the IPFIX MIB module requires SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580]. it also imports the textual conventions InetAddressType and InetAddress from the INET ADDRESS MIB module [RFC4001] 🫶
the IPFIX SELECTOR MIB module also requires SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580] 🦋
8. MIB Definitions ✨
this section has the definitions for the IPFIX-MIB module and the IPFIX-SELECTOR-MIB module 🎀 There are different mandatory groups for Collector and Exporter implementations, and the statistical objects are made OPTIONAL 💖
8.1. IPFIX MIB Definition
IPFIX-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, mib-2, Unsigned32, Counter64,
Gauge32
FROM SNMPv2-SMI -- RFC2578
TimeStamp, DateAndTime
FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- RFC2580
InterfaceIndexOrZero
FROM IF-MIB -- RFC2863
InetAddressType, InetAddress, InetPortNumber
FROM INET-ADDRESS-MIB -- RFC4001
PhysicalIndexOrZero
FROM ENTITY-MIB; -- RFC4133
ipfixMIB MODULE-IDENTITY
LAST-UPDATED "201004190000Z" -- 19 April 2010
ORGANIZATION "IETF IPFIX Working Group"
CONTACT-INFO
"WG charter:
http://www.ietf.org/html.charters/ipfix-charter.html
Mailing Lists:
General Discussion: ipfix@ietf.org
To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix
Archive:
http://www1.ietf.org/mail-archive/web/ipfix/current/index.html
Editor:
Thomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-128
Email: Thomas.Dietz@nw.neclab.eu
Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi
180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Gerhard Muenz
Technische Universitaet Muenchen
Department of Informatics
Chair for Network Architectures and Services (I8)
Boltzmannstr. 3
85748 Garching
Germany
Phone: +49 89 289-18008
Email: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz"
DESCRIPTION
"The IPFIX MIB defines managed objects for IP Flow
Information eXport. These objects provide information about
managed nodes supporting the IPFIX protocol,
for Exporters as well as for Collectors.
Copyright (c) 2010 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
-- Revision history
REVISION "201004190000Z" -- 19 April 2010
DESCRIPTION
"Initial version, published as RFC 5815."
::= { mib-2 193 }
--******************************************************************
-- Top Level Structure of the MIB
--******************************************************************
ipfixObjects OBJECT IDENTIFIER ::= { ipfixMIB 1 }
ipfixConformance OBJECT IDENTIFIER ::= { ipfixMIB 2 }
ipfixMainObjects OBJECT IDENTIFIER ::= { ipfixObjects 1 }
ipfixStatistics OBJECT IDENTIFIER ::= { ipfixObjects 2 }
--==================================================================
-- 1.1: Objects used by all IPFIX implementations
--==================================================================
--------------------------------------------------------------------
-- 1.1.1: Transport Session Table
--------------------------------------------------------------------
ipfixTransportSessionTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixTransportSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the currently established Transport
Sessions between an Exporting Process and a Collecting
Process."
::= { ipfixMainObjects 1 }
ipfixTransportSessionEntry OBJECT-TYPE
SYNTAX IpfixTransportSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixTransportSessionTable."
INDEX { ipfixTransportSessionIndex }
::= { ipfixTransportSessionTable 1 }
IpfixTransportSessionEntry ::=
SEQUENCE {
ipfixTransportSessionIndex Unsigned32,
ipfixTransportSessionProtocol Unsigned32,
ipfixTransportSessionSourceAddressType InetAddressType,
ipfixTransportSessionSourceAddress InetAddress,
ipfixTransportSessionDestinationAddressType InetAddressType,
ipfixTransportSessionDestinationAddress InetAddress,
ipfixTransportSessionSourcePort InetPortNumber,
ipfixTransportSessionDestinationPort InetPortNumber,
ipfixTransportSessionSctpAssocId Unsigned32,
ipfixTransportSessionDeviceMode INTEGER,
ipfixTransportSessionTemplateRefreshTimeout Unsigned32,
ipfixTransportSessionOptionsTemplateRefreshTimeout Unsigned32,
ipfixTransportSessionTemplateRefreshPacket Unsigned32,
ipfixTransportSessionOptionsTemplateRefreshPacket Unsigned32,
ipfixTransportSessionIpfixVersion Unsigned32,
ipfixTransportSessionStatus INTEGER
}
ipfixTransportSessionIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Locally arbitrary, but unique identifier of an entry in
the ipfixTransportSessionTable. The value is expected to
remain constant from a re-initialization of the entity's
network management agent to the next re-initialization."
::= { ipfixTransportSessionEntry 1 }okay bestie, this part is all about the ipfixTransportSessionEntry columns, and each one describes a little piece of a transport session 🦋✨
ipfixTransportSessionProtocol OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The transport protocol used for receiving or transmitting
IPFIX Messages. Protocol numbers are assigned by IANA. A
current list of all assignments is available from
<http://www.iana.org/>."
REFERENCE
"RFC 5101, Specification of the IP Flow
Information Export (IPFIX) Protocol for the Exchange of IP
Traffic Flow Information, Section 10."
::= { ipfixTransportSessionEntry 2 }
ipfixTransportSessionSourceAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of address used for the source address,
as specified in RFC 4001. This object is used with protocols
(specified in ipfixTransportSessionProtocol) like TCP (6)
and UDP (17) that have the notion of addresses. SCTP (132)
should use the ipfixTransportSessionSctpAssocId instead.
If SCTP (132) or any other protocol without the notion of
addresses is used, the object MUST be set to unknown(0)."
::= { ipfixTransportSessionEntry 3 }
ipfixTransportSessionSourceAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The source address of the Exporter of the IPFIX Transport
Session. This value is interpreted according to the value of
ipfixTransportSessionAddressType as specified in RFC 4001.
This object is used with protocols (specified in
ipfixTransportSessionProtocol) like TCP (6) and UDP (17) that
have the notion of addresses. SCTP (132) should use the
ipfixTransportSessionSctpAssocId instead. If SCTP (132) or
any other protocol without the notion of addresses is used,
the object MUST be set to a zero-length string."
::= { ipfixTransportSessionEntry 4 }
ipfixTransportSessionDestinationAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of address used for the destination address,
as specified in RFC 4001. This object is used with protocols
(specified in ipfixTransportSessionProtocol) like TCP (6)
and UDP (17) that have the notion of addresses. SCTP (132)
should use the ipfixTransportSessionSctpAssocId instead.
If SCTP (132) or any other protocol without the notion of
addresses is used, the object MUST be set to unknown(0)."
::= { ipfixTransportSessionEntry 5 }
ipfixTransportSessionDestinationAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The destination address of the Collector of the IPFIX
Transport Session. This value is interpreted according to
the value of ipfixTransportSessionAddressType, as specified
in RFC 4001. This object is used with protocols
(specified in ipfixTransportSessionProtocol) like TCP (6)
and UDP (17) that have the notion of addresses. SCTP (132)
should use the ipfixTransportSessionSctpAssocId instead.
If SCTP (132) or any other protocol without the notion of
addresses is used, the object MUST be set to a zero-length
string"
::= { ipfixTransportSessionEntry 6 }
ipfixTransportSessionSourcePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The transport protocol port number of the Exporter.
This object is used with protocols (specified in
ipfixTransportSessionProtocol) like TCP (6)
and UDP (17) that have the notion of ports. SCTP (132)
should copy the value of sctpAssocLocalPort if the
Transport Session is in collecting mode or
sctpAssocRemPort if the Transport Session is in
exporting mode. The association is referenced
by the ipfixTransportSessionSctpAssocId.
If any other protocol without the notion of
ports is used, the object MUST be set to zero."
::= { ipfixTransportSessionEntry 7 }
ipfixTransportSessionDestinationPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The transport protocol port number of the Collector. The
default value is 4739 for all currently defined transport
protocol types. This object is used with protocols
(specified in ipfixTransportSessionProtocol) like TCP (6)
and UDP (17) that have the notion of ports. SCTP (132)
should copy the value of sctpAssocRemPort if the
Transport Session is in collecting mode or
sctpAssocLocalPort if the Transport Session is in
exporting mode. The association is referenced
by the ipfixTransportSessionSctpAssocId.
If any other protocol without the notion of
ports is used, the object MUST be set to zero."
::= { ipfixTransportSessionEntry 8 }
ipfixTransportSessionSctpAssocId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The association id used for the SCTP session between the
Exporter and the Collector of the IPFIX Transport Session.
It is equal to the sctpAssocId entry in the sctpAssocTable
defined in the SCTP MIB. This object is only valid if
ipfixTransportSessionProtocol has the value 132 (SCTP). In
all other cases, the value MUST be zero."
REFERENCE
"RFC 3873, Stream Control Transmission Protocol (SCTP)
Management Information Base (MIB)."
::= { ipfixTransportSessionEntry 9 }
ipfixTransportSessionDeviceMode OBJECT-TYPE
SYNTAX INTEGER {
exporting(1),
collecting(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The mode of operation of the device for the given Transport
Session. This object can have the following values:
exporting(1)
This value MUST be used if the Transport Session is
used for exporting Records to other IPFIX Devices,
i.e., this device acts as Exporter.
collecting(2)
This value MUST be used if the Transport Session is
used for collecting Records from other IPFIX Devices,
i.e., this device acts as Collector."
::= { ipfixTransportSessionEntry 10 }
ipfixTransportSessionTemplateRefreshTimeout OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"On Exporters, this object contains the time in seconds
after which IPFIX Templates are resent by the
Exporter.
On Collectors, this object contains the lifetime in seconds
after which a Template becomes invalid when it is not
received again within this lifetime.
This object is only valid if ipfixTransportSessionProtocol
has the value 17 (UDP). In all other cases, the value MUST
be zero."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Sections 10.3.6 and 10.3.7."
::= { ipfixTransportSessionEntry 11 }
ipfixTransportSessionOptionsTemplateRefreshTimeout OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"On Exporters, this object contains the time in seconds
after which IPFIX Options Templates are resent by the
Exporter.
On Collectors, this object contains the lifetime in seconds
after which an Options Template becomes invalid when it is
not received again within this lifetime.
This object is only valid if ipfixTransportSessionProtocol
has the value 17 (UDP). In all other cases the value MUST
be zero."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Sections 10.3.6 and 10.3.7."
::= { ipfixTransportSessionEntry 12 }
ipfixTransportSessionTemplateRefreshPacket OBJECT-TYPE
SYNTAX Unsigned32
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"On Exporters, this object contains the number of exported
IPFIX Messages after which IPFIX Templates are resent
by the Exporter.
On Collectors, this object contains the lifetime in number
of exported IPFIX Messages after which a Template becomes
invalid when it is not received again within this lifetime.
This object is only valid if ipfixTransportSessionProtocol
has the value 17 (UDP). In all other cases the value MUST
be zero."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Sections 10.3.6 and 10.3.7."
::= { ipfixTransportSessionEntry 13 }
ipfixTransportSessionOptionsTemplateRefreshPacket OBJECT-TYPE
SYNTAX Unsigned32
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"On Exporters, this object contains the number of exported
IPFIX Messages after which IPFIX Options Templates are
resent by the Exporter.
On Collectors, this object contains the lifetime in number
of exported IPFIX Messages after which an Options Template
becomes invalid when it is not received again within this
lifetime.
This object is only valid if ipfixTransportSessionProtocol
has the value 17 (UDP). In all other cases the value MUST
be zero."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Sections 10.3.6 and 10.3.7."
::= { ipfixTransportSessionEntry 14 }
ipfixTransportSessionIpfixVersion OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"On Exporters the object contains the version number of the
IPFIX protocol that the Exporter uses to export its data in
this Transport Session.
On Collectors the object contains the version number of the
IPFIX protocol it receives for this Transport Session.
If IPFIX Messages of different IPFIX protocol versions are
transmitted or received in this Transport Session, this
object contains the maximum version number."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Section 3.1."
::= { ipfixTransportSessionEntry 15 }okay bestie, we're still deep in the MIB, and this part is all about the Transport Session status and the template tables 💜 these objects are how the MIB tracks what each session is doing and which templates are in play 🦋
ipfixTransportSessionStatus OBJECT-TYPE
SYNTAX INTEGER {
unknown(0),
inactive(1),
active(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of a Transport Session. This object can have the
following values:
unknown(0)
This value MUST be used if the status of the
Transport Session cannot be detected by the equipment.
This value should be avoided as far as possible.
inactive(1)
This value MUST be used for Transport Sessions that
are specified in the system but are not currently active.
The value can be used, e.g., for Transport Sessions that
are backup (secondary) sessions in a Transport Session
group.
active(2)
This value MUST be used for Transport Sessions that are
currently active and transmitting or receiving data."
::= { ipfixTransportSessionEntry 16 }ok so the status object is giving "is this session alive right now?" 🌸 three values: unknown(0) when the box can't tell, inactive(1) for sessions that exist on paper but aren't running (think backup sessions in a group 👀), and active(2) for sessions that are actually sending or receiving data ✨
--------------------------------------------------------------------
-- 1.1.2: Template Table
--------------------------------------------------------------------
ipfixTemplateTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixTemplateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the Templates and Options Templates that
are transmitted by the Exporting Process or received by the
Collecting Process.
The table contains the Templates and Options Templates that
are received or used for exporting data for a given
Transport Session group and Observation Domain.
Withdrawn or invalidated (Options) Template MUST be removed
from this table."
::= { ipfixMainObjects 2 }
ipfixTemplateEntry OBJECT-TYPE
SYNTAX IpfixTemplateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixTemplateTable."
INDEX {
ipfixTransportSessionIndex,
ipfixTemplateObservationDomainId,
ipfixTemplateId
}
::= { ipfixTemplateTable 1 }
IpfixTemplateEntry ::=
SEQUENCE {
ipfixTemplateObservationDomainId Unsigned32,
ipfixTemplateId Unsigned32,
ipfixTemplateSetId Unsigned32,
ipfixTemplateAccessTime DateAndTime
}
ipfixTemplateObservationDomainId OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Id of the Observation Domain for which this Template
is defined. This value is used when sending IPFIX Messages.
The special value of 0 indicates that the Data Records
exported with this (Option Template) cannot be applied to a
single Observation Domain."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Section 3.1."
::= { ipfixTemplateEntry 1 }
ipfixTemplateId OBJECT-TYPE
SYNTAX Unsigned32 (256..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This number indicates the Template Id in the IPFIX
Message. Values from 0 to 255 are not allowed for Template
Ids."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Section 3.4.1."
::= { ipfixTemplateEntry 2 }
ipfixTemplateSetId OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This number indicates the Set Id of the Template. This
object allows to easily retrieve the Template type.
Currently, there are two values defined. The value 2 is
used for Sets containing Template definitions. The value 3
is used for Sets containing Options Template definitions."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Section 3.3.2."
::= { ipfixTemplateEntry 3 }
ipfixTemplateAccessTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the Transport Session is in exporting mode
(ipfixTransportSessionDeviceMode) the time when this
(Options) Template was last sent to the Collector(s).
In the specific case of UDP as transport protocol, this
time is used to know when a retransmission of the
(Options) Template is needed.
If it is in collecting mode, this object contains the
time when this (Options) Template was last received from
the Exporter. In the specific case of UDP as transport
protocol, this time is used to know when this (Options)
Template times out and thus is no longer valid."
::= { ipfixTemplateEntry 4 }the template table is basically the big list of every Template and Options Template floating around, indexed by session, observation domain, and template Id 🧚 the big rule here is that withdrawn or invalidated templates MUST get removed, no exceptions bestie 🙈
the access time column is where the drama lives: on exporters it's when the template was last sent, and on collectors it's when it was last received, and for UDP that timestamp is what decides when a template needs resending or when it times out 😭
--------------------------------------------------------------------
-- 1.1.3: Exported Template Definition Table
--------------------------------------------------------------------
ipfixTemplateDefinitionTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixTemplateDefinitionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"On Exporters, this table lists the (Options) Template fields
of which a (Options) Template is defined. It defines the
(Options) Template given in the ipfixTemplateId specified in
the ipfixTemplateTable.
On Collectors, this table lists the (Options) Template fields
of which a (Options) Template is defined. It defines the
(Options) Template given in the ipfixTemplateId specified in
the ipfixTemplateTable."
::= { ipfixMainObjects 3 }
ipfixTemplateDefinitionEntry OBJECT-TYPE
SYNTAX IpfixTemplateDefinitionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixTemplateDefinitionTable."
INDEX {
ipfixTransportSessionIndex,
ipfixTemplateObservationDomainId,
ipfixTemplateId,
ipfixTemplateDefinitionIndex
}
::= { ipfixTemplateDefinitionTable 1 }
IpfixTemplateDefinitionEntry ::=
SEQUENCE {
ipfixTemplateDefinitionIndex Unsigned32,
ipfixTemplateDefinitionIeId Unsigned32,
ipfixTemplateDefinitionIeLength Unsigned32,
ipfixTemplateDefinitionEnterpriseNumber Unsigned32,
ipfixTemplateDefinitionFlags BITS
}
ipfixTemplateDefinitionIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The ipfixTemplateDefinitionIndex specifies the order in
which the Information Elements are used in the (Options)
Template Record.
Since a Template Record can contain a maximum of 65535
Information Elements, the index is limited to this value."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Sections 3.4.1 and 3.4.2."
::= { ipfixTemplateDefinitionEntry 1 }
ipfixTemplateDefinitionIeId OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the Information Element Id at position
ipfixTemplateDefinitionIndex in the (Options) Template
ipfixTemplateId. This implicitly specifies the data type
of the Information Element. The elements are registered
at IANA. A current list of assignments can be found at
<http://www.iana.org/assignments/ipfix>"
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Section 3.2.
RFC 5102, Information Model for IP Flow Information Export."
::= { ipfixTemplateDefinitionEntry 2 }
ipfixTemplateDefinitionIeLength OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the length of the Information Element Id at
position ipfixTemplateDefinitionIndex in the (Options)
Template ipfixTemplateId."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Section 3.2.
RFC 5102, Information Model for IP Flow Information Export."
::= { ipfixTemplateDefinitionEntry 3 }
ipfixTemplateDefinitionEnterpriseNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"IANA enterprise number of the authority defining the
Information Element identifier in this Template Record.
Enterprise numbers are assigned by IANA. A current list of
all assignments is available from
<http://www.iana.org/assignments/enterprise-numbers/>.
This object must be zero(0) for all standard Information
Elements registered with IANA. A current list of these
elements is available from
<http://www.iana.org/assignments/ipfix/ipfix.xhtml>."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Section 3.2.
RFC 5102, Information Model for IP Flow Information Export."
::= { ipfixTemplateDefinitionEntry 4 }
ipfixTemplateDefinitionFlags OBJECT-TYPE
SYNTAX BITS {
scope(0),
flowKey(1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This bitmask indicates special attributes for the
Information Element:
scope(0)
This Information Element is used for scope.
flowKey(1)
This Information Element is a Flow Key.
Thus, we get the following values for an Information Element:
If neither bit scope(0) nor bit flowKey(1) are set
The Information Element is neither used for scoping nor
as Flow Key.
If only bit scope(0) is set
The Information Element is used for scoping.
If only bit flowKey(1) is set
The Information Element is used as Flow Key.
Both bit scope(0) and flowKey(1) MUST NOT be set at the same
time. This combination is not allowed."
REFERENCE
"RFC 5101, Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic Flow
Information, Sections 2 and 3.4.2.1.
RFC 5102, Information Model for IP Flow Information Export."
::= { ipfixTemplateDefinitionEntry 5 }the definition table is where each template's fields get spelled out, one row per Information Element 🎀 and the flags column is so iconic: scope(0) and flowKey(1) can each be set on their own, but both at once is a big no, periodt 💅
Okay bestie, the MIB definitions keep going 🎀 these tables are where the Export, Metering Process, and Observation Point stuff lives, so read every line 💅
--------------------------------------------------------------------
-- 1.1.4: Export Table
--------------------------------------------------------------------
ipfixExportTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixExportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists all exports of an IPFIX device.
On Exporters, this table contains all exports grouped by
Transport Session, Observation Domain Id, Template Id, and
Metering Process represented by the
ipfixMeteringProcessCacheId. Thanks to the ipfixExportIndex,
the exports can group one or more Transport Sessions to
achieve a special functionality like failover management,
load-balancing, etc. The entries with the same
ipfixExportIndex, ipfixObservationDomainId,
and ipfixMeteringProcessCacheId define a Transport
Session group. If the Exporter does not use Transport
Session grouping, then each ipfixExportIndex contains a
single ipfixMeteringProcessCacheId and thus a singe
Transport Session, and this session MUST have the member
type primary(1). Transport Sessions referenced in this
table MUST have the ipfixTransportSessionDeviceMode
exporting(1).
On Collectors, this table is not needed."
::= { ipfixMainObjects 4 }
ipfixExportEntry OBJECT-TYPE
SYNTAX IpfixExportEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixExportTable."
INDEX {
ipfixExportIndex,
ipfixMeteringProcessCacheId,
ipfixTransportSessionIndex
}
::= { ipfixExportTable 1 }
IpfixExportEntry ::=
SEQUENCE {
ipfixExportIndex Unsigned32,
ipfixExportMemberType INTEGER
}
ipfixExportIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Locally arbitrary, but unique identifier of an entry in
the ipfixExportTable. The value is expected
to remain constant from a re-initialization of the entity's
network management agent to the next re-initialization.
A common ipfixExportIndex between two entries from this
table expresses that there is a relationship between the
Transport Sessions in ipfixTransportSessionIndex. The type
of relationship is expressed by the value of
ipfixExportMemberType."
::= { ipfixExportEntry 1 }
ipfixExportMemberType OBJECT-TYPE
SYNTAX INTEGER {
unknown(0),
primary(1),
secondary(2),
parallel(3),
loadBalancing(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of a member Transport Session in a Transport
Session group (identified by the value of ipfixExportIndex,
ipfixObservationDomainId, and ipfixMeteringProcessCacheId).
The following values are valid:
unknown(0)
This value MUST be used if the status of the group
membership cannot be detected by the equipment. This
value should be avoided as far as possible.
primary(1)
This value is used for a group member that is used as
the primary target of an Exporter. Other group members
(with the same ipfixExportIndex and
ipfixMeteringProcessCacheId) MUST NOT have the value
primary(1) but MUST have the value secondary(2).
This value MUST also be specified if the Exporter does
not support Transport Session grouping. In this case,
the group contains only one Transport Session.
secondary(2)
This value is used for a group member that is used as a
secondary target of an Exporter. The Exporter will use
one of the targets specified as secondary(2) within the
same Transport Session group when the primary target is
not reachable.
parallel(3)
This value is used for a group member that is used for
duplicate exporting, i.e., all group members identified
by the ipfixExportIndex are exporting the same Records
in parallel. This implies that all group members MUST
have the same membertype parallel(3).
loadBalancing(4)
This value is used for a group member that is used
as one target for load-balancing. This means that a
Record is sent to one of the group members in this
group identified by ipfixExportIndex.
This implies that all group members MUST have the same
membertype loadBalancing(4)."
::= { ipfixExportEntry 2 }
--------------------------------------------------------------------
-- 1.1.5: Metering Process Table
--------------------------------------------------------------------
ipfixMeteringProcessTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixMeteringProcessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists so-called caches used at the Metering
Process to store the metering data of Flows observed at
the Observation Points given in the
ipfixObservationPointGroupReference. The table lists the
timeouts that specify when the cached metering data is
expired.
On Collectors, the table is not needed."
::= { ipfixMainObjects 5 }
ipfixMeteringProcessEntry OBJECT-TYPE
SYNTAX IpfixMeteringProcessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixMeteringProcessTable."
INDEX { ipfixMeteringProcessCacheId }
::= { ipfixMeteringProcessTable 1 }
IpfixMeteringProcessEntry ::=
SEQUENCE {
ipfixMeteringProcessCacheId Unsigned32,
ipfixMeteringProcessObservationPointGroupRef Unsigned32,
ipfixMeteringProcessCacheActiveTimeout Unsigned32,
ipfixMeteringProcessCacheInactiveTimeout Unsigned32
}
ipfixMeteringProcessCacheId OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Locally arbitrary, but unique identifier of an entry in the
ipfixMeterinProcessTable. The value is expected to remain
constant from a re-initialization of the entity's network
management agent to the next re-initialization."
::= { ipfixMeteringProcessEntry 1 }
ipfixMeteringProcessObservationPointGroupRef OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Observation Point Group Id that links this table entry
to the ipfixObservationPointTable. The matching
ipfixObservationPointGroupId in that table gives the
Observation Points used in that cache. If the Observation
Points are unknown, the
ipfixMeteringProcessObservationPointGroupRef MUST be zero."
::= { ipfixMeteringProcessEntry 2 }
ipfixMeteringProcessCacheActiveTimeout OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"On the Exporter, this object contains the time after which a
Flow is expired (and a Data Record for the template is sent)
even though packets matching this Flow are still received by
the Metering Process. If this value is 0, the Flow is not
prematurely expired."
REFERENCE
"RFC 5470, Architecture for IP Flow Information Export,
Section 5.1.1, item 3."
::= { ipfixMeteringProcessEntry 3 }
ipfixMeteringProcessCacheInactiveTimeout OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"On the Exporter. this object contains the time after which a
Flow is expired (and a Data Record for the template is sent)
when no packets matching this Flow are received by the
Metering Process for the given number of seconds. If this
value is zero, the Flow is expired immediately, i.e., a Data
Record is sent for every packet received by the Metering
Process."
REFERENCE
"RFC 5470, Architecture for IP Flow Information Export,
Section 5.1.1, item 1"
::= { ipfixMeteringProcessEntry 4 }
--------------------------------------------------------------------
-- 1.1.6: Observation Point Table
--------------------------------------------------------------------
ipfixObservationPointTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixObservationPointEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the Observation Points used within an
Exporter by the Metering Process. The index
ipfixObservationPointGroupId groups Observation Points
and is referenced in the Metering Process table.
On Collectors this table is not needed."
::= { ipfixMainObjects 6 }
ipfixObservationPointEntry OBJECT-TYPE
SYNTAX IpfixObservationPointEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixObservationPointTable."
INDEX {
ipfixObservationPointGroupId,
ipfixObservationPointIndex
}
::= { ipfixObservationPointTable 1 }
IpfixObservationPointEntry ::=
SEQUENCE {
ipfixObservationPointGroupId Unsigned32,
ipfixObservationPointIndex Unsigned32,
ipfixObservationPointObservationDomainId Unsigned32,
ipfixObservationPointPhysicalEntity PhysicalIndexOrZero,
ipfixObservationPointPhysicalInterface InterfaceIndexOrZero,
ipfixObservationPointPhysicalEntityDirection INTEGER
}
ipfixObservationPointGroupId OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Locally arbitrary, but unique identifier of an entry in the
ipfixObservationPointTable. The value is expected to remain
constant from a re-initialization of the entity's network
management agent to the next re-initialization.
This index represents a group of Observation Points.
The special value of 0 MUST NOT be used within this table
but is reserved for the usage in the
ipfixMeteringProcessTable. An index of 0 for the
ipfixObservationPointGroupReference index in that table
indicates that an Observation Point is unknown or
unspecified for a Metering Process cache."
::= { ipfixObservationPointEntry 1 }Okay bestie, we're picking up mid-object with the Observation Point columns 💖 Here's the first chunk:
ipfixObservationPointIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Locally arbitrary, but unique identifier of an entry in the
ipfixObservationPointTable. The value is expected to remain
constant from a re-initialization of the entity's network
management agent to the next re-initialization.
This index represents a single Observation Point in an
Observation Point group."
::= { ipfixObservationPointEntry 2 }
ipfixObservationPointObservationDomainId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Id of the Observation Domain in which this
Observation Point is included.
The special value of 0 indicates that the Observation
Points within this group cannot be applied to a single
Observation Domain."
REFERENCE
"RFC 5101, Specification of the IP Flow Information Export
(IPFIX) Protocol for the Exchange of IP
Traffic Flow Information, Section 3.1."
::= { ipfixObservationPointEntry 3 }
ipfixObservationPointPhysicalEntity OBJECT-TYPE
SYNTAX PhysicalIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the index of a physical entity in
the ENTITY MIB. This physical entity is the given
Observation Point. If such a physical entity cannot be
specified or is not known, then the object is zero."
::= { ipfixObservationPointEntry 4 }
ipfixObservationPointPhysicalInterface OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the index of a physical interface in
the IF MIB. This physical interface is the given
Observation Point. If such a physical interface cannot be
specified or is not known, then the object is zero.
This object MAY be used stand alone or in addition to
ipfixObservationPointPhysicalEntity. If
ipfixObservationPointPhysicalEntity is not zero, this object
MUST point to the same physical interface that is
referenced in ipfixObservationPointPhysicalEntity.
Otherwise, it may reference any interface in the IF MIB."
::= { ipfixObservationPointEntry 5 }
ipfixObservationPointPhysicalEntityDirection OBJECT-TYPE
SYNTAX INTEGER {
unknown(0),
ingress(1),
egress(2),
both(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The direction of the Flow that is monitored on the given
physical entity. The following values are valid:
unknown(0)
This value MUST be used if a direction is not
known for the given physical entity.
ingress(1)
This value is used for monitoring incoming Flows on the
given physical entity.
egress(2)
This value is used for monitoring outgoing Flows on the
given physical entity.
both(3)
This value is used for monitoring incoming and outgoing
Flows on the given physical entity."
::= { ipfixObservationPointEntry 6 }Next up is the Selection Process table, which is where the Selector Functions get lined up in order 🎀 The tree diagram inside the description is a whole vibe 🦋
--------------------------------------------------------------------
-- 1.1.7: Selection Process Table
--------------------------------------------------------------------
ipfixSelectionProcessTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixSelectionProcessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains Selector Functions connected to a
Metering Process by the index ipfixMeteringProcessCacheId.
The Selector Functions are grouped into Selection Processes
by the ipfixSelectionProcessIndex. The Selector Functions
are applied within the Selection Process to the packets
observed for the given Metering Process cache in increasing
order implied by the ipfixSelectionProcessSelectorIndex.
This means Selector Functions with lower
ipfixSelectionProcessSelectorIndex are applied first. The
remaining packets are accounted for in Flow Records.
Since IPFIX does not define any Selector Function (except
selecting every packet), this is a placeholder for future
use and a guideline for implementing enterprise-specific
Selector Function objects.
The following object tree should visualize how the
Selector Function objects should be implemented:
ipfixSelectorFunctions
|
+- ipfixFuncSelectAll
| |
| +- ipfixFuncSelectAllAvail (is the function available?)
|
+- ipfixFuncF2
| |
| +- ipfixFuncF2Avail (is the function F2 available?)
| |
| +- ipfixFuncF2Parameters (a table with parameters)
...
|
+- ipfixFunFn...
If a Selector Function takes parameters, the MIB should
contain a table with an entry for each set of parameters
used at the Exporter."
::= { ipfixMainObjects 7 }
ipfixSelectionProcessEntry OBJECT-TYPE
SYNTAX IpfixSelectionProcessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixSelectionProcessTable."
INDEX {
ipfixMeteringProcessCacheId,
ipfixSelectionProcessIndex,
ipfixSelectionProcessSelectorIndex
}
::= { ipfixSelectionProcessTable 1 }
IpfixSelectionProcessEntry ::= SEQUENCE {
ipfixSelectionProcessIndex Unsigned32,
ipfixSelectionProcessSelectorIndex Unsigned32,
ipfixSelectionProcessSelectorFunction OBJECT IDENTIFIER
}
ipfixSelectionProcessIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Locally arbitrary, but unique identifier of an entry in the
ipfixSelectionProcessTable. The value is expected to remain
constant from a re-initialization of the entity's network
management agent to the next re-initialization."
::= { ipfixSelectionProcessEntry 1 }
ipfixSelectionProcessSelectorIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index specifying the order in which the referenced
ipfixSelctionProcessSelectorFunctions are applied to the
observed packet stream within the given Selection Process
(identified by the ipfixSelectionProcessIndex). The
Selector Functions are applied in increasing order, i.e.,
Selector Functions with lower index are applied first."
::= { ipfixSelectionProcessEntry 2 }
ipfixSelectionProcessSelectorFunction OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The pointer to the Selector Function used at position
ipfixSelectionProcessSelectorIndex in the list of Selector
Functions for the Metering Process cache specified by the
index ipfixMeteringProcessCacheId and for the given
Selection Process (identified by the
ipfixSelectionProcessIndex).
This usually points to an object in the IPFIX SELECTOR MIB.
If the Selector Function does not take parameters, then it
MUST point to the root of the function subtree. If the
function takes parameters, then it MUST point to an entry
in the parameter table of the Selector Function."
::= { ipfixSelectionProcessEntry 3 }Now we're in the Transport Session Statistics table 📊 Lots of Counter64 energy here, so iconic 🌈
--------------------------------------------------------------------
-- 1.2.1: Transport Session Statistics Table
--------------------------------------------------------------------
ipfixTransportSessionStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixTransportSessionStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Transport Sessions statistics between
Exporting Processes and Collecting Processes."
::= { ipfixStatistics 1 }
ipfixTransportSessionStatsEntry OBJECT-TYPE
SYNTAX IpfixTransportSessionStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixTransportSessionStatsTable."
AUGMENTS { ipfixTransportSessionEntry }
::= { ipfixTransportSessionStatsTable 1 }
IpfixTransportSessionStatsEntry ::=
SEQUENCE {
ipfixTransportSessionRate Gauge32,
ipfixTransportSessionPackets Counter64,
ipfixTransportSessionBytes Counter64,
ipfixTransportSessionMessages Counter64,
ipfixTransportSessionDiscardedMessages Counter64,
ipfixTransportSessionRecords Counter64,
ipfixTransportSessionTemplates Counter64,
ipfixTransportSessionOptionsTemplates Counter64,
ipfixTransportSessionDiscontinuityTime TimeStamp
}
ipfixTransportSessionRate OBJECT-TYPE
SYNTAX Gauge32
UNITS "bytes/second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes per second received by the
Collector or transmitted by the Exporter. A
value of zero (0) means that no packets were sent or
received, yet. This object is updated every second."
::= { ipfixTransportSessionStatsEntry 1 }
ipfixTransportSessionPackets OBJECT-TYPE
SYNTAX Counter64
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets received by the Collector
or transmitted by the Exporter.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixTransportSessionDiscontinuityTime."
::= { ipfixTransportSessionStatsEntry 2 }
ipfixTransportSessionBytes OBJECT-TYPE
SYNTAX Counter64
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes received by the Collector
or transmitted by the Exporter.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixTransportSessionDiscontinuityTime."
::= { ipfixTransportSessionStatsEntry 3 }
ipfixTransportSessionMessages OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IPFIX Messages received by the
Collector or transmitted by the Exporter.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixTransportSessionDiscontinuityTime."
::= { ipfixTransportSessionStatsEntry 4 }Okay so the counters keep coming and they're giving main character energy 📊✨
ipfixTransportSessionDiscardedMessages OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received IPFIX Message that are malformed,
cannot be decoded, are received in the wrong order, or are
missing according to the sequence number.
If used at the Exporter, the number of messages that could
not be sent due to, e.g., internal buffer overflows, network
congestion, or routing issues.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixTransportSessionDiscontinuityTime."
::= { ipfixTransportSessionStatsEntry 5 }
ipfixTransportSessionRecords OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Data Records received by the Collector or
transmitted by the Exporter.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixTransportSessionDiscontinuityTime."
::= { ipfixTransportSessionStatsEntry 6 }
ipfixTransportSessionTemplates OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Templates received or transmitted.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixTransportSessionDiscontinuityTime."
::= { ipfixTransportSessionStatsEntry 7 }
ipfixTransportSessionOptionsTemplates OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Options Templates received or transmitted.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixTransportSessionDiscontinuityTime."
::= { ipfixTransportSessionStatsEntry 8 }
ipfixTransportSessionDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the most recent occasion at which
one or more of the Transport Session counters suffered a
discontinuity.
A value of zero indicates no such discontinuity has
occurred since the last re-initialization of the local
management subsystem."
::= { ipfixTransportSessionStatsEntry 9 }
--------------------------------------------------------------------
-- 1.2.2: Template Statistics Table
--------------------------------------------------------------------
ipfixTemplateStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixTemplateStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists statistics objects per Template."
::= { ipfixStatistics 2 }
ipfixTemplateStatsEntry OBJECT-TYPE
SYNTAX IpfixTemplateStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixTemplateStatsTable."
AUGMENTS { ipfixTemplateEntry }
::= { ipfixTemplateStatsTable 1 }
IpfixTemplateStatsEntry ::=
SEQUENCE {
ipfixTemplateDataRecords Counter64,
ipfixTemplateDiscontinuityTime TimeStamp
}
ipfixTemplateDataRecords OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Data Records that are transmitted or received
per Template.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ipfixTemplateDiscontinuityTime."
::= { ipfixTemplateStatsEntry 1 }
ipfixTemplateDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the most recent occasion at which
the Template counter suffered a discontinuity.
A value of zero indicates no such discontinuity has
occurred since the last re-initialization of the local
management subsystem."
::= { ipfixTemplateStatsEntry 2 }
--------------------------------------------------------------------
-- 1.2.3: Metering Process Statistics Table
--------------------------------------------------------------------
ipfixMeteringProcessStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixMeteringProcessStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists statistic objects that have data per
Metering Process cache.
On Collectors, this table is not needed."
::= { ipfixStatistics 3 }
ipfixMeteringProcessStatsEntry OBJECT-TYPE
SYNTAX IpfixMeteringProcessStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixMeteringProcessStatsTable."
AUGMENTS { ipfixMeteringProcessEntry }
::= { ipfixMeteringProcessStatsTable 1 }
IpfixMeteringProcessStatsEntry ::=
SEQUENCE {
ipfixMeteringProcessCacheActiveFlows Gauge32,
ipfixMeteringProcessCacheUnusedCacheEntries Gauge32,
ipfixMeteringProcessCacheDataRecords Counter64,
ipfixMeteringProcessCacheDiscontinuityTime TimeStamp
}
ipfixMeteringProcessCacheActiveFlows OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Flows currently active at this cache."
::= { ipfixMeteringProcessStatsEntry 1 }
ipfixMeteringProcessCacheUnusedCacheEntries OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of unused cache entries."
::= { ipfixMeteringProcessStatsEntry 2 }
ipfixMeteringProcessCacheDataRecords OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Data Records generated.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixTemplateDiscontinuityTime."
::= { ipfixMeteringProcessStatsEntry 3 }
ipfixMeteringProcessCacheDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the most recent occasion at which
the Metering Process counter suffered a discontinuity.
A value of zero indicates no such discontinuity has
occurred since the last re-initialization of the local
management subsystem."
::= { ipfixMeteringProcessStatsEntry 4 }
--------------------------------------------------------------------
-- 1.2.4: Selection Process Statistics Table
--------------------------------------------------------------------
ipfixSelectionProcessStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpfixSelectionProcessStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains statistics for the Selector Functions
connected to Metering Process by the index
ipfixMeteringProcessCacheId.
The indexes MUST match an entry in the
ipfixSelectionProcessTable."
::= { ipfixStatistics 4 }
ipfixSelectionProcessStatsEntry OBJECT-TYPE
SYNTAX IpfixSelectionProcessStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the ipfixSelectionProcessStatsTable."
AUGMENTS { ipfixSelectionProcessEntry }
::= { ipfixSelectionProcessStatsTable 1 }
IpfixSelectionProcessStatsEntry ::= SEQUENCE {
ipfixSelectionProcessStatsPacketsObserved Counter64,
ipfixSelectionProcessStatsPacketsDropped Counter64,
ipfixSelectionProcessStatsDiscontinuityTime TimeStamp
}
ipfixSelectionProcessStatsPacketsObserved OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets observed at the entry point of the
function. The entry point may be the Observation Point or
the exit point of another Selector Function.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixSelectionProcessStatsDiscontinuityTime."
::= { ipfixSelectionProcessStatsEntry 1 }
ipfixSelectionProcessStatsPacketsDropped OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets dropped while selecting packets.
Discontinuities in the value of this counter can occur at
re-initialization of the management system and at other
times as indicated by the value of
ipfixSelectionProcessStatsDiscontinuityTime."
::= { ipfixSelectionProcessStatsEntry 2 }
ipfixSelectionProcessStatsDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the most recent occasion at which
one or more of the Selector counters suffered a
discontinuity.
A value of zero indicates no such discontinuity has
occurred since the last re-initialization of the local
management subsystem."
::= { ipfixSelectionProcessStatsEntry 3 }
--==================================================================
-- 2: Conformance Information
--==================================================================
ipfixCompliances OBJECT IDENTIFIER ::= { ipfixConformance 1 }
ipfixGroups OBJECT IDENTIFIER ::= { ipfixConformance 2 }
--------------------------------------------------------------------
-- 2.1: Compliance Statements
--------------------------------------------------------------------
ipfixCollectorCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"An implementation that builds an IPFIX Collector
that complies to this module MUST implement the objects
defined in the mandatory group ipfixCommonGroup.
The implementation of all objects in the other groups is
optional and depends on the corresponding functionality
implemented in the equipment.
An implementation that is compliant to this MIB module
is limited to use only the values TCP (6), UDP (17), and
SCTP (132) in the ipfixTransportSessionProtocol object
because these are the only protocol currently specified
for usage within IPFIX (see RFC 5101)."
MODULE -- this module
MANDATORY-GROUPS {
ipfixCommonGroup
} GROUP ipfixCommonStatsGroup
DESCRIPTION
"These objects should be implemented if the statistics
function is implemented in the equipment."
::= { ipfixCompliances 1 }
ipfixExporterCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"An implementation that builds an IPFIX Exporter that
complies to this module MUST implement the objects defined
in the mandatory group ipfixCommonGroup. The implementation
of all other objects depends on the implementation of the
corresponding functionality in the equipment."
MODULE -- this module
MANDATORY-GROUPS {
ipfixCommonGroup,
ipfixExporterGroup
}
GROUP ipfixCommonStatsGroup
DESCRIPTION
"These objects should be implemented if the statistics
function is implemented in the equipment."
GROUP ipfixExporterStatsGroup
DESCRIPTION
"These objects MUST be implemented if statistical functions
are implemented on the equipment."
::= { ipfixCompliances 2 }
--------------------------------------------------------------------
-- 2.2: MIB Grouping
--------------------------------------------------------------------
ipfixCommonGroup OBJECT-GROUP
OBJECTS {
ipfixTransportSessionProtocol,
ipfixTransportSessionSourceAddressType,
ipfixTransportSessionSourceAddress,
ipfixTransportSessionDestinationAddressType,
ipfixTransportSessionDestinationAddress,
ipfixTransportSessionSourcePort,
ipfixTransportSessionDestinationPort,
ipfixTransportSessionSctpAssocId,
ipfixTransportSessionDeviceMode,
ipfixTransportSessionTemplateRefreshTimeout,
ipfixTransportSessionOptionsTemplateRefreshTimeout,
ipfixTransportSessionTemplateRefreshPacket,
ipfixTransportSessionOptionsTemplateRefreshPacket,
ipfixTransportSessionIpfixVersion,
ipfixTransportSessionStatus,
ipfixTemplateSetId,
ipfixTemplateAccessTime,
ipfixTemplateDefinitionIeId,
ipfixTemplateDefinitionIeLength,
ipfixTemplateDefinitionEnterpriseNumber,
ipfixTemplateDefinitionFlags
}
STATUS current
DESCRIPTION
"The main IPFIX objects."
::= { ipfixGroups 1 }
ipfixCommonStatsGroup OBJECT-GROUP
OBJECTS {
ipfixTransportSessionRate,
ipfixTransportSessionPackets,
ipfixTransportSessionBytes,
ipfixTransportSessionMessages,
ipfixTransportSessionDiscardedMessages,
ipfixTransportSessionRecords,
ipfixTransportSessionTemplates,
ipfixTransportSessionOptionsTemplates,
ipfixTransportSessionDiscontinuityTime,
ipfixTemplateDataRecords,
ipfixTemplateDiscontinuityTime
}
STATUS current
DESCRIPTION
"Common statistical objects."
::= { ipfixGroups 2 }
ipfixExporterGroup OBJECT-GROUP
OBJECTS {
ipfixExportMemberType,
ipfixMeteringProcessObservationPointGroupRef,
ipfixMeteringProcessCacheActiveTimeout,
ipfixMeteringProcessCacheInactiveTimeout,
ipfixObservationPointObservationDomainId,
ipfixObservationPointPhysicalEntity,
ipfixObservationPointPhysicalInterface,
ipfixObservationPointPhysicalEntityDirection,
ipfixSelectionProcessSelectorFunction
}
STATUS current
DESCRIPTION
"The main objects for Exporters."
::= { ipfixGroups 3 }
ipfixExporterStatsGroup OBJECT-GROUP
OBJECTS {
ipfixMeteringProcessCacheActiveFlows,
ipfixMeteringProcessCacheUnusedCacheEntries,
ipfixMeteringProcessCacheDataRecords,
ipfixMeteringProcessCacheDiscontinuityTime,
ipfixSelectionProcessStatsPacketsObserved,
ipfixSelectionProcessStatsPacketsDropped,
ipfixSelectionProcessStatsDiscontinuityTime
}
STATUS current
DESCRIPTION
"The statistical objects for Exporters."
::= { ipfixGroups 4 }
END8.2. IPFIX SELECTOR MIB Definition ✨
okay bestie, this is the second MIB, the IPFIX SELECTOR MIB 🦋 It's the spot where the standard filtering and sampling functions live, the ones you can point to from the ipfixSelectorTable of the IPFIX MIB 💅 Its subtree, ipfixSelectorFunctions, is basically a placeholder folder for all of those standard functions 🎀
Also, the IANA is the one who keeps this module up to date 👑 and new stuff can be added through Expert Review [RFC5226], which is a review by a group of experts picked by an IETF Area Director 🧚 the experts have a strict checklist 🙈 Anyway, the full module is right below 👇
IPFIX-SELECTOR-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, mib-2
FROM SNMPv2-SMI -- RFC2578
TruthValue
FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF; -- RFC2580
ipfixSelectorMIB MODULE-IDENTITY
LAST-UPDATED "201003150000Z" -- 15 March 2010
ORGANIZATION "IETF IPFIX Working Group"
CONTACT-INFO
"WG charter:
http://www.ietf.org/html.charters/ipfix-charter.html
Mailing Lists:
General Discussion: ipfix@ietf.org
To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix
Archive:
http://www1.ietf.org/mail-archive/web/ipfix/current/index.html
Editor:
Thomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-128
Email: Thomas.Dietz@nw.neclab.eu
Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi
180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Gerhard Muenz
Technische Universitaet Muenchen
Department of Informatics
Chair for Network Architectures and Services (I8)
Boltzmannstr. 3
85748 Garching
Germany
Phone: +49 89 289-18008
Email: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz"
DESCRIPTION
"The IPFIX SELECTOR MIB module defines the standard
filtering and sampling functions that can be referenced in
the ipfixSelectorTable of the IPFIX MIB. The subtree
ipfixSelectorFunctions is a placeholder where all standard
filtering and sampling functions should be located.
The IPFIX SELECTOR MIB module is maintained by IANA and can
be extended through Expert Review [RFC5226], i.e., review by
one of a group of experts designated by an IETF Area
Director. The group of experts MUST check the requested MIB
objects for completeness and accuracy of the description.
Requests for MIB objects that duplicate the functionality of
existing objects SHOULD be declined. The smallest available
OID SHOULD be assigned to a new MIB objects. The
specification of new MIB objects SHOULD follow the structure
specified in RFC 5815 and MUST be published using a
well-established and persistent publication medium. The
experts will initially be drawn from the Working Group
Chairs and document editors of the IPFIX and PSAMP Working
Groups.
Copyright (c) 2010 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
-- Revision history
REVISION "201003150000Z" -- 15 March 2010
DESCRIPTION
"Initial version, published as RFC 5815."
::= { mib-2 194 }
--******************************************************************
-- Top Level Structure of the MIB
--******************************************************************
ipfixSelectorObjects OBJECT IDENTIFIER
::= { ipfixSelectorMIB 1 }
ipfixSelectorConformance OBJECT IDENTIFIER
::= { ipfixSelectorMIB 2 }
--==================================================================
-- 1: Objects used by all IPFIX implementations
--==================================================================
--------------------------------------------------------------------
-- 1.1: Packet Selector Functions for IPFIX
--------------------------------------------------------------------
ipfixSelectorFunctions OBJECT IDENTIFIER
::= { ipfixSelectorObjects 1 }
--------------------------------------------------------------------
-- 1.1.1: Function 1: Selecting All Packets
--------------------------------------------------------------------
ipfixFuncSelectAll OBJECT IDENTIFIER
::= { ipfixSelectorFunctions 1 }
ipfixFuncSelectAllAvail OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the availability of the trivial
function of selecting all packets. This function is always
available."
::= { ipfixFuncSelectAll 1 }
--==================================================================
-- 2: Conformance Information
--==================================================================
ipfixSelectorCompliances OBJECT IDENTIFIER
::= { ipfixSelectorConformance 1 }
ipfixSelectorGroups OBJECT IDENTIFIER
::= { ipfixSelectorConformance 2 }
--------------------------------------------------------------------
-- 2.1: Compliance Statements
--------------------------------------------------------------------
ipfixSelectorBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"An implementation that builds an IPFIX Exporter that
complies to this module MUST implement the objects defined
in the mandatory group ipfixBasicGroup. The implementation
of all other objects depends on the implementation of the
corresponding functionality in the equipment."
MODULE -- this module
MANDATORY-GROUPS {
ipfixSelectorBasicGroup
}
::= { ipfixSelectorCompliances 1 }
--------------------------------------------------------------------
-- 2.2: MIB Grouping
--------------------------------------------------------------------
ipfixSelectorBasicGroup OBJECT-GROUP
OBJECTS {
ipfixFuncSelectAllAvail
}
STATUS current
DESCRIPTION
"The main IPFIX objects."
::= { ipfixSelectorGroups 1 }
END9. Security Considerations ✨
okay bestie, this is the serious part 🥺 There are no management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. So if these MIB modules are implemented correctly, an intruder can't alter or create any management objects through direct SNMP SET operations. No cap, that's a big win 💅
Some of the readable objects here (anything with a MAX-ACCESS other than not-accessible) might be sensitive or vulnerable in certain network environments 🙈 So it's important to control even GET and/or NOTIFY access to them, and possibly even encrypt their values when they travel over the network via SNMP. These are the tables and objects, plus how sensitive or vulnerable they are:
ipfixTransportSessionTablecontains configuration data that might be sensitive, because objects in this table may reveal information about the network infrastructure.ipfixExportTablecontains configuration data that might be sensitive, because objects in this table may reveal information about the network infrastructure as well.ipfixMeteringProcessTablecontains configuration data that might be sensitive, because objects in this table may reveal information about the IPFIX Device itself.ipfixObservationPointTablecontains configuration data that might be sensitive, because objects in this table may reveal information about the IPFIX Device itself and the network infrastructure.ipfixSelectorFunctionscurrently contains no sensitive data, but it might be worth securing anyway since it may hold sensitive data in a future version ✨
Everything else (all other objects and tables) contains no data considered sensitive 🌸
Now the plot twist 😭 SNMP versions before SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. Main character problem 💀
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410] Section 8), including full support for the SNMPv3 cryptographic mechanisms for authentication and privacy 🔐
Further, deploying SNMP versions before SNMPv3 is NOT RECOMMENDED 🙅♀️ Instead, it is RECOMMENDED to deploy SNMPv3 and enable cryptographic security. It's then a customer/operator responsibility to make sure that the SNMP entity giving access to an instance of these MIB modules is properly configured, so the objects are only accessible to principals (users) who legitimately have the right to GET or SET (change/create/delete) them. Lock the door, bestie 🗝️
10. IANA Considerations 💅
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
ipfixMIB { mib-2 193 }
ipfixSelectorMIB { mib-2 194 }Also, IANA maintains the whole IPFIX SELECTOR MIB module 🎀 Additions to it are subject to Expert Review [RFC5226], meaning review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check requested MIB objects for completeness and accuracy of their description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. The smallest available OID SHOULD be assigned to new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in Section 6, and MUST be published using a well-established and persistent publication medium 📚 The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups 🧚
11. Acknowledgments 🫶
This document is a product of the IPFIX Working Group 🦋 The authors want to thank the following people: Paul Aitken for his detailed review, Dan Romascanu and the MIB doctors, and many more, for the technical reviews and feedback. Thank you all, you're literally the best 💖
12. References 📚
12.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
- [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)", RFC 3873, September 2004.
- [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.
- [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
- [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
12.2. Informative References
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
- [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
- [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
- [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
- [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
- [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
- [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
Authors' Addresses 💌
Thomas Dietz (editor)
NEC Europe, Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
DE
Phone: +49 6221 4342-128
EMail: Thomas.Dietz@nw.neclab.eu
Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
JA
Phone: +81-422-59-3978
EMail: akoba@nttv6.net
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
BE
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Gerhard Muenz
Technische Universitaet Muenchen
Department of Informatics
Chair for Network Architectures and Services (I8)
Boltzmannstr. 3
Garching 85748
DE
Phone: +49 89 289-18008
EMail: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz📦 where this page comes from
- ietf: rfc5815 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms