RFC 6615
Definitions of Managed Objects for IP Flow Information Export
RFC 6615: Definitions of Managed Objects for IP Flow Information Export 🎀
okay bestie, let's talk about RFC 6615 💖 It's a Standards Track document from the IETF, published in June 2012 and filed under ISSN 2070-1721. It obsoletes RFC 5815, which means this one is the newer, updated version. The title block doesn't list anything it updates.
The main authors are T. Dietz (editor) from NEC Europe Ltd., A. Kobayashi from NTT PF Labs, B. Claise from Cisco Systems, Inc., and G. Muenz from Technische Universitaet Muenchen. The whole squad 🫶
Abstract ✨
so the abstract says this doc defines managed objects for IP Flow Information eXport (IPFIX) 📊. These objects help you monitor IPFIX Exporters and IPFIX Collectors, and that includes their basic configuration info. it's giving monitoring dashboard energy 💅
Status of This Memo 📜
this is an Internet Standards Track document 🎀 It's a product of the Internet Engineering Task Force (IETF), it reflects the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 5741.
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6615 🦋
Copyright Notice 🌸
the copyright is Copyright (c) 2012 IETF Trust and the persons identified as the document authors, and all rights are reserved 💜
this doc falls under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. read them carefully, because they explain your rights and restrictions. if you extract Code Components from this doc, they have to include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥
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 ................................13
5.6. The Observation Point Table ...............................14
5.7. The Selection Process Table ...............................15
5.8. The Statistical Tables ....................................16
5.8.1. The Transport Session Statistical Table ............16
5.8.2. The Template Statistical Table .....................16
5.8.3. The Metering Process Statistical Table .............16
5.8.4. The Selection Process Statistical Table ............16
6. Structure of the IPFIX SELECTOR MIB ............................16
6.1. The Selector Functions ....................................17
7. Relationship to Other MIB Modules ..............................19
7.1. Relationship to the ENTITY MIB and Interfaces MIB .........19
7.2. MIB Modules Required for IMPORTS ..........................19
8. MIB Definitions ................................................20
8.1. IPFIX MIB Definition ......................................20
8.2. IPFIX SELECTOR MIB Definition .............................56
9. Security Considerations ........................................60
10. IANA Considerations ...........................................61
11. Acknowledgments ...............................................62
12. References ....................................................62
12.1. Normative References .....................................62
12.2. Informative References ...................................631. Introduction ✨
this doc defines two MIB modules for monitoring IP Flow Information eXport (IPFIX) Devices, which means both Exporters and Collectors 🦋 Most of the objects in the IPFIX MIB module must be implemented, but some objects may be implemented depending on what the equipment actually does.
because the IPFIX architecture [RFC5470] allows Filtering and/or Sampling functions to cut down on data volume, this doc also gives you the IPFIX SELECTOR MIB module. It holds the standardized selection methods, and IANA controls it 💅 The full configuration of the IPFIX Metering Process is out of scope for these MIB modules, so that's a different story 🙈
the key words are the BCP 14 vibes. they're interpreted as described in RFC 2119 [RFC2119], and here's the full list: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL".
2. IPFIX Documents Overview 📚
the IPFIX protocol gives network admins access to IP Flow information 📊 The architecture for exporting measured IP Flow information from an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], following the requirements in [RFC3917]. The protocol document [RFC5101] explains how IPFIX Data Records and Templates travel over a congestion-aware transport protocol from Exporting Processes to Collecting Processes. IPFIX also has a formal description of its Information Elements (their name, type, and extra semantic info), as specified in [RFC5102]. Last, [RFC5472] describes what kinds of applications can use IPFIX, how they can use the info, and how the IPFIX framework fits with other architectures and frameworks 🌈
it's assumed that Flow metering, export, and collection follow 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 the IPFIX Metering Process may optionally use aren't covered in this MIB doc. Those are defined in the Packet Sampling (PSAMP) framework [RFC5474] and the Sampling techniques [RFC5475] docs. Still, the IPFIX SELECTOR MIB module gives the basis for defining Sampling and Filtering functions. 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 documents that describe the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] 💜
managed objects are accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined with the mechanisms in the Structure of Management Information (SMI). This memo specifies MIB modules that comply with 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 live in the IPFIX protocol document [RFC5101] 🫶
5. Structure of the IPFIX MIB 🏗️
the IPFIX MIB module has seven main tables 👑 They are the Transport Session table, the Template table and its matching 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 Filtering and/or Sampling functions to reduce data volume, the IPFIX MIB module provides the basic objects for those 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 ✨
everything else in the MIB module holds statistical values for the different tables 📈
the following subsections describe all the tables in the IPFIX MIB module 🦋
part 1 of 12 done, more to come in part 2 💖🌈
5.1. The Transport Session Table ✨
okay so the Transport Session is literally the foundation of this whole MIB 💖 everything else hangs off of it 🫶 The Transport Session table (ipfixTransportSessionTable) holds every single Transport Session between the Exporter and the Collector 🦋 It says which transport layer protocol the session uses, and then, depending on that protocol, it stores the extra details for that session 🎀 For UDP and TCP, that means the source and destination address plus the source and destination port 🌸 For the Stream Control Transmission Protocol (SCTP), the table has ipfixTransportSessionSctpAssocId, which is the index for the SCTP association in the SCTP MIB module [RFC3873] 🧚
The mode the device is running in, so whether the Transport Session is for collecting or exporting, lives in ipfixTransportSessionDeviceMode 👑 The table also keeps the configured refresh settings for Templates and Options Templates that go over unreliable connections like UDP 💅 And last but not least, it records the IPFIX version being exported or collected by that session, plus the session's status ✨
To make this less abstract, let's imagine a scenario 🍓 We've got 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 Transport Session table on the Exporter 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
| +- ipfixTransportSessionOptionsTemplateRefreshTimeout (12) = 0
| +- ipfixTransportSessionTemplateRefreshPacket (13) = 0
| +- ipfixTransportSessionOptionsTemplateRefreshPacket (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
+- ipfixTransportSessionOptionsTemplateRefreshTimeout (12)
| = 100
+- ipfixTransportSessionTemplateRefreshPacket (13) = 10
+- ipfixTransportSessionOptionsTemplateRefreshPacket (14) = 10
+- ipfixTransportSessionIpfixVersion (15) = 10
+- ipfixTransportSessionStatus (16) = 2 (active)The numbers in parentheses are the OID numbers 🔢 The Collectors would end up with the same entry too, except the index would most likely be different, and ipfixTransportSessionDeviceMode would be collecting(2) 💜
5.2. The Template Table
The Template table lists every Template (Options Templates included) that gets sent by an Exporter or received by a Collector 📋 The (Options) Templates are unique per Observation Domain and per Transport Session 🫶 The Transport Session also tells you the device mode, so whether it's an Exporter or a Collector 👀 So this 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 moment 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, which defines the Template and the 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, we're going to assume that the Transport Session stored at index 5 in the Exporter's Transport Session table is stored at index 17 in the (corresponding) Collector's Transport Session table 🦋 With that, the Template table on the Collector 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 is analogous to the one shown above 🌸
5.3. The Template Definition Table
The Template Definition table lists all the Information Elements sitting inside a Template or an Options Template 🧩 Because of that, 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 also stores the enterprise number for enterprise-specific Information Elements, plus flags for each Information Element 🏳️ Those flags say whether the Information Element is being used for scoping or as a Flow Key 👑
Let's resume our example one more time 💅 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 ⏱️ So the Template Definition table on the Exporter looks like this:
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
| +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0
| +- ipfixTemplateDefinitionFlags (5) = 0
|
+- index (2) (ipfixTemplateDefinitionIndex)
| +- ipfixTemplateDefinitionIndex (1) = 2
| +- ipfixTemplateDefinitionIeId (2) = 159
| | (flowEndDeltaMicroseconds)
| +- ipfixTemplateDefinitionIeLength (3) = 4
| +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0
| +- ipfixTemplateDefinitionFlags (5) = 0
|
+- index (3) (ipfixTemplateDefinitionIndex)
| +- ipfixTemplateDefinitionIndex (1) = 3
| +- ipfixTemplateDefinitionIeId (2) = 1
| | (octetDeltaCount)
| +- ipfixTemplateDefinitionIeLength (3) = 8
| +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0
| +- ipfixTemplateDefinitionFlags (5) = 0
|
+- index (4) (ipfixTemplateDefinitionIndex)
+- ipfixTemplateDefinitionIndex (1) = 4
+- ipfixTemplateDefinitionIeId (2) = 132
| (droppedOctetDeltaCount)
+- ipfixTemplateDefinitionIeLength (3) = 8
+- ipfixTemplateDefinitionEnterpriseNumber (4) = 0
+- ipfixTemplateDefinitionFlags (5) = 0The matching entry on the Collector is the same, except it has a different ipfixTransportSessionIndex, e.g., 17 like in the previous example 🎀
5.4. The Export Table
Okay bestie, the Export table (ipfixExportTable) is where Exporters get to be extra 💅 about failover, load-balancing, and sending duplicate exports to several Collectors ✨. It has three indexes that link each 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 🦋. The member type of each group member tells you its functionality. All Transport Sessions referenced in this table MUST have a ipfixTransportSessionDeviceMode value of exporting(1).
If the Exporter doesn't do Transport Session grouping, then each ipfixExportIndex holds a single ipfixMeteringProcessCacheId, which means a single Transport Session (ipfixTransportSessionIndex). That session MUST have a member type value of primary(1) 🌸.
For failover, a Transport Session group can hold one Transport Session with member type primary(1) and several Transport Sessions with type secondary(2). Entries with other member types are not allowed in that kind of group. For load-balancing or parallel export, every Transport Session 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. Not our problem today, bestie 🙈.
To keep going with the example, let's 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 has 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 the Exporter uses the Metering Process cache (index (9)), which we'll explain below, to export IPFIX Data Records for Transport Sessions 5 and 11 🎀. Templates 257 and 264 from above get exported within Transport Session 5 as primary, with Transport Session 11 as the secondary. Templates 273 and 289 go out within Transport Session 11 as primary, with Transport Session 5 as the secondary. Main character energy for both sessions 👑.
Now, if a manager wants to figure out what the backups are (if any) for Template Records exported from a specific Exporter to a specific Collector, here are the steps they follow 🔍:
- Look up the Collector IP address in the
ipfixTransportSessionDestinationAddressobject (in theipfixTransportSessionTable). - From the same row, double-check the Exporter IP address in the
ipfixTransportSessionSourceAddressobject. - From the same row, write down the
ipfixTransportSessionIndexvalue. - Use that
ipfixTransportSessionIndexvalue in theipfixTemplateTableand look up the pairs of (ipfixTemplateObservationDomainId,ipfixTemplateId). From there, the manager works out the Template Record(s) (ipfixTemplateId), exported from the Observation Domain(s) (ipfixTemplateObservationDomainId) on the tracked Exporter (ipfixTransportSessionSourceAddress) to the tracked Collector (ipfixTransportSessionDestinationAddress) 🧚. - Reusing the same
ipfixTransportSessionIndexin theipfixExportTable, look in the table for a value ofipfixExportMemberTypethat equals "primary". There could be multiple entries whereipfixExportMemberTypeequals "primary" in theipfixExportTable, so you might need several rounds until you land on the correctipfixTransportSessionIndexvalue 😭. - From the same row, write down the
ipfixExportIndexvalue. - In the
ipfixExportTable, under the same three index values (ipfixExportIndex,ipfixMeteringProcessCacheId, andipfixTransportSessionIndex), look up the entries whereipfixExportMemberTypeis different from "primary". Write down the associatedipfixTransportSessionIndexvalue. - From the
ipfixTransportSessionTable, look up the Transport Session details for thisipfixTransportSessionIndexvalue. For example, grab the secondary Collector IP address and port (ipfixTransportSessionDestinationAddressandipfixTransportSessionSourcePort) 🎉.
5.5. The Metering Process Table
The Metering Process, as defined in [RFC5101], is basically a bundle of functions 💖. One of them is maintaining the Flow Records. That function is responsible for passing the Flow Records to the Exporting Process and also for detecting Flow expiration ⏰. The Flow Records that the Metering Process maintains can be grouped by the Observation Points where they're observed. The instance that maintains each group of Flow Records is a kind of cache. That's why the Metering Process table (ipfixMeteringProcessTable) is indexed by cache IDs (ipfixMeteringProcessCacheId). Each cache can be maintained by its own 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 cover in the next subsection. If no Observation Point is specified for the Flow Records, the ipfixMeteringProcessObservationPointGroupRef MUST be zero(0) 🙈. The timeouts (ipfixMeteringProcessCacheActiveTimeout and ipfixMeteringProcessCacheIdleTimeout) specify when Flows expire ⌛.
ipfixMeteringProcessTable (6)
|
+- ipfixMeteringProcessEntry (1)
|
+- index (9) (ipfixMeteringProcessCacheId)
+- ipfixMeteringProcessCacheId (1) = 9
+- ipfixMeteringProcessObservationPointGroupRef (2) = 17
+- ipfixMeteringProcessCacheActiveTimeout (3) = 100
+- ipfixMeteringProcessCacheIdleTimeout (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 Interfaces MIB module [RFC2863]. The objects in the ENTITY MIB module referenced by ipfixObservationPointPhysicalEntity, or the objects in the Interfaces MIB module referenced by ipfixObservationPointPhysicalInterface, identify the Observation Point.
At least one reference for the objects ipfixObservationPointPhysicalEntity or ipfixObservationPointPhysicalInterface MUST exist for a valid Observation Point entry, no exceptions 🔥. If a reference to the Observation Point is given in both ipfixObservationPointPhysicalEntity and ipfixObservationPointPhysicalInterface, then both MUST point to the same physical interface. However, if one of the two references (ipfixObservationPointPhysicalEntity or ipfixObservationPointPhysicalInterface) can't be given, its reference MUST be 0. On top of that, a direction can be given to be more specific about 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, as 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) says the order in which the functions are applied to the packets observed at the Observation Points linked to the Metering Process cache. Selection methods run in increasing order, so the ones with a lower ipfixSelectionProcessSelectorIndex go first ⭐.
The functions are referenced by object identifiers that point to each 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, an entry for that Metering Process SHOULD be created that points to the Select All function (ipfixFuncSelectAll) 🌸.
5.8. The Statistical Tables
Statistical tables that augment the ipfixTransportSessionTable, ipfixTemplateTable, ipfixMeteringProcessTable, and ipfixSelectionProcessTable have been defined 📊. Every statistical table has a discontinuity object holding a timestamp for when a discontinuity event happened. That lets the management system know the counters in those tables might not be continuous anymore 🫶.
5.8.1. The Transport Session Statistical Table
The Transport Session Statistical table (ipfixTransportSessionStatsTable) augments the ipfixTransportSessionTable with stats 📈. It contains the rate (in bytes per second) at which IPFIX Messages are received or sent out. It also has the number of bytes, packets, messages, Records, Templates, and Options Templates received or sent, plus the number of messages that were discarded 💜.
5.8.2. The Template Statistical Table
This table has 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 ✨
okay so this table is the glow-up for the Selection Process table (ipfixSelectionProcessTable) 💅🦋 It adds two generic stat values: how many packets got observed, and how many packets got dropped by the selection method. literally the tea 🍓
6. Structure of the IPFIX SELECTOR MIB 🎀
bestie, this is where the IPFIX SELECTOR MIB module lives 🧚 It defines the standard Filtering and Sampling functions you can reference from ipfixSelectionProcessTable. Every standard Filtering and Sampling function MUST be registered in the subtree under the object ipfixSelectorFunctions (iso.org.dod.internet.mgmt.mib-2.ipfixSelectorMIB.ipfixSelectorObjects.ipfixSelectorFunctions, or 1.3.6.1.2.1.194.1.1). The top-level OIDs in the subtree under the object ipfixSelectorFunctions MUST be registered in a sub-registry maintained by IANA at http://www.iana.org/assignments/smi-numbers. The first entry in this subtree is the Select All function (ipfixFuncSelectAll), defined in this document as {ipfixSelectorFunctions 1}.
New Selector Functions MUST be registered at IANA and are subject to Expert Review [RFC5226], which means 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 new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in Section 6.1 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
the picture below shows what the MIB tree usually should look like 👀 It already has ipfixFuncSelectAll in it. The subtree in ipfixFuncF2 gives the basic structure that all selection methods SHOULD follow.
ipfixSelectorFunctions
|
+- ipfixFuncSelectAll
| |
| +- ipfixFuncSelectAllAvail (is the function available?)
|
+- ipfixFuncF2
| |
| +- ipfixFuncF2Avail (is the function F2 available?)
| |
| +- ipfixFuncF2Parameters (a table with parameters)
...
|
+- ipfixFuncFn...The selection method SHOULD be designed as a MIB subtree introduced by an object with the name ipfixFunc appended by a function name. The objects in this subtree SHOULD be prefixed by this name. If the function is named Fx, then we would start a subtree with an OID named ipfixFuncFx. This subtree should contain an object ipfixFuncFxAvail that has the type TruthValue. If a selection method takes parameters, the MIB should contain a table named ipfixFuncFxParameters, which should contain all the parameters that the selection method specifies. An entry in this table will be referenced by the IPFIX MIB module if the selection method with the parameters is used ✨
to make it click, here's an example of a function MyFunc with three integer parameters, Param1, Param2, and Param3. In the example, there are currently two instances of the parameter sets, defined with indexes 1 and 4 🧁
ipfixSelectorFunctions (1)
|
+- ipfixFuncMyFunc (?)
|
+- ipfixFuncMyFuncAvail (1) = true
+- ipfixFuncMyFuncParameters (2)
|
+- ipfixFuncMyFuncParametersEntry (1)
|
+- index (1) (ipfixFuncMyFuncParametersIndex)
| +- ipfixFuncMyFuncParam1 (1) = 47
| +- ipfixFuncMyFuncParam2 (2) = -128
| +- ipfixFuncMyFuncParam3 (3) = 19
|
+- index(4) (ipfixFuncMyFuncParametersIndex)
+- ipfixFuncMyFuncParam1 (1) = 19
+- ipfixFuncMyFuncParam2 (2) = -1
+- ipfixFuncMyFuncParam3 (3) = 728if the function above gets referenced in the IPFIX MIB module, the ipfixSelectionProcessTable would look 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 that applies the same function two times, just with different parameter sets 🔥 First MyFunc runs with the parameters from the set at index 4, and then it runs again with the parameters from the set at index 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 Interfaces MIB module [RFC2863] 🌸
7.1. Relationship to the ENTITY MIB and Interfaces MIB
the Observation Point table (ipfixObservationPointTable) has a reference to the ENTITY MIB module [RFC4133] (ipfixObservationPointPhysicalEntity) and a reference to the Interfaces MIB module [RFC2863] (ipfixObservationPointPhysicalInterface). If the implementers of the IPFIX MIB module want to specify the physical entity where Flows are observed, then they SHOULD also implement the ENTITY MIB and/or the Interfaces MIB module. Implementing the ENTITY MIB and/or the Interfaces MIB module is OPTIONAL. If one of them is not implemented, then all values of the respective column ipfixObservationPointPhysicalEntity or ipfixObservationPointPhysicalInterface in the Observation Point table are zero, and the values of the ipfixObservationPointPhysicalEntityDirection columns are unknown(0), if none of them are defined 🙈
7.2. MIB Modules Required for IMPORTS
the IPFIX MIB module needs the modules 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 needs SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580] 💖
8. MIB Definitions
this section has the definitions of the IPFIX-MIB module and the IPFIX-SELECTOR-MIB module 👑 There are different mandatory groups defined for Collector and Exporter implementations. 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 "201206110000Z" -- 11 June 2012
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
Heidelberg 69115
Germany
Phone: +49 6221 4342-128
Email: Thomas.Dietz@neclab.eu
Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 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
Garching 85748
Germany
Email: muenz@net.in.tum.de"
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) 2012 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 "201206110000Z" -- 11 June 2012
DESCRIPTION
"Fixed errata from RFC 5815. Published as RFC 6615."
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 }okay this part is literally where the table gets real 💅 the sequence lists every column, and then each object gets its own definition with its index, its access rules, and where it lives in the entry 🎀
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 }
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/assignments/protocol-numbers/>."
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 { unknown(0), ipv4(1), ipv6 (2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of address used for the source address,
as specified in RFC 4001. The InetAddressType supported
values are ipv4(1) and ipv6(2). 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 { unknown(0), ipv4(1), ipv6 (2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of address used for the destination address,
as specified in RFC 4001. The InetAddressType supported
values are ipv4(1) and ipv6(2). 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 }the refresh timeouts and packet counts are giving very "only valid for UDP, zero everywhere else" energy 🦋
okay the refresh knobs and template tables are up next 🎀
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 }
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, for example, 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 }
--------------------------------------------------------------------
-- 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) Templates 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 (Options 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 the Template type to be easily retrieved.
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 the Transport Session 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 }
--------------------------------------------------------------------
-- 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/>.Okay bestie, the Template Definition table is wrapping up, then we're on to the Export Table 💅✨
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/>."
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) is 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 }
--------------------------------------------------------------------
-- 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 single
Transport Session; this session MUST have a member type
value of primary(1). Transport Sessions referenced in this
table MUST have a ipfixTransportSessionDeviceMode value of
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 indicates 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 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 member type (i.e., 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
member type (i.e., 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,
ipfixMeteringProcessCacheIdleTimeout 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
ipfixMeteringProcessTable. 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 }
ipfixMeteringProcessCacheIdleTimeout 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 }Next up: the Observation Point Entry, so keep your eyes peeled 👀🦋
Okay so this is where the MIB actually gets into the nitty gritty 💅 Each Observation Point gets its own entry, and the table is indexed by a group ID plus a point index 🦋
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 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 }
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 Interfaces 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 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
Interfaces 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 🧚 This is where the Selector Functions live, grouped into Selection Processes and applied in order of their selector index. The MIB even sketches out a little object tree so you can picture how they should be laid out 🌸
--------------------------------------------------------------------
-- 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 as indicated by the ipfixSelectionProcessSelectorIndex.
This means Selector Functions with a 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 help the reader 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)
...
|
+- ipfixFuncFn...
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
ipfixSelectionProcessSelectorFunctions 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 a 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 }Last bit for this part: the Transport Session Statistics Table 📊 It lists stats between Exporting Processes and Collecting Processes, and it AUGMENTS the Transport Session table, so it's like a little bonus layer on top 🎀
--------------------------------------------------------------------
-- 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 Session 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
}okay bestie, the Transport Session counters are literally the vibe 💖 These are the MIB objects that keep count of the traffic on each session 🦋 Let's get into it ✨
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 }
ipfixTransportSessionDiscardedMessages OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received IPFIX Messages 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, for example, 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 that 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 that 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 statistics 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
ipfixMeteringProcessCacheDiscontinuityTime."
::= { 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 that 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 a 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 }Okay so the stats are about to get spicy 📊✨ This first bit is the packet-dropping counter, and it's giving "how many packets did the selector just yeet" 💀
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 that no such discontinuity has
occurred since the last re-initialization of the local
management subsystem."
::= { ipfixSelectionProcessStatsEntry 3 }The discontinuity time is the bestie who tells you when the counters last glitched 🫶 A value of zero means nothing has glitched since the local management subsystem last got re-initialized. Very clean, very organized 🎀
Now we're moving into the conformance part, aka the section where the MIB gets its little rulebook 📖💅
--==================================================================
-- 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 with 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 with this MIB module
is limited to using only the values TCP (6), UDP (17), and
SCTP (132) in the ipfixTransportSessionProtocol object
because these are the only protocols 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 }So for the Collector compliance, the big rule is that it MUST implement everything in ipfixCommonGroup. Everything else in the other groups is optional and depends on what the equipment actually does 🤷♀️ The Collector also has to stick to TCP (6), UDP (17), and SCTP (132) for ipfixTransportSessionProtocol, because those are the only protocols IPFIX currently specifies (see RFC 5101). Strict, but iconic 👑
ipfixExporterCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"An implementation that builds an IPFIX Exporter that
complies with 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 statistics functions
are implemented in the equipment."
::= { ipfixCompliances 2 }The Exporter has a bigger to-do list 📦 It MUST implement ipfixCommonGroup and it also has to take on ipfixExporterGroup as mandatory. Then the stats groups are a vibe check: ipfixCommonStatsGroup should be implemented if the equipment does statistics, and ipfixExporterStatsGroup MUST be implemented if statistics functions are there. So if the equipment counts stuff, the Exporter has to count the Exporter stuff too 🧮💖
--------------------------------------------------------------------
-- 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,
ipfixMeteringProcessCacheIdleTimeout,
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 }
ENDAnd that's the grouping section, the sorting hat for every object 🌈🦋 The main groups hold the core IPFIX stuff, the common stats group holds the counters, and the Exporter groups hold everything that's specific to exporting 🧚 The whole thing wraps up with END 💜
8.2. IPFIX SELECTOR MIB Definition ✨
okay bestie, this is the actual MIB module, the IPFIX SELECTOR one 🎀 It has its own IMPORTS, its own identity, and its own conformance stuff, and it's the home of the standard Filtering and Sampling functions that the ipfixSelectionProcessTable can reference 💅 Everything is copied exactly below, left margin and all.
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 "201206110000Z" -- 11 June 2012
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
Heidelberg 69115
Germany
Phone: +49 6221 4342-128
Email: Thomas.Dietz@neclab.eu
Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 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
Garching 85748
Germany
Email: muenz@net.in.tum.de"
DESCRIPTION
"The IPFIX SELECTOR MIB module defined in this section
provides the standard Filtering and Sampling functions that
can be referenced in the ipfixSelectionProcessTable. All
standard Filtering and Sampling functions MUST be registered
in the subtree under object ipfixSelectorFunctions
(1.3.6.1.2.1.194.1.1). The top-level OIDs in the subtree
under object ipfixSelectorFunctions MUST be registered in a
sub-registry maintained by IANA at
<http://www.iana.org/assignments/smi-numbers/>.
New Selector Functions MUST be registered at IANA and are
subject to 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 new MIB objects. The specification
of new MIB objects SHOULD follow the structure specified in
[RFC6615] 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) 2012 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 "201206110000Z" -- 11 June 2012
DESCRIPTION
"Update to MIB description to reflect updated registration
of new Sampling and Filtering functions. Published as
RFC 6615."
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 with 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 so the good news first 🫶 there are no management objects in this MIB module with a MAX-ACCESS of read-write or read-create. Zero. So if this MIB module is implemented correctly, an intruder can't alter or create any of its management objects with direct SNMP SET operations 🔒
but the readable objects are a different story 👀 Any object with a MAX-ACCESS other than not-accessible can be sensitive or vulnerable in some 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, and why they're sensitive:
ipfixTransportSessionTable- contains configuration data that might be sensitive because objects in this table may reveal information about the network infrastructureipfixExportTable- contains configuration data that might be sensitive because objects in this table may reveal information about the network infrastructure as wellipfixMeteringProcessTable- contains configuration data that might be sensitive because objects in this table may reveal information about the IPFIX Device itselfipfixObservationPointTable- contains configuration data that might be sensitive because objects in this table may reveal information about the IPFIX Device itself and the network infrastructureipfixSelectorFunctions- currently contains no sensitive data but might want to be secured anyway, since it may contain sensitive data in a future version
All other objects and tables contain no data that is considered sensitive.
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. 🚨
Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. so lock it down, bestie 💖
10. IANA Considerations ✨
Okay so, IANA is the bestie who keeps all the registries, and this doc gives them a little to do 🦋 The MIB module here uses two OBJECT IDENTIFIER values that were already assigned in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
ipfixMIB { mib-2 193 }
ipfixSelectorMIB { mib-2 194 }The IPFIX SELECTOR MIB registry from [RFC5815] Section 10 has been removed by IANA 🗑️, since its use is discontinued with this document. Bye bye, old registry 🫶
IANA has created and maintains a sub-registry at http://www.iana.org/assignments/smi-numbers, and the top-level OIDs in the subtree under object ipfixSelectorFunctions MUST be registered there 💜 The starting version of this sub-registry looks like this:
Sub-registry Name: IPFIX-SELECTOR-MIB Functions
Reference: [RFC6615]
Registration Procedures: Expert Review [RFC5226]
Prefix: iso.org.dod.internet.mgmt.
mib-2.ipfixSelectorMIB.ipfixSelectorObjects.ipfixSelectorFunctions
(1.3.6.1.2.1.194.1.1)
Decimal Name Description Reference
------- ------------------ ----------------- ---------
1 ipfixFuncSelectAll Select everything [RFC6615]Adding things to this sub-registry is subject to Expert Review [RFC5226], which just means a group of experts picked by an IETF Area Director takes a look 🧐 That group MUST check the requested MIB objects for completeness and accuracy of the description, because accuracy is everything 💅 Requests for MIB objects that copy what an existing object already does SHOULD be declined, since nobody needs duplicates 🙅♀️ The smallest available OID SHOULD be assigned to new MIB objects 🔢 And the specification of new MIB objects SHOULD follow the structure from Section 6.1, and it MUST be published using a well-established and persistent publication medium 📚✨ The experts will start out drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups 🌸
11. Acknowledgments
Shoutout time 📣 This document is a product of the IPFIX Working Group, and the authors wanted to thank Paul Aitken for his detailed review 🫶 They also thank Dan Romascanu and the MIB doctors, plus many more people, for their technical reviews and feedback. The whole squad showed up for this one 🎀
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., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [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.
- [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
- [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.
- [RFC5101] Claise, B., Ed., "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.
- [RFC5815] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 5815, April 2010.
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.
- [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
- [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004.
- [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., Ed., 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., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
- [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
- [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
- [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011.
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@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
Diegem 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
EMail: muenz@net.in.tum.de📦 where this page comes from
- ietf: rfc6615 2012-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms