Inline Monitoring Services Configuration

Benefits of Inline Monitoring Services

Flexible—Inline monitoring services allow different inline-monitoring instances to be mapped to different firewall filter terms, unlike in traditional sampling technologies, where all the instances are mapped to the Flexible PIC Concentrator (FPC). This provides you with the flexibility of sampling different streams of traffic at different rates on a single interface.

Packet format agnostic—Traditional flow collection technologies rely on packet parsing and aggregation by the network element. With inline monitoring services, the packet header is exported to the collector for further processing, but without aggregation. Thereby, you have the benefit of using arbitrary packet fields to process the monitored packets at the collector.

Inline Monitoring Services Feature Overview

Service providers and content providers typically require visibility into traffic flows to evaluate peering agreements, detect traffic anomalies and policy violations, and monitor network performance. To meet these requirements, you would traditionally export aggregate flow statistics information using inline active flow monitoring or IPFIX variants.

As an alternative approach, you can sample the packet content, add metadata information, and export the monitored packets to an collector. The inline monitoring services enable you to do this on MX Series routers and on PTX routers that run Junos OS Evolved.

With inline monitoring services, you can monitor every IPv4 and IPv6 packet on both ingress and egress directions of an interface. Starting in Junos OS Release 26.2R1 for the MX304 router, you can choose either IPFIX or sFlow version 5 (RFC 3176) export format. IPFIX is the default export format. The IPFIX export format supports all traffic families. The sFlow version 5 export format supports only family inet and family inet6.

An inline monitoring services instance can support either the IPFIX export version or the sFlow version 5 export version. One inline monitoring services instance cannot support both versions. We also do not recommend that you toggle between export formats on one instance. You should configure a different instance for each export format.

You configure templates only for the IPFIX export format. You cannot configure a template when the sflow-v5 export format statement is configured for the inline monitoring services instance.

For more information about the sFlow standard, see RFC3176. For more information about the sFlow version 5 format, see sFlow Version 5.

Inline Monitoring Services IPFIX Export Format Overview

With inline monitoring services, you can monitor every IPv4 and IPv6 packet on both ingress and egress directions of an interface. The software encapsulates the monitored traffic in an IPFIX format and exports the actual packet up to the configured clip length to an collector for further processing. By default, Junos OS supports a maximum clip length of 126 bytes starting from the Ethernet header and Junos OS Evolved supports a maximum clip length of 256 bytes starting from the Ethernet header.

Figure 1 illustrates the IPFIX format specification.

Figure 1: Inline Monitoring IPFIX Specification

The IPFIX header and IPFIX payload are encapsulated using the IP or UDP transport layer. The exported IPFIX format includes two data records and two data templates that are exported to every collector:

• Data record—Includes incoming and outgoing interface, flow direction, data link frame section, and data link frame size. This information is sent to the collector only when sampled packets are being exported.

  Figure 2 is a sample illustration of IPFIX data record packet.

• Option data record—Includes system level information, such as exporting process ID, and sampling interval. This information is sent to the collector periodically, irrespective of whether sampling packets are being exported are not.

  Figure 3 is a sample illustration of IPFIX option data record packet.

  Table 1: Information Element fields in IPFIX Option Data Packet

  Number	Information Element ID	Information Element Length	Details
  1	144	4B	Observation domain ID - An unique identifier of exporting process per IPFIX device. Purpose of this field is to limit the scope of other information element fields.
  2	34	4B	Sampling interval at which the packets are sampled. 1000 indicates that one of 1000 packets is sampled.

• Data template—Includes five information elements:

  • Ingress interface

  • Egress interface

  • Flow direction

  • Data link frame size

  • Variable data link frame selection

  Figure 4 is a sample illustration of IPFIX data template packet.

• Option data template—Includes flow exporter and sampling interval information.

  Figure 5 is a sample illustration of IPFIX option data template packet.

When there is a new or changed inline monitoring services configuration, periodic export of data template and option data template is immediately sent to the respective collectors.

Figure 2: IPFIX Data Record

Figure 3: IPFIX Option Data Record

Figure 4: IPFIX Data Template

Figure 5: IPFIX Option Data Template

Inline Monitoring Services sFlow Version 5 Export Format Overview

With inline monitoring services (IMON), you can monitor every IPv4 and IPv6 packet on both ingress and egress directions of an interface. The software encapsulates the monitored traffic in an sFlow version 5 format and exports the actual packet up to the configured clip length to an IPv4-addressable collector for further processing. By default, Junos OS supports a maximum clip length of 126 bytes, starting from the Ethernet header.

For this export format, you can have up to 4 collectors under each IMON instance. Because the export format is configured at the instance level and not at the collector level, the export format applies to all collectors under that instance. You can sample traffic on only one logical interface per physical interface. All traffic under that logical interface is sampled. You can export the sFlow datagram through a non-default VRF.

The sFlow version 5 header and payload are encapsulated using the IP or UDP transport layer. This sFlow version 5 datagram includes:

• IPv4 datagram header

• UDP datagram header

• Sample datagram header for version 5

• Flow sample header

• Raw packet header

The IPv4 datagram header contains the following fields:

The UDP datagram contains the following fields:

You can view the information in these datagrams at the collector, see Figure 6 for a sample capture.

Figure 6: Sample sFlow version 5 IP/UDP Datagram

Fields in the sample_datagram_v5 header of the exported datagram are shown in Table 4. This header is labeled InMon sFlow in the sample capture shown in Figure 9.

Figure 7: Sub-agent ID Format

The fields of the Flow Sample header of the exported datagram are shown in Table 5. This header is labeled Flow Sample in the sample capture shown in Figure 9.

Figure 8: Source ID Format

The fields of the sampled_header header of the exported datagram are shown in Table 7. This header is labeled Raw Packet Header in the sample capture shown in Figure 9.

You can view the information in these headers at the collector, see Figure 9 for a sample.

Figure 9: Sample Capture of sFlow Datagram

Inline Monitoring Services Configuration Overview

You can configure a maximum of sixteen (Junos OS) or seven (Junos OS Evolved) inline-monitoring instances that support template and collector-specific configuration parameters. Each inline monitoring instance supports up to four collectors (maximum of 64 collectors in total), and, for Junos OS and IPFIX export format only, you can specify different sampling rates under each collector configuration. Because of this flexibility, the inline monitoring services overcome the limitations of traditional sampling technologies, such as inline active flow monitoring, sFlow, and port mirroring.

To configure inline monitoring:

1. You must include the inline-monitoring statement at the [edit services] hierarchy level. Here you specify the template and inline monitoring instance parameters. You must specify the collector parameters under the inline-monitoring instance.

2. Specify arbitrary match conditions using a firewall filter term and an action to accept the configured inline-monitoring instance. This maps the inline-monitoring instance to the firewall term.

3. Map the firewall filter under the family inet or inet6 statement using the inline-monitoring-instance statement at the [edit firewall filter name then] hierarchy level. Starting in Junos OS Release 21.1R1 and for the IPFIX export format, you can also map the firewall filter under the family any, bridge, ccc, mpls, or vpls statements. For Junos OS Evolved, the bridge and vplsfamilies are not supported; use the ethernet-switch family instead. Junos OS Evolved does support the any, ccc, inet, inet6, and mpls families as well. You can also alternatively apply the firewall filter to a forwarding table filter with input or output statement to filter ingress or egress packets, respectively.

Remember:

• The device must support a maximum packet length (clip length) of 126 bytes (Junos OS) or 256 bytes (Junos OS Evolved) to enable inline monitoring services.

• You cannot configure more than 16 (Junos OS) or 7 (Junos OS Evolved) inline-monitoring instances because of the scarcity of bits available in the packet in the forwarding path.

• Apply inline monitoring services only on a collector interface, that is, the interface on which the collector is reachable. You must not apply inline monitoring on IPFIX traffic as this generates another IPFIX packet for sampling, thereby creating a loop. This includes inline monitoring service-generated traffic, such as template and record packets, option templates, and option record packets for the IPFIX export format and datagrams for the sFlow version 5 export format.

• When inline monitoring services are enabled on aggregated Ethernet (AE) interfaces, the information element values for the IPFIX export format are as follows:

  Table 8: Information Element Values for Aggregated Ethernet Interfaces

  Direction of inline monitoring service on AE interface	Information element-10 (Incoming interface)	Information element-14 (Outgoing interface)
  Ingress	SNMP ID of AE	0
  Egress	SNMP ID of AE	SNMP ID of member link

• When inline monitoring services are enabled on IRB interfaces, the information element values for the IPFIX export format are as follows:

  Table 9: Information Element Values for IRB Interfaces

  Direction of inline monitoring service on IRB interface	Information element-10 (Incoming interface)	Information element-14 (Outgoing interface)
  Ingress	SNMP ID of IRB	0
  Egress	SNMP ID of IRB	SNMP ID of vlan-bridge encapsulated interface

• (IPFIX export format only) For XL-XM based devices (with Lookup chip (XL) and buffering ASIC (XM)), the length of the Data Link Frame Section information element in an exported packet can be shorter than the clip length even if the egress packet length is greater than clip length.

  The length of the Data Link Frame Section information element is reduced by 'N' number of bytes where 'N' = (ingress packet Layer 2 encapsulation length - egress packet Layer 2 encapsulation length).

  For instance, the Layer 2 encapsulation length for the ingress packet is greater than that of the egress packet when the ingress packet has MPLS labels and egress packet is of IPv4 or IPv6 type. When traffic flows from the provider edge (PE) device to the customer edge (CE) device, the ingress packet has VLAN tags and the egress packet is untagged.

  In such cases, the clip length can go past the last address location of the packet head, generating a PKT_HEAD_SIZE system log message. This can result in degradation of packet forwarding for the device.

• In the ingress direction, the IPFIX egressInterface (information element ID 14) or the sFlow flow_sample.output_interface field does not report the SNMP index of the output interface. These fields always report the value zero in case of ingress direction. For the IPFIX export format, the receiving collector process should identify the validity of this field based on the flowDirection (information element ID 61).

• (sFlow export format only) Some forwarding scenarios may overwrite the ingress logical or physical interface information during the lifetime of the packet. For these cases, reporting the actual media WAN port (ge-/xe-/et-/ae-) is not possible. For example:

  1. On a MPLS tunnel tail end, when an MPLS packet is received, the target VRF is identified using the VPN label and the packet switches from the default VRF to the customer VRF using the LSI interface associated to the customer VRF. Therefore, the LSI interface index overwrites the ingress logical or physical interface index in the data path. Inline monitoring services always reports the latest interface information, which is the LSI interface in this case.

  2. Packets traveling through dynamic tunnels report the FTI interface instead of the ingress interface.

• (sFlow export format only) In the egress direction, if a packet is trapped or dropped before the packet goes through the Ethernet encapsulation nexthop, the sampled_header.sampled_pkt datagram field reports without the Ethernet header and the sampled_header.protocol datagram field reports the value 1 (Ethernet).

• (sFlow export format only) You cannot export the sFlow datagram through the management interface. The collector must be reachable through a WAN port.

Supported and Unsupported Features with Inline Monitoring Services

Inline monitoring services supports:

• Graceful Routing Engine switchover

• In-service software upgrade (ISSU), nonstop software upgrade (NSSU), and nonstop active routing (NSR)

• Ethernet interfaces and integrated routing and bridging (IRB) interfaces

• Junos node slicing

• Starting in Junos OS Evolved Release 22.4R1, configuring DSCP, forwarding class, or routing instances for collectors.

• Starting in Junos OS Evolved Release 22.4R1, configuring template IDs or option template IDs.

Inline monitoring services currently does not support:

• Configuring more than 16 (Junos OS) or 7 (Junos OS Evolved) inline-monitoring instances.

• Junos Traffic Vision

• Prior to Junos OS Release 21.1R1, the inline-monitoring-instance term action is supported only for inet and inet6 family firewall filters. Starting in Junos OS Release 21.1R1 and for the IPFIX export format only, it is supported for the any, bridge, ccc, mpls, and vpls family firewall filters.

• IPv6 addressable collectors

• Virtual platforms

• Logical systems

• (IPFIX export format only) Configuring both the observation domain ID and observation cloud ID. You must choose only one of them.

• An inline monitoring instance action used for exception reporting cannot be used for any other purpose, such as a firewall re-direct action or a regular inline-monitoring action.

• An inline monitoring instance used for a firewall re-direct action cannot be used for any other purpose, such as exception reporting or a regular inline-monitoring action.

• Prior to Junos OS Evolved Release 22.4R1, configuring DSCP, forwarding class, or routing instances for collectors.

• Prior to Junos OS Evolved Release 22.4R1, configuring template IDs or option template IDs. The system generates these for you.

• (Junos OS Evolved) Configuring port mirroring and inline monitoring services under the same firewall filter term .

• (Junos OS Evolved) In the egress direction, configuring both sFlow and exception reporting; you must choose only one of them.