No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Configuration Guide - Network Management and Monitoring

CloudEngine 12800 and 12800E V200R005C10

This document describes the configurations of Network Management and Monitoring, including SNMP, RMON, LLDP, NQA, Service Diagnosis, Mirroring, Packet Capture, sFlow, and NETCONF.
Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Intelligent Traffic Analysis for TCP Flows

Intelligent Traffic Analysis for TCP Flows

When packets in a specified TCP flow pass through the same switch along the round-trip path, the intelligent traffic analysis module of the switch matches the TCP flow using ACL rules on the inbound interface of the switch, and creates a flow table for the matched packets for in-depth analysis. In this way, it is possible to obtain high-precision information such as the packet loss rate, delay, and TCP flow status.

TCP Flow Matching

  • Flow matching on the TDE

    The administrator configures a service flow to be detected on the TDE and delivers an ACL rule to match the service flow. The TDE sends matched packets to the TAP, and discards unmatched packets. Currently, only some advanced ACL rules are supported. The ACL rules that are not supported cannot be delivered, and the TAP cannot receive service flows that match unsupported ACL rules. The following rules are supported:
    • Rule 1: TCP + destination IPv4 address
    • Rule 2: TCP + destination IPv4 address + destination TCP port number
    • Rule 3: TCP + source IPv4 address + destination IPv4 address
    • Rule 4: TCP + source IPv4 address + destination IPv4 address + destination TCP port number

    Based on the configured ACL rule, the TDE delivers another rule for matching service flows in the opposite direction. In this way, bidirectional service flows matching the ACL rules are sent to the TAP for high-precision analysis of flow characteristics.

  • Flow matching on the TAP

    The TAP analyzes a received service flow. If the flow meets the requirements, the TAP creates a flow table and analyzes the flow. Otherwise, the TAP discards the flow. The TAP also discards the flow if it exceeds the processing capability of the TAP. Currently, the TAP can only perform flow creation and analysis for the following packets:
    • Common IPv4 TCP packets
    • VXLAN packets: The original packet is an IPv4 TCP packet, and the inner packet does not carry a VLAN tag.
    • VXLAN packets: The original packet is an IPv4 TCP packet, and the inner packet carries one VLAN tag.

TCP Flow Analysis

Intelligent traffic analysis for TCP flows is a technology that provides packet statistics collection and analysis based on flows. After receiving matched TCP packets, the TAP creates flows based on 5-tuple information in the packets and generates a flow table. The TAP then collects statistics on some key fields in the flow table, and analyzes the statistical results to obtain characteristics of the flow, that is, high-precision service flow information.

The statistics in a flow table are continuously collected within the flow lifetime, and can be viewed on the switch. In addition, the statistical results are exported to the TDA for further display and analysis after the flow is aged out.

  • Flow creation based on 5-tuple information

    Currently, intelligent traffic analysis for TCP flows supports flow creation based on 5-tuple information in service packets. The 5-tuple information uniquely identifies a session. The following is an example of 5-tuple: 192.168.1.1, 10000, TCP, 172.16.1.1, and 80. This 5-tuple indicates that the terminal with the IP address 192.168.1.1 and using port number 10000 establishes a TCP connection with the terminal with the IP address 172.16.1.1 and using port number 80.

    The following table lists the five keys in 5-tuple information for TCP flow creation in intelligent traffic analysis.

    Table 18-1 Keys in 5-tuple information for flow creation

    Key

    Description

    SPORT

    Specifies the source port number of a service flow.

    SIP

    Specifies the source IP address of a service flow. Currently, only IPv4 addresses are supported.

    • For a flow table created based on SYN packets, the SIP is the source IP address of the SYN packets.
    • For a flow table created based on TCP intermediate data packets, the SIP is the source IP address of the first packet received by the TAP.

    DPORT

    Specifies the destination port number of a service flow.

    DIP

    Specifies the destination IP address of a service flow. Currently, only IPv4 addresses are supported.

    Protocol

    Specifies the protocol type. Only TCP is supported.

  • Flow table characteristics

    After a TCP flow table is generated based on 5-tuple information, the TAP collects statistics on fields in the flow table and analyzes the characteristics of the flow.

    Table 18-2 lists the characteristics that can be analyzed by the TAP.

    Table 18-2 Characteristics that can be analyzed by the TAP

    Characteristic

    Description

    Number of discarded packets

    The TAP can collect the following statistics on packets discarded along the round-trip path:
    • Total number of discarded packets
    • Number of packets discarded on the upstream device

    Delay

    The TAP can calculate the round trip time (RTT) for packets sent and received along the round-trip path, respectively. The RTT is the average sliding delay calculated based on bidirectional packets. It is precise to the nearest microsecond.

    Number of packets

    The TAP can count the numbers of packets sent and received along the round-trip path, respectively.

    Flow status

    The TAP can analyze the TCP flow status in the current flow table. The flow status can be one of the following:

    • SYN status
    • SYN + ACK status
    • ACK status
    • TCP connection establishment status
    • TCP connection termination status

    Flow creation time

    Time when a TCP flow is created.

    Inbound interface of packets

    The TAP can identify the inbound interfaces of packets in both directions along the round-trip path, respectively.

    VXLAN Network Identifier (VNI)

    The TAP can identify the VNIs of packets in both directions along the round-trip path, respectively.

TCP Flow Export

Intelligent traffic analysis for TCP flows allows users to view service flow characteristics analyzed by the TAP. However, flow tables need to be sent to the TDA to provide visualized and user-friendly analysis results. Currently, only the FabricInsight can be used as the TDA.

Figure 18-3 shows the process of exporting a flow table. The intelligent traffic analysis flow tables that contain flow analysis results are first stored in the cache of the switch. When a flow table in the cache meets the aging conditions, the switch sends the flow table to the FabricInsight collector. The FabricInsight collector then summarizes the content and sends it to the FabricInsight analyzer for final processing and display of flow characteristics information.

Figure 18-3 Exporting a TCP flow table

An intelligent traffic analysis flow table can be exported to the FabricInsight collector only after the flow ages out. Specifically, when a flow table in the cache meets aging conditions or its aging time expires, the flow table is sent to the collector. The switch supports three aging modes for TCP flows: active aging, inactive aging, and FIN- or RST-based aging. When multiple aging modes are configured on the switch, a flow is aged out when it meets any aging condition.

  • Active aging

    A flow is collected within a specified period, starting from its first packet. When this specified period is reached, the switch exports analysis information about the flow to the TDA. This mode is called active aging. Active aging enables the switch to periodically export the statistics about flows that last for a long time.

  • Inactive aging

    If no record is added to the flow table of a specified flow within the inactive aging period (that is, the number of collected packets in the inactive aging period does not increase), the switch exports records of this flow to the TDA and deletes the records. This aging mode is called inactive aging.

    Inactive aging clears unnecessary entries in the intelligent traffic analysis cache so that the switch can fully leverage statistics entries. This mode requires the switch to export statistics about the flows that last for a short period. Once a flow stops, the switch exports flow statistics to save memory space.

  • FIN- or RST-based aging

    When a FIN or RST packet is added to a flow, the TCP connection for this flow is disconnected. In this case, the switch can immediately export the existing statistics in the flow table and delete the flow records to save space in the flow table.

    This aging mode is disabled by default. Flow analysis results are exported based on active aging or inactive aging.

In practice, the TAP uses the NetStream V9 template to define the statistical fields in an intelligent traffic analysis flow table. When a flow table meets aging conditions, the TAP adds the statistical fields in the flow table to the NetStream V9 template for encapsulation, instead of directly exporting the flow table to the FabricInsight collector. Then the forwarding chip sends the encapsulated packets to the collector based on routing entries.

Figure 18-4 shows the format of an exported packet in the intelligent traffic analysis system. Such a packet is encapsulated based on UDP, and includes the NetStream packet header in NetStream V9 format and one or more intelligent traffic analysis results. In addition, intelligent traffic analysis for TCP flows needs to be used together with the Layer 3 remote traffic mirroring function. Therefore, the source IP address of the exported packets in the intelligent traffic analysis system must be set to the IP address of the mirrored device in Layer 3 remote traffic mirroring.

Figure 18-4 Format of an exported packet in the intelligent traffic analysis system

After receiving the exported packets from the intelligent traffic analysis system, the FabricInsight collector summarizes the characteristics of service flows based on packet information such as source addresses, and sends the characteristics to the FabricInsight analyzer for visualized processing.

Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100075344

Views: 19778

Downloads: 22

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next