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

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
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).
Application Scenarios

Application Scenarios

This section describes the applicable scenario of BFD.

BFD for IP Links

You can create a single-hop or multi-hop BFD session on an IP link to rapidly detect faults:

  • Single-hop BFD detects IP connectivity of the forwarding link between two directly connected systems.

  • Multi-hop BFD detects IP connectivity of paths between two indirectly connected systems. These paths may span multiple hops or overlap.

Application

Typical application 1

As shown in Figure 11-8, a BFD session detects a single-hop path between two devices and the BFD session is bound to the outbound interface.

Figure 11-8 Single-hop BFD for IP links

Typical application 2

As shown in Figure 11-9, a BFD session detects a multi-hop path between SwitchA and SwitchC, and the BFD session is bound to the peer IP address but not the outbound interface.

Figure 11-9 Multi-hop BFD for IP links

BFD for Static Routes

Unlike dynamic routing protocols, static routes do not have a dedicated detection mechanism. After a fault occurs, static routes cannot detect the fault, and the network administrator must delete the corresponding static route. BFD for static routes enables a BFD session to detect the status of the link of the static route on the public network.

Each static route can be bound to a BFD session. When a BFD session bound to a static route detects a fault (for example, the link changes from Up to Down) on a link, BFD reports the fault to the routing management module (RM). Then, the RM configures the route as inactive, indicating that the route is unavailable and deleted from the IP routing table. When the BFD session bound to the static route is successfully set up or the link of the static route recovers (that is, the link changes from Down to Up), BFD reports the event to the RM and the RM configures the static route as active, indicating that the route is available and added to the IP routing table.

BFD for OSPF

A link failure or topology change may lead to route recalculation; therefore, convergence of routing protocols must be shortened as much as possible to improve network performance. A feasible solution is to rapidly detect link faults and immediately notify routing protocols of the faults.

BFD for OSPF associates a BFD session with OSPF. The BFD session rapidly detects a link fault and notifies OSPF of the fault. By doing this, OSPF quickly responds to the network topology change. Table 11-6 lists OSPF convergence speed.

Table 11-6 OSPF convergence speed

Whether a BFD Session Is Bound

Link Fault Detection Mechanism

Convergence Speed

No

Timeout of the OSPF Hello keepalive timer

At the second level

Yes

BFD session in Down state

At the millisecond level
Application
Figure 11-10 BFD for OSPF

As shown in Figure 11-10, SwitchA establishes OSPF neighbor relationships with SwitchC and SwitchD. The outbound interface in the route from SwitchA to SwitchB is Interface 1. Packets from SwithA traverse SwitchC, and then reach SwitchB. When the OSPF neighbor is in Full state, the system instructs BFD to create a BFD session.

When a fault occurs on the link between SwitchA and SwitchC, the BFD session detects the fault and notifies SwitchA. SwitchA processes the neighbor Down event and recalculates the route. Then, the new outbound interface in the route is Interface 2. Packets from SwitchA traverse SwitchD, and then reach SwitchB.

BFD for IS-IS

Generally, the interval at which Intermediate System to Intermediate System (IS-IS) sends Hello packets is 10s. The holdtime of neighbors is three times the interval at which Hello packets are sent. If the Switch Module does not receive a Hello packet from its neighbor within the holddown time, the Switch Module deletes the neighbor relationship. That is, the Switch Module detects neighbor faults in seconds. The second-level detection leads to the loss of a large number of packets on a high-speed network.

In BFD for IS-IS, BFD session setup is dynamically triggered by IS-IS but not configured manually. When detecting a fault, the BFD session notifies IS-IS through the RM. Then, IS-IS processes the neighbor Down event and rapidly updates the link state PDU (LSP) and performs the partial route calculation (PRC). This speeds up IS-IS route convergence. BFD is not used to replace the Hello mechanism of IS-IS. Instead, BFD works with IS-IS to rapidly detect link faults and to immediately notify IS-IS of route recalculation, which guides packet forwarding. Table 11-7 lists IS-IS convergence speed.

Table 11-7 IS-IS convergence speed

Whether a BFD Session Is Bound

Link Fault Detection Mechanism

Convergence Speed

No

Hello mechanism

At the second level

Yes

BFD session in Down state

At the millisecond level

Application
Figure 11-11 BFD for IS-IS

As shown in Figure 11-11, IS-IS is enabled on devices and association between BFD and IS-IS is enabled on SwitchA and SwitchB. When the link between SwitchA and SwitchB fails, BFD can rapidly detect the fault and report the fault to IS-IS. IS-IS then disconnects the neighbors of this interface, which triggers topology calculation. IS-IS updates LSPs so that the neighbors, for example, Switch B's neighbor SwitchC, can receive the updated LSPs from SwitchB. IS-IS fast convergence is implemented.

BFD for BGP

BGP enables the Switch Module to periodically send Keepalive packet to its peers for fault detection. Detecting a fault takes more than 1s. When traffic is transmitted at gigabit rates, long-time fault detection will cause loss of enormous packets. Association between BFD and BGP enables BFD to rapidly detect faults on links between BGP peers and reports faults to BGP, which implements fast BGP route convergence. Table 11-8 lists BGP convergence speed.

Table 11-8 BGP convergence speed

Whether a BFD Session Is Bound

Link Fault Detection Mechanism

Convergence Speed

No

Keepalive packet mechanism

At the second level

Yes

BFD session in Down state

At the millisecond level

Application
Figure 11-12 BFD for BGP

As shown in Figure 11-12, SwitchA belongs to AS 100, and SwitchB belongs to AS 200. SwitchA and SwitchB are directly connected and establish an EGBP connection. BFD detects the status of the EGBP connection between SwitchA and SwitchB. When the link between SwitchA and SwitchB becomes faulty, BFD can rapidly detect the fault and notify BGP of the fault.

BFD for VRRP

When the VRRP master fails, the VRRP backup with the highest priority should take over traffic within a short time to shorten service interruption.

When the VRRP master fails, VRRP determines whether to perform preemption based on the timeout interval of the backup. The switching takes more than 1s. BFD can be used to rapidly detect the master status and shorten traffic interruption. BFD detects real IP addresses of the master and backup devices during communication. If communication is abnormal, the backup device considers that the master device is Down and becomes the master device. a VRRP backup group implements a master/backup VRRP switchover rapidly by tracking the BFD session status. The switchover time is within 50 milliseconds.

Application
Figure 11-13 BFD for VRRP

As shown in Figure 11-13, SwitchA and SwitchB establish a VRRP group. SwitchA functions as the master and SwitchB functions as the backup. User traffic is transmitted through SwitchA. A BFD session is established between SwitchA and SwitchB. The VRRP group tracks the BFD session status. When the BFD session status changes, the priority of the VRRP group is changed and then a master/backup VRRP switchover is triggered.

When a BFD session detects a link fault between SwitchA and SwitchC, BFD reports a Down event to VRRP. Then the priority of SwitchB increases above the priority of SwitchA. SwitchB becomes the master switch immediately and subsequent user traffic is forwarded through SwitchB. In this manner, fast master/backup VRRP switchover is performed.

BFD for PIM

If a DR on the shared network segment becomes faulty, PIM neighbor relationships time out, and a new DR election is triggered among PIM neighbors. Consequently, multicast data transmission is interrupted. The interruption period, usually in seconds, is at least as long as the timeout interval of the neighbor relationship.

After detecting a fault on the peer, BFD immediately instructs the PIM module to trigger a new DR election without waiting for timeout of the neighbor relationship.

BFD for PIM can rapidly detect faults on the Assert winner and is also applicable to Assert election on a shared network segment.

Table 11-9 lists PIM convergence speed.

Table 11-9 PIM convergence speed

Whether a BFD Session Is Bound

Link Fault Detection Mechanism

Convergence Speed

No

Neighbor relationship timeout

At the second level

Yes

BFD session in Down state

At the millisecond level

Application
Figure 11-14 BFD for PIM

As shown in Figure 11-14, on the shared network segment connected to user hosts, downstream interface Interface1 on SwitchC and downstream interface Interface2 on SwitchD establish a PIM BFD session and send BFD control packets to detect the link status.

SwitchC functions as the DR and its downstream interface Interface1 is responsible for forwarding multicast data. If Interface1 becomes faulty, BFD fast notifies the RM of the session status, and the RM notifies the PIM module. The PIM module then triggers a new DR election. SwitchD quickly begins functioning as the new DR and its downstream interface Interface2 forwards multicast data to the receivers.

BFD for Perlink

Two devices are directly connected through an Eth-Trunk in a VLAN. If BFD for IP is bound to the VLANIF interface to detect the Eth-Trunk, BFD selects an link of a member interface of the Eth-Trunk as the detection path. If this link is faulty and other links are normal, the BFD session becomes Down. In this case, BFD may incorrectly report faults.

To solve this problem, BFD for Perlink is used to detect an Eth-Trunk. After BFD for Perlink is bound to a VLANIF interface, a management session is created. In addition, a dynamic unicast BFD sub-session is created for each member interface of the Eth-Trunk. The management session does not BFD sub-session is created for each member interface of the Eth-Trunk. Instead, it is used to manage the sub-session status and report the sub-session status to the upper-layer applications. BFD sub-sessions perform negotiation and detection, and report their status to the management session. The management session becomes Down only when all sub-sessions become Down.

The device supports BFD for Perlink based on the BFD Echo function. The following describes the working process of BFD for Perlink on the network shown in Figure 11-15.

Figure 11-15 Networking of BFD for Perlink

A Transparent Interconnection of Lots of Links (TRILL) network is deployed between RB1 and RB2. GW1 is directly connected to RB1, and an inter-board Eth-Trunk is deployed between GW1 and RB1; GW2 is directly connected to RB2, and an inter-board Eth-Trunk is deployed between GW2 and RB2. Inter-board Eth-Trunks on GW1 and GW2 join the same VLAN. BFD is required to detect faults on the link between GW1 and GW2. After BFD for Perlink is configured on GW1:
  1. On GW1, each BFD sub-session is created for each Eth-Trunk member link, and a BFD packet is constructed and sent out from a specified member interface. The BFD packet uses the IP address of the local VLANIF interface as the destination IP address, GW2's MAC address as the destination MAC address, and dynamically created local and remote discriminators.
  2. RB1 receives the BFD packet from the member interface and forwards it through the TRILL network.
  3. After receiving the BFD packet, RB2 selects a member link to forward it according to the hash algorithm.
  4. After receiving the BFD packet, GW2 finds that the destination IP address of the BFD packet is the IP address of the VLANIF interface on GW1. GW2 immediately loops back the BFD packet in the forwarding plane.
  5. After receiving the loopback packet, RB2 forwards it through the TRILL network.
  6. After the loopback packet returns RB1, GW1 also selects a member link according to the hash algorithm and sends it to GW1.

In the forwarding process, if member link 1 between GW1 and RB1 becomes faulty, sub-session 1 becomes Down, but sub-session 2 is still Up. Therefore, the management session is still Up, and BFD does not report faults incorrectly.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 57826

Downloads: 3619

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