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 Probe for 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 uses probe packets to collect network-wide flow data. IFA samples the flow of interest and generates probe packets. These packets are representative of the original flow, possessing the same characteristics as the original flow. This means that IFA packets traverse the same path in the network and the same queues in the networking element as the original 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.

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 terminating 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 terminating 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 ProcessingIFA Processing

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.
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 terminating node
  • Inserts terminating 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.
Note:

IFA terminating functionality requires a valid Juniper Advanced Telemetry Feature (ATF) license.

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 NodeLayer 3 IFA 2.0 Packet Format at the IFA Initiator Node

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 NodeVXLAN IFA 2.0 Packet Format at the IFA Initiator Node
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 HeaderIFA Header
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 FormatIFA Metadata Header Format
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 terminating 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).

Figure 6: IFA Metadata Stack HeaderIFA Metadata Stack Header
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 auto statement. If you configure 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.

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.
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, 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 FormatIngress (Rx) Tailstamp Format
Figure 8: Egress (Tx) Tailstamp FormatEgress (Tx) Tailstamp Format

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, and 100 Gbps.
IFA transit Identifies IFA packets, appends their metadata, and forwards it.
IFA terminating
  • Support to export IFA data to any configured IPv4 collector in IPFIX format.
  • Support to combine multiple IFA packets into a single IPFIX export.

Supported IFA 2.0 IPFIX Format (Terminating Node)

The terminating 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 terminating node formats the IFA 2.0 data and sends it to a collector.

Figure 9: IFA 2.0 IPFIX TemplateIFA 2.0 IPFIX Template

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

Figure 10: VXLAN IFA 2.0 IPFIX Sample Packet

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 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 terminating nodes (generally leaf nodes). For IFA transit nodes (generally spine nodes), it is not required to configure the flow type.
    • For VXLAN IFA flow, the egress port-related metadata for the terminating node (including egress port number, speed, queue ID, and congestion) are incorrect. It is recommended that you ignore the termination node egress-port-related metadata for VXLAN flows.
    • 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 probe 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).
    • You cannot configure different sample rates for different flows on a port for an IFA initiator. All flows within a port should have the same sample rate.

  • 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 cannot perform the hop-limit check to insert the tailstamp. The QFX5220 also cannot insert metadata into the metadata stack in the IFA probe packet header; instead, the QFX 5220 appends a tailstamp to the end of the IFA probe packet.

    QFX5220 supports only 18 bits for the Rx Seconds Timestamp value. The QFX5130 and QFX5700 support a 20-bit Rx Seconds Timestamp value.

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

  • IFA Terminating Node

    • You can configure only a single IPv4 collector at the terminating node.
    • The terminating node metadata has the queue ID 47. This queue ID is reserved for IFA packet export.
    • The terminating node does not perform a hop-limit check. Even if the incoming IFA packet has hop-limit set to 0, the terminating 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. IFA 2.0 doesn't support any other match qualifiers.
  • 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 terminating 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.
  • The terminating node accepts an IFA packet size up to 9000 bytes (including IFA headers). On the terminating 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).
  • 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 device that supports IFA feature. The following QFX switches support the IFA 2.0 feature:

  • QFX5120-32C, QFX5120-48Y, QFX5120-48T, and QFX5120-48YM, running Junos OS

  • QFX5130-32CD, running Junos OS Evolved (transit node role only)

  • QFX5220-32CD and QFX5220-128C, running Junos OS Evolved (transit node role only)

  • QFX5700, running Junos OS Evolved (transit node role only)

See the release history table at the end of this topic for information on when devices were first supported in Junos OS.

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, terminating) 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 11 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 11: Sample Inband Flow Analyzer Scenario

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 6 summarizes the configurations for IFA initiator, transit, and terminating nodes.

Table 6: 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 terminating 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 terminating 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/terminating node
(Mandatory) IFA flow type 
user@host# set services inband-flow-telemetry flow-type (l3 | vxlan)
 Mandatory configuration for IFA initiator and terminating node. This configuration is not required for IFA transit 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 terminating 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/terminating 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/terminating 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 terminating 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. You can configure firewall filter with any of the below match conditions:
    • Source IP address
    • Destination IP address
    • Source port
    • Destination port
    • Protocol

    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 Terminating Node

To configure your device as IFA terminating 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 terminating node also.

  3. Configure IFA profile with the collector information for the terminating 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

    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 12 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 terminating node for analysis.

Figure 12: Topology for Analyzing VXLAN Traffic Flow using IFA 2.0Topology for Analyzing VXLAN Traffic Flow using IFA 2.0

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

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 terminating 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 terminating 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 terminating 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 Terminating 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 terminating 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 terminating 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 Terminating Node

An IFA terminating node performs the following for a flow:

  • Inserts terminating 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 terminating 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 terminating 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 Terminating 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.

[edit]

user@host> show configuration interfaces

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 Terminating Node)

Verify IFA Statistics

Purpose

Display the IFA statistics on the terminating 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 terminating 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 terminating 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
22.4R1-EVO
Inband Flow Analyzer (IFA) 2.0 transit node support (QFX Series switches)—In Junos OS Evolved 22.4R1, we've extended support for the IFA 2.0 transit node role to the QFX5130-32CD, QFX5220-32CD, QFX5220-128C, and QFX5700 switches.
22.2R1
Inband Flow Analyzer (IFA) 2.0 (QFX Series switches)—In Junos OS Release 22.2R1, we've extended support for IFA 2.0 to the QFX5120-48YM and QFX5120-48T switches. We've also 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
Inband Flow Analyzer (IFA) 2.0 (QFX5120-48Y and QFX5120-32C)—In Junos OS Release 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.