Feature Description - Network Reliability

HUAWEI NetEngine5000E Core Router
V800R002C01
Feature Description - Network

Reliability
Issue 01
Date 2011-10-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2011-10-15) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Feature Description - Network Reliability About This Document
About This Document
Intended Audience
This document describes the network reliability features in terms of its overview, principle, and
applications.
This document together with other types of document helps intended readers get a deep
understanding of the network reliability features.
This document is intended for:
l Network planning engineers
l Commissioning engineers
l Data configuration engineers
l System maintenance engineers
Related Versions (Optional)

The following table lists the product versions related to this document.
Product Name Version
HUAWEI NetEngine5000E V800R002C01

Core Router
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk, which if not

avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which

if not avoided, could result in minor or moderate injury.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential ii

Feature Description - Network Reliability About This Document
Symbol Description
Indicates a potentially hazardous situation, which if not

avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save time.
Provides additional information to emphasize or supplement

important points of the main text.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 01 (2011-10-15)

Initial field trial release.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential iii

Feature Description - Network Reliability Contents
Contents
About This Document.....................................................................................................................ii

1 BFD...................................................................................................................................................1
1.1 Introduction to BFD............................................................................................................................................2
1.2 References..........................................................................................................................................................2
1.3 Principles............................................................................................................................................................3
1.3.1 BFD for IP.................................................................................................................................................6
1.3.2 BFD for PST..............................................................................................................................................8
1.3.3 Multicast BFD...........................................................................................................................................8
1.3.4 BFD for PIS...............................................................................................................................................9
1.4 Applications......................................................................................................................................................10
1.4.1 BFD for USR...........................................................................................................................................10
1.4.2 BFD for OSPF.........................................................................................................................................10
1.4.3 BFD for IS-IS..........................................................................................................................................11
1.4.4 BFD for BGP...........................................................................................................................................12
1.4.5 BFD for LSP............................................................................................................................................13
1.4.6 BFD for TE..............................................................................................................................................14
2 VRRP..............................................................................................................................................17
2.1 Introduction to VRRP.......................................................................................................................................18
2.2 References........................................................................................................................................................19
2.3 Principles..........................................................................................................................................................20
2.3.1 Master/Backup Mode..............................................................................................................................24
2.3.2 VRRP Load Balancing............................................................................................................................24
2.3.3 VRRP Security........................................................................................................................................25
2.3.4 Tracking the Interface Status...................................................................................................................25
2.3.5 Fast VRRP Switchover............................................................................................................................26
2.3.6 Enabling the Virtual IP Address to Be Pinged........................................................................................26
2.4 Applications......................................................................................................................................................26
2.4.1 VRRP Tracking the Interface Status.......................................................................................................27
2.4.2 VRRP Tracking the BFD Session Status.................................................................................................28
3 EFM OAM.....................................................................................................................................29
3.1 Introduction to EFM OAM...............................................................................................................................30
3.2 References........................................................................................................................................................31
Issue 01 (2011-10-15) Huawei Proprietary and Confidential iv

Feature Description - Network Reliability Contents
3.3 Principles..........................................................................................................................................................31
3.3.1 Peer Discovery.........................................................................................................................................31
3.3.2 Link Monitoring......................................................................................................................................33
3.3.3 Fault Notification.....................................................................................................................................33
3.3.4 Remote Loopback....................................................................................................................................34
3.3.5 Association Between EFM OAM and an Interface.................................................................................34
3.4 Applications......................................................................................................................................................35
Issue 01 (2011-10-15) Huawei Proprietary and Confidential v

Feature Description - Network Reliability 1 BFD
1 BFD
About This Chapter
1.1 Introduction to BFD

1.2 References
1.3 Principles
1.4 Applications
Issue 01 (2011-10-15) Huawei Proprietary and Confidential 1

1.1 Introduction to BFD

Definition
Bidirectional Forwarding Detection (BFD) can quickly detect a communication fault between
systems and notify upper-layer applications of the fault.
Purpose
BFD minimizes the impact of a fault on services and improves network availability. To achieve
this, a network device must quickly detect a communication fault between adjacent devices. The
upper-layer protocol can then rectify the fault to maintain normal services.
On a live network, a link fault can be detected in one of the following ways:
l Hardware detection signals (for example, the Synchronous Digital Hierarchy (SDH) alarm
function) can detect a link fault. This allows for the quick fault detection .
l If the preceding method is unavailable, the Hello mechanism of a routing protocol can
detect a fault.
The preceding methods, however, have the following problems:
l Only certain media support fault detection through hardware.
l It takes longer than one second for the Hello mechanism of a routing protocol to detect a
fault. When data is transmitted at gigabit rates, such a slow detection will cause a large
amount of data to be discarded.
l In small-scale Layer 3 networks with no deployed routing protocols, the Hello mechanism
of a routing protocol cannot be used to detect a fault. In this case, a fault between any of
the interconnected systems is hard to detect.
BFD is developed to address the preceding problems.
The BFD provides the following functions:
l Fault detection with a light load and high speed for channels between neighboring
forwarding engines. It can detect faults that occur on an interface, a data link, or a
forwarding engine.
l Provides a unified mechanism to monitor any media and protocol layer in real time.
BFD sessions cannot be created on a management interface or bound to the IP address of a
management interface.
Benefits
BFD is used to monitor and rapidly detect changes in the connectivity of links or IP routes on a
network, which helps improve network performance. Quickly detecting a communication failure
between adjacent systems can help the system rapidly create a backup tunnel to restore
communication and improve the reliability of a network.
1.2 References
The following table lists the references of this document.

Document Description Remarks
RFC 5880 Bidirectional Forwarding -

Detection (BFD)

Detection (BFD) for IPv4
and IPv6 (Single Hop)
RFC 5882 Generic Application of -

Bidirectional Forwarding
Detection (BFD)

Detection (BFD) for
Multihop Paths

Detection (BFD) for
MPLS Label Switched
Paths (LSPs)
1.3 Principles
BFD detects communication faults between forwarding engines. Specifically, BFD detects the
connectivity of a data protocol on a path between systems. The path can be a physical link or a
logical link, including tunnels.
BFD interacts with upper-layer applications in the following way:
l An upper-layer application provides monitoring parameters for BFD, such as the address
and time.
l Using these parameters, BFD creates, deletes, or modifies a BFD session and notifies the
upper-layer application of the BFD session status.
BFD has the following features:
l Provides fault detection with a light load and high speed for paths between neighboring
forwarding engines.
l A single mechanism for fault detection on all mediums and protocol layers, providing a
uniform detection mechanism on an entire network.
The following sections describe the basic functions of BFD, including the BFD detection
mechanism, the types of links that BFD detects, session establishment modes, and session
management.
BFD Detection Mechanism

The BFD detection mechanism uses two systems to set up a BFD session and periodically sends
BFD control packets from one to the other. If one system does not receive any BFD control
packets within a specified period of time, the system concludes that a fault occurs on the path.
BFD control packets are encapsulated through UDP. In the initial phase of a BFD session, both
systems negotiate the BFD parameters with each other using BFD control packets. These

parameters include discriminators, expected minimum intervals for sending and receiving BFD
control packets, and local BFD session status. After negotiating successfully, BFD control
packets are periodically sent along the path between these two systems at the negotiated receiving
and sending intervals.
BFD can operate in one of two modes:
l Asynchronous mode: is the mode BFD primarily operates in. In asynchronous mode, two
systems periodically send BFD control packets to each other along the path between them.
If one system repeatedly fails to receive multiple BFD control packets within a specified
period, the status of the BFD session is considered Down.
l Demand mode: is used if a large number of BFD sessions exist on a system. With many
BFD sessions, periodically sending BFD control packets is very resource-intensive and
affects system performance. In this situation, the demand mode can be used. In demand
mode, the system does not periodically send BFD control packets after a BFD session has
been set up, but it detects connectivity through another mechanism (such as the Hello
mechanism of a routing protocol or the hardware detection mechanism) to reduce the
amount of system resources required by the BFD session.
Types of Links Detected by BFD

l IP links
On the NE5000E, BFD can detect IPv4 and IPv6 links of the following types, including
both single-hop links and multi-hop links:
Layer 3 physical interfaces
Ethernet sub-interfaces
If a physical Ethernet interface has multiple sub-interfaces, BFD sessions can be established
separately on the physical Ethernet interface and each of its sub-interfaces.
l IP-Trunks
IP-Trunk links
IP-Trunk member links
BFD sessions can simultaneously detect an IP-Trunk interface and IP-Trunk member
interfaces.
l Eth-Trunks
Layer 2 Eth-Trunk links
Layer 2 Eth-Trunk member links
Layer 3 Eth-Trunk links
Layer 3 Eth-Trunk member links
BFD sessions can simultaneously detect an Eth-Trunk interface and Eth-Trunk member
interfaces.
l MPLS LSPs
To detect the connectivity of a Multiprotocol Label Switching label switched path (MPLS
LSP), a BFD session is negotiated in one of the following modes:
Static mode: A BFD session is established through the negotiation based on the local
discriminator and remote discriminator that are manually configured.
Dynamic mode: A BFD session is established through the negotiation based on the BFD
discriminator time-to-live (TLV) carried in LSP ping packets.
In static mode, BFD can detect the following types of LSPs:

LDP LSPs
TE: tunnels and static Constraint-Routing LSPs (CR-LSPs) and Resource Reservation
Protocol (RSVP) CR-LSPs that are bound to the tunnels.
BFD can detect a TE tunnel that uses a signaling protocol such as CR-static or RSVP-TE,
and the primary LSP bound to the TE tunnel.
In dynamic mode, BFD can detect the following types of LSPs:
LDP LSPs
TE: Static CR-LSPs and RSVP CR-LSPs that are bound to tunnels.
BFD Session Establishment Modes

A BFD session can be set up in either static mode or dynamic mode.
BFD sessions are differentiated by the My Discriminator field and the Your Discriminator field
in BFD control packets. The configurations of the My Discriminator field and the Your
Discriminator field are different depending on whether either a static BFD session or a dynamic
BFD session is being set up.
l Static BFD session

In a statically configured BFD session, the parameters, including the local discriminator
and the remote discriminator, are set using command lines. Then, a request to establish a
BFD session is manually distributed.
l Dynamic BFD session
To set up a dynamic BFD session, the system processes the local discriminator and the
remote discriminator as follows:
Dynamically allocating the local discriminator
When an application triggers the dynamic setup of a BFD session, the system allocates
a value in the range of the dynamic session discriminators as the local discriminator of
the BFD session. Then, the local system sends a BFD control packet with a Your
Discriminator field of 0 to the remote system to negotiate the BFD session.
Self-learning remote discriminator
When one end of a BFD session receives a BFD control packet with a Your
Discriminator of 0, the BFD control packet is checked. If the packet matches the local
BFD session, the local end learns the value of the My Discriminator field in the received
BFD control packet and thus obtains the remote discriminator.
BFD Session Management

The BFD session statuses are as follows:
l Down: A BFD session is in the Down state or has been just set up.
l Init: The local system can communicate with the remote system, and the local system
expects the session to go Up.
l Up: A BFD session is successfully set up.
l AdminDown: A BFD session is in the administratively Down state.
The session status is conveyed in the State field of a BFD control packet. The system changes
the session status based on the local session status and the received session status of the remote
end.

When a BFD session is to be set up or deleted, the BFD state machine implements a three-way
handshake to ensure that the two systems are aware of the status change.
Figure 1-1 shows the transition process of the state machine in the establishment of a BFD
session.
Figure 1-1 Establishment of a BFD session

RouterA RouterB
DOWN Sta: Down DOWN

Sta: Down
DOWN => INIT

DOWN => INIT Sta: Init
Sta: Init
INIT => UP
Sta: Up INIT => UP
Sta: Up
1. Router A and Router B start their BFD state machines with an initial state of Down.
Router A and Router B send BFD control packets with a State field of Down. In a static
BFD session, the value of the Your Discriminator field in a BFD control packet is manually
specified. In a dynamic BFD session, the value of the Your Discriminator field is 0.
2. After receiving a BFD packet with a State field of Down, Router B switches the session
status to Init and sends a BFD packet with a State field of Init.
3. After the local BFD session status of Router B changes to Init, Router B no longer processes
the received BFD packets with a State field of Down.
4. The state transition of the BFD session on Router A is the same as the state transition of
the BFD session on Router B.
5. After receiving a BFD packet with a State field of Init, Router B changes the local session
status to Up.
6. The status change of the BFD session on Router A is the same as the status change of the
BFD session on Router B.
1.3.1 BFD for IP

A BFD session can be established to quickly detect faults of an IP link.
BFD for IP detects single-hop and multi-hop IPv4 and IPv6 links:
l Single-hop BFD detects the IP route connectivity between directly-connected systems. The
single hop refers to a hop on an IP link. Only one single-hop BFD session can be set up to

detect a specified interface that is enabled with a specified data protocol between two
systems.
l Multi-hop BFD detects all paths between two systems. Each path may contain multiple
hops, and these paths may partially overlap.
Application Environment
Typical application I:
Figure 1-2 shows a BFD session detecting a single-hop IPv4 path between two routers and the
BFD session is bound to the outgoing interface.
Figure 1-2 Networking diagram of single-hop BFD for IPv4

BFD session
POS1/0/0 POS1/0/0
10.1.1.1/25 10.1.1.2/25
RouterA RouterB
BFD session
Typical application II:
Figure 1-3 shows a BFD session detecting a multi-hop IPv4 path between Router A and
Router C. The BFD session is bound to the peer IP address but not the outgoing interface.
Figure 1-3 Networking diagram of multi-hop BFD for IPv4

BFD session
POS1/0/0 POS1/0/0 POS2/0/0 POS2/0/0

10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
RouterA RouterB RouterC
BFD session
Typical application III:
Figure 1-4 shows a BFD session detecting a single-hop IPv6 path between Router A and
Router B. The BFD session is bound to the outgoing interface.

Figure 1-4 Networking diagram of single-hop BFD for IPv6
BFD session
RouterA RouterB
GE1/0/0 GE1/0/0
2001::1/64 2001::2/64
BFD session
Typical application VI:

Figure 1-5 shows a BFD session detecting a multi-hop IPv6 path between Router A and
Router C. The BFD session is bound to the peer IP address but not the outgoing interface.
Figure 1-5 Networking diagram of multi-hop BFD for IPv6
BFD session
GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0

2001::1/64 2001::2/64 2002::1/64 2002::2/64
BFD session
1.3.2 BFD for PST

When a BFD session detects a fault, the BFD module changes the interface status in the port
state table (PST), which then triggers a FRR switchover. BFD for PST can only be used for a
single-hop BFD session that is bound to an interface.
BFD for PST is widely used in different FRR applications. A BFD for PST session is bound to
an interface associated with the PST. After detecting that a link is Down, the BFD session goes
Down and sets the bit representing the PST of the interface to Down. This triggers the FRR
switchover.
1.3.3 Multicast BFD

Multicast BFD quickly detects link faults by detecting connectivity of links between interfaces
that do not have Layer 3 attributes such as IP addresses.
After multicast BFD is configured, a BFD session sends multicast BFD packets through the
network layer. If the link is reachable, the remote interface receives the multicast BFD packets
and forwards the packets to the BFD module. In this manner, the BFD module detects that the

link is normal. On a trunk member link, multicast BFD packets are forwarded through the
network layer without IP attributes, and they travel directly through the data link layer to detect
link connectivity. The remote IP address used in the multicast BFD session is the default known
multicast IP address (224.0.0.107-224.0.0.250). Any packet with the default known multicast
IP address is forwarded to the BFD module. The IP forwarding process is then complete.
Figure 1-6 Networking diagram of multicast BFD

BFD session
GE1/0/0 GE1/0/0
RouterA RouterB
BFD session
As shown in Figure 1-6, multicast BFD can quickly detect connectivity of a link between
interfaces. A BFD session that adopts the default multicast address and is bound to the outgoing
interface GE 1/0/0 is required on Router A and Router B to quickly detect the connectivity of
the link in between them.
1.3.4 BFD for PIS

BFD for process interface status (PIS) is a simple mechanism in which the behavior of a BFD
session is associated with the interface status. BFD for PIS improves the sensitivity of interfaces
in detecting a link fault and minimizes the impact of faults on non-direct links.
When using BFD for PIS, after detecting a link fault, a BFD session immediately sends a message
indicating the Down state to the associated interface. The interface then enters the BFD Down
state, which is equivalent to the Down state of the link protocol. In the BFD Down state, the
interface processes only BFD packets to quickly detect the link fault.
For each BFD session that needs to be associated with the interface status, the multicast BFD
session is configured. In this manner, the forwarding of BFD packets is independent of the IP
attributes on the interface.

Figure 1-7 Networking diagram of BFD for PIS

BFD session
GE1/0/0 GE1/0/0
RouterA RouterB
BFD session
In Figure 1-7, a BFD session is established between Router A and Router B. The BFD session
sends a packet with the source address of the default multicast IP address to the bound interface
GE 1/0/0 to detect the single-hop link. After BFD for PIS is configured, when detecting a link
fault, the BFD session sends a message indicating the Down state to the associated interface.
The interface then enters the BFD Down state.
1.4 Applications
1.4.1 BFD for USR

BFD for unicast static route (USR) IPv4 USRs. After a BFD session is bound to an IPv4 USR,
any change to the link status is quickly detected.
Unlike dynamic routing protocols, USRs lack a detection mechanism. If a fault occurs on a
network, an administrator needs to handle it manually. Using BFD for USR, BFD sessions are
bound to IPv4 static routes on a public network and can detect the status of the links of those
routes.
A single BFD session can only be bound to a single IPv4 USR. When a BFD session bound to
a USR detects a fault (for example, the link changes from Up to Down) on a link of the USR,
BFD reports the fault to the routing management module (RM). Then, the RM sets the USR to
"inactive" (indicating that the route is unavailable and deleted from the IP routing table).
When the BFD session bound to the USR is successfully set up or the link of the USR recovers
from the fault (that is, the link changes from Down to Up), BFD reports the event to the RM and
the RM sets the USR to "active" (indicating that the route is available and added to the IP routing
table).
1.4.2 BFD for OSPF

A link fault or a change of network topology may lead to rerouting on the router. To improve
network availability, the convergence time of routing protocols must be shortened. Link failures
are an inevitability. Therefore, a effective solution is required to quickly detect failures and notify
the routing protocols of any failures immediately.

BFD for OSPF associates a BFD session with OSPF. The BFD session quickly detects any link
failure and notifies OSPF of the failure. This shortens the time required for OSPF to respond to
a change of network topology.
Table 1-1 shows the time required for network convergence when OSPF is and is not associated
with a BFD session.
Table 1-1 OSPF convergence time

BFD Status Link Failure Detection Mechanism Convergence
Time
BFD is OSPF Hello Keepalive timer expires. Seconds

disabled.
BFD is enabled. A BFD session goes Down. Milliseconds
Figure 1-8 Networking diagram of BFD for OSPF
RouterC
cost1
cost1
POS1/0/0
RouterA RouterB
POS2/0/0
cost1
cost10
RouterD
As shown in Figure 1-8, Router A sets up OSPF neighbor relationships with both Router C and
Router D. The outgoing interface of the route from Router A to Router B is POS 1/0/0, and the
route is destined for Router B through Router C. When the neighbor status is Full, OSPF notifies
BFD of the establishment of a BFD session.
1. When the link between Router A and Router C fails, BFD detects the fault and notifies
Router A of it.
2. Router A then processes that the neighbor has gone Down and recalculates the route. The
outgoing interface of the new route is POS 2/0/0, and the route is destined for Router B
through Router D.
1.4.3 BFD for IS-IS

Generally, Intermediate System-to-Intermediate System (IS-IS) sends Hello messages at an
interval of 10 seconds. The period of time it advertises the failure of a neighbor is three times
the interval between Hello messages. If the router fails to receive a Hello packet from its neighbor
within the period of advertising that a neighbor has failed, the router deletes the route to the
neighbor. It takes the router seconds to detect the failure of a neighbor. This leads to the loss of
a large number of packets on high-speed networks.

BFD for IS-IS refers to the dynamic establishment of a BFD session that is triggered by IS-IS
but not configured manually. When detecting a fault, the BFD session notifies IS-IS of the fault
through the RM. Then, IS-IS processes the event that the neighbor has gone Down and quickly
updates the link state PDU (LSP) and performs the partial route calculation (PRC). In this
manner, IS-IS routes quickly converge.
The BFD detection interval can be set in milliseconds. Instead of replacing the Hello mechanism
of IS-IS, BFD works with IS-IS to quickly detect an adjacency fault. In addition, BFD instructs
IS-IS to recalculate routes, which ensures correct packet forwarding.
Figure 1-9 Networking diagram of BFD for IS-IS

BFD session
POS1/0/0 POS1/0/0 POS2/0/0 POS2/0/0

10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
BFD session
BFD is enabled on Router A, Router B, and Router C. When a fault occurs on the link between
Router A and Router B, the BFD session quickly detects the fault and notifies IS-IS of the fault
through the RM. Then, IS-IS sets the neighbor status to Down to trigger an IS-IS topology
calculation. In addition, IS-IS updates LSPs to ensure that other neighbors, such as those of
Router C and Router B, can receive the updated LSPs from Router B quickly. In this manner,
the network topology quickly converges.
1.4.4 BFD for BGP

The Border Gateway Protocol (BGP) periodically sends Keepalive messages to a peer to detect
the status of the peer. The detection, however, takes over one second. Therefore, when data
transmission is at gigabit rates, a large amount of data is discarded, which cannot meet the high
reliability requirements of carrier-class networks.
Therefore, BFD for BGP is used to quickly detect faults on links between BGP peers in
milliseconds and to notify BGP of the faults. In this manner, BGP routes can quickly converge.

Figure 1-10 Networking diagram of BFD for BGP
BFD session
AS 100 AS 200
EBGP
POS1/0/0
POS1/0/0
200.1.1.2/24
RouterA200.1.1.1/24
RouterB
BFD session
As shown in Figure 1-10, Router A belongs to AS 100 and Router B belongs to AS 200.
Router A and Router B are directly connected and an External Border Gateway Protocol (EGBP)
connection is set up. BFD is enabled to detect the BGP neighbor relationship between Router A
and Router B. When the link between Router A and Router B fails, BFD can quickly detect the
fault and notify BGP of the fault.
1.4.5 BFD for LSP

A BFD session established on an LSP can quickly detect a fault on the LSP. This provides end-
to-end protection for the LSP.
When a BFD session detects a fault on an LSP that is unidirectional, the backward link can be
an IP link, an LSP, or a TE tunnel.
To detect the connectivity of an MPLS LSP, a BFD session is negotiated in either of the following
modes:
l Static mode: A BFD session is established through negotiation based on the local
discriminator and remote discriminator that are manually configured.
l Dynamic mode: A BFD session is established through negotiation based on the BFD
discriminator TLVs carried in LSP ping packets.
Currently, BFD can only detect Static BFD for LDP LSP.
BFD runs in asymmetric mode to detect the connectivity of an LSP. That is, the ingress and
egress periodically send BFD packets to each other. If the ingress or the egress does not receive
a BFD packet from the other end within a detection period, the LSP is considered to be Down
and BFD sends the LSP management module (LSPM) an LSP Down message.

Figure 1-11 Networking diagram of BFD for LDP LSP
BFD session PE2
P1
PE1 CE2
BFD session
PE3
As shown in Figure 1-11, only traffic from PE1 to CE2 is involved in this implementation. When
a fault occurs on the link between PE1 and P1, PE1 can detect the fault through the interface,
and BFD for LDP LSP is not required. When a fault occurs on the link between P1 and PE2,
however, PE1 cannot detect the fault through the interface, therefore BFD for LDP LSP needs
to be configured so that faults can be quickly detected.
An LDP LSP is set up from PE1 to PE2. BFD for LDP LSP is enabled and a BFD session is set
up to detect the LDP LSP. In addition, policies for Virtual Private Network fast reroute (VPN
FRR) are configured on PE1 and the protection path between PE1 and PE3 is specified.
When a fault occurs on the link between PE1 and P1 or between P1 and PE2, PE1 quickly detects
the LSP fault and triggers VPN FRR switching. In this manner, traffic is switched to the path
PE1 -> PE3 -> CE2 for protection.
1.4.6 BFD for TE

BFD for TE is an end-to-end fast detection mechanism that is applicable to MPLS TE. BFD for
TE can quickly detect faults along a link of an MPLS TE tunnel.
The traditional detection mechanisms, including the RSVP Hello mechanism and the RSVP
summary refresh (Srefresh) mechanism, require a long time to detect a fault. BFD uses fast
packet transmission mode and can quickly detect faults on an MPLS TE tunnel, which then
triggers the fast traffic fallover. In this manner, services are maintained.
BFD can detect TE tunnels in the following modes:
l Static BFD for CR-LSP

Static BFD for CR-LSP detects a CR-LSP for an LSP fault. The BFD session needs to be
manually configured.
l Static BFD for TE
Static BFD for TE detects the entire TE tunnel and can trigger the traffic fallover of
applications, such as VPN FRR.
l Dynamic BFD for CR-LSP

Dynamic BFD for CR-LSP functions in the same manner as static BFD for CR-LSP. The
session establishment mode of dynamic BFD for CR-LSP is different from that of static
BFD for CR-LSP. In dynamic BFD for CR-LSP, the establishment of a BFD session is
dynamically triggered.
The difference between BFD for TE and BFD for CR-LSP is that the objects that BFD reports
faults to are different. In BFD for TE, BFD notifies applications such as VPN, of faults and
triggers the traffic fallover between different tunnel interfaces. In BFD for CR-LSP, BFD notifies
TE tunnels of faults and triggers the traffic fallover between different CR-LSPs in the same TE
tunnel.
BFD is bound to an LSP, and a BFD session is set up between the ingress and the egress. A BFD
packet is sent by the ingress and forwarded to the egress through an LSP. Then, the egress
responds to the BFD packet. In this manner, a BFD session at the ingress can quickly detect any
change to the status of the path through which the LSP passes.
After a link fault is detected, BFD notifies the LSP management module. Then, traffic is switched
to the backup LSP, and a new BFD session is set up between the ingress and the egress along
the backup LSP.
Figure 1-12 Networking diagram of BFD for LSP
Before
switchover
After switchover
Primary Lsp
Backup Lsp
BFD session

In Figure 1-12, a BFD session detects the link through which the primary LSP passes. When a
fault occurs on the link of the primary LSP, the BFD session at the ingress immediately reports
the fault to the forwarding plane. Then, the ingress switches traffic to the backup LSP.
This networking is applicable to BFD for TE, BFD for hot standby, and BFD for tunnel protection
group.
Figure 1-13 Networking diagram of BFD for TE
R1 R2
P2 Primary tunnel
Backup tunnel
P3
Primary Lsp
Backup Lsp
l Fallover from a primary LSP to a hot-standby LSP

In Figure 1-13, a primary tunnel is set up between R1 and R2, and a hot-standby LSP is
set up. A BFD session is established from R1 to R2 to detect the primary LSP in the tunnel.
When a fault occurs on the primary LSP, the BFD session quickly notifies R1 of the fault.
After receiving the fault notification, R1 quickly switches traffic to the backup LSP to
ensure normal traffic transmission.
l Fallover from a primary tunnel to a backup tunnel
As shown in Figure 1-13, a primary tunnel is set up along the path R1 -> P2 -> R2, and a
backup tunnel is set up along the path R1 -> P3 -> R2. A BFD session is set up on the path
R1 -> P2 -> R2 to monitor the primary tunnel. When a fault occurs on the primary tunnel,
the BFD session quickly notifies R1 of the fault. After receiving the fault information, R1
quickly switches traffic to the backup tunnel to ensure normal traffic transmission.

Feature Description - Network Reliability 2 VRRP
2 VRRP
About This Chapter
2.1 Introduction to VRRP

2.2 References
2.3 Principles
2.4 Applications

2.1 Introduction to VRRP

Definition
The Virtual Router Redundancy Protocol (VRRP) is a fault-tolerant protocol. By grouping
several routers into a virtual router, VRRP can switch the service of a faulty next-hop router to
another router through certain mechanisms. This ensures the continuity and reliability of
communications.
The basic concepts of VRRP are as follows:
l VRRP Router: It is a device running VRRP and may join one or multiple virtual routers.
l Virtual Router: It is an abstract device managed by VRRP, also called a VRRP backup
group. A virtual router functions as the default gateway in a shared local area network
(LAN). A virtual router consists of a virtual router identifier and a group of virtual IP
addresses.
l Virtual IP address: It is the IP address of a virtual router. A virtual router can be manually
assigned one or multiple virtual IP addresses.
l IP address owner: It is a VRRP router that uses a virtual IP address as the actual interface
address. When working normally, the VRRP router responds to the packets with the
destination address being the virtual IP address, such as ping packets and TCP packets.
l Virtual MAC address: It is a MAC address generated by a virtual router according to a
virtual router ID. A virtual router has one virtual MAC address in the format of
00-00-5E-00-01-{VRID}. When responding to an Address Resolution Protocol (ARP)
request, a virtual router uses the virtual MAC address rather than the real MAC address of
the interface.
l Primary IP address: A primary IP address is selected from the real interface addresses.
Usually, it is the first configured IP address of the interface. The primary IP address is used
as the source IP address in VRRP advertisement packets.
l Master Router (virtual router master): It is a VRRP router that forwards packets to the
virtual IP address or responds to ARP requests. When an IP address owner is available, it
usually functions as the master router.
l Backup Routers (virtual router backups): They are a group of VRRP routers that do not
forward packets. When the master router becomes faulty, the backup routers compete to
be the new master router.
l Preemption mode: In preemption mode, if the priority of a backup router is higher than the
priority of the current master router, the backup router automatically becomes the master
router.
Purpose
With the development of the Internet, the demand for high network reliability is increasing. For
LAN users, it is important to be in contact with the external network at any time.
Usually, all hosts within a network are configured with the same default route destined for an
egress gateway. In this manner, the hosts communicate with external networks. When the egress
gateway becomes faulty, all hosts fail to communicate with external networks.

To improve the reliability of the system, a common method is to configure multiple egress
gateways. The route selection among these gateways, however, is a problem to be solved because
hosts in a LAN do not support dynamic routing protocols.
In this situation, the Internet Engineering Task Force (IETF) puts forward VRRP. VRRP
provides reliability for hosts in a LAN to access external networks. A VRRP backup group with
a specified virtual IP address can be configured on routers. Hosts use the virtual IP address as
the default gateway address. This implements gateway backup without changing the networking.
This protocol defines the following application functions:
l Master/backup mode: VRRP provides the IP address backup function in master/backup

mode. In this mode, a virtual router must be set up, consisting of a master router and several
backup routers. These routers form a VRRP backup group. Normally, the master router
carries all services. When the master router fails, a backup router takes over the services.
l VRRP load balancing: In VRRP local balancing, multiple virtual routers carry services at
the same time. A VRRP backup group cannot carry out VRRP load balancing on its own.
This mode requires the participation of at least two VRRP backup groups created on more
than one router, with each group sharing the workload. As a result, traffic is balanced among
the routers.
l VRRP security: Different authentication modes and authentication keys can be set in VRRP
packet headers for networks at different security levels to prevent devices against attacks.
l mVRRP
An mVRRP backup group can be bound to multiple service VRRP groups, but an
mVRRP backup group functioning as a service VRRP group cannot be bound to any
other mVRRP group.
One service VRRP backup group can be bound to only one mVRRP backup group.
After multiple service VRRP backup groups are bound to an mVRRP backup group,
the mVRRP backup group determines the status of all service VRRP backup groups by
sending VRRP packets. In this manner, less VRRP packets are sent and VRRP packets
can be processed more efficiently.
The mVRRP backup group tracks the status of BFD sessions to implement VRRP fast
switchovers.
Benifits
A VRRP backup group brings uses the following benefits:
l Improves network reliability.

l Simplifies network management and decreases operation and maintenance expenditures.
2.2 References
The following table lists the references of this document.
Docume Description Remar

nt ks
RFC 2338 Virtual Router Redundancy Protocol (version number One 1998) -
RFC 2787 Definitions of Managed Objects for the Virtual Router Redundancy -
Protocol

Docume Description Remar

nt ks
RFC 3768 Virtual Router Redundancy Protocol (version number Two 2004) -
RFC5798 Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6 -
2.3 Principles
VRRP combines a group of routers on a LAN into a backup group that functions as a virtual
router. Hosts on the LAN only use the IP address of the virtual router, not the actual IP address
of a target device. By setting the IP address of the virtual router as the default gateway, the hosts
on the LAN can communicate with external networks using this virtual gateway.
VRRP dynamically associates the virtual router with a physical router that transmits services.
When the physical router fails, another router is elected to transmit services. The entire process
is transparent to users. The internal and external networks can communicate without interruption.
Figure 2-1 Schematic diagram for a virtual router
Virtual IP Address:
10.110.10.1 RouterA
Master
10.110.10.5
HostA
RouterB
Backup
10.110.10.6
HostB Network
RouterC
10.110.10.7 Backup
HostC
Ethernet
On the network shown in Figure 2-1, the implementation of the virtual router is as follows:
l Router A, Router B, and Router C form a VRRP backup group that functions as a virtual
router. The IP address of the virtual router is 10.110.10.1. The virtual IP address can be
specified or borrowed from an interface on another router in this VRRP backup group.
l The actual IP addresses of the physical routers: Router A, Router B, and Router C are
10.110.10.5, 10.110.10.6, and 10.110.10.7 respectively.

l Hosts on the LAN only need to set the default route to 10.111.10.1 rather than a physical
interface address of a specific router.
Hosts communicate with external networks by using this virtual gateway. The working
mechanism of the VRRP backup group is as follows:
l A master router is selected according to the priority. There are two modes for the selection
of a master router.
After a comparison of priorities, the router with a higher priority is selected as the master
router.
When two routers with the same priority compete to be the master router, their IP
addresses are compared. The router whose interface has a higher IP address is selected
as the master router.
l Other routers function as backup routers and track the status of the master router all the
time.
When working normally, the master router sends a VRRP advertisement packet at
intervals to notify the backup routers in the group that the master router works normally.
In a VRRP backup group consisting of a master router and a backup router, if the backup
router has not received any advertisement packet from the master router within a period
of time, the backup router becomes the master router. If there are multiple backup
routers in a VRRP backup group and the backup routers have not received any
advertisement packet from the master router within a certain period of time, more than
one backup router may claim to be the master router in a short period. The routers then
compare the priorities of the received VRRP packets with the local priority, and the
router with a higher priority is selected as the master router. After a backup router
becomes the master, it sends gratuitous ARP packets to refresh MAC entries on the
routers. In this manner, user traffic is switched to the master router. In addition, the
entire process is open to users.
The preceding analysis shows that in VRRP, no additional operations need to be performed on
the hosts, and the hosts can communicate with external networks normally even when a router
fails.
VRRP Packet Format

VRRP packets are used to advertise the priority value and status of the master device to the other
VRRP routers in a VRRP backup group.
A VRRP packet is encapsulated by using an IP header and is sent by using the multicast IP
address as a destination address. In the IP header, the source IP address is the IP address of the
interface whose VRRP status is Master (not the virtual IP address or the IP address of the interface
whose VRRP status is Backup); the destination address is 224.0.0.18; the TTL is 255; the
protocol number is 112. Figure 2-2 shows the format of a VRRP packet.

Figure 2-2 Schematic diagram of the format of a VRRP packet
0 34 7 15 23 31
Version Type Virtual Rtr ID Priority Count IP Addrs
Auth Type Adver Int Checksum
IP Address (1)
...
IP Address (n)
Authentication Data (1)
Authentication Data (2)
The meanings of the fields are as follows:

l Version: is the version number of the VRRP protocol. The value is 2.
l Type: is the type of VRRP packet. The value is only 1, indicating the Advertisement packet.
l Virtual router ID (VRID): is the virtual router ID. The value ranges from 1 to 255.
l Priority: is the priority value carried in a VRRP Advertisement packet, indicating the
priority of a device sending the packet in a VRRP backup group. The value ranges from 0
to 255, but only values 1 to 254 are allowed to be set. The value 0 indicates that the master
device quits the master state. This allows a backup device to preempt the master device
though the Adver_Timer does not expire. The value 255 is reserved for the IP address
owner. The default value is 100.
l Count IP Addrs: is the number of virtual IP addresses carried in a VRRP Advertisement
packet.
l Authentication Type: is the authentication mode for VRRP Advertisement packets:
0: Non Authentication
1: Simple Text Password
2: Reserved
NOTE
The NE5000E supports simple text authentication.

l Advertisement interval: is the interval at which a VRRP Advertisement packet is sent.The

default interval is 1s.
l Checksum: is the checksum value.
l IP Address(es): is the virtual IP address of a VRRP backup group.
l Authentication Data: is the authentication text. This field is non-0 in simple text
authentication and 0 in other authentication modes.
VRRP State Machine

The VRRP protocol defines three states in a state machine: Initialize, Master, and Backup. A
device only in the Master state is allowed to forward packets whose destination address is the
virtual IP address.
Figure 2-3 shows the transition process of the VRRP state machine.
Figure 2-3 Transition process of the VRRP state machine
Initialize
A
A
ed
Sh
S t ts p
d
iv
an
ce
a r ri o
ut
i
t u ri
do
re
d
5 ve
p ty
w
is
m is
25 ei
n
ge
i s ec
es s
m
sa
es
r
sa ma
rit is
es
sa
g e lle
io e
m
ge
pr ag
is r t h
y
n
s
w
is
re an
its es
do
ce 2
re
m
ut
ce
iv 5 5
up
Sh
ed
iv
at
ed
A
an
St
Receive a packet whose priority is

d
A
higher than the local priority

Master Backup
MASTER_DOWN_TIMER expires
Initialize: After a device in a VRRP backup group starts, the device works in the Initialize state.
If this device receives a Startup message indicating that its VRRP-enabled interface is Up, this
device transitions to Backup or Master. If the device is the IP address owner whose VRRP
priority value is 255, it transitions to Master after receiving the Startup message. A device in the
Initialize state processes no VRRP Advertisement packet.
Master: A device in the Master state performs the following operations:

l Periodically sends a VRRP Advertisement packet.
l Responds to an ARP request carrying the virtual MAC address.
l Forwards IP packets whose destination MAC address is the virtual MAC address.
l Receives IP packets whose destination IP address is the virtual IP address if the master
device is the owner of the virtual IP address. Alternatively, it discards these IP packets if
the master device is not the owner.

l Transitions to Backup if the VRRP priority in a received VRRP packet is higher than the
local VRRP priority.
l Transitions to Backup if the VRRP priority in a received VRRP packet is the same as the
local VRRP priority and the IP address of the sender is higher than the IP address of the
master device.
l Transitions to Initialize after receiving a Shutdown message, indicating that the VRRP-
enabled interface has been shut down.
Backup: A device in the Backup state performs the following operations:
l Receives VRRP Advertisement packets from the master device, and checks whether the
sender is the master.
l Produces no response to an ARP request carrying the virtual IP address.
l Discards IP packets whose destination MAC address is the virtual MAC address.
l Discards IP packets whose destination IP address is the virtual IP address.
l Discards packets carrying VRRP priorities lower than the local VRRP priority and does
not reset the Adver_Timer. Alternatively, it discards the packet and resets the Adver_Timer,
but does not compare IP addresses if receiving packets carrying VRRP priorities the same
as the local VRRP priority.
l Transitions to Master if a Master_Down_Timer timeout message is received.
l Transitions to Initialize after receiving a Shutdown message, indicating that the VRRP-
enabled interface is shut down.
2.3.1 Master/Backup Mode

VRRP provides IP address backup in master/backup mode. In this mode, a virtual router must
be set up, consisting of a master router and multiple backup routers. These routers form a backup
group.
Normally, the master router carries all services. When the master router fails, a backup router
takes over the services.
2.3.2 VRRP Load Balancing

On the NE5000E, a router can function as a backup router in multiple VRRP backup groups.
When multiple backup groups are configured, load balancing can be carried out among them.
In load balancing mode, multiple routers transmit services at the same time; therefore, two or
more backup groups need to be set up.
The load balancing mode has the following characteristics:
l Each backup group consists of a master router and several backup routers.
l The master routers of the backup groups can be different.
l An interface on a router can join multiple backup groups and its priority in the backup
groups varies.

Figure 2-4 Schematic diagram of the VRRP load balancing mode

Backup group 1
Virtual IP Address:
10.110.10.1 RouterA
Master/Backup
10.110.10.5
HostA
RouterB
Backup
10.110.10.6
HostB Network
RouterC
Backup/Master
HostC 10.110.10.7
Ethernet
Backup group 2
Virtual IP Address:
10.110.10.2
As shown in Figure 2-4, two backup groups are configured, namely, Backup group 1 and Backup
group 2.
l Router A functions as the master in Backup group 1 and a backup in Backup group 2.
l Router B functions as a backup in both Backup group 1 and Backup group 2.
l Router C functions as the master in Backup group 2 and a backup in Backup group 1.
l Certain hosts use Backup group 1 as the gateway, and the other hosts use Backup group 2
as the gateway.
In this manner, load balancing of data traffic is carried out, and the mutual backup is achieved.
2.3.3 VRRP Security

Different authentication modes and authentication keys can be set in VRRP packet headers in
networks at different security levels.
In a secure network, the default setting can be adopted. That is, the router does not authenticate
the VRRP packets to be sent or the received VRRP packets. In addition, all received VRRP
packets are considered as valid. In this case, no authentication key needs to be set.
VRRP provides simple text authentication and MD5 authentication for networks that are
vulnerable to attacks. The simple text authentication password is a string of 1 to 8 characters.
The MD5 authentication password is a string of 1 to 8 characters in plain text or a string of 24
characters in cipher text.
2.3.4 Tracking the Interface Status

A VRRP backup group can be configured to track multiple interfaces on a device where the
VRRP backup group resides. If the interface tracked by a VRRP backup group goes Up or Down,

the priority of each device in the VRRP backup group automatically changes by a certain value.
This allows the VRRP-enabled devices in the VRRP backup group to re-compete with each other
to be the master device.
A VRRP backup group tracks a maximum of eight interfaces in either of the following modes:
l Increase mode: means that if the tracked interface goes Down, the VRRP priorities of
devices in a VRRP backup group increase by a specified value.
l Reduce mode: means that if the tracked interface goes Down, the VRRP priorities of devices
in a VRRP backup group reduce by a specified value.
2.3.5 Fast VRRP Switchover

BFD rapidly detects faults in links and IP routes and monitors the connectivity of the links and
IP routes. VRRP rapidly implements master/backup switchovers within 1 second by tracking
the BFD session status.
If BFD detects a fault, the BFD session goes Down and the BFD module notifies the interface
board of the status change. This triggers the rapid master/backup VRRP switchover. BFD detects
a fault in one of the following situations:
l The interface on which a VRRP backup group is created fails.
l The master and backup devices are not directly connected.
l The master and the backup devices are directly connected but a transmission device exists
on the link between the master and backup devices.
BFD detects faults in the link between the master and backup devices. If a fault occurs, the
backup device considers that the master device is unavailable, and automatically becomes the
master device. The backup device becomes the master device in one of the following situations:
l The back-to-back connection is interrupted.
l The connection between the master and the switch is interrupted in one of the following
cases:
The master device restarts.
The link between the master device and the switch is interrupted.
The switch restarts.
A rapid VRRP switchover is performed if the following conditions are met:
l On the backup device, the interfaces detected by BFD sessions must be connected to the
master device.
l If the master device is unavailable, the VRRP priority of the backup device increases to a
value higher than the VRRP priority of the master device, and needs to preempt the master
device.
2.3.6 Enabling the Virtual IP Address to Be Pinged

The virtual IP address in a VRRP backup group serves as the IP address of the default gateway
for hosts. Although pinging the virtual IP address is a useful method for monitoring a VRRP
backup group, it exposes the VRRP backup group to ICMP packet attacks. The VRRP-enabled
Router can be configured to allow its virtual IP address able or unable to be pinged.
2.4 Applications

2.4.1 VRRP Tracking the Interface Status
Figure 2-5 Networking diagram for VRRP tracking the interface status
Internet
GE1/0/0 GE1/0/0
RouterA VRRP RouterB
Switch
Data flow before switchover

Data flow after switchover
Solved problem: VRRP cannot detect status changes of VRRP-incapable interface. If the link
between the VRRP-enabled device and hosts fails, VRRP cannot detect the fault and services
are interrupted.
Configuration notes are as follows:

l VRRP is configured to track a specified interface.
l A VRRP backup group tracks a maximum of eight interfaces in either Increase or Reduce
mode.
l If the status of an interface tracked by a VRRP group changes, the VRRP backup group is
notified of the change and increases or decreases the VRRP priorities of devices to perform
a VRRP switchover.
On the network shown in Figure 2-5, VRRP is enabled on Router A and Router B. The VRRP
priority of Router B is higher than that of Router A. Router B tracks the interface connected to
the Internet in Reduce mode. Router B is the master device and forwards user traffic along the
links in green in Figure 2-5. Router B is tracking the interface connected to the Internet in Reduce
mode. If the interface fails, the VRRP backup group detects the change and reduces VRRP
priorities to perform a master/backup switchover. As a result, Router A preempts the master
device and takes over user traffic.

2.4.2 VRRP Tracking the BFD Session Status

Figure 2-6 Networking diagram for VRRP tracking the BFD session status
RouterA RouterB
Switch
Solved problem: Traffic loss lasts a long time though a VRRP backup group detects a link fault
after the fault occurs.
Configuration notes are as follows:
l BFD that detects faults in milliseconds is enabled to detect faults in the link between
Router A and Router B. If the link or a remote host fails, the BFD session can rapidly detect
the fault.
l After the VRRP backup group is configured to track the BFD session, if BFD detects a
fault, the BFD session goes Down. The VRRP backup group will be notified of the status
change.
l The VRRP backup group adjusts the VRRP priorities to allow a backup device to rapidly
preempt the master device.
l By tracking the BFD session, a VRRP backup group performs a master/backup switchover
within 200 milliseconds.
On the network shown in Figure 2-6, a VRRP backup group is configured on Router A and
Router B. Router A is the master device and forwards user traffic. A BFD session is established
on Router A and Router B. The VRRP backup group tracks the status of the BFD session. If the
status of the BFD session changes, the VRRP priorities of devices in the VRRP backup group
change. This triggers the master/backup switchover. If a BFD session detects a link fault between
Router A and a switch, the BFD session goes Down and the status change is reported to VRRP.
The priority of Router B increases to be higher than the priority of Router A. Router B becomes
the master immediately and subsequent user traffic is forwarded by Router B. In this manner,
the master/backup VRRP switchover is rapidly performed.

Feature Description - Network Reliability 3 EFM OAM
3 EFM OAM
About This Chapter
3.1 Introduction to EFM OAM

3.2 References
3.3 Principles
3.4 Applications

3.1 Introduction to EFM OAM

Definition
Ethernet Operation, Administration, and Maintenance (OAM) is used to manage and maintain
Ethernet.
The primary function of Ethernet OAM is performance management. Performance management
measures the packet loss ratio, delay, and jitter during packet transmission. It also collects
statistics about various types of traffic on the network. Performance management is usually
implemented at the user access point.
With performance management tools, a carrier can monitor the network status and locate faults
by using a Network Management System (NMS). In this way, the carrier can determine whether
the network forwarding capacity is in line with the Service Level Agreement (SLA) signed with
users.
Ethernet OAM effectively improves the manageability and maintainability of the Ethernet and
guarantees network stability.
Link-level Ethernet OAM technologies, such as Ethernet in the First Mile (EFM) OAM, defined
in IEEE 802.3ah, provide functions that include link connectivity check, link fault monitoring,
remote fault notification, and remote loopback for two directly-connected devices. On MANs,
link-level Ethernet OAM technologies are mainly applied between Customer Edges (CEs) and
Provider Edges (PEs). This guarantees the reliability and stability of connections between the
user network and carrier network.
Purpose
Since it first appeared, the Ethernet technology has gradually become the major LAN technology
because of its easy implementation and low costs. In recent years, Gigabit Ethernet and 10G
Ethernet have been introduced, which have enabled Ethernet to expand its sphere of application
to MANs or WANs.
Ethernet was initially used in LANs. Compared with MANs and WANs, LANs have less
stringent reliability and stability requirements. Ethernet, therefore, lacks an OAM mechanism,
which hinders Ethernet from developing into an ISP network. As such, it becomes necessary to
implement OAM on the Ethernet.

3.2 References
Document Description Remarks
IEEE Std 802.3ah-2004 Carrier Sense Multiple

Access with Collision
Detection (CSMA/CD)
Access Method and
Physical Layer
Specifications
Amendment: Media Access
Control Parameters,
Physical Layers, and
Management Parameters
for Subscriber Access
Networks
3.3 Principles
3.3.1 Peer Discovery

The EFM OAM working mode is an attribute of the interface on which EFM OAM is enabled.
EFM OAM has two working modes: active mode and passive mode. The default EFM OAM
working mode of an interface is active mode.
Before configuring EFM OAM on an interface, configure the working mode of the interface:
l If the active mode is configured, the interface initiates the peer discovery process by
initiating OAM Protocol Data Units (OAM PDUs) after being enabled with EFM OAM.
l If the passive mode is configured, the interface does not initiate OAM PDUs after being
enabled with EFM OAM. Instead, the interface waits for the peer end to send OAM PDUs.
This prevents two interfaces in passive mode from negotiating the establishment of a
session. In addition, interfaces in passive mode cannot initiate requests for remote loopback.
When EFM OAM is enabled on an interface in active mode, the interface initiates the peer
discovery process. The interface and its peer interface then enter the EFM OAM discovery phase.

Figure 3-1 Schematic diagram of peer discovery
Initiates peer discovery Interface 2

by initiating an OAM PDU in passive mode
Interface 1
in active mode Responds to peer discovery
by replying with an OAM PDU
OAM PDU data flow
In Figure 3-1, assume that the EFM OAM working mode of Interface 1 is active and that the
mode of Interface 2 is passive. After EFM OAM is enabled on Interface 1, the EFM OAM state
of Interface 1 becomes Discovery. The peer discovery process is performed as follows:
1. Interface 1 sends an OAM PDU to Interface 2. This OAM PDU carries the EFM OAM
configuration of Interface 1.
2. After receiving the OAM PDU, Interface 2 compares its EFM OAM configuration with
that of Interface 1 and then responds with an OAM PDU. The OAM PDU sent from
Interface 2 to Interface 1 carries not only the EFM OAM configurations of both Interface
1 and Interface 2, but also the Flags field, which indicates whether Interface 2 is satisfied
with the EFM OAM configuration of Interface 1.
Figure 3-2 shows the OAM PDU format.
Figure 3-2 OAM PDU format
Information TLV type

Destination MAC=01-80-C2-00-00-02 Information TLV
length
Source MAC
OAM version number
Protocol number=88-09
OAM revision number
Sub-protocol number=03
State field
Local Information
Flags field
TLV OAM configuration
Remote
Code field OAM PDU
Information TLV
configuration
Data ......
OUI
Check field
Vendor Specific Info

Figure 3-3 Description of OAM configuration
Value Name Description

7:5 reserved and set to 0 in Local Information
TLVs
4 Variable Retrieval
1=DTE supports sending of Variable Response
OAM PDUs
0=DTE does not support sending of Variable
Response OAM PDUs
3 Link Events
1=DTE supports parsing of link events
0=DTE does not support parsing of link events
2 OAM Remote Loopback
OAM Configuration OAM configuration 1=DTE has the OAM remote loopback capability
0=DTE does not have the OAM remote
loopback capability
1 Unidirectional Support
1=DTE is capable of sending OAM PDUs when
no data packet is transmitted on the receive link
0=DTE is not capable of sending OAM PDUs
when no data packet is transmitted on the receive
link
0 OAM Mode
1=DTE is configured to work in active mode
0=DTE is configured to work in passive mode
3. After receiving the OAM PDU sent by Interface 2, Interface 1 compares its EFM OAM
configuration with that of Interface 2 to check whether their configurations match.
After the preceding process is complete, Interface 1 and Interface 2 enter the Detect state if their
EFM OAM configurations match. In the Detect state, the two interfaces periodically send OAM
PDUs to maintain their neighbor relationship. If their EFM OAM configurations do not match,
the two interfaces remain in the Discovery state and keep sending OAM PDUs for status
negotiation until the negotiation succeeds or EFM is disabled on one or both of the interfaces.
3.3.2 Link Monitoring

After link monitoring is configured, the system queries physical-layer statistics about the
interface management module and checks the link quality of an interface. Within a specified
period, if the number of error frames, error codes, or error frame seconds detected on an interface
reaches or exceeds the specified threshold, it indicates that the link where the interface resides
is faulty. An OAM PDU is sent to notify the peer device of the link fault. An error frame second
is a 1-second interval during which at least one error frame is detected.
3.3.3 Fault Notification

The following faults can be reported:
l Protocol packet timeout: If no protocol packet is received within a specified period, the
EFM module logs the fault event and send an Event Notification OAMPDU to report the
fault event to the peer device.

l Interface faults: If an interface fault occurs, the EFM module logs the fault event and sends
an Information OAMPDU to report the fault event to the peer device.
l Board or system reset: If a board or system is reset, the EFM module logs the fault event
and sends an Information OAMPDU to report the fault event to the peer device.
3.3.4 Remote Loopback

In Figure 3-4, when the local interface sends non-OAM PDUs to the remote interface, the remote
interface transmits the non-OAM PDUs back to the local interface, instead of forwarding non-
OAM PDUs based on their destination addresses. This is called remote loopback.
Remote loopback can be used to locate link faults and test the link quality. In remote loopback
mode, the local interface sends test packets to the remote interface. The local device then
computes communication quality parameters, such as the packet loss ratio, of the current link
based on the number of packets sent and received.
Figure 3-4 Schematic diagram of remote loopback
Non-OAM PDUs
Interface 1 Interface 2
in active mode in passive mode
Data flow
Remote loopback can be enabled on an interface only when the interface is in active mode and
both the local interface and its remote peer are in the Detect state. Remote loopback functions
as follows:
1. The local interface sends a loopback request to the remote interface and waits for a response.
2. After receiving the loopback request from the local interface, the remote interface sends a
loopback reply to the local interface and then enters the remote loopback state.
3. If the local interface receives the loopback reply within two seconds, it enters the remote
loopback state. If the local interface does not receive a loopback reply in two seconds, it
retransmits a loopback request to the remote interface. An interface can retransmit a
loopback request a maximum of three times.
To stop remote loopback, the local interface sends the remote interface a message that disables
remote loopback. After receiving this message, the remote interface exits the loopback state.
Users may forget to stop remote loopback after a remote loopback test, which will make the link
unable to forward service data for a long time. To avoid such a situation, remote loopback can
be automatically disabled after a timeout period. The timeout period of remote loopback is
configurable. After remote loopback times out, the local interface automatically sends the remote
interface a message to disable remote loopback.
3.3.5 Association Between EFM OAM and an Interface

When an interface that has EFM OAM enabled detects a link connectivity fault, the interface
will forward no packets except EFM protocol packets. As a result, Layer 2 and Layer 3 services

are blocked. Therefore, associating EFM OAM with an interface may greatly affect services.
After detecting link connectivity recovery, EFM OAM resumes packet forwarding and unblocks
Layer 2 and Layer 3 services on the interface. Before associating EFM OAM with an interface,
ensure that the EFM OAM protocol state of the interfaces at both ends of the link is Detect.
Current optical interfaces support the full-duplex mode. Optical interfaces are considered
physically Up if they can receive packets. It is possible, however, for the working state and
physical state of an optical interface to be inconsistent.
In Figure 3-5, Device A and Device B are connected through two optical interfaces, GE 1/0/1
and GE 1/0/1. If Line 2 becomes faulty, GE 1/0/1 on Device B cannot receive any packets, and
its physical state becomes Down. GE 1/0/1 on Device A can still receive packets sent by Device
B over Line 1. Therefore, the physical state of GE 1/0/1 on Device A remains Up. In this case,
however, GE 1/0/1 on Device A is unable to transmit services, and the services on Device A are
not aware of the actual working state of this interface. As a result, service transmission is affected.
Figure 3-5 Schematic diagram of EFM OAM connectivity check for a single fiber
Device A Device B
GE1/0/1 GE1/0/1
2
TX
GE1/0/1 1 GE1/0/1
RX
3.4 Applications
EFM OAM can be used to detect faults on and monitor the performance of E-LAN services.
Figure 3-6 Networking diagram for E-LAN

UPE CE
UPE
Metro
CE
UPE CE
802.3ah detection

802.3ah is used between CEs and UPEs to implement OAM between links.


Feature Description - Network Reliability

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Feature Description - Network Reliability

Hochgeladen von

Copyright:

Verfügbare Formate

HUAWEI NetEngine5000E Core Router

Feature Description - Network

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2011-10-15) Huawei Proprietary and Confidential i

About This Document

Related Versions (Optional)

Product Name Version

HUAWEI NetEngine5000E V800R002C01

Indicates a hazard with a high level of risk, which if not

Indicates a hazard with a medium or low level of risk, which

Issue 01 (2011-10-15) Huawei Proprietary and Confidential ii

Indicates a potentially hazardous situation, which if not

Provides additional information to emphasize or supplement

Changes in Issue 01 (2011-10-15)

Issue 01 (2011-10-15) Huawei Proprietary and Confidential iii

About This Document.....................................................................................................................ii

Issue 01 (2011-10-15) Huawei Proprietary and Confidential iv

Issue 01 (2011-10-15) Huawei Proprietary and Confidential v

About This Chapter

1.1 Introduction to BFD

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 1

1.1 Introduction to BFD

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 2

Document Description Remarks

RFC 5880 Bidirectional Forwarding -

RFC 5881 Bidirectional Forwarding -

RFC 5882 Generic Application of -

RFC 5883 Bidirectional Forwarding -

RFC 5884 Bidirectional Forwarding -

BFD Detection Mechanism

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 3

Types of Links Detected by BFD

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 4

BFD Session Establishment Modes

l Static BFD session

BFD Session Management

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 5

Figure 1-1 Establishment of a BFD session

DOWN Sta: Down DOWN

DOWN => INIT

1.3.1 BFD for IP

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 6

Figure 1-2 Networking diagram of single-hop BFD for IPv4

Typical application II:

Figure 1-3 Networking diagram of multi-hop BFD for IPv4

POS1/0/0 POS1/0/0 POS2/0/0 POS2/0/0

RouterA RouterB RouterC

Typical application III:

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 7

Figure 1-4 Networking diagram of single-hop BFD for IPv6

Typical application VI:

Figure 1-5 Networking diagram of multi-hop BFD for IPv6

GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0

RouterA RouterB RouterC

1.3.2 BFD for PST

1.3.3 Multicast BFD

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 8

Figure 1-6 Networking diagram of multicast BFD

1.3.4 BFD for PIS

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 9

Figure 1-7 Networking diagram of BFD for PIS

1.4.1 BFD for USR