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


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


Configuration Guide - Network Management and Monitoring

S2720, S5700, and S6720 V200R013C00

This document describes the configurations of Network Management and Monitoring, including SNMP, RMON, RMON2, LLDP, Performance Management, iPCA, NQA, Service Diagnosis, Mirroring, Packet Capture, NetStream, sFlow, TWAMP Light, NETCONF, ECA, Intelligent Video O&M, eMDI, and Network Deception.
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).
Interaction Process for Intelligent Video O&M

Interaction Process for Intelligent Video O&M

Basic Process

Intelligent video O&M aims to provide the user and application experience awareness capability for networks. CampusInsight, an intelligent O&M system, is adopted to intelligently associate changes to user and application experience with those to network status, thereby implementing visualization, association, diagnosis, rectification, and prediction of network faults. Intelligent video O&M saves manpower, reduces OPEX and fault self-healing time, and improves user experience.

The intelligent video O&M system supports data collection and reporting as well as data analysis and display. The system uses Telemetry technology to collect KPI information about network devices to obtain user experience indicators in seconds. User logs and alarms are reported through Syslog and Telemetry. CampusInsight, as an intelligent analysis platform, identifies faults by using big data analytics technology and machine learning algorithms, and displays services visually. For details about data collection using Telemetry technology, see Figure 15-1. The data collection process involves devices and a network management system (NMS).
  • The devices refer to switches. They receive data collection instructions from the NMS, sample data sources specified by the NMS, and send sampling data to the collector in the NMS.
  • The NMS is composed of a collector, an analyzer, and the Agile Controller-Campus.
    • Collector (CampusInsight): receives and stores monitoring data sent by devices.
    • Analyzer (CampusInsight): analyzes the monitoring data saved on the collector.
    • Agile Controller-Campus: configures and manages network devices, and sends data required by the collector. The controller is not required when CampusInsight is deployed in standalone mode.
In the independent deployment solution, the switch is connected to CampusInsight independently and reports data, and implements quality awareness based on the collected data. In the joint deployment solution, the switch is deployed together with the Agile Controller-Campus, and the Agile Controller-Campus automatically delivers configurations of the interconnection between the switch and CampusInsight to help the switch report data. In addition, the Agile Controller-Campus can dynamically deliver configurations to the switch based on CampusInsight requirements to track paths and locate faults.
Figure 15-1  Data collection using Telemetry technology
Telemetry technology has the following advantages over traditional data collection technologies (such as SNMP and CLI):
  • Data is collected in push mode instead of the pull mode. After data collection is configured, devices report data at the specified interval. This push mode improves data analysis timeliness, and avoids the impacts of the pull mode on the collector and network traffic.
  • Data is organized based on the YANG model, coded using the Google Protocol Buffer (GPB) protocol, and transmitted using the Google Remote Procedure Call (GRPC) protocol. This standard data model simplifies data analysis and monitoring, and allows multi-vendor devices to be managed compatibly and easily.

Reporting Device-Level KPI Statistics

Switches report device-level KPI statistics (such as port traffic statistics, packet loss rate, CPU usage, and PoE information) to CampusInsight through HTTP/2+Protobuf interfaces. CampusInsight analyzes and summarizes the information reported by the switches, and then displays the running status of the switches. According to the PoE information reported by switches, CampusInsight displays the PoE power supply information and issue list, as shown in Figure 15-2. This figure is only an example. For all O&M items supported by CampusInsight, see the CampusInsight V100R002C00 Product Documentation. For the KPI statistics that can be reported by switches to CampusInsight, see KPI Information That Switches Can Send to CampusInsight.
Figure 15-2  Issue analysis on CampusInsight

Reporting Audio and Video Information

If audio and video devices are connected through a switch to a network with audio and video traffic, the switch can monitor the setup and termination of sessions for media streams transmitted over SIP. Switches can also obtain audio quality parameters through Enhanced Media Delivery Index (eMDI) instances and detect dynamic indicators of media streams, thereby implementing real-time monitoring of session packets on network nodes and fast demarcation of faulty network segments. Then, switches can calculate the mean opinion scores (MOSs) of media streams based on the data packet loss rate monitored through the eMDI instance and the size of the largest packet lost in the specified period. Finally, the switches report the KPIs and MOSs of media streams monitored by eMDI to CampusInsight through HTTP/2+Protobuf interfaces. CampusInsight displays statistics about SIP session setup failures and successes and the number of abnormal offline sessions, as well as traffic trends and the session list, as shown in Figure 15-3.
Figure 15-3  Application analysis on CampusInsight

Reporting Log and Alarm Information

When a log or an alarm is generated on a switch, the switch reports the log or alarm to CampusInsight through Syslog or SNMP. As shown in Figure 15-4, CampusInsight displays the severity, name, and occurrence time of the log or alarm, helping network administrators locate and rectify faults. For the log and alarm information that can be reported by switches to CampusInsight, see Logs and Alarms that Can Be Reported by Switches to CampusInsight.
Figure 15-4  Alarm list on CampusInsight
Updated: 2019-04-20

Document ID: EDOC1100065680

Views: 52013

Downloads: 496

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