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.


NE20E-S2 V800R010C10SPC500 Feature Description - Network Reliability 01

This is NE20E-S2 V800R010C10SPC500 Feature Description - Network Reliability
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).


To minimize the impact of device faults on services and improve network availability, a network device must be able to quickly detect communication faults with adjacent devices. Measures can then be taken to promptly rectify the faults to ensure service continuity.

On a live network, link faults can be detected using either of the following mechanisms:
  • Hardware detection: For example, the Synchronous Digital Hierarchy (SDH) alarm function can be used to detect link faults. Hardware fault detection mechanisms are fast, but cannot be used in all scenarios by all media.

  • Slow Hello mechanism: It usually refers to the Hello mechanism of a routing protocol. The detection rate for slow Hello mechanisms is measured in seconds. Detection times of one second or more can result in large losses if data is being transmitted at gigabit rates. For delay-sensitive services, such as voice, a delay of one second or more is also unacceptable.

  • Other detection mechanisms: Different protocols or manufacturers may provide proprietary detection mechanisms, but it is difficult to deploy proprietary mechanisms when systems are interconnected for interworking.

Bidirectional Forwarding Detection (BFD) is a unified detection mechanism that can detect a fault in milliseconds on a network. BFD is compatible with all types of transmission media and protocols. BFD implements the fault detection function by establishing a BFD session and periodically sending BFD control packets along the path between them. If one system does not receive BFD control packets within a specified period, the system regards it as a fault occurrence on the path.

In multicast scenarios, if the DR on a shared network segment is faulty and the neighbor relationship times out, other PIM neighbors start a new DR election. Consequently, multicast data transmission is interrupted for a few seconds.

BFD for PIM can detect a link's status on a shared network segment within milliseconds and respond quickly to a fault on a PIM neighbor. If the interface configured with BFD for PIM does not receive any BFD packets from the current DR within a configured detection period, the interface considers that a fault has occurred on the designated router (DR). The BFD module notifies the route management (RM) module of the session status, and the RM module notifies the PIM module. Then, the PIM module triggers a new DR election immediately rather than waiting for the neighbor relationship to time out. This minimizes service interruptions and improves the multicast network reliability.
Currently, BFD for PIM can be used on both IPv4 PIM-SM/Source-Specific Multicast (SSM) and IPv6 PIM-SM/SSM networks.
Figure 2-26 BFD for PIM

As shown in Figure 2-26, on the shared network segment where user hosts reside, a PIM BFD session is set up between the downstream interface Port 2 of Device B and the downstream interface Port 1 of Device C. Both ports send BFD packets to detect the status of the link between them.

Port 2 of Device B is elected as a DR for forwarding multicast data to the receiver. If Port 2 fails, BFD immediately notifies the RM module of the session status and the RM module then notifies the PIM module. The PIM module triggers a new DR election. Port 1 of Device C is then elected as a new DR to forward multicast data to the receiver.

Updated: 2019-01-02

Document ID: EDOC1100055473

Views: 13198

Downloads: 4

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