Internet Protocol Flow Information Export (IPFIX)

IPFIX (Internet Protocol Flow Information Export) is an IETF protocol created by the need for a common, universal standard of export for Internet Protocol flow information from routers, probes and other devices used by mediation systems, accounting/billing systems and network management systems to facilitate services such as measurement, accounting and billing. The IPFIX standard defines how IP flow information is to be formatted and transferred from an exporter to a collector.

IPFIX Architecture

A Metering Process collects data packets at an Observation Point, optionally filters them and then aggregates information about these packets. Using the IPFIX protocol, an Exporter then sends this information to a Collector. Exporters and Collectors in a many-to-many relationship as one Exporter can send data to many Collectors and one Collector can receive data from many Exporters.

IPFIX Protocol

IPFIX considers a flow to be any number of packets observed in a specific timeslot and sharing a number of properties such as same source, same destination, or same protocol. Using IPFIX, devices such as routers send information to a central monitoring station about the view of a potentially larger network.

IPFIX is a push protocol, meaning each sender periodically sends IPFIX messages to configured receivers without any interaction by the receiver.

The actual makeup of data in IPFIX messages depends on the sender. IPFIX introduces the makeup of these messages to the receiver with the help of special Templates. The sender also accepts user-defined data types in the messages, so the protocol is freely extensible and can adapt to different scenarios.

IPFIX prefers the Stream Control Transmission Protocol (SCTP) as the transport layer protocol, but also allows the use of the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). SCTP provides some of the same service features of both TCP and UDP. SCTP consists of message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP. It differs from the two protocols when providing multi-homing and redundant paths to increase resilience and reliability.

IPFIX Collector

Flow collectors dynamically reads the templates exported by flow capable hardware and store the flows being sent. Most IPFIX collectors provide reporting on the data and some even provide behavior analysis to help detect network threats.

On each Pluribus switch, Netvisor OS embeds a real-time non-sampled IPFIX metering process, and each switch can be configured as an IPFIX exporter. In addition, Netvisor OS supports exporting to multiple collectors.

Bidirectional Flow Support

Pluribus Networks supports bidirectional flows for IPFIX in that every flow record contains the attribute of both endpoints. Many flow analysis tasks benefit from association of the upstream and downstream flows of a bidirectional communication, for example, separating answered and unanswered TCP requests, calculating round trip times, and more. Metering processes not part of an asymmetric routing infrastructure, especially those deployed at a single point through which bidirectional traffic flows, are well positioned to observe bidirectional flows (Biflows). In such topologies, the total resource requirements for Biflow assembly are often lower if the Biflows are assembled at the measurement interface as opposed to the IPFIX Collector. The IPFIX Protocol requires only information model extensions to be complete as a solution for exporting Biflow data.

Information Elements

Information in messages of the IPFIX protocol is modeled in terms of Information Elements of the IPFIX information model.

All Information Elements specified for the IPFIX protocol has the following properties defined:

Abstract Data Types Supported by IPFIX

IPFIX supports abstract data types unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64. These data type semantics can be further specified, for example, by totalCounter, deltaCounter, identifier, or flags.

Abstract Data Type

Description

unsigned8

Represents a non-negative integer value in the range of 0 to 255.

unsigned16

Represents a non-negative integer value in the range of 0 to 65535.

unsigned32

Represents a non-negative integer value in the range of 0 to 4294967295.

unsigned64

Represents a non-negative integer value in the range of 0 to 18446744073709551615.

signed8

Represents an integer value in the range of -128 to 127.

signed16

Represents an integer value in the range of -32768 to 32767.

signed32

Represents an integer value in the range of -2147483648 to 2147483647.

signed64

Represents an integer value in the range of

  -9223372036854775808 to 9223372036854775807

float32

Corresponds to an IEEE single-precision 32-bit floating-point type

float64

Corresponds to an IEEE single-precision 64-bit floating-point type

boolean

Represents a binary value. The only allowed values are true and false.

macAddress

Represents a MAC-48 address

octetArray

Represents a finite-length string of octets.

string

Represents a finite-length string of valid characters from the Unicode coded character set. Unicode incorporates ASCII and the characters of many other international character sets.

dateTimeSeconds

Represents a time value expressed with second-level precision.

dateTimeMilliseconds

Represents a time value expressed with millisecond-level precision.

dateTimeMicrosecond

Represents a time value expressed with microsecond-level precision

dateTimeNanoseconds

Represents a time value expressed with nanosecond-level precision.

ipv4Address

Represents an IPv4 address.

ipv6Address

Represents an IPv6 address.

basicList

Supports structured data export.

subTemplateList

Supports structured data export.

subTemplateMultiList

supports structured data export.

Data Type Semantics Supported by IPFIX

These semantics apply only to numeric types, as noted in the description of each semantic below.

Abstract Data Type

Description

quantity

A numeric (integral or floating point) value representing a measured value pertaining to the record. This is distinguished from counters that represent an ongoing measured value whose "odometer" reading is captured as part of a given record. This is the default semantic type of all numeric data types.

totalCounter

An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type.  For example, an unsigned64 with counter semantics continues to increment until reaching the value of 2**64 - 1.  At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a total counter is similar to the semantics of counters used in the Simple Network Management Protocol (SNMP), such as Counter32 . The only difference between total counters and counters used in SNMP is that the total counters have an initial value of 0. A total counter counts independently of the export of its value.

deltaCounter

An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics continues to increment until reaching the value of 2**64 - 1. At this point, the next increment wraps its value to zero and continue counting from zero. The semantics of a delta counter is similar to the semantics of counters used in SNMP, such as Counter32. The only difference between delta counters and counters used in SNMP is that the delta counters have an initial value of 0. A delta counter is reset to 0 each time it is exported and/or expires without export.

identifier

An integral value that serves as an identifier. Specifically, mathematical operations on two identifiers (aside from the equality operation) are meaningless. For example, Autonomous System ID 1 * Autonomous System ID 2 is meaningless. Identifiers MUST be one of the signed or unsigned data types.

flags

An integral value that represents a set of bit fields. Logical operations are appropriate on such values, but other mathematical operations are not.  Flags MUST always be of an unsigned data type.

Information Elements Supported by Netvisor OS and IPFIX

Data Field

Element ID

Name

Description

Data Type

Units

Data Type Semantic

proto

4

protocolIdentifier

The value of the protocol number in the IP packet header.

The protocol number identifies the IP packet payload type. Protocol numbers are defined in the IANA Protocol Numbers registry.

unsigned8

 

identifier

cur-state

6

tcpControlBits

TCP control bits observed for the packets of this Flow. This information is encoded as a bit field. For each TCP control bit, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow has the corresponding TCP control bit set to 1. The bit is cleared to 0 otherwise.

unsigned16

 

flags

src-port

7

sourceTransportPort

The source port identifier in the transport header. For the transport protocols UDP, TCP, and SCTP, this is the source port number in the respective header. This field MAY also be used for future transport protocols with 16-bit source port identifiers.

unsigned16

 

identifier

src-ip

8

sourceIPv4Address

The IPv4 source address in the IP packet header.

ipv4Address

 

default

src-switch-port

10

ingressInterface

The index of the IP interface where packets of this Flow are received. The value matches the value of managed object 'ifIndex'. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized,

unsigned32

 

identifier

dst-port

11

destinationTransportPort

The destination port identifier in the transport header. For the transport protocols UDP, TCP, and SCTP, this is the destination port number in the respective header. This field MAY also be used for future transport protocols

with 16-bit destination port identifiers.

unsigned16

 

identifier

dst-ip

12

destinationIPv4Address

The IPv4 destination address in the IP packet header.

ipv4Address

 

default

dst-switch-
port

14

egressInterface

The index of the IP interface where packets of this Flow are sent. The value matches the value of managed object 'ifIndex' .

Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized.

unsigned32

 

identifier

 

41

exportedMessageTotalCount

The total number of IPFIX Messages the Exporting Process has sent since the Exporting Process (re-)initialization to a particular Collecting Process. The reported number excludes the IPFIX Message that carries the counter value. If this Information Element is sent to a particular Collecting Process, then by default, it specifies the number of IPFIX Messages sent to the Collecting Process.

unsigned64

messages

totalCounter

 

 

 

The total number of Flow Records that the Exporting Process has sent as Data Records since the Exporting Process (re-)initialization to a particular Collecting Process. The reported number excludes Flow Records in the IPFIX Message with the counter value.

If this Information Element is sent to a particular Collecting Process, then by default, it specifies the number of Flow Records sent to the process.

 

 

 

src-mac

56

sourceMacAddress

The IEEE 802 source MAC address field.

macAddress

 

default

vlan

58

vlanId

Virtual LAN identifier associated with ingress interface.

unsigned16

 

identifier

dst-mac

80

destinationMacAddress

The IEEE 802 source MAC address field.

macAddress

 

default

started-time

150

flowStartSeconds

The absolute timestamp of the first packet of this Flow.

dateTimeSeconds

seconds

default

ended-time

151

flowEndSeconds

The absolute timestamp of the last packet of this Flow.

dateTimeSeconds

seconds

default

 

216

 

 

unsigned16

 

identifier

 

217

 

 

unsigned16

 

identifier

 

218

 

 

unsigned64

packets

totalCounter

 

219

 

 

unsigned64

packets

totalCounter

 

222

 

 

unsigned64

packets

totalCounter

obytes

231

InitiatorOctets

The total number of Layer 4 payload bytes in a flow from the initiator. The initiator is the device triggering the session creation, and remains the same for the life of the session.

unsigned64

octets

deltaCounter

ibytes

232

responderOctets

The total number of Layer 4 payload bytes in a flow from the responder. The responder is the device that replies to the initiator, and remains the same for the life of the session.

unsigned64

octets

deltaCounter

0x01

239

 

 

unsigned8

 

identifier

src-switch-port

252

 

 

unsigned32

 

unsigned32

dst-switch-port

253

egressPhysicalInterface

The index of a networking device's physical interface for example, a switch port, where the flow packets are sent.

unsigned32

 

identifier

ether-type

256

ethernetType

The Ethernet type field of an Ethernet frame identifying the MAC client protocol carried in the payload.

unsigned16

 

identifier

 

257

 

 

unsigned8

 

identifier

 

258

 

 

dateTimeSeconds

milliseconds

default

 

259

 

 

unsigned16

 

identifier

 

260

 

 

dateTimeSeconds

seconds

default

 

261

 

 

dateTimeSeconds

seconds

default

 

262

 

 

octetArray

 

default

 

349

 

 

octetArray

 

default

 

350

 

 

string

 

default

 

351

layer2Segment

The identifier of a Layer 2 network segment in an overlay network.

The most significant byte identifies the Layer 2 network overlay network encapsulation type:

• 0x00 reserved

• 0x01 VxLAN

• 0x02 NVGRE

The three lowest significant bytes hold the value of the Layer 2 overlay network segment identifier.

For example:

• a 24 bit segment ID VXLAN Network Identifier (VNI)

• a 24 bit Tenant Network Identifier (TNI) for NVGRE

unsigned64

 

identifier

 

368

 

 

unsigned32

 

identifier

 

369

 

 

unsigned32

 

identifier

 

401

 

 

unsigned64

octets

deltaCounter

Netvisor OS also supports the following private Information Elements:

latency

47269.1

Latency
Microseconds

TCP session latency

dateTimeSeconds

microseconds

default

Configuring IPFIX

To configure IPFIX from the CLI, you must have a host IP address as the destination for the IPFIX collector. Netvisor OS uses port 9090 by default, and the default transport protocol TCP.

CLI network-admin@switch > ipfix-collector-create name ipfix-host1 port 9090 transport-protocol tcp dscp 3

To enable the IPFIX service, use the command, ipfix-service-modify enable. You can also set the collection interval using this command. To set the collection interval to one hour, use the following syntax:

CLI network-admin@switch > ipfix-service-modify enable export-interval 0d1h0m0s

Topic Feedback

Was this topic useful to you? Please provide feedback to improve the content.