NE disconnection principles


1. Only the primary gateway is configured.
The NMS sends detection frames of all NEs to be managed to the primary gateway at an interval of 1 minute. (The interval can be modified in the configuration file on the NMS. The default interval is 1 minute.) If an NE responds to the corresponding detection frame within 1 minute, the NMS determines that the NE is reachable. If the NMS does not receive any response after sending two consecutive detection frames to an NE (the maximum number of NE detection frames sent by the NMS is configurable and the default value is 3), the NMS reports an NE disconnection event when sending the next (third) NE detection frame. It can be concluded that an NE may have been inaccessible for about 2 minutes when the NE disconnection event is reported by the NMS.
2. Both primary and secondary gateways are configured.
The NMS sends NE detection frames to the primary gateway at an interval of 1 minute but does not send NE detection frames to the secondary gateway. If each NE responds to the corresponding detection frame within 1 minute, it indicates that the primary gateway can reach all NEs and the NEs are reachable by the NMS. If the NMS does not receive any response after sending two consecutive detection frames to one or multiple NEs through the primary gateway, the NMS determines that the NEs are unreachable through the primary gateway. Then, the NMS sends the next NE detection frame to both the primary and secondary gateways concurrently, and reports an NE disconnection event. If there is a response to the NE detection frame sent through the secondary gateway, it indicates that the NE is reachable through the secondary gateway. If the path through the primary gateway is not restored, the NMS always sends NE detection frames through the secondary gateway until the primary gateway is restored.

Other related questions:
Principles of HSB
The AR supports the HSB function. HSB implementation involves data synchronization and traffic switching. Data synchronization is performed to ensure consistent information on the master and backup devices when the two devices are working normally. Traffic switching is performed to ensure non-stop service forwarding when the master device fails or recovers. The principle for data synchronization is to establish active and standby channels between devices that back up each other. Session entries of the master device can be synchronized to the backup device through the channel at one time, in real time, or periodically. The principle for traffic switching is based on negotiation between the master device and the backup device using VRRP. When the master device fails, a new master device is elected based on VRRP priorities and the traffic is switched to the master device. For details, see “HSB Configuration�?in AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600 V200R008 CLI-based Configuration Guide - Reliability.

OTN principles
An OTN is a network consisting of optical NEs that are connected through optical fibers. It can transmit, multiplex, route, manage, monitor, and protect client signals on optical channels. A main feature of the OTN is client independence. That is, the transmission and configuration of any digital signals are irrelevant to the features of a client. OTN has the following advantages over traditional SDH: More powerful forward error correction, Tandem connection monitoring (TCM) at more levels, transparent transmission of client signals, and scalable switching capacity.

Principle of BSSID generation
Centralized BSSID management allows an AC to automatically assign a unique BSSID to each VAP. You only need to configure a carrier ID and an AC ID for an AC. Then the AC automatically assigns a BSSID to each VAP. The BSSID allows you to rapidly locate a VAP on a network. A BSSID is generated based on the AC ID, carrier ID, and WLAN ID.

What is the working principle of Streaming?
A Streaming topology can be developed and compressed into a JAR file by using Storm APIs or referring to the CQL syntax manual. After the topology is submitted to the Streaming cluster, Nimbus automatically assigns it to the Supervisor node for processing. The topology logs can be viewed on the UI through the port provided by Logviewer.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top