Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Inband Flow Analyzer (IFA) 2.0 Real-Time Flow Monitoring

Inband Flow Analyzer (IFA) 2.0 collects data on a per-hop basis across the network. You export this data to external collectors to perform localized or end-to-end analytics.

Inband Flow Analyzer 2.0

Inband Flow Analyzer 2.0 Overview

Inband Flow Analyzer 2.0 (IFA 2.0) is a feature that you can use to monitor and analyze packets as they enter and exit the network. As the network administrator, you can use this feature to collect data related to the paths the packets take through the network and how long the packets spend at each hop. This data provides an indication of excessive latency and possible congestion. This feature helps you to get insights about complex networks by collecting per-hop flow data on the data plane.

IFA collects network-wide flow data using either live mode or probe mode. When the node operates in live mode, the software inserts the IFA base header and IFA metadata into the live packets. When the node operates in probe mode, the software samples the live packet flow and copies the sampled packet to create the initial packet that carries the IFA layers. These probe packets are representative of the original flow, possessing the same characteristics as the original flow. This means that IFA probe packets traverse the same path in the network and the same queues in the networking element as the original live packet would. As a result, IFA probe packets traverse the same network path as the original flow, experiencing similar latency and congestion.

You can use Inband Flow Analyzer 2.0 (IFA 2.0) to collect flow data information such as:

  • Residence time (latency)

  • Per-hop latency

  • Per-hop ingress port number

  • Per-hop egress port number

  • Received packet timestamp value

  • Queue ID

  • Congestion notification

  • Egress port speed

IFA 2.0 is defined in the IETF draft titled Inband Flow Analyzer, draft-kumar-ippm-ifa-02.

Benefits

  • IFA probe packets traverse the same network path as the original flow, helping you to monitor the network for faults and performance issues.
  • Monitors live traffic and thus helps to perform packet-level latency analysis and queue-congestion monitoring to optimize the network performance.

Modes (Junos OS Evolved only)

Starting in Junos OS Evolved Release 25.4R1, we support two modes for the IFA 2.0 feature. The new modes are as follows:

  • In live mode, for those switches that support it, IFA 2.0 uses the original packets as IFA packets.

  • In probe mode, IFA 2.0 uses copies of the original packets as the IFA probe packets. This mode is the default.

When you configure an IFA initiator node to initiate IFA packets:

  • In live mode, the initiator inserts IFA headers and metadata into the live packets.

  • In probe mode, the initiator samples the flow and copies that sample to create the probe.

When you configure an IFA terminator node to parse the IFA header in the packet:

  • If it is a live packet, then the terminator strips the IFA layer and forwards the modified live packet to its destination. The terminator also sends a mirror copy of the IFA packet, with all of the IFA metadata, to the IFA collector.

  • If the packet is a probe packet, then the terminator drops the packet and sends a mirror copy to the collector with all the IFA metadata.

To specify the mode, configure the mode (live | probe) statement at the [edit services inband-flow-telemetry] hierarchy level. The default mode is probe. Use the show services inband-flow-telemetry global command to see results that include the mode information.

Inband Flow Analyzer Process

IFA uses the following processing nodes (as shown in Figure 1) to monitor and analyze flows:

  • IFA initiator node (also known as ingress node)

  • IFA transit node

  • IFA terminator node (also known as egress node)

IFA 2.0 supports processing both Layer 3 (L3) and VXLAN flows, but you can't configure IFA for both L3 and VXLAN flows on the same device. The flow-type options are mutually exclusive. You use the flow-type configuration statement to set the flow type of interest —either L3 or VXLAN. You configure the flow-type statement only for the IFA initiator and IFA terminator nodes (generally leaf nodes). For an IFA transit node (generally a spine node), you don't need to configure the flow-type statement.

Figure 1: IFA Processing Flow diagram illustrating IFA data collection: Initiator Node, Transit Node, terminator Node, and Collector with blue arrow for original flow and black arrow for IFA copy.

Table 1 summarizes the different functions that the IFA processing nodes perform:

Table 1: IFA Node Functions
IFA Node Function

IFA initiator node

Samples the flow traffic of interest (L3 or VXLAN) and creates an IFA copy by adding an IFA header to each sample. If you configured live mode, the initiator inserts IFA headers and metadata into the live packets.

IFA transit node

 Identifies IFA packets and appends their metadata to the metadata stack in the packet.

  • If any packet comes with an IFA header, the node inserts the metadata into the metadata stack and forwards it. If the hop limit is 0, the node does not insert the metadata.

  • When a non-IFA device receives an IFA packet, the device forwards it without IFA processing.

  • The QFX5220 as an IFA transit node can not insert metadata into the metadata stack of the IFA probe packet header. Instead, the QFX5220 adds a tailstamp to the end of the IFA probe packet that includes timestamps and other metadata.

IFA terminator node

  • Inserts terminator node metadata into an IFA packet.

  • Formats the IFA packets in IP Flow Information Export (IPFIX) format and sends the packets to the configured collector. You can use any collector (or application) that supports the IPFIX format. Unlike the QFX5120 switch, the QFX5240 switch does not use the IPFIX format. Instead, the QFX5240 switch uses the IPFIX PSAMP format to format the data sent to the collector.

Note:

IFA terminator functionality requires a valid Juniper Advanced Telemetry Feature (ATF) license. The QFX5240 switch does not need a license for IFA termination.

IFA Probe Packet Headers

An IFA 2.0 probe packet contains the following:

  • IFA Header

  • IFA Metadata Header

  • IFA Metadata Stack

Figure 2 shows the L3 IFA 2.0 packet format at the IFA initiator node:

Figure 2: Layer 3 IFA 2.0 Packet Format at the IFA Initiator Node Diagram of network packet structure showing layers: L2 Header, L3 Header, IFA Header, L4 Header, IFA Metadata Header, IFA Metadata Stack, and Payload. IFA components are highlighted.

Figure 3 shows the VXLAN IFA 2.0 packet format at the IFA initiator node.

Figure 3: VXLAN IFA 2.0 Packet Format at the IFA Initiator Node Packet structure showing encapsulation layers and headers for telemetry: outer L2, L3, L4, IFA headers, VxLAN, inner L2, L3, L4, and payload.
Note:

When VXLAN is used, then the IFA headers are added after VXLAN encapsulation using a three-pass mechanism.

IFA Header

IFA 2.0 defines an upper layer header (ULH), similar to how TCP, UDP, Generic Routing Encapsulation (GRE), and Spanning Tree Protocol (STP) define a ULH. The IFA ULH is always the first header after the IP header, even if there are some other IPv4 extension headers. The NextHdr field (that is, the Protocol Type field in the IFA header) carries the original IP header protocol field value. Figure 4 shows the IFA header format.

Figure 4: IFA Header IFA header format with fields: IFA Version 4 bits, GNS 4 bits, Protocol Type 8 bits, FLAGS 8 bits, MAX Length 8 bits.
Table 2 provides details about the IFA header fields.
Table 2: IFA Header Fields
IFA Header Field Description

IFA Version

Version of the IFA header. In the current implementation, the IFA version is 2.0.

GNS

Global namespace (GNS) for IFA metadata. The IFA initiator node sets the value for this field as 0xF.

Protocol Type

IP header protocol type. This value is copied from the IP header.

FLAGS

Unused

MAX Length

Maximum allowed length of the metadata stack in multiples of four octets. The initiator node initializes this field. Each node in the path compares the current length with the maximum length. If the current length equals or exceeds the maximum length, the transit node stops inserting metadata. You can configure this maximum allowed length. The default value is 240 octets (for 30 hops).

IFA Metadata Header

IFA 2.0 defines a compact 4-byte metadata header as shown in Figure 5. The IFA initiator node adds this header to the probe packet.

Figure 5: IFA Metadata Header Format Data structure with four 8-bit fields: Request Vector, Action Vector, Hop Limit, and Current Length; identifier jn-000099.
Table 3 provides details about the IFA metadata header fields.
Table 3: IFA Metadata Header Fields
IFA Metadata Header Field Description

Request Vector

Specifies the presence of fields as specified by the GNS. Unused.

Action Vector

Specifies the node-local or the end-to-end action on the IFA packets. Unused.

Hop Limit

Specifies the maximum number of allowed hops in an IFA zone. The initiator node initializes this field. The hop limit is decremented at each hop. If the hop limit of the incoming packet is 0, the current node does not insert metadata. You can configure this limit. The default value is 250.

The terminator node does not perform the hop limit check.

Current Length

Specifies the current length of the metadata stack in multiples of 4 octets.

IFA Metadata Stack

Each IFA hop inserts hop-specific metadata into an IFA metadata stack as shown in Figure 6. The IFA initiator node adds the metadata header after the L4 header.

The QFX5220 as a transit node can not insert metadata into the metadata stack of the IFA probe packet header. Instead, the QFX5220 adds a tailstamp to the end of the IFA probe packet that includes timestamps and other metadata. For more information about these tailstamps, see Tailstamps for IFA Probe Packets (QFX5220 only).

The Egress Port Speed field in the IFA 2.0 Metadata stack is not supported on the QFX5230. The value in the field is always '0' irrespective of the egress port speed.

Figure 6: IFA Metadata Stack Header Diagram of data packet structure with fields: LNS 4 bits, Device ID 20 bits, IP TTL 8 bits, Egress Port Speed 4 bits, Congestion 2 bits, Queue ID 6 bits, Rx Timestamp Seconds 20 bits, Egress Port Number 16 bits, Ingress Port Number 16 bits, RX Timestamp Nano Seconds 32 bits, Residence Time Nano Seconds 32 bits, Opaque Data 1 Reserved 32 bits, Opaque Data 2 Hi Reserved 16 bits, Opaque Data 2 Low Reserved 16 bits, Opaque Data 3 Reserved 32 bits.
Table 4 provides details about the IFA metadata stack header fields.
Table 4: IFA Metadata Stack Header Fields
IFA Metadata Stack Header Field Description

LNS

Local namespace. You must set the LNS value to 1.

Device ID

User-configurable device ID. You can explicitly configure the device ID or configure the device-id auto statement. If you configure device-id auto, the device ID is internally generated from the router ID or the management IP address.

IP TTL

IP time-to-live (TTL) value at each hop.

Egress Port Speed

Encodings are 0–10Gbps, 1–25Gbps, 2–40Gbps, 3–50Gbps, 4–100Gbps, 5–200Gbps, 6–400Gbps, 7–800Gbps.

Egress port speed is mapped with IFA metadata. For example, when a egress port speed is 10Gbps, then the speed field of IFA packet is set to 0.

Congestion

Indicates whether the packet has experienced congestion. You must enable an explicit congestion notification (ECN) on the egress port.

Queue ID

Egress port queue ID.

Rx Timestamp Seconds

Received packet timestamp value (in seconds). It is the collector's responsibility to retrieve time-of-day (ToD) from these 20-bit values. 20-bit seconds will wrap around every 12 days. Collector has to periodically sync up ToD within the wraparound time and use it along with 20-bit from metadata to derive the 32-bit Rx Timestamp Seconds value.

Egress Port Number

Egress hardware (ASIC) port number.

Ingress Port Number

Ingress hardware port number.

Rx Timestamp Nano Seconds

Received timestamp value in nanoseconds. This timestamp is the exact value after the timestamp in seconds. Add this to the Rx Timestamp Seconds value to get the exact timestamp with nanoseconds precision.

Residence Time Nano Seconds

Per-hop latency in nanoseconds. For the QFX5120, the residence time is calculated as 0x3B9ACA00 (1 second in nanoseconds) + TX_NSEC - RX_NSEC. (An extra second is added to every packet to avoid wraparound handling.) In contrast, for the QFX5130, QFX5220, QFX5230, QFX5240, QFX5241, and QFX5700, the residence time is updated as the actual value.

Tailstamps for IFA Probe Packets (QFX5220 only)

The QFX5220 as a transit node can not insert metadata into the metadata stack of the IFA probe packet header. Instead, the QFX5220 adds a tailstamp to the end of the IFA probe packet that includes timestamps and other metadata. The QFX5220 adds a total of 28 bytes of metadata as a tailstamp. Upon receiving the IFA probe packet, the IFA termination node uses the TTL value in the metadata to identify the number of tailstamps (that is, the number of QFX5220 hops on the path between two QFX5120 or QFX5130 devices). Then the tailstamps are converted into the correct metadata format and inserted into the correct place in the metadata stack, so that the metadata appears in the order that the transit nodes added them. Once complete, the IFA termination node exports the data in IPFIX format to the configured external collector.

Due to this inability to insert metadata into the stack, the IFA metadata stack fields IP TTL , Egress Port Speed and Congestion for the QFX5220 are received with the value of 0 at the collector. You must configure the collector to ignore these unsupported fields from the QFX5220.

The tailstamp includes 14 bytes of ingress (Rx) tailstamp and 14 bytes of egress (Tx) tailstamp. Figure 7 and Figure 8 provide details about the format of these timestamps.

Figure 7: Ingress (Rx) Tailstamp Format Diagram of a network protocol data packet structure with fields: Timestamp Seconds, Timestamp Nano Seconds, Reserved, Origin_ID with Device ID and Port Number, R/T, and FCS for error-checking.
Figure 8: Egress (Tx) Tailstamp Format Diagram of a data packet structure with fields: Timestamp Seconds, Timestamp Nano Seconds, T, R, Q, C flags, Origin_ID, R/T flag, and FCS for error detection.

Supported Features on IFA Nodes

Table 5 lists the features supported by IFA nodes.

Table 5: Supported Features on IFA Nodes
IFA Node Supported Features

IFA initiator

Traffic and interface types:

  • IPv4 and IPv6 traffic.

  • VXLAN traffic.

  • UDP and TCP.

  • Tagged and untagged packets.

  • Aggregation links (LAG) and multichassis LAG (MC-LAG). In case of LAG egress, the original packet and the IFA probe copy use the same port to exit.

  • IRB interfaces. (The inband-flow-telemetry-init and inband-flow-telemetry-terminate filters must be applied on the underlying Layer 2 interfaces for IRB traffic.)

  • ECMP traffic. In case of ECMP traffic, the original packet and the IFA probe copy use the same port to exit.

  • Interface speeds, such as 10 Gbps, 25 Gbps, 40 Gbps, 50 Gbps,100 Gbps, 200 Gbps, 400 Gbps, and 800 Gbps.

IFA transit

Identifies IFA packets, appends their metadata, and forwards it.

IFA terminator

  • Support to export IFA data to any configured IPv4 collector in IPFIX format.

  • (QFX5120 switch only) Support to combine multiple IFA packets into a single IPFIX export.

  • (QFX5240 switch only) Support for a single packet in a single IPFIX PSAMP export.

Supported IFA 2.0 IPFIX Format (Terminator Node)

The terminator node formats the IFA 2.0 packets in IPFIX format, updates the egress port information, and sends the packet to the configured collector. The IFA 2.0 IPFIX template is the same for L3 traffic and VXLAN traffic. Figure 9 shows the IPFIX template in which the terminator node formats the IFA 2.0 data and sends it to a collector.

You cannot use the QFX5220 switch as an IFA transit node when a QFX5240 switch is the IFA terminator mode.

The QFX5240 switch does not use these IPFIX templates. Instead, the QFX5240 switch terminates the IFA packet, mirror encapsulates it, and sends one IPFIX PSAMP packet to the collector for each IFA packet. The PSAMP packet contains the destination MAC address of the collector, the source MAC address of the collector, the user-configurable source IP address, the user-configurable destination IP address, the UDP source port, the user-configurable UDP destination port, the IPFIX PSAMP header, and the MAC source and destination addresses of either the IFA or the original packet. These fields are followed by the IP layer header, IFA header, L4 layer (UDP/TCP) header, IFA metadata header and IFA metadata stack, and the payload.

Figure 9: IFA 2.0 IPFIX Template Decoded IPFIX packet showing protocol version 10, message length 48 bytes, timestamp Jan 11 1970, flow sequence 1128891, observation domain ID 305419896, and a data template with ID 257 and three fields with types 100, 101, and 102.

Figure 10 shows the template for an IFA 2.0 IPFIX PSAMP packet received by the collector.

Figure 10: IFA 2.0 IPFIX PSAMP Template IPFIX PSAMP packet template image showing a data template.

Figure 11 shows a sample VXLAN IFA 2.0 packet received by the configured collector in IPFIX format.

Figure 11: VXLAN IFA 2.0 IPFIX Sample Packet Network flow data packet screenshot from a monitoring tool showing IPFIX protocol version 10, flow details with version, length, timestamp, flow sequence, observation domain id, set id 257, and enterprise-specific entries in hexadecimal.

Limitations of IFA 2.0 Configuration

Before you configure IFA 2.0 on a device running Junos OS, you must be aware of the following limitations:

  • Protocol Number—IFA 2.0 uses the experimental protocol number 253. If the switch receives any traffic with protocol number 253, those packets will hit the IFA transit filter. In this case the QFX5220 adds a 28-byte tailstamp to those packets. For the QFX5130, QFX5230, QFX5240, and QFX5700 switches, even though the packets hit the filter, IFA metadata is not added to the packets. However, the IFA transit statistics do increment.

  • Filter Resource Allocation—If filter hardware resources are already exhausted in the system, the IFA feature does not work because it needs filter resources. You can monitor the system log (syslog) for filter space exhaustion errors.

  • Layer 2 and BUM Traffic—IFA 2.0 is not supported on Layer 2 switched traffic and broadcast, unknown unicast, and multicast (BUM) traffic.

  • IFA Layer 3 and VXLAN Flows

    • IFA 2.0 supports processing both L3 and VXLAN flows, but you can't configure IFA for both L3 and VXLAN flows on the same device. The flow-type options are mutually exclusive. You use the flow-type configuration statement to set the flow type of interest —either L3 or VXLAN. This restriction is only applicable for IFA initiator and terminator nodes (generally leaf nodes). For IFA transit nodes (generally spine nodes), it is not required to configure the flow type.

    • (For QFX5120 switches only) For a VXLAN IFA flow, the egress port-related metadata for the terminator node (including egress port number, speed, queue ID, and congestion) are incorrect. It is recommended that you ignore the terminator node egress-port-related metadata for VXLAN flows.

    • (For QFX5240 switches only) For VXLAN flows, IFA terminated packets sent to the collector contain metadata from only the initiator node and all the transit nodes. These packets do not contain metadata from the terminator node.

    • An IFA flow-type (L3 or VXLAN) change requires IFA filter removal and reconfiguration. In case of a flow-type mismatch (for example, flow-type configured as VXLAN, whereas the incoming traffic is L3 or vice versa), we can't guarantee IFA behavior (IFA packets could be initiated with invalid fields).

  • IFA Initiator Node

    • L4 header (UDP/TCP) is mandatory for IFA initiation.

    • IFA initiation for VXLAN flow does not work if the egress port is configured to function as a link aggregation group (LAG) (links connecting leaf to spine).

  • IFA Transit Nodes—Devices running Junos OS and Junos OS Evolved do not support the maximum length check for the metadata stack. Configure the hop-limit option to limit the insertion of metadata on transit nodes. The QFX5220 transit node cannot perform the hop-limit check to insert the tailstamp. The QFX5220 transit node also cannot insert metadata into the metadata stack in the IFA probe packet header; instead, the QFX5220 transit node appends a tailstamp to the end of the IFA probe packet.

    The QFX5220 transit node supports only 18 bits for the Rx Seconds Timestamp value. The QFX5130, QFX5230, QFX5240, QFX5241, and QFX5700 transit nodes support a 20-bit Rx Seconds Timestamp value.

    The Residence Time Nano Seconds field is updated as the actual value on the QFX5220, QFX5230, QFX5240, QFX5241, QFX5130, and QFX5700 transit nodes, but on the QFX5120 transit node, 1 second (1000000000 ns) is added along with the actual residence time. ​

  • IFA Terminator Node

    • You can configure only a single IPv4 collector at the terminator node.

    • (QFX5120 terminator nodes only) The terminator node metadata has the queue ID 47. This queue ID is reserved for IFA packet export.

    • (QFX5120 terminator nodes only) The terminator node does not perform a hop-limit check. Even if the incoming IFA packet has hop-limit set to 0, the terminator node inserts the metadata and reduces the hop limit by 1, which resets the hop-limit value to 255.

Usage Considerations

Following are the IFA 2.0 related usage considerations:

  • Sampled IFA packets have an additional 40 bytes (4-byte IFA header + 4-byte IFA metadata header + 32-byte metadata) when it egresses on the initiator node. On subsequent IFA nodes, 32-byte IFA metadata is inserted at every hop. Due to insertion of per-hop metadata into IFA packets, the packet size grows after every hop. You must configure the interface's maximum transmission unit (MTU) accordingly along the network path. In case of an IFA zone with a large number of transit nodes, you must take care of the MTU. Alternatively, you can configure the hop-limit option at the initiator node to ensure that the size of the IFA packets never exceeds the specified MTU value.

  • To select the flow of interest, you can use any combination of source IP address, destination IP address, source port, destination port, and protocol match qualifiers. For VXLAN termination on a terminator node, use the outer source IP address and destination IP address as match qualifiers. IFA 2.0 doesn't support any other match qualifiers for the QFX5120 switch. For a QFX5240 terminator node, we recommend that you use any combination of the outer source IP address and destination IP address, source port, destination port, and protocol as match qualifiers, but you can also use any other available match qualifiers under the term to select a flow.

    Another option is to configure the initiation or termination filter without any qualifiers. In this case, all incoming IFA packets on the port are initiated or terminated.

  • You must configure a unique device ID for each hop within an IFA zone. If you've configured the auto option for the device ID, then the device ID is generated from the last 20 bits of the router ID or management IP address.

  • If you've configured the sampling rate as aggressive, the egress ports might experience congestion due to more IFA copies. This port congestion could create congestion on terminator nodes when IFA copies are sent to the chip processor for IPFIX export. We recommend that you select the sampling rate accordingly.

  • When you configure an IFA 2.0 initiator, an internal mirror session is created for the loopback port. As a result, the number of user-configurable mirror sessions reduces from 4 to 3 on the QFX5120 switch or reduces from 8 to 7 on the QFX5240 switch.

  • The terminator node accepts an IFA packet size up to 9000 bytes (including IFA headers). On the terminator node, multiple IFA received packets are combined into a single IPFIX export packet. You can combine a maximum of 10 IFA records in a single IPFIX export packet. By default, a maximum of 256 bytes of the original flow packet are exported as part of the IPFIX export, along with IFA headers. The maximum size of a single IPFIX packet is 9000 bytes. You must configure the MTU properly on the collector port. Because the maximum size of a single IPFIX packet is 9000 bytes, the maximum clip length for the IPFIX packet is equal to or less than: 9000 bytes - (IFA header length + IFA metadata header length + IFA metadata stack length).

  • On a QFX5240 terminator mode, for both live and probe mode, the entire IFA packet is mirror encapsulated using IPFIX PSAMP format, for both Layer 3 and VXLAN flows. The software sends one IPFIX PSAMP packet to the collector for each IFA packet.

  • We recommend that you use only IFA-aware (supported) devices within the IFA zone. We cannot guarantee proper IFA behavior with IFA-unaware devices.

Configure Inband Flow Analyzer 2.0

IFA is a type of Inband Network Telemetry (INT) that allows you to collect information about the network state by the data plane.

To configure IFA 2.0 for monitoring the network for faults, performance issues, and collect the data for analysis, you need to configure the IFA roles first. You can configure the IFA roles on a Junos OS or Junos OS Evolved device that supports the IFA feature. See Feature Explorer: Inband Flow Analyzer (IFA) 2.0 for supported devices.

Table 6 describes the interoperability of the QFX5240 switch with other supported devices for IFA initiator, transit, and terminator roles:

Table 6: IFA Roles Supported, by Device Model
IFA initiator IFA transit IFA terminator

QFX5240, live or probe mode

QFX5120, QFX5130, QFX5230, QFX5240, and QFX5241

QFX5240 (mode is not configured on a terminator node)

QFX5240, probe mode

QFX5120, QFX5130, QFX5220, QFX5230, QFX5240, and QFX5241

QFX5120 (we support only probe mode on this platform)

Note: For a QFX5220 transit node, we support only the QFX5120 switch as the terminator node because the QFX5120 switch can convert tailstamps into metadata.

QFX5120 (we support only probe mode on this platform)

QFX5120, QFX5130, QFX5230, QFX5240, and QFX5241

QFX5240 (mode is not configured on a terminator node)

QFX5120 (we support only probe mode on this platform)

QFX5120, QFX5130, QFX5220, QFX5230, QFX5240, and QFX5241

QFX5120 (we support only probe mode on this platform)

Following are some of the guidelines for configuring a Junos OS device for an IFA role:

  • You can use the same model switches or different switches to play the IFA roles (initiator, transit, terminator) for a particular IFA flow.
  • You can use the same device to perform all three different IFA roles for different flows.
  • In an IFA flow, the transit IFA role is optional.

Figure 12 illustrates a sample scenario for configuring IFA nodes on Junos OS devices. In this scenario, different Junos OS devices that support the IFA feature play different IFA roles in a single IFA flow.

Figure 12: Sample Inband Flow Analyzer Scenario Network flow diagram of Inband Flow Analyzer process showing data path between Host A and Host B via Juniper QFX5120 switches with IFA headers.

Following are some of the guidelines for configuring IFA nodes:

  • You can enable the IFA configuration on the interface only through the firewall filter configuration.
  • You can apply IFA filter only on ingress direction on the port.

Table 7 summarizes the configurations for IFA initiator, transit, and terminator nodes.

Table 7: IFA Configurations for IFA Roles

IFA Configuration Parameter

Configuration Statement

 IFA Role

(Mandatory) Configure Device ID

 
user@host# set services inband-flow-telemetry device-id (<1 - 1048575> | auto)
 Mandatory configuration for IFA initiator, transit, and terminator nodes.

(Optional, QFX5120-48YM or QFX5220 only) Configure a more accurate clock source

 
user@host# set services inband-flow-telemetry clock-source (ntp|ptp)
 IFA initiator, transit, and terminator nodes.

(Optional) IFA maximum metadata stack length 

user@host# set services inband-flow-telemetry meta-data-stack-length <8 - 255>

Default value : 240 (for 30 hops)

 IFA initiator node

(Optional) IFA maximum hop limit

 
user@host# set services inband-flow-telemetry hop-limit <1 - 250>

Default value : 250

 IFA initiator node

(Optional) No IPv6 address match

 
user@host# set services inband-flow-telemetry no-ipv6-address-match
 IFA initiator/terminator node

(Mandatory) IFA flow type

 
user@host# set services inband-flow-telemetry flow-type (l3 | vxlan)
 Mandatory configuration for IFA initiator and terminator node. This configuration is not required for IFA transit node.
(Optional) Mode 
user@host# set services inband-flow-telemetry mode (live | probe)

Probe mode is the default. Therefore, you do not need to configure this statement unless you want to configure live mode on a device that supports that feature.

IFA initiator node

IFA sampling

 
user@host# set services inband-flow-telemetry profile ifa-profile-name sample-rate <1-16777215>
 IFA initiator node

Collector information

 
user@host# set services inband-flow-telemetry profile ifa-profile-name collector source-address IP-address
user@host# set services inband-flow-telemetry profile ifa-profile-name collector destination-address IP-address
user@host# set services inband-flow-telemetry profile ifa-profile-name collector destination-port port-number
user@host# set services inband-flow-telemetry profile ifa-profile-name collector maximum-clip-length length
user@host# set services inband-flow-telemetry profile ifa-profile-name collector mtu size
IFA terminator node

IFA filter for L3 flow

For example:

user@host# set firewall family inet filter f1 term t1 from match-condition
user@host# set firewall family inet filter f1 term t1 then inband-flow-telemetry-init p1
user@host# set firewall family inet filter f1 term t2 from match-condition
user@host# set firewall family inet filter f1 term t2 then inband-flow-telemetry-terminate p2
user@host# set interfaces (interface-name | wildcard) unit 0 family inet filter input f1
IFA initiator/terminator node

IFA filter for VXLAN flow

For example:

user@host# set firewall family ethernet-switching filter f1 term term1 from match-condition
user@host# set firewall family ethernet-switching filter f1 term t1 then inband-flow-telemetry-init p1
user@host# set firewall family ethernet-switching filter f1 term t2 from match-condition
user@host# set firewall family ethernet-switching filter f1 term t2 then inband-flow-telemetry-terminate p2
user@host# set interfaces (interface-name | wildcard) unit 0 family ethernet-switching filter input f1
IFA initiator/terminator node

Configure IFA Initiator Node

To configure your device as IFA 2.0 initiator:

  1. Configure the device ID. You can also configure the value auto for device-id. If the device-id is configured as auto, the device-id is internally generated from the router ID or the management IP address.

    In this example, the device id for IFA initiator node is configured as 10000.

  2. Configure the flow type. You can configure either of two flow types, l3 or vxlan. You cannot configure L3 and VXLAN flows together in the same device.

    In this example, the flow type is configured as l3. If you configure l3 flow-type in the initiator node, then you must choose l3 flow-type for the terminator node also.

  3. (Optional) Configure the maximum metadata stack length. Each IFA hop inserts hop-specific metadata into the IFA metadata stack.

    In this example, the metadata stack length is configured as 80.

  4. Configure the hop limit.

    In this example, hop-limit is configured as 10. The hop limit is decremented at each hop. If the incoming hop limit is 0, the current node does not insert metadata.

  5. Configure IFA sampling. The sampling rate is the average number of samples obtained in one second. You cannot have different sample rate for different flows on an IFA initiator node enabled on a port. All flows within a port should have same sample rate.

    In this example, the sample rate is configured as 1000; meaning out of 1000 packets, 1 packet will be sampled per second.

  6. Configure IFA firewall filters to select a flow. You can configure a firewall filter with any of the below match conditions:
    • Source IP address
    • Destination IP address
    • Source port
    • Destination port
    • Protocol

    For the QFX5120 switch, we support only these match conditions. For the QFX5240 switch, we support all match conditions, but we recommend you use the above match conditions to select a flow.

    Create a firewall and configure the action inband-flow-telemetry-init.

    In this example, you configure a firewall filter named f1, with the term name t1 containing the action inband-flow-telemetry-init, and the inband flow telemetry initiator profile p1 mapped to it:

  7. Map the firewall filter to the family under the logical unit of the already-configured interface to apply the action inband-flow-telemetry-init in the ingress direction.

    To map the firewall filter:

    In this example, you map the f1 firewall filter to the inet family of logical interface 0 of the physical interface et-0/0/0:

Configure IFA Transit Node

To configure your device as IFA transit node:

Configure the device ID. You can also configure the value auto for device-id. If the device-id is configured as auto, then the device-id is internally generated from the router ID or the management IP address.

For example:

Configure IFA Terminator Node

To configure your device as IFA terminator node:

  1. Configure the device ID. You can also configure the value auto for device-id. If the device-id is configured as auto, then the device-id is internally generated from the router ID or the management IP address.

    For example:

  2. Configure the flow type. You can configure either of two flow types, l3 or vxlan. You cannot configure L3 and VXLAN flows together in the same device.

    If you configure l3 flow-type in the initiator node, then you must choose l3 flow-type for the terminator node also.

  3. Configure IFA profile with the collector information for the terminator node.

    For example:

  4. You can configure firewall filter with any of the below match conditions:
    • Source IP address
    • Destination IP address
    • Source port
    • Destination port
    • Protocol

    For the QFX5120 switch, we support only these match conditions. For the QFX5240 switch, we support all match conditions, but we recommend you use the above match conditions to select a flow.

    Create a firewall and configure the action inband-flow-telemetry-terminate.

    In this example, you configure a firewall filter named f2, with the term name t1 containing the action inband-flow-telemetry-terminate, and the inband-flow-telemetry-terminate profile p2 mapped to it:

  5. Map the firewall filter to the family under the logical unit of the already-configured interface to apply the inband-flow-telemetry-terminate action in the egress direction.

    To map the firewall filter:

    In this example, you map the f2 firewall filter to the inet family of the logical interface 0 of the physical interface et-0/0/0:

View Inband Flow Analyzer Statistics

You can view the following IFA related information:

  • IFA statistics using the show services inband-flow-telemetry stats operational mode command.
  • IFA global parameters using the show services inband-flow-telemetry global operational mode command.
  • IFA-configured profiles using the show services inband-flow-telemetry profile operational mode command.

You can clear the IFA statistics using clear inband-flow-telemetry stats operational mode command.

IFA statistics are retrieved directly from the PFE and are not maintained in the Routing Engine. Therefore, a PFE-process restart clears the IFA statistics and a Routing-Engine process restart does not impact the IFA statistics.

Example - Configure Inband Flow Analyzer 2.0 for Traffic Monitoring

Use this example to configure the IFA 2.0 nodes on your QFX Series switches that enable analyzing of Layer 3 or VXLAN traffic flows. Figure 13 shows the topology where IFA 2.0 is configured on QFX Series switches that support the IFA 2.0 feature. In this topology, VXLAN traffic is monitored at the initiator and data is collected at the terminator node for analysis.

Figure 13: Topology for Analyzing VXLAN Traffic Flow using IFA 2.0 Network topology diagram showing Juniper QFX5120 switches in spine-leaf architecture with labeled connections.

Requirements

This example uses the following hardware and software components:

  • One QFX5120-32C switch as a spine node
  • Two QFX5120-48Y switches as the leaf nodes
  • Junos OS Release 21.4R1

You can use other QFX Series switches in the initiator, transit, and terminator roles. See Table 6 to see what roles QFX Series switches support in IFA 2.0.

Pre-Requisites

This example assumes that you already have an EVPN-VXLAN based network and want to enable traffic monitoring on QFX switches.

Before you Begin

Overview

In this example, you'll configure one of the QFX5120-48Y switches (Leaf 1) as an initiator node, the QFX5120-32C switch as a transit node, and the second QFX5120-48Y switch (Leaf 2) as a terminator node. The VXLAN traffic flows from Host 1 to Host 2. Configuring IFA on the ingress and egress nodes allows you to monitor network operation and identify the performance issues.

The QFX5120-32C functions as a spine to connect the QFX5120-48Y leaf nodes. At the terminator node, you collect the sampled traffic in IPFIX format using an IPv4 collector application.

Configuration

In this example, you'll configure the following functionality on the switches:

  1. Configure Leaf 1 as an initiator node and configure initiator related attributes, like global device identifier and the sampling rate. Configure an IFA profile and firewall filter with the action as inband-flow-telemetry-init, and bind the IFA firewall filter to the interfaces.
  2. Configure the QFX5120-32C spine switch as a transit node with a global device identifier. When you configure a global device identifier, the spine device adds the IFA metadata and forwards the IFA probe packets.
  3. Configure Leaf 2 as a terminator node. Configure the IFA profile with the collector information and firewall filter with the action as inband-flow-telemetry-terminate, and bind the IFA firewall filter to the interfaces.

CLI Quick Configuration

To quickly configure this example on your QFX series devices, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configuration on QFX5120-48Y Switch (Leaf 1 — IFA Initiator Node)

Note:

Recall that in this example you add IFA to a pre-configured EVPN-VXLAN baseline. The configuration shown here focuses on the delta needed to add IFA to the baseline. We show some of the existing configuration to best show how the IFA delta relates to the baseline.

Configuration on QFX5120-32C Switch (IFA Transit Node)

Configuration on QFX5120-48Y Switch (Leaf 2 — IFA Terminator Node)

Step-by-Step Procedure

Configure QFX5120-48Y Switch (Leaf 1) as an Initiator Node

An IFA initiator node performs the following functions for a flow:

  • Samples the flow traffic of interest based on the configuration.
  • Converts the traffic into an IFA flow by adding an IFA header to each sample.
  • Updates the packet with initiator node metadata.

  1. Configure the IFA initiator node attributes. The traffic flow type is configured as VXLAN for initiator node. Note that you must configure the same flow type for both the initiator and the terminator node, either L3 or VXLAN. As in this example, if the VXLAN traffic flow type is configured for the initiator node, ensure that you configure VXLAN traffic flow type for the terminator node as well.

    When sample-rate is configured with value as 1, every packet that is received in the ingress port is sampled. If you prefer less aggressive sampling, increase the sample-rate value.

  2. Bind the filter to the initiator node ingress interface.

  3. Create a firewall to control IFA sampling. You begin by defining the types of host traffic that should be sampled. In this example you want to perform analysis on UDP and TCP traffic flows. In this example, you configure an firewall filter named f_init, with the term name term1.

    You configure the filter to perform IFA sampling by adding the action modifier inband-flow-telemetry-init to the t1 term. Note that the inband flow telemetry profile ifa_profile_host1 is linked to the filter:

Configure QFX5120-32C Switch as a Transit Node

An IFA transit node inserts transit node metadata in the IFA packets in the specified VXLAN flow.

Configure the global device identifier for the transit node, QFX5120-32C switch.

Configure QFX5120-48Y Switch (Leaf 2) as a Terminator Node

An IFA terminator node performs the following for a flow:

  • Inserts terminator node metadata in IFA packets.
  • Performs a local analytics function on one or more segments of metadata, for example, threshold breach for residence time, congestion notifications, and so on.
  • Filters an IFA flow in case of cloned traffic.
  • Sends a copy or report of the packet to collector.
  • Removes the IFA headers and forwards the packet in case of live traffic.

  1. Configure the terminator node related attributes, like global device identifier and flow type.

    Configure an IFA profile with the collector related information.

  2. Configure the collector interface for terminator node Leaf 2.

    Apply the firewall filter to the pre-configured interface to activate inband flow telemetry egress processing at Leaf 2.

    In this example, you map the f-term firewall filter to the inet family of logical interface 0 of the physical interface xe-0/0/18:

  3. Create a firewall filter and configure the action inband-flow-telemetry-terminate.

    In this example, you configure a firewall filter named f-term, with the term name t1 containing the action inband-flow-telemetry-terminate, with the inband flow telemetry terminate profile p_term mapped to it:

Results

Results on QFX5120-48Y Switch (Leaf 1 — IFA Initiator Node)

From operational mode, confirm your configuration by entering the show configuration services, show configuration interfaces, and show configuration firewall commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Note:

The output shows portions of the pre-existing EVPN-VXLAN baseline to provide the context for the configuration delta needed to add IFA.

When you are done configuring the feature on your device, enter commit from configuration mode.

Results on QFX5120-32C Switch (IFA Transit Node)

From operational mode, confirm your configuration by entering the show configuration services, and show configuration interfaces commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

When you are done configuring the feature on your device, enter commit from configuration mode.

Results on QFX5120-48Y Switch (Leaf 1 — IFA Terminator Node)

From operational mode, confirm your configuration by entering the show configuration services, show configuration interfaces, and show configuration firewall commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

When you are done configuring the feature on your device, enter commit from configuration mode.

Verification

Verification on QFX5120-48Y Switch (Leaf 1 — IFA Initiator Node)

Verify IFA Statistics

Purpose

Display the IFA statistics on the initiator node.

Action

From operational mode, enter the show services inband-flow-telemetry stats command.

Verify IFA Global Configuration

Purpose

Display the IFA global parameters configured on the initiator node.

Action

From operational mode, enter the show services inband-flow-telemetry global command.

Verify IFA Profile

Purpose

Display the IFA profile configured on the initiator node.

Action

From operational mode, enter the show services inband-flow-telemetry profile command.

Verification on QFX5120-32C Switch (IFA Transit Node)

Verify IFA Statistics

Purpose

Display the IFA statistics on the transit node.

Action

From operational mode, enter the show services inband-flow-telemetry stats command.

Verify IFA Global Configuration

Purpose

Display the IFA global parameters configured on the transit node.

Action

From operational mode, enter the show services inband-flow-telemetry global command.

Verification on QFX5120-48Y Switch (Leaf 2 — IFA Terminator Node)

Verify IFA Statistics

Purpose

Display the IFA statistics on the terminator node.

Action

From operational mode, enter the show services inband-flow-telemetry stats command.

Verify IFA Global Configuration

Purpose

Display the IFA global parameters configured on the terminator node.

Action

From operational mode, enter the show services inband-flow-telemetry global command.

Verify IFA Profile

Purpose

Display the IFA profile configured on the terminator node.

Action

From operational mode, enter the show services inband-flow-telemetry profile command.

See Also

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
25.4R1-EVO
We've added support for configuring live mode to Junos OS Evolved, to the QFX5240 switch.
24.4R1-EVO
We've extended support for the initiator and terminator roles to Junos OS Evolved.
22.4R1-EVO
We've extended support for the IFA 2.0 transit node role to Junos OS Evolved.
22.2R1
We've added support for configuring the MTU and maximum clip length for IFA packets, and for the QFX5120-48YM switch, setting the IFA clock source.
21.4R1
We've introduced support for IFA 2.0 on QFX Series switches. IFA 2.0 monitors and analyzes packets when they enter and exit the network. You can use IFA 2.0 to monitor the network for faults and performance bottlenecks. IFA 2.0 supports both Layer 3 and VXLAN flows.