NetAnalysis is a network traffic monitoring and analysis technology that performs in-depth analysis of service flows to obtain performance statistics about the service flows, such as packet loss rate and latency. NetAnalysis can send the analysis results to a NetAnalysis processor for analysis and display, which helps you monitor the network operation status and locate network faults.

NetAnalysis architecture

A typical NetAnalysis system consists of the following elements:

· NetAnalysis data exporter (NDE)—Uses an ACL to match the service flows to be analyzed and replicates them to a NetAnalysis processor.

· NetAnalysis processor (NAP)—Receives, processes, and analyzes service flows and outputs the results to a NetAnalysis data analyzer.

· NetAnalysis data analyzer (NDA)—Provides a Web interface for obtaining, displaying, and analyzing service flow data.

Typically, an NDE and an NAP are collocated on a device. As shown in Figure 1, when a service flow and its return traffic are forwarded along the same path, all devices on the path obtain bidirectional traffic of the service flow. You can configure NetAnalysis on these devices to analyze the flow to obtain performance statistics such as packet loss rate and latency.

Figure 1 NetAnalysis system

NetAnalysis workflow

As shown in Figure 2, NetAnalysis works as follows:

1. The NDE uses ACLs to match the service flows monitored by NetAnalysis and replicates the service flows to the NAP.

2. The NAP creates a flow table for each received service flow to analyze it if the service flow meets CM connection setup requirements. The NAP drops a service flow if the service flow does not meet those requirements or the NAP is overloaded. For more information about CM connection setup, see "CM connection setup."

3. The NAP encapsulates the analysis results into packets destined for the NDA and sends the packets to the NDA for analysis and display.

Figure 2 NetAnalysis workflow

Configuring NetAnalysis for RoCEv2 traffic

About NetAnalysis for RoCEv2 traffic

Remote direct memory access (RDMA) is a direct memory access technology used in InfiniBand networks to resolve the delay of data processing on servers. RDMA transmits data directly through the network from one system to another system without involving either one's operating system. CPUs do not process the data in transmission, which increases the bandwidth and reduces latency and resource usage.

RDMA over converged Ethernet version 2 (RoCEv2) is an RDMA technology used on Ethernet networks. RoCEv2 is widely used to reduce the latency caused by CPU processing and improve application performance in TCP/IP transmission for high-performance computing, distributed storage, and AI. In these scenarios, multiple nodes might send packets simultaneously to the same node, and the burst of traffic will congest queues or even cause packet loss on the destination node. As a result, the network latency increases, and traffic throughput drops. To resolve the issues, configure NetAnalysis to monitor the status of RoCEv2 networks by analyzing RoCEv2 flow data such as packet loss, latency, throughput, and forwarding path.

RoCEv2 packet format

RoCEv2 is a network layer protocol that enables Layer 3 communication between broadcast domains. RoCEv2 encapsulates packets based on the UDP encapsulation. Figure 3 shows the format of an RoCEv2 packet.

Figure 3 RoCEv2 packet format

An RoCEv2 packet contains the following fields:

· Ethernet header—Includes the source and destination MAC addresses.

· IP header—Includes the source and destination IP addresses.

· UDP header—Includes the source and destination port numbers. The destination port number is fixed at 4791.

· InfiniBand base transport header—Includes key fields monitored by NetAnalysis.

· IB payload.

· ICRC and FCS.

The InfiniBand base transport header contains the following fields:

· Opcode—RoCEv2 packet type indicating the operation mode. Available values for this field include the following:

¡ ConnectMsg—The packet is used for setting up an RoCEv2 connection. The connection is called a communication management (CM) connection. Devices in an RoCEv2 network transmit data packets through CM connections.

¡ Send—The packet is sent to the remote end without specifying where the receiver stores data.

¡ Write—The packet carries the address, key, and length of data to be written to the remote end.

¡ Read—The packet carries the address, key, and length of data to be read from the remote end. RoCEv2 packets of the Send, Write, and Read types are analyzed during throughput analysis.

¡ ACK—The packet is a response message returned by the receiver. Based on the ACK extended transport header unique to RoCEv2 ACK packets, an ACK packet can be one of the following types:

- Common ACK packet indicating that data is received successfully.

- NAK packet that indicates packet loss.

· Dest QP—Destination QP that identifies an RoCEv2 flow. This field is similar to the destination port number. It is a key value used by NetAnalysis to create an RoCEv2 flow table.

· PSN—Sequence number of the RoCEv2 packet. Packet loss is determined by checking whether the PSNs of packets are consecutive. If packet loss occurs, the receiver returns an NAK packet.

CM connection setup

RDMA sets up CM connections based on RoCE packets or TCP packets with custom fields. NetAnalysis can analyze the RoCE packets and TCP packets used for CM connection setup. The analysis process does not differ much between the packet types. The following information uses RoCE packet-based CM connection setup as an example.

Figure 4 shows the process of CM connection setup.

Figure 4 CM connection setup process

The CM connection setup procedure is as follows:

2. The client sends a Connect Request to the server to request RoCEv2 connection setup.

3. After receiving the Connect Request, the server replies with a Connect Reply. After receiving this packet, the client determines that an RoCEv2 connection has been set up with the server.

4. The client sends a ReadyToUse packet to the server. After receiving this packet, the server determines that the CM connection is set up successfully.

RoCEv2 flow analysis

After NetAnalysis is enabled to collect RoCEv2 traffic statistics on the device, the NDE issues rules for matching RoCEv2 packets based on the Opcode field. The NAP creates flow entries to form an RoCEv2 flow table based on the 4-tuple information in RoCEv2 connection setup packets. The 4-tuple information is the IP address of the client, IP address of the server, QP of the client, and QP of the server.

The NAP collects statistics about key fields in the flow table that is created based on the RoCEv2 data packets sent by the NDE, and analyzes the statistics to obtain characteristics of the RoCEv2 flow. You can view the statistics in the flow table on the device, and the statistics are exported to the NDA for display and analysis after the flow ages out.

RoCEv2 flow aging

The RoCEv2 flow aging mechanism allows the device to output flow statistics to the NDA. After NetAnalysis is enabled to analyze RoCEv2 traffic, the device saves flow statistics in the RoCEv2 cache. When an RoCEv2 flow ages out, the device exports the related flow statistics to the NDA and deletes the flow statistics from the RoCEv2 cache to save cache space.

Only inactive RoCEv2 flows age out. The device starts an inactive flow aging timer after receiving a packet for a flow. If the device has not received any packet for the flow when the timer expires, the flow ages out. To save cache space, the device will delete the sessions for inactive flows and notifies the NDA of the deletion events.

RoCEv2 flow filtering

NetAnalysis can use ACLs to filter the RoCEv2 flows that traverse the device. You can use this feature to collect statistics about the RoCEv2 flows of interest. For more information about ACLs, see ACL and QoS Configuration Guide.

NetAnalysis for RoCEv2 traffic tasks at a glance

To configure NetAnalysis to analyze RoCEv2 traffic, perform the following tasks:

1. Setting the mode of RoCEv2 traffic analysis

2. Enabling RoCEv2 traffic statistics collection

3. Enabling RoCEv2 packet loss analysis globally

4. (Optional.) Enabling AI ECN for RoCEv2 traffic statistics collection

5. (Optional.) Setting the interval for reporting RoCEv2 traffic statistics to the NDA

6. (Optional.) Setting the sampling rate for RoCEv2 packets

7. (Optional.) Setting the aging timer for inactive RoCEv2 flows

8. (Optional.) Enabling the NetAnalysis statistics feature for RoCEv2 traffic within a VXLAN tunnel

9. (Optional.) Enabling the global packet loss analysis feature for RoCEv2 traffic within a VXLAN tunnel

Setting the mode of RoCEv2 traffic analysis

About this task

As shown in Figure 5, NetAnalysis can use either of the following modes for RoCEv2 traffic analysis when multiple paths exist between an RoCEv2 client and an RoCEv2 server:

· Bidirectional mode—NetAnalysis monitors bidirectional traffic sent between the server and the client. Based on the 4-tuple information in CM connection setup packets, NetAnalysis can collect RoCEv2 traffic statistics based on sessions and provide the session-specific RTT and lost packet count.

· Unidirectional mode—NetAnalysis monitors the traffic sent from the client to the server to obtain the 3-tuple information used for creating RoCEv2 flow entries. In this mode, NetAnalysis collects RoCEv2 traffic statistics based on flows and provides only packet throughput information.

As a best practice to ensure correct RoCEv2 traffic analysis, configure the mode of RoCEv2 traffic analysis as follows:

· Enable bidirectional mode on the devices attached to the server and the client (Device C and Device D).

· Enable unidirectional mode on the intermediate devices (Device A and Device B).

Figure 5 Mode of RoCEv2 traffic analysis

Restrictions and guidelines

For NetAnalysis features to take effect, first set the mode of RoCEv2 traffic analysis.

When you change the mode of RoCEv2 traffic analysis, all NetAnalysis configuration and the RoCEv2 cache are cleared. Make sure you are fully aware of the impact of this operation when you perform it on a live network.

If you set the bidirectional mode, the ACL specified in the netanalysis rocev2 statistics command must match both client-to-server traffic and server-to-client traffic.

When you specify the session keyword in the netanalysis rocev2 mode command, the device analyzes RoCEv2 traffic based on session information (five-tuple and Opcode field) for NetAnalysis and packet loss, and sends the results to the NAP. In this case, you cannot configure NetAnalysis statistics or packet loss analysis separately on RoCEv2 traffic.

Procedure

1. Enter system view.

system-view

2. Set the mode of RoCEv2 traffic analysis.

netanalysis rocev2 mode { bidir | single } [ session ]

By default, RoCEv2 traffic analysis is disabled, and the mode of RoCEv2 traffic analysis is not set.

Enabling RoCEv2 traffic statistics collection

About this task

Perform this task to enable NetAnalysis to analyze RoCEv2 traffic and send the analysis results to the NAP. You can use an ACL to match the RoCEv2 traffic of interest. The deny or permit action in the ACL does not take effect. NetAnalysis supports the following rules of advanced ACLs:

· Rule 1—Matches the UDP protocol and destination IPv4 address.

· Rule 2—Matches the UDP protocol and source IPv4 address.

· Rule 3—Matches the UDP protocol and source and destination IPv4 addresses.

To ensure correct collection and reporting of RoCEv2 traffic statistics, use the rules supported by NetAnalysis. For more information about ACLs, see ACL and QoS Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enable RoCEv2 traffic statistics collection.

netanalysis rocev2 statistic { global | acl name acl-name }

By default, RoCEv2 traffic statistics collection is disabled.

Enabling RoCEv2 packet loss analysis globally

About this task

This task enables the device to perform RoCEv2 packet loss analysis for all received RoCEv2 packets.

Restrictions and guidelines

For RoCEv2 packet loss analysis to take effect, first enable bidirectional mode for RoCEv2 traffic analysis.

Procedure

1. Enter system view.

system-view

2. Enable RoCEv2 packet loss analysis globally.

netanalysis rocev2 drop global

By default, RoCEv2 packet loss analysis is disabled globally.

Enabling AI ECN for RoCEv2 traffic statistics collection

About this task

AI ECN allows the device to collect RoCEv2 traffic statistics on a per-session basis on the outgoing interfaces for RoCEv2 traffic and send the RoCEv2 traffic statistics to the NDA. Based on the RoCEv2 traffic statistics, the NDA automatically adjusts the ECN threshold for lossless queues to ensure low latency and high throughput for lossless traffic. For more information about ECN, see QoS configuration in ACL and QoS Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enable AI ECN for RoCEv2 traffic statistics collection.

netanalysis rocev2 ai-ecn enable

By default, AI ECN is disabled for RoCEv2 traffic statistics collection.

Setting the interval for reporting RoCEv2 traffic statistics to the NDA

About this task

Perform this task to adjust the interval at which the device reports RoCEv2 traffic statistics to the NDA.

Procedure

1. Enter system view.

system-view

2. Set the interval for reporting RoCEv2 traffic statistics to the NDA.

netanalysis rocev2 report-interval interval

By default, the device reports RoCEv2 traffic statistics to the NDA at an interval of 10 seconds.

Setting the sampling rate for RoCEv2 packets

About this task

A sampling rate allows the device to sample one packet from a number of RoCEv2 packets for analysis. For example, if you configure the sampling rate as 1000, the device samples 1 packet from 1000 RoCEv2 packets.

Restrictions and guidelines

For the sampling rate to take effect, first set the mode of RoCEv2 traffic analysis.

Procedure

1. Enter system view.

system-view

2. Set the sampling rate for RoCEv2 packets.

netanalysis rocev2 sampling-rate rate

By default, no sampling rate is set for RoCEv2 packets.

Setting the aging timer for inactive RoCEv2 flows

About this task

When an inactive RoCEv2 flow ages out, the device outputs the related traffic statistics to the NDA, deletes these traffic statistics from the RoCEv2 cache, and deletes the related flow entries.

Procedure

1. Enter system view.

system-view

2. Set the aging timer for inactive RoCEv2 flows.

netanalysis rocev2 timeout inactive seconds

By default, the aging timer for inactive RoCEv2 flows is set to 30 seconds.

Enabling the NetAnalysis statistics feature for RoCEv2 traffic within a VXLAN tunnel

About this task

To understand and optimize network performance, and to enhance the transmission speed and reliability, you can configure the NetAnalysis statistics feature for RoCEv2 traffic within a VXLAN tunnel.

By using this feature, you can perform NetAnalysis statistical analysis on RoCEv2 traffic at the VXLAN tunnel edges and intermediate nodes. The device characterizes each traffic flow's data, including volume, bandwidth, and latency, and uploads the analysis results.

Restrictions and guidelines

The specified RoCEv2 traffic is matched through ACL rules, but the designated deny or permit actions do not take effect. Currently, only the following advanced ACL rules are supported:

· rule1—Configures only the UDP protocol and destination IPv4 address.

· rule2—Configures only the UDP protocol and source IPv4 address.

· rule3—Configures only the UDP protocol, source IPv4 address, and destination IPv4 address.

Unsupported ACL rules do not take effect, preventing NAP from receiving the matched traffic flows. For more information about ACL rule configuration, see ACL and QoS Configuration Guide.

This feature only supports collecting statistics of VXLAN tunnel traffic within a data center network and does not support collecting statistics of VXLAN-DCI tunnel traffic between data centers.

Enabling the NetAnalysis statistics feature for RoCEv2 traffic on VXLAN tunnel intermediate nodes

1. Enter system view.

system-view

2. Enable the NetAnalysis statistics feature for RoCEv2 traffic on VXLAN tunnel intermediate nodes.

netanalysis rocev2 vxlan statistics { acl name acl-name | global }

By default, the NetAnalysis statistics feature is disabled for RoCEv2 traffic on VXLAN tunnel intermediate nodes.

Enabling the NetAnalysis statistics feature for RoCEv2 traffic at the VXLAN tunnel edges

1. Enter system view.

system-view

2. Enable the NetAnalysis statistics feature for RoCEv2 traffic at the VXLAN tunnel edges.

netanalysis rocev2 vxlan-ip statistics { acl name acl-name | global }

By default, the NetAnalysis statistics feature is disabled for RoCEv2 traffic at the VXLAN tunnel edges.

Enabling the global packet loss analysis feature for RoCEv2 traffic within a VXLAN tunnel

About this task

In a VXLAN network with RoCEv2, ensuring zero packet loss for network traffic is crucial. You can configure this feature to analyze packet loss for decapsulated RoCEv2 traffic at both intermediate and edge nodes within the VXLAN tunnel.

Restrictions and guidelines

For this feature to take effect, you must first set the mode of RoCEv2 traffic analysis to bidirectional.

This feature only supports packet loss analysis on RoCEv2 traffic in VXLAN tunnels within a data center network and does not support packet loss analysis on RoCEv2 traffic in VXLAN-DCI tunnels between data centers.

Enabling the global packet loss analysis feature for RoCEv2 traffic on VXLAN tunnel intermediate nodes

1. Enter system view.

system-view

2. Enable the global packet loss analysis feature for RoCEv2 traffic on VXLAN tunnel intermediate nodes.

netanalysis rocev2 vxlan drop global

By default, the global packet loss analysis feature is disabled for RoCEv2 traffic on VXLAN tunnel intermediate nodes.

Enabling the global packet loss analysis feature for RoCEv2 traffic at the VXLAN tunnel edges

1. Enter system view.

system-view

2. Enable the global packet loss analysis feature for RoCEv2 traffic at the VXLAN tunnel edges.

netanalysis rocev2 vxlan-ip drop global

By default, the global packet loss analysis feature is disabled for RoCEv2 traffic at the VXLAN tunnel edges.

Display and maintenance commands for NetAnalysis for RoCEv2 traffic

Execute display commands in any view and reset commands in user view.

Task	Command
Display configuration and status of the RoCEv2 cache.	display netanalysis rocev2 cache [ destination destination-ip \| dstvxlan-id dstvxlan-id \| source source-ip \| srcvxlan-id srcxlan-id ]*
Display RoCEv2 traffic statistics.	display netanalysis rocev2 statistics
Clear RoCEv2 traffic statistics.	reset netanalysis rocev2 statistics

NetAnalysis for RoCEv2 traffic configuration examples‌

Example: Configuring NetAnalysis to analyze RoCEv2 traffic

Network configuration

As shown in Figure 6, configure NetAnalysis on the device to analyze the bidirectional RoCEv2 traffic sent between the server and the client and output the RoCEv2 traffic statistics to the NDA.

Figure 6 Network diagram

‌

Procedure

1. Assign an IP address to each interface, as shown in Figure 6. (Details not shown.)

2. Configure NetAnalysis to analyze RoCEv2 traffic:

# Enable bidirectional RoCEv2 traffic analysis.

<Device> system-view

[Device] netanalysis rocev2 mode bidir

# Enable global RoCEv2 traffic statistics collection.

[Device] netanalysis rocev2 statistics global

Verifying the configuration

# Display configuration and status of the RoCEv2 cache after the device has been operating for a period of time.

[Device] display netanalysis rocev2 cache

NOTE:

S2D: source to destination D2S: destination to source

RTT: round trip time RPT: packet throughput in read mode

WPT: packet throughput in write mode SPT: packet throughput in send mode

I: input O: output L: local R: remote

NetAnalysis cache information:

-----------------------------------------------------------------------------

Flow created at Service type

Src IP Src QP S2D RTT S2D RPT S2D SPT/WPT

S2D NAK Pkts S2D Interface(I) S2D Interface(O)

S2D Src VXLAN ID S2D Dst VXLAN ID

Dst IP Dst QP D2S RTT D2S RPT D2S SPT/WPT

D2S NAK Pkts D2S Interface(I) D2S Interface(O)

D2S Src VXLAN ID D2S Dst VXLAN ID

-----------------------------------------------------------------------------

01/22/2019 09:08:15 RC

11.110.2.2 93309 50 11 11

2 Vlan-int100(L) Vlan-int200(L)

10 10

12.110.2.2 85353 50 11 11

8373 Vlan-int200(L) Vlan-int100(L)

10 10

# Display RoCEv2 traffic statistics.

[Device] display netanalysis rocev2 statistics

Last statistics resetting time: Never

--------------------------------------------------------------------------------

Received packets: 1833088

--------------------------------------------------------------------------------

Type

Active Aged Created Reported

(Sessions) (Sessions) (Sessions) (Sessions)

--------------------------------------------------------------------------------

RoCEv2

2 0 2 10

--------------------------------------------------------------------------------

Configuring NetAnalysis for UDP traffic

About NetAnalysis for UDP traffic

User Datagram Protocol (UDP) is a connectionless, datagram-oriented, simple transport layer protocol. Due to its low latency and high efficiency, UDP is widely used in applications that require high real-time performance, have relatively low data reliability requirements, or provides transmission reliability functions. Use NetAnalysis to perform intelligent traffic monitoring and analysis of UDP traffic, allowing analyzing path information of UDP traffic and monitoring the state of the UDP network.

UDP packet format

UDP is a transport layer protocol that transmits data by splitting it into datagrams and adding destination and source port numbers. UDP is encapsulated based on the IP protocol, and the packet format is shown in Figure 7.

Figure 7 UDP packet format

The meanings of each field in a UDP packet are as follows:

· Ethernet Header: Carries the source MAC address and the destination MAC address.

· IP Header: The main fields in the IP header include the following:

¡ Protocol: Indicates the protocol used by the data in the IP packet.

¡ Identification: Used to identify and distinguish different IP datagrams on the same host. Every time the host sends a UDP packet, the value of the Identification field increases by 1.

¡ Source IP.

¡ Destination IP.

· UDP Header: Includes the following fields:

¡ Source Port.

¡ Destination Port.

¡ Length: Length of the UDP packet. The minimum value is 8 bytes. If the length value is 8, it indicates that the UDP packet only contains the UDP header with no UDP data.

¡ Checksum: Used to verify the correctness of UDP packets during transmission.

· UDP Data: Data in the UDP packet.

UDP flow analysis

By segmenting the sequence numbers of UDP packets, a UDP flow can be divided into multiple blocks. NetAnalysis statistics collection for UDP traffic analyzes UDP flows based on the block granularity.

With NetAnalysis enabled for UDP traffic, the NAP analyzes all UDP packets contained in the first UDP Block received. It forms a flow entry based on the quintuple key values (source port ID , source IP address, destination port ID, destination IP address, and UDP protocol) to create a UDP flow table.

After establishing a UDP flow table based on the first UDP Block, the NAP compiles statistics on some key fields in the flow table using subsequent UDP Blocks sent by NDE. Based on the statistical result, the NAP obtains information about the UDP flow. You can view the statistics in the flow table on the device. The statistical result will be sent to NDA for further display and analysis after the flow ages out.

UDP flow aging

UDP flow aging is a method by which the device outputs flow statistical information to NDA. When NetAnalysis is enabled for UDP traffic, the device first stores the flow statistics in the NetAnalysis buffer. When the flow information stored on the device ages, the device sends the flow statistics to the NDA and clears the corresponding information in the buffer.

When the device continuously receives a UDP flow, the NetAnalysis statistics collection function for UDP traffic periodically outputs flow analysis results to NDA based on the Block granularity. If the inactive time of a UDP flow (time collapsed since the last packet was received) exceeds the set inactive aging time, the device considers the flow to be inactive (the flow has stopped). Then, the device sends the current flow table to NDA and deletes it from the buffer to release space for incoming flows. This process is called the aging of inactive flows.

UDP flow filtering

NetAnalysis statistics collection for UDP traffic can be used in conjunction with ACL. It can match UDP traffic according to ACL rules, so that NetAnalysis for UDP traffic analyzes only the packets matching the ACL. Use this method for NetAnalysis to analyze only specific traffic, better meeting diverse user statistical requirements. For more information about ACL, see ACL and QoS Configuration Guide.

NetAnalysis for UDP traffic tasks at a glance

To configure NetAnalysis to analyze UDP traffic, perform the following tasks:

1. Enabling UDP traffic statistics collection

2. (Optional.) Specifying the number of blocks for segment analysis of UDP traffic

3. (Optional.) Setting the aging timer for inactive UDP flow

Enabling UDP traffic statistics collection

About this task

Perform this task to enable NetAnalysis to analyze UDP traffic and send the analysis results to the NAP. You can use an ACL to match the UDP traffic of interest. The deny or permit action in the ACL does not take effect. NetAnalysis supports the following rules of advanced ACLs:

· Rule 1—Matches the UDP protocol and destination IPv4 address.

· Rule 2—Matches the UDP protocol and source IPv4 address.

· Rule 3—Matches the UDP protocol and source and destination IPv4 addresses.

· Rule 4—Matches the UDP protocol, source and destination IPv4 addresses, and UDP destination ports.

For more information about ACL, see ACL and QoS Configuration Guide.

Restrictions and guidelines

NetAnalysis statistics collection does not support RoCEv2 packets with a destination UDP port number of 4791.

Procedures

1. Enter system view.

system-view

2. Enable UDP traffic statistics collection.

netanalysis udp statistics [ vxlan { single-tagged | untagged } ] acl name acl-name inbound

By default, UDP traffic statistics collection is disabled.

Specifying the number of blocks for segment analysis of UDP traffic

About this task

NetAnalysis for UDP traffic performs analysis on UDP flows based on the Block granularity. Each UDP flow contains multiple UDP packets. With each packet sent, the Identification field increases by 1. The field value determines the UDP packet sequence number. In a UDP flow, UDP packets have sequence numbers ranging from 0 to 65535. By segmenting the sequence numbers of UDP packets, a UDP flow can be divided into multiple blocks. The NAP creates a flow table for the received UDP block and analyzes all UDP packets contained in the block.

Procedures

1. Enter system view.

system-view

2. Specify the number of blocks for segment analysis of UDP traffic.

netanalysis udp identification block block-number

By default, the number of blocks for segment analysis of UDP traffic is 256.

Setting the aging timer for inactive UDP flow

About this task

With NetAnalysis statistics collection for UDP traffic enabled, the device must also send the UDP flow table containing the statistical results to the specified NDA to complete further processing and visualization of the flow information. When an inactive UDP flow ages out, the device outputs the related traffic statistics to the NDA, deletes these traffic statistics from the UDP cache, and deletes the related flow entries.

Procedures

1. Enter system view.

system-view

2. Set the aging timer for inactive UDP flow.

netanalysis udp timeout inactive seconds

By default, the aging timer for inactive UDP flow is 30 seconds.

Display and maintenance commands for NetAnalysis for UDP traffic

Execute display commands in any view and reset commands in user view.

Task	Command
Display configuration and status of the UDP cache.	display netanalysis udp cache [ destination destination-ip \| interface interface-type interface-number \| source source-ip \| vni vxlan-id ]*
Display UDP traffic statistics.	display netanalysis udp statistics
Clear UDP traffic statistics.	reset netanalysis udp statistics

NetAnalysis for UDP traffic configuration examples‌

Example: Configuring NetAnalysis to analyze UDP traffic

Network configuration

As shown in Figure 8, configure NetAnalysis on the device to analyze the bidirectional UDP traffic sent between the server and the client and output the UDP traffic statistics to the NDA.

Figure 8 Network diagram

‌

Procedures

1. Assign an IP address to each interface, as shown in Figure 8. (Details not shown.)

2. Configure an ACL:

# Create an IPv4 advanced ACL numbered 3001 and named abc.

<Device> system-view

[Device] acl number 3001 name abc

# Create an ACL rule to allow UDP packets from 1.1.1.0/16 to 2.2.2.0/16 to pass.

[Device-acl-ipv4-adv-3001] rule permit udp source 1.1.1.0 0.0.255.255 destination 2.2.2.0 0.0.255.255

[Device-acl-ipv4-adv-3001] quit

3. Configure NetAnalysis to analyze UDP traffic:

# Enable UDP traffic analysis on packets matching the specified ACL in the inbound direction.

[Device] netanalysis udp statistics acl name abc inbound

Verifying the configuration

After the device has been running for a while, check the statistics of the UDP flow.

# Display configuration and status of the UDP cache after the device has been operating for a period of time.

<Device> display netanalysis udp cache source 1.1.1.2 destination 2.2.2.2

NetAnalysis cache information:

-----------------------------------------------------------------------------

Flow created at Direction

Src IP Dst IP Src Port Dst Port

Interface VNI Block Id Block Timestamp

Receive Packets Receive Bytes

-----------------------------------------------------------------------------

10/22/2023 09:08:15 inbound

1.1.1.2 2.2.2.2 1000 2000

Vlan-int100 N/A 10 100000000

5000 6000000

# Display UDP traffic statistics.

<Device> display netanalysis udp statistics

Last statistics resetting time: Never

--------------------------------------------------------------------------------

Received packets: 2833088

--------------------------------------------------------------------------------

Type

Active Aged Created Reported

(Flows) (Flows) (Flows) (Flows)

--------------------------------------------------------------------------------

UDP

4 0 2 20

--------------------------------------------------------------------------------

Configuring NetAnalysis unified flow analytics (UFA)

About NetAnalysis UFA

NetAnalysis UFA is a network traffic monitoring and analysis technology designed for comprehensive traffic across the network. It is suitable for in-depth analysis of entire network traffic, helping users quickly detect and accurately locate network failures, thereby improving network operation efficiency. When users need to perform in-depth analysis on TCP/UDP/VXLAN traffic in the network, they can enable this feature.

NetAnalysis UFA tasks at a glance

To configure NetAnalysis UFA, perform the following tasks:

1. Configuring NetAnalysis UFA

2. (Optional.) Configuring ISDF

3. (Optional.) Configuring unauthorized access detection

Configuring NetAnalysis UFA

About this task

After UFA is enabled, the device will perform NetAnalysis statistical analysis on incoming TCP/UDP/VXLAN traffic. The device establishes flow tables and collects traffic statistics based on information such as the five-tuple of the traffic, and then uploads the statistical results to a network analytics processor (NAP) for further processing. The NAP helps users gain a more comprehensive understanding of traffic patterns within the network by analyzing forwarding paths of data flows, identifying TCP anomalies, and investigating packet loss during forwarding.

The UFA feature supports full-flow analysis, In-situ Flow Information Telemetry (iFIT), Mirror on Drop (MOD), and congestion reporting. Full-flow analysis comprehensively records and analyzes all data flows in the network environment. It enables real-time or offline analysis of every data flow, providing detailed traffic statistics and insights. By monitoring all traffic, it identifies potential security threats such as abnormal traffic patterns and malicious attacks. iFIT is a real-time detection method applied during data flow transmission. It performs end-to-end and hop-by-hop measurements to monitor packet loss and latency between devices. MOD is used to monitor and identify packet loss during internal network data transmission. It diagnoses root causes such as forwarding anomalies and packet drops triggered by ACL deny rules. It reports drop reasons to the analyzer, and the analyzer takes corrective measures to optimize network performance and enhance data reliability. Congestion reporting monitors network congestion by enabling congestion detection on network nodes. It identifies congested nodes and paths in real time, and then provides traffic regulation recommendations or automatically adjusts traffic to alleviate congestion. Data on flows with excessive delay is reported to the FGLB and analyzer. The analyzer processes this data to generate traffic profiles, guiding service forwarding.

Restrictions and guidelines

If the following features (listed in descending order of priority) are configured, only the feature with the highest priority takes effect:

· NetAnalysis for UDP.

· NetAnalysis UFA.

· Flexible global load balancing (FGLB) adaptive routing.

· NetStream and IPv6 NetStream.

· MOD and flow group in delay monitoring mode.

For more information about FGLB adaptive routing, see adaptive routing in Layer 3—IP Routing Configuration Guide. For more information about NetStream and IPv6 NetStream, see "Configuring NetStream" and "Configuring IPv6 NetStream." For more information about MOD and flow groups, see Telemetry Configuration Guide.

When iFIT and INT are configured based on the same flow, iFIT takes precedence.

Procedure

1. Enter system view.

system-view

2. Enable unified flow analytics and enter UFA view.

netanalysis unified-flow

By default, UFA is disabled.

3. Set the aging time for the hardware flow table.

hardware-flow aging-time time-value

By default, the aging time for the hardware flow table is 500 milliseconds.

4. Set the export interval for the hardware flow table.

hardware-flow export-interval interval

By default, the export interval for the hardware flow table is 1000 milliseconds.

5. Set the delay threshold for the hardware flow table.

hardware-flow delay-threshold threshold-value

By default, the delay threshold for the hardware flow table is 10000 milliseconds.

By default, the delay threshold for the hardware flow table is 1000 milliseconds.

6. Set the aging time for the software flow table.

aging-time time-value

The default setting is 30 seconds.

7. Set the export interval for the software flow table.

export-interval interval

The default setting is 10 seconds.

8. Configure the iFIT coloring bit.

ifit color-flag tos-bit tos-bit

By default, no iFIT coloring bit is configured.

When this command is executed together with other commands that can change DSCP values (such as qos priority, priority-flow-control dscp-mapping, remark dscp, and so on), the iFIT configuration takes the highest priority and will override modifications to the DSCP values made by other configurations.

9. Set the iFIT measurement period.

ifit period period-time

The default setting is 30 seconds.

10. Enable packet drop reason reporting.

report-loss-reason enable

By default, packet drop reason reporting is enabled.

11. Create a UFA instance and enter its view.

instance instance-id name instance-name

By default, no UFA instances exist.

12. Configure traffic matching rules for the UFA instance.

flow ipv4 [ source-ip src-ip-address [ src-mask-length ] | destination-ip dest-ip-address [ dest-mask-length ] | protocol { { sctp | tcp | udp } [ source-port src-port-number ] [ destination-port dest-port-number ] | protocol-number } ]*

flow ipv6 [ source-ip src-ipv6-address [ src-prefix-length ] | destination-ip dest-ip-address [ dest-prefix-length ] | protocol { { sctp | tcp | udp } [ source-port src-port-number ] [ destination-port dest-port-number ] | protocol-number } ]*

flow any-ip

By default, no traffic matching rule is configured for a UFA instance.

13. Specify a flow type for the UFA instance.

flow-type { dynamic [ ip-pair ] | static }

By default, the flow type is dynamic flow.

14. Specify a role for an interface.

bind interface interface-type interface-number { egress | ingress | ingress-egress [ bidirectional-flow ] | transit [ bidirectional-flow ] }

By default, no role is specified for an interface.

15. Specify a default interface role.

bind all-interface { egress | ingress | ingress-egress [ bidirectional-flow ] | transit [ bidirectional-flow ] }

By default, no default interface role is specified.

16. Enable a measurement feature for the UFA instance.

activate { { flow-analysis | ifit | isdf-detect drop } * | mod }

By default, no measurement feature is enabled for a UFA instance.

17. Exclude an interface from iFIT.

exclude interface interface-type interface-number

By default, no interface is excluded from iFIT.

Configuring ISDF

About this task

When a network link fails, traditional routing convergence technologies based on the control plane (CP) dynamic routing protocols (for example, BGP and OSPF) can achieve convergence times in the hundreds of milliseconds. This cannot meet the stringent network performance requirements of services such as online transactions and autonomous driving. The ISDF technology can solve this problem.

Instant Silent-Fault Detection and Failover (ISDF) is a fully data plane (DP)-based fault detection and recovery technology. It represents a technological evolution from reliance on CP protocol interaction for convergence to real-time fault detection and rapid path switchover-based convergence in the DP. By using DP fault detection, remote fault advertisement, and fast-path switchover mechanisms, ISDF achieves millisecond-level network convergence, significantly improving network reliability and data transmission efficiency.

Procedure

1. Enter system view.

system-view

2. Enable UFA and enter UFA view.

netanalysis unified-flow

By default, UFA is disabled.

3. Set the measurement period for fault detection.

isdf-detect period period-time

The default setting is 3000 milliseconds.

4. Set the packet loss threshold for fault detection.

isdf-detect drop-threshold percent

The default setting is 30%.

Configuring unauthorized access detection

About this task

The mechanisms for detecting unauthorized hubs and routers are different.

· Detecting unauthorized hub—The device detects unauthorized hubs by identifying whether multiple IP addresses and MAC addresses exist on an interface. Typically, an interface corresponds to only one IP address and one MAC address. If the device detects multiple IP addresses and MAC addresses exist on an interface, it determines that unauthorized hubs are connected.

· Detecting unauthorized router—The device detects unauthorized routers by examining the TTL value. The initial TTL value is typically 128, 64, 255, 32, or 1. After a packet passes through a router, the TTL value decreases by 1. If the device detects that the TTL value of a packet is not the initial value, it determines that unauthorized routers are connected.

Restrictions and guidelines

After you execute the uad enable command in system view, all interfaces on the device are enabled with unauthorized access detection. If the device detects unauthorized hubs or routers, it notifies the controller. The controller takes an action on them.

After you execute the uad enable command in interface view, the corresponding interface is enabled with unauthorized access detection.

When unauthorized access detection is enabled globally, you can execute the undo uad enable command in interface view to disable unauthorized access detection on the corresponding interface. If you execute the undo uad enable command in system view, the uad enable command executed in interface view does not take effect.

Procedure

1. Enter system view.

system-view

2. Enable unauthorized access detection globally.

uad enable { unauthorized-hub | unauthorized-router }

By default, unauthorized access detection is disabled.

3. Enter Layer 3 interface view.

interface interface-type interface-number

4. Enable unauthorized access detection on the interface.

uad enable

By default, unauthorized access detection is enabled on an interface.

Display and maintenance commands for NetAnalysis UFA

Execute display commands in any view and reset commands in user view.

Task	Command
Display UFA flow table information.	display netanalysis unified-flow ipv4 [ destination-ip dest-ip-address [ dest-mask-length ] \| protocol { protocol-number \| { sctp \| tcp \| udp } [ destination-port dest-port-number \| source-port src-port-number ]* } \| source-ip src-ip-address [ src-mask-length ] \| vlan-id vlan-id-value \| vxlan-id vxlan-id-value ]* slot slot-number display netanalysis unified-flow ipv6 [ destination-ipv6 dest-ipv6-address [ dest-prefix-length ] \| protocol { protocol-number \| { sctp \| tcp \| udp } [ destination-port dest-port-number \| source-port src-port-number ]* } \| source-ipv6 src-ipv6-address [ src-prefix-length ] \| vlan-id vlan-id-value \| vxlan-id vxlan-id-value ]* [ slot slot-number ]
Display event information about silent faults.	display netanalysis unified-flow isdf-detect event-log
Clear UFA flow table information.	reset netanalysis unified-flow { ipv4 \| ipv6 } slot slot-number

‌

NetAnalysis UFA configuration examples

Example: Enabling iFIT

Network configuration

As shown in Figure 9, configure NetAnalysis UFA on Device A, Device B, and Device C to perform NetAnalysis statistical analysis on packets sent between the server and client. Enable iFIT on these devices to perform iFIT measurement on traffic between the server and client.

Figure 9 Network diagram

‌

Table 1 Interface label and interface name mappings

Interface label	Interface name
Interface1	Ten-GigabitEthernet1/0/1
Interface2	Ten-GigabitEthernet1/0/2

Configuring Device A

1. As shown in Figure 9, assign an IP address to each interface and configure route settings to ensure that these IP addresses are reachable. (Details not shown.)

2. Configure NetAnalysis UFA.

# Enable unified flow analytics and Configure the iFIT coloring bit and coloring period.

[DeviceA] netanalysis unified-flow

[DeviceA-netanalysis-unified-flow] ifit color-flag tos-bit 0

[DeviceA-netanalysis-unified-flow] ifit period 10

# Create a UFA instance, configure traffic matching rules for the UFA instance, and specify roles for interfaces. Then, enable iFIT for the UFA instance.

[DeviceA-netanalysis-unified-flow] instance 1 name a

[DeviceA-netanalysis-instance-1] flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

[DeviceA-netanalysis-instance-1] bind interface Ten-GigabitEthernet1/0/1 ingress

[DeviceA-netanalysis-instance-1] bind interface Ten-GigabitEthernet1/0/2 transit

[DeviceA-netanalysis-instance-1] activate ifit

Configuring Device B

1. As shown in Figure 9, assign an IP address to each interface and configure route settings to ensure that these IP addresses are reachable. (Details not shown.)

2. Configure NetAnalysis UFA.

# Enable unified flow analytics and Configure the iFIT coloring bit and coloring period.

[DeviceB] netanalysis unified-flow

[DeviceB-netanalysis-unified-flow] ifit color-flag tos-bit 0

[DeviceB-netanalysis-unified-flow] ifit period 10

# Create a UFA instance, configure traffic matching rules for the UFA instance, and specify roles for interfaces. Then, enable iFIT for the UFA instance.

[DeviceB-netanalysis-unified-flow] instance 1 name a

[DeviceB-netanalysis-instance-1] flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

[DeviceB-netanalysis-instance-1] bind all-interface transit

[DeviceB-netanalysis-instance-1] activate ifit

Configuring Device C

1. As shown in Figure 9, assign an IP address to each interface and configure route settings to ensure that these IP addresses are reachable. (Details not shown.)

2. Configure NetAnalysis UFA.

# Enable unified flow analytics and Configure the iFIT coloring bit and coloring period.

[DeviceC] netanalysis unified-flow

[DeviceC-netanalysis-unified-flow] ifit color-flag tos-bit 0

[DeviceC-netanalysis-unified-flow] ifit period 10

# Create a UFA instance, configure traffic matching rules for the UFA instance, and specify roles for interfaces. Then, enable iFIT for the UFA instance.

[DeviceC-netanalysis-unified-flow] instance 1 name a

[DeviceC-netanalysis-instance-1] flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

[DeviceC-netanalysis-instance-1] bind interface Ten-GigabitEthernet1/0/1 transit

[DeviceC-netanalysis-instance-1] bind interface Ten-GigabitEthernet1/0/2 egress

[DeviceC-netanalysis-instance-1] activate ifit

Verifying the configuration

# Display the IPv4 UFA flow table information on Device A after the device has been operating for a period of time.

<DeviceA> display netanalysis unified-flow ipv4

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source Port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

# Display the UFA flow table information for the specified source and destination IPv4 addresses on Device A after the device has been operating for a period of time.

<DeviceA> display netanalysis unified-flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

Direction : Inbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Ingress 174049063 1 20000 2560000 1740490630,0 Ten-GigabitEthernet1/0/1

Ingress 174049062 0 20006 2560007 1740490620,0 Ten-GigabitEthernet1/0/1

--------------------------------------------------------------------------------------------------------------

Direction : Outbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Transit 174049063 1 20000 2560000 1740490630,0 Ten-GigabitEthernet1/0/2

Transit 174049062 0 20005 2560006 1740490620,0 Ten-GigabitEthernet1/0/2

--------------------------------------------------------------------------------------------------------------

# Display the UFA flow table information for the specified source and destination IPv4 addresses on Device B after the device has been operating for a period of time.

<DeviceB> display netanalysis unified-flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

Direction : Inbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Transit 174049063 1 20000 2560000 1740490630,0 Ten-GigabitEthernet1/0/1

Transit 174049062 0 20006 2560007 1740490620,0 Ten-GigabitEthernet1/0/1

--------------------------------------------------------------------------------------------------------------

Direction : Outbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Transit 174049063 1 20000 2560000 1740490630,0 Ten-GigabitEthernet1/0/2

Transit 174049062 0 20005 2560006 1740490620,0 Ten-GigabitEthernet1/0/2

--------------------------------------------------------------------------------------------------------------

# Display the UFA flow table information for the specified source and destination IPv4 addresses on Device C after the device has been operating for a period of time.

<DeviceC> display netanalysis unified-flow ipv4 source-ip 1.1.1.1 destination-ip

4.4.4.2

Direction : Outbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Egress 174049438 0 20000 2560000 1740494380,0 Ten-GigabitEthernet1/0/2

Egress 174049437 1 20005 2560006 1740494370,0 Ten-GigabitEthernet1/0/2

--------------------------------------------------------------------------------------------------------------

Direction : Inbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Transit 174049438 0 20000 2560000 1740494380,0 Ten-GigabitEthernet1/0/1

Transit 174049437 1 20005 2560006 1740494370,0 Ten-GigabitEthernet1/0/1

--------------------------------------------------------------------------------------------------------------

Example: Enabling full-flow analysis and iFIT

Network configuration

As shown in Figure 10, configure NetAnalysis UFA on Device A, Device A, and Device C to perform NetAnalysis statistical analysis on packets sent between the server and client. Enable full-flow analysis and iFIT on these devices to perform in-depth analysis on traffic between the server and client.

Figure 10 Network diagram

‌

Table 2 Interface label and interface name mappings

Interface label	Interface name
Interface1	Ten-GigabitEthernet1/0/1
Interface2	Ten-GigabitEthernet1/0/2

Configuring Device A

1. As shown in Figure 10, assign an IP address to each interface and configure route settings to ensure that these IP addresses are reachable. (Details not shown.)

2. Configure NetAnalysis UFA.

# Enable unified flow analytics and Configure the iFIT coloring bit and coloring period.

[DeviceA] netanalysis unified-flow

[DeviceA-netanalysis-unified-flow] ifit color-flag tos-bit 0

[DeviceA-netanalysis-unified-flow] ifit period 10

# Create a UFA instance, configure traffic matching rules for the UFA instance, and specify roles for interfaces. Then, enable full-flow analysis and iFIT for the UFA instance.

[DeviceA-netanalysis-unified-flow] instance 1 name a

[DeviceA-netanalysis-instance-1] flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

[DeviceA-netanalysis-instance-1] bind interface Ten-GigabitEthernet1/0/1 ingress

[DeviceA-netanalysis-instance-1] bind interface Ten-GigabitEthernet1/0/2 transit

[DeviceA-netanalysis-instance-1] activate flow-analysis ifit

Configuring Device B

1. As shown in Figure 10, assign an IP address to each interface and configure route settings to ensure that these IP addresses are reachable. (Details not shown.)

2. Configure NetAnalysis UFA.

# Enable unified flow analytics and Configure the iFIT coloring bit and coloring period.

[DeviceB] netanalysis unified-flow

[DeviceB-netanalysis-unified-flow] ifit color-flag tos-bit 0

[DeviceB-netanalysis-unified-flow] ifit period 10

# Create a UFA instance, configure traffic matching rules for the UFA instance, and specify roles for interfaces. Then, enable full-flow analysis and iFIT for the UFA instance.

[DeviceB-netanalysis-unified-flow] instance 1 name a

[DeviceB-netanalysis-instance-1] flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

[DeviceB-netanalysis-instance-1] bind all-interface transit

[DeviceB-netanalysis-instance-1] activate flow-analysis ifit

Configuring Device C

1. As shown in Figure 10, assign an IP address to each interface and configure route settings to ensure that these IP addresses are reachable. (Details not shown.)

2. Configure NetAnalysis UFA.

# Enable unified flow analytics and Configure the iFIT coloring bit and coloring period.

[DeviceC] netanalysis unified-flow

[DeviceC-netanalysis-unified-flow] ifit color-flag tos-bit 0

[DeviceC-netanalysis-unified-flow] ifit period 10

# Create a UFA instance, configure traffic matching rules for the UFA instance, and specify roles for interfaces. Then, enable full-flow analysis and iFIT for the UFA instance.

[DeviceC-netanalysis-unified-flow] instance 1 name a

[DeviceC-netanalysis-instance-1] flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

[DeviceC-netanalysis-instance-1] bind interface Ten-GigabitEthernet1/0/1 transit

[DeviceC-netanalysis-instance-1] bind interface Ten-GigabitEthernet1/0/2 egress

[DeviceC-netanalysis-instance-1] activate flow-analysis ifit

Verifying the configuration

# Display the IPv4 UFA flow table information on Device A after the device has been operating for a period of time.

<DeviceA> display netanalysis unified-flow ipv4

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source Port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

# Display the UFA flow table information for the specified source and destination IPv4 addresses on Device A after the device has been operating for a period of time.

<DeviceA> display netanalysis unified-flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

Direction : Inbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

Start time (sec) : 2025-02-24 17:37:07 (1740418627)

End time (sec) : 2025-02-24 17:46:07 (1740419167)

Input packets : 20000

Input bytes : 2560000

Output packets : 20000

Output bytes : 2560000

Current TTL : 0

Min TTL : 253

Max TTL : 255

Discarded packets : 0

Discarded bytes : 0

Discard reason : 0

Abnomral reason : 0

Cross chip : True

Current delay : 1120ns

Average delay : 1152ns

Min delay : 1120ns

Max delay : 1184ns

Average jitter : 32ns

Min jitter : 0ns

Max jitter : 64ns

Interface name : Ten-GigabitEthernet1/0/1

Main interface name : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Ingress 174041916 0 40000 5120000 1740419160,0 Ten-GigabitEthernet1/0/1

Ingress 174041915 1 40000 5120000 1740419150,0 Ten-GigabitEthernet1/0/1

--------------------------------------------------------------------------------------------------------------

Direction : Outbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

Start time (sec) : 2025-02-24 17:37:07 (1740418627)

End time (sec) : 2025-02-24 17:46:07 (1740419167)

Input packets : 20000

Input bytes : 2560000

Output packets : 20000

Output bytes : 2560000

Current TTL : 0

Min TTL : 253

Max TTL : 255

Discarded packets : 0

Discarded bytes : 0

Discard reason : 0

Abnomral reason : 0

Cross chip : True

Current delay : 1120ns

Average delay : 1152ns

Min delay : 1120ns

Max delay : 1184ns

Average jitter : 32ns

Min jitter : 0ns

Max jitter : 64ns

Interface name : Ten-GigabitEthernet1/0/2

Main interface name : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Transit 174041916 0 40000 5120000 1740419160,0 Ten-GigabitEthernet1/0/2

Transit 174041915 1 40005 5120006 1740419150,0 Ten-GigabitEthernet1/0/2

--------------------------------------------------------------------------------------------------------------

# Display the UFA flow table information for the specified source and destination IPv4 addresses on Device B after the device has been operating for a period of time.

<DeviceB> display netanalysis unified-flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

Direction : Outbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

Start time (sec) : 2025-02-24 17:46:07 (1740419167)

End time (sec) : 2025-02-25 14:33:07 (1740493987)

Input packets : 20000

Input bytes : 2560000

Output packets : 20000

Output bytes : 2560000

Current TTL : 0

Min TTL : 253

Max TTL : 255

Discarded packets : 0

Discarded bytes : 0

Discard reason : 0

Abnomral reason : 0

Cross chip : True

Current delay : 1120ns

Average delay : 1152ns

Min delay : 1120ns

Max delay : 1184ns

Average jitter : 32ns

Min jitter : 0ns

Max jitter : 64ns

Interface name : Ten-GigabitEthernet1/0/2

Main interface name : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Transit 174049398 0 40000 5120000 1740493980,0 Ten-GigabitEthernet1/0/2

Transit 174049397 1 40005 5120006 1740493970,0 Ten-GigabitEthernet1/0/2

--------------------------------------------------------------------------------------------------------------

Direction : Inbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

Start time (sec) : 2025-02-24 17:46:07 (1740419167)

End time (sec) : 2025-02-25 14:33:07 (1740493987)

Input packets : 20000

Input bytes : 2560000

Output packets : 20000

Output bytes : 2560000

Current TTL : 0

Min TTL : 253

Max TTL : 255

Discarded packets : 0

Discarded bytes : 0

Discard reason : 0

Abnomral reason : 0

Cross chip : True

Current delay : 1120ns

Average delay : 1152ns

Min delay : 1120ns

Max delay : 1184ns

Average jitter : 32ns

Min jitter : 0ns

Max jitter : 64ns

Interface name : Ten-GigabitEthernet1/0/1

Main interface name : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Transit 174049398 0 40000 5120000 1740493980,0 Ten-GigabitEthernet1/0/1

Transit 174049397 1 40005 5120006 1740493970,0 Ten-GigabitEthernet1/0/1

--------------------------------------------------------------------------------------------------------------

# Display the UFA flow table information for the specified source and destination IPv4 addresses on Device C after the device has been operating for a period of time.

<DeviceC> display netanalysis unified-flow ipv4 source-ip 1.1.1.1 destination-ip 4.4.4.2

Direction : Outbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

Start time (sec) : 2025-02-24 17:46:07 (1740419167)

End time (sec) : 2025-02-25 14:33:07 (1740493987)

Input packets : 20000

Input bytes : 2560000

Output packets : 20000

Output bytes : 2560000

Current TTL : 0

Min TTL : 253

Max TTL : 255

Discarded packets : 0

Discarded bytes : 0

Discard reason : 0

Abnomral reason : 0

Cross chip : True

Current delay : 1120ns

Average delay : 1152ns

Min delay : 1120ns

Max delay : 1184ns

Average jitter : 32ns

Min jitter : 0ns

Max jitter : 64ns

Interface name : Ten-GigabitEthernet1/0/2

Main interface name : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Egress 174049398 0 40000 5120000 1740493980,0 Ten-GigabitEthernet1/0/2

Egress 174049397 1 40005 5120006 1740493970,0 Ten-GigabitEthernet1/0/2

--------------------------------------------------------------------------------------------------------------

Direction : Inbound

Instance ID : 1

Source IP/mask : 1.1.1.1/32

Destination IP/mask : 4.4.4.2/32

Source port : --

Destination port : --

Protocol : 253

VNI : --

VLAN : --

VPN instance : --

Start time (sec) : 2025-02-24 17:46:07 (1740419167)

End time (sec) : 2025-02-25 14:33:07 (1740493987)

Input packets : 20000

Input bytes : 2560000

Output packets : 20000

Output bytes : 2560000

Current TTL : 0

Min TTL : 253

Max TTL : 255

Discarded packets : 0

Discarded bytes : 0

Discard reason : 0

Abnomral reason : 0

Cross chip : True

Current delay : 1120ns

Average delay : 1152ns

Min delay : 1120ns

Max delay : 1184ns

Average jitter : 32ns

Min jitter : 0ns

Max jitter : 64ns

Interface name : Ten-GigabitEthernet1/0/1

Main interface name : --

--------------------------------------------------------------------------------------------------------------

Role Period ID Color Packet count Byte count Timestamp(sec,nsec) IfName

--------------------------------------------------------------------------------------------------------------

Transit 174049398 0 40000 5120000 1740493980,0 Ten-GigabitEthernet1/0/1

Transit 174049397 1 40005 5120006 1740493970,0 Ten-GigabitEthernet1/0/1

--------------------------------------------------------------------------------------------------------------

12-Network Management and Monitoring Configuration Guide

Configuring NetAnalysis

NetAnalysis workflow

Configuring NetAnalysis for RoCEv2 traffic

Setting the mode of RoCEv2 traffic analysis

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

Enabling AI ECN for RoCEv2 traffic statistics collection

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

Enabling the global packet loss analysis feature for RoCEv2 traffic at the VXLAN tunnel edges

Display and maintenance commands for NetAnalysis for RoCEv2 traffic

NetAnalysis for RoCEv2 traffic configuration examples‌

Network configuration

Procedure

Verifying the configuration

About this task

Restrictions and guidelines

Procedures

About this task

Procedures

About this task

Procedures

NetAnalysis for UDP traffic configuration examples‌

Network configuration

Procedures

Verifying the configuration

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

Network configuration

Configuring Device A

Configuring Device B

Configuring Device C

Verifying the configuration

Network configuration

Configuring Device A

Configuring Device B

Configuring Device C

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