SJ-20140731105308-016-ZXR10 M6000-S (V3.00.10) Carrier-Class Router Configuration Guide (Reliability) - 608083

ZXR10 M6000-S
Carrier-Class Router
Configuration Guide (Reliability)

Version: 3.00.10
ZTE CORPORATION
No. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://support.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright 2014 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited.
Additionally, the contents of this document are protected by
contractual confidentiality obligations.

All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided as is, and all express, implied, or statutory warranties, representations or conditions
are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit the ZTE technical support website http://support.zte.com.cn to inquire for related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No.
Revision Date
Revision Reason
R1.0
2014-10-20
First edition.
Serial Number: SJ-20140731105308-016

Publishing Date: 2014-10-20 (R1.0)
SJ-20140731105308-016|2014-10-20 (R1.0)
ZTE Proprietary and Confidential
Contents
About This Manual ......................................................................................... I
Chapter 1 Reliability Overview .................................................................. 1-1
Chapter 2 Service Availability Manager Configuration ........................... 2-1
2.1 SAMGR Overview .............................................................................................. 2-1
2.2 Configuring the SAMGR ..................................................................................... 2-4
2.3 SAMGR Configuration Instances ......................................................................... 2-5
2.3.1 Linkage Between EFM and VRRP ............................................................. 2-5
2.3.2 Linkage Between CFM and VRRP............................................................. 2-9
Chapter 3 VRRP Configuration ................................................................. 3-1

3.1 VRRP Overview ................................................................................................. 3-1
3.2 VRRP Network Application ................................................................................. 3-4
3.3 Configuring the VRRP ........................................................................................ 3-8
3.4 VRRP Configuration Instances ...........................................................................3-11
3.4.1 Basic VRRP Configuration Example .........................................................3-11
3.4.2 Symmetrical VRRP Configuration Example .............................................. 3-14
3.4.3 VRRP Heartbeat Configuration Example.................................................. 3-16
3.4.4 VRRP BFD Configuration Example.......................................................... 3-18
3.4.5 VRRP-Related LINK BFD Function Configuration Example ....................... 3-21
Chapter 4 Ping Detect Configuration........................................................ 4-1

4.1 Ping Detect Overview ......................................................................................... 4-1
4.2 Configuring the Ping Detect Function................................................................... 4-3
4.3 Ping Detect Configuration Instances .................................................................... 4-4
4.3.1 Basic Ping Detect Configuration Example .................................................. 4-4
4.3.2 Configuration Example of the Track Ping Function Used For Directly
Connected Routes .................................................................................. 4-6
Chapter 5 EFM Configuration.................................................................... 5-1

5.1 EFM Overview ................................................................................................... 5-1
5.2 Configuring the EFM........................................................................................... 5-3
5.3 EFM Configuration Instances .............................................................................. 5-6
5.3.1 EFM Connection Establishment ................................................................ 5-6
5.3.2 EFM Remote Loopback .......................................................................... 5-10
Chapter 6 CFM Configuration.................................................................... 6-1

6.1 CFM Overview ................................................................................................... 6-1
I
SJ-20140731105308-016|2014-10-20 (R1.0)
6.2 Configuring the CFM .......................................................................................... 6-4

6.3 CFM Configuration Instances .............................................................................. 6-7
6.3.1 CFM Fast Connectivity Detection .............................................................. 6-7
6.3.2 Cross-L2 VPN Connectivity Detection.......................................................6-11
Chapter 7 BFD Configuration .................................................................... 7-1

7.1 BFD Overview.................................................................................................... 7-1
7.2 Configuring the BFD ........................................................................................... 7-2
7.3 BFD Configuration Instances............................................................................. 7-10
7.3.1 Configuring the PIM BFD ........................................................................ 7-10
7.3.2 Configuring Static Single-Hop BFD.......................................................... 7-14
7.3.3 Configuring Static Multi-Hop BFD ............................................................ 7-16
Chapter 8 FRR Configuration .................................................................... 8-1

8.1 IP FRR Configuration ......................................................................................... 8-1
8.1.1 IP FRR Overview ..................................................................................... 8-1
8.1.2 Nested FRR Overview .............................................................................. 8-3
8.1.3 Configuring IP FRR .................................................................................. 8-4
8.2 Static Route FRR Configuration .......................................................................... 8-4
8.3 L2 VPN FRR Configuration ................................................................................. 8-5
8.3.1 L2 VPN FRR Overview ............................................................................. 8-5
8.3.2 Configuring L2 VPN FRR .......................................................................... 8-6
8.4 L3VPN FRR Configuation ................................................................................... 8-6
8.4.1 Brief Introduction to L3VPN FRR ............................................................... 8-6
8.4.2 Configuring L3 VPN FRR .......................................................................... 8-7
8.5 TE FRR Configuration ........................................................................................ 8-7
8.5.1 TE FRR Overview .................................................................................... 8-7
8.5.2 TE FRR Work Flow .................................................................................. 8-9
8.5.3 Configuring TE FRR ............................................................................... 8-14
Chapter 9 OAM Binding Configuration..................................................... 9-1

9.1 Overview ........................................................................................................... 9-1
9.2 Configuring the Interface Association Detection Function ...................................... 9-4
9.3 Binding the OAM Function to an Interface ............................................................ 9-5
Chapter 10 Graceful Restart Configuration ........................................... 10-1

10.1 IP Graceful Restart Configuration .................................................................... 10-1
10.2 LDP Graceful Restart Configuration ................................................................. 10-3
Chapter 11 NSR Configuration ................................................................ 11-1

11.1 NSR Overview.................................................................................................11-1
II
SJ-20140731105308-016|2014-10-20 (R1.0)
11.2 Configuring the NSR Function ..........................................................................11-2

11.3 NSR Configuration Example .............................................................................11-3
Chapter 12 Master/Slave Main Control Handover ................................. 12-1

12.1 Master/Slave Main Control Handover Overview................................................ 12-1
12.2 Configuring the Active/Standby Switchover ...................................................... 12-2
12.3 Master/Slave Main Control Handover Configuration Example ............................ 12-3
Chapter 13 Load Sharing Configuration ................................................ 13-1

13.1 Load Sharing Overview................................................................................... 13-1
13.2 Configuring Route Load Sharing...................................................................... 13-1
13.3 Configuring Multicast Load Sharing ................................................................. 13-2
13.4 Configuring MPLS VPN Load Sharing.............................................................. 13-2
Figures............................................................................................................. I
Glossary ........................................................................................................ III
III
SJ-20140731105308-016|2014-10-20 (R1.0)
This page intentionally left blank.
IV
SJ-20140731105308-016|2014-10-20 (R1.0)
About This Manual

Purpose
This manual describes the principle, configuration commands and configuration instances
about reliability function of ZXR10 M6000-S.
Intended Audience
This manual is intended for:
l
l
l
Network planning engineers

Commissioning engineers
Maintaining engineers
What Is in This Manual

This manual contains the following chapters:
Chapter 1, Reliability
Describes the meaning and requirements of Reliability, and the
Overview
relationship of various functions related to Reliability.
Chapter 2, Service Availability
Describes the SAMGR principle, configuration commands and
Manager Configuration
configuration instances.
Chapter 3, VRRP
Describes the VRRP principle, configuration commands and
Configuration
Chapter 4, Ping Detect
Describes the ping detect principle, configuration commands and
Configuration
Chapter 5, EFM Configuration
Describes the EFM principle, configuration commands and

Chapter 6, CFM Configuration
Describes the CFM principle, configuration commands and

Chapter 7, BFD Configuration
Describes the BFD principle, configuration commands and

Chapter 8, FRR Configuration
Describes the FRR principle, configuration commands and

Chapter 9, OAM Binding
Describes the OAM Binding principle, configuration commands and
Configuration
Chapter 10, Graceful Restart
Describes the GR principle, configuration commands and
Configuration
Chapter 11, NSR
Describes the NSR principle, configuration commands and
Configuration
I
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 12, Master/Slave
Describes the master/slave main control handover principle,
Main Control Handover
configuration commands and configuration instances.
Chapter 13, Load Sharing
Describes the load sharing principle, configuration commands and
Configuration
Conventions
This manual uses the following conventions:
Italics
Variables in commands. It may also refer to other related manuals and documents.
Bold
Menus, menu options, function names, input fields, option button names, check boxes,
drop-down lists, dialog box names, window names, parameters, and commands.
Constant
Text that you type, program codes, filenames, directory names, and function names.
width
[]
Optional parameters.
{}
Mandatory parameters.
Separates individual parameter in series of parameters.
Danger: indicates an imminently hazardous situation. Failure to comply can result in

death or serious injury, equipment damage, or site breakdown.
Warning: indicates a potentially hazardous situation. Failure to comply can result in
serious injury, equipment damage, or interruption of major services.
Caution: indicates a potentially hazardous situation. Failure to comply can result in

moderate injury, equipment damage, or interruption of minor services.
Note: provides additional information about a certain topic.
II
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 1
Reliability Overview
Reliability Introduction
With the rapid development of IP technology, various value-added services are widely
used on the Internet. Some important carrier-class services, such as Next Generation
Network (NGN), the 3rd Generation Mobile Communications (3G), Internet Protocol
Television (IPTV) stream media, special line, and Virtual Private Network (VPN), have
high requirement for reliability on the Internet Protocol (IP) network. The reliability
requirements of the carrier-class services on the IP network include:
l
l
l
Device reliability
Link reliability
Network reliability
On the bearer network, the availability of a network device is required to reach 99.999%.
In this case, the duration of service shutdown during continuous operation in a whole year
must be less than 5 minutes. High reliability is a basic requirement of a carrier-class device,
and it is a basic requirement for telecom operators to construct networks. As a basic
network for bearer services, the reliability of the bearer network becomes an important
part.
On a router or a Packet Transport Network (PTN), reliability technology includes device
hardware redundancy and network reliability technology. In this manual, the network
reliability technology is described.
Network reliability technology includes network fault detection technology and protection
switching technology.
Network Fault Detection Technology

The network fault detection technology includes the following detection mechanisms in
accordance with network layers:
l
l
l
l
Transport layer and physical layer: Automatic Protection Switching (APS).

Link layer: Bidirectional Forwarding Detection (BFD), Multiprotocol Label Switching
(MPLS) Operations, Administration and Maintenance (OAM) and Ethernet
Operations, Administration and Maintenance (Eth-OAM).
Network layer: HELLO mechanism of various protocols, LLO mechanism, Virtual
Router Redundancy Protocol (VRRP), and BFD.
Application layer: heartbeats of various application protocols.
Protection Switching Technology

The protection switching technologies includes the following types:
1-1
SJ-20140731105308-016|2014-10-20 (R1.0)
ZXR10 M6000-S Configuration Guide (Reliability)
l
l
End-to-end protection: APS 1:1 linear protection, APS 1+1 linear protection and hot
standby.
Local protection: FRR, including IP FRR, LDP FRR, TE FRR, and PW FRR.
1-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 2
Service Availability Manager

Configuration
Table of Contents
SAMGR Overview ......................................................................................................2-1
Configuring the SAMGR .............................................................................................2-4
SAMGR Configuration Instances ................................................................................2-5
2.1 SAMGR Overview

Introduction
Service Availability Manager (SAMGR) is used to manage the relationship between
services and the availability. The SAMGR has the following functions:
l
l
l
l
Track object management

Track group management
Operation, Administration and Maintenance (OAM) binding management
OAM mapping management
The SAMGR implements the linkage between various detection technologies and services.
It ensures the quick switch of services when the network link is faulty.
In practical applications, a router provides multiple detection technologies. At the same
time, there are also many protection switching applications that need to monitor detection
results on a real-time basis to meet the requirements for availability in different network
structures. Therefore, the SAMGR is used to implement the linkage between various
detection technologies and services.
The SAMGR isolates detection technologies from services, and reduces the coupling
between modules. The working principles are as follows:
1. The SAMGR abstracts a detection example to a track object. It associates the track
object with the detection example by configuring a track name for the track object.
The track name is called directly in the service where the detection result needs to be
monitored.
2. When detecting that the link state changes, the detection technology advertises the
state change to the SAMGR directly.
3. The SAMGR informs the application service associated with the track object. The
application service performs state switching in accordance with the state change to
protect the link.
2-1
SJ-20140731105308-016|2014-10-20 (R1.0)
At the same time, the SAMGR also can manage the binding relation between racks and
send the local state to the remote end. In this way, fault transmission and recovery is
accomplished.
Linkage Among VRRP, SAMGR, EOAM and BFD

Figure 2-1 displays the linkage among VRRP, SAMGR, EOAM, and BFD.
Figure 2-1 Linkage Among VRRP, SAMGR, EOAM and BFD
The network structure descriptions are as follows:

1. The EOAM is configured between the routers and the switches to keep links alive.
BFD is configured between router A and router B.
2. Router A and router B operate in active/standby mode. The routers monitor the states
of EOAM and BFD separately.
3. The VRRP runs on the directly connected interfaces between router A/router B and
the switches to form a VRRP group.
4. The SAMGR monitors the results of EOAM and BFD in VRRP service in real time,
thus ensuring the reliability for VRRP.
When EOAM detects a fault, it reports the fault to the SAMGR. The SAMGR informs the
service to switch the state directly in accordance with the relation between the track object
and the service.
When a fault of the pee-type BFD occurs on the router, the SAMGR advertises the state
to the service, and then the service performs switching in accordance with its policy on the
basis of the EOAM state and the BFD state.
Linkage of Symmetrical Dual-Connection Between CE and PE

A CE connects to two PEs symmetrically to perform linkage of states between detections,
see Figure 2-2.
2-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 2 Service Availability Manager Configuration
Figure 2-2 Linkage of Symmetrical Dual-Connection Between CE and PE
The network structure descriptions are as follows:

1. A PW is established between PE-1 and PE-3, and a PW is established between PE-2
and PE-4.
2. The CE1 connects to PE-1 and PE-2.
3. The CE2 connects to PE-3 and PE-4.
4. The OAM detection (Ethernet in the First Mile (EFM)/Connectivity Fault Management
(CFM)/link keepalive) is enabled between CEs and PEs.
5. The BFD is enabled between PEs to detect PWs. MPLS OAM is enabled between
PEs to detect TE Label Switched Paths (LSPs).
6. The OAM mapping/binding is associated between the Access Circuit (AC)-side link
detection and PW link detection (or between LDPs) to transmit a fault.
The principle of fault detection and switching is as follows:
If a fault occurs on the AC between CE1 and PE1,
1. The AC EOAM of PE1 detects the AC fault and informs the SAMGR.
2. The SAMGR of PE1 maps the detection track object of PW corresponding to the AC
in accordance with the OAM mapping/binding configuration.
3. If BFP or MPLS-OAM is configured between PEs, PE-1 transmits the OAM fault to
PE-2 transparently.
4. When PE3 receives the BFD/MPLS OAM/LDP fault, if there is a standby PW
on the remote PE, PE3 switches the traffic. Otherwise, PE3 performs OAM
mapping/binding to map the corresponding AC and advertises the fault to CE2.
If a fault occurs on a PW,
1. BFD/MPLS OAM on a PE detects the PW/LSP fault.
2. The PE performs OAM mapping/binding to map the corresponding local AC.
3. If there is a standby PW on the PE, the PE switches traffic. Otherwise, the PE performs
OAM mapping/binding to map the corresponding AC and advertises the fault to the
local CE.
2-3
SJ-20140731105308-016|2014-10-20 (R1.0)
2.2 Configuring the SAMGR

This procedure describes how to configure the SAMGR.
Steps
1. Configure a track object.
Step
Command
Function
ZXR10(config)#samgr
Enters samgr configuration mode.
ZXR10(config-samgr)#track <name> efm
Configures a track object with detection
interface <interface-name>
type "efm".
ZXR10(config-samgr)#track <name> cfm
md <1-65535> ma <1-65535> remote-mep
type "cfm".
<1-8191>
4
ZXR10(config-samgr)#track <name>
ping-detect group <1-100>
type "ping-detect". Ping-detection

group number range: 1100.
ZXR10(config-samgr)#track <name> sqa
instance <1-150>
type "sqa". SQA instance number

range: 1150.
mpls-oam tunnel-id <1-8000> ingress-id
type "mpls-oam". mpls-oam tunnel
<ingress-vlaue>
number range: 18000.
ZXR10(config-samgr)#track <name> pw
pw-name <pw-name>
type "pw".
ZXR10(config-samgr)#track <name> vrrp
interface <interface-name> vrid <1-255>
type "vrrp".
ZXR10(config-samgr)#track <name> bfd
session <bfd-session-name>
type bfd, where <bfd-session-name>

indicates the bfd name (range: 132
characters)
10
ZXR10(config-samgr)#track <name> tp-oam
meg<1-65535>
type "tp-oam". meg value range:

165535.
11
interface<interface-name>
type "interface".
2. Configure a track group.
2-4
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config)#samgr
Enters SAMGR configuration mode.
ZXR10(config-samgr)#track-gr
Configures a track group and enters track group
oup <group-name>
configuration mode.
ZXR10(config-samgr-group-
Adds a track object to the track group.
track-group-name)#track
<track-name>
4
ZXR10(config-samgr-group-
Configures the policy of a track group, where
track-group-name)#inactive-num
inactive-number indicates the number of invalid
ber <1-10>
track objects that result in invalidity of the track

group.
3. Configure the binding relation.

Step
Command
Function
ZXR10(config)#samgr
Enters SAMGR configuration

mode.
ZXR10(config-samgr)#sa-bind track <name> to {track |
Configures the binding
track-group}<name>
relation between track objects

or between track groups.
4. Verify the configurations.

Command
Function
ZXR10#show samgr brief
Displays the brief information related to track

objects.
ZXR10#show samgr track [<trackname>[verb
Displays the detailed information about a track
ose]]
object such as state change.
ZXR10#show samgr track-group
Displays the detailed information about a track
[<trackname>[verbose]]
group such as state change.
End of Steps
2.3 SAMGR Configuration Instances

2.3.1 Linkage Between EFM and VRRP
Configuration Description
As shown in Figure 2-3, the VRRP protocol is used between R2 and R3. The VRRP virtual
address is the interface address 10.0.0.1. R2 works as a master router.
2-5
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 2-3 Linkage Between EFM and VRRP
Configuration Flow
1. Configure EFM connection on the direct-connected interfaces of the link between S1
and R2.
2. Configure a EFM track object on the direct-connected interface of R2 in SAMGR configuration mode.
3. Configure the same VRRP group number and virtual address on R2 and R3. To set
R2 as a master router, bind the VRRP on R2 to the EFM track object.
4. When the EFM function is disabled on S1, the VRRP group on R2 is changed to the
Init status, and the VRRP group on R3 is changed to the Master status. When the
EFM function is enabled, the VRRP group on R2 is changed to the Master status, and
the VRRP group of R3 is changed to the Backup status.
Configuration Commands
Run the following commands on S1:
S1(config)#set ethernet-oam enable
S1(config)#interface gei_4/1
S1(config-gei_4/1)#set ethernet-oam
enable
Run the following commands on R2:

R2(config)#interface gei-0/2/0/1
R2(config-if-gei-0/2/0/1)#no shutdown
R2(config-if-gei-0/2/0/1)#ip address 10.0.0.1 255.255.0.0
R2(config-if-gei-0/2/0/1)#exit
R2(config)#efm
R2(config-efm)#set ethernet-oam function enable
R2(config-efm)#interface gei-0/2/0/1
R2(config-efm-if-gei-0/2/0/1)#set ethernet-oam function enable
R2(config-efm-if-gei-0/2/0/1)#exit
2-6
SJ-20140731105308-016|2014-10-20 (R1.0)

R2(config-efm)#exit
R2(config)#samgr
R2(config-samgr)#track efm efm interface gei-0/2/0/1
R2(config-samgr)#exit
R2(config)#vrrp
R2(config-vrrp)#interface gei-0/2/0/1
R2(config-vrrp-if-gei-0/2/0/1)#vrrp 1 ipv4 10.0.0.1
R2(config-vrrp-if-gei-0/2/0/1)#vrrp 1 out-interface gei-0/3/0/2
R2(config-vrrp-if-gei-0/2/0/1)#vrrp 1 track object efm link-type
R2(config-vrrp-if-gei-0/2/0/1)#exit

R3(config-if-gei-0/5/0/1)#
R3(config)#vrrp
R3(config-vrrp-if-gei-0/5/0/1)#end
Configuration Verification
Check the VRRP configuration results on R2 and R3. The results show that R2 is a master
router and R3 is a backup router. The output of the show samgr command on R2 shows
that the EFM track object is in up state.
R2#show vrrp
ipv4 brief
Interface
vrID Pri Time
A P L State
gei-0/2/0/1
A P
255 1000
Master addr
Master 10.0.0.1
VRouter addr
10.0.0.1
R2(config)#show samgr brief

The total of track at this Router is 3.
================================================================================
Track-name
Detect-type
App-num
State
TransState
efm
efm
up
T-ok
R3#show vrrp ipv4 brief
2-7
SJ-20140731105308-016|2014-10-20 (R1.0)

Interface
vrID Pri Time
gei-0/5/0/1
A P L State
100 1000
Master addr
Backup 10.0.0.2
VRouter addr
10.0.0.1
When EFM is disabled on S1, the VRRP group on R2 is changed from Master to Init, and
that of R3 is changed to Master. The output of the show samgr command on R2 shows
that the EFM track object is in L-DOWN status.
S1(config-efm)#set ethernet-oam function disable
S1(config-efm)#exit

Interface
vrID Pri Time
gei-0/2/0/1
A P L State
100 1000
Master addr
Init
0.0.0.0
VRouter addr
10.0.0.1
R2#show samgr brief

============================================================================
Track-name
Detect-type
App-num
State
efm
efm
L-down
TransState

Interface
vrID Pri Time
gei-0/5/0/1
A P L State
100 1000
Master addr
Master 10.0.0.2
VRouter addr
10.0.0.1
When the EFM function on S1 is enabled, the VRRP group of R2 is changed to Master,
and that of R3 is changed to Backup. The EFM track object on R2 is in up status.
S1(config-efm)#set ethernet-oam function enable
S1(config-efm)#exit

Interface
vrID Pri Time
gei-0/2/0/1
A P L State
100 1000
Master addr
Master
10.0.0.1
VRouter addr
10.0.0.1
R2#show samgr brief

============================================================================
Track-name
Detect-type
App-num
State
efm
efm
up
TransState

Interface
vrID Pri Time
gei-0/5/0/1
100 1000
A P L State
P
Backup
Master addr
VRouter addr
10.0.0.2
10.0.0.1
2-8
SJ-20140731105308-016|2014-10-20 (R1.0)
2.3.2 Linkage Between CFM and VRRP

As shown in Figure 2-4, the VRRP protocol is used between R2 and R3. The VRRP virtual
address is the interface address 10.0.0.1 of R2. R2 works as a master router.
Figure 2-4 Link Between CFM and VRRP
Configuration Flow
1. Configure CFM continuous detection on the direct-connected interfaces of the link
between S1 and R2.
2. Configure a CFM track object on the direct-connected interface of R2 in SAMGR
configuration mode.
3. Configure the same VRRP group number and virtual address on R2 and R3. To set
R2 as a master router, bind VRRP on R2 to the CFM track object.
4. When the CFM function on S1 is disabled, the VRRP group of R2 is changed to the
Init status, and that of R3 is changed to the Master status. When the CFM function on
S1 is enabled, the VRRP group of R2 is changed to Master and that of R3 is changed
to Backup.
Run the following commands on S1:
S1(config)#cfm enable
S1(config)#cfm ccm-format 1
S1(config)#cfm create md session 1 name md2 level 7
S1(config-md)#ma create session 1 name a4
S1(config-md-ma)#create mep session 1 8 direction down
S1(config-md-ma)#create rmep session 1 16 remote-mac 00d0.d011.3377
S1(config-md-ma)#assign mep 8 to interface gei_4/1
S1(config-md-ma)#mep 8 state enable
S1(config-md-ma)#mep 8 ccm-send enable
S1(config-md-ma)#mep 16 state enable

2-9
SJ-20140731105308-016|2014-10-20 (R1.0)

R2(config)#cfm
R2(config-cfm)#set cfm enable
R2(config-cfm)#create md index 2 name-format 2 name md2 level 7
R2(config-cfm)#md index 2
R2(config-cfm-md-2)#create ma index 4 name-format 2 name a4
R2(config-cfm-md-2)#ma index 4
R2(config-cfm-md-2-ma-4)#create mep mepid 16 direction down interface gei-0/2/0/1
R2(config-cfm-md-2-ma-4)#create rmep mepid 8 remote-mac 00a1.1122.0011
R2(config-cfm-md-2-ma-4)#set mep 16 state enable
R2(config-cfm-md-2-ma-4)#set mep 16 ccm-send enable
R2(config-cfm-md-2-ma-4)#exit
R2(config-cfm-md-2)#exit
R2(config-cfm)#exit
R2(config)#samgr
R2(config-samgr)#track cfm cfm md 2 ma 4 remote-mep 8
R2(config)#vrrp
R2(config-vrrp-if-gei-0/2/0/1)#vrrp 1 track object cfm link-type
R2(config-vrrp-if-gei-0/2/0/1)#exit

2-10
SJ-20140731105308-016|2014-10-20 (R1.0)

R3(config)#vrrp
R3(config-vrrp-if)-gei-0/5/0/1#end
Check the VRRP configuration result of R2 and R3. The results show that R2 is a Master
router and R3 is a Backup router. The output of the show samgr command shows that the
CFM track object is in up status.
R2#show vrrp
ipv4 brief
Interface
vrID Pri Time
A P L State
gei-0/2/0/1
A P
255 1000
Master addr
VRouter addr
Master 10.0.0.1
10.0.0.1

================================================================================
Track-name
Detect-type
App-num
State
TransState
cfm
cfm
up
T-ok

Interface
vrID Pri Time
gei-0/5/0/1
100 1000
A P L State
P
Master addr
Backup 10.0.0.2
VRouter addr
10.0.0.1
When the CFM function of S1 is disabled, the VRRP of R2 is changed from Master to Init,
and that of R3 is changed to Master. The CFM track object of R2 is in local down status.
S1(config)#cfm disable
S1(config-cfm)#set cfm disable
S1(config-cfm)#exit

Interface
vrID Pri Time
gei-0/2/0/1
100 1000
A P L State
P
Init
Master addr
0.0.0.0
VRouter addr
10.0.0.1
R2#show samgr brief

================================================================================
Track-name
Detect-type
App-num
State
TransState
cfm
cfm
L-down
T-ok

Interface
vrID Pri Time
gei-0/5/0/1
100 1000
A P L State
P
Master
Master addr
VRouter addr
10.0.0.2
10.0.0.1
2-11
SJ-20140731105308-016|2014-10-20 (R1.0)
When the CFM function of S1 is enabled, the VRRP of R2 is changed to Master, and that
of R3 is changed to Backup. The CFM track object of R2 is in up status.
S1(config)#cfm enable
S1(config-cfm)#set cfm enable
S1(config-cfm)#exit

Interface
vrID Pri Time
A P L State
gei-0/2/0/1
A P
255 1000
Master addr
Master 10.0.0.1
VRouter addr
10.0.0.1
R2#show samgr brief

================================================================================
Track-name
Detect-type
App-num
State
TransState
cfm
cfm
up
T-ok

Interface
vrID Pri Time
gei-0/5/0/1
100 1000
A P L State
P
Backup
Master addr
VRouter addr
10.0.0.2
10.0.0.1
2-12
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 3
VRRP Configuration
Table of Contents
VRRP Overview .........................................................................................................3-1
VRRP Network Application .........................................................................................3-4
Configuring the VRRP ................................................................................................3-8
VRRP Configuration Instances .................................................................................3-11
3.1 VRRP Overview

VRRP Introduction
With the development of Internet, the requirements for network reliability is ever increasing.
For Local Area Network (LAN) users, it is important to keep communications with external
networks.
The same default route is set for all hosts in the internal network to the egress network
gateway (router A in Figure 3-1). With the default route, hosts in the internal network
communicate with external network. If a fault occurs on the egress network gateway, the
communication between the hosts and the external network will be interrupted.
Figure 3-1 Default Network Gateway in LAN
A common method to improve system reliability is to configure multiple egress network

gateways. Because hosts in LANs normally do not support dynamic routing protocols, it is
a problem to select a route among multiple egress network gateways.
The Virtual Router Redundancy Protocol (VRRP) is a fault-tolerant protocol. The VRRP
can implement routing among multiple egress network gateways by isolating physical
devices from logical devices. After that, the problem is solved.
3-1
SJ-20140731105308-016|2014-10-20 (R1.0)
In LANs with multicasting or broadcasting ability (such as Ethernet), the VRRP provides
a logical network gateway to ensure that transmission links are used fully. This not only
avoids service interruption due to faults on a network gateway device, but also avoids
modification of routing protocol configuration.
VRRP Election Flow

The VRRP forms a virtual router with the router A and router B in a LAN, see Figure 3-2.
Figure 3-2 VRRP Election Flow
The virtual router has its own IP address 10.100.10.1 (this IP address can be the same
with an interface address on a router). Route A and router B also have their own IP
addresses (IP address of router A is 10.100.10.2 and IP address of router B is 10.100.10.3).
Hosts in the LAN only knows the IP address 10.100.10.1 of the virtual router. Hosts do
not know the IP addresses of router A and Router B. Router A and router B set the IP
address 10.100.10.1 of the virtual router as their default routes. Therefore, hosts in the
LAN communicate with other networks through this virtual router. The virtual router needs
to perform the following operations:
1. The virtual router selects a master router in accordance with the priority. The router
with the highest priority becomes the master router and its state is Master. If the priority
of routers are the same, the router which configures VRRP and enables the VRRP
function to send VRRP protocol messages first will be the master router. The master
router provides routing service.
2. The other router operates as a backup router. It detects the state of the master router
at any time.
l When the master router works properly, it sends a VRRP multicasting message
at a certain interval to inform the backup router in the group that the master router
works properly.
3-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 3 VRRP Configuration
l
l
If the backup router in the group does not receive messages from the master
router for a long time, the backup router changes its state to Master.
When there are several backup routers in the group, there might be several master
routers at this time. In this situation, each master router compares the priorities
in the VRRP messages with its local priority. If its local priority is smaller than the
priorities in the VRRP messages, the master router changes its state to Backup.
Otherwise, the master keeps its state.
In this way, the router with the highest priority becomes the new master router. The
VRRP backup function is completed.
VRRP Router States

The routers that form the virtual router have three states, Initialize, Master, and Backup.
The states descriptions are as follows:
l
Initialize
A router enters this state after the system is started. When an interface receives a
startup message, the router becomes Backup state (when the priority is not 255) or
Master state (when the priority is 255). In Initialize state, the router does not handle
VRRP messages.
Master
When a router is in Master state, it performs the following operations:
1. It sends VRRP multicasting messages periodically.
2. It sends free Address Resolution Protocol (ARP) messages to make virtual
Medium Access Control (MAC) address that corresponds to the virtual IP address
known by all hosts in the network.
3. It replies to the ARP request for the virtual IP address with the virtual MAC address
instead of the real MAC address on the interface.
4. It forwards IP messages of which the destination MAC address is the virtual MAC
address.
In Master state, when the router receives a VRRP message in which the priority is
higher than the priority of the router, the router enters the Backup state. When it
receives a Shutdown event, the router enters the Initialize state.
Backup
When a router is in Backup state, it performs the following operations:
1. It receives VRRP multicasting messages from the master router to know the state
of the master router.
2. It does reply to the ARP requests for the virtual IP address.
3. It drops IP messages of which the destination IP address is the virtual IP address.
For the state conversion, see Figure 3-3.
3-3
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 3-3 State Conversion in VRRP
In accordance with the above analysis, the hosts in the network do not have any extra
operations, and the communications with external network will not be affected due to the
faults on a router.
3.2 VRRP Network Application

VRRP Monitoring Interface State
The VRRP provides a function to monitor interface states. That is, the VRRP not only
provides the backup function if a fault occurs on an interface in the backup group, but also
for a fault occurring on another interface on routers.
When the monitored interface state is down, the priority of the router decreases by a certain
value automatically, which makes the priorities of other routers in the backup group be
higher than the priority of this router. This urges master/slave router changeover.
The router with the highest priority becomes the master router and the changeover is
completed.
For an application of VRRP monitoring interface, see Figure 3-4.
Figure 3-4 Application of VRRP Monitoring Interface
3-4
SJ-20140731105308-016|2014-10-20 (R1.0)
In Figure 3-4, the VRRP Group 1 monitors the interface marked with a red point on router A.
When the interface works properly, router A acts as the master router. When the interface
is down, the priority of router A is decreased. As a result, the priority of router A is lower
than that of router B. In this way, master/backup changeover is completed.
VRRP Load Sharing

Load sharing means that several routers bear services at the same time to avoid
occurrence of idle routers. Therefore, it is necessary to create two or more backup groups
to implement load sharing, see Figure 3-5.
Figure 3-5 Application of VRRP Load Sharing
The load sharing function has the following features:

l
l
l
Each backup group contains a Master device and several Backup devices.
The Master devices in the backup groups can be different.
A router can be added into different backup groups, and the router has different
priorities in these backup groups.
1. Application scene descriptions of VRRP load sharing
l In Figure 3-5, the VRRP Group 1 (with virtual IP address 10.0.0.1) and the VRRP
Group 2 (with virtual IP address 10.0.0.100) are configured on the same interfaces
on router A and router B.
l The real IP address of physical router A is 10.0.0.2, and the real IP address of
physical router B is 10.0.0.3.
l The default gateway of a part of hosts in the LAN is 10.0.0.1, and the default
gateway of the other part of hosts in the LAN is 10.0.0.100.
2. Working mechanism
Router A and router B have the following agreements during the VRRP negotiation
through priority configuration of the backup groups on router A and router B:
l
l
Router A operates as the master router in Group 1 and operates as a backup

router in Group 2.
Router B operates as the master router in Group 2 and operates as a backup
router in Group 1.
3-5
SJ-20140731105308-016|2014-10-20 (R1.0)
A part of the hosts uses the backup group 1 as the gateway and the traffic is
sent through router A. The other part of the hosts uses the backup group 2 as the
gateway and the traffic is sent through router B.
In this way, the data flows are shared and backed up.
VRRP Heartbeat Configuration

In some applications, there is no layer 2 forwarding device under the routers and the
protocol packet cannot be sent through the interface on which a VRRP group is configured.
In this case, the VRRP heartbeat must be configured. If a heartbeat is configured in
the VRRP group, the VRRP protocol packet is sent through the heartbeat interface. If a
heartbeat is not configured in the VRRP group, the out-interface is the interface on which
a VRRP is configured.
VRRP Track Configuration

There are three applications of VRRP link detection.
l
Application one
The VRRP protocol is used between router A and router B. These two routers are used
for master/backup selection. The EOAM (including Ethernet in the First Mile (EFM)
and Connectivity Fault Management (CFM)) is used to detect the link state between
the switch and the router.
Figure 3-6 EOAM for VRRP Application One
For the state transfer of EOAM for VRRP, see Figure 3-7. EOAM monitors the link
state between the router and the switch. When receiving the link fault notified by
EOAM in the master or backup state, the VRRP transfers to the initialize state directly.
When all VRRP interfaces are in up state and VRRP is in initialize state, the VRRP
receives link recovery notified by EOAM, and the backup group is the IP Owner, the
state will transfer to the master state, otherwise, the state will transfer to the backup
state.
3-6
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 3-7 VRRP and EOAM State Transfer
Application two
The VRRP protocol is used between router A and router B, and these two routers are
used for master/backup selection, see Figure 3-8. The EOAM (including EFM and
CFM) is used to detect the link state between the switches and the routers. BFD is
used to detect the link state between routers. In this application, the EOAM can be
replaced by the link BFD.
Figure 3-8 EOAM for VRRP Application Two
For the state transfer of EOAM (or link BFD) + peer BFD for VRRP, see Figure 3-9.
When receiving the link fault notified by EOAM in the master or backup state, VRRP
transfers to the initialize state directly. When all VRRP interfaces are up, the VRRP is
in initialize state, the VRRP receives link recovery notified by EOAM, and the group
is the IP Owner, the state will transfer to the master state, otherwise, the state will
transfer to the backup state. If the VRRP is in backup state, and the VRRP receives
the link fault notified by peer BFD, the VRRP will transfer to the master state.
3-7
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 3-9 VRRP and EOAM + Peer BFD State Transfer
Application three
The VRRP protocol is used between router A and router B, see Figure 3-10. These
two routers are used for master/backup selection. The EOAM (including EFM and
CFM) is used to detect the link states between router A and router C, and between
router B and router C. The state of EOAM for VRRP transfers in accordance with
the VRRP protocol negotiation. When receiving the link fault notified by EOAM, the
VRRP decreases the priority based on configuration and triggers master/slave router
changeover.
Figure 3-10 EOAM for VRRP Application Three
3.3 Configuring the VRRP

This procedure describes how to configure the VRRP.
Steps
1. Configure the VRRP.
3-8
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config)#vrrp
Enters VRRP configuration mode.
ZXR10(config-vrrp)#interface
Enters VRRP interface configuration
<interface-name>
mode.
ZXR10(config-vrrp-if-interface-name)#v
Configures VRRP virtual IPv4 address
rrp <vrid>ipv4<ip-address>[secondary]
in VRRP interface configuration mode.
<vrid> indicates the virtual router ID,

range: 1255.
4
Configures VRRP priority in VRRP
rrp <vrid> priority <level>
interface configuration mode. The range

of <level> is 1-254. The default value of
priority is 100.
Configures VRRP group preemption
rrp <vrid> preempt [delay <seconds>| disable]

<seconds> indicates preemption delays,
range: 03600, default: 0.
Configures the interval to send VRRP
rrp <vrid> timers advertise {<1-40>| msec
advertisements in VRRP interface
<50-40000>}
configuration mode. The default value

of interval is 1 second.
Unit for <1-40>: second, unit for
<50-40000>: millisecond.
The parameter msec is optional and it
is to change the unit of the interval to
millisecond from second.
Configures whether sending interval is
rrp <vrid> timers learn
learnt from the notification packets. The

default configuration is not learning.
Configures the reload delay time for the
rrp <vrid> reload-delay <0-65535>}
VRRP link, default: 0 s.
ZXR10(config-vrrp-if-interface-
Configures a VRRP track interface in
name)#vrrp <vrid> track interface
VRRP interface configuration mode.
<interface-name>[priority-decrement <1-254>|
When the priority decrement is not

configured, the default value (10) is
rapid-down]
used. The default configuration is not

tracing any link state.
10
Configures VRRP heartbeat in VRRP
rrp <vrid> out-interface <interface-name>
interface configuration mode, that is to

configure a VRRP packet out-interface.
3-9
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
11
Configures a VRRP authentication string
rrp <vrid> text-authentication <string>

The string can contain 1-8 characters.
(This configuration is only valid in VRRP
version 2.)
12
Configures VRRP detection event group
rrp <vrid> track { group | object}<string>{
or detection object and policy type in
link-type | peer-type | priority-decrement
VRRP interface configuration mode.
<1-254>}
13
Configures VRRP version in VRRP
rrp <vrid> version {2|3}
interface configuration mode.

v2 supports IPv4 configuration, v3
supports IPv4 and IPv6 configuration.
14
Enables the accept function in VRRP
rrp <vrid> accept
interface configuration mode, default:

enabled.
15
Enables the check-ttl function in VRRP
rrp <vrid> check-ttl
interface configuration mode, default:

enabled.
16
17
Configures VRRP administration group
rrp <vrid> admin-group { owner | interface
function in VRRP interface configuration
<interface-name> vrid <1-255>}
mode.
Configures the mode to send packets
rrp <vrid> send-mode {all | rotation}
on an egress interface (heart beaten

line) of VRRP.
l
All: All heartbeat lines send

packages at the same time.
Rotation: The heartbeat line sends

packages in polling mode.
<vrid>: ID of the virtual router, range: 1-255.

secondary: A secondary IP address supported by the virtual router.
priority-decrement: Decreases the priority for a specified tracing link. By default, the
priority is decreased by 10.
rapid-down: Indicates that the priority is switched to 1 immediately. If this command
is run on VRRP master router, a special message will be sent to a Backup router. In
this case, the backup router will be switched to a master router immediately.
priority-decrement <1-254>: Priority decrement.
owner: The current group is the administration group which receives packets and
manages link states.
3-10
SJ-20140731105308-016|2014-10-20 (R1.0)
2. Configure the LINK BFD function or PEER BFD function relating to the VRRP.
Command
Function
ZXR10(config-samgr)#track <track-object-name> bfd
Configures a track object in SAMGR
configuration mode.
ZXR10(config-vrrp-if-interface-name)#vrrp
Configures the VRRP detection event
<vrid> track {group | object}<string>{link-type |
group, detection object, and policy type
peer-type | priority-decrement <1-254>}

Command
Function
ZXR10#show vrrp ipv4 brief
Displays the brief information about all

IPv4 VRRP groups on a router.
ZXR10#show vrrp ipv4 brief interface <interface-name>
Displays the brief information about

all IPv4 VRRP groups on a specific
interface.
ZXR10#show vrrp interface <interface-name>[vrid
Displays the detailed information about
<1-255>]
all VRRP groups or a specified group on

a specified interface.
End of Steps
3.4 VRRP Configuration Instances

3.4.1 Basic VRRP Configuration Example
As shown in Figure 3-11, VRRP is run between R1 and R2. R1 interface address is set
to 10.0.0.1 and R2 interface address is set to 10.0.0.2. The VRRP virtual address is the
interface address 10.0.0.1 on R1. R1 is called the IP address owner and has the highest
priority 255. R1 works as the master router. The VRRP virtual address can also be set to
another address and a higher priority is set for R1 so that R1 is the master router.
3-11
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 3-11 Basic VRRP Configuration (IPv4)
Configuration Flow
1. Enter the interfaces on which VRRP should be enabled and configure IP addresses.
2. Enter VRRP configuration mode from global configuration mode and then enter the
interfaces to configure VRRP.
3. Configure the same VRRP group ID and virtual addresses for R1 and R2. To make
R1 the master router or specify a higher priority for R1, configure related commands
on R1 first. If the priorities (the default priority is 100) of two routers are the same, the
router on which VRRP is enabled first and messages are advertised first becomes the
master router in the group.
R1(config)#vrrp

R2(config)#vrrp
3-12
SJ-20140731105308-016|2014-10-20 (R1.0)
View the VRRP information and configuration result on R1, as shown below.
Interface
vrID Pri Time A P L
gei-0/1/0/1
255 1000 A P
State
Master addr
VRouter addr
Master
10.0.0.1
10.0.0.1
/*A: whether the router is the address owner.

P: whether preemption is configured.
L: whether to learn the interval to advertise VRRP messages on the
master.*/
R1#show vrrp interface gei-0/1/0/1 vrid 1

gei-0/1/0/1 - vrID 1
Vrrp configure info:
/*VRRP configuration information*/
IP version 4, VRRP version 3

Virtual IP address is 10.0.0.1
Virtual MAC address is 0000.5e00.0101
Advertise time is 1.000 (s)
Configured priority is 100
Preemption enable, delay 0 (s)
Reload delay 0 (s)
No authentication data
Check ttl enable
Vrrp accept mode enable
Out-interface send-mode is all
Tracked interface items: 0
Interface
State
Policy
Reduce-Priority
Tracked detect items: 0

Admin-group is None
Vrrp run info:
/*Running information of VRRP on current interface*/
State is Master
/*VRRP running state*/
1 state changes, last state change 07:57:25 7 day(s)
/*Number of state changes and the time for how long the system has been running
until the last change. If there is no change, the value is 0.*/
Current priority is 255
/*Current priority, the largest priority of the Owner is 255*/
Master router is local
Master router address is 10.0.0.1
Master router priority is 255
Master Advertisement interval is 1.000 (s)
Master Down interval is 3.003 (s), no learn
3-13
SJ-20140731105308-016|2014-10-20 (R1.0)
3.4.2 Symmetrical VRRP Configuration Example

As shown in Figure 3-12, symmetrical VRRP means load sharing is supported, and two
VRRP groups are configured. PC1 and PC2 use the virtual router in Group 1 as the default
network gateway, and the address is 10.0.0.1. PC3 and PC4 use the virtual router in Group
2 as the default network gateway, and the address is 10.0.0.2. R1 and R2 provide backups
for each other. When both routers are invalid, the communications between the hosts and
external network will be interrupted.
Figure 3-12 Symmetrical VRRP Configuration (IPv4)
Configuration Flow
3. Configure VRRP Group 1 and corresponding virtual address on R1. Configure VRRP
Group 2 and corresponding virtual address on R2. Specify a higher priority for VRRP
Group 1 on R1 and VRRP Group 2 on R2, so that R1 is the master router in Group
1 and the backup router in Group 2, and R2 is the master router in Group 2 and the
backup router in Group 1. R1 and R2 provide backups for each other.
R1(config)#vrrp
R1(config-vrrp-if-gei-0/1/0/1)end
3-14
SJ-20140731105308-016|2014-10-20 (R1.0)

R2(config)#vrrp
Interface
vrID Pri Time A P L State
Master addr VRouter addr
gei-0/1/0/1 1
255 1000 A P
Master
10.0.0.1
10.0.0.1
gei-0/1/0/1 2
100 1000 P
Master
10.0.0.1
10.0.0.2

master.*/

gei-0/1/0/1 - vrID 1
/*VRRP configuration information*/

Reload delay 0 (s)
Check ttl enable
Interface
State
Policy
Reduce-Priority

Admin-group is None
Vrrp run info:
State is Master

3-15
SJ-20140731105308-016|2014-10-20 (R1.0)

1 state changes, last state change 07:57:25 7 day(s)
/*current priority, the largest priority of the Owner is 255*/
Master Advertisement interval is 1.000 (s)
Master Down interval is 3.003 (s), no learn
3.4.3 VRRP Heartbeat Configuration Example

As shown in Figure 3-13, VRRP is run between R1 and R2. The VRRP virtual address is
the interface address 10.0.0.1 on R1. R1 works as the master router.
Figure 3-13 VRRP Heartbeat Configuration (IPv4)
Configuration Flow
3. Configure the same VRRP group ID and virtual addresses for R1 and R2. To make
R1 as the master router, specify a higher priority on R1, or set it to be the IP address
owner which means that R1 interface address is taken as the virtual address and R1
has the highest priority 255.
4. In VRRP interface configuration mode, configure egress interfaces for VRRP groups
to ensure that packets can be sent and received through the two egress interfaces.
3-16
SJ-20140731105308-016|2014-10-20 (R1.0)

R1(config)#vrrp

R2(config)#vrrp
Interface
gei-0/1/0/1
vrID
1
Pri
Time
255
1000
L State
Master
Master addr
VRouter addr
10.0.0.1
10.0.0.1

master.*/
gei-0/1/0/1 - vrID 1
Vrrp configure info: /*VRRP configuration information*/
Advertise time is 1.000(s)
Preemption enable, delay 0(s)
Reload delay 5 (s)
Check ttl enable
Out-interface(heartbeat line) is gei-0/1/0/2
3-17
SJ-20140731105308-016|2014-10-20 (R1.0)

Interface
State
Policy
Reduce-Priority

Admin-group is None
Vrrp run info:
State is Master
2 state changes, last state change 00:00:00
/*Current priority, the largest priority of the Owner is 255*/
Master Advertisement interval is 1.000(s)
Master Down interval is 3.003(s), no learn
3.4.4 VRRP BFD Configuration Example

Figure 3-14 shows that the VRRP is running between Router A and Router B. The VRRP
virtual IP address is 10.0.0.3.
Figure 3-14 VRRP Track Configuration (IPv4)
Configuration Flow
1. Enter the interfaces on which VRRP will be configured and configure IP addresses on
the interfaces.
2. Enter VRRP configuration mode from global configuration mode, and then enter the
interface on which VRRP will be configured.
3-18
SJ-20140731105308-016|2014-10-20 (R1.0)
3. Configure the same VRRP group ID and virtual IP address for Router A and Router B.
To set Router A as the master router, specify a higher priority on Router A, or set it to
be the IP address owner which means that Router A interface address is taken as the
virtual address and Router A has the highest priority 255.
4. Enter SAMGR configuration mode on Router A and Router B to configure an
detection object respectively. Configure the Ethernet Operation, Administration and
Maintenance (EOAM) object on Router A and Router B, and then configure the
Bidirectional Forwarding Detection (BFD) object.
5. Enter VRRP interface configuration mode on Router A and Router B, enable VRRP
track function to track the objects configured in Step 4 respectively.
Run the following commands on Router A:
RA(config)#interface gei-0/1/0/1
RA(config-if-gei-0/1/0/1)#no shutdown
RA(config-if-gei-0/1/0/1)#ip address 10.0.0.1 255.255.0.0
RA(config-if-gei-0/1/0/1)#exit
RA(config)#vrrp
RA(config-vrrp)#interface gei-0/1/0/1
RA(config-vrrp-if-gei-0/1/0/1)#vrrp 1 ipv4 10.0.0.3
RA(config-vrrp-if-gei-0/1/0/1)#vrrp 1 track object zte1 link-type
RA(config-vrrp-if-gei-0/1/0/1)#vrrp 1 track object zte2 peer-type
RA(config-vrrp-if-gei-0/1/0/1)#end
The trace object named zte1 and zte2 must be configured in the SAMGR module in
advance. For details, refer to Chapter 1 Service Availability Manager Configuration.
Run the following commands on Router B:
RB(config)#interface gei-0/1/0/1
RB(config-if-gei-0/1/0/1)#no shutdown
RB(config-if-gei-0/1/0/1)#ip address 10.0.0.2 255.255.0.0
RB(config-if-gei-0/1/0/1)#exit
RB(config)#vrrp
RB(config-vrrp)#interface gei-0/1/0/1
RB(config-vrrp-if-gei-0/1/0/1)#vrrp 1 ipv4 10.0.0.3
RB(config-vrrp-if-gei-0/1/0/1)#vrrp 1 track object zte1 link-type
RB(config-vrrp-if-gei-0/1/0/1)#vrrp 1 track object zte2 peer-type
RB(config-vrrp-if-gei-0/1/0/1)#end
The trace object named zte1 and zte2 must be configured in the SAMGR module in
advance. For details, refer to Chapter 1 Service Availability Manager Configuration.
View the VRRP track information on Router A, as shown below.
RA#show vrrp ipv4 brief
3-19
SJ-20140731105308-016|2014-10-20 (R1.0)

Interface
vrID
Pri
Time
gei-0/1/0/1
100
1000
L State
Master
Master addr
VRouter addr
10.0.0.1
10.0.0.3

L: whether to learn the interval to advertise VRRP messages on the master.*/
RA#show vrrp interface gei-0/1/0/1

gei-0/1/0/1 - vrID 1
Advertise time is 1.000(s)
Preemption enable, delay 0(s)
Reload delay 5 (s)
Check ttl enable
Interface
State
Policy
Reduce-Priority

Track name: zte2
Track type: object
Detect type: zte2
Policy type: peer

Track state: up
Track name: zte1
Track type: object
Detect type: zte1
Policy type: link

Track state: up
Admin-group is None
Vrrp run info:
State is Master
3-20
SJ-20140731105308-016|2014-10-20 (R1.0)
3.4.5 VRRP-Related LINK BFD Function Configuration Example

Figure 3-15 shows that the VRRP function and the LINK BFD function related to the VRRP
are configured on R1 and R2.
Figure 3-15 VRRP Function and VRRP-Related LINK BFD Function Configuration
Configuration Flow
1. Configure a track object on R1 and R2 in SAMGR configuration mode.
2. Relate the track object to R1 and R2 in VRRP configuration mode after the VRRP
function is configured.
R1(config)#samgr
R1(config-samgr)#track 1 bfd session bfd
R1(config)#vrrp
R1(config-vrrp)#interface xgei-0/5/0/3
R1(config-vrrp-if-xgei-0/5/0/3)#vrrp 1 track object 1 link-type
R1(config-vrrp-if-xgei-0/5/0/3)#exit
R1(config-vrrp)#exit

R2(config)#samgr
R2(config-samgr)#track 1 bfd session bfd
R2(config)#vrrp
R2(config-vrrp)#interface xgei-0/0/0/3
R2(config-vrrp-if-xgei-0/0/0/3)#vrrp 1 track object 1 link-type
R2(config-vrrp-if-xgei-0/0/0/3)#exit
R2(config-vrrp)#exit
Run the show vrrp interface command on R1. The execution result is displayed as follows:
R1(config)#show vrrp interface xgei-0/5/0/3
xgei-0/5/0/3 - vrID 1
3-21
SJ-20140731105308-016|2014-10-20 (R1.0)

Reload delay 0 (s)
Check ttl enable
Interface
State
Policy
Reduce-Priority

Track name: 1
Track type: object
Detect type: bfd
Policy type: link

Track state: up
Admin-group is None
Vrrp run info:
State is Master
Run the show vrrp interface command on R2. The execution result is displayed as follows:
R2(config)#show vrrp interface xgei-0/0/0/3
xgei-0/0/0/3 - vrID 1
Reload delay 0 (s)
Check ttl enable
Interface
State
Policy
Reduce-Priority
3-22
SJ-20140731105308-016|2014-10-20 (R1.0)

Track name: 1
Track type: object
Detect type: bfd
Policy type: link

Track state: up
Admin-group is None
Vrrp run info:
State is Master
3-23
SJ-20140731105308-016|2014-10-20 (R1.0)
3-24
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 4
Ping Detect Configuration

Table of Contents
Ping Detect Overview .................................................................................................4-1
Configuring the Ping Detect Function .........................................................................4-3
Ping Detect Configuration Instances...........................................................................4-4
4.1 Ping Detect Overview

Introduction
The Ping Detect function is also called the automatic detection function. It detects the
reachability of the destination through request/response messages of the ICMP. After the
detection, it feeds back the detection results to the related backup functional module to
trigger the active/standby switchover function based on the application of the network layer.
The external router for branch router is configured with interface backup on the Ethernet
interface, see Figure 4-1.
Figure 4-1 Application Overview of Ping Detect
If the destination is unreachable because the Ethernet interface of the peer gateway 1
corresponding to the main link is not configured with an IP address, the backup mode
that depends on the protocol status of the detection interface cannot implement the
active/standby switchover function.
4-1
SJ-20140731105308-016|2014-10-20 (R1.0)
In the same way, if the destination of (non-direct) the main link is faulty, for example, the
external dedicated line of gateway 1 is faulty, the traditional backup mechanism also cannot
implement the active/standby switchover function.
The detection results ( the destination ICMP is reachable or unreachable) will be fed back
to the related modules, such as static route backup module, dialing backup module, and
the VRRP module, to trigger the active/standby switchover operation. After that, the above
faults are solved.
Ping Detect Operating Flow

The whole operating flow of the Ping detection group is as follows:
1. Configure the global Ping Detect group that may include several detection lists.
Several detection policies can be flexibly defined, for example, the detection period of
the detection group, maximum number of times of retries in a detection, and timeout
time of a detection.
You can set the relation between multiple detection lists in the detection group to "AND"
or "OR".
l
If the relation is set to "AND", the detection group is regarded as unreachable if a

detection list is unreachable.
l If the relation is set to "OR", the detection group is regarded as reachable if a
detection list is reachable.
2. Configure the detection units of the detection list, including the detected address
(IPv4/IPv6), VRF name, outgoing interface, and next hop.
The relation between the detection units in the detection list can be set to "AND" or
"OR".
l
If the relation is set to "AND", the detection list is regarded as unreachable if a

detection unit is unreachable.
l If the relation is set to "OR", the detection list is regarded as reachable if a
detection unit is reachable.
3. In SAMGR configuration mode, run the track test ping-detect group command
to enable the Ping Detect function. The Ping Detect group sends ICMP detection
messages to the objects to be detected continuously, and confirms that the objects to
be detected are reachable in accordance with the detection policies (detection times,
time-out duration) defined before.
l
l
Note:
You can check the Ping Detect result by running the show samgr brief command.
To use the Ping Detect function, the ICMP service of the firewall corresponding to the
objects to be detected should be enabled.
4-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 4 Ping Detect Configuration
4.2 Configuring the Ping Detect Function

This procedure describes how to configure the ping detect function.
Steps
1. Configure the ping detect function.
Step
Command
Function
ZXR10(config)#detect-group
Configures a detect group. Group number:
<group-number>
1200.
ZXR10(config-detect-group-number)#op
Configures the logical relationship "and"
tion {and | or}
and "or" for the detection list.
and: It indicates that this group is

connected when all lists in the group are
connected.
or: It indicates that the group is connected
when any list in the group is connected.
3
ZXR10(config-detect-group-number)#ret
Configures the maximum number of times
ry-times <retry-times>
that the detect group re-transmits detect

results to the Ping module. Range: 110,
default: 2.
ZXR10(config-detect-group-number)#lo
Configures the loop detection time for the
op-time <seconds>
detect group. Range: 286400, unit: s,

and default value: 15s.
ZXR10(config-detect-group-number)#ti
Configures the time-out time for the PING
me-out <seconds>
operation. Range: 120, unit: s, default:

2.
ZXR10(config-detect-group-number)#l
Configures a detection list of the detection
ist <list-number>
group.
ZXR10(config-detect-group-number-
Configures logic relations (AND or OR)
list-number)#option {and | or}
between detection units..

l
and: The list is regarded as reachable

when all the units in the list are
reachable.:
or: The list is regarded as reachable

when any unit in the list is reachable.
4-3
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-detect-group-number-
Configures the detection unit, specified
list-number)#item <item-number>[vrf
destination address, VRF name, next-hop
<vrf-name>]{<des-ipv4-address>[<next-ipv4-a
address, and outgoing interface.
ddress> interface <interface-name>]|<des-i

pv6-address>[<next-ipv6-address> interface
<interface-name>]}
9
Enables the Ping Detect function in Samgr
ping-detect group <group-number>
configuration mode.

Command
Function
ZXR10#show running-config ping-detect
Displays the configurations of the ping detect

function. The default value is not displayed.
ZXR10#show running-config ping-detect all
Displays all configurations of the ping detect

function.
Displays the information about the Samgr
ZXR10#show samgr track
Track Ping Detect function.

Displays the information about the Samgr
ZXR10#show samgr track-group
track-group function.
Displays the results of the Ping Detect function.
ZXR10#show samgr brief
End of Steps
4.3 Ping Detect Configuration Instances

4.3.1 Basic Ping Detect Configuration Example
As shown in Figure 4-2, there are three interfaces between R1 and R2. It is required to
configure a detection group between R1 and R2.
Figure 4-2 Network Architecture of Ping Detect Configuration Example
The addresses for the interfaces on R1 and R2 are as follows:

4-4
SJ-20140731105308-016|2014-10-20 (R1.0)
Interface
R1
R2
IP Address
Mask
gei-0/1/0/5
100.0.0.15
255.255.255.0
gei-0/1/0/6
101.0.0.15
255.255.255.0
gei-0/1/0/7
102.0.0.15
255.255.255.0
gei-0/1/0/5
100.0.0.20
255.255.255.0
gei-0/1/0/6
101.0.0.20
255.255.255.0
gei-0/1/0/7
102.0.0.20
255.255.255.0
Configuration Flow
1. Configure a detect group.
2. Configure the detect items for the detect group.
3. Enable the Ping Detect function in Samgr configuration mode, and check the results
by running the show command.
4. Configure the logical relationship to And or Or for the detect group, add an item that
cannot be pinged successfully, and then check the detect results.
Run the following commands to configure R1:
ZXR10(config)#detect-group 1
ZXR10(config-detect-group-1)#list 1
ZXR10(config-detect-group-1-list-1)#item 1 100.0.0.20
ZXR10(config-detect-group-1-list-1)#exit
ZXR10(config-detect-group-1)#exit
ZXR10(config)#samgr
ZXR10(config-samgr)#track test ping-detect group 1
ZXR10(config-samgr)#exit
Check the Ping Detect configuration results on R1:
ZXR10(config)#show samgr brief
======================================================================
Track-name
Detect-type
App-num
State
TransState
test
ping-detect
up
T-ok
Set the logical relationship for the detect object to And, and then add an item that cannot
be pinged successfully.
ZXR10(config-detect-group-1-list-1)#option and
/*Set the logical relationship for the detect object to "and"*/
4-5
SJ-20140731105308-016|2014-10-20 (R1.0)

======================================================================
Track-name
Detect-type
App-num
State
TransState
test
ping-detect
L-down
T-ok
Set the logical relationship for the detect object to Or, and then check the detect results:
ZXR10(config-detect-group-1-list-1)#option or
/*Set the logical relationship for the detect object to "or"*/
ZXR10(config-detect-group-1)#exit
======================================================================
Track-name
Detect-type
App-num
State
TransState
test
ping-detect
up
T-ok
4.3.2 Configuration Example of the Track Ping Function Used For

Directly Connected Routes
Figure 4-3 shows the track ping function used for the directly connected routes.
Figure 4-3 Track Ping Function Used for Directly Connected Routes
4-6
SJ-20140731105308-016|2014-10-20 (R1.0)
Configuration Flow
1. Configure the IP address on R1, R2, and R4 separately, and enable the OSPF protocol.
The OSPF neighbour is established between the routers.
2. Configure the ping-detect detection group on R2, configure a track object in SAMGR
configuration mode, and bind the track object to the gei-0/7/1/8 interface.
R1(config)#router ospf 19
R1(config-ospf-19)#router-id 22.22.22.22
R1(config-ospf-19)#network 71.88.1.0 0.0.0.255 area 0
R1(config-ospf-19)#exit

R2(config)#interface gei-0/2/1/7.1
R2(config-if-gei-0/2/1/7.1)#ip address 41.52.17.2 255.255.255.0
R2(config-if-gei-0/2/1/7.1)#exit
R2(config)#vlan-configuration
R2(config-vlan)#interface gei-0/2/1/7.1
R2(config-vlan-if-gei-0/2/1/7.1)#encapsulation-dot1q 1
R2(config-vlan-if-gei-0/2/1/7.1)#exit
R2(config)#detect-group 10
R2(config-detect-group-10)#retry-times 3
R2(config-detect-group-10)#loop-time 12
R2(config-detect-group-10)#time-out 3
R2(config-detect-group-10)#list 1
R2(config-detect-group-10-list-1)#option or
R2(config-detect-group-10-list-1)#item 1 41.52.17.3 41.52.17.2 interface
4-7
SJ-20140731105308-016|2014-10-20 (R1.0)

gei-0/2/1/7.1
R2(config-detect-group-10-list-1)#item 2 19.19.19.1
R2(config-detect-group-10-list-1)#exit
R2(config-detect-group-10)#exit
R2(config)#samgr
R2(config-samgr)#track abc ping-detect group 10
R2(config-if-gei-0/7/1/8)#track abc

R4(config)#interface gei-0/0/0/8.1
R4(config-if-gei-0/0/0/8.1)#ip address 1.2.3.4 255.255.255.0
R4(config-if-gei-0/0/0/8.1)#ip address 41.52.17.3 255.255.255.0 secondary
R4(config-if-gei-0/0/0/8.1)#interface mac-address offset 23
R4(config-if-gei-0/0/0/8.1)#exit
R4(config)#vlan-configuration
R4(config-vlan)#interface gei-0/0/0/8.1
R4(config-vlan-if-gei-0/0/0/8.1)#encapsulation-dot1q 1
R4(config-vlan-if-gei-0/0/0/8.1)#exit
Execute the show samgr brief command to check the track object on R2. The track object
on R2 is in up status, and the directly connected route of the gei-0/7/1/8 interface is added.
Track-name
Detect-type
abc
ping-detect
App-num
1
State
TransState
up
T-ok
R2#show ip protocol routing network 71.88.1.0

Codes: OSPF-3D = ospf-type3-discard, OSPF-5D = ospf-type5-discard, TE = rsvpte,
OSPF-7D = ospf-type7-discard, USER-I = user-ipaddr, RIP-D = rip-discard,
OSPF-E = ospf-ext, ASBR-V = asbr-vpn, GW-FWD = ps-busi, GW-UE = ps-user,
4-8
SJ-20140731105308-016|2014-10-20 (R1.0)

BGP-AD = bgp-aggr-discard, BGP-CE = bgp-confed-ext, NAT64 = sl-nat64-v4,
USER-N = user-network, USER-S = user-special, DHCP-S = dhcp-static,
DHCP-D = dhcp-dft
Marks: *valid, >best, s-stale
Dest
NextHop
RoutePrf
RouteMetric
Protocol
*>
71.88.1.0/24
71.88.1.1
direct
71.88.1.0/24
71.88.1.0
110
ospf
*>
71.88.1.1/32
71.88.1.1
address
Execute the shutdown command on the gei-0/2/1/7.1 interface. The track object of R2 is
in down status, and the directly connected route of the gei-0/7/1/8 interface is deleted.
R2#show samgr brief
Track-name
Detect-type
abc
ping-detect
App-num
1
State
L-down
R2#show ip protocol routing network 71.88.1.0

Codes: OSPF-3D = ospf-type3-discard, OSPF-5D = ospf-type5-discard, TE = rsvpte,
OSPF-7D = ospf-type7-discard, USER-I = user-ipaddr, RIP-D = rip-discard,
OSPF-E = ospf-ext, ASBR-V = asbr-vpn, GW-FWD = ps-busi, GW-UE = ps-user,
BGP-AD = bgp-aggr-discard, BGP-CE = bgp-confed-ext, NAT64 = sl-nat64-v4,
USER-N = user-network, USER-S = user-special, DHCP-S = dhcp-static,
DHCP-D = dhcp-dft
Marks: *valid, >best, s-stale
Dest
NextHop
RoutePrf
RouteMetric Protocol
4-9
SJ-20140731105308-016|2014-10-20 (R1.0)
4-10
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 5
EFM Configuration
Table of Contents
EFM Overview............................................................................................................5-1
Configuring the EFM ..................................................................................................5-3
EFM Configuration Instances .....................................................................................5-6
5.1 EFM Overview

Introduction
EFM is a standard defined by Institute of Electrical and Electronics Engineers (IEEE), and
is used to detect, monitor, and maintain directly connected links. It is mainly used for
monitoring and detecting the links at the access side.
On the ZXR10 M6000-S, EFM monitors the operation state statistics of point-to-point links
directly connected in physical. The EFM monitors the link operation information as much
as possible, such as error rate of frame transmission, comparison of sending rate and
receiving rate on the link, and loss statistics. At the same time, the EFM also detects and
advertises the emergency failure and events of the system, such as system unrecoverable
fault. This ensures the transmission quality on Layer 2 links to some extent, and monitors
the operation state in real time. This is helpful for network administrators to maintain the
network, and reduces the maintenance cost.
The ZXR10 M6000-S supports the following EMF functions:
l
l
l
l
l
Supporting automatic negotiation with other devices

Supporting remote loopback statistics detection on the links
Supporting detection of link error frames and symbols
Supporting emergency event advertisement
Supporting linkage function handling selectively
EFM Features
The EFM features are as follows:
1. The EFM detects whether the EFM function on the peer device is enabled through its
protocol packets. It interacts with packets to know whether the negotiation procedure
is completed in accordance with the related configurations on two devices.
2. After the negotiation, the EFM collects statistics of link operation information (such as
error frames or symbols) in accordance with the link monitoring in a cycle.
5-1
SJ-20140731105308-016|2014-10-20 (R1.0)
3. When the number of error frames or symbols exceeds the threshold, the EFM triggers
related event notification to inform the local device and the remote device. In this way,
the network administrators know the operation information of the link.
The EFM can also enable remote loopback function to detect the packet loss caused by
the difference between the local receiving rate and the remote receiving rate or the link
fault.
EFM packets are low-speed protocol packets. The packets cannot be forwarded by
devices. Therefore, the EFM can only be applied on the directly connected device, see
Figure 5-1.
Figure 5-1 EFM Principle
The packets cannot be forwarded across devices. The application environment is simple.
The EFM has accuracy requirements for detection. Two devices send keepalive packets
periodically to each other to keep successful protocol negotiation. Other functions of EFM
can be enabled after the successful negotiation.
When detecting an event, the EFM notifies the peer device through specific packets.
EFM Remote Loopback Function

As a statistical function provided by the EFM, the remote loopback function detects the
frame loss and processing capability of links. This function is triggered manually and
may result in non-OAMPDU frame loopback. Besides, this function may interrupt other
services. As a result, this function can be disabled manually and only enabled when the
links need to be detected.
The remote loopback function compares the number of messages at the receiving end
and the number of messages at the sending end to learn about the frame transmission
status, for example, different frame loss and receiving loopback processing capability can
both result in inconsistency between the number of messages at the receiving end and
the number of messages at the sending end. You can compare the number of frames
at the receiving end and the number of frames at the sending end to learn about the link
transmission status, or obtain further information in conjunction with other protocols.
5-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 5 EFM Configuration
5.2 Configuring the EFM

This procedure describes how to configure the basic attributes and functions for the EFM
to monitor and detect access links.
Steps
1. Configure global attributes for the EFM.
Step
Command
Function
ZXR10(config)#efm
Enters EFM configuration

mode.
ZXR10(config-efm)#set ethernet-oam function <state>
Sets the switch to enable EFM

globally.
ZXR10(config-efm)#set ethernet-oam oui <word>
Sets the Organizationally

Unique Identifier (OUI) field of
an EFM vendor. By default, it
is ZTE.
ZXR10(config-efm)#set ethernet-oam remote-timeout
Configures the time-out of
<value>
EFM overall loopback control,

range: 110, default: 3 s.
2. Configure interface attributes for the EFM.

Step
Command
Function
ZXR10(config-efm)#interface <interface-name>
Enters EFM interface

configuration mode.
ZXR10(config-efm-if)#set ethernet-oam function
Enables EFM on a specific
<state>
interface.
ZXR10(config-efm-if-interface-name)#set
Enables or disables the EFM
ethernet-oam rmt-loopback {start| stop}
remote loopback function.
Enables (default) or disables
ethernet-oam rmt-loopback-mode {enable | disable}
the specified interface to make

a response to a loopback
request.
Disables the specified
ethernet-oam rmt-loopback-guard recovery-forward
interface to make a response

to a loopback request, and
forcibly restore the local status
to transfer status.
5-3
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-efm-if)#set ethernet-oam link-monitor
Enables link monitoring
function <state>
function on a specific
interface.
Configures the error frame
ethernet-oam link-monitor frame threshold
statistics window value and
<th-value>[window <win-value>]
threshold of link monitoring.

<th-value>, threshold of error
frames, range: 165535,
default: 1.
<win-value>, window value of
error frame , range: 160,
default: 1 s.
Configures the error symbol
ethernet-oam link-monitor symbol-period threshold
statistics window value and
threshold of link monitoring.

symbols, range: 165535,
default: 1.
<win-value>, Window value of
error symbol, range: 165535,
default: 1 million.
ethernet-oam link-monitor frame-period threshold
cycle statistics window
value and threshold of link

monitoring.
frame cycle, range: 1-65535,
and default: 1.
<win-value>, window value
of error frame cycle, range:
1-65535, and default: 1
million.
10
ethernet-oam link-monitor frame-second threshold
second-cycle statistics
window value and threshold

of link monitoring.
frame second-cycle, range:
1-900, and 1.
<win-value>, window value
of error frame second-cycle,
5-4
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
range: 1-900, and default: 1
s.
11
Sets the link timeout time and
ethernet-oam link-timeout {<timeout-value1>|fast
the package sending period:
<timeout-value2>[ period <period-value>]}
timeout-value1: timeout time,

range: 320, default: 5 s.
timeout-value2: timeout time,
range: 3200, default: 50,
unit: 100ms.
period-value: package
sending period, range: 110,
default: 10, unit: 100ms.
12
ZXR10(config-efm-if)#set ethernet-oam mode <mode>
Configures EFM configuration

mode, active or passive. The
default mode is active.
13
ZXR10(config-efm-if)#set ethernet-oam rmt-loopback
Enables or disables EFM link
<operation>
loopback function manually.

Command
Function
ZXR10#show ethernet-oam [<interface-name>{discovery |
Displays the global EFM
link-monitor | statistics| variable-retrieval}]
configuration, or the interface

EFM configuration and state.
4. Maintain the EFM.

Command
Function
ZXR10#debug ethernet-oam {all |{interface <interface-name>}
Debugs the sending and
|{packet interface <interface-name> [{dual |in | out} type
receiving of EFM packets. Use
{all | information | lpbk-ctrl | notify | org-spec | reqst-varb |
the no format of this command to
respse-varb} mode {all-time | number <num-value>}}]}}
disable the debugging.
End of Steps
5-5
SJ-20140731105308-016|2014-10-20 (R1.0)
5.3 EFM Configuration Instances

5.3.1 EFM Connection Establishment
Figure 5-2 shows that R1 and R2 are connected directly. It is required to configure EFM
on the direct connected interfaces of R1 and R2 to establish a connection.
Figure 5-2 Network Architecture of EFM Connection Establishment
Configuration Flow
1. Configure EFM on the interface of R1 connecting to R2 directly. Enable EFM and
link-monitor on a specified interface, and then enable EFM globally.
2. Configure EFM on the interface of R2 connecting to R1 directly. Enable EFM and
link-monitor on a specified interface, and then enable EFM globally.
3. Run show ethernet-oam discovery command on R1 and R2 to check the EFM
connection establishment.
4. Run show ethernet-oam link-monitor command on R1 and R2 to view the count of link
errors between R1 and R2.
R1(config)#efm
R1(config-efm-if-gei-0/0/1/1)#set ethernet-oam link-monitor funciton enable
R1(config-efm)#set ethernet-oam oui R1
R1(config-efm)#exit

R2(config)#efm
5-6
SJ-20140731105308-016|2014-10-20 (R1.0)

R2(config-efm)#exit
1. Run the show ethernet-oam discovery command on R1 to check the link EFM
negotiation, as shown below.
R1(config-efm)#show ethernet-oam gei-0/0/1/1 discovery
PortId 32: Ethernet Oam enable
Local DTE
---------Config:
Mode
:active
Period Time
:10*(100ms)
Link time out
:50*(100ms)
Status:
/*local state*/
Parser
:forward
/*forwarding state of receiver*/
Multiplexer
:forward
/*forwarding state of sender*/
Stable
:yes
/*Locl link state is "stable".*/
Discovery
:done
/*Link discovery is done.*/
Loopback
:off
/*Loopback is off.*/
PDU max size
:1518
/*Maximum supported length of a local
PDU Revision
:1
/*Local configuration is modified once.*/
Unidirection
:nonsupport
package.*/
Remote DTE
----------Config:
Mode
:active
Link Monitor
:support
Unidirection
:nonsupport
Remote Loopback
:support
Mib Retrieval
:nonsupport
PDU max size
:1518
Remote OUI(hex)
:52-32-00
Status:
/*remote state*/
Parser
:forward
/*forwarding mode*/
Multiplexer
:forward
/*forwarding mode*/
Stable
:yes
/*Remote link state is "stable".*/
Mac Address
:1622.30c4.e999
/*MAC of remote device*/
PDU Revision
:0
/*Remote configuration is modified for 0 time.*/
2. Run the show ethernet-oam link-monitor command on R1 to check the count of link
errors, as shown below.
R1(config)#show ethernet-oam gei-0/0/1/1 link-monitor
5-7
SJ-20140731105308-016|2014-10-20 (R1.0)

Link Monitoring of Interface: gei-0/0/1/1
Link Monitoring enable
Error Symbol Period Event:
Symbol Window
: 1(million symbols)
Error Symbol Threshold
: 1(symbol)
Error Symbols
: 0
Local Total Error Symbols : 0

Remote Total Error Symbols: 0
Local Total Error Events
: 0
Remote Total Error Events : 0

Error Frame Event:
Frame Window
: 1(s)
Error Frame Threshold
: 1(frame)
Error Frames
: 0
Local Total Error Frames
: 0
Remote Total Error Frames : 0

: 0

Error Frame Period Event:
Period Window
: 1(ten thousand frames)
Error Period Threshold
: 1(frame)
Error Frames
: 0
: 0

: 0

Error Frame Seconds Event:
Error Seconds Window
: 1(s)
Error Seconds Threshold
: 1(s)
Error Frame Seconds
: 0(s)
Local Total Error Frame Seconds
: 0(s)
Remote Total Error Frame Seconds : 0(s)

Local Total Error Frame Seconds Events
: 0
Remote Total Error Frame Seconds Events : 0
3. Run the show ethernet-oam discovery command on R2 to check the link EFM
negotiation, as shown below.
R2(config)#show ethernet-oam gei-0/0/0/1 discovery
Local DTE
---------Config:
Mode
:active
Period Time
:10*(100ms)
Link time out
:50*(100ms)
5-8
SJ-20140731105308-016|2014-10-20 (R1.0)

Status:
Parser
:forward
Multiplexer
:forward
Stable
:yes
Discovery
:done
Loopback
:off
PDU max size
:1518
PDU Revision
:0
Unidirection
:nonsupport
Remote DTE
----------Config:
Mode
:active
Link Monitor
:support
Unidirection
:nonsupport
Remote Loopback
:support
Mib Retrieval
:nonsupport
PDU max size
:1514
Remote OUI(hex)
: 52-31-00
Status:
Parser
:forward
Multiplexer
:forward
Stable
:yes
Mac Address
:1210.1210.1211
PDU Revision
:1
4. Run the show ethernet-oam link-monitor command on R2 to check the count of link
errors, as shown below.
R2(config)#show ethernet-oam gei-0/0/0/1 link-monitor
Link Monitoring of Interface: gei-0/0/0/1
Link Monitoring enable
Error Symbol Period Event:
Symbol Window
: 1(million symbols)
Error Symbol Threshold
: 1(symbol)
Error Symbols
: 0
Local Total Error Symbols : 0

Remote Total Error Symbols: 0
: 0

Error Frame Event:
Frame Window
: 1(s)
Error Frame Threshold
: 1(frame)
Error Frames
: 0
: 0
5-9
SJ-20140731105308-016|2014-10-20 (R1.0)

: 0

Error Frame Period Event:
Period Window
: 1(ten thousand frames)
Error Period Threshold
: 1(frame)
Error Frames
: 0
: 0

: 0

Error Frame Seconds Event:
Error Seconds Window
: 1(s)
Error Seconds Threshold
: 1(s)
Error Frame Seconds
: 0(s)
Local Total Error Frame Seconds
: 0(s)
Remote Total Error Frame Seconds : 0(s)

Local Total Error Frame Seconds Events
: 0
Remote Total Error Frame Seconds Events : 0
5.3.2 EFM Remote Loopback

As shown in Figure 5-3, R1 and R2 are connected directly. Configure EFM on the direct
connected interfaces of R1 and R2. Enable remote loopback on R1. R2 loops back the
packets.
Figure 5-3 EFM Remote Loopback
Configuration Flow
1. Configure EFM on the interface of R1 connecting to R2 directly. Enable EFM globally.
2. Configure EFM on the interface of R2 connecting to R1 directly. Enable EFM globally.
3. After the EFM connection is established on R1 and R2, enable remote loopback on
R1.
4. Run show ethernet-oam discovery command on R1 and R2 to check the EFM
connection establishment.
5-10
SJ-20140731105308-016|2014-10-20 (R1.0)

R1#configure terminal
R1(config)#efm
R1(config-efm)#exit
Run the following commands R2:

R2(config)#efm
R2(config-efm)#exit
After the EFM connection is established, enable remote loopback on R1:

R1(config)#efm
R1(config-efm-if-gei-0/0/1/1)#set ethernet-oam rmt-loopback start
R1(config-efm)#exit
On the link where the EFM connection is established, R1 sends packets to R2 except
OAMPDU. When R2 receives the packets, it will loop them back to R1 directly.
R1(config-efm)#show ethernet-oam gei-0/0/1/1 discovery
Local DTE
---------Config:
Mode
:active
Period Time
:10*(100ms)
Link time out
:50*(100ms)
Status:
Parser
:discard
Multiplexer
:forward
Stable
:yes
5-11
SJ-20140731105308-016|2014-10-20 (R1.0)

Discovery
:done
Loopback
:on(Master)
PDU max size
:1518
PDU Revision
:3
Unidirection
:nonsupport
Remote DTE
----------Config:
Mode
:active
Link Monitor
:support
Unidirection
:nonsupport
Remote Loopback
:support
Mib Retrieval
:nonsupport
PDU max size
:1518
Remote OUI(hex)
:52-32-00
Status:
Parser
:loopback
Multiplexer
:discard
Stable
:yes
Mac Address
:00ee.ff10.2102
PDU Revision
:1
5-12
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 6
CFM Configuration
Table of Contents
CFM Overview ...........................................................................................................6-1
Configuring the CFM ..................................................................................................6-4
CFM Configuration Instances .....................................................................................6-7
6.1 CFM Overview

Introduction
Ethernet technology becomes the leading technology gradually due to its simplicity and
low cost since it was born. In recent years, with the applications of gigabit and 10gigabit
Ethernet technology, Ethernet has been extended towards Metropolitan Area Network
(MAN) and Wide Area Network (WAN).
Ethernet was mainly applied in LAN in early times. Compared with MAN and WAN,
LAN has lower requirements for reliability and stability. As a result, Ethernet was
lacking of OAM mechanism, which became a serious obstruction to use Ethernet as
operator networks. Therefore, implementing OAM in Ethernet became an inevitable
development trend. In this case, a series of standard technologies were generated, such
as IEEE 802.3ah (Operations, Administration, and Maintenance - OAM), IEEE 802.1ag
(Connectivity Fault Management) and International Telecommunications Union (ITU) - T
Y.1731 (OAM functions and mechanisms for Ethernet based networks).
IEEE 802.1ag (CFM) provides connectivity detection logically on point-to-point links. It
detects the connectivity between two logical points, supporting functions such as loopback,
link trace and ITU-T Y1731. CFM can check, isolate, and report connectivity faults in
Virtual Local Area Networks (VLANs) effectively. The CFM is the main protocol used for
link monitoring, detection, and troubleshooting at the data link layer. It can implement link
detection of Ethernet data link layer on most full-duplex point-to-point links and analogical
point-to-point links, without depending on specific system interfaces.
The CFM mainly has three functions:
l
Fault detection: An MEP sends and receives Continuity Check Messages (CCMs)
periodically to detect the connectivity of the network. It can discover connectivity
failures and non-consensual connectivity (situations of wrong connections).
Fault confirmation and isolation: This function belongs to the management behavior.
Network administrators confirm the faults through Loopback Messages (LBMs) or
Loopback Replies (LBRs), and then isolate the faults.
6-1
SJ-20140731105308-016|2014-10-20 (R1.0)
Path discovery: An MEP uses Linktrace Messages (LTMs) or Linktrace Replies (LTRs)
to discover paths and trace the path from an MEP to another MEP or the path between
Maintenance domain Intermediate Points (MIPs).
CFM Features
The CFM can check, isolate, and report connectivity faults in VLANs effectively.
To manage and maintain the network, network administrators make a plan for the network
services and levels, and divide the entire network into several MDs. For the sketch map
of an MD, see Figure 6-1.
Figure 6-1 Maintenance Domain
A series of ports are defined for the edge devices and the internal device, see Figure 6-1.
l
l
The gray points on the edge devices are the services ports connecting to devices
outside the domain. These points are defined as MEPs.
The black points on the devices (including the internal device) are ports connecting to
devices inside the domain. These points are defined as MIPs.
The management function is implemented through the MEPs and MIPs.

A network can be divided into user domain, provider domain, and operator domain. Each
domain is specified to a level. There are levels from 0 to 7. The level of a domain decides
6-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 6 CFM Configuration
the inclusion relation of domains. A domain of a higher level may include domains of lower
levels. However, a domain of a lower level cannot include a domain of a higher level. The
domains of the same level cannot include each other. Therefore, the domain of the largest
range has the highest level. The inclusion relation of domains can be tangent (internally
tangent or externally tangent) and inclusive, but it cannot be intersecting.
IEEE 802.1ag standard defines the following mechanisms:
1. Several nesting MDs configured through a bridge network or a network of a bridge
network. The domains may be managed by different management organizations.
2. An Maintenance Association (MA) identified by an individual MD in a specific bridge
and a group of VLANs.
3. The protocol, flow, and formats of CFM protocol packets that are used to detect and
isolate connectivity faults.
4. Configuration ability to configure and manage Maintenance Points (MPs) in an MA. An
MP is used to generate and receive CFM packets.
5. MPs ordered to execute isolation and result inspection for confirmed faults.
LCK Function
The ETH-LCK function is used to learn about the management locking of the server layer
MEP and subsequentservice traffic interruption. The service traffic is sent to the MEP that
expects to receive the traffic. The MEP that receives the frame carrying the ETH-LCK
information can distinguish faults from management locking of the MEP. This function is
an application used by the MEP for management locking. The MEP periodically continues
sending the frames carrying the ETH-LCK information until the management/diagnosis is
unlocked.
To support the ETH-LCK transmission function, you need to configure the following specific
information:
l
l
Client-level: Clients MEP level

Lck interval:ETH-LCK transmission period
LCK transmission: When a signal is locked, the MEP sends an LCK frame whose
transmission period depends on the LCK transmission period. The transmission
periods of LCK and AIS are the same. The first LCK frame must be sent after the
management/diagnosis action.
LCK receiving: Once an LCK frame is received, the MEP checks this frame to ensure
that its MEP level corresponds to the configured MEP level. The period field indicates the
expected LCK frame period. The MEP needs to immediately checks the LCK status after
receiving the LCK frame, and then clears the LCK status if no LCK frame is received within
3.5 times the LCK transmission period.
Client-Level
Before enabling the AIS and LCK functions, the CFM needs to set the client level of the
local MEP.
6-3
SJ-20140731105308-016|2014-10-20 (R1.0)
The client-level configurations involve the client-level configurations of the LCK and AIS
functions. After these two functions are enabled, signals are transmitted between the
specified maintenance domain layer specified by the client-level value, and the client level
must be higher than the MD level of the local MEP.
6.2 Configuring the CFM

This procedure describes how to configure basic attributes and functions for the CFM to
detect the point-to-point connectivity.
Steps
1. Configure the CFM function.
Step
Command
Function
ZXR10(config)#cfm
Enters CFM configuration

mode.
ZXR10(config-cfm)#set cfm enable
Enables CFM globally.
ZXR10(config-cfm)#create md index <index>
Creates an MD.
name-format <format>[name <md-name>] level <level>
<level> refers to the level of

the maintenance domain. The
range is 07. The bigger the
value, the higher the level.
ZXR10(config-cfm)#md index < index >
Enters MD configuration
mode.
ZXR10(config-cfm-md-index)#create ma index <index>
Creates an MA.
name-format <format> name < ma-name>[vid <vid>]

6
ZXR10(config-cfm-md-index)#ma index <index>
Enters MA configuration
mode.
ZXR10(config-cfm-md-index-ma-index)#set
Configures the interval of
ccminterval <interval>
CCM in an MA, in the range of

1-7 corresponding to 3.3 ms,
10 ms, 100 ms, 1 s, 10 s, 60
s, and 600 s
Creates an MEP.
ZXR10(config-cfm-md-index-ma-index)#create
mep mep-id <mepid> direction {down | up} interface

<interface-name>
6-4
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-cfm-md-index-ma-index)#create rmep
Creates an RMEP.
mepid <mepid > remote-mac <mac-address>
<mepid >, MEP ID, in the range

of 1-8191, not duplicated in
the local MA including the
MEP.
<mac-address>, MAC address
of RMEP.
10
ZXR10(config-cfm-md-index-ma-index)#create mip
Creates an MIP.
session-id <session-id> interface <interface-name>

11
ZXR10(config-cfm-md-index-ma-index)#set mep
Enables or disables local
<mepid> state {enable|disable}
management in an MEP. For

an RMEP, this enables or
disables CCM detection.
12
Enables or disables to send
<mepid> ccm-send {enable|disable}
CCM in an MEP. It is only

effective in the local MEP.
<mepid >, MEP ID, in the
range of 18191. It can be set
to a local MEP or a remote
MEP.
13
Configures the lowest fault
<mepid> alarm-lowest-pri <priority>
class that can trigger alarms

in an MEP, in the range of 1-9.
By default, it is 1.
14
Configures the client lay level
<mepid> client-level <client-level>
of the local MEP. To cancel

the setting, use the no form of
this command.
<client-level> ranges from 1 to
7. <mepid > ranges from 1 to
8191. Only the local MEP is
configurable.
15
Configures the intervals at
<mepid> lck interval {1|3}
which an LCK platform locking

signal is sent. 1 indicates
that the interval is 1 , and 3
indicates that the interval is 1
min.
6-5
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
16
ZXR10(config-cfm-md-index-ma-index)#create rmep
Creates an RMEP.
mepid <mepid >[ remote-mac <mac-address>]
<mepid > ranges from 1-8191,

and must be unique in the
local MA, including the local
MEP.
<mac-address> is an optional
MAC address of a remote
MEP. When the remote MEP
automatically detects the MAC
function, the MAC address is
not specified.
2. Configure the package detection function.

Command
Function
ZXR10#cfm loopback md <md-index> ma <ma-index>
Sends LBMs.
local-mep <mepid> type unicast <mac-address>[repeat

<time>][size <length>][timeout <second>]
ZXR10#cfm linktrace md <md-index> ma <ma-index>
Sends LTMs. By default, the
local-mep < mepid><mac-address>[timeout2 <second>][ttl
time-out is 5, and the TTL is 64.
<value>]
<md-index>: MD index, range: 165535.

<ma-index>: MA index, range: 165535.
<mepid>: Local MEP ID, identifying a local MEP in an MA uniquely, range: 18191, .
repeat <time>: Number of LBMs sent at a time, range: 1200, default: 3.
size <length>: The length of Data TLV field in an LBM, range: 1400, default: 0.
timeout <second>: Interval (s) of LBM time-out, range: 110, default: 5.
timeout2 <second>: Interval (s) of LTR time-out, range: 510, default: 5.
ttl <value>: The maximum hops that LTMs can be forwarded, range: 164, default: 64
s.
3. Configure the MIP in PW interface configuration mode.
Step
Command
Function
ZXR10(config-cfm)#interface <IfName>
Enters PW interface
configuration mode.
ZXR10(config-cfm-if-IfName)#mip level <level>
Configures the MIP in PW

Executes the no command to
cancel this configuration.
6-6
SJ-20140731105308-016|2014-10-20 (R1.0)

Command
Function
ZXR10#show cfm status
Displays the CFM global configuration

state.
ZXR10#show cfm md {<md-index>|all}
Displays the information about a specific

MD.
ZXR10#show cfm ma {<ma-index>|all} md <md-index>

a specific MA.
ZXR10#show cfm mp {<mpid>|all} md <md-index> ma
Displays the detailed configuration and
<ma-index>
state information about a specific MP.
ZXR10#show cfm mip {all-interface | interface
Displays the configuration information
<specify-interface>}
about the specific MIP.
End of Steps
6.3 CFM Configuration Instances

6.3.1 CFM Fast Connectivity Detection
As shown in Figure 6-2, R1 and R2 are connected directly. Configure CFM on the direct
connected interfaces of R1 and R2 to establish a connection.
Figure 6-2 CFM Connection Establishment
Configuration Flow
1. Create MDs and MAs on R1 and R2. The MDs have the same ID and name, and the
MAs have the same ID and name. Enable CFM globally.
2. Create local MEPs on the direct connected interfaces of R1 and R2. The MEPs are
of the same level. Use the peer MAC and MEP ID to create RMEPs on R1 and R2.
Enable local MEP, CCM sending and RMEP.
3. Run the show cfm mp command on R1 and R2 to check the MEP identification bit to
see the CFM connection establishment.
6-7
SJ-20140731105308-016|2014-10-20 (R1.0)

R1(config)#cfm
R1(config-cfm)#create md index 1 name-format 2 name MD1 level 4
R1(config-cfm-md-1)#create ma index 1 name-format 2 name MA1
R1(config-cfm-md-1-ma-1)#set ccminterval 1
/*fast detection*/

R1(config-cfm-md-1-ma-1)#create rmep mepid 2 remote-mac 00ee.efab.ede3
R1(config-cfm-md-1-ma-1)#end

R2(config)#cfm
R2(config-cfm)#create md index 1 name-format 2 name MD1 level 4
R2(config-cfm-md-1)#create ma index 1 name-format 2 name MA1
R2(config-cfm-md-1-ma-1)#set ccminterval 1
R2(config-cfm-md-1-ma-1)#create rmep mepid 1 remote-mac 0016.1514.1312
R2(config-cfm-md-1-ma-1)#end
1. Run the show cfm mp all md 1 ma 1 command on R1 to check the link information, as
shown below.
R1(config)#show cfm mp all md 1 ma 1
MP type
: Local MEP
Direction
: down
MEPID
: 1
MEPIndex
: 1
Level
: 4
Primary VID
: 0
Assign port
: gei-0/0/1/1
Priority
: 7
LowestAlarmPriority
: 1
6-8
SJ-20140731105308-016|2014-10-20 (R1.0)

Client level
: invalid
Admin state
: enable
CCM state/interval
: enable/3.3ms
AIS state/interval
: disable/1s
LCK state/interval
: disable/1s
DM state
: disable
LM state
: disable
-----------------------------------------------------------------------PresentRDI
: 0
MADefectIndication
: 0
SomeRDIDefect
: 0
SomeRMEPCCMDefect
: 0
ErrorCCMDefect
: 0
UnexpectedLevelDefect
: 0
UnexpectedPeriodDefect
: 0
UnexpectedMACDefect
: 0
UnexpectedMEPIDDefect
: 0
XconCCMDefect
: 0
AISRcvdFlag
: 0
LCKRcvdFlag
: 0
-----------------------------------------------------------------------TotalSendCCMs
: 61225
TotalRcvdCCMs
: 61225
RightRcvdCCMs
: 61225
DefErrorCCMs
: 0
DiscardCCMs
: 0
DefXconCCMs
: 0
TotalSendLBMs
: 0
TotalRcvdLBRs
: 0
TotalRcvdLBMs
: 0
TotalSendLBRs
: 0
------------------------------------------------------------------------
MP type
: Remote MEP
MEPID
: 2
MEPIndex
: 2
Level
: 4
RemoteMAC
: 00ee.efab.ede3
Admin state
: enable
CCM interval
: 3.3ms
-----------------------------------------------------------------------RMEPLastRDI
: 0
RMEPCCMdefect
: false
-----------------------------------------------------------------------LMMCount
: 0
DLMCount
: 0
LMMFrameSendRemote
: 0
DLMFrameSendRemote
: 0
LMMFrameSendLocal
: 0
DLMFrameSendLocal
: 0
LMMFrameLossRemote
: 0
DLMFrameLossRemote
: 0
LMMFrameLossLocal
: 0
DLMFrameLossLocal
: 0
LMMAveFrameLossRemote
: 0
DLMAveFrameLossRemote
: 0
LMMAveFrameLossLocal
: 0
DLMAveFrameLossLocal
: 0
LMMHighFrameLossRemote
: 0
DLMHighFrameLossRemote
: 0
LMMHighFrameLossLocal
: 0
DLMHighFrameLossLocal
: 0
LMMTotalFrameLossRemote : 0
DLMTotalFrameLossRemote : 0
LMMTotalFrameLossLocal
DLMTotalFrameLossLocal
: 0
: 0
LMMFrameLossRatioRemote : 0.000000
DLMFrameLossRatioRemote : 0.000000
LMMFrameLossRatioLocal
DLMFrameLossRatioLocal
: 0.000000
: 0.000000
6-9
SJ-20140731105308-016|2014-10-20 (R1.0)

-----------------------------------------------------------------------Proactive DM Count
1DMFrameTimeDelay
: 0s, 0ns
1DMFrameTimeDelayChg
: 0s, 0ns
DMMFrameTimeDelay
: 0s, 0ns
DMMFrameTimeDelayChg
: 0s, 0ns
On-demand DM Count
1DMFrameTimeDelay
: 0s, 0ns
: 0s, 0ns
DMMFrameTimeDelay
: 0s, 0ns
: 0s, 0ns
------------------------------------------------------------------------
2. Run the show cfm mp all md 1 ma 1 command on R2 to check the link information, as
shown below.
R2(config)#show cfm mp all md 1 ma 1
MP type
Direction
: Local MEP
: down
MEPID
: 2
MEPIndex
: 1
Level
: 4
Primary VID
: 0
Assign port
: gei-0/0/1/1
Priority
: 7
LowestAlarmPriority
: 1
Client level
: invalid
Admin state
: enable
CCM state/interval
: enable/3.3ms
AIS state/interval
: disable/1s
LCK state/interval
: disable/1s
DM state
: disable
LM state
: disable
-----------------------------------------------------------------------PresentRDI
: 0
MADefectIndication
: 0
SomeRDIDefect
: 0
SomeRMEPCCMDefect
: 0
ErrorCCMDefect
: 0
UnexpectedLevelDefect
: 0
UnexpectedPeriodDefect
: 0
UnexpectedMACDefect
: 0
UnexpectedMEPIDDefect
: 0
XconCCMDefect
: 0
AISRcvdFlag
: 0
LCKRcvdFlag
: 0
-----------------------------------------------------------------------TotalSendCCMs
: 61719
TotalRcvdCCMs
: 61225
RightRcvdCCMs
: 61225
DefErrorCCMs
: 0
DiscardCCMs
: 0
DefXconCCMs
: 0
TotalSendLBMs
: 0
TotalRcvdLBRs
: 0
TotalRcvdLBMs
: 0
TotalSendLBRs
: 0
6-10
SJ-20140731105308-016|2014-10-20 (R1.0)

------------------------------------------------------------------------
MP type
: Remote MEP
MEPID
: 1
MEPIndex
: 2
Level
: 4
RemoteMAC
: 0016.1514.1112
Admin state
: enable
CCM interval
: 3.3ms
-----------------------------------------------------------------------RMEPLastRDI
: 0
RMEPCCMdefect
: false
-----------------------------------------------------------------------LMMCount
: 0
DLMCount
: 0
LMMFrameSendRemote
: 0
DLMFrameSendRemote
: 0
LMMFrameSendLocal
: 0
DLMFrameSendLocal
: 0
LMMFrameLossRemote
: 0
DLMFrameLossRemote
: 0
LMMFrameLossLocal
: 0
DLMFrameLossLocal
: 0
LMMAveFrameLossRemote
: 0
DLMAveFrameLossRemote
: 0
LMMAveFrameLossLocal
: 0
DLMAveFrameLossLocal
: 0
LMMHighFrameLossRemote
: 0
DLMHighFrameLossRemote
: 0
LMMHighFrameLossLocal
: 0
DLMHighFrameLossLocal
: 0
LMMTotalFrameLossRemote : 0
LMMTotalFrameLossLocal
DLMTotalFrameLossRemote : 0
: 0
DLMTotalFrameLossLocal
: 0
LMMFrameLossRatioRemote : 0.000000
DLMFrameLossRatioRemote : 0.000000
LMMFrameLossRatioLocal
DLMFrameLossRatioLocal
: 0.000000
: 0.000000
-----------------------------------------------------------------------Proactive DM Count
1DMFrameTimeDelay
: 0s, 0ns
: 0s, 0ns
DMMFrameTimeDelay
: 0s, 0ns
: 0s, 0ns
On-demand DM Count
1DMFrameTimeDelay
: 0s, 0ns
: 0s, 0ns
DMMFrameTimeDelay
: 0s, 0ns
: 0s, 0ns
------------------------------------------------------------------------
6.3.2 Cross-L2 VPN Connectivity Detection

In an L2 VPN network, CFM MEPs and MIPs are configured on CE1, PE1, PE2 and CE2
to detect the connectivity of the link CE1-PE1-PE2-CE2, see Figure 6-3.
6-11
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 6-3 Cross-L2 VPN Connectivity Detection
Configuration Flow
1. Create MDs and MAs on CE1, PE1, PE2 and CE2. The MDs have the same ID and
name, and the MAs have the same ID and name.
2. Set the interfaces on CE1 and CE2 as a group of CFM connectivity detection. For the
configuration, refer to the configuration example of CFM Fast Connectivity Detection.
Enable alarm on CE1 and CE2.
3. Configure MIPs on the interfaces of PE1 and PE2 at the public network side and the
AC side. Enable CFM globally.
4. Configure CE1 to execute CFM linktrace and CFM loopback towards MIPs and MEPs
on PE1, PE2 and CE2. Check the link connectivity.
Run the following commands on CE1:
CE1(config)#cfm
CE1(config-cfm)#set cfm enable
CE1(config-cfm)#create md index 1 name-format 2 name MD1 level 4
CE1(config-cfm)#md index 1
CE1(config-cfm-md-1)#create ma index 1 name-format 2 name MA1 vid 1
/*VLAN value of the sub-interface on the AC side of the L2VPN AC.*/
CE1(config-cfm-md-1)#ma index 1
CE1(config-cfm-md-1-ma-1)#create mep mepid 1 direction down interface gei-0/2/0/6.1
CE1(config-cfm-md-1-ma-1)#set ccminterval 1
/*fast detection*/
CE1(config-cfm-md-1-ma-1)#set mep 1 state enable

CE1(config-cfm-md-1-ma-1)#set mep 1 ccm-send enable
CE1(config-cfm-md-1-ma-1)#create rmep mepid 2 remote-mac 00ee.efab.ede3
CE1(config-cfm-md-1-ma-1)#exit
CE1(config-cfm-md-1)#exit
6-12
SJ-20140731105308-016|2014-10-20 (R1.0)

CE1(config-cfm)#exit
CE1(config)#logging on
CE1(config)#exit
Run the following commands on CE2:

CE2(config)#cfm
CE2(config-cfm)#set cfm enable
CE2(config-cfm)#create md index 1 name-format 2 name MD1 level 4
CE2(config-cfm)#md index 1
CE2(config-cfm-md-1)#create ma index 1 name-format 2 name MA1 vid 1
/*VLAN value of the sub-interface on the AC side of the L2VPN AC.*/
CE2(config-cfm-md-1)#ma index 1
CE2(config-cfm-md-1-ma-1)#create mep mepid 2 direction down interface gei-0/2/0/3.1
CE2(config-cfm-md-1-ma-1)#set ccminterval 1
CE2(config-cfm-md-1-ma-1)#set mep 2 ccm-send enable
CE2(config-cfm-md-1-ma-1)#create rmep mepid 1 remote-mac 0016.1514.1312
CE2(config-cfm-md-1-ma-1)#exit
CE2(config-cfm-md-1)#exit
CE2(config-cfm)#exit
Run the following commands on PE1:

PE1(config)#cfm
PE1(config-cfm)#set cfm enable
PE1(config-cfm)#interface pw1
PE1(config-cfm-if-pw1)#mip level 4
PE1(config-cfm-if-pw1)#exit
PE1(config-cfm)#create md index 1 name-format 2 name MD1 level 4
PE1(config-cfm)#md index 1
PE1(config-cfm-md-1)#create ma index 1 name-format 2 name MA1 vid 1
PE1(config-cfm-md-1)#ma index 1
PE1(config-cfm-md-1-ma-1)#create mip session-id 1 interface gei-0/3/1/6.1
PE1(config-cfm-md-1-ma-1)#end
Run the following commands on PE2:

PE2(config)#cfm
PE2(config-cfm)#set cfm enable
PE2(config-cfm)#interface pw1
PE2(config-cfm-if-pw1)#mip level 4
PE2(config-cfm-if-pw1)#exit
PE2(config-cfm)#create md index 1 name-format 2 name MD1 level 4
PE2(config-cfm)#md index 1
PE2(config-cfm-md-1)#create ma index 1 name-format 2 name MA1 vid 1
PE2(config-cfm-md-1)#ma index 1
PE2(config-cfm-md-1-ma-1)#create mip session-id 1 interface gei-0/1/1/2.1
6-13
SJ-20140731105308-016|2014-10-20 (R1.0)

PE2(config-cfm-md-1-ma-1)#end
CE1 executes CFM linktrace (trace) and CFM loopback (ping) towards PE1, PE2 and
CE2. If the link is normal, the responses of the operations (trace and ping) are correct. If
the link becomes faulty from normal state, CE1 and CE2 will generate CFM alarms. The
operations (trace and ping) executed by CE2 towards are shown below.
CE2#cfm loopback md 1 ma 1 local-mep 1 type unicast 0016.1514.1312
Sending 3 loopback messages to 0016.1514.1312,timeout is 5 seconds.
Reply from 00.16.15.14.13.12: byte=0 success

Packet : Sent= 3, Received= 3, Lost=0
CE2#cfm ltr-read trans-id 43 md 1 ma 1 mep 1

The reply of linktrace to 0016.1514.1312.
-------------------------------------------------------------------------------
Hops
MAC ADDRESS
Forwarded
Ingress
Egress
Relay
Action
Action
Action
------------------------------------------------------------------------------F
00d0.d0c0.e21f
Forwarded
IngOk
0022.2324.251f
Forwarded
IngOk
0016.1514.1312
Not Forwarded
IngOk
EgrOk
EgrOk
RlyFDB
RlyFDB
RlyHit
Trace complet
6-14
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 7
BFD Configuration
Table of Contents
BFD Overview ............................................................................................................7-1
Configuring the BFD...................................................................................................7-2
BFD Configuration Instances....................................................................................7-10
7.1 BFD Overview

Introduction
For network devices, an important feature is to detect the communication failures between
adjacent systems rapidly. This way, when failures occur, the devices can establish
alternative paths or hand over services to other links more quickly.
The BFD provides a solution to the above problem. The BFD protocol can detect failures
on any types of paths between adjacent systems, including direct-connected physical link,
virtual circuit, tunnel, MPLS LSP, multi-hop routing channel, and indirect-connected tunnel.
Because of its simplicity and unitary, BFD can focus on fast detection of forwarding failures.
It helps networks to implement transmission of voice, video, and other services with good
Quality of Service (QoS), thus helps service providers to provide real-time services (such
as Voice over Internet Protocol (VoIP)) on the basis of IP network.
BFD Features
The BFD is a simple Hello protocol. It is similar to the Hello mechanisms of routing
protocols. The BFD is simpler and universal. The two systems that establish a BFD
session send packets to each other periodically. If one system does not receive any
packet from the peer in a specific period, it considers that there is a failure on the
communication path. The BFD session will be down, and the BFD will inform the upper
layer protocol to select another path. To reduce the loads of devices, some special
application modes are designed in the BFD. In these modes, devices can reduce the
number of BFD packets sent to the peers; or it is unnecessary for the devices to send
BFD packets periodically. The devices can send the packets only when it is necessary.
The BFD protocol aims at fast failure detection (including failures on interfaces, data
links, and even forwarding engines) on a bidirectional tunnel between forwarding engines.
Another aim is to provide a single detection mechanism that can be applied to any type of
medium and any protocol layer. BFD detects failures in the forwarding engines between a
device and the next hop. It is likely to work in some parts of a system forwarding engine.
The forwarding engine and the control engine are isolated. This not only binds the
7-1
SJ-20140731105308-016|2014-10-20 (R1.0)
protocol to the forwarding plane, but also isolates the protocol from the routing protocol
engine (control plane). Therefore, BFD can take effect in non-interrupt forwarding and
run in the control engine.
The BFD provides failure detection between systems, including directly connected physical
links, virtual links, tunnels, MPLS LSPs, and multi-hop routing paths.
Static BFD
A ZXR10 M6000-S BFD can be established in the following two modes:
l
l
Static BFD establishment: Establish a BFD session through configuring related

protocol parameters by using instantiation commands.
Dynamic BFD establishment: Establish a BFD session (triggered by the protocol)
in conjunction with the BFD enabling command in the route protocol/MPLS protocol
mode.
The ZXR10 M6000-S supports the following scenarios:

l
l
l
The dynamic BFD function is used to detect LDP-LSP/RSVP-LSP.

The static BFD function is used to detect LDP-LSP.
The static BFD function is used to detect static tunnels.
7.2 Configuring the BFD

This procedure describes how to configure basic attributes and functions for the BFD to
detect the connectivity between two different forwarding systems.
Steps
1. Configure an BFD session.
Step
Command
Function
ZXR10(config)#bfd
Enters BFD configuration

mode.
ZXR10(config-bfd)#session <session-name>{l2-bfd
Configures a BFD session in
interface <interface-name> source <src-ip-address>|
BFD configuration mode.
link-bfd {ipv4 | ipv6}<src-ip-address><dst-ip-address>
<src-ip-address>, establishes
interface <interface-name>[vrf <vrf-name>]| peer-bfd {ipv4
the source address for the
| ipv6}<src-ip-address><dst-ip-address>[vrf <vrf-name>]|
session (It must be the local
ldp-bfd fec-address <src-ipv4-address><mask-length>[vrf
address).
<vrf-name>]| pw-bfd pw-name <pw-name>| rsvp-bfd
<dst-ip-address>, establishes
te_tunnel <tunnel-id>}
the destination address for

the session (It is not limited
to the directed address).
<interface-name>, specifies
the egress interface for
7-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 7 BFD Configuration
Step
Command
Function
the session . If the egress
interface is not specified,
the message may be sent
locally instead of the egress
interface.
ZXR10(config-bfd)#interface <interface-name>
Specifies the interface that

needs to configure sessions
in BFD configuration mode.
ZXR10(config-bfd-interface-name)#time-negotiation
Configures the package
interval <interval> min-rx < min-rx> multiplier
transceiver duration and
<multiplier>
the detection multiplier for

the BFD session under the
interface.
The following modes include
this command: BFD interface
mode, PEER-BFD example
mode, RSVP-BFD example
mode, PW-BFD example
mode, and L2-BFD example
mode.
ZXR10(config-bfd-peer-session-name)#pkt-len min
Configures the maximum
<min-pkt-length> max <max-pkt-length>
length of the detection

package in LINK-BFD
example mode and
PEER-BFD example mode.
ZXR10(config-bfd-peer-session-name)#multiport
Configures the destination
{enable | disable}
port in PEER-BFD example

mode.
ZXR10(config-bfd-peer-session-name)#dscp <DSCP
Configures the DSCP value
value>
for the BFD package.

The following modes use
this command: LINK-BFD
example mode, PEER-BFD
example mode, LDP-BFD
example mode, RSVP-BFD
example mode, PW-BFD
example mode, and L2-BFD
example mode.
ZXR10(config-bfd-l2-session-name)#discriminator
Configures the local and
ld <local-discriminator> rd <remote-discriminator>
remote identifiers in L2-BFD

example mode.
7-3
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-bfd)#default destination <multicast-ipv4-
Configures the default
address>
multicast destination address

for the BFD on L2 in BFD
configuration mode.
<interval>: indicates the interval to send detection message. Range: 3990. Unit: ms.
<min-rx-interval>: indicates the interval to receive detection message. Range: 3990.
Unit: ms.
<multiplier>: indicates the detection multiplier. Range: 350.
<min-pkt-length>: minimum length of a BFD detection package, range: 24512,
default: 24 bytes.
<max-pkt-length>: maximum length of a BFD detection package, range: 24512,
default: 24 bytes.
enable: sets the UDP port number of the package to 3784.
disable: set the UDP port number of the package to 4784.
<DSCP value>: DSCP value of the BFD package, range: 063, default: 56.
<local-discriminator>: identifier of the local session, range: 12048.
<remote-discriminator>: identifier of the remote session, range: 14294967295.
<multicast-ipv4-address>: detects the multiple destination address of the BFD session
on L2, range: 224.0.0.111224.0.0.250, default: 224.0.0.250.
2. Configure the BFD function for a static route.
Command
Function
ZXR10(config)#ip route vrf <vrf-name> <prefix> <net-mask>
Configures a static route for the
{<forwarding-router's-address> [globle] | <interface-name>
private network, and enables the
[<forwarding-router's-address>]} [<distance-metric>] [metric
BFD function for this link.
<metric-number>] bfd enable [name <description-name> |

permanent | track <track-name>]
ZXR10(config)#ip route <prefix> <net-mask> {<forwarding-rout
Configures a static route for the
er's-address> | <interface-name>[<forwarding-router's-address>]}
public network, and enables the
[<distance-metric>] [metric <metric-number>] bfd enable
BFD function for this link.
[name <description-name> | permanent | track <track-name>]
<forwarding-router's-address>: the IP address of the next hop, in dotted-decimal format.

globle: The private network route specifies that the IP address of the next hop is the
address of the public network. This parameter and the bfd enable parameter are
mutually exclusive.
<distance-metric>: administrative distance, default: 1, range: 1255.
7-4
SJ-20140731105308-016|2014-10-20 (R1.0)
<metric-number>: metric value of a route, default: 1, range: 1255.

<description-name>: description of a static route, range: 164 characters.
<track-name>: associated track detection name, range: 131 characters.
During a static route configuration, you need to confirm the unique link to the
destination, and execute the bfd enable command to enable the BFD detection
function for this link.
3. Configure the OSPF BFD.
Step
Command
Function
ZXR10(config)#router ospf <process-id>
Creates an OSPF process or enters

a specified OSPF process.
ZXR10(config-ospf-id)#bfd
Enables BFD of all interfaces.
ZXR10(config-ospf-id)#interface
Selects an interface which is
<interface-name>
necessary to enable the BFD

function.
ZXR10(config-ospf-id-if-interface-name)#b
Enables or disable BFD of the
fd [disable]
current interface.
It is allowed to enable BFD of all interfaces in OSPF route configuration mode, or

enable BFD of all interfaces in a specified area, or enter OSPF interface configuration
mode to enable BFD of a current interface.
4. Configure IS-IS BFD.
Step
Command
Function
ZXR10(config)#router isis [<process-id>][vrf
Creates an IS-IS process or enters
<vrf-name>]
a specified IS-IS process.
ZXR10(config-isis-id)#interface
Enables BFD of interfaces in IS-IS
<interface-name>
route configuration mode.
ZXR10(config-isis-id-if-interface-name)#bf
Enable IS-IS BFD.
d-enable
After BFD is enabled on an interface running IS-IS, when the interface establishes
IS-IS neighbor relationship with a remote interface, the BFD session based on IS-IS
is established on the direct-connected link between this pair of interfaces.
5. Configure BGP BFD.
Step
Command
Function
ZXR10(config)#router bgp <as-number>
Configures BGP on the device.
ZXR10(config-bgp)#neighbor {<ipv4-address>|<ipv
Enables BFD.
6-address>|<peer-group-name>} fall-over bfd

7-5
SJ-20140731105308-016|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-bgp)#neighbor [<ipv4-address>|<p
Configures the BFD time parameter.
eer-group-name>] fall-over bfd interval <inerval>

min-rx <min-rx> multiplier <multiplier>
Single-hop (direct-connected link) BFD or multi-hop (indirect-connected link) BFD

can be configured according to whether the BGP neighbor is connected directly or
indirectly.
6. Configure LDP BFD.
Step
Command
Function
ZXR10(config)#mpls ldp instance <1-65535>[vrf
Enables LDP to establish
<vrf-name>]
an LSP along the ordinary

hop-by-hop routes and enters LDP
configuration mode.
ZXR10(config-ldp)#bfd <FEC address><mask
Configures parameters related
length> interval <interval> min-rx < min-rx>
to LDP LSP BFD and triggers to
multiplier <multiplier>[protect-unbinding | source
establish an LDP BFD session.
<ip-address>]
It is only necessary to configure LDP BFD unidirectionally. After the remote address
of the LSP is specified, the BFD session in the reverse direction will be established
automatically, and the destination address is the LDP discovery sources.
<FEC address>: The LSP address to establish a BFD session, usually a remote network
segment.
<mask length>: The mask length of the remote address, range: 032.
<interval>: The minimum intervals of sending packets, range: 3990, in the unit of ms.
<min_rx>: The minimum interval of receiving packets, range: 3990 s.
<multiplier>: Multiplier of detection time-out, range: 350.
7. Configure RSVP BFD.
Command
Function
ZXR10(config)#mpls traffic-eng
Enables the TE function globally.
ZXR10(config-mpls-te)#interface te_tunnel<number>
Creates a tunnel interface.
ZXR10(config-mpls-te-if-interface-name)#bfd
Enables BFD in MPLS-TE

real-interface mode.
ZXR10(config-mpls-te-tunnel-te_tunnel-
Enables tunnel lsp BFD in tunnel
number)#tunnel mpls traffic-eng bfd interval <interval>
interface mode of MPLS-TE.
min-rx < min-rx > multiplier <multiplier>
7-6
SJ-20140731105308-016|2014-10-20 (R1.0)
<interval>: The minimum interval to send specified BFD control message, range:
3990 ms.
<min-rx>: The minimum interval to receive specified BFD control message, range:
3990 ms.
<multiplier>: Multiplier of specified BFD control messages, range: 350.
8. Configure the BFD function related to the VRRP.
Command
Function
ZXR10(config-samgr)#track <track-object-name> bfd
Configures a track object in
SAMGR configuration mode.
ZXR10(config-vrrp-if-interface-name)#vrrp <vrid>
Configures the VRRP detection
track {group | object}<string>{link-type | peer-type |
event group, detection object,
priority-decrement <priority-value>}
and policy type in VRRP

<vrid>: ID of a virtual router.
Range: 1255.
<string>: name of the detection
group or detection object.
Range: 131 characters.
<priority-value>: indicates the
priority to be decreased. Range:
1254.
9. Configure the VPWS BFD function.

Command
Function
ZXR10(config-vpws-vpws-name-pw-pw-number-
Configures the VPWS BFD
neighbour-peer-router-id)#vccv bfd capability {basic |
function in VPWS configuration
status} encapsulation {raw | ip}
mode.
10. Configure the remote PW-BFD transmission, and then BGP-BFD faults can be
transmitted to the PW-BFD in the L2 network. In this way, the access point can switch
over active and standby PWs.
Command
Function
ZXR10(config-bfd)#session<instance-name>pw-bfd
< instance-name >: BFD instance
pw-name<pw-name>[local-IP <local-ip-address>
name.
Remote-IP<remote-ip-address>pw-ttl<ttl-number>][CV-Stop]
<pw-name>: PW name. Range:

132 characters.
<local-ip-address>: local device IP.
<remote-ip-address>: remote
device IP.
<ttl-number>: number of hops to
the remote device.
7-7
SJ-20140731105308-016|2014-10-20 (R1.0)
11. Configure a static BFD session.

Command
Function
ZXR10(config-bfd)#session <instance-name> link-bfd
Configures a static BFD session
ipv4 <local-ipv4-address><remote-ipv4-address> interface
of IP type.
<interface-name>[vrf <vrf-name>][ld <local-discriminator> rd
< instance-name >: instance name
<remote- discriminator>]
of the BFD session establishment.

<local-ipv4-address >: source
IPv4 address of the BFD session
establishment.
<interface-name>: outgoing
interface of the specified session.
<vrf-name>: VRF name. Range:
132 characters.
<local-discriminator>: local
identifier (range: 1-2048).
<remote-discriminator>: remote
identifier (range: 1-4294967295).
ZXR10(config-bfd)#session <instance-name> peer-bfd ipv4
Configures a multi-hop static BFD
<local-ipv4-address><remote-ipv4-address>[vrf <vrf-name>][ld
session.
<local-discriminator> rd <remote- discriminator>]
< instance-name >: instance

name of the multi-hop BFD static
session establishment
<local-ipv4-address >: source
IPv4 address of the BFD session
establishment.
<remote-ipv4address>: remote
IP address of the session.
132 characters.
identifier. Range: 12048.
ZXR10(config-bfd)#session <instance-name> ldp-bfd
Configures a static BFD session
fec-address < fec-address> mask-length < mask-length>[vrf
of LDP type.
<vrf-name>][ld <local-discriminator> rd <remote-
discriminator>]
of the static BFD session (of LDP

type) establishment.
<fec-address >: equivalent address
for transferring.
<mask-length>: mask length.
Range: 032.
7-8
SJ-20140731105308-016|2014-10-20 (R1.0)
Command
Function
132 characters.
identifier.
ZXR10(config-bfd)#session <instance-name> rsvp-bfd
Configures a static BDF session
te_tunnel <tunnel-id>[ld <local-discriminator> rd <remote-
of RSVP type.
discriminator>]

of static BFD (of RSVP type)
establishment.
<tunnel-id>: tunnel ID of the static
session of RSVP type

Command
Function
ZXR10#show running-config bfd
Queries a BFD session.
ZXR10#show bfd neighbors ip detail[location
Displays the detailed information about the BFD
<board-name>]
session.
ZXR10#show bfd neighbors ip brief[location
Displays the brief information about IP-type BFD
<board-name>]
session.
ZXR10#show bfd neighbors ldp brief[location
Displays the brief information about LDP-type
<board-name>]
BFD session.
ZXR10#show bfd neighbors ldp detail[location
Displays the detailed information about LDP-type
<board-name>]
BFD session.
ZXR10#show bfd neighbors rsvp {lsp | passive
Displays the brief information about RSVP-type
| tunnel} brief [location <board-name>]
BFD session.
ZXR10#show bfd neighbors rsvp {lsp | passive
| tunnel} detail [location <board-name>]
RSVP-type BFD session.
ZXR10#show bfd neighbors pw brief[location
Displays the brief information about PW-type BFD
<board-name>]
session.
ZXR10#show bfd neighbors pw detail[location
Displays the detailed information about PW-type
<board-name>]
BFD session.
ZXR10#show bfd neighbors l2 brief[location
Displays the brief information about l2-type BFD
<board-name>]
session.
7-9
SJ-20140731105308-016|2014-10-20 (R1.0)
Command
Function
ZXR10#show bfd neighbors l2 detail[location
Displays the detailed information about l2-type
<board-name>]
BFD session.
ZXR10#show bfd statistics [location
Displays the BFD information configured on the
<board-name>]
device.
ZXR10#show bfd neighbors local-disc
Displays the BFD information related to the local
<local-discriminator>
identifier configured on the device.
13. Maintain the BFD.

Command
Function
ZXR10#debug bfd packet
Displays the brief information about the packets

sent and received during the BFD session
establishment.
Displays the state change information about the
ZXR10#debug bfd event
BFD session during BFD establishment

Displays the information about the packets
ZXR10#debug bfd byte
(packets in the UDP data area) sent and received

during the BFD session establishment.
Displays the error information generated during
ZXR10#debug bfd error
the BFD link establishment when the BFD session

is established.
Enable the debug switch of the BFD function.
ZXR10#debug bfd all
End of Steps
7.3 BFD Configuration Instances

7.3.1 Configuring the PIM BFD
Figure 7-1 shows the PIM BFD function configuration.
Figure 7-1 PIM BFD Function Configuration Example
7-10
SJ-20140731105308-016|2014-10-20 (R1.0)
Configuration Flow
1.
2.
3.
4.
5.
Configure the address for the corresponding interface.

Enter multicast configuration mode.
Enter PIM configuration mode.
Enter interface configuration mode and enable the PIM-SM function.
Enable the BFD function in PIM interface configuration mode.
R1(config)#ip multicast-routing
R1(config-mcast)#router pim
R1(config-mcast-pim)#interface gei-0/2/0/3
R1(config-mcast-pim-if-gei-0/2/0/3)#pimsm
R1(config-mcast-pim-if-gei-0/2/0/3)#bfd-enable
R1(config-mcast-pim-if-gei-0/2/0/3)#exit
R1(config-mcast-pim-if-gei-0/2/0/7)#dr-priority 20

R2(config)#interface loopback5
R2(config-if-loopback5)#ip address 5.5.5.35 255.255.255.255
R2(config-if-loopback5)#exit
R2(config)#ip multicast-routing
R2(config-mcast)#router pim
7-11
SJ-20140731105308-016|2014-10-20 (R1.0)

R2(config-mcast-pim-if-gei-0/3/0/8)#bfd-enable
R2(config-mcast-pim-if-gei-0/3/0/7)#dr-priority 20
Run the show ip pim interface command on R1 to check the interface status. The execution
result is displayed as follows:
R1(config)#show ip pim interface
Address
Interface
State Nbr
Hello
DR
DR
PIM
33.1.1.1
gei-0/2/0/7
Up
30
20
33.1.1.1
199.1.1.1
gei-0/2/0/3
Up
30
199.1.1.2 Disabled S
Count Period Priority
Mode
Silent
Disabled S
Run the show ip pim neighbor command on R1 to check the neighbour status. The
execution result is displayed as follows:
R1(config)#show ip pim neighbor
Neighbor Address
Interface
DR Priority
Uptime
Expires
Ver
199.1.1.2
gei-0/2/0/3
00:07:48
00:01:23
V2
Run the show bfd neighbor ip brief command on R1 to check the BFD status. The execution
R1(config)#show bfd neighbor ip brief
LocalAddr
PeerAddr
LD
RD
199.1.1.1
199.1.1.2
2053
2054
Hold
150
State
UP
Interface
gei-0/2/0/3
R1(config)#show bfd neighbor ip detail

---------------------------------------------------------------------------LocalAddr: 199.1.1.1
PeerAddr : 199.1.1.2
Local Discr:2053
Remote Discr:2054
Holdown(ms):150
Interface: gei-0/2/0/3
Vpnid:0
VRF Name:---
State:UP
BFD Type:SingleHop
Instance Name:
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:0
MinTxInt:50
MinRxInt:50
Multiplier:3
Received MinTxInt:50
Received MinRxInt:50
Received Multiplier:3
Length:24
Min Echo Interval:0
7-12
SJ-20140731105308-016|2014-10-20 (R1.0)

Min BFD Length:24
Max BFD Length:24
Rx Count:4352
Rx Interval (ms) min/max/avg:30
/100
/59
Tx Count:4159
Tx Interval (ms) min/max/avg:50
/120
/59
Registered Protocols:PIM
Uptime:0 day(s),0 hour(s),6 minute(s)
Control Plane Rcv Phy Interface Name: gei-0/2/0/3
===========================================================================
Run the show ip pim neighbor command on R2 to check the neighbour status. The
R2(config)#show ip pim neighbor
Neighbor Address
Interface
DR Priority
Uptime
Expires
Ver
199.1.1.1
gei-0/3/0/8
00:07:48
00:01:23
V2
Run the show bfd neighbor ip brief command on R2 to check the BFD status. The execution
R2(config)#show bfd neighbor ip brief
LocalAddr
PeerAddr
LD
RD
Hold
State
Interface
199.1.1.2
199.1.1.1
2055
2054
150
UP
gei-0/3/0/8
RP3(config)#sho bfd neighbor ip detail

---------------------------------------------------------------------------LocalAddr: 199.1.1.2
PeerAddr : 199.1.1.1
Local Discr:2055
Remote Discr:2054
Holdown(ms):150
Interface: gei-0/3/0/8
Vpnid:0
VRF Name:---
State:UP
BFD Type:SingleHop
Instance Name:
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:0
MinTxInt:50
MinRxInt:50
Multiplier:3
Length:24
Min Echo Interval:0
Min BFD Length:24
Max BFD Length:24
Rx Count:804
/100
/59
Tx Count:813
/80
/59
Registered Protocols:PIM
Control Plane Rcv Phy Interface Name: gei-0/3/0/8
============================================================================
7-13
SJ-20140731105308-016|2014-10-20 (R1.0)
7.3.2 Configuring Static Single-Hop BFD

At present, single-hop BFD and static multi-hop BFD are not associated with routes. For
static single-hop BFD, it is necessary to configure an egress interface. For static multi-hop
BFD, it is unnecessary to configure an egress. This is the difference. As shown in Figure
7-2, it is required to configure static single-hop BFD that is not associated with a route on
R1, and configure static route BFD on R2.
Figure 7-2 Static Single-Hop BFD Configuration Example
Configuration Flow
1. Configure static single-hop BFD on R1.
2. Configure static route BFD on R2.
R1(config)#interface xgei-0/5/0/3
R1(config-if-xgei-0/5/0/3)#no shutdown
R1(config-if-xgei-0/5/0/3)#ip address 172.20.130.213 255.255.255.0
R1(config-if-xgei-0/5/0/3)#exit
R1(config)#bfd
R1(config-bfd)#session test link-bfd ipv4 172.20.130.213 172.20.130.214
interface xgei-0/5/0/3
R1(config-bfd-link-test)#!

R2(config)#ip route 172.20.96.1 255.255.255.255 xgei-0/0/0/3 172.20.130.213
bfd enable
7-14
SJ-20140731105308-016|2014-10-20 (R1.0)

/*It is necessary to configure an egress interface for static single-hop BFD.*/
After the configuration, a static single-hop BFD session on R1 and a static route BFD
session on R2 should be established successfully. Run the following command to view
the configuration results.
Run the show bfd neighbors [ip brief|ip-detail] command to check whether the static
single-hop BFD configuration and static route BFD take effect.
Check the configuration result on R1.
R1#show bfd neighbors ip brief
LocalAddr
PeerAddr
LD
RD
Hold
State
Interface
172.20.130.213
172.20.130.214
58
150
UP
xgei-0/5/0/3
R1#show bfd neighbors ip detail

LocalAddr:172.20.130.213
PeerAddr :172.20.130.214
Local Discr:2153
Remote Discr:2395
State:UP
Holdown(ms):150
Interface: xgei-0/5/0/3
Vpnid:0
VRF Name:---
BFD Type:SingleHop
Instance Name:test
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:1
MinTxInt:50
MinRxInt:50
Multiplier:3
Length:24
Min Echo Interval:0
Min BFD Length:24
Max BFD Length:24
Rx Count:0
/0
/0
Tx Count:0
/0
/0
Registered Protocols:INSTANCE
Control Plane Rcv Phy Interface Name: xgei-0/5/0/3
=============================================================================

R2#show bfd neighbors ip brief
LocalAddr
PeerAddr
LD
RD
Hold
State
interface
172.20.130.214
172.20.130.213
58
150
UP
xgei-0/0/0/3
R2#show bfd neighbors ip detail

-----------------------------------------------------------------------------
7-15
SJ-20140731105308-016|2014-10-20 (R1.0)

LocalAddr:172.20.130.214
PeerAddr :172.20.130.213
Local Discr:2395
Remote Discr:2153
Holdown(ms):150
Interface: xgei-0/0/0/3
Vpnid:0
VRF Name:---
State:UP
BFD Type:SingleHop
Instance Name:
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:1
MinTxInt:50
MinRxInt:50
Multiplier:3
Length:24
Min Echo Interval:0
Min BFD Length:24
Max BFD Length:24
Rx Count:0
/0
/0
Tx Count:188
/0
/0
Registered Protocols:STATIC
============================================================================
7.3.3 Configuring Static Multi-Hop BFD

Single-hop BFD and static multi-hop BFD are not associated with routes. For static
single-hop BFD, it is necessary to configure an egress interface. For static multi-hop
BFD, it is unnecessary to configure an egress. This is the difference. As shown in Figure
7-3, it is required to configure static multi-hop BFD that is not associated with a route on
R1, and configure BGP multi-hop BFD on R3.
Figure 7-3 Static Multi-Hop BFD Configuration Example
Configuration Flow
1. Configure static multi-hop BFD on R1.
2. Configure BGP multi-hop BFD on R3.
7-16
SJ-20140731105308-016|2014-10-20 (R1.0)
R1(config-ospf-1)#network 172.20.130.0 0.0.0.255 area 0.0.0.0
R1(config)#router bgp 18004

R1(config-bgp)#neighbor 172.20.108.2 remote-as 18004
R1(config-bgp)#neighbor 172.20.108.2 update-source loopback1
R1(config-bgp)#exit
R1(config)#bfd
R1(config-bfd)#session test peer-bfd ipv4 172.20.96.1 172.20.108.2
R1(config-bfd-session-test)#end


7-17
SJ-20140731105308-016|2014-10-20 (R1.0)

R3(config)#router bgp 18004

R3(config-bgp)#neighbor 172.20.96.1 remote-as 18004
R3(config-bgp)#neighbor 172.20.96.1 update-source loopback1
R3(config-bgp)#neighbor 172.20.96.1 fall-over bfd
R3(config-bgp)#exit
R3(config-bfd)#session test peer-bfd ipv4 172.20. 108.2 172.20.96.1
R3(config-bfd-session-test)#end
After the configuration, a static multi-hop BFD session on R1 and a BGP multi-hop BFD
session on R3 should be established successfully. Run the following command to view
the configuration results.
Run the show bfd neighbors [ip brief|ip detail] command to check whether the static
single-hop BFD configuration and BGP multi-hop BFD configuration take effect.
R1(config)#show bfd neighbors ip brief
LocalAddr
172.20.96.1
PeerAddr
172.20.108.2
LD
RD
Hold
State
Interface
150
UP
---
R1(config)#show bfd neighbors ip detail

---------------------------------------------------------------------------LocalAddr: 172.20.96.1
PeerAddr : 172.20.108.2
Local Discr:2395
Remote Discr:2153
Holdown(ms):150
Interface:---
Vpnid:0
VRF Name:
State:UP
BFD Type:MultiHop
Instance Name:test
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:1
7-18
SJ-20140731105308-016|2014-10-20 (R1.0)

MinTxInt:50
MinRxInt:50
Multiplier:3
Length:24
Min Echo Interval:0
Min BFD Length:24
Max BFD Length:24
Rx Count:190
/200
/200
Tx Count:188
/220
/220
Registered Protocols:INSTANCE
Control Plane Rcv Phy Interface Name:
============================================================================

R3(config)#show bfd neighbors ip brief
LocalAddr
PeerAddr
LD
RD
Hold
State
172.20.108.2
172.20.96.1
150
UP
Interface
-----
R3(config)#show bfd neighbors ip detail

---------------------------------------------------------------------------LocalAddr:172.20.108.2
PeerAddr :172.20.96.1
Local Discr:2056
Remote Discr:2127
Holdown(ms):150
Interface:---
Vpnid:0
VRF Name:---
State:UP
BFD Type:MultiHop
Instance Name:test
---------------------------------------------------------------------------Version:1
Dest UDP Port:4784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:1
MinTxInt:50
MinRxInt:50
Multiplier:3
Length:24
Min Echo Interval:0
Min BFD Length:24
Max BFD Length:24
Rx Count:50
/50
/48
Tx Count:40
/48
/46
Registered Protocols:BGP
============================================================================
7-19
SJ-20140731105308-016|2014-10-20 (R1.0)
7-20
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 8
FRR Configuration
Table of Contents
IP FRR Configuration .................................................................................................8-1
Static Route FRR Configuration .................................................................................8-4
L2 VPN FRR Configuration ........................................................................................8-5
L3VPN FRR Configuation...........................................................................................8-6
TE FRR Configuration ................................................................................................8-7
8.1 IP FRR Configuration

8.1.1 IP FRR Overview
Introduction
When a link or a node in the network becomes invalid, the packet passing through the
invalid nodes to the destination may be dropped or cause loops. Therefore, transient flow
interruption or traffic loopback is inevitable in network until the network calculates out the
new topology and routes. The interruption duration is about a few seconds. At present,
some new technologies in the router field can shorten the convergence time within one
second.
With the development of Internet technologies and applications of different complicated
services, some applications (such as voice and video) are extremely sensitive to the traffic
interruption. Once the network is not steady, there will be serious effect to those services.
When a node becomes invalid, the rapid recovery of traffic is very important. At present, the
communication industry considers that the network convergence period has three levels,
including:
l
l
l
Sub-Second: It is the requirement of most IP networks.

Sub-500 ms: It is an objective that can be reached.
Sub-50 ms: This is a business requirement for some specified parts in the IP network.
Convergence Time and Traffic Loss

The following aspects normally takes the convergence time:
1. The time that is used to discover invalid nodes and links. The detection time is tens of
milliseconds for an invalid physical link. The detection time is dozens of seconds for
invalidations in protocol plane.
2. The time that is used to notice the invalid event to the control plane of a router. It costs
several milliseconds to tens of milliseconds.
8-1
SJ-20140731105308-016|2014-10-20 (R1.0)
3. The time that is used to take the corresponding responses to the invalid node and
link. The response includes triggering and flooding the new link state, and updating
packets. Normally it is several milliseconds to tens of milliseconds.
4. The time that is used to notice other nodes in network that the local router link is invalid.
Normally it is tens of milliseconds to a hundred seconds normally on each node.
5. The time that is used to recalculate the triggering route. For Interior Gateway Protocol
(IGP) protocols that use Dijkstra algorithm, the time is tens of milliseconds.
6. The time that is used to interact with line interface cards to calculate the new routing
information and form the new forwarding table. The time varies in accordance with the
number of routing entries. Normally it is several hundred milliseconds.
7. The time that is used to load the new forwarding route entries into hardware. Normally
it is tens of milliseconds.
The traffic loss may occur in the above mentioned steps. The traffic loss can be divided
into two stages, including:
1. Stage 1: The router fails to discover the invalid link immediately, and it still forwards
the traffic to the invalid link.
2. Stage 2: The route discovers the invalid link, but the network is in convergence
process. The local forwarding table is different with that of other routers, which
causes micro-loop in forwarding plane.
To shorten the traffic interruption duration, a mechanism must be provided to implement
the following functions:
1. Discover the invalid link quickly.
2. When the link is invalid, provide a recovery path quickly.
3. Prevent forwarding micro-loop during the further recovery process.
This mechanism is the IP Fast-Reroute (FRR).
Work Flow
The working procedure of IP FRR is as follows:
1.
2.
3.
4.
Detect faults quickly: The common technologies include BFD, and physical signal test.
Modify the forwarding plane: Hand over the traffic to the recalculated backup path.
Perform route re-convergence.
After finishing the re-convergence, hand over the route to the optimal path.
Obviously, the backup path is to fill the FRR gap, which hands over the traffic to the backup
next hop, to guarantee that the service will not be interrupted.
There are some conditions to form the OSPF FRR or IS-IS FRR relationship. To form
the FRR relationship of default LFAs test mode, the algorithm should meet the condition
Distance_opt (Ni, D) < Distance_opt (Ni, S) + Distance (S, D). That is, the distance from
the next hop on the backup link to the destination should be shorter than the sum of the
distance from the next hop on the backup link to the source node and the distance from
the source node on the primary link to the destination node.
8-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 8 FRR Configuration
To form the FRR relationship of down-stream-path mode, the algorithm should meet the
condition Distance_opt (Ni, D) < Distance (S, D). That is, the distance from the next hop
on the backup link to the destination should be shorter than that from the source node on
the primary link to the destination node.
The establishment of BGP FRR relationship is relatively simpler. It only needs two different
next hops to the same destination.
8.1.2 Nested FRR Overview

At present, FRR is classified into IP FRR, LDP FRR, TE FRR, VPN FRR, and PWE3
FRR. In a reliable networking environment, one or more FRR technologies are deployed
as required to improve the reliability of the netowrk.
The following describes the principle and working flow for several nested FRRs.
VPN FRR+TE/LDP FRR

As shown in Figure 8-1, VPN FRR is formed among PE1, PE2, and PE4, LDP/TE FRR is
formed between PE1 and PE2. VPN FRR is used to protect the node fault, and TE /LDP
FRR is used to protect link fault.
Figure 8-1 VPN FRR + TE/LDP FRR Application Scenes
As shown above, there are three links from CE1 to CE2 (not considering PE3),
PE1>PE2>CE2, PE1>PE4>CE2, and PE1>PE4>PE2>CE2.
When the link between PE1 and PE2 is faulty, TE /LDP FRR will be triggered to switch
the link (external switchover). However, for VPN FRR, the nexthop is PE2, and the link
between PE1 and PE2 is reachable (Before the TE /LDP FRR switchover, the link is PE1
> PE2. After the TE /LDP FRR switchover, the link is PE1>PE4>PE2. The relationship of
VPN FRR is not changed, so the switchover is not required. (VPN FRR and TE /LDP FRR
share the same egress interface, so the internal VPN FRR supports only BFD perceptive
switchover instead of the port switchover in nested mode.
When PE2 is faulty, the VPN FRR switchover happens (internal switchover) when the
link PE1>PE4>PE2 is unreachable, and the link PE1>PE4 is reachable. In this case, the
multiple link protection, and multiple switchover purpose are realized.
8-3
SJ-20140731105308-016|2014-10-20 (R1.0)
PWE3/VPWS FRR+TE/LDP FRR

As shown in Figure 8-2, PW FRR is formed among PE1, PE2, and PE3, and LDP/TE FRR
is formed between PE1 and PE2. PW FRR is used to protect node fault, and TE /LDP
FRR is used to protect link fault.
Figure 8-2 VPWS/PWE3 FRR + TE/LDP FRR Application Scenes
The FRR switchover is the same as VPN FRR + TE/LDP FRR application scene.
IP FRR+TE FRR
As shown in Figure 8-2, IP FRR is formed among PE1, PE2, and PE3, and TE FRR is
formed between PE1 and PE2.
8.1.3 Configuring IP FRR

The IP FRR function is usually used together with a routing protocol. Common IP FRR
functions include OSPF FRR, IS-IS FRR and BGP FRR. For the principle and configuration
of IP FRR, please refer to the related topics in ZXR10 M6000-S Carrier-Class Router
Configuration Guide (MPLS ).
8.2 Static Route FRR Configuration

Introduction
Static route FRR means that the IP FRR technology is used in the static route. The user
can configure the relationship between the active route and the standby route in the static
route. When the link or node in the network becomes invalid, the traffic will be handed
over to the standby route quickly. After the network is restored, the traffic will be handed
over to the active route again.
The operation process of static route FRR is as follows:
1. Detect the fault quickly. The common technology includes BFD and physical signal
detection.
2. Modify the forwarding plane and hand over the traffic to the prepared backup path.
3. Converge the route again.
8-4
SJ-20140731105308-016|2014-10-20 (R1.0)
4. After the route convergence, the traffic will be handed over to the optimization path.
The backup path is to fill the route convergence gap. It ensures the continuity of the service
by switching the traffic to the backup path quickly.
The static route cannot calculate the route and converge the route again, so the user needs
to specify routes to form the relationship between the active route and the backup route.
That is to say, configure two static routes with the same destination address, different
egress interfaces and different priorities.
Configuring Static Route FRR

For the configuration commands and configuration examples of static route FRR, refer to
related topics in the ZXR10 M6000-S Configuration Guide (IPv4 Route).
8.3 L2 VPN FRR Configuration

8.3.1 L2 VPN FRR Overview
L2 VPN FRR Introduction
Nowadays, network develops rapidly. The triple-play requirement becomes more and more
exigent. The operators pay much attention to the service convergence speed when faults
occur. When any node has a fault, the service handover on the adjacent nodes should
be finished within 50 ms, and the point-to-point service convergence should be finished
within 1 s. This has been the threshold indicator of the bearer network. To meet these
requirements, L2 VPN FRR comes into being.
L2 VPN FRR is a set of protection mechanisms applied to links and nodes. When an LSP
link or a node has a fault, the faulty place is protected. In this way, traffic can pass through
the protected link or node without interruption. Meanwhile, the head node can initiate the
reestablishment of the active path without affecting data transmission.
L2 VPN FRR Work Flow

L2 VPN FRR is also called PW FRR. PW FRR is a link and node protection handover
technology for L2 VPN services encapsulated on the base of Pseudo Wire Emulation
Edge-to-Edge (PWE3). Its basic principle is to protect a PW with another PW that is
established in advance, that is, PW redundancy. The PW established in advance is called
the standby PW, and the protected PW is called the active PW. The final goal of L2 VPN
FRR is to protect the active path by using the standby PW to evade the faulty link or node.
PW FRR is used on H-VPLS UPEs. In full-mesh PW network, it is unnecessary to use PW
FRR.
As shown in Figure 8-3, UPE1 connects to NPE2 amd NPE3. PW12 and PW13 are of
redundant hot backup relation. The active and standby attributes are specified statically
during network plan. When protect type of PW is unidirectional mode, there is only one
PW of them can forward services at any moment.
8-5
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 8-3 L2 VPN FRR Work Flow
When the active PW has a fault, with the link failure detection technology such as BFD,
PW FRR handover will be triggered. For example, CE forwards traffic to CE2. When the
active PW (PW12) or NPE2 has a fault, PW FRR handover is triggered. Traffic on UPE1 is
handed over to the standby PW (PW13) quickly. When the active PW recovers, PW FRR
handover is traggered again and traffic is handed over back to the active PW.
8.3.2 Configuring L2 VPN FRR

For the principle and configuration of L2 VPN FRR, refer to the related topics in ZXR10
M6000-S Carrier-Class Router Configuration Guide (VPN).
8.4 L3VPN FRR Configuation

8.4.1 Brief Introduction to L3VPN FRR
As the basic communication device, the data products have more requirements on the
forwarding steady and the fast fault restoration capability on the device. With increasing
requirements on the VPN communication, the FRR function becomes increasingly
important. The FRR function of VPN route only refers to the VPN FRR in a private
network. It does not include the FRR switched from a public network.
At present, the route learnt from the VPR refers to the route learnt from different remote
PEs. In this case, the FRR relationship is formed.
PE1 learnt different private routes within the same network segment from PE2 and PE3,
see Figure 8-4. It forms the FRR of L3VPN on PE1. When the traffic is sent from CE1 to
CE2, a private route with active/standby relationship is generated on PE1 and the FRR of
L3VPN is generated. In this case, the traffic is switched quickly.
8-6
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 8-4 L3VPN FRR Networking Structure
With the route fast switching technology in the private VPN network, the forwarding items of
the active PE and the standby PE set in a remote PE, and the PE fault fast detection, VPN
FRR switches the traffic to a standby path before the VPN route convergence is completed
8.4.2 Configuring L3 VPN FRR

For the principle and configuration commands of L3 VPN FRR, refer to related topics in
the ZXR10 M6000-S Configuration Guide (VPN).
8.5 TE FRR Configuration

8.5.1 TE FRR Overview
TE FRR Introduction
MPLS TE FRR is a set of link and node protection handover mechanism in MPLS TE.
when an LSP link or a node has a fault, the faulty node is protected. In this way, traffic can
go through the tunnel through the protecting link or node without interruption. Meanwhile,
the head node can initiate the reestablishment of the active path without affecting data
transmission.
The basic principle of MPLS FRR is to protect one or more LSPs with another LSP that is
established in advance. The LSP established in advance is called the FRR LSP, and the
protected LSP is called the active LSP. The final goal of MPLS TE FRR is to protect the
active path by using the FRR tunnel to evade the faulty link or node.
TE FRR Modes
MPLS TE FRR is realized on the base of RSVP TE.
There are two modes to realize MPLS TE FRR.
l
Detour mode: It is one-to-one backup. In this mode, the device provides protection
for each protected LSP and establishes a protecting path for each protected LSP. The
protecting path is called Detour LSP.
8-7
SJ-20140731105308-016|2014-10-20 (R1.0)
Bypass mode: It is facility backup. In this mode, a protecting path is used to protect
several LSPs. The protecting path is called Bypass LSP.
Detour mode realizes the protection for each LSP. This needs relatively more cost. In
practical applications, Bypass mode is widely used. The following contents describe
Bypass mode is described in details.
Bypass mode is shown in Figure 8-5. The blue arrows indicate the active LSP, and the red
arrows indicate the Bypass LSP. When the link between RTB and RTC or the node RTC
is invalid, the data on the active LSP will be handed over to the Bypass LSP. The packet
sent by RTB uses the label distributed by RTF in the top layer of the header. Meanwhile,
the out-label of RTC is input into the label stack to be used as the next layer label.
Figure 8-5 FRR Though Bypass Mode
On the path RTB - RTF - RTD, the LSP uses two layers of labels. When RTD receives a
packet, it pops out the label that is distributed for RTF by RTD, and then it uses the label
that is distributed for RTF by RTD to forward the packet.
Related Item
l
l
l
l
Active LSP: It is relative to the Detour LSP or the Bypass LSP. It is the protected LSP.
Point of Local Repair (PLR): It is the head node of the Detour LSP or the Bypass LSP.
It must be on the active LSP, and it should not be the tail node.
Merge Point (MP): It is the tail node of the Detour LSP or the Bypass LSP. It must be
on the active LSP, and it should not be the head node.
Link protection: The PLR and the MP are connected through a direct connection. The
active LSP passes through this link. When this link is invalid, the data can be handed
over to the Detour LSP or the Bypass LSP.
Node protection: The PLR and the MP are connected through a router. The active
LSP passes this router. When this router is invalid, the data can be handed over to
the Detour LSP or the Bypass LSP.
8-8
SJ-20140731105308-016|2014-10-20 (R1.0)
8.5.2 TE FRR Work Flow

FRR in Bypass mode is shown in Figure 8-6.
Figure 8-6 FRR in Bypass Mode
FRR in Bypass mode described here is realized according to RFC by extending the
SESSION_ATTRIBUTE object and the RECORD_ROUTE object.
Active LSP Establishment

The establishment of an active LSP is the same with that of a common LSP. As shown in
Figure 8-6, RSVP sends the PATH message from the head node (RT1) to the downstream
hop by hop (passing by RT1 - RT2 - RT3 - RT4 - RT5). And then RSVP sends the RESV
message from the tail node (RT5) to the upstream hop by hop. When the devices handle
the RESV message, they distribute labels and reserve resources to establish the LSP.
The protocol draft extends some flag bits in SESSION_ATTRIBUT object and object
RECORD_ROUTE for FRR. The differences between the establishment of a protected
LSP and a common LSP lie in the handling of these flag bits.
l
In the SESSION_ATTRIBUT object of a PATH message, the flag bits added include
whether the LSP needs local protection, whether to record labels, whether to use
Share-Explicit (SE) style, and whether to protect bandwidth.
In the RECORD_ROUTE object of an RESV message, the flag bits added include
whether the LSP has been protected, whether the data has been handed over,
whether it is the bandwidth that has been protected, and whether it is protected by
a node.
8-9
SJ-20140731105308-016|2014-10-20 (R1.0)
The establishment of an active LSP is triggered by configuring a tunnel on the head

node (RT1) manually. Before the establishment, if the FRR attribute of the LSP has
been specified through commands, RSVP will add the flag bits (whether the LSP
needs local protection, whether to record labels and whether to use SE style) to the
SESSION_ATTRIBUTE object of the PATH message. If bandwidth has been specified
for the LSP, the flag bit for bandwidth protection will also be added to the object. When
the downstream nodes receive this PATH message, they know that it is an LSP needing
FRR by identifying the local protection flag.
For an LSP needing FRR (identified according to the flags in the previous PATH message),
when the nodes send RESV messages to the upstream, they will record the egress,
LSR ID and label of an RESV message in RECORD_ROUTE object. The information is
cumulatively transmitted to the upstream nodes.
When the node receive the RESV message for the first time, they select a suitable
Bypass LSP for the LSP according to the information in the RECORD_ROUTE object.
The procedure to select a suitable Bypass LSP for the active LSP is called binding. The
algorithm of the binding is introduced in details later.
After the binding FRR calculation for the active LSP, the RECORD_ROUTE object in the
RESV message sent to the upstream will point out whether the LSP has been protected. If
it is protected, the protected egress address (eth1 on RT2) and the egress address (eth3
on RT2) of the RESV message will be recorded. If it is not protected, the corresponding
flags in the RECORD_ROUTE object will be cleared, and only the egress address (eth3
on RT2) of the RESV message will be recorded. Binding calculation is not supported on
egresses. The flags in the RECORD_ROUTE object of an RESV message sent to the
upstream on the egresses are cleared.
The establishment of an active LSP with FRR protection is basically consistent with that
of a common LSP. The binding calculation is added to the establishment of an active LSP,
and some flags and sub-objects are added to the PATH message and RESV message.
Bypass LSP Establishment

There are two modes to establish a Bypass LSP, manual mode and automatic mode.
l
In manual Bypass LSP establishment, when a tunnel without FRR attribute is specified
to protect a physical interface, the LSP it corresponds to becomes the Bypass LSP. As
shown in Figure 8-6, the manual establishment of a Bypass LSP (tunnel12 on RT2)
is triggered by configuration on the PLR (RT2). The configuration has no difference
from that of a common LSP basically, except that FRR attribute cannot be configured
for a Bypass LSP. That is, a Bypass LSP cannot be an active LSP at the same time,
and LSPs cannot be nested-protected.
Automatic Bypass LSP is a simplification of the manual mode. When the active LSP
needs FRR protection, the PLR can select a Bypass LSP or establish a Bypass
LSP automatically to protect the active LSP. This mode is called automatic Bypass.
An automatic Bypass can protect multiple active LSPs as long as it meets the
requirements of the active LSPs.
8-10
SJ-20140731105308-016|2014-10-20 (R1.0)
A Bypass LSP can protect multiple physical interfaces, but it cannot protect the egress of
its own.
FRR can protect a link or a node. When Bypass LSP protection is needed, it is necessary
to plan the link or node to be protected and specify the protection mode (link protection or
node protection). Generally, node protection can protect the protected node and the link
between this node and the PLR. It seems that node protection is better.
Generally, the bandwidth of a Bypass LSP is used to protect the active LSP. All resources
on the tunnel are only used after handover. During configuration, it is necessary to make
sure that the bandwidth configured is not less than the sum of all LSPs to be protected.
Otherwise, when FRR is valid, Bypass cannot provide the protection that meets the
requirements of user services completely.
Generally, Bypass LSP is in idle state, and it does not carry over data services. If the
Bypass LSP is intended to protect the active LSP and forward data at the same time, it is
required to configure enough bandwidth.
Binding Calculation
Binding can mean to specify a Bypass LSP to protect a physical interface. This is called
the binding between a Bypass LSP and a physical interface. A Bypass LSP can be bound
to multiple physical interfaces. A physical interface can also be bound to multiple Bypass
LSPs.
Binding can also mean to select a suitable Bypass LSP to protect an active LSP. This is
called the binding between an active LSP and a Bypass LSP. The binding calculation is the
procedure to bind an active LSP to a Bypass LSP. If the binding calculation succeeds, the
RESV message will inform the upstream nodes that the active LSP has been protected.
The result of the binding calculation includes the following items:
l
l
l
Protection type (it is link-type protection or node-type protection) and LSR ID of the
MP
The label distributed by the MP for the previous hop (This label corresponds to the
label of the MP LSR ID in RECORD_ROUTE object of the active LSP.)
Bypass LSP interface and the NHLFE information of the Bypass LSP
The result is mainly used for the sending of data and signaling from the Bypass LSP after
handover.
The binding calculation result is saved. When local invalidation occurs, the result can be
used immediately. This is the reason why MPLS TE FRR can make fast responses to
invalidations.
Invalidation Detection
Invalidation detection aims at discovering the invalidation of the link (between RT2 and
RT3) or the node (RT3) as soon as possible, thus to trigger handover to reduce packet
loss.
8-11
SJ-20140731105308-016|2014-10-20 (R1.0)
Invalidation detection does not judge whether it is an invalidation of a link or a node. It is

considered as an interface invalidation (eth1 of RT2) at last.
Interface invalidation triggers all LSPs that use this interface as egress to execute FRR
handover as soon as possible. If an LSP has been protected by a link according to the
binding calculation result, the data will be handed over to the protecting link. When it is a
node invalidation in fact, the protection will not succeed, and this LSP will be deleted. If
the LSP has been protected by a node according to the binding calculation result, the data
will be handed over to the protecting node. When it is a link invalidation in fact, the Bypass
LSP will be overleaped even if the next hop node is available.
A part of link invalidations and node invalidations can be detected by link layer protocols.
The speed of the link layer protocols to discover an invalidation is related to the interface
type. Other invalidations are discovered through the Hello mechanism of RESV. The speed
of the Hello mechanism to discover an invalidation is relatively slower.
It is possible to enable Hello mechanism on each physical interface that needs protection.
When Hello mechanism is also enabled on the peer interface, Hello messages and
responses will be sent periodically between two routers. When a link or a node is invalid,
the Hello message or response will be lost. If the message or response is lost for continual
three times, it is considered that an invalidation occurs.
Handover Procedure
Handover means to enable the Bypass LSP. The data and RSVP messages on the active
LSP will not be forwarded along the previous path.
Handover can be triggered when the interface (eth1 of RT2) is closed by a command or
when invalidation detection discovers an interface (eth1 of RT2) invalidation. The data and
signaling of the protected LSP on the invalid interface will be handed over to the Bypass
LSP. The upstream nodes are informed that the handover occurs.
LSP Maintenance After Handover

After the handover, the previous LSP is unavailable. To prevent the LSP from being deleted
when it expires, RSVP needs to keep message flush between PLR (RT2) and MP (RT4).
The PATH message is sent to the MP through the Bypass LSP (Tunnel12 on RT2) after
modification. When the MP receives the PATH message, it confirms that itself is the
MP node. The RESV message is sent to the PLR node through multi-hop IP forwarding
(passing by RT4 - RT7 - RT2) after the modification.
After the handover, the PATH message sent to the MP by the PLR is changed according
to the following points:
1. The egress interface (eth2 on RT2) address of the PLR on the Bypass LSP is filled in
the PHOP field.
2. The ingress LSR ID in SENDERTEMPLATE is changed to the egress interface (eth2
on RT2) address of the PLR on the Bypass LSP.
3. The PLR address recorded in RECORD_ROUTE object is changed to the egress
interface (eth2 on RT2) address of the PLR on the Bypass LSP.
8-12
SJ-20140731105308-016|2014-10-20 (R1.0)
4. All nodes previous to the MP are deleted in an Explicit Route Object (ERO). The
address first belonging to the MP is changed to the MP LSR ID.
The MP receives the PATH message through the Bypass LSP. As the SESSION is not
changed, but the ingress LSR ID (it is RT1 LSR ID previously) in SENDERTEMPLATE is
changed to the egress interface (eth2 on RT2) address of the PLR on the Bypass LSP, MP
will know that this is a PATH message after the FRR handover and the local node is the
MP.
The PATH message sent to downstream by the MP does not change with the handover.
The RESV message sent to upstream by the MP is changed according to the following
points:
1. The Filter Spec source address in the message is changed to the PHOP address
(address of eth2 on RT2) in the PATH message.
2. The NHOP in the message is changed to the ingress interface (eth2 on RT4) address
of the MP on the Bypass LSP.
3. The RECORD_ROUTE object in the RESV message records the ingress interface
(eth2 on RT4) address of the MP on Bypass LSP.
4. The destination in the IP header of the message is the egress interface (eth2 on RT2)
address of the PLR on the Bypass LSP.
5. The Time To Live (TTL) value in the RESV message is set to 255. The TTL value in
the header of the protocol message is set to 1.
After the handover, the RESV message sent to upstream by the PLR also has some
changes. The egress interface (eth2 on RT2) address of the PLR on the Bypass LSP
is added to the RECORD_ROUTE object.
After the handover, the forwarding paths of PTEAR message, RERR message, RTEAR
message and PERR message of the active LSP also change.
After the handover of node protection, the protected node (RT3) may send the PTEAR
message to downstream due to the expiration of the PATH message. The MP (RT4) will
ignore this message. In addition, the MP will send the RTEAR message on the previous
LSP ingress interface (eth3 on RT4) during the handover. This is to make the protected
node (RT3) release corresponding resource as soon as possible.
MBB
For FRR, a function of Make Before Break (MBB) is to make the LSP (tunnel1 on RT1)
protected by the Bypass LSP recover to normal state. When handover occurs on the active
LSP, the head node starts the MBB procedure to calculate a new available path. When
the new path is established, a new suitable standby LSP will be selected to form the new
binding relationship.
Data Forwarding
Before the handover, the data forwarding on the active LSP is the same with that on a
common LSP. After the handover, the data is forwarded to the MP through the Bypass
LSP.
8-13
SJ-20140731105308-016|2014-10-20 (R1.0)
8.5.3 Configuring TE FRR

For the principle and configuration of TE FRR, please refer to the related topics in ZXR10
M6000-S Carrier-Class Router Configuration Guide (MPLS).
8-14
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 9
OAM Binding Configuration

Table of Contents
Overview ....................................................................................................................9-1
Configuring the Interface Association Detection Function ...........................................9-4
Binding the OAM Function to an Interface ..................................................................9-5
9.1 Overview
For some network applications, users cannot deploy end-to-end PWs or tunnels. As a
result, the service protection is complicated, especially in a multi-point fault scenario, and
services may be interrupted. In a typical bridging network solution, the access layer,
convergence layer, and core layer respectively use their network protection measures.
However, there is no mapping mechanism among these layers, which may result in service
interruption in case of a multi-point fault.
Figure 9-1 shows a bridging network. The access layer uses the "PW-FRR + VRRP"
protection, the convergence layer uses the "Hot-Standby + VPN-FRR" or "static
end-to-end tunnel + VPN-FRR" protection, and the core layer uses the "dynamic VRRP
+ active/standby" protection. If a multi-point fault occurs, for example, 1 and 2, 2 and 3,
3 and 4, or 4 and 5, the end-to-end service is interrupted.
A multi-point fault may result in end-to-end service interruption, because the access layer,
convergence layer, and core layer only provide protection on the local layers, and cannot
detect faults of other layers. As a result, a normal layer sends data through original routes,
and a faulty layer cannot transfer service traffic because of the multi-point fault.
9-1
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 9-1 Multi-Point Fault Network Solution
The OAM mapping and linkage between different layers can solve the above problem. For
the principle, see Figure 9-2.
9-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 9 OAM Binding Configuration
Figure 9-2 OAM Mapping and Linkage Principle
When R1 detects that faults 1 and 2 occur simultaneously, R1 notifies R2 about the faults
through the application fault OAM binding function, and then R2 performs the protection
switching.
The association can be implemented through detection groups. The association can be
used to shut down a port or prevent the port from transferring messages (excluding OAM
messages).
l
l
Method 1: Associated physical and logical ports are shut down.

Method 2: If the SF flag is configured at a logical interface, only OAM messages can
be transferred.
9-3
SJ-20140731105308-016|2014-10-20 (R1.0)
9.2 Configuring the Interface Association Detection

Function
This procedure describes how to configure the interface association detection function by
using related commands.
Steps
1. Configure the L2 association detection function for an interface.
Step
Command
Function
ZXR10(config)#interface {<interface-name>|byname
Enters interface configuration
<byname>}
mode.
ZXR10(config-if-interface-name)#track
Configures the L2 association
<track-name>[group]
detection function for the
interface.
<track-name>: track name (range: 1-31 characters).

[group]: Optional. Indicates whether it is a detection group. Set this parameter to
group to indicate a detection group. If this parameter is not specified, it is not a
detection group.
2. Configure the IPv4 association detection function for an interface.
Step
Command
Function
<byname>}
mode.
ZXR10(config-if-interface-name)#ipv4 track
Configures the IPv4
<track-name>[group]
association detection function

for the interface.

detection group.
3. Configure the IPv6 association detection function for an interface.
Step
Command
Function
<byname>}
mode.
ZXR10(config-if-interface-name)#ipv6 track
Configures the IPv6
<track-name>[group]
association detection function
for the interface.

9-4
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 9 OAM Binding Configuration

detection group.
4. Verify the configuration result.
Command
Function
ZXR10(config)#show running-config-interface
Queries the interface
[interface-name]
configuration.
End of Steps
9.3 Binding the OAM Function to an Interface

This procedure describes how to bind the OAM function to an interface.
Steps
1. Block or shut down an interface based on the interface detection result.
Step
Command
Function
<byname>}
mode.
ZXR10(config-if-interface-name)#track
Blocks or shuts down an
trigger<track-name>[group]{block|shutdown}
interface based on the

interface detection result.

[group]: Block or shut down an interface based on the interface detection result.
{block|shutdown}: block means blocking an interface, and shutdown means shutting
down an interface.
2. Verify the configuration result.
Command
Function
ZXR10(config)#show running-config-interface
Queries the interface
[interface-name]
configuration.
End of Steps
9-5
SJ-20140731105308-016|2014-10-20 (R1.0)
9-6
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 10
Graceful Restart
Configuration
Table of Contents
IP Graceful Restart Configuration .............................................................................10-1
LDP Graceful Restart Configuration .........................................................................10-3
10.1 IP Graceful Restart Configuration

Introduction
In many situations, occasional interruption of a router is unpredictable, which may cause
the interruption of the forwarding data flow and the route oscillation. If the control function
of a router can be separated from the forwarding function, a certain policy can be used
to reduce the impact on the restarted router and its neighbors caused by an interruption
event to the minimum extent. The type of the policy is Graceful Restart (GR).
This chapter describes the applications of IP GR in the following fields.
l
l
l
Applying IP GR in OSPF
Applying IP GR in IS-IS
Applying IP GR in BGP
OSPF/IS-IS GR
This policy is:
1. Other routers on the network keep their link states during the IS-IS/OSPF restart
period.
2. The restarted router keeps its forwarding information before the restart in a short
period, that is, the FIB can keep steady on the restarted router in a short period, thus
not affecting the forwarding of the data flow.
3. After the router is restarted, the router finishes the LSP/Link State Advertisement (LSA)
synchronization with its neighbor routers quickly.
4. The router calculates Shortest Path First (SPF) after the LSP/LSA database
synchronization.
With this policy, the restarted router still can forward data during the restart period, and
the neighbor routers still can operate properly during the restart period. The restart will not
cause any route oscillation.
10-1
SJ-20140731105308-016|2014-10-20 (R1.0)
BGP GR
At present, the routing protocols only run on the Management Process Units (MPUs)
of a router. The routing protocols do not run on a standby board. After active/standby
changeover, the routing protocols run on the standby board.
To support the GR capability, the route protocol needs to accomplish the following tasks.
l
l
Prevent the neighbor relationship between the neighbor routers and the restarted
router from being oscillated during the restart period.
After the restart, the restarted router synchronizes the routing information with its
neighbor routers as soon as possible, and then updates the local routing information.
The BGP GR principle on a GR router and a helper router is described as follows:

l
GR Router
1. When initiating to establish the BGP neighbor relationship, R1 and R2 negotiate
the GR capability through OPEN messages.
2. When the R1 is restarted, routes are kept on the interface cards for forwarding
data.
3. The R1 establishes a new Transfer Control Protocol (TCP) connection with the
neighbor R2. In the BGP OPEN message, When the Restart state field in the
BGP OPEN message is set to 1, it indicates that the router is restarted just now.
At the same time, the router advertises the value of restart time to neighbors (this
value should be less than the Holdtime value in the OPEN message). In addition,
the router also needs to inform the neighbors of the supported address family
route GR.
4. After establishing BGP neighbor relationship with R2 successfully, R1 receives
and processes the route updates from the neighbor and starts the Wait-For-EOR
timer.
5. The R1 puts the local BGP route calculation off until it receives the End-of-RIB
flags from all GR-Aware BGP neighbors or until the local Wait-For-EOR timer
times out.
6. The R1 calculates routes and sends route updates to the neighbors. After the
updates are completed, R1 sends the End-of-RIB flags to the neighbors.
Helper Router
1. When initiating to establish BGP neighbor relationship, R2 negotiates with R1
about the GR capability, and it records R1 as a GR-Capable router.
2. When R1 is restarted, R2 may be aware that the TCP connection between itself
and R1 is disconnected, or maybe R2 does not detect the disconnection before
a new TCP connection is established between them. If R2 does not detect the
disconnection, go to Step 4. Otherwise, go to Step 3.
3. The R2 keeps the routes sent from the restarted router R1 and marks the stale
flags. After that, R2 starts the Restart Timer.
4. The restarted router initiates to establish a new connection, deletes the Restart
Timer, and starts the Wait-For-EOR Timer.
5. If the Restart Timer times out before the new connection is established, or if R2
receives the OPEN message (for the new connection) whose Forwarding state
10-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 10 Graceful Restart Configuration
is not 1 (The Forwarding state value 0 indicates that the restarted router does
not support nonstop forwarding of the corresponding address family routes), or if
the OPEN message does not contain the corresponding AFI/SAFI address family
support information, R2 goes to Step 8.
6. Otherwise, R2 sends route updates to the restarted router. After that, it sends the
End-Of-RIB flags.
7. If the Wait-For-EOR Timer times out before the End-Of-RIB flags are sent, R2
goes to Step 8.
8. The kept routes of the restarted router is cleared. The data is forwarded in
accordance with the normal BGP forwarding flow.
Configuring IP Graceful Restart

For the configuration commands and configuration examples of IP Graceful Restart, refer
to related topics in the ZXR10 M6000-S Configuration Guide (IPv4 Route).
10.2 LDP Graceful Restart Configuration

LDP Graceful Restart Introduction
In the MPLS network, you must try to ensure that the system is in normal status. In this
case, the system can be in steady status for a long period. Many factors may result in
the instability of a system, such as interrupted physical link, unstable protocol, or system
update. For the faults resulting from the restart of the LSR control plane, or the data transfer
corresponding to the restart of the LDP control plane, you can solve them by using the LDP
Graceful Restart mechanism.
l
When the LDP Graceful Restart mechanism is not used, and the session is interrupted
for the restart of the version, protocol, or session, all related control modules and
transferring items will be deleted. In addition, you need to bind the flag after the
session is restarted again.
After the LDP Graceful Restart mechanism is used (the router can transfer data), all
items can be transferred through the old flag after the session is interrupted. In this
case, the operations on the control plane have no effect on the data plane.
The LSD Graceful Restart mechanism is used for the LSR that can transfer the data or
cannot transfer the data during the LDP restart. However, at least one LSR can transfer
data during the restart. For the LSR that cannot transfer data, it helps the neighbor node
to reduce the influence on the data transferring although it cannot reduce the influence on
its own data transferring.
LDP Graceful Restart Work Flow

The restart of the LDP control plane includes the following aspects:
l
Session restart. During this restart, the LSR can transfer data, and the session can
be established again. In this case, you may not know which LSR is restarted. These
10-3
SJ-20140731105308-016|2014-10-20 (R1.0)
two LSRs save the control information of the LDP protocol, so they can be considered
as the auxiliary node.
LSR restart or LDP signaling restart. During this restart, LSR can transfer data. For
example, restart nodes and auxiliary nodes exist during the version update or the
active/standby changeover. The restart node has no control information of the LDP
protocol layer, so the corresponding handling methods are different.
The working process of the LDP Graceful Restart mechanism is as follows:

l
Restart node
1. When the control plane of the LSR is restarted, you must ensure that it can transfer
data during the recovery process. If not, you need to set the Recovery Time in
the Initialization message sent to the peer end to 0s.
2. If the LSR can transfer data, you need to start the timer (the corresponding value
can be set), and then set all the transferred items to stale. When the timer times
out, delete all transferred items marked with stale. The notified Recovery time
when you re-establish the session is the remaining time of the timer when the
Initialization message is sent.
3. During the restart, the LSR still can transfer data with the old transferring items. At
the same time, it can establish a session again and send the mapping information
through the processes stipulated in the LDP protocol. When the LSR receives
a mapping message, it will find the corresponding items in the transferring table,
and then clear the stale mark. In this case, the restart process is completed.
Auxiliary node
1. After the LSR finds that the session with the the neighbor is down, it will confirm
that the the neighbor node can transfer data in accordance with the FT Reconnect
Timeout in the Initialization message when a session is established. If the the
neighbor node can transfer data, it will set all transferring labels learnt from the
session to stale, and then save these labels for the later data transferring.
2. When the session is down, the LSR restarts the reconnect timer. The set time is
the minimum value between the FT Reconnect Timeout notified by the peer end
and the Neighbor Liveness time configured locally. In this case, the LSR waits
for both parties to establish the session again. If the session is not established
successfully after the timer times out, the forwarding items marked with stale will
be deleted.
3. If the session is established successfully before the timer times out, the LSR will
cancel the timer, and determine the recovery time notified by the peer end. If the
the neighbor router cannot transfer data, it will delete all the items marked with
stale. If the the neighbor router can transfer data, this LSR will restart the timer.
The set time is the minimum time between the Recovery Time notified by the peer
end and the Maximum Recovery time configured locally.
4. After receiving the mapping message from the peer end, the LSR will recover or
update the items marked with stale, and then clear the stale mark. At the same
time, this router will send the mapping information on the assumption that the
session is in up status. If the timer times out, the LSR will delete all the transferring
items marked with stale.
10-4
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 10 Graceful Restart Configuration
The following uses an example to describe the working process of LDP Graceful Restart.
R1 and R2 is configured with the LDP Graceful Restart function, and the session and the
corresponding LSP that supports the LDP Graceful Restart function are established, see
Figure 10-1.
Figure 10-1 Network Architecture of LDP Graceful Restart Configuration
The working process of the LDP Graceful Restart function is as follows:

1. The R1 finds that the service between R1 and R2 is interrupted, so the session is
down.
2. The R1 marks all external labels learned from R2 with stale. However, these labels
also can be used for data transferring.
3. A session is established again between R1 and R2.
4. The R1 and R2 notify the label binding information. When R1 learns the external label
of R2, it will clear the mark stale.
Configuring LDP Graceful Restart

For the configuration commands and configuration examples of LDP Graceful Restart,
refer to related topics in the ZXR10 M6000-S Configuration Guide (MPLS).
10-5
SJ-20140731105308-016|2014-10-20 (R1.0)
10-6
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 11
NSR Configuration
Table of Contents
NSR Overview..........................................................................................................11-1
Configuring the NSR Function ..................................................................................11-2
NSR Configuration Example.....................................................................................11-3
11.1 NSR Overview

During the network application, device faults resulting from various factors may cause
the interruption of network services. To minimize the influence of device faults on the
whole network, it is required to design a high-reliability device to improve the system fault
tolerance and fault recovery speed.
The high reliability is one of the important indexes to judge a device. At present, the
reliability technology includes:
l
GR: a series of standards defined in IETF, which ensures that the package forwarding
operation is not interrupted when the protocol is restarted. This function minimizes the
influence of faults on the whole network.
NSR: a higher reliability technology. It ensures that the route between the forwarding
plane and the control plane is not interrupted after the switchover between the
active/standby control planes. With this function, the device faults almost have no
influence on the whole network.
Traditionally, route convergence happens when the device has a fault. During the route
convergence, both loops and black holes may occur, which have serious influence on the
network.
With the NSR function, a fault is recovered within the device, so there is no influence
on the network. The NSR function synchronizes valid information in real time between
the processing units of the active/standby control planes. During the active/standby
switchover, the NSR function ensures that the route between the forwarding plane and the
control plane is not interrupted. After the switchover, extra protocol recovery procedures
with its neighbors are not required.
NSR Principle
After the NSR function is enabled for the device, the normal handling flow is as follows:
1. Input packages are sent to the processing unit of the active control plane.
11-1
SJ-20140731105308-016|2014-10-20 (R1.0)
2. After receiving the input packages, the processing unit of the active control plane
processes these packages, generates necessary check information, and then sends
all packages to the processing unit of the standby control plane.
3. After receiving the packages from the processing unit of the active control plane, the
processing unit of the standby control plane processes all information, and then sends
a complete message to the processing unit of the active control plane.
4. After receiving the complete message from the processing unit of the standby control
plane, the processing unit of the active control plane sends all output packages
generated by itself.
The device with the NSR function synchronizes the information in real time between the
processing units of the active/standby control planes, which ensures that the statuses
and processing logics of the processing units of the active/standby control planes are the
same. When the processing unit of the active control plane is faulty, the active/standby
switchover happens. The processing unit of the standby control plane immediately
becomes active. In this case, the services of both the forwarding plane and the control
plane are not interrupted, and extra protocol recovery procedures with its neighbors are
not required.
11.2 Configuring the NSR Function

This procedure describes how to configure the NSR function.
Steps
1. Enable the NSR function.
Command
Function
ZXR10(config)#nsr enable all
Enables the NSR function.
2. Disable the NSR function.

Command
Function
ZXR10(config)#nsr disable all
Disables the NSR function.

Command
Function
ZXR10#show synchronization [MPU- | detail]
Displays the real-time

synchronization information
between the active/standby
control planes.
[MPU- ]: displays the CPU synchronization information.

11-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 11 NSR Configuration
[ detail]: displays the detailed status information between the active/standby

synchronization.
End of Steps
11.3 NSR Configuration Example

Figure 11-1 shows the network. The device is enabled with the NSR function after it
operates for a while.
Figure 11-1 NSR Configuration Example
Configuration Flow
1. Confirm that the device operates properly. The ACT indicator on the active main
control board is ON, and that of the standby main control board is OFF. The RUN
indicators on both the active/standby main control boards flash at the frequency of
1Hz. The ALARM indicators on the active/standby main control boards are OFF.
2. Configure the NSR function.
3. Check the NSR configuration results.
Run the following command on the ZXR10 M6000-S:
ZXR10(config)#nsr enable all
Run the show synchronization detail command to check the NSR configuration results. The
ZXR10(config)#show synchronization detail
======================================================================
======================================================================
Module
: the name of module
LE
: the name of logic entity
Sync-type
: the type of synchronization
Sync-state : the state of synchronization

======================================================================
======================================================================
Module
LE
Sync-type
Sync-state
11-3
SJ-20140731105308-016|2014-10-20 (R1.0)

======================================================================
ISIS
T_SC
GR
Synchronized
---------------------------------------------------------------------OSPF
T_SC
GR
Synchronized
---------------------------------------------------------------------BGP
T_SC
GR
Synchronized
---------------------------------------------------------------------RIP
T_SC
GR
Synchronized
---------------------------------------------------------------------BASE
T_SC
GR
Synchronized
---------------------------------------------------------------------LDP
T_SC
GR
Synchronized
---------------------------------------------------------------------MPLSTE
T_SC
GR
Synchronized
---------------------------------------------------------------------======================================================================
DB sync-state
: Synchronized
System file sync-state
: Synchronized
======================================================================
/*The NSR function takes effect only when it is used together with a module,
for example, the IS-IS and OSPF.*/
11-4
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 12
Master/Slave Main Control

Handover
Table of Contents
Master/Slave Main Control Handover Overview........................................................12-1
Configuring the Active/Standby Switchover ..............................................................12-2
Master/Slave Main Control Handover Configuration Example...................................12-3
12.1 Master/Slave Main Control Handover Overview

Master/slave handover means the handover between the master main control board and
the slave main-control board. When the master main control board operates improperly
(powered off or reset manually), if the slave main-control board is online, the system will
implement handover automatically. This handover is transparent to applications at upper
layer.
Master/slave main-control board handover shields off the influence due to the faults on
the main switching board. Applications at upper layer are not affected, which ensures the
timely handling of system data information.
The automatic master/slave handover is triggered when the master main-control plane
is restarted. In addition, you can run the master/slave handover command or press
the master/slave handover button on the main-control board to trigger the master/slave
handover.
The master/slave handover is implemented by the process modules operating on the
main-control board. The flow of master/slave handover is as follows:
1. Control the handover order of application process, and then send slave-to-master and
master-to-slave messages to application processes, that is, the master/slave handover
of application programs.
2. Set the master/slave state of boards, and interact with communication modules for
handover of communication links with periphery boards, that is, the communication
link handover.
During this period, the intermediate state handover of application processes and data
synchronization (including the time when data is synchronized) are completed by
application processes themselves.
For the boards with master/slave configuration, if a fault occurs on the master main-control
board, the slave board needs to know the fault quickly and implement the handover.
Therefore, it is necessary to use a mate board scan thread to scan the state of the mate
12-1
SJ-20140731105308-016|2014-10-20 (R1.0)
board in real time. When the master/slave state or in-place state changes, the scan
thread will inform the corresponding main-control process to trigger the master/slave
handover flow quickly.
When the thread scans that the master board operates improperly and the slave board
operates properly, it will trigger the handover. The procedure of handover is implemented
by the corresponding process module of the main-control.
12.2 Configuring the Active/Standby Switchover

This procedure describes how to configure the active/standby switchover.
The
active/standby switchover includes the compulsive switchover and graceful switchover.
Context
You can implement active/standby switchovers through commands, by removing and
re-installing the active main control board, by pressing the EXCH button, by pressing the
reset button on the active main control board, or when a fault occurs on the active main
control board.
Active/standby switchover can be classified into compulsive switchovers and graceful
switchovers.
l
Compulsive switchover: Includes the switchovers caused by executing the force

command, by removing and re-installing the active main control board or pressing
the reset button, and the switchovers due to faults on the master main control board.
Graceful switchover: Includes the switchovers caused by executing the grace
command and pressing the EXCH button.
The differences between a compulsive switchover and a graceful switchover are described
below.
l
For a compulsive switchover (except the force command switchover), the system
does not check whether the conditions to perform switchover are met. No matter
which state the board is in at present, the switchover is accomplished by resetting the
master main control board.
When you run the force command to complete the active/standby switchover, you
need to check required conditions for the switchover, for example, the standby board is
online, the file initialization is completed, and the database initialization is completed.
The active/standby switchover fails when one condition is not met.
For a graceful switchover, the system checks whether the conditions to perform
switchover are met, for example, whether the slave board is online, whether the
version synchronization is completed, whether the process is powered on, and
whether the database synchronization is completed.
12-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 12 Master/Slave Main Control Handover
Steps
1. Check the active/standby synchronization status before the active/standby switchover
configuration.
The prerequisites to execute the active/standby switchover correctly are as follows:
the active/standby main control boards are online and are operating properly, and the
synchronization of the active/standby database is completed.
Before executing the active/standby switchover, run the following commands to
verify that the active and the standby main control boards are online, and that the
synchronization of the active and the standby database is completed.
Commands
Function
ZXR10#show processor
Verifies that the master and the slave main

control boards are online.
Checks the synchronization status of the
ZXR10#show synchronization
logical entities of the active/standby main

control boards.
2. Configure active/standby main control switchover.

Command
Function
ZXR10#redundancy switch sc force [<Line>]
Implements a compulsive switchover.
ZXR10#redundancy switch sc grace [<Line>]
Implements a graceful switchover.
End of Steps
12.3 Master/Slave Main Control Handover Configuration

Example
As shown in Figure 12-1, the three devices work properly at first. After a period, R2
implements master/slave handover.
Figure 12-1 Master/Slave Main Control Handover
Configuration Flow
1. When the device work properly, the ACT indicator for the master main control board is
on, and the ACT indicator for the slave main control board is off. The RUN indicator for
12-3
SJ-20140731105308-016|2014-10-20 (R1.0)
the master main control board flashes at the frequency of 1 Hz. The ALM indicators
for the master and slave main control boards are off.
2. Use one of the following operations to implement master/slave handover:
a. Configure the master/slave main control handover command.
b. Press the reset button on the master main control board.
c.
Plug out the master main control board and then plug it in.
d. Press the EXCH button on the master main control board.

3. After the master/slave handover, the RUN indicator for the new master main control
board is on. Besides the alarm indicating the master/slave handover, there is no other
alarm.
The command used to configure master/slave main control handover is shown below.
ZXR10#redundancy switch sc grace
Proceed with redundancying switch SC? [yes/no]:yes
View the configuration result, as shown below.
/*Before the handover*/
R2#show processor
================================================================================
================================================================================
Character: CPU current character in system
MSC
: Master-SC in Cluster System
SSC
: Slave-SC in Cluster System
N/A
: None-SC in Cluster System
CPU(5s)
: CPU usage ratio measured in 5 seconds
CPU(1m)
: CPU usage ratio measured in 1 minute
CPU(5m)
: CPU usage ratio measured in 5 minutes
Peak
: CPU peak usage ratio measured in 1 minute
PhyMem
: Physical memory (megabyte)
FreeMem
: Free memory (megabyte)
Mem
: Memory usage ratio
================================================================================
================================================================================
Character CPU(5s) CPU(1m) CPU(5m) Peak PhyMem FreeMem Mem

================================================================================
PFU-0/1/0
N/A
10%
10%
11%
18%
2048
718
64.941%
-------------------------------------------------------------------------------PFU-0/3/0
N/A
9%
8%
9%
9%
4096
2451
40.161%
-------------------------------------------------------------------------------MPU-0/5/0
SSC
9%
9%
9%
9%
4096
2849
30.444%
--------------------------------------------------------------------------------
12-4
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 12 Master/Slave Main Control Handover

MPU-0/6/0
MSC
27%
24%
26%
27%
6144
4190
31.803%
-------------------------------------------------------------------------------/*The character of MPU-0/6/0 is displayed as an MSC. This means that it is the

master main control board at present. The character of MPU-0/5/0 is displayed
as an SSC. This means that it is the slave main control board at present. The
main control board is in Slot 6.*/
/*After the handover*/

R2#show processor
================================================================================
================================================================================
Character: CPU current character in system
MSC
: Master-SC in Cluster System
SSC
: Slave-SC in Cluster System
N/A
: None-SC in Cluster System
CPU(5s)
: CPU usage ratio measured in 5 seconds
CPU(1m)
: CPU usage ratio measured in 1 minute
CPU(5m)
: CPU usage ratio measured in 5 minutes
Peak
: CPU peak usage ratio measured in 1 minute
PhyMem
: Physical memory (megabyte)
FreeMem
: Free memory (megabyte)
Mem
: Memory usage ratio
================================================================================
================================================================================
Character CPU(5s) CPU(1m) CPU(5m) Peak PhyMem FreeMem Mem

================================================================================
PFU-0/1/0
N/A
10%
10%
11%
18%
2048
718
64.941%
-------------------------------------------------------------------------------PFU-0/3/0
N/A
9%
8%
9%
9%
4096
2451
40.161%
-------------------------------------------------------------------------------MPU-0/5/0
MSC
100%
100%
9%
100%
4096
2849
30.444%
-------------------------------------------------------------------------------MPU-0/6/0
SSC
26%
25%
27%
27%
6144
4190
31.803%
-------------------------------------------------------------------------------/*The character of MPU-0/6/0 is displayed as an SSC. This means that it is the

master slave control board at present. The character of MPU-0/5/0 is displayed
as an MSC. This means that it is the master main control board at present. After the
handover, the main board in Slot 5 becomes master, and the main control board in
Slot 0 becomes slave.*/
12-5
SJ-20140731105308-016|2014-10-20 (R1.0)
12-6
SJ-20140731105308-016|2014-10-20 (R1.0)
Chapter 13
Load Sharing Configuration

Table of Contents
Load Sharing Overview ............................................................................................13-1
Configuring Route Load Sharing...............................................................................13-1
Configuring Multicast Load Sharing ..........................................................................13-2
Configuring MPLS VPN Load Sharing ......................................................................13-2
13.1 Load Sharing Overview

The load sharing supported by the ZXR10 M6000-S includes the route load sharing, the
multicast load sharing, and the MPLS VPN load sharing.
A router forwards an IP packet in accordance with the IP routing table. When there are
several paths to the same destination prefix in the routing table, the priorities of these
paths may be the same or different. The router always selects the route with the highest
priority as the action path. If multiple paths have the same highest priority, the traffic to the
destination prefix can be shared by these paths to implement the load sharing.
With increasing traffic in the network, the requirement on the performance, such as
bandwidth and delay, becomes increasing higher. At present, the optimization route
forwarding is used. All traffic is forwarded through a single link. In this case, the above
requirement cannot be met. So, it is required to establish multiple LSPs in accordance
with different routes and balance the traffic in accordance with a certain rule. The traffic is
allocated to different links for forwarding to implement the load sharing function of MPLS.
The MPLS VPN load sharing includes three parts:
l
l
l
LDP
VRF
MP-BGP
Through the configuration for these three parts, several routes from the external layer and
internal layer of the MPLS VPN and the CE side share the load in the private network and
the public network.
13.2 Configuring Route Load Sharing

The route load sharing function is normally used together with a routing protocol. For
the principle and configuration commands, refer to related topics in the ZXR10 M6000-S
Configuration Guide (IPv4 Routing).
13-1
SJ-20140731105308-016|2014-10-20 (R1.0)
13.3 Configuring Multicast Load Sharing

For the principle and configuration commands of the multicast load sharing, refer to related
topics in the ZXR10 M6000-S Configuration Guide (IPv4 Multicast).
13.4 Configuring MPLS VPN Load Sharing

For the principle and configuration commands of the MPLS VPN load sharing, refer to
related topics in the ZXR10 M6000-S Configuration Guide (VPN).
13-2
SJ-20140731105308-016|2014-10-20 (R1.0)
Figures
Figure 2-1 Linkage Among VRRP, SAMGR, EOAM and BFD.................................... 2-2
Figure 2-2 Linkage of Symmetrical Dual-Connection Between CE and PE................ 2-3
Figure 2-3 Linkage Between EFM and VRRP ........................................................... 2-6
Figure 2-4 Link Between CFM and VRRP ................................................................. 2-9
Figure 3-1 Default Network Gateway in LAN ............................................................. 3-1
Figure 3-2 VRRP Election Flow................................................................................. 3-2
Figure 3-3 State Conversion in VRRP....................................................................... 3-4
Figure 3-4 Application of VRRP Monitoring Interface ................................................ 3-4
Figure 3-5 Application of VRRP Load Sharing........................................................... 3-5
Figure 3-6 EOAM for VRRP Application One ............................................................ 3-6
Figure 3-7 VRRP and EOAM State Transfer ............................................................. 3-7
Figure 3-8 EOAM for VRRP Application Two............................................................. 3-7
Figure 3-9 VRRP and EOAM + Peer BFD State Transfer .......................................... 3-8
Figure 3-10 EOAM for VRRP Application Three........................................................ 3-8
Figure 3-11 Basic VRRP Configuration (IPv4) ......................................................... 3-12
Figure 3-12 Symmetrical VRRP Configuration (IPv4) .............................................. 3-14
Figure 3-13 VRRP Heartbeat Configuration (IPv4) .................................................. 3-16
Figure 3-14 VRRP Track Configuration (IPv4)......................................................... 3-18
Figure 3-15 VRRP Function and VRRP-Related LINK BFD Function
Configuration ........................................................................................ 3-21
Figure 4-1 Application Overview of Ping Detect ........................................................ 4-1
Figure 4-2
Network Architecture of Ping Detect Configuration Example ................... 4-4
Figure 4-3 Track Ping Function Used for Directly Connected Routes ........................ 4-6
Figure 5-1 EFM Principle .......................................................................................... 5-2
Figure 5-2 Network Architecture of EFM Connection Establishment.......................... 5-6
Figure 5-3 EFM Remote Loopback ......................................................................... 5-10
Figure 6-1 Maintenance Domain ............................................................................... 6-2
Figure 6-2 CFM Connection Establishment............................................................... 6-7
Figure 6-3 Cross-L2 VPN Connectivity Detection .................................................... 6-12
Figure 7-1 PIM BFD Function Configuration Example ............................................. 7-10
Figure 7-2 Static Single-Hop BFD Configuration Example....................................... 7-14
Figure 7-3 Static Multi-Hop BFD Configuration Example ......................................... 7-16
I
SJ-20140731105308-016|2014-10-20 (R1.0)
Figure 8-1 VPN FRR + TE/LDP FRR Application Scenes.......................................... 8-3

Figure 8-2 VPWS/PWE3 FRR + TE/LDP FRR Application Scenes............................ 8-4
Figure 8-3 L2 VPN FRR Work Flow .......................................................................... 8-6
Figure 8-4 L3VPN FRR Networking Structure ........................................................... 8-7
Figure 8-5 FRR Though Bypass Mode...................................................................... 8-8
Figure 8-6 FRR in Bypass Mode ............................................................................... 8-9
Figure 9-1 Multi-Point Fault Network Solution ........................................................... 9-2
Figure 9-2 OAM Mapping and Linkage Principle ....................................................... 9-3
Figure 10-1 Network Architecture of LDP Graceful Restart Configuration................ 10-5
Figure 11-1 NSR Configuration Example................................................................. 11-3
Figure 12-1 Master/Slave Main Control Handover................................................... 12-3
II
SJ-20140731105308-016|2014-10-20 (R1.0)
Glossary
3G
- The 3rd Generation Mobile Communications
AC
- Access Circuit
APS
- Automatic Protection Switching
ARP
- Address Resolution Protocol
BFD
- Bidirectional Forwarding Detection
CCM
- Continuity Check Message
CFM
- Connectivity Fault Management
EFM
- Ethernet in the First Mile
ERO
- Explicit Route Object
FIB
- Forwarding Information Base
FRR
- Fast Reroute
GR
- Graceful Restart
IEEE
- Institute of Electrical and Electronics Engineers
IETF
- Internet Engineering Task Force
IGP
- Interior Gateway Protocol
IP
- Internet Protocol
IPTV
- Internet Protocol Television
III
SJ-20140731105308-016|2014-10-20 (R1.0)
IS-IS
- Intermediate System-to-Intermediate System
ITU
- International Telecommunications Union
LAN
- Local Area Network
LBM
- Loopback Message
LDP
- Label Distribution Protocol
LSA
- Link State Advertisement
LSP
- Label Switched Path
LSR
- Label Switch Router
LTM
- Link Trace Message
LTR
- Link Trace Reply
MA
- Maintenance Association
MAC
- Media Access Control
MAN
- Metropolitan Area Network
MIP
- Maintenance domain Intermediate Point
MP
- Merge Point
MPLS
- Multiprotocol Label Switching
MPU
- Management Process Unit
NGN
- Next Generation Network
NSR
- Non-Stop Routing
IV
SJ-20140731105308-016|2014-10-20 (R1.0)
Glossary
OAM
- Operation, Administration and Maintenance
OSPF
- Open Shortest Path First
OUI
- Organizationally Unique Identifier
PLR
- Point of Local Repair
PTN
- Packet Transport Network
PWE3
- Pseudo Wire Emulation Edge-to-Edge
QoS
- Quality of Service
RFC
- Request For Comments
SPF
- Shortest Path First
TCP
- Transmission Control Protocol
TTL
- Time To Live
VLAN
- Virtual Local Area Network
VPN
- Virtual Private Network
VRRP
- Virtual Router Redundancy Protocol
VoIP
- Voice over Internet Protocol
WAN
- Wide Area Network
V
SJ-20140731105308-016|2014-10-20 (R1.0)

SJ-20140731105308-016-ZXR10 M6000-S (V3.00.10) Carrier-Class Router Configuration Guide (Reliability) - 608083

Hochgeladen von

Dokumentinformationen

Originaltitel

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

SJ-20140731105308-016-ZXR10 M6000-S (V3.00.10) Carrier-Class Router Configuration Guide (Reliability) - 608083

Hochgeladen von

Copyright:

Verfügbare Formate

ZXR10 M6000-S

Configuration Guide (Reliability)

Additionally, the contents of this document are protected by

contractual confidentiality obligations.

Serial Number: SJ-20140731105308-016

ZTE Proprietary and Confidential

Chapter 3 VRRP Configuration ................................................................. 3-1

Chapter 4 Ping Detect Configuration........................................................ 4-1

Chapter 5 EFM Configuration.................................................................... 5-1

Chapter 6 CFM Configuration.................................................................... 6-1

ZTE Proprietary and Confidential

6.2 Configuring the CFM .......................................................................................... 6-4

Chapter 7 BFD Configuration .................................................................... 7-1

Chapter 8 FRR Configuration .................................................................... 8-1

Chapter 9 OAM Binding Configuration..................................................... 9-1

Chapter 10 Graceful Restart Configuration ........................................... 10-1

Chapter 11 NSR Configuration ................................................................ 11-1

ZTE Proprietary and Confidential

11.2 Configuring the NSR Function ..........................................................................11-2

Chapter 12 Master/Slave Main Control Handover ................................. 12-1

Chapter 13 Load Sharing Configuration ................................................ 13-1

ZTE Proprietary and Confidential

This page intentionally left blank.

ZTE Proprietary and Confidential

About This Manual

Network planning engineers

What Is in This Manual

Describes the meaning and requirements of Reliability, and the

relationship of various functions related to Reliability.

Chapter 2, Service Availability

Describes the SAMGR principle, configuration commands and

Describes the VRRP principle, configuration commands and

Chapter 4, Ping Detect

Describes the ping detect principle, configuration commands and

Chapter 5, EFM Configuration

Describes the EFM principle, configuration commands and

Chapter 6, CFM Configuration

Describes the CFM principle, configuration commands and

Chapter 7, BFD Configuration

Describes the BFD principle, configuration commands and

Chapter 8, FRR Configuration

Describes the FRR principle, configuration commands and

Chapter 9, OAM Binding

Describes the OAM Binding principle, configuration commands and

Chapter 10, Graceful Restart

Describes the GR principle, configuration commands and

Chapter 11, NSR

Describes the NSR principle, configuration commands and

ZTE Proprietary and Confidential

Chapter 12, Master/Slave

Describes the master/slave main control handover principle,

Main Control Handover

configuration commands and configuration instances.

Chapter 13, Load Sharing

Describes the load sharing principle, configuration commands and

Separates individual parameter in series of parameters.

Danger: indicates an imminently hazardous situation. Failure to comply can result in

Caution: indicates a potentially hazardous situation. Failure to comply can result in

ZTE Proprietary and Confidential

Network Fault Detection Technology

Transport layer and physical layer: Automatic Protection Switching (APS).

Protection Switching Technology

ZTE Proprietary and Confidential