Configuration Guide - Network Management and Monitoring

CloudEngine 8800, 7800, 6800, and 5800 V200R005C10

This document describes the configurations of Network Management and Monitoring, including SNMP, RMON, NETCONF, OpenFlow, LLDP, NQA, Mirroring, Packet Capture, Packet Trace, Path and Connectivity Detection Configuration, NetStream, sFlow, and iPCA.

About This Document
SNMP Configuration
- Overview of SNMP
- Understanding SNMP
- Application Scenarios for SNMP
- Summary of SNMP Configuration Tasks
- Licensing Requirements and Limitations for SNMP
- Default Settings for SNMP
- Configuring a Device to Communicate with an NMS Through SNMPv1
- Configuring a Device to Communicate with an NMS Through SNMPv2c
- Configuring a Device to Communicate with an NMS Through SNMPv3 (USM User)
- Configuring a Device to Communicate with an NMS Through SNMPv3 (AAA Local User)
- Configuring a Device to Communicate with an NMS Through the SNMP Proxy
- Maintaining SNMP
  - Checking SNMP Packet Statistics
- Configuration Examples for SNMP
RMON Configuration
- Overview of RMON
- Understanding RMON
- Application Scenarios for RMON
- Licensing Requirements and Limitations for RMON
- Configuring RMON
- Configuration Examples for RMON
  - Example for Configuring RMON
NETCONF Configuration
- Overview of NETCONF
- Understanding NETCONF
- NETCONF Base Operations (Schema)
- NETCONF Standard Capabilities (Schema)
- NETCONF Extended Capabilities (Schema)
- YANG Model
- NETCONF Base Operations (YANG)
- NETCONF Standard Capabilities (YANG)
- NETCONF Extended Capabilities (YANG)
  - YANG-library
- Applicable Scenarios for NETCONF
- Licensing Requirements and Limitations for NETCONF
- Establishing Communication Between the NMS and a Device Using NETCONF
- Reporting Alarms Through NETCONF
  - NETCONF Alarm List
- Maintaining NETCONF
  - Enabling NETCONF Operation Log Query
- Configuration Examples for NETCONF
  - Example for Establishing Communication Between the NMS and a Device Using NETCONF
RESTCONF Configuration
- Overview of RESTCONF
- Understanding RESTCONF
- RESTCONF Operations Methods
- Application Scenarios for RESTCONF
  - RESTCONF-based Configuration and Management
- Licensing Requirements and Limitations for RESTCONF
- Configuring RESTCONF for Device Management
  - Configuring an HTTP Server
- Configuration Examples for RESTCONF
  - Example for Configuring RESTCONF-based Device Management
OpenFlow Agent Configuration
- Overview of OpenFlow
- Understanding OpenFlow
  - OpenFlow System Structure
  - OpenFlow Working Mechanism
- Application Scenarios for OpenFlow
- Licensing Requirements and Limitations for the OpenFlow Agent
- Configuring the OpenFlow Agent
- Maintaining the OpenFlow Agent
- Configuration Examples for the OpenFlow Agent
  - Example for Configuring the OpenFlow Agent
OVSDB Configuration
- Overview of OVSDB
- Understanding OVSDB
- OVSDB Schema Table
- Application Scenarios for OVSDB
- Licensing Requirements and Limitations for OVSDB
- VXLAN Deployment Solution (VMware NSX Controller Mode)
- Configuring OVSDB
- Configuration Examples for OVSDB
  - Example for Deploying VXLAN Layer 2 Gateway and BFD for VXLAN Through the VMware NSX Controller
LLDP Configuration
- Overview of LLDP
- Understanding LLDP
- Licensing Requirements and Limitations for LLDP
- Default Settings for LLDP
- Configuring Basic LLDP Functions
- Configuring the LLDP Alarm Function
- Maintaining LLDP
  - Clearing LLDP Statistics
  - Monitoring LLDP Status
- Configuration Examples for LLDP
NQA Configuration
- Overview of NQA
- Understanding NQA
- NQA Test Mechanisms
- NQA Association Mechanism
- Application Scenarios for NQA
- Summary of NQA Configuration Tasks
- Licensing Requirements and Limitations for NQA
- Configuring an NQA Test Instance
- Configuring the NQA Transmission Delay Threshold and Alarm Threshold
  - Configuring the Two-Way Transmission Delay Threshold
  - Configuring the One-Way Transmission Delay Threshold
- Configuring the Trap Function
- Scheduling an NQA Test Instance
- Maintaining NQA
  - Clearing NQA Test Statistics
- Configuration Examples for NQA
Mirroring Configuration
- Overview of Mirroring
- Understanding Mirroring
- Licensing Requirements and Limitations for Mirroring
- Configuring Mirroring
- Configuration Examples for Mirroring
Packet Capture Configuration
- Overview of Packet Capture
- Licensing Requirements and Limitations for Packet Capture
- Configuring the Device to Capture Forwarded Packets
- Configuring Capturing for Packets Sent to the CPU
- Configuration Examples for Packet Capture
  - Example for Configuring Packet Capture Function
Packet Trace Configuration
- Overview of Packet Trace
- Licensing Requirements and Limitations for Packet Trace
- Configuring Packet Trace
- Configuration Examples for Packet Trace
  - Example for Configuring Packet Trace
Discarded Packet Capture Configuration
- Overview of Discarded Packet Capture
- Application Scenarios for Discarded Packet Capture
- Licensing Requirements and Limitations for Discarded Packet Capture
- Configuring Discarded Packet Capture
- Configuration Examples for Discarded Packet Capture
  - Example for Configuring Discarded Packet Capture
Path and Connectivity Detection Configuration
- Overview of Path Detection
- Overview of Connectivity Detection
- Application Scenarios for Path/Connectivity Detection
- Licensing Requirements and Limitations for Path/Connectivity Detection
- Configuring Path Detection
- Configuring Connectivity Detection
NetStream Configuration
- Overview of NetStream
- Understanding NetStream
- Calculation of the NetStream Sampling Rate
- Application Scenarios for NetStream
- Licensing Requirements and Limitations for NetStream
- Configuring IPv4 Original Flow Statistics Export
- Configuring IPv6 Original Flow Statistics Export
- Configuring IPv4 Aggregation Flow Statistics Export
- Configuring IPv6 Aggregation Flow Statistics Export
- Configuring IPv4 Flexible Flow Statistics Export
- Configuring IPv6 Flexible Flow Statistics Export
- Configuring VXLAN Flexible Flow Statistics Export
- Configuring Layer 2 NetStream Flow Statistics Export
- Configuring NetStream Top Talkers
- Maintaining NetStream
  - Clearing NetStream Statistics
- Configuration Examples for NetStream
sFlow Configuration
- Overview of sFlow
- Understanding sFlow
- Application Scenarios for sFlow
- Licensing Requirements and Limitations for sFlow
- Default Settings for sFlow
- Configuring sFlow
- Maintaining sFlow
  - Checking sFlow Packet Statistics
  - Clearing sFlow Packet Statistics
- Configuration Examples for sFlow
  - Example for Configuring sFlow
iPCA Configuration
- Overview of iPCA
- Understanding iPCA
- Application Scenarios for iPCA
  - End-to-End Performance Measurement
  - Hop-by-Hop Performance Measurement
- Licensing Requirements and Limitations for iPCA
- Default Settings for iPCA
- Configuring iPCA to Implement End-to-End Performance Measurement
- Configuring iPCA to Implement Hop-by-Hop Performance Measurement
- Maintaining iPCA
  - Configuring the Condition of Triggering iPCA Performance Alarm
  - Monitoring the Running Status of iPCA
- Configuration Examples for iPCA
  - Example for Configuring iPCA End-to-End Performance Measurement
  - Example for Configuring iPCA Hop-by-Hop Performance Measurement
IOAM Configuration
- Overview of IOAM
- Understanding IOAM
- Licensing Requirements and Limitations for IOAM
- Configuring the Ingress Node
- Configuring Transit Node
- Configuring the Egress Node
- Configuration Examples for IOAM
  - Example for Configuring IOAM
Telemetry Configuration
- Overview of Telemetry
- Understanding Telemetry
- Application Scenarios for Telemetry
  - Telemetry Applications in a Traffic Adjustment Scenario
  - Telemetry Application in a Microburst Traffic Detection Scenario
- Licensing Requirements and Limitations for Telemetry
- Configuring Telemetry Static Subscription
- Configuring Telemetry Dynamic Subscription
- Configuration Examples for Telemetry
  - Example for Configuring Telemetry Static Subscription Based on gRPC
  - Example for Configuring Telemetry Dynamic Subscription Based on gRPC
Intelligent Traffic Analysis Configuration
- Overview of Intelligent Traffic Analysis
- Understanding Intelligent Traffic Analysis
  - Components of the Intelligent Traffic Analysis System
  - Intelligent Traffic Analysis for TCP Flows
- Application Scenario for Intelligent Traffic Analysis
- Licensing Requirements and Limitations for Intelligent Traffic Analysis
- Configuring Intelligent Traffic Analysis for TCP Flows
- Configuration Example for Intelligent Traffic Analysis
  - Example for Configuring Export of TCP Flow Analysis Results

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).

Overview of Path Detection

Purpose

With the fast development of network services, the sizes of data center networks sharply increase. Understanding the forwarding path of a specific flow or the path between two network devices will help operations and maintenance (O&M) personnel locate network faults quickly. The path detection function provided by switches works with the Agile Controller. A switch is able to identify the path detection packets delivered by the Agile Controller, calculate the outbound interfaces based on the MAC address table or routing table, send the outbound/inbound interfaces and path detection packets to the Agile Controller, and forward the path detection packets out. The Agile Controller calculates the entire path through which traffic passes based on the information reported by the switch. If network traffic is interrupted, O&M personnel can quickly locate the faulty device.

IPv4 Path Detection

IPv4 path detection is classified into the following types:

OAM-based IPv4 path detection: The device identifies whether the packets are detection packets based on the OAM and OAM PDU fields in the packets. To enable OAM-based IPv4 path detection, run the ip path detection enable command.
DSCP-based IPv4 path detection: The device identifies whether the packets are detection packets based on the DSCP value and OAM PDU field in the packets. To enable DSCP-based IPv4 path detection, run the ip path detection enable dscp dscp-value command.

NOTE:

The IPv4 path detection function can detect only the traffic path between any two devices when no tunnel is configured or a VXLAN tunnel is configured.

If DSCP-based IPv4 path detection is enabled, plan the DSCP value that is used to identify detection packets, and ensure that the DSCP values are not used by any other service traffic.

On the CE6880EI and CE5880EI, the IPv4 path detection function cannot identify ICMP detection packets. Therefore, you must select UDP or TCP when constructing detection packets.

CE8861EI, CE8868EI, CE6865EI, and CE6857EI do not support OAM-based IPv4 path detection.

OAM-based IPv4 path detection

The Agile Controller delivers common UDP/TCP/ICMP packets. Figure 13-1 shows the packet format. The device identifies path detection packets based on the detection flag (OAM) and detection data (OAM PDU). For the TCP packet, the 4-byte OAM is placed in the Acknowledgment Number field in the header. The length of the TCP packet header must be 20 bytes. The OAM PDU is placed in the Payload of the TCP packet. For the UDP/ICMP packet, the 4-byte OAM is placed in the Payload. The OAM PDU is also placed in the Payload. However, the length of (UDP/ICMP Header + OAM + other fields) is 20 bytes.

Figure 13-1 Path detection packet

In Figure 13-2, LSWs are ordinary Layer 3 switches of an IP network, the Spines are the VXLAN Layer 3 gateways, the Switches perform transparent transmission on the VXLAN, the Leaves are the VXLAN Layer 2 gateways, and the point of delivery (POD) areas are two physical networks of the data center. The O&M personnel need to detect the path from VM1 to VM3. Assume that the path is Leaf2 -> Switch1 -> Spine1 -> LSW1 -> Spine3 -> Switch3 -> Leaf6 -> VM3. The detection process is as follows:

The Agile Controller creates a path detection packet based on configuration. The source IP address is the IP address of VM1, and the destination IP address is the IP address of VM3.
The Agile Controller encapsulates the path detection packet into a Packet-out message, and sends the Packet-out message to Leaf2.
After receiving the Packet-out message, Leaf2 identifies the detection flag in the path detection packet, calculates the outbound interface based on the MAC address table, and sends the Packet-in message carrying the outbound interface, inbound interface, and path detection packet to the Agile Controller. Then Leaf2 encapsulates the path detection packet into the VXLAN packet and sends the VXLAN packet to Switch1.
After receiving the VXLAN packet, Switch1 calculates the outbound interface based on MAC address table, and sends a Packet-in message carrying the outbound interface, inbound interface, and VXLAN packet to the Agile Controller. Then Switch1 transparently transmit the VXLAN packet to Spine1.
After receiving the VXLAN packet, Spine1 calculates the outbound interface based on routing table, and sends a Packet-in message carrying the outbound interface, inbound interface, and VXLAN packet to the Agile Controller. Then Spine1 decapsulates the VXLAN packet and sends the path detection packet to LSW1.
After receiving the path detection packet, LSW1 calculates the outbound interface based on routing table, and sends a Packet-in message carrying the outbound interface, inbound interface, and path detection packet to the Agile Controller. Then LSW1 forwards the path detection packet to Spine3.
After receiving the path detection packet, Spine3 calculates the outbound interface based on routing table, and sends a Packet-in message carrying the outbound interface, inbound interface, and path detection packet to the Agile Controller. Then Spine3 encapsulates the path detection packet into the VXLAN packet and sends the VXLAN packet to Switch3.
After receiving the VXLAN packet, Switch3 repeats the operations performed by Switch1.
After receiving the VXLAN packet, Leaf6 calculates the outbound interface based on MAC address table, and sends a Packet-in message carrying the outbound interface, inbound interface, and VXLAN packet to the Agile Controller. Then Leaf6 decapsulates the VXLAN packet and sends the path detection packet to VM3.
The Agile Controller calculates the entire path from VM1 to VM3 based on the information returned by Leaf2, Switch1, Spine1, LSW1, Spine3, Switch3, and Leaf6.

Figure 13-2 Path detection diagram

DSCP-based IPv4 path detection

The Agile Controller delivers common UDP/TCP/ICMP packets. Figure 13-3 shows the packet format. The device identifies path detection packets based on the detection flag (DSCP value) and detection data (OAM PDU). The process of DSCP-based IPv4 path detection is similar to that of OAM-based IPv4 path detection, and is not mentioned here.

Figure 13-3 DSCP-based IPv4 path detection packet

DSCP-based IPv6 Path Detection

The Agile Controller delivers common IPv6 UDP/TCP/ICMP packets. Figure 13-4 shows the packet format. The device identifies path detection packets based on the detection flag (DSCP value) and detection data (OAM PDU). The DSCP-based IPv6 path detection process is similar to the OAM-based IPv4 path detection process and is not mentioned here.

NOTE:

DSCP-based IPv6 path detection can only be used on the IPv6 over IPv4 VXLAN network.

If DSCP-based IPv6 path detection is enabled, plan the DSCP value that is used to identify detection packets, and ensure that the DSCP value is not used by any other service traffic.

Figure 13-4 DSCP-based IPv6 path detection packet

IPv6 VXLAN Path Detection

The Agile Controller delivers IPv6 VXLAN packets for path detection. Figure 13-5 shows the packet format. Switches identify IPv6 VXLAN detection packets based on the OAM PDU and the VXLAN Flag in the IPv6 VXLAN packet header (which is 00000001). The inner-layer L2 frame of IPv6 VXLAN detection packets uses the Pseudo-Header and OAM PDU.

NOTE:

IPv6 VXLAN path detection can detect only traffic paths between VTEPs, not VMs.

Figure 13-5 IPv6 VXLAN detection packet

Table 13-1 Fields in the IPv6 VXLAN detection packet

Field	Description
OAM PDU	Detection data.
Pseudo-Header	Pseudo header, which is 128 bytes long. This field is not required for path detection.
VXLAN Header	VXLAN Flag: 8 bits, which is 00000001. The VXLAN Flag identifies IPv6 VXLAN detection packets. Reserved (24 bits): reserved field. VNI: VXLAN Network Identifier (24 bits). Reserved (8 bits): reserved field.
Out UDP Header	UDP packet header used to encapsulate the VXLAN packet. The UDP port number is 4789.
Out IPv6 Header	IPv6 packet header in the VXLAN packet.
Out Ethernet Header	Ethernet header in the VXLAN packet.

In Figure 13-6, the Agile Controller has set up OpenFlow and NETCONF connections with spine and leaf switches. The O&M personnel need to detect all paths between VTEP1 and VTEP2. Assume that the paths include Leaf1 -> Spine1 -> Leaf3 and Leaf2 -> Spine2 -> Leaf4. The following describes the process of detecting the path Leaf1 -> Spine1 -> Leaf3:

The Agile Controller creates an IPv6 VXLAN detection packet based on user configuration. The source IP address is the IP address of VTEP1, and the destination IP address is the IP address of VTEP2.
The Agile Controller encapsulates the IPv6 VXLAN detection packet into a Packet-out message, and sends the Packet-out message to Leaf1.
After receiving the Packet-out message, Leaf1 identifies the detection flag in the IPv6 VXLAN detection packet, calculates the outbound interface by searching for related entries based on the IP quintuple information, and sends the Packet-in message carrying the outbound interface, inbound interface, and IPv6 VXLAN detection packet to the Agile Controller. Leaf1 then sends the IPv6 VXLAN detection packet to Spine1.
After receiving the IPv6 VXLAN detection packet, Spine1 calculates the outbound interface by searching for related entries based on the IP quintuple information, and sends a Packet-in message carrying the outbound interface, inbound interface, and IPv6 VXLAN detection packet to the Agile Controller. Spine1 then sends the IPv6 VXLAN detection packet to Leaf3.
After receiving the IPv6 VXLAN detection packet, Leaf3 finds that the destination IP address of the packet is its own IP address, and then sends a Packet-in message carrying the inbound interface and IPv6 VXLAN detection packet to the Agile controller. Because the destination IP address of the IPv6 VXLAN detection packet is the IP address of Leaf3, the packet will not be forwarded.
The Agile Controller calculates the entire path from VTEP1 to VTEP2 based on the information returned by Leaf1, Spine1, and Leaf3.

Figure 13-6 IPv6 VXLAN path detection

Translation

简体中文

Download

Updated: 2019-04-20

Document ID: EDOC1100075365

Downloads: 129

Average rating:

This Document Applies to these Products

Related Version

Reminder

Configuration Guide - Network Management and Monitoring

CloudEngine 8800, 7800, 6800, and 5800 V200R005C10

This document describes the configurations of Network Management and Monitoring, including SNMP, RMON, NETCONF, OpenFlow, LLDP, NQA, Mirroring, Packet Capture, Packet Trace, Path and Connectivity Detection Configuration, NetStream, sFlow, and iPCA.