In-situ Flow Information Telemetry (iFIT) determines network performance by measuring the packet loss and packet delay of service packets transmitted on a public network or an MPLS, SR-MPLS, SRv6, G-SRv6, or G-BIER transit network. iFIT is easy to deploy and provides an accurate assessment of network performance.

iFIT can be used for the following purposes:

· iFIT application-level measurement—Measures the metrics such as the packet loss rate and delay when service traffic passes through the transmission network. The measurement result can be used to assess the network transmission quality for the service traffic.

· iFIT tunnel-level measurement—Measures the metrics such as the packet loss rate and delay when packets pass through SRv6 tunnels. The measurement results can be used for intelligent route selection of the SRv6 TE policy module.

iFIT technical standards

iFIT complies with technical standards of CMCC, China Telecom, and China Unicom. These sets of technical standards have typical differences in encapsulation requirements for iFIT headers in IPv6 packets. Choose one set of standards as needed.

Devices included in iFIT measurement on the same SRv6 link must be configured with the same technical standards. If you fail to do so, iFIT packet parsing might fail, leading to inaccurate iFIT measurement results.

Basic concepts

Instance

iFIT implements independent measurement and statistics of different target flow packet loss and delay parameters through instances.

An instance is a logical concept and the smallest configuration unit of iFIT. Users must create an instance on the ingress node, where they can specify parameters such as target flow and measurement period. When you bind an instance to the incoming interface or the device of a target flow, the performance parameters of the target flow received on the specified interface can be measured and statistically analyzed.

An instance is bound to a target flow. By configuring multiple instances and binding them to different target flows, you can simultaneously measure and gather performance parameters of various target flows.

Measurement period

After the measurement function in the iFIT instance is activated on the device, iFIT will continuously measure the performance parameters of the target flow bound to this instance. To facilitate users to understand the performance parameters of the target flow at any time, iFIT measures the performance parameters of the target flow in fixed durations (configurable via the CLI) as periods. The ingress node, transit nodes, and egress node calculate the total number of target packets received or transmitted during each period, and the analyzer calculates the packet loss parameters for each period. The ingress node, transit nodes, and egress node record the timestamp of the first packet received or transmitted in each period, and the analyzer calculates the delay parameters for each period.

Coloring bit

The coloring bit, also known as the mark bit, can periodically identify a target flow, achieving the purpose of periodically sampling and collecting statistics on the target flow.

iFIT uses two coloring bits: one for loss measurement to calculate packet loss parameters, and the other for delay measurement to calculate delay parameters.

iFIT application-level measurement

Application scenarios

End-to-end measurement

To measure the packet loss and packet delay on the entire network, use end-to-end measurement. As shown in Figure 1, iFIT measures whether packet loss or packet delay occurs between the ingress node (where the target flow enters the IP network) and the egress node (where the flow leaves the network).

Figure 1 End-to-end measurement

‌

Hop-by-hop measurement

To accurately locate the packet loss and packet delay of each network node, use hop-by-hop measurement. To locate the faulty node, you can divide an end-to-end network into smaller measurement spans. As shown in Figure 2, iFIT measures whether the packet loss and packet delay occurs between the ingress node and egress node, ingress node and transit node, transit node and egress node.

Figure 2 Hop-by-hop measurement

‌

NOTE:

When the egress device on a network does not support iFIT, end-to-end measurement is not supported, but hop-by-hop measurement is. You configure iFIT on the ingress device and other devices that support iFIT to measure performance of a specific link.

‌

iFIT architecture

Figure 1 and Figure 2 show the important iFIT concepts including transit network, target flow, detection point, and measurement system.

Transit network

A transit network is a network that transmits target flows. A service flow are neither generated nor terminated within the transit network. In the current software version, iFIT supports measuring only service flows on Layer 3 transit networks.

To measure the transmission quality of a target flow in a transit network, iFIT adds an iFIT header to the target flow. The encapsulation format of an iFIT header varies by transit network type, which can the one of the following:

· Tunnel—Corresponds to the transit network types such as MPLS, SR-MPLS, SRv6, G-SRv6, and G-BIER. On a Tunnel network, the ingress node itself must encapsulate service packets with MPLS, SRv6, and so on. To implement iFIT measurement, the ingress node adds extension fields to carry iFIT measurement data during the encapsulation of service packets with MPLS, SRv6, and so on. This is used for subsequent recognition and processing on forwarding nodes.

· Native-IP—Corresponds to the transit network type of the public network. On a Native-IP network, the ingress node keeps the original service packets unchanged and encapsulates an SRv6 BE header on top of the original service packets to carry iFIT measurement data. This is used for subsequent recognition and processing on forwarding nodes.

Target flow

iFIT provides statistics on a per-flow basis. The target flows can be divided into the following types:

· Static flow—A static flow is used to map and manage dynamic flows. A service flow acts as a configuration template. The ingress node generates a static flow after you enable iFIT measurement and execute the flow command to configure the flow match criteria on the ingress node.

The ingress node uses a device ID and a flow ID to uniquely identify the static flow. The device ID is configured by the device-id command and the flow ID is a number randomly generated on the ingress node in the range of 1 to 1048575.

To view the device ID, flow ID, transit network type, and other settings of a static flow on the ingress node, execute the display ifit flow static command.

· Dynamic flow—A dynamic flow is a service flow dynamically learnt by the device. Dynamic flows are generated as follows:

¡ For the ingress node, if the device receives a service flow that matches the flow match criteria of a static flow, a dynamic flow with the same device ID and flow ID as the static flow is generated. The ingress node also encapsulates the device ID and the flow ID in the iFIT headers of service packets before sending the service packets to a transit node and the egress node.

¡ For a transit node and the egress node, they parse the received service packets and generate dynamic flows by dynamically learning from the iFIT headers of the service packets.

The device uses the device ID and flow ID in the iFIT header to identify the flow. If the device does not receive the packets using the same device ID and the same flow ID for a period of time, the device will delete the dynamic flow entry.

Detection point

A detection point is an interface where iFIT measurement is performed. You can specify detection points as required.

Measurement system

The measurement system includes the following device roles:

· The ingress node refers to the point that the flow enters the transit network. It filters the target flow, adds iFIT headers to the packets of the flow, collects packet statistics and reports packet statistics to the analyzer.

· A transit node resides between the egress node and the ingress node. This type of point identifies the target flow by the iFIT header and reports the measurement statistics to the analyzer according to the measurement mode in the iFIT header.

On an SRv6 network, the source and endpoint nodes of an SRv6 tunnel act as the ingress and egress nodes for iFIT measurement, respectively, with the nodes in between named as transit nodes. Transit nodes are divided into two types: Those in the SID list and those not in the SID list. By default, only transit nodes in the SID list can perform iFIT measurement. Those not in the SID list are not included in SRv6 processing and can only perform regular IPv6 packet forwarding, which even with iFIT measurement enabled, do not parse iFIT headers for iFIT measurement. To configure transit nodes not in the SID list to perform iFIT measurement, configure the settings depending on the network as follows:

¡ On an SRv6 TE policy or SRv6 BE network of CMCC, perform the following operations:

- Specify CMCC technical standards for iFIT.

- Specify hop-by-hop measurement for iFIT.

- Execute the ifit enable and trace-measure per-hop commands on the transit node.

¡ On an SRv6 BE network of China Telecom or Unicom, perform the following operations:

- Specify China Telecom or Unicom technical standards for iFIT, respectively.

- Specify hop-by-hop measurement for iFIT.

- Execute the ifit enable and trace-measure per-hop commands on the transit node.

¡ On an SRv6 TE policy network of China Telecom or Unicom, transit nodes that use China Telecom or Unicom technical standards do not support iFIT measurement based on the requirements of these technical standards.

· The egress node identifies the target flow by the iFIT header, reports the measurement statistics to the analyzer, and removes the iFIT header from the packet.

· The analyzer collects the statistics reported by the ingress node, transit nodes, and egress node for data summarization and calculation.

iFIT header

An iFIT header is encapsulated in service packets and contains key parameters such as device ID, flow ID, measurement period, measurement mode, whether to measure delay, and whether to measure packet loss.

· Device ID: A device ID uniquely identifies a device included in iFIT measurement and a device ID and a flow ID uniquely identify an iFIT flow.

· Flow ID: A flow ID is automatically generated on the ingress node. It will be encapsulated in the iFIT headers and sent to a transit node and the egress node to uniquely identify a target flow along with the device ID on an iFIT network.

· Measurement period: The device performs iFIT measurement periodically. A measurement period refers to the time interval from the start of a measurement to the collection and reporting of the measurement data.

· Measurement mode: Indicates end-to-end measurement or hop-by-hop measurement.

Time synchronization mechanism

Before starting the iFIT measurement, make sure all devices are time synchronized. Therefore, all iFIT-enabled devices can use the same measurement period to report the packet statistics to the analyzer. As a best practice, the analyzer and all iFIT-enabled devices are time synchronized to facilitate management and maintenance.

Both PTP and NTP can be used to synchronize time between devices. Time synchronization is accurate to sub-microseconds through PTP and to milliseconds through NTP.

· As a best practice, use PTP for time synchronization in an iFIT measurement network to ensure higher accuracy.

· If the devices do not support PTP, but support high-precision NTP, enable high-precision NTP on the local and remote devices.

· If the device does not support PTP or high-precision NTP for time synchronization, use the standard NTP. When the standard NTP is deployed, the device supports iFIT packet loss measurement but cannot perform delay measurement accurately. The delay is related with the physical link distance and network status. The transmission delay on some links might be less than one millisecond. Using NTP for time synchronization can affect the accuracy of iFIT delay measurement.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

Operating mechanism

Packet loss measurement mechanism

The number of incoming packets and that of outgoing packets on a network should be equal within a measurement period. If they are not equal, packet loss occurs in the transit network.

Packet delay measurement mechanism

When packets of the target flow pass through multiple detection points, each point will record the timestamp when the first packet passes through the point in each period and report the recorded timestamp to the analyzer. Then, the analyzer can use the timestamp values reported by different detection points to calculate the packet delay.

Measurement data reporting mechanism

iFIT-enabled devices push the measurement data to the analyzer by using the gRPC protocol.

Currently, only gRPC dial-out mode is supported. In this mode, iFIT-enabled devices act as gRPC clients and the analyzer acts as a gRPC server (also called a gRPC collector in the gRPC protocol).

An iFIT-enabled device can send the iFIT data to the analyzer at either of the following intervals:

· gRPC subscription interval—If you set a gRPC subscription interval when configuring gRPC subscription, the device sends the iFIT data to the analyzer at the gRPC subscription interval after establishing a gRPC connection to the analyzer, regardless of whether the sampling path is a periodic sampling path or an event-trigger sampling path.

· iFIT measurement interval—If you do not set a gRPC subscription interval when configuring gRPC subscription and the sampling path is a periodic sampling path, the device cannot send the iFIT data to the analyzer. If you do not set a gRPC subscription interval when configuring gRPC subscription and the sampling path is an event-trigger sampling path, the device sends the iFIT data to the analyzer at the iFIT measurement interval after establishing a gRPC connection to the analyzer.

NOTE:

· The iFIT periodic sampling path is ifit/flowstatistics/flowstatistic.

· The iFIT event-trigger sampling paths are insuitoam/measurereport (containing iFIT measurement result) and insuitoam/flowinfo (containing iFIT flow information).

For more information about gRPC, see gRPC configuration in Telemetry Configuration Guide. For more information about iFIT sampling paths, see the NETCONF API documentation of iFIT.

Working mechanism

The following illustrates the working mechanism of hop-by-hop measurement. No transit nodes exist in end-to-end measurement but end-to-end measurement works similarly as hop-by-hop measurement.

As shown in Figure 3, the flow passes through four devices. Three devices are enabled with iFIT. The iFIT measurement works as follows:

1. The analyzer synchronizes the time with all iFIT-enabled devices through PTP or NTP. As a best practice, use PTP.

2. The iFIT-enabled devices takes the following actions:

a. The ingress node parses the packets to identify the target flow. It encapsulates iFIT headers to the packets, counts the number of packets, and reports the packet quantity and timestamp to the analyzer through gRPC periodically.

The ingress node is the interface bound to the target flow.

b. A transit node counts the number of packets containing iFIT headers and reports the packet quantity and timestamp to the analyzer through gRPC periodically.

When the target flow passes through an iFIT-enabled device, the interfaces where the target flow enters the iFIT-enabled device and leaves the iFIT-enabled device are transit nodes.

c. The egress node parses the packets to identify the target flow. It counts the number of packets containing iFIT headers, reports the packet quantity and timestamp to the analyzer through gRPC periodically, removes iFIT headers from the packets and forwards the packets.

When the target flow leaves the transit network, the interface where the target flow leaves the iFIT-enabled device is the egress point.

3. The analyzer calculates the packet delay for the target flow of the same period and same instance.

Figure 3 Network diagram

‌

iFIT measurement in an SRv6 HoVPN scenario

As shown in Figure 4, in an SRv6 HoVPN scenario, there's an SRv6 network between the UPE and the MPE and another between the MPE and the SPE. On such a network, by default, iFIT can separately measure the performance of two SRv6 tunnels as follows:

· Specify the UPE as the ingress node and the MPE as the egress node on the SRv6 network 1 to measure the performance of the first SRv6 tunnel.

· Specify the MPE as the ingress node and the SPE as the egress node on the SRv6 network 2 to measure the performance of the second SRv6 tunnel. When a packet passes through the MPE, the original iFIT header is removed and a new iFIT header is added based on the egress interface that belongs to another SRv6 network.

To measure the performance of the entire UPE-to-SPE link, specify the UPE as the ingress node and the MPE as a transit node. In addition, enable iFIT header inheriting on the MPE. Then, if the MPE receives a packet from the UPE and the next hop for the packet is the specified SPE, the MPE inherits the iFIT header into the SRv6 packet sent to the SPE. This preserves the previous iFIT header information during traffic transmission on a hierarchical network, enabling measurement of the entire PE hierarchical link's performance.

Figure 4 iFIT measurement in an SRv6 HoVPN scenario

iFIT tunnel-level measurement

iFIT tunnel-level measurement is used to measure the end-to-end quality of the SRv6 tunnel of the SRv6 TE policy. The measurement result can be used for intelligent route selection of the SRv6 TE policy module.

Application scenarios

iFIT supports end-to-end measurement and hop-by-hop measurement for different application scenarios,

· End-to-end measurement

When the egress node in an SRv6 tunnel supports iFIT measurement, use end-to-end measurement. Figure 5 shows a typical application scenario for iFIT tunnel-level measurement:

a. After iFIT is enabled on the ingress node and egress node of an SRv6 TE policy, the ingress node and egress node will measure the transmitted packet count, latency, and jitter of the SRv6 tunnel periodically based on the iFIT operating mechanism.

b. The ingress node collects and calculates the packet loss rate, latency, and jitter for each SRv6 TE policy and provides the measurement results to the SRv6 TE policy module on the same node.

c. The SRv6 TE policy module on the ingress node will select the optimal forwarding path for the service traffic intelligently based on the iFIT measurement results.

Figure 5 iFIT support for SRv6 TE policy intelligent route selection

‌

· Hop-by-hop measurement

When the egress node in an SRv6 tunnel does not support iFIT measurement, use hop-by-hop measurement. Deploy iFIT measurement on the node closest to the egress node of an SRv6 tunnel in the SID list that supports iFIT. Then, iFIT identify this node as "the egress node" of an SRv6 link such as Device E, Device B, and Device F as shown in Figure 6, iFIT will use the measurement results from the ingress node to the egress node as the overall iFIT measurement results for the entire SRv6 link, which will be used for intelligent route selection in the SRv6 TE policy.

If multiple nodes in an SRv6 link are enabled with iFIT measurement, such as Device B and Device C, as shown in Figure 5. iFIT will calculate the overall iFIT measurement results for the entire SRv6 link based on the node closest to the egress node of the SRv6 tunnel (Device C).

a. Enable iFIT on the ingress node and "the egress node" in an SRv6 TE policy.

b. The ingress node and "the egress node" will measure the transmitted packet count, latency, and jitter of the SRv6 tunnel periodically based on the iFIT operating mechanism.

c. The ingress node collects and calculates the packet loss rate, latency, and jitter for each SRv6 TE policy and provides the measurement results to the SRv6 TE policy module on the same node.

d. The SRv6 TE policy module on the ingress node will select the optimal forwarding path for the service traffic intelligently based on the iFIT measurement results.

Figure 6 ‌iFIT support for SRv6 TE policy intelligent route selection (hop-by-hop measurement)

For more information about the SRv6 TE policies and BFD for the SRv6 TE policies, see SRv6 TE policies configuration in Segment Routing Configuration Guide.

iFIT architecture

In iFIT application-level measurement, iFIT reports measurement results to a collector via Telemetry, which then performs aggregation and calculations. For intelligent router selection of the SRv6 TE policy module, iFIT reports measurement results from both the ingress and egress nodes of the SRv6 TE policies to the ingress node, where the results are aggregated and calculated. The iFIT tunnel-level measurement architecture mainly includes three components: target flow, Collector, and Analyzer.

Target flow

iFIT leverages tunnel sessions established by SRv6 TE policies, targeting the packets within these tunnels as the flows of interest. It adds an iFIT header onto packets that match the defined criteria for measurement.

Collector

Collector is deployed on the egress node of the SRv6 TE policy.

The egress node that operates in Collector mode sends the local iFIT measurement results for SRv6 paths to the ingress node (Analyzer) of the SRv6 TE policy via UDP packets.

Analyzer

Analyzer is deployed on the ingress node of the SRv6 TE policy.

A node performs the following tasks when operating in Analyzer mode:

· Forwards the local iFIT measurement results to Analyzer on the same node.

· Analyzer aggregates and calculates the iFIT measurement results received from both the ingress and egress nodes, deriving metrics such as packet loss, latency, and jitter for the SRv6 tunnels.

Operating mechanism

The iFIT tunnel-level measurement workflow is as follows:

1. Time-synchronize the ingress and egress nodes.

2. Deploy the SRv6 TE policy on the network. The policy selects the optimal path for service forwarding.

3. Use iFIT for the SRv6 TE policy on the ingress node and issue measurement parameters to iFIT, such as the segment list ID of the SRv6 tunnel, iFIT measurement interval, whether to measure packet loss, whether to measure one-way or two-way latency, packet loss rate criteria, latency criteria, and jitter criteria.

4. The ingress node automatically creates an iFIT instance and assigns a FlowID to it.

5. The iFIT instance on the ingress node matches tunnel packets by the segment list ID in the SRv6 TE policy:

¡ For matched tunnel packets, iFIT performs packet loss and latency measurements and sends the results to the local Analyzer module.

¡ For unmatched tunnel packets, iFIT does not perform a measurement.

6. The egress node parses the iFIT headers in the packets and performs iFIT packet loss and latency measurements.

7. Collector (egress node) establishes a UDP session with the ingress node based on the source address of the received packets and sends the counted packet statistics and packet timestamps to the ingress node over the UDP session, according to the iFIT measurement interval defined in the SRv6 TE policy.

8. Analyzer (ingress node) calculates the packet loss rate by comparing the number of packets received on the ingress and egress nodes and computes one-way latency and one-way jitter based on the timestamp when a packet was sent from the ingress node and timestamp when the same packet was received on the egress node. If the calculated results exceed the packet loss rate, latency, or jitter thresholds defined in the SRv6 TE policy, Analyzer reports the exceeding metrics to the local SRv6 TE policy module on the same node. iFIT will then immediately notify the SRv6 TE policy to initiate a link switch, redirecting traffic to an alternate path.

Configuring iFIT application-level measurement

iFIT application-level measurement measures the metrics such as the packet loss rate and delay when service traffic passes through the transmission network. The measurement result can be used to assess the network transmission quality for the service traffic.

Restrictions and guidelines

If different APN instances on a device have the same APN ID and share the same traffic physical egress, only one APN instance is allowed for iFIT measurement.

To ensure iFIT measurement accuracy on a VPLS network, you can deploy only unicast forwarding services on the network. If multicast or broadcast services are present on the network, traffic from these services might lead to inaccurate iFIT measurement results.

On the MPLS L3VPN to SRv6 and VXLAN to SRv6 networks, only the measurement based on the PeerLocator granularity is supported for iFIT application-level measurement when the following conditions are met:

· iFIT detects the SRv6 network.

· iFIT uses the intermediate device that connects the MPLS/VXLAN and SRv6 networks as the ingress node.

In SRv6-based hybrid networking, if public traffic is steered to an SRv6 tunnel through static routes or BGP recursive routes, it does not support PeerLocator granularity-based iFIT measurement. PeerLocator granularity-based iFIT measurement is supported only when you configured public routes as global VPN instances.

When the transport network type of a service flow is IP, iFIT measurement based on five-tuple granularity generates statistical data only on the ingress node. In an SRv6 HoVPN scenario, if the first segment of the SRv6 tunnel is enabled with iFIT measurement, do not configure iFIT measurement on the second segment to avoid inaccurate measurement data. If the first segment is an MPLS or SRv6 network and is disabled with iFIT measurement, you can configure iFIT measurement on the second segment.

In iFIT measurement, iFIT application-level measurement takes precedence over iFIT tunnel-level measurement. In iFIT application-level quality measurement, the following measurement granularities in descending order of priority are supported: Five-tuple granularity, APN ID granularity, and PeerLocator granularity.

iFIT measurement does not support GRE over MPLS, MPLS over GRE, or IPSec over GRE scenario.

An iFIT instance monitors only one flow. If you configure flows multiple times for an iFIT instance, the most recent configuration takes effect.

For the flows to be monitored by different instances, the flow attributes must not be identical and cannot conflict to avoid inaccurate measurement result.

As a best practice, configure iFIT first on the transit nodes and the egress node and then the ingress node. Thus, the measurement results of the previous measurement periods will not affected if iFIT measurement starts on the ingress node but not on the transit nodes and the egress node.

Modifying the iFIT instance or restarting the ingress node will cause flow ID change, which might cause inaccurate measurement data or no data in several measurement periods.

SRv6/G-SRv6 includes SRv6/G-SRv6 TE and SRv6/G-SRv6 BE networks. The iFIT configuration varies by network type as follows:

· On an SRv6/G-SRv6 TE network, after iFIT on a device in a SID list is enabled, the device can perform iFIT measurement. For a transit node not in a SID list, even with iFIT measurement enabled, this transit node does not parse iFIT headers for iFIT measurement. Such transit nodes can parse iFIT headers for iFIT measurement only when CCMC technical standards are used on the ingress node and ifit enable and trace-measure per-hop are executed on these transit nodes.

· On an SRv6/G-SRv6 BE network, if you specify hop-by-hop measurement as the measurement mode, iFIT generates iFIT data only on the ingress and egress nodes during SRv6/G-SRv6 forwarding. By default, the transit points only forward IPv6 packets and do not participate in SRv6/G-SRv6 processing, so no iFIT data is generated on the transit points. For transit nodes to perform iFIT measurement, execute the ifit enable and trace-measure per-hop commands on the transit nodes.

Prerequisites

Before configuring iFIT, configure PTP or NTP settings to synchronize time for the analyzer and all iFIT-enabled devices. Both PTP and NTP can be used to synchronize time between devices. time synchronization is accurate to sub-microseconds through PTP and to milliseconds through NTP.

· As a best practice, use PTP for time synchronization in an iFIT measurement network.

· If the devices do not support PTP but support high-precision NTP, enable high-precision NTP on the local and remote devices.

· If the devices do not support PTP or high-precision NTP, use standard NTP. When NTP is used, the device can measure packet loss rates, but the delay measurement is not accurate.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

To enable the iFIT-enabled devices to report the measurement results to the analyzer, configure gRPC on the analyzer and iFIT-enabled devices. For more information about gRPC, see gRPC configuration in Telemetry Configuration Guide.

Configuring the ingress node

Tasks at a glance

To configure the ingress node, perform the following tasks:

· Enabling iFIT

· Configuring a device ID

· Creating an iFIT instance

· Configuring the transit network type for a target flow

· Configuring a static flow

· Configuring a detection point

· Configuring a measurement mode

· Configuring a measurement period

· Enabling iFIT measurement

Enabling iFIT

1. Enter system view.

system-view

2. Enable the iFIT functionality globally and enter its view, or enter the existing iFIT view.

ifit enable

By default, the iFIT functionality is disabled.

3. Specify a device ID.

device-id device-id

By default, no device ID is specified.

A device ID is required and uniquely identifies a device on an iFIT measurement network.

4. Specify the standards used by iFIT.

technical-standard { cmcc | telecom | unicom }

By default, iFIT uses the CMCC technical standards.

This command is not required for end-to-end measurement and will not impact the measurement results of end-to-end measurement.

To ensure correct measurement results of hop-by-hop measurement, you must execute this command and make sure the devices included in iFIT measurement are configured with the same technical standards.

Configuring a device ID

About this task

When the transit network type for a service flow is MPLS, SR-MPLS, SRv6, G-SRv6, or G-BIER, and iFIT measurement is required for the service flow, you must specify the device ID of a device. A device ID must be unique within an iFIT network. This is because in these types of transit networks, iFIT uses the device ID to uniquely identify a device and uses a device ID and a flow ID to uniquely identify a static flow and the corresponding dynamic flows.

Procedure

1. Enter system view.

system-view

2. Specify an iFIT device ID.

device-id device-id

By default, no device identifier is specified.

A device identifier is required to uniquely identify an iFIT device on an iFIT network.

Creating an iFIT instance

1. Enter system view.

system-view

2. Enter iFIT view.

ifit enable

3. Create an iFIT instance and enter its view.

instance instance-name

Configuring the transit network type for a target flow

About this task

To measure the transmission quality of an iFIT flow on a transit network, the administrator must perform the following operations:

· Specify the device where the iFIT flow enters the transit network as the ingress node.

· Specify the device where the iFIT flow leaves the transit network as the egress node.

The ingress node adds an iFIT header to the target flow. The encapsulation format of an iFIT header varies by transit network type.

Configure this feature type depends on the transit network type of the target flow:

· If the transit network is an MPLS, SR-MPLS, SRv6, G-SRv6, or G-BIER network, specify the iFIT network type for iFIT measurement as Tunnel.

· If the transit network is the public network, specify the iFIT network type for iFIT measurement as Native-IP.

Procedure

1. Enter system view.

system-view

2. Enter iFIT view.

ifit enable

3. Create an iFIT instance and enter its view.

instance instance-name

4. Specify the transit network type for iFIT measurement.

transmit-network type { tunnel | native-ip }

By default, the transit network type for iFIT measurement is Tunnel. This transit network type supports iFIT measurement on a G-SRv6, SRv6, G-BIER, MPLS, or SR-MPLS network.

Configuring a static flow

About this task

Static flows are key elements for iFIT measurement. Before starting an iFIT measurement, you must configure a static flow to be measured on the ingress node. The transit nodes and egress node will automatically learn the static flow through the iFIT header of the packets.

The device can perform iFIT measurement based on the following granularities in different scenarios:

· Layer 2 parameter granularity—Measures communication quality of a service flow within an L2VPN tunnel. You can match the service flow by using Layer 2 parameters such as source MAC, destination MAC, Ethernet packet type, VLAN ID, and VLAN priority. This measurement granularity is supported on an EVPN VPLS over MPLS/SR-MPLS, EVPN VPWS over MPLS/SR-MPLS, EVPN VPLS over SRv6/G-SRv6, or EVPN VPWS over SRv6/G-SRv6 network.

· 5-tuple granularity—Measures communication quality of service flows. You can use 5-tuple elements to match service flows and perform iFIT measurement on any service traffic on a network. This granularity is available for all networks supported by iFIT.

· PeerLocator granularity—Measures end-to-end communication quality on the entire network. On an IPv6 network, the peer-locator keyword can specify a tunnel. The device performs iFIT measurement on all service flows through the tunnel. This granularity is available only for SRv6 and G-SRv6 networks.

· APN ID granularity—Measures the communication quality of an application. This granularity is available only for L3VPN over SRv6/G-SRv6 networks.

Procedure

1. Enter system view.

system-view

2. Enter iFIT view.

ifit enable

3. Specify a next hop for iFIT encapsulation.

encapsulation nexthop ipv4-address

On an MPLS or SR-MPLS network, you must execute this command to specify a peer PE for iFIT encapsulation. The device performs iFIT encapsulation only for service flows sent to the specified peer PE. If you do not execute this command, only the ingress node generates statistics, and other nodes do not generate statistics even if iFIT is enabled on them.

On an SRv6, G-SRv6, or G-BIER network, this command is not required. This command does not take effect on these networks.

4. Create an iFIT instance and enter its view.

instance instance-name

5. On a Native-IP network, configure a static flow to be monitored by the instance based on 5-tuple granularity.

¡ IPv4:

flow unidirection source-ip { src-ip-address [ src-mask-length ] | any } destination-ip { dest-ip-address [ dest-mask-length ] | any } [ protocol { { sctp | tcp | udp } [ source-port src-port-number ] [ destination-port dest-port-number ] | protocol-number } ] [ dscp dscp-value ] vpn-instance vpn-instance-name

¡ IPv6:

flow unidirection source-ipv6 { src-ipv6-address [ src-prefix-length ] | any } destination-ipv6 { dest-ipv6-address [ dest-prefix-length ] | any } [ protocol { { sctp | tcp | udp } [ source-port src-port-number ] [ destination-port dest-port-number ] | protocol-number } ] [ dscp dscp-value ] vpn-instance vpn-instance-name

By default, no static flow is configured for an iFIT instance.

6. On an MPLS or SR-MPLS public network, configure a static flow to be monitored by the instance based on 5-tuple granularity.

¡ IPv4:

¡ IPv6:

IPv6 service flows are not supported in the current software version.

By default, no static flow is configured for an iFIT instance.

7. On an MPLS or SR-MPLS private network, configure a static flow to be monitored by the instance based on 5-tuple granularity.

¡ IPv4:

¡ IPv6:

By default, no static flow is configured for an iFIT instance.

8. On an EVPN VPLS over MPLS/SR-MPLS network, configure a static flow to be monitored by the instance.

¡ iFIT measurement based on Layer 2 parameter granularity:

flow unidirection { destination-mac dest-mac-address | eth-type eth-type-id | priority-8021p priority-value | source-mac src-mac-address | vlan vlan-id } * vsi vsi-name

¡ iFIT measurement based on 5-tuple granularity:

- IPv4:

- IPv6:

By default, no static flow is configured for an iFIT instance.

9. On an EVPN VPWS over MPLS/SR-MPLS network, configure a static flow to be monitored by the instance.

¡ iFIT measurement based on based on Layer 2 parameter granularity:

flow unidirection { destination-mac dest-mac-address | eth-type eth-type-id | priority-8021p priority-value | source-mac src-mac-address | vlan vlan-id } * xconnect-group group-name connection connection-name

¡ iFIT measurement based on 5-tuple granularity:

- IPv4:

- IPv6:

By default, no static flow is configured for an iFIT instance.

10. On an IPv4 over SRv6/G-SRv6 public network, configure a static flow to be monitored by the instance.

¡ iFIT measurement based on 5-tuple granularity:

- IPv4:

- IPv6:

¡ iFIT measurement based on PeerLocator granularity:

- IPv4:

flow unidirection [ source-ip any destination-ip any ] peer-locator ipv6-address prefix-length

- IPv6:

flow unidirection [ source-ipv6 any destination-ipv6 any ] peer-locator ipv6-address prefix-length

By default, no static flow is configured for an iFIT instance.

11. On an L3VPN/EVPN L3VPN over SRv6/G-SRv6 network, configure a static flow to be monitored by the instance.

¡ iFIT measurement based on 5-tuple granularity:

- IPv4:

- IPv6:

¡ iFIT measurement based on PeerLocator granularity:

- IPv4:

flow unidirection [ source-ip any destination-ip any ] [ vpn-instance vpn-instance-name ] peer-locator ipv6-address prefix-lengh

- IPv6:

flow unidirection [ source-ipv6 any destination-ipv6 any ] [ vpn-instance vpn-instance-name ] peer-locator ipv6-address prefix-length

¡ iFIT measurement based on APN ID granularity on IPv4 and IPv6 service flows:

flow unidirection apn-id-ipv6 instance apn-instance-name

undo flow

By default, no static flow is configured for an iFIT instance.

12. On an EVPN VPLS over SRv6/G-SRv6 network, configure a static flow to be monitored by the instance.

¡ iFIT measurement based on Layer 2 parameter granularity:

flow unidirection { destination-mac dest-mac-address | eth-type eth-type-id | priority-8021p priority-value | source-mac src-mac-address | vlan vlan-id } * vsi vsi-name

¡ iFIT measurement based on 5-tuple granularity:

- IPv4:

- IPv6:

¡ iFIT measurement based on PeerLocator granularity:

flow unidirection vsi vsi-name peer-locator ipv6-address prefix-length

By default, no static flow is configured for an iFIT instance.

13. On an EVPN VPWS over SRv6/G-SRv6 network, configure a static flow to be monitored by the instance.

¡ iFIT measurement based on Layer 2 parameter granularity:

¡ iFIT measurement based on 5-tuple granularity:

- IPv4:

- IPv6:

¡ iFIT measurement based on PeerLocator granularity:

flow unidirection xconnect-group group-name connection connection-name peer-locator ipv6-address prefix-length

By default, no static flow is configured for an iFIT instance.

14. On a G-BIER network, configure a static flow to be monitored by the instance.

¡ IPv4:

¡ IPv6:

By default, no static flow is configured for an iFIT instance.

Configuring a detection point

About this task

Before enabling iFIT measurement on the ingress node of an instance, you must bind an interface to the instance.

After you bind an interface to an instance, iFIT parses the packets passing through the interface to identify the target packets and add an iFIT header to each target packets. Meanwhile, iFIT will count the number of target packets, and send the packet count and timestamp to the analyzer at intervals through gRPC.

You can configure only one set of flow match criteria for an instance. An instance can be bound to multiple interfaces. Each bound interface matches target flows based on the same set of criteria and assigns different flow IDs to target flows. iFIT measures the delay and packet loss of target flows on a per-interface basis.

Restrictions and guidelines

You can bind an iFIT instance to only a Layer 3 physical interface, Layer 3 aggregate interface, slot-based L2VE interface, slot-based L3VE interface, and slot-based L3VE subinterface to an instance. For more information about L2VE interfaces, L3VE interfaces, and L3VE subinterfaces, see L2VPN access to L3VPN or IP backbone in MPLS Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter iFIT view.

ifit enable

3. Create an iFIT instance and enter its view.

instance instance-name

4. Bind an interface to the instance.

bind interface interface-type interface-number

By default, an instance is not bound to any interface.

Configuring a measurement mode

1. Enter system view.

system-view

2. Enter iFIT view.

ifit enable

3. Create an iFIT instance and enter its view.

instance instance-name

4. Specify an iFIT measurement mode.

measure mode { e2e | trace }

By default, end-to-end measurement is used.

Configuring a measurement period

About this task

iFIT collects performance statistics based on the measurement period.

· The sender records the sending time of the first iFIT packet in each sending interval, and counts the number of the iFIT packets sent from an interface in each sending interval. Sending interval = iFIT measurement period.

· The receiver records the receiving time of the first iFIT packet in each receiving interval, and counts the number of the iFIT packets received by an interface in each receiving interval. To reduce the impact of network delay and disorder on statistics, the receiving interval equals to (1+1/3) measurement period.

If network delay between the ingress and egress nodes is greater than 1/3 measurement period, the accuracy of iFIT packet loss statistics might be affected. This is because iFIT considers packets received beyond the receiving interval as packet loss. For example, the measurement period is 1 second and the network delay greater than 1/3 seconds (333 milliseconds), the accuracy of iFIT packet loss statistics might be affected. In this case, set the measurement period to a greater value.

Restrictions and guidelines

You can set the iFIT measurement period to one second only when PTP or high-precision NTP is deployed for time synchronization.

Procedure

1. Enter system view.

system-view

2. Enter iFIT view.

ifit enable

3. Create an iFIT instance and enter its view.

instance instance-name

4. Specify the measurement period for the iFIT instance.

period period

By default, the measurement period for an iFIT instance is 30 seconds.

Enabling iFIT measurement

About this task

You can configure packet loss measurement and packet delay measurement as required. Both packet loss measurement and packet delay measurement are enabled by default. You cannot disable packet loss measurement from the CLI, but can disable packet delay measurement from the CLI.

Procedure

1. Enter system view.

system-view

2. Enter iFIT view.

ifit enable

3. Create an iFIT instance and enter its view.

instance instance-name

4. (Optional.) Disable packet delay measurement.

delay-measure disable

By default, packet delay measurement is enabled.

5. Enable iFIT measurement for the iFIT instance.

measure enable

By default, iFIT measurement for an iFIT instance is disabled.

Configuring the MPE in an SRv6 HoVPN scenario

About this task

In an SRv6 HoVPN scenario, to measure the performance of the entire UPE-to-SPE link, you must configure this feature.

Procedure

1. Enter system view.

system-view

2. Enable iFIT and enter iFIT view.

ifit enable

By default, iFIT is disabled.

3. Specify the standards used by iFIT.

technical-standard { cmcc | telecom | unicom }

By default, iFIT uses the CMCC technical standards.

This command is not required for end-to-end measurement and will not impact the measurement results of end-to-end measurement.

To ensure correct measurement results of hop-by-hop measurement, you must execute this command and make sure the devices included in iFIT measurement are configured with the same technical standards.

4. Enable iFIT header inheriting.

inherit peer-locator prefix prefix-length

By default, iFIT header inheriting is disabled.

Configuring a transit node and the egress node

Tasks at a glance

Transit nodes are required only for hop-by-hop measurement. For end-to-end measurement, do not configure transit nodes.

To configure a transit node, perform the following tasks:

· Enabling iFIT

· (Optional.) Managing a dynamic flow

To configure the ingress node, perform the following tasks:

· Enabling iFIT

· (Optional.) Managing a dynamic flow

Enabling iFIT

1. Enter system view.

system-view

2. Enable the iFIT functionality globally and enter its view.

ifit enable

By default, the iFIT functionality is disabled.

3. Specify the standards used by iFIT.

technical-standard { cmcc | telecom | unicom }

By default, iFIT uses the CMCC technical standards.

This command is not required for end-to-end measurement and will not impact the measurement results of end-to-end measurement.

To ensure correct measurement results of hop-by-hop measurement, you must execute this command and make sure the devices included in iFIT measurement are configured with the same technical standards.

4. (Optional.) Enable iFIT measurement on transit nodes in an SRv6 tunnel.

trace-measure per-hop [ be | te ]

By default, iFIT measurement is disabled on transit nodes in an SRv6 tunnel.

This command is required only when a device not in an SID list uses CMCC technical standards and must participate in iFIT measurement. This command does not take effect if other technical standards are used.

On an SRv6 TE policy network, the subsequent transit nodes might not have the SRH due to special settings such as PSP. In this case, for the subsequent transit nodes to forcedly parse iFIT headers for iFIT measurement, execute trace-measure per-hop be on these transit nodes instead of trace-measure per-hop te.

Managing a dynamic flow

1. Enter system view.

system-view

2. Enable the iFIT functionality globally and enter its view.

ifit enable

3. Specify the aging parameters for dynamic flows.

dynamic-flow aging-time multi-value [ threshold-percent threshold-percent ]

By default, the aging time for dynamic flows is 10 times the measurement period and it cannot be less than 5 minutes.

4. Delete iFIT dynamic flows.

delete dynamic-flow { all | device-id device-id flow-id flow-id }

Display and maintenance commands for iFIT application-level measurement

Execute display commands in any view.

Task	Command
Display dynamic flow information.	display ifit flow dynamic [ device-id device-id flow-id flow-id ]
Display static flow information.	display ifit flow static [ device-id device-id flow-id flow-id ]
Display global information about iFIT target flows.	display ifit global-information
Display iFIT instance information.	display ifit instance [ instance-name ]
Display statistics about an iFIT dynamic flow for the most recent 10 measurement periods.	display ifit statistic device-id device-id flow-id flow-id [ verbose ]
Clear iFIT statistics of dynamic flows for the most recent 10 measurement periods.	reset ifit statistic [ device-id device-id flow-id flow-id \| instance instance-name ]

‌

iFIT configuration examples

Example: Configuring iFIT on a Native-IP network

Network configuration

As shown in Figure 7, the backbone network is an IPv6 network. In this IPv6 network, deploy public IPv6 over SRv6 BE between PEs and use an SRv6 tunnel to transmit IPv6 data and iFIT information.

· Configure EBGP to exchange VPN routing information between the CEs and PEs.

· Configure IPv6 IS-IS on the PEs in the same AS to realize IPv6 network connectivity.

· Configure IBGP to exchange IPv6 routing information.

· Configure iFIT to monitor the occurrence of packet loss and packet delay value when the flow passes through PE 1 and PE 2.

Figure 7 Network diagram

‌

Prerequisites

1. Set up the SRv6 BE network. (Details not shown.)

For more information, see public network IP over SRv6 configuration in Segment Routing Configuration Guide.

2. Configure basic PTP or NTP functions for time synchronization between PE 1 and PE 2. (Details not shown.)

Both PTP and NTP can be used to synchronize time between devices. Time synchronization is accurate to sub-microseconds through PTP and to milliseconds through NTP. As a best practice, use PTP for time synchronization in an iFIT measurement network.

If the devices do not support PTP but support high-precision NTP, enable high-precision NTP on the local and remote devices.

If the devices do not support PTP or high-precision NTP, use the standard NTP. When the standard NTP is used, the device can measure packet loss rates, but the delay measurement is not accurate.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

Procedure

1. Configure PE 1.

a. Configure gRPC:

# Enable the gRPC service.

<PE1> system-view

[PE1] grpc enable

# Create a sensor group named test, and add sensor path ifit/flowstatistics/flowstatistic.

[PE1] telemetry

[PE1-telemetry] sensor-group test

[PE1-telemetry-sensor-group-test] sensor path ifit/flowstatistics/flowstatistic depth 2

[PE1-telemetry-sensor-group-test] quit

# Create a destination group named collector1. Specify a collector that uses IPv6 address 10::10 and port number 50050.

[PE1-telemetry] destination-group collector1

[PE1-telemetry-destination-group-collector1] ipv6-address 10::10 port 50050

[PE1-telemetry-destination-group-collector1] quit

# Configure a subscription named A to bind sensor group test with destination group collector1. Set the sampling interval to 5 seconds.

[PE1-telemetry] subscription A

[PE1-telemetry-subscription-A] sensor-group test sample-interval 5

[PE1-telemetry-subscription-A] destination-group collector1

[PE1-telemetry-subscription-A] quit

[PE1-telemetry] quit

b. Configure iFIT:

# Enable the iFIT functionality.

[PE1] ifit enable

# Specify the device ID.

[PE1-ifit] device-id 100

# Configure instance a.

[PE1-ifit] instance a

# Specify the transit network type as Native-IP and measurement mode as end-to-end measurement.

[PE1-ifit-instance-a] transmit-network type native-ip

[PE1-ifit-instance-a] measure mode trace

[PE1-ifit-instance-a] flow unidirection source-ip 2000::1 destination-ip 2001::1 vpn-instance vpn1

[PE1-ifit-instance-a] bind interface gigabitethernet 1/0/1

# Enable the iFIT functionality.

[PE1-ifit-instance-a] measure enable

[PE1-ifit-instance-a] quit

[PE1-ifit] quit

2. Configure P.

# Configure gRPC:

Use the same procedure to configure gRPC on P as you configure gRPC on PE 1.

# Enable the iFIT functionality.

<P> system-view

[P] ifit enable

3. Configure PE 2.

# Configure gRPC:

Use the same procedure to configure gRPC on P as you configure gRPC on PE 1.

# Enable the iFIT functionality.

<PE2> system-view

[PE2] ifit enable

Verifying the configuration

1. View information about iFIT instance a on PE 1.

[PE1] display ifit instance a

Instance name : a

Device ID : 100

Transmit network type : Native-IP

Flow information:

Flow type : Static

Flow direction : Unidirection

Source IPv6/prefix length : 2000::1/64

Destination IPv6/prefix length : 2001::1/64

Protocol : Any

Source port : Any

Destination port : Any

DSCP : --

VPN instance name : vpn1

Measurement information:

Period : 30 sec

Measurement mode : trace

Loss measurement : Enabled

Delay measurement : Enabled

Measurement configuration : Enabled

Measurement status : Active

Flow items:

Flow ID Interface

1 Ten-GigabitEthernet0/0/15

2. View information about the iFIT static flow on PE 1.

[PE1] display ifit flow static

Instance name : 1

Device ID : 100

Flow ID : 1

Transmit network type : Native-IP

Flow information:

Flow type : Static

Flow direction : Unidirection

Source IPv6/prefix length : 2000::1/64

Destination IPv6/prefix length : 2001::1/64

Protocol : Any

Source port : Any

Destination port : Any

DSCP : --

VPN instance name : vpn1

Measurement information:

Period : 30 sec

Measurement mode : trace

Loss measurement : Enabled

Delay measurement : Enabled

Measurement configuration : Enabled

Measurement status : Active

Bound interface:

Ten-GigabitEthernet0/0/15

3. View information about the iFIT dynamic flow on PE 1.

[PE1] display ifit flow dynamic

Device ID : 100

Flow ID : 1

Flow type : Dynamic

Flow direction : Unidirection

Period : 30 sec

Actual aging-time : 300 sec

Aging threshold : 30%

Interface information:

Name Direction

Ten-GigabitEthernet0/0/15 Ingress

GigabitEthernet1/0/2 TransitOutput

4. View iFIT statistics on PE 1.

[PE1] display ifit statistic device-id 100 flow-id 1

Period ID Direction PktCount Timestamp(sec, nsec) Interface

55593875 Ingress 12668295 1667816250, 5692918 GE1/0/1

55593875 TransitOut 12668295 1667816250, 5702118 GE1/0/2

55593876 Ingress 12669756 1667816280, 4268742 GE1/0/1

55593876 TransitOut 12669756 1667816280, 4278486 GE1/0/2

55593877 Ingress 12668696 1667816310, 6303734 GE1/0/1

55593877 TransitOut 12668696 1667816310, 6313286 GE1/0/2

...

Example: Configuring iFIT on an MPLS private network

As shown in Figure 8:

· Configure IPv4 EVPN L3VPN for different sites of a VPN instance to communicate with each other.

· Configure the CE and the PE of each site to use EBGP to exchange VPN routes.

· Configure the PEs to communicate through OSPF and to exchange BGP EVPN routes through MP-IBGP.

· Configure iFIT to monitor the occurrence of packet loss and packet delay value when the flow passes through the VPN 1 tunnel.

Figure 8 Network diagram

‌

Prerequisites

1. Configure EVPN L3VPN. (Details not shown.)

For information about configuring EVPN L3VPN, see EVPN L3VPN configuration in EVPN Configuration Guide.

2. Configure basic PTP or NTP functions for time synchronization between PE 1 and PE 2. (Details not shown.)

If the devices do not support PTP but support high-precision NTP, enable high-precision NTP on the local and remote devices.

If the devices do not support PTP or high-precision NTP, use the standard NTP. When the standard NTP is used, the device can measure packet loss rates, but the delay measurement is not accurate.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

Procedure

1. Configure gRPC:

# Enable the gRPC service.

<PE1> system-view

[PE1] grpc enable

# Create a sensor group named test, and add sensor path ifit/flowstatistics/flowstatistic.

[PE1] telemetry

[PE1-telemetry] sensor-group test

[PE1-telemetry-sensor-group-test] sensor path ifit/flowstatistics/flowstatistic depth 2

[PE1-telemetry-sensor-group-test] quit

# Create a destination group named collector1. Specify a collector that uses IPv4 address 10.10.10.10 and port number 50050.

[PE1-telemetry] destination-group collector1

[PE1-telemetry-destination-group-collector1] ipv4-address 10.10.10.10 port 50050

[PE1-telemetry-destination-group-collector1] quit

# Configure a subscription named A to bind sensor group test with destination group collector1. Set the sampling interval to 5 seconds.

[PE1-telemetry] subscription A

[PE1-telemetry-subscription-A] sensor-group test sample-interval 5

[PE1-telemetry-subscription-A] destination-group collector1

[PE1-telemetry-subscription-A] quit

[PE1-telemetry] quit

2. Configure iFIT:

# Enable the iFIT functionality.

[PE1] ifit enable

[PE1-ifit] device-id 1

# Configure instance a to monitor the unidirectional flow from source IP 1.1.1.1/24 to destination IP 1.1.3.1/24 with the PE at 3.3.3.9 as the next hop in VPN instance vpn1.

[PE1-ifit] encapsulation nexthop 3.3.3.9

[PE1-ifit] instance a

[PE1 ifit-instance-a] flow unidirection source-ip 1.1.1.1 24 destination-ip 1.1.3.1 24 vpn-instance vpn1

# Bind interface Ten-GigabitEthernet0/0/15 to instance a.

[PE1-ifit-instance-a] bind interface ten-gigabitethernet 0/0/15

# Specify 10 seconds as the measurement period.

[PE1-ifit-instance-a] period 10

# Specify end-to-end measurement as the measurement mode.

[PE1-ifit-instance-a] measure mode e2e

# Enable iFIT measurement.

[PE1-ifit-instance-a] measure enable

[PE1-ifit-instance-a] quit

[PE1-ifit] quit

3. Configure PE 2:

# Configure gRPC.

Use the same procedure to configure gRPC on PE 2 as you configure gRPC on PE 1.

# Enable the iFIT functionality.

<PE2> system-view

[PE2] ifit enable

Verifying the configuration

1. View iFIT statistics on PE 1.

[PE1] display ifit statistic device-id 1 flow-id 3

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Ingress 4124 1630599180, 1889782 XGE0/0/15

163059919 Ingress 4124 1630599190, 1901494 XGE0/0/15

163059920 Ingress 4124 1630599200, 1912118 XGE0/0/15

2. View iFIT statistics on PE 2.

[PE2] display ifit statistic device-id 1 flow-id 3

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Egress 4124 1630599180, 1948185 XGE0/0/15

163059919 Egress 4124 1630599190, 1959405 XGE0/0/15

163059920 Egress 4120 1630599200, 1968503 XGE0/0/15

3. Packet loss occurs in period 163059920 by viewing iFIT statistics on the analyzer.

Example: Configuring iFIT on an IPv4 L3VPN over SRv6 network

Network configuration

As shown in Figure 9, the backbone network is an IPv6 network, and VPN 1 is an IPv4 network. Deploy MPLS L3VPN over SRv6 between PE 1 and PE 2 and use an SRv6 tunnel to transmit VPNv4 traffic between the PEs.

· Configure EBGP to exchange VPN routing information between the CEs and PEs.

· Configure IPv6 IS-IS on the PEs in the same AS to realize IPv6 network connectivity.

· Configure MP-IBGP to exchange VPNv4 routing information between the PEs.

· Configure iFIT to monitor the occurrence of packet loss and packet delay value when the flow passes through the VPN 1 tunnel.

Figure 9 Network diagram

‌

Prerequisites

1. Configure IPv4 L3VPN over SRv6. (Details not shown.)

For information about configuring MPLS L3VPN over SRv6, see IP L3VPN over SRv6 configuration in Segment Routing Configuration Guide.

2. Configure basic PTP or NTP functions for time synchronization between PE 1 and PE 2. (Details not shown.)

If the devices do not support PTP but support high-precision NTP, enable high-precision NTP on the local and remote devices.

If the devices do not support PTP or high-precision NTP, use the standard NTP. When the standard NTP is used, the device can measure packet loss rates, but the delay measurement is not accurate.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

Procedure

1. Configure gRPC:

# Enable the gRPC service.

<PE1> system-view

[PE1] grpc enable

# Create a sensor group named test, and add sensor path ifit/flowstatistics/flowstatistic.

[PE1] telemetry

[PE1-telemetry] sensor-group test

[PE1-telemetry-sensor-group-test] sensor path ifit/flowstatistics/flowstatistic depth 2

[PE1-telemetry-sensor-group-test] quit

# Create a destination group named collector1. Specify a collector that uses IPv6 address 10::10 and port number 50050.

[PE1-telemetry] destination-group collector1

[PE1-telemetry-destination-group-collector1] ipv6-address 10::10 port 50050

[PE1-telemetry-destination-group-collector1] quit

# Configure a subscription named A to bind sensor group test with destination group collector1. Set the sampling interval to 5 seconds.

[PE1-telemetry] subscription A

[PE1-telemetry-subscription-A] sensor-group test sample-interval 5

[PE1-telemetry-subscription-A] destination-group collector1

[PE1-telemetry-subscription-A] quit

[PE1-telemetry] quit

2. Configure iFIT:

# Enable the iFIT functionality.

[PE1] ifit enable

[PE1-ifit] device-id 1

# Configure instance a to monitor the performance parameters of the service flow transmitting in VPN instance vpn1 from source end 1.1.1.1/24 to destination end 1.1.2.1/24.

[PE1-ifit] encapsulation nexthop-ipv6 3::3

[PE1-ifit] instance a

[PE1-ifit-instance-a] flow unidirection source-ip 1.1.1.1 24 destination-ip 1.1.2.1 24 vpn-instance vpn1

# Bind interface Ten-GigabitEthernet 0/0/15 to instance a.

[PE1-ifit-instance-a] bind interface ten-gigabitethernet 0/0/15

# Specify 10 seconds as the measurement period.

[PE1-ifit-instance-a] period 10

# Enable iFIT measurement.

[PE1-ifit-instance-a] measure enable

[PE1-ifit-instance-a] quit

[PE1-ifit] quit

3. Configure PE 2:

# Configure gRPC.

Use the same procedure to configure gRPC on PE 2 as you configure gRPC on PE 1.

# Enable the iFIT functionality.

<PE2> system-view

[PE2] ifit enable

Verifying the configuration

1. View iFIT statistics on PE 1.

[PE1-ifit-instance-a] display ifit statistic device-id 1 flow-id 2

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Ingress 4124 1630599180, 1889782 XGE0/0/15

163059919 Ingress 4124 1630599190, 1901494 XGE0/0/15

163059920 Ingress 4124 1630599200, 1912118 XGE0/0/15

2. View iFIT statistics on PE 2.

[PE2] display ifit statistic device-id 1 flow-id 2

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Egress 4124 1630599180, 1948185 XGE0/0/15

163059919 Egress 4124 1630599190, 1959405 XGE0/0/15

163059920 Egress 4120 1630599200, 1968503 XGE0/0/15

3. Packet loss occurs in period 163059920 by viewing iFIT statistics on the analyzer.

Example: Configuring iFIT on an IPv6 EVPN L3VPN over SRv6 network

Network configuration

As shown in Figure 10, the backbone network is an IPv6 network. Deploy EVPN L3VPN over SRv6 in SRv6-BE mode between PE 1 and PE 2 and use an SRv6 tunnel to transmit EVPN traffic between the PEs.

· Configure EBGP to exchange VPN routing information between the CEs and PEs.

· Configure IPv6 IS-IS on the PEs in the same AS to realize IPv6 network connectivity.

· Configure MP-IBGP to exchange EVPN routing information between the PEs.

· Configure iFIT to monitor the occurrence of packet loss and packet delay value when the flow passes through the VPN 1 tunnel.

Figure 10 Network diagram

‌

Prerequisites

1. Configure IPv6 EVPN L3VPN over SRv6. (Details not shown.)

For information about configuring IPv6 EVPN L3VPN over SRv6, see EVPN L3VPN over SRv6 configuration in Segment Routing Configuration Guide.

2. Configure basic PTP or NTP functions for time synchronization between PE 1 and PE 2. (Details not shown.)

If the devices do not support PTP but support high-precision NTP, enable high-precision NTP on the local and remote devices.

If the devices do not support PTP or high-precision NTP, use the standard NTP. When the standard NTP is used, the device can measure packet loss rates, but the delay measurement is not accurate.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

Procedure

1. Configure gRPC:

# Enable the gRPC service.

<PE1> system-view

[PE1] grpc enable

# Create a sensor group named test, and add sensor path ifit/flowstatistics/flowstatistic.

[PE1] telemetry

[PE1-telemetry] sensor-group test

[PE1-telemetry-sensor-group-test] sensor path ifit/flowstatistics/flowstatistic depth 2

[PE1-telemetry-sensor-group-test] quit

# Create a destination group named collector1. Specify a collector that uses IPv6 address 10::10 and port number 50050.

[PE1-telemetry] destination-group collector1

[PE1-telemetry-destination-group-collector1] ipv6-address 10::10 port 50050

[PE1-telemetry-destination-group-collector1] quit

# Configure a subscription named A to bind sensor group test with destination group collector1. Set the sampling interval to 5 seconds.

[PE1-telemetry] subscription A

[PE1-telemetry-subscription-A] sensor-group test sample-interval 5

[PE1-telemetry-subscription-A] destination-group collector1

[PE1-telemetry-subscription-A] quit

[PE1-telemetry] quit

2. Configure iFIT:

# Enable the iFIT functionality.

[PE1] ifit enable

[PE1-ifit] device-id 1

# Configure instance a to monitor the performance parameters of the service flow transmitting in VPN instance vpn1 from source end 2001::1 to destination end 2002::1.

[PE1-ifit] encapsulation nexthop-ipv6 3::3

[PE1-ifit] instance a

[PE1-ifit-instance-a] flow unidirection source-ipv6 2001::1 destination-ipv6 2002::1 vpn-instance vpn1

# Bind interface Ten-GigabitEthernet0/0/15 to instance a.

[PE1-ifit-instance-a] bind interface ten-gigabitethernet 0/0/15

# Specify 10 seconds as the measurement period.

[PE1-ifit-instance-a] period 10

# Enable iFIT measurement.

[PE1-ifit-instance-a] measure enable

[PE1-ifit-instance-a] quit

[PE1-ifit] quit

3. Configure PE 2:

# Configure gRPC.

Use the same procedure to configure gRPC on PE 2 as you configure gRPC on PE 1.

# Enable the iFIT functionality.

<PE2> system-view

[PE2] ifit enable

Verifying the configuration

1. View iFIT statistics on PE 1.

[PE1-ifit-instance-a] display ifit statistic device-id 1 flow-id 2

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Ingress 4124 1630599180, 1889782 XGE0/0/15

163059919 Ingress 4124 1630599190, 1901494 XGE0/0/15

163059920 Ingress 4124 1630599200, 1912118 XGE0/0/15

2. View iFIT statistics on PE 2.

[PE2] display ifit statistic device-id 1 flow-id 2

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Egress 4124 1630599180, 1948185 XGE0/0/15

163059919 Egress 4124 1630599190, 1959405 XGE0/0/15

163059920 Egress 4120 1630599200, 1968503 XGE0/0/15

3. Packet loss occurs in period 163059920 by viewing iFIT statistics on the analyzer.

Example: Configuring iFIT on an EVPN VPWS over SRv6 network

Network configuration

As shown in Figure 11, user sites CE 1 and CE 2 connect to PE1 and PE 2, respectively through Ethernet interfaces. Configure CE 1 and CE 2 to communicate through an SRv6 tunnel over the IPv6 backbone network.

The two PEs set up an SRv6 tunnel after assigning End.DX2 SIDs to the cross-connect. On a PE, this SRv6 tunnel is used as an SRv6 PW to encapsulate and forward Layer 2 data packets received from the local site and destined for a remote site.

Configure iFIT to monitor the occurrence of packet loss and packet delay value when the flow passes through the SRv6 tunnel.

Figure 11 Network diagram

‌

Prerequisites

1. Configure EVPN VPWS over SRv6. (Details not shown.)

For information about configuring EVPN VPWS over SRv6, see EVPN VPWS over SRv6 configuration in Segment Routing Configuration Guide.

2. Configure basic PTP or NTP functions for time synchronization between PE 1 and PE 2. (Details not shown.)

If the devices do not support PTP but support high-precision NTP, enable high-precision NTP on the local and remote devices.

If the devices do not support PTP or high-precision NTP, use the standard NTP. When the standard NTP is used, the device can measure packet loss rates, but the delay measurement is not accurate.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

Procedure

1. Configure PE 1:

a. Configure gRPC:

# Enable the gRPC service.

<PE1> system-view

[PE1] grpc enable

# Create a sensor group named test, and add sensor path ifit/flowstatistics/flowstatis.

[PE1] telemetry

[PE1-telemetry] sensor-group test

[PE1-telemetry-sensor-group-test] sensor path ifit/flowstatistics/flowstatistic depth 2

[PE1-telemetry-sensor-group-test] quit

# Create a destination group named collector1. Specify a collector that uses IPv6 address 10::10 and port number 50050.

[PE1-telemetry] destination-group collector1

[PE1-telemetry-destination-group-collector1] ipv6-address 10::10 port 50050

[PE1-telemetry-destination-group-collector1] quit

# Configure a subscription named A to bind sensor group test with destination group collector1. Set the sampling interval to 5 seconds.

[PE1-telemetry] subscription A

[PE1-telemetry-subscription-A] sensor-group test sample-interval 5

[PE1-telemetry-subscription-A] destination-group collector1

[PE1-telemetry-subscription-A] quit

[PE1-telemetry] quit

b. Configure iFIT:

# Enable the iFIT functionality.

[PE1] ifit enable

[PE1-ifit] device-id 1

# Configure instance a to monitor the service flow with cross-connect con1 of cross-connect group xca. The PeerlLocator for the service flow is 200::.

[PE1-ifit] instance a

[PE1-ifit-instance-a] flow unidirection xconnect-group xca connection con1 peer-locator 200:: 64

# Bind interface Ten-GigabitEthernet 0/0/15 to instance a.

[PE1-ifit-instance-a] bind interface ten-gigabitethernet 0/0/15

# Specify 10 seconds as the measurement period.

[PE1-ifit-instance-a] period 10

# Enable the iFIT functionality.

[PE1-ifit-instance-a] measure enable

[PE1-ifit-instance-a] quit

[PE1-ifit] quit

2. Configure PE 2:

a. Configure gRPC.

Use the same procedure to configure gRPC on PE 2 as you configure gRPC on PE 1.

b. Enable the iFIT functionality.

<PE2> system-view

[PE2] ifit enable

Verifying the configuration

1. View iFIT statistics on PE 1.

[PE1] display ifit statistic device-id 1 flow-id 2

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Ingress 4124 1630599180, 1889782 XGE0/0/15

163059919 Ingress 4124 1630599190, 1901494 XGE0/0/15

163059920 Ingress 4124 1630599200, 1912118 XGE0/0/15

2. View iFIT statistics on PE 2.

[PE2] display ifit statistic device-id 1 flow-id 2

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Egress 4124 1630599180, 1948185 XGE0/0/15

163059919 Egress 4124 1630599190, 1959405 XGE0/0/15

163059920 Egress 4120 1630599200, 1968503 XGE0/0/15

3. Packet loss occurs in period 163059920 by viewing iFIT statistics on the analyzer.

Example: Configuring iFIT on an EVPN VPLS over SRv6 network

Network configuration

As shown in Figure 12, user sites CE 1 and CE 2 connect to PE1 and PE 2, respectively through Ethernet interfaces. Configure CE 1 and CE 2 to achieve communicate through EVPN VPLS over SRv6 over the IPv6 backbone network.

PEs set up an SRv6 tunnel by advertising End.DT2M SIDs, End.DT2U SIDs, and End.DX2 SIDs to each other through BGP EVPN routes. On a PE, this SRv6 tunnel is used as a PW to encapsulate and forward Layer 2 data packets received from the local site and destined for a remote site.

Configure iFIT to monitor the occurrence of packet loss and packet delay value when the flow passes through the SRv6 tunnel.

Figure 12 Network diagram

‌

Prerequisites

1. Configure EVPN VPLS over SRv6. (Details not shown.)

For information about configuring EVPN VPLS over SRv6, see EVPN VPLS over SRv6 configuration in EVPN Configuration Guide.

2. Configure basic PTP or NTP functions for time synchronization between PE 1 and PE 2. (Details not shown.)

If the devices do not support PTP but support high-precision NTP, enable high-precision NTP on the local and remote devices.

If the devices do not support PTP or high-precision NTP, use the standard NTP. When the standard NTP is used, the device can measure packet loss rates, but the delay measurement is not accurate.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

Procedure

1. Configure PE 1:

a. Configure gRPC:

# Enable the gRPC service.

<PE1> system-view

[PE1] grpc enable

# Create a sensor group named test, and add sensor path ifit/flowstatistics/flowstatis.

[PE1] telemetry

[PE1-telemetry] sensor-group test

[PE1-telemetry-sensor-group-test] sensor path ifit/flowstatistics/flowstatistic depth 2

[PE1-telemetry-sensor-group-test] quit

# Create a destination group named collector1. Specify a collector that uses IPv6 address 10::10 and port number 50050.

[PE1-telemetry] destination-group collector1

[PE1-telemetry-destination-group-collector1] ipv6-address 10::10 port 50050

[PE1-telemetry-destination-group-collector1] quit

# Configure a subscription named A to bind sensor group test with destination group collector1. Set the sampling interval to 5 seconds.

[PE1-telemetry] subscription A

[PE1-telemetry-subscription-A] sensor-group test sample-interval 5

[PE1-telemetry-subscription-A] destination-group collector1

[PE1-telemetry-subscription-A] quit

[PE1-telemetry] quit

b. Configure iFIT:

# Enable the iFIT functionality.

[PE1] ifit enable

[PE1-ifit] device-id 1

# Configure instance a to monitor the service flow with VSI vsi and PeerLocator 200::.

[PE1-ifit] instance a

[PE1-ifit-instance-a] flow unidirection vsi vsi1 peer-locator 200:: 64

# Bind interface Ten-GigabitEthernet 0/0/15 to instance a.

[PE1-ifit-instance-a] bind interface ten-gigabitethernet 0/0/15

# Specify 10 seconds as the measurement period.

[PE1-ifit-instance-a] period 10

# Enable the iFIT functionality.

[PE1-ifit-instance-a] measure enable

[PE1-ifit-instance-a] quit

[PE1-ifit] quit

2. Configure PE 2:

a. Configure gRPC:

Use the same procedure to configure gRPC on PE 2 as you configure gRPC on PE 1.

b. Enable the iFIT functionality.

<PE2> system-view

[PE2] ifit enable

Verifying the configuration

1. View iFIT statistics on PE 1.

[PE1] display ifit statistic device-id 1 flow-id 2

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Ingress 4124 1630599180, 1889782 XGE0/0/15

163059919 Ingress 4124 1630599190, 1901494 XGE0/0/15

163059920 Ingress 4124 1630599200, 1912118 XGE0/0/15

2. View iFIT statistics on PE 2.

[PE2] display ifit statistic device-id 1 flow-id 2

Period ID Direction PktCount Timestamp(sec, nsec) Interface

163059918 Egress 4124 1630599180, 1948185 XGE0/0/15

163059919 Egress 4124 1630599190, 1959405 XGE0/0/15

163059920 Egress 4120 1630599200, 1968503 XGE0/0/15

3. Packet loss occurs in period 163059920 by viewing iFIT statistics on the analyzer.

Configuring iFIT tunnel-level measurement

Prerequisites

For information about configuring SRv6 TE policies, see SRv6 TE policies configuration in Segment Routing Configuration Guide.

Before you configure iFIT, gRPC configuration is not required. Make sure basic PTP or NTP functions are configured for the ingress and egress nodes to synchronize time. Both PTP and NTP can be used for time synchronization between devices. Time synchronization is accurate to sub-microseconds through PTP and to milliseconds through NTP.

· As a best practice, use PTP for time synchronization in an iFIT measurement network.

· If the devices do not support PTP, but support high-precision NTP, enable high-precision NTP on the local and remote devices.

· If the device does not support PTP or high-precision NTP for time synchronization, use the standard NTP. When the standard NTP is deployed, the device supports iFIT packet loss measurement and two-way delay measurement, but cannot perform one-way delay measurement accurately. iFIT application-level measurement supports measuring only packet loss rates and one-way delay. iFIT tunnel-level measurement supports measuring packet loss rates, one-way delay, and two-way delay depending on the associated SRv6 TE policy configuration.

For more information about PTP and NTP, see "Configuring PTP” and "Configuring NTP", respectively.

Restrictions and guidelines

To meet various customer networking requirements, iFIT supports measuring SRv6 tunnel quality in the following networking types:

· The egress node of an SRv6 tunnel supports iFIT measurement.

On such a network, set the SRv6 tunnel's egress node as the iFIT measurement egress node. Configure end-to-end measurement on the ingress node, measuring the quality of the entire SRv6 tunnel.

· The egress node of an SRv6 tunnel does not support iFIT measurement, but the penultimate hop is included in the SID list.

On such a network, use the iFIT-capable node closest to the original egress node of the SRv6 tunnel in the SID list as the new egress node of the SRv6 link. Use the quality of the link between the ingress node and this new egress node to represent the quality of the entire SRv6 tunnel. On this network, configure hop-by-hop measurement on the ingress node.

· To meet China Mobile's networking requirements, you can specify the node that is not in the SID list but closest to the egress node of an SRv6 tunnel and supports iFIT as the new egress node of the SRv6 link. Use the quality of the link between the ingress node and this new egress node to represent the quality of the entire SRv6 tunnel. On this network, configure hop-by-hop measurement on the ingress node of iFIT measurement and execute the trace-measure per-hop command on the egress node of iFIT measurement. In addition, make sure both the ingress and egress nodes are configured with the CMCC technical standards.

iFIT application-level measurement takes precedence over iFIT tunnel-level measurement.

Configuring the ingress node

1. Enter system view.

system-view

2. Enable iFIT and enter iFIT view.

ifit enable

By default, iFIT is disabled.

3. Specify the iFIT measurement mode. Use one of the following commands:

¡ instance instance-name

¡ measure mode { e2e | trace }

¡ quit

By default, end-to-end measurement is used.

If the egress node of the SRv6 tunnel supports iFIT, specify e2e as the measurement mode. If the egress node of the SRv6 tunnel does not support iFIT, specify trace as the measurement mode.

You can also configure the iFIT measurement mode from the SRv6 TE policy module. If the measurement mode specified by the SRv6 TE policy module is different from that by the measure mode command, the measurement mode specified by the SRv6 TE policy module takes effect. For more information, see SRv6 TE policy commands in Segment Routing Command Reference.

4. Specify the standards used by iFIT.

technical-standard { cmcc | telecom | unicom }

By default, iFIT uses the CMCC technical standards.

This command is not required for end-to-end measurement and will not impact the measurement results of end-to-end measurement.

To ensure correct measurement results of hop-by-hop measurement, you must execute this command and make sure the devices included in iFIT measurement are configured with the same technical standards.

5. Configure the device to act as iFIT Analyzer and enter iFIT Analyzer view.

work-mode analyzer

By default, the device does not act as iFIT Analyzer.

6. Configure iFIT Analyzer to only collect and report the iFIT measurement result for SRv6 paths.

service-type srv6-segment-list

By default, iFIT Analyzer does not collect or report the iFIT measurement result.

Configuring the egress node

1. Enter system view.

system-view

2. Enable iFIT and enter iFIT view.

ifit enable

By default, iFIT is disabled.

3. Specify the standards used by iFIT.

technical-standard { cmcc | telecom | unicom }

By default, iFIT uses the CMCC technical standards.

This command is not required for end-to-end measurement and will not impact the measurement results of end-to-end measurement.

To ensure correct measurement results of hop-by-hop measurement, you must execute this command and make sure the devices included in iFIT measurement are configured with the same technical standards.

4. (Optional.) Enable iFIT measurement on transit nodes in SRv6 runnels.

trace-measure per-hop [ te ]

By default, iFIT measurement is disabled on transit nodes in SRv6 tunnels.

Execute this command only when a device not in an SID list uses CMCC technical standards and must participate in iFIT measurement. This command does not take effect if other technical standards are used.

5. Configure the device to act as iFIT Collector and enter iFIT Collector view.

work-mode collector

By default, the device does not act as iFIT Collector.

6. Configure iFIT Collector to only collect and report the iFIT measurement result for SRv6 paths.

service-type srv6-segment-list

By default, iFIT Collector does not collect or report the iFIT measurement result.

Display and maintenance commands for iFIT tunnel-level measurement

You can execute the following display commands in any view:

To display global information of iFIT target flows, execute the following command:

display ifit global-information

To display information about the iFIT flow for the SRv6 TE policy, execute the following command:

display ifit srv6-segment-list [ segment-list-id ]

To display the iFIT measurement result from iFIT Analyzer, execute the following command:

display ifit statistic-type { one-way-delay | one-way-loss } { srv6-segment-list segment-list-id | device-id device-id flow-id flow-id }

14-Network Management and Monitoring Configuration Guide

Configuring iFIT

Instance

Measurement period

Coloring bit

iFIT application-level measurement

End-to-end measurement

Hop-by-hop measurement

Packet loss measurement mechanism

Packet delay measurement mechanism

Measurement data reporting mechanism

Working mechanism

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

Configuring a measurement period

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

Display and maintenance commands for iFIT application-level measurement

Network configuration

Prerequisites

Procedure

Verifying the configuration

Prerequisites

Procedure

Verifying the configuration

Network configuration

Prerequisites

Procedure

Verifying the configuration

Network configuration

Prerequisites

Procedure

Verifying the configuration

Network configuration

Prerequisites

Procedure

Verifying the configuration

Network configuration

Prerequisites

Procedure

Verifying the configuration

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us