SJ-20130205142913-019-ZXR10 M6000 (V1.00.60) Carrier-Class Router Configuration Guide (Reliability) PDF

ZXR10 M6000
Carrier-Class Router
Configuration Guide (Reliability)
Version: 1.00.60
ZTE CORPORATION
No. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright © 2013 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 ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No. Revision Date Revision Reason
R2.2 2013-02-28 Fourth edition, adding the "Cooperation Configuration Example

Between a Directly Connected Route and the Ping Detect" topic.
R2.0 2012-07-20 Third edition
R1.1 2012-03-30 Second edition
R1.0 2011-12-10 First edition
Serial Number: SJ-20130205142913-019
Publishing Date: 2013-02-28 (R2.2)
SJ-20130205142913-019|2013-02-28 (R2.2) 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 SAMGR Configuration ........................................................................................ 2-4
2.3 Maintaining SAMGR ........................................................................................... 2-6
2.4 SAMGR Configuration Instances ......................................................................... 2-9
2.4.1 Linkage between EFM and VRRP ............................................................. 2-9
2.4.2 Linkage between CFM and VRRP ........................................................... 2-12
Chapter 3 VRRP Configuration ................................................................. 3-1

3.1 VRRP Overview ................................................................................................. 3-1
3.2 VRRP Network Application ................................................................................. 3-4
3.3 Configuring VRRP .............................................................................................. 3-8
3.4 Maintaining VRRP .............................................................................................3-11
3.5 VRRP Configuration Instances .......................................................................... 3-13
3.5.1 Basic VRRP Configuration Example ........................................................ 3-13
3.5.2 Symmetrical VRRP Configuration Example .............................................. 3-15
3.5.3 VRRP Heartbeat Configuration Example.................................................. 3-18
3.5.4 VRRP BFD Configuration Example.......................................................... 3-20
Chapter 4 Ping Detect Configuration........................................................ 4-1

4.1 Ping Detect Overview ......................................................................................... 4-1
4.2 Configuring Ping Detect ...................................................................................... 4-2
4.3 Maintaining Ping Detect ...................................................................................... 4-3
4.4 Ping Detect Configuration Instances .................................................................... 4-4
4.4.1 Basic Ping Detect Configuration Examples................................................. 4-4
4.4.2 Cooperation Configuration Example Between a Directly Connected
Route and the Ping Detect....................................................................... 4-6
Chapter 5 EFM Configuration.................................................................... 5-1

5.1 EFM Overview ................................................................................................... 5-1
5.2 Configuring EFM ................................................................................................ 5-2
5.3 Maintaining EFM ................................................................................................ 5-4
5.4 EFM Configuration Instances .............................................................................. 5-6
5.4.1 EFM Connection Establishment ................................................................ 5-6

5.4.2 EFM Remote Loopback .......................................................................... 5-10
Chapter 6 CFM Configuration.................................................................... 6-1

6.1 CFM Overview ................................................................................................... 6-1
6.2 Configuring CFM ................................................................................................ 6-3
6.3 CFM Maintenance .............................................................................................. 6-5
6.4 CFM Configuration Instances .............................................................................. 6-6
6.4.1 CFM Fast Connectivity Detection .............................................................. 6-6
6.4.2 Cross-L2 VPN Connectivity Detection...................................................... 6-10
Chapter 7 BFD Configuration .................................................................... 7-1

7.1 BFD Overview.................................................................................................... 7-1
7.2 BFD Configuration.............................................................................................. 7-2
7.3 BFD Maintenance .............................................................................................. 7-6
7.4 BFD Configuration Instances............................................................................... 7-7
7.4.1 Configuring IS-IS BFD .............................................................................. 7-7
7.4.2 Configuring OSPF BFD ............................................................................ 7-9
7.4.3 Configuring BGP Single-Hop BFD ........................................................... 7-10
7.4.4 Configuring BGP Multi-Hop BFD ............................................................. 7-12
7.4.5 Configuring Static Route BFD ................................................................. 7-14
7.4.6 Configuring LDP BFD ............................................................................. 7-16
7.4.7 Configuring Static Single-Hop BFD.......................................................... 7-18
7.4.8 Configuring Static Multi-Hop BFD ............................................................ 7-20
7.4.9 Configuring BFD on RSVP Interface ........................................................ 7-23
7.4.10 Configuring RSVP LSP BFD ................................................................. 7-26
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
II

8.5.2 TE FRR Work Flow .................................................................................. 8-9
8.5.3 Configuring TE FRR ............................................................................... 8-14
Chapter 9 Graceful Restart Configuration ............................................... 9-1

9.1 IP Graceful Restart Configuration ........................................................................ 9-1
9.2 LDP Graceful Restart Configuration..................................................................... 9-3
Chapter 10 Master/Slave Main Control Handover ................................. 10-1

10.1 Master/Slave Plane Handover Overview .......................................................... 10-1
10.2 Configuring Master/Slave Main-control Handover ............................................. 10-2
10.3 Maintaining Master/Slave Main-control Handover ............................................. 10-2
10.4 Master/Slave Main-control Handover Configuration Example............................. 10-6
Chapter 11 Load Sharing Configuration................................................. 11-1

11.1 Load Sharing Overview ....................................................................................11-1
11.2 Configuring the Load Sharing ...........................................................................11-1
11.3 Configuring Multicast Load Sharing...................................................................11-2
11.4 Configuring MPLS VPN Load Sharing ...............................................................11-2
Figures............................................................................................................. I
Glossary ........................................................................................................ III
III

IV

About This Manual
Purpose
This manual describes the principle, configuration commands, maintenance commands
and configuration examples about the reliability function of the ZXR10 M6000.
Intended Audience
This manual is intended for:
l Network planning engineers
l Commissioning engineers
l On-duty personnel
What Is in This Manual

This manual contains the following chapters:
Chapter Summary
1, Reliability Overview Describes the meaning and requirements of the reliability, and the
relationship of various functions related to the reliability.
2, Service Availability Describes the principle, configuration commands, maintenance

Manager Configuration commands, and configuration examples of the SAMGR.
3, VRRP Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the VRRP.
4, Ping Detect Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the ping detect.
5, EFM Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the EFM.
6, CFM Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the CFM.
7, BFD Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the BFD.
8, FRR Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the FRR.
9, Graceful Restart Describes the principle, configuration commands, maintenance

Configuration commands, and configuration examples of the GR.

Chapter Summary
10, Master/Slave Main Control Describes the principle, configuration commands, maintenance
Handover commands, and configuration examples of the master/slave
main-control handover.
11, Load Sharing Describes the principle, configuration commands, maintenance

Configuration commands, and configuration examples of the load sharing.
Conventions
This manual uses the following typographical conventions:
Typeface Meaning
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

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 Device reliability
l Link reliability
l 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 Transport layer and physical layer: Automatic Protection Switching (APS).

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

The protection switching technologies includes the following types:
1-1

ZXR10 M6000 Configuration Guide (Reliability)
l End-to-end protection: APS 1:1 linear protection, APS 1+1 linear protection and hot
standby.
l Local protection: FRR, including IP FRR, LDP FRR, TE FRR, and PW FRR.
1-2

Chapter 2
Service Availability Manager
Configuration
Table of Contents
SAMGR Overview ......................................................................................................2-1
SAMGR Configuration ................................................................................................2-4
Maintaining SAMGR...................................................................................................2-6
SAMGR Configuration Instances ................................................................................2-9
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 Track object management
l Track group management
l Operation, Administration and Maintenance (OAM) binding management
l 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 trackname for the track object.
The trackname 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.
2-1

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.
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

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 PE–1,

1. The AC EOAM of PE–1 detects the AC fault and informs the SAMGR.
2. The SAMGR of PE–1 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 PE–3 receives the BFD/MPLS OAM/LDP fault, if there is a standby PW
on the remote PE, PE–3 switches the traffic. Otherwise, PE–3 performs OAM
mapping/binding to map the corresponding AC and advertises the fault to CE–2.
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

2.2 SAMGR Configuration

Configuring a Track Object
To configure a track object on the ZXR10 M6000, perform the following commands:
Step Command Function
1 ZXR10(config)#samgr Enters SAMGR configuration mode.
2 ZXR10(config-samgr)#track <name> efm interface Configures a track object with detection type
<interface-name> "efm".
3 ZXR10(config-samgr)#track <name> cfm md Configures a track object with detection type

<1-65535> ma <1-65535> local-mep <1-8191> "cfm".
remote-mep <1-8191>
4 ZXR10(config-samgr)#track <name> ping-detect Configures a track object with detection type

group <1-10> "ping-detect". The range of the Ping-detection
group is 1-10.
5 ZXR10(config-samgr)#track <name> sqa instance Configures a track object with detection type
<1-150> "sqa". The range of the SQA example is : 1-150.
6 ZXR10(config-samgr)#track <name> mpls-oam Configures a track object with detection type

tunnel-id <1-4000> ingress-id <ingress-vlaue> "mpls-oam". The range of the mpls-oam tunnel
egress-id <egress-value> is 1-4000.
7 ZXR10(config-samgr)#track <name> link-bfd { ipv4 Configures a track object with detection type
<local-ipv4-address>< remote-ipv4-address >| ipv6 < "link-bfd".
local-ipv6-address >< remote-ipv6-address >} interface
<interface-name>[vrf <vrf-name>]
8 ZXR10(config-samgr)#track <name> peer-bfd { ipv4 Configures a track object with detection type
<local-ipv4-address><remote-ipv4-address>| ipv6 < "peer-bfd".
local-ipv6-address><remote-ipv6-address>}[vrf <vrf-name>]
9 ZXR10(config-samgr)#track <name> ldp-bfd Configures a track object with detection type

fec-address < fec-address > mask-length <1-32> "ldp-bfd". interval <10-990> indicates the
interval <10-990> min-rx <10-990> multiplier <3-50> minimum interval for sending BFD packets, and
min-rx <10-990> indicates the minimum interval
for receiving BFD packets.
10 ZXR10(config-samgr)#track <name> rsvp-bfd Configures a track object with detection type

tunnel-id <1-4000> interval <10-990> min-rx <10-990> "rsvp-bfd".
multiplier <3-50>
2-4

11 ZXR10(config-samgr)#track <name> pw-bfd vcid Configures a track object with detection type
<1-4294967295> peerid <peer-id>{aal1 | aal2 | atm-aal5 "pw-bfd".
| atm-cell | atm-vcc | atm-vpc | cem | ceop | cesopsn-basic
| cesopsn-cas | hdlc | e1 | e3 | ehter | ether-vlan |
fr-dlci-martini | fr-dlci | fr-port | ip | ppp | t1 | t3}[interval
<10-990> min_rx <10-990> multiplier <3-50>]
12 ZXR10(config-samgr)#track <name> pw vcid Configures a track object with detection type

<1-4294967295> peerid <peer-id>{aal1|aal2|atm-aa "pw".
l5|atm-cell|atm-vcc|atm-vpc|cem|ceop| cesopsn-basic
| cesopsn-cas | dhlc | e1 |e3| ether | ether-vlan |
fr-dhci-martini | fr-dlci | fr-port | ip | ppp | t1 |t3}
13 ZXR10(config-samgr)#track <name> vrrp interface Configures a track object with detection type
<interface-name> vrid <1-255> "vrrp".
14 ZXR10(config-samgr)#track <name> l2-bfd session Configures a track object with detection type
<session-name> “l2-bfd”. <session-name> indicates the l2-bfd
name (Length: 1-32 characters)
Configuring a Track Group

To configure a track group on the ZXR10 M6000, perform the following steps:
2 ZXR10(config-samgr)#track-group Configures a track group and enters track group configuration

<group-name> mode.
3 ZXR10(config-samgr-track-group)#tr Adds a track object to the track group.

ack <track-name>
4 ZXR10(config-samgr-track-group)#inac Configures the policy for a track group. inactive-number

tive-number <1-10> indicates the number of invalid track objects resulting in
invalidity of the track group.
Configuring Binding Relation

To configure the binding relationship on the ZXR10 M6000, perform the following steps:
2 ZXR10(config-samgr)#sa-bind track <name> to {track | Configures the binding relationship

track-group}<name> between track objects or between
track groups.
Parameter descriptions in Step 2 are as follows:
2-5

Parameter Description
track<name> Name of the passive track object, that is, the name of the track object
that receives state transmission.
{track | track-group}<name> Name of an active track object or track group, that is, the name of
the track object or track group that starts state transmission.
2.3 Maintaining SAMGR

To maintain SAMGR on the ZXR10 M6000 , run the following commands:
Command Function
ZXR10#show samgr brief Displays the brief information related to a track object.
ZXR10#show samgr track [<trackname>[verbose]] Displays the detailed information of a track object, for
example, the state change information.
ZXR10#show samgr track-group [<trackname>[verbose]] Displays the detailed information of a track group, for
example, the state change information.
The following is sample output from the show samgr brief command:
ZXR10#show samgr brief
The total of track at this Router is 7
======================================================
Track-name Detect-type App-num State
vrrp2 vrrp 0 up
oam1 mpls-oam 1 up
ping1 ping-detect 0 L-down
vrrp1 vrrp 0 up
efm1 efm 1 T-down
ping2 ping-detect 0 up
vrrp2 vrrp 0 up
Parameter descriptions are as follows:
Command Output Description
Track-name Name of a configured track object.
Detect-type Detection type of a track object.
App-num Number of times that the track object is used.
State State of the track object.
The following is sample output from the show samgr track command:
ZXR10#show samgr track
Track name is xx
2-6

Detect type : peer-bfd

Track parameter
Local IP: 1.1.1.1 Remote IP: 1.1.1.3 Vrf name: zte
App number : 0
Active track : none
Passive track: none
Oam-mapping : no
Track state : unknow
State change : 0 state changes, last state change 00-00-00 00:00:00
Track name is bfd1

Detect type : link-bfd
Track parameter
Local IP: 1.1.1.1 Remote IP: 1.1.1.2 Interface: fei-0/1/0/1
App number : 0
Active track : none
Passive track: none
Oam-mapping : no
Track state : unknow
Track name is tcp

Detect type : sqa
Track parameter
Instance number: 4
App number : 0
Active track : none
Passive track: none
Oam-mapping : no
Track state : local down
Track name is oam1

Detect type : mpls-oam
Track parameter
Tunnel Id: 1 Ingress Id: 1.2.3.4
App number : 1
Active track : none
Passive track: none
Oam-mapping : no
Track state : up
ZXR10(config)#show samgr track sqa verbose

Track name is sqa
2-7

State change record:

old state new state change time
1 unknown local down 2010-07-19 02:57:28
2 local down up 2010-07-19 03:05:16
3 up local down 2010-07-19 03:06:24
4 local down up 2010-07-19 03:08:00
5 up local down 2010-07-19 03:08:13
Track name Name of a track object.
Detect type Detection type of track object.
Track parameter Parameters of a track object.
App number Number of times that the track object is used.
Active track Whether to act as a passive track to receive state information from the active track.
Passive track Whether to act as an active track to send the state information to the passive track.
Oam-mapping Whether the track has the OAM mapping ID.
Track state The state of the track object.
State change The state change information of the track object.
old state The original state of the track object before the state is changed.
new state The current state of the track object after the state is changed.
change time The state change time of the track object.
The following is sample output from the show samgr track-group command:
ZXR10#show samgr track-group
Track-group name: aaa
Set inactive number: all
App number: 0
Track-group state: up
Track-group member: 0
-------------------------------
Track-group name: group1
Set inactive number: 1
App number: 0
Track-group state: local down
Track-group member: 3
Track name: ping3 State: up
Track name: ping2 State: up
Track name: ping1 State: local down
ZXR10(config)#show samgr track-group 1 verbose
2-8

Track name is 1
State change record:
old state new state change time
1 up local down 2010-07-19 03:14:43
2 local down up 2010-07-19 03:14:50
3 up local down 2010-07-19 03:14:56
4 local down up 2010-07-19 03:15:01
Track-group name Name of a track group.
Set inactive number Policy for a track group.
App number Number of times that the track object is used.
Track-group member Members in a track group .
Track name Name of track objects that are bound to the track group.
State State of the track object.
old state The original state of the track group before the state is changed.
new state The current state of the track group after the state is changed.
change time The state change time of the track group.
2.4 SAMGR Configuration Instances

2.4.1 Linkage between EFM and VRRP
Configuration Description
The VRRP protocol is used between R2 and R3. The VRRP virtual address is the interface
address 10.0.0.1. The R2 operates as a master router, see Figure 2-3.
Figure 2-3 Linkage between EFM and VRRP
2-9

Configuration Flow
1. Configure the EFM connection for the directly-connected interfaces between S1 and
R2.
2. Configure an EFM track object for the directly-connected interface of R2 in SAMGR
configuration mode.
3. Configure the same VRRP group number and virtual address for R2 and R3. To set
R2 as a master router, bind the VRRP of 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 Command
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)#ip address 10.0.0.1 255.255.0.0
R2(config-if)#exit
R2(config-if)#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)#set ethernet-oam function enable
R2(config-efm-if)#exit
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)#vrrp 1 ipv4 10.0.0.1
R2(config-vrrp-if)#vrrp 1 out-interface gei-0/3/0/2
R2(config-vrrp-if)#vrrp 1 track object efm link-type
R2(config-vrrp-if)#exit
2-10

R3(config-if)#exit
R3(config-if)#exit
R3(config)#vrrp
R3(config-vrrp-if)#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 Master addr VRouter addr
gei-0/2/0/1 1 255 1000 A P Master 10.0.0.1 10.0.0.1
R2#show samgr brief

The total of track at this Router is 1.
============================================================================
efm efm 1 up

gei-0/5/0/1 1 100 1000 P Backup 10.0.0.1 10.0.0.1
When the EFM function on S1 is disabled , the status of 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 local down status.

S1(config-efm)#set ethernet-oam function disable
S1(config-efm)#exit

gei-0/2/0/1 1 255 1000 A P Init 0.0.0.0 10.0.0.1
R2#show samgr brief

2-11

============================================================================
efm efm 1 L-down

gei-0/5/0/1 1 100 1000 P Master 10.0.0.2 10.0.0.1
When the EFM function on S1 is enabled, the status of the VRRP group on 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

gei-0/2/0/1 1 100 1000 P Master 10.0.0.1 10.0.0.1
R2#show samgr brief

============================================================================
efm efm 1 up

gei-0/5/0/1 1 100 1000 P Backup 10.0.0.1 10.0.0.1
2.4.2 Linkage between CFM and VRRP

address 10.0.0.1 of R2 that operates as a master router. For the network structure, see
Figure 2-4.
2-12

Figure 2-4 Link between CFM and VRRP
Configuration Flow
1. Configure the CFM continuous detection for the directly-connected interfaces between
S1 and R2.
2. Configure a CFM track object for the directly-connected interface of R2 in SAMGR
configuration mode.
3. Configure the same VRRP group number and virtual address for R2 and R3. To set
R2 as a master router, bind VRRP of R2 to the track object with the detection type
"CFM".
4. When the CFM function on S1 is disabled, the status of the VRRP group onR2 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 status of the VRRP group on 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

R2(config-if)#exit
R2(config-if)#exit
2-13

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

R3(config-if)#exit
R3(config-if)#exit
R3(config)#vrrp
R3(config-vrrp-if)#end
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 shows that the
CFM track object is in up status.
2-14


gei-0/2/0/1 1 255 1000 A P Master 10.0.0.1 10.0.0.1
R2(config)#show samgr brief

============================================================================
cfm cfm 1 up

gei-0/5/0/1 1 100 1000 P Backup 10.0.0.1 10.0.0.1
When the CFM function on S1 is disabled, the status of the VRRP group on 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

gei-0/2/0/1 1 255 1000 A P Init 0.0.0.0 10.0.0.1
R2#show samgr brief
============================================================================
cfm cfm 1 L-down

gei-0/5/0/1 1 100 1000 P Master 10.0.0.2 10.0.0.1
When the CFM function on S1 is enabled, the status of the VRRP group on 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

gei-0/2/0/1 1 255 1000 A P Master 10.0.0.1 10.0.0.1
R2#show samgr brief
2-15


============================================================================
cfm cfm 1 up

gei-0/5/0/1 1 100 1000 P Backup 10.0.0.2 10.0.0.1
2-16

Chapter 3
VRRP Configuration
Table of Contents
VRRP Overview .........................................................................................................3-1
VRRP Network Application .........................................................................................3-4
Configuring VRRP ......................................................................................................3-8
Maintaining VRRP ....................................................................................................3-11
VRRP Configuration Instances .................................................................................3-13
3.1 VRRP Overview

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.
3-1

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.
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
priorities are the same, the master IP addresses on interfaces are compared. The
router with the greater master IP address on an interface becomes 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.
3-2

Chapter 3 VRRP Configuration
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.
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.
l 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.
l 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.
l 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

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

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 Each backup group contains a Master device and several Backup devices.
l The Master devices in the backup groups can be different.
l 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 Router A operates as the master router in Group 1 and operates as a backup
router in Group 2.
l Router B operates as the master router in Group 2 and operates as a backup
router in Group 1.
l 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.
3-5

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

Figure 3-7 VRRP and EOAM State Transfer
l 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

Figure 3-9 VRRP and EOAM + Peer BFD State Transfer
l 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 VRRP

To configure VRRP on the ZXR10 M6000, perform the following steps:
1 ZXR10(config)#vrrp Enters VRRP configuration mode.
2 ZXR10(config-vrrp)#interface <interface-name> Enters VRRP interface configuration mode.
3-8

3 ZXR10(config-vrrp-if)#vrrp <vrid>ipv4<ip-address Configures VRRP virtual IPv4 address in VRRP

>[secondary] interface configuration mode.<vrid> indicates the
virtual router ID.
Range: 1-255.
4 ZXR10(config-vrrp-if)#vrrp <vrid> priority <level> Configures VRRP priority in VRRP interface

configuration mode.
Range: 1-254, default: 100.
5 ZXR10(config-vrrp-if)#vrrp <vrid> preempt [delay Configures VRRP group pre-emption in VRRP

<seconds>] interface configuration mode.<seconds> indicates
pre-emption delay.
Range: 0-3600 seconds, default: 0.
6 ZXR10(config-vrrp-if)#vrrp <vrid> timers advertise Configures the interval to send VRRP

{<1-40>|[msec <50-40000>]} advertisements in VRRP interface configuration
mode. The default value of interval is 1 second.
Unit for <1-40> is second, and unit for <50-40000>
is millisecond.
The parameter msec is optional and it changes
the unit of the interval to millisecond from second.
7 ZXR10(config-vrrp-if)#vrrp <vrid> timers learn Configures whether sending interval is learnt

from the notification packets. The default
configuration is not learning.
8 ZXR10(config-vrrp-if)#vrrp <vrid> track interface Configures a VRRP track interface in VRRP

<interface-name>[priority-decrement <1-254>| interface configuration mode. When the priority
rapid-down] decrement is not specified, the default priority
is decreased by 10. Any link state is not traced
by default.
9 ZXR10(config-vrrp-if)#vrrp <vrid> out-interface Configures VRRP heartbeat in VRRP interface

<interface-name> configuration mode, that is to configure a
out-interface for VRRP packets.
10 ZXR10(config-vrrp-if)#vrrp <vrid> text-authenticat Configures a VRRP authentication string in

ion <string> VRRP interface configuration mode. The string
consists of 1-8 characters. (This configuration is
only available for version 2 of the VRRP.)
11 ZXR10(config-vrrp-if)#vrrp <vrid> track { Configures VRRP detection group, detection

group | object}<string>{ link-type | peer-type | object, or policy type in VRRP interface
priority-decrement <1-254>} configuration mode.
12 ZXR10(config-vrrp-if)#vrrp <vrid> version {2|3} Configures VRRP version in VRRP interface

configuration mode.
v2 supports IPv4 configuration, and v3 supports
IPv4 and IPv6 configuration.
3-9

13 ZXR10(config-vrrp-if)#vrrp <vrid> accept Enables the accept function in VRRP interface

configuration mode. This function is enabled by
default.
14 ZXR10(config-vrrp-if)#vrrp <vrid> check-ttl Enables tje check-ttl function in VRRP interface

configuration mode, default: enabled.
15 ZXR10(config-vrrp-if)#vrrp <vrid> admin-group { Configures VRRP administration group function

owner | interface <interface-name> vrid <1-255>} in VRRP interface configuration mode.
16 ZXR10(config-vrrp-if)#vrrp <vrid> send-mode {all | Configures the mode to send packets on an

rotation} egress interface (heartbeat line) of VRRP.
l All: All heartbeat lines send packages at the
same time.
l Rotation: The heartbeat line sends
packages in polling mode.
<vrid> ID of the virtual router.

Range: 1-255.
ipv4 VRRP IPv4 virtual address.
<ip-address> IP address of the virtual router.
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 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.
<vrid> ID of the virtual router. Range: 1-255.
group Track group.
object Track object.
string Name of a track group or track object.
3-10

link-type Link-type.
peer-type Peer-type.
priority-decrement <1-254> Priority decrement.
<vrid> ID of the virtual router. Range: 1-255.
owner The current group is the administration group that receives packets and
manages link states.
<interface-name> Interface name of the administration group.
vrid <1-255> Virtual router ID of the administration group.

Range: 1-255.
3.4 Maintaining VRRP

To maintain VRRP on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#show vrrp ipv4 brief Displays the brief information of all IPv4 VRRP
groups on a router.
ZXR10#show vrrp ipv4 brief interface <interface-name> Displays the brief information of all IPv4 VRRP
groups on a specific interface.
ZXR10#show vrrp interface <interface-name>[vrid <1-255>] Displays the detailed information of all VRRP
groups or a specified group on a specified
interface.
The following is sample output from the show vrrp ipv4 brief command:
ZXR10#show vrrp ipv4 brief

fei-0/1/0/2 255 254 999 P Master 192.168.1.10 15.15.15.1
fei-0/1/0/1 100 200 10000 P Master 35.35.35.1 1.1.1.1
fei-0/1/0/1 120 255 157 A P L Master 35.35.35.1 35.35.35.1
Interface Interface on which VRRP is used.
vrID ID of the VRRP group. Range: 1-255.
3-11

Pri VRRP priority.
Time The local notification time (millisecond).
A Whether it is a owner of the virtual address, which means whether the

VRRP virtual IP address is the same as the IP address of the interface.
P Whether the preemption mode is used.
L Whether the learning mode is used.
State VRRP state.
Master addr Interface address of the master router in a virtual router group.
VRouter addr IP address of a virtual router.
The following is sample output from the show vrrp ipv4 brief interface command:
ZXR10#show vrrp ipv4 brief interface fei-0/1/0/1
The total of vrrp group on this Interface is 2.
======================================================================
fei-0/1/0/1 100 200 10000 P Master 35.35.35.1 1.1.1.1
fei-0/1/0/1 120 255 157 A P L Master 35.35.35.1 35.35.35.1
The following is sample output from the show vrrp interface command:
ZXR10(config)#show vrrp interface smartgroup4
smartgroup4 - vrID 5
Vrrp configure info:
IP version 4, VRRP version 3
Virtual IP address is 0.0.0.0
Virtual MAC address is 0000.5e00.0105
Advertise time is 1.000 sec
Configured priority is 100
Preemption enable, delay 0 secs
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:
State is Init
0 state changes, last state change 00:00:00
Current priority is 100
Master router is unknown
3-12

Master router address is 0.0.0.0

Master router priority is 0
Master Advertisement interval is 0.000 sec
Master Down interval is 3.609 sec, no learn
Decrement-Priority The decreased priority after the tracked interface is shut down.
Tracked interface The tracked interface.
Track name The name of tracked group or object.
Track type The track type, including detection group and detection object.
Detect type The link detection type, which is configured in SAMGR configuration.
Master router is local This router is the master router is the virtual router group.
3.5 VRRP Configuration Instances

3.5.1 Basic VRRP Configuration Example
The VRRP protocol is used between the R1 and the R2. The interface address of the R1
is set to 10.0.0.1 and that of the R2 is set to 10.0.0.2. The VRRP virtual address is the
interface address 10.0.0.1 on the R1. In this case, the R1 is the IP address owner and has
the highest priority 255. The R1 operates as the master router. The VRRP virtual address
can also be set to another address. When the R1 is configured with the highest priority,
the R1 is the master router. For the network structure, see Figure 3-11.
Figure 3-11 Basic VRRP Configuration (IPv4)
3-13

Configuration Flow
1. Enter the interfaces on which VRRP will be configured and configure an IP address
for it.
2. Enter VRRP configuration mode from global configuration mode and then enter the
interface on which the VRRP is to be configured.
3. Configure the same VRRP group ID and virtual address for the R1 and the R2. To
make the R1 the master router or specify a higher priority for the R1, configure related
commands on the R1 first. If the priorities (the default priority is 100) of two routers
are the same, the router becomes the master router in the group, on which VRRP is
enabled and messages are advertised first.
Run the following commands on the R1:
R1(config)#interface fei-0/1/0/1
R1(config)#vrrp
R1(config-vrrp)#interface fei-0/1/0/1

R2(config)#vrrp
View the VRRP information and configuration result on the R1, which is displayed as
follows:
fei-0/1/0/1 1 255 1000 A P 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#sho vrrp interface fei-0/1/0/1 vrid 1

fei-0/1/0/1 - vrID 1
Vrrp configure info: /*VRRP configuration information*/
3-14


Check ttl enable
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 22:50:03 6 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, the largest priority of the Owner is 255*/
Master router is local
R1#
3.5.2 Symmetrical VRRP Configuration Example

Symmetrical VRRP means load sharing is supported. In this example, 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. The R1 and R2 provide backups
for each other. When both R1 and R2 become invalid, the communications between the
hosts and external network will be interrupted. For the network structure, see Figure 3-12.
3-15

Figure 3-12 Symmetrical VRRP Configuration (IPv4)
Configuration Flow
for it.
3. Configure VRRP Group 1 and corresponding virtual address on R1, and 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. After 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. The R1 and R2 provide backups for each other.
R1(config)#vrrp
R2(config)#vrrp
3-16

Check the VRRP information and configuration result on R1, as shown below.
fei-0/1/0/1 1 255 1000 A P Master 10.0.0.1 10.0.0.1
fei-0/1/0/1 2 100 1000 P Backup 10.0.0.2 10.0.0.2
L: whether to learn the interval for sending VRRP messages from the master.*/
R1#show vrrp interface fei-0/1/0/1 vrid 1

fei-0/1/0/1 - vrID 1
Check ttl enable
Admin-group is None
Vrrp run info: /*Operation information of VRRP on current interface*/
State is Master /*VRRP operation state*/
1 state changes, last state change 22:50:03 6 day(s)
/*Number of state changes and the time for how long the system has been
operated until the last change. If there is no change, the value is 0.*/
/*current priority, the largest priority of the Owner is 255*/
R1#
3-17

3.5.3 VRRP Heartbeat Configuration Example

address 10.0.0.1 of R1. R1 operates as the master router. For the network structure, see
Figure 3-13.
Figure 3-13 VRRP Heartbeat Configuration (IPv4)
Configuration Flow
for it.
3. Configure the same VRRP group ID and virtual address for R1 and R2. To make R1 as
the master router, specify a higher priority for R1, or set it to be the IP address owner
(The interface address of R1 is set as the virtual address and R1 has the highest
priority 255).
4. In VRRP interface configuration mode of R1 and R2, configure egress interfaces for
packets in the VRRP group to ensure that packets can be sent and received through
these two egresses.
R1(config)#vrrp
R1(config-vrrp-if)#vrrp 1 out-interface fei-0/1/0/2
3-18

R2(config)#vrrp
R2(config-vrrp-if)#vrrp 1 out-interface fei-0/1/0/2
Check the VRRP information and configuration results on R1, which are displayed as
follows:

fei-0/1/0/1 1 255 1000 A P Master 10.0.0.1 10.0.0.1
R1#show vrrp interface fei-0/1/0/1 vrid 1

fei-0/1/0/1 - vrID 1
Check ttl enable
Out-interface(heartbeat line) is fei-0/1/0/2
Admin-group is None
Vrrp run info:
/*Running information of VRRP on current interface*/
State is Master
/*VRRP running state*/
/*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, the largest priority of the Owner is 255*/
3-19


3.5.4 VRRP BFD Configuration Example

The VRRP protocol is used between Router A and Router B. The VRRP virtual IP address
is 10.0.0.3. For the network structure, see Figure 3-14.
Figure 3-14 VRRP Track Configuration (IPv4)
Configuration Flow
1. Enter the interface on which VRRP will be configured and configure an IP address for
it.
2. Enter VRRP configuration mode from global configuration mode, and then enter the
3. Configure the same VRRP group ID and virtual IP addre for Router A and Router B. To
set Router A as the master router, specify a higher priority for Router A, or set it to be
the IP address owner (The interface address of Router A is set as the virtual address
and Router A has the highest priority 255).
4. Enter SAMGR configuration mode of Router A and Router B to configure a
detection object respectively. Configure the Ethernet Operation, Administration and
Maintenance (EOAM) object for Router A and Router B, and then configure the
Bidirectional Forwarding Detection (BFD) object.
5. Enter VRRP interface configuration mode of 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:
3-20

RA(config)#interface fei-0/1/0/1
RA(config-if)#ip address 10.0.0.1 255.255.0.0
RA(config-if)#exit
RA(config)#vrrp
RA(config-vrrp)#interface fei-0/1/0/1
RA(config-vrrp-if)#vrrp 1 ipv4 10.0.0.3
RA(config-vrrp-if)#vrrp 1 track object zte1 link-type
RA(config-vrrp-if)#vrrp 1 track object zte2 peer-type
The tracked object named zte1 and zte2 should be configured in the SAMGR module in
advance. For the detailed configuration, refer to the “SAMGR Configuration” chapter.
Run the following commands on Router B:
RB(config)#interface fei-0/1/0/1
RB(config-if)#ip address 10.0.0.2 255.255.0.0
RB(config-if)#exit
RB(config)#vrrp
RB(config-vrrp)#interface fei-0/1/0/1
RB(config-vrrp-if)#vrrp 1 ipv4 10.0.0.3
RB(config-vrrp-if)#vrrp 1 track object zte1 link-type
RB(config-vrrp-if)#vrrp 1 track object zte2 peer-type
The tracked object named zte1 and zte2 should be configured in the SAMGR module in
advance. For the detailed configuration, refer to the “SAMGR Configuration” chapter.
Check the VRRP track information and configuration results on Router A, which is
displayed as follows:
RA#show vrrp ipv4 brief
fei-0/1/0/1 1 100 1000 A P Master 10.0.0.1 10.0.0.3
RA#show vrrp interface fei-0/1/0/1

fei-0/1/0/1 - vrID 1
Vrrp configure info:
3-21

Check ttl enable
Track name: zte2 Track type: object Detect type: peer-bfd
Policy type: peer
Track state: unknown
Track name: zte1 Track type: object Detect type: cfm
Policy type: link
Track state: unknown
Admin-group is None
Vrrp run info:
State is Master
3-22

Chapter 4
Ping Detect Configuration
Table of Contents
Ping Detect Overview .................................................................................................4-1
Configuring Ping Detect..............................................................................................4-2
Maintaining Ping Detect..............................................................................................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

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 a global Ping detection group, including the address and the nexthop for the
group to be detected.
You can define some detection policies flexibly, such as the detection period, maximum
retry times, and time-out time.
You can configure the "and” or "or" relationship among multiple detection objects of a
detection group.
l If the relationship among multiple objects to be detected is "and", and one IP
address cannot be pinged successfully, it means that the detection group is
unreachable, and it does not detect other addresses any more.
l If the relationship among multiple objects to be detected is " or", and one
IP address can be pinged successfully, it means that the detection group is
reachable, and it does not detect other addresses any more.
2. 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.
Note:
l You can check the Ping Detect result by running the show samgr brief command.
l To use the Ping Detect function, the ICMP service of the firewall corresponding to the
objects to be detected should be enabled.
4.2 Configuring Ping Detect

To configure the Ping Detect function on the ZXR10 M6000, perform the following steps:
1 ZXR10(config)#detect-group <group-number> Configures a detection group. The range of the

group number is 1-10.
4-2

Chapter 4 Ping Detect Configuration
2 ZXR10(config-detect)#option {And | Or} Configures the logical relationship "and" or "or" for
objects to be detected.
And: It indicates that this group is connected when
all items in the group are connected.
Or: It indicates that this group is connected when
any item in the group is connected.
3 ZXR10(config-detect)#detect-list <list-number>[vrf Configures detection items for the detection group,

<vrf-name>]<des-ip-address>[<next-ip-address>] and the destination address for a detection item,
and specifies the next hop address.
4 ZXR10(config-detect)#retry-times <retry-times> Configures the maximum number of times that the

detection group re-transmits detection results to the
Ping module.
5 ZXR10(config-detect)#loop-time <seconds> Configures the loop detection interval for the

detection results. Range: 2-86400s, default: 15s.
6 ZXR10(config-detect)#time-out <seconds> Configures the time-out time that the detection

group transmits detection results to the PING
module.
Range: 1-20s, default: 2s.
7 ZXR10(config-samgr)#track <name> ping-detect Enables the Ping Detect function in SAMGR

group <group-number> configuration mode.
4.3 Maintaining Ping Detect

To maintain the ping detect function on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#show running-config ping-detect Displays the configuration of the Ping Detect function.
The default value is not displayed.
ZXR10#show running-config ping-detect all Displays the configuration of the Ping Detect function.
The default value is displayed.
ZXR10#show samgr track Displays the information of the Samgr Track Ping Detect
function.
ZXR10#show samgr brief Displays the Ping Detect results.
The following is sample output from the show samgr track command:
ZXR10#show samgr track

Track name is test
Detect type : ping-detect
4-3

Track parameter
Group: 1
App-sub count : 0
Dyn-creat count: 0
Active track : none
Passive track : none
Track state : up
Detect type Displays the track type.
Track parameter Displays track parameters.
Track state Displays the track state.
4.4 Ping Detect Configuration Instances

4.4.1 Basic Ping Detect Configuration Examples
There are three interfaces between R1 and R2. A detection group between R1 and R2
must be configured. For the network structure, see Figure 4-2.
Figure 4-2 Network Structure of Basic Ping Detect Configuration Example
Addresses of the interfaces on R1 and R2 are as follows:
Interface IP Address Mask
fei-0/1/0/5 100.0.0.15 255.255.255.0
R1 fei-0/1/0/6 101.0.0.15 255.255.255.0
fei-0/1/0/7 102.0.0.15 255.255.255.0
fei-0/1/0/5 100.0.0.20 255.255.255.0
R2 fei-0/1/0/6 101.0.0.20 255.255.255.0
fei-0/1/0/7 102.0.0.20 255.255.255.0
4-4

Configuration Flow
1. Configure a detection group.
2. Configure detection items for the detection group on R1.
3. Set parameters for the detection group as required.
4. Enable the Ping Detect function in Samgr configuration mode, and check the result by
running the show command.
5. Set the logical relationship among objects to be detected to And, add a detection item
that cannot be pinged successfully, and then check the detection result. Set the logical
relationship among objects to be detected to Or, and then check the detection result.
Run the following commands to configure R1:
ZXR10(config)#detect-group 1
ZXR10(config-detect)#detect-list 1 100.0.0.20
ZXR10(config-detect)#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
======================================================================
test ping-detect 0 up
Set the logical relationship among objects to be detected to And, and then add a detection
item that cannot be pinged successfully.
ZXR10(config-detect)#option And
/*Set the logical relationship for the detect object to "And"*/
======================================================================
test ping-detect 0 L-down
Set the logical relationship among objects to be detected to Or, and then check the detect
result:
ZXR10(config-detect)#option Or
4-5

/*Set the logical relationship for the detect object to "Or"*/

======================================================================
test ping-detect 0 up
4.4.2 Cooperation Configuration Example Between a Directly

Connected Route and the Ping Detect
This section describes the basic functions of the cooperation between a directly connected
route and the Ping Detect, see Figure 4-3.
Figure 4-3 Cooperation Configuration Between a Directly-Connected Route and the

Ping Detect
Configuration Flow
1. Set the IP addresses for R1, R2 and R4, enable the OSPF protocol, and create OSPF
neighbor relations between routers.
2. Configure the ping detect group on R2, configure the tracing object(s) of samgr, and
bind the tracing object(s) on the interface gei-0/7/1/8.
Configuration Commands
4-6

R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#router ospf 19
R1(config-ospfv2)#router-id 22.22.22.22
R1(config-ospfv2)#network 71.88.1.0 0.0.0.255 area 0
R1(config-ospfv2)#exit

R2(config-if)#exit
R2(config-if)#exit
R2(config)#interface gei-0/2/1/7.1
R2(config-subif)#ip address 41.52.17.2 255.255.255.0
R2(config-subif)#exit
R2(config)#vlan
R2(config-vlan)#interface gei-0/2/1/7.1
R2(config-subvlan-if)#encapsulation-dot1q 1
R2(config-subvlan-if)#exit
R2(config)#detect-group 10
R2(config-detect)#option or
R2(config-detect)#retry-times 3
R2(config-detect)#loop-time 12
R2(config-detect)#time-out 3
R2(config-detect)#detect-list 9 41.52.17.3 41.52.17.2
R2(config-detect)#detect-list 3 19.19.19.1
R2(config-detect)#exit
4-7

R2(config)#samgr
R2(config-samgr)#track abc ping-detect group 10
R2(config-if)#track abc
R2(config-if)#exit

R4(config-if)#exit
R4(config)#interface gei-0/0/0/8.1
R4(config-subif)#ip address 1.2.3.4 255.255.255.0
R4(config-subif)#ip address 41.52.17.3 255.255.255.0 secondary
R4(config-subif)#interface mac-address offset 23
R4(config-subif)#exit
R4(config)#vlan
R4(config-vlan)#interface gei-0/0/0/8.1
R4(config-subvlan-if)#encapsulation-dot1q 1
R4(config-subvlan-if)#exit
Query the status of the tracing object(s) on R2, and you can find that the status of the
tracing object is up. Run the show samgr brief command to check whether there is a
new IP address for a direct routing of the interface gei-0/7/1/8 added in the protocol table,
which is displayed as follows:
R2(config)#show samgr brief
abc ping-detect 1 up
R2#show ip protocol routing network 71.88.1.0

Protocol routes:
status codes: *valid, >best, i-internal, s-stale
Dest NextHop RoutePrf RouteMetric Protocol

*> 71.88.1.0/24 71.88.1.1 0 0 direct
4-8

* 71.88.1.0/24 71.88.1.0 110 1 ospf

*> 71.88.1.1/32 71.88.1.1 0 0 address
After disabling the gei-0/2/1/7.1 interfaces using the shutdown command, check whether
the tracing state is down on R2. The direct routes of the gei-0/7/1/8 interfaces will be
removed.
R2#show samgr brief
abc ping-detect 1 L-down
R2#show ip protocol routing network 71.88.1.0

IPv4 Routing Table:
status codes: *valid, >best
Dest Gw Interface Owner Pri Metric
4-9

This page intentionally left blank.
4-10

Chapter 5
EFM Configuration
Table of Contents
EFM Overview............................................................................................................5-1
Configuring EFM ........................................................................................................5-2
Maintaining EFM ........................................................................................................5-4
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, 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 supports the following EMF functions:

l Supporting automatic negotiation with other devices
l Supporting remote loopback statistics detection on the links
l Supporting detection of link error frames and symbols
l Supporting emergency event advertisement
l 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

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.
5.2 Configuring EFM

To configure EFM on the ZXR10 M6000, perform the following steps:
1 ZXR10(config)#efm Enters EFM configuration mode
2 ZXR10(config-efm)#set ethernet-oam function <state> Sets the switch to enable EFM

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

Identifier (OUI) field for the EFM
vendor. By default, it is set to ZTE.
4 ZXR10(config-efm)#set ethernet-oam remote-timeout <value> Configures the time-out time for the
EFM overall loopback control.
Range: 1-10, unit: second, default:
3.
5 ZXR10(config-efm)#interface <interface-name> Enters EFM interface configuration

mode.
5-2

Chapter 5 EFM Configuration
6 ZXR10(config-efm-if)#set ethernet-oam function <state> Enables the EFM function for a

specific interface.
7 ZXR10(config-efm-if)#set ethernet-oam link-monitor function Enables the link monitoring function

<state> for a specific interface.
8 ZXR10(config-efm-if)#set ethernet-oam link-monitor frame Configures the window value and

threshold <th-value> window <win-value> threshold value for the error frames
during the link monitoring.
9 ZXR10(config-efm-if)#set ethernet-oam link-monitor Configures the window value and

symbol-period threshold <th-value> window <win-value> threshold for the error symbols
during the link monitoring.
10 ZXR10(config-efm-if)#set ethernet-oam link-monitor frame-period Configures the window value and

threshold <th-value> window <win-value> threshold for error frames during the
link monitoring.
11 ZXR10(config-efm-if)#set ethernet-oam link-monitor frame-second Configures the window value and

threshold <th-value> window <win-value> threshold for the error frames per
second during the link monitoring.
12 ZXR10(config-efm-if)#set ethernet-oam link-timeout <timeout-value1>: Sets link time-out

{<timeout-value1>| fast {<timeout-value2>[period <period-value>]}} time. Range: 3-20 seconds, default:
5 seconds.
<timeout-value2>: Sets link
time-out time. Range: 3-200 (100
millisecond), default: 50 (100
millisecond).
<period-value>: Sets the period that
the link sends packets. Range: 1-10
(100 millisecond), default :10 (100
millisecond).
13 ZXR10(config-efm-if)#set ethernet-oam mode <mode> Configures EFM configuration mode,

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

loopback function manually.
<th-value> Threshold of error frames. Range: 1-65535, default: 1.
<win-value> Window value of error frame. Range: 1-60 seconds, default: 1 second.
5-3

<th-value> Threshold of error symbols. Range: 1-65535, default: 1.
<win-value> Window value of error symbol. Range: 1-65535 millions, default: 1 million.
<th-value> Threshold of error frame cycle. Range: 1-65535 millions, default: 1 million.
<win-value> Window value of error frame cycle. Range: 1-65535 millions, default: 1
million.
<th-value> Threshold of error frames per second. Range: 1-900 frames per second,
default: 1 frame per second.
<win-value> Window value of error frames per second. Range: 1-900 seconds, default:
1 second.
5.3 Maintaining EFM

To maintain EFM on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#debug ethernet-oam {interface < interface-name>| packet interface Sends or receives EFM packets. Run
<interface-name>{dual | in | out} type {all | information| lpbk-ctrl | notify | the no command to disable all enabled
org-spec | reqst-varb | respst-varb} mode {all-time | number <num-value>}} functions.
ZXR10#show ethernet-oam [<interface-name>{discovery | link-monitor Displays the global EFM configuration,

| statistics}] or the interface EFM configuration and
state.
Parameter descriptions of the debug command are as follows:
<interface-name> Interface name
dual Displays the information of sent and received packets.
in Displays the information of received packets.
out Displays the information of sent packets.
all Displays information of all types of EFM packets.
information Displays the information of EFM information packets.
5-4

lpbk-ctrl Displays the information of EFM loopback control packets.
notify Displays the information of EFM notification packets.
org-spec Displays the information of packets defined by vendors.
reqst-varb Displays the information of EFM variable-request packets.
respst-varb Displays the information of EFM variable-response packets.
all-time Always displays packet debugging information.
<num-value> Specifies the number of packets of which the information will be displayed.
<interface-name> Interface name.
discovery The parameter after the interface name used to display the related state
information of the EFM negotiation.
link-monitor The parameter after the interface name used to display the related
information of the EFM link monitoring.
statistics The parameter after the interface name used to display the related
information of the EFM packet statistics, including sent and received packet
statistics of the loopback.
The following is sample output from the show ethernet-oam command:

ZXR10#show ethernet-oam fei-0/1/0/1 discovery
PortId 2: Ethernet Oam enable
Local DTE
----------
Config:
Mode :active
Period Time :10*(100ms)
Link time out :50*(100ms)
Status:
Parse :forward
Multiplexer :forward
Stable :no
Discovery :undone
Loopback :off
PDU Revision :0
Unidirection :nonsupport
5-5

Remote DTE
-----------
Config:
Mode :passive
Link Monitor :nonsupport
Remote Loopback :nonsupport
Mib Retrieval :nonsupport
PDU max size :1518
Status:
Parse :forward
Stable :no
Mac Address :0000.0000.0000
PDU Revision :0
Mode EFM working mode.
Link time out Link time-out.
Parse Parser state.
Multiplexer Multiplexer state.
Stable Local and remote stable bit.
Discovery Identifier of discovery complete.
Loopback Identifier of loopback enabling.
PDU Revision Revision in the packet.
5.4 EFM Configuration Instances

5.4.1 EFM Connection Establishment
R1 and R2 are connected directly. The EFM on the directly-connected interfaces of R1
and R2 need to be configured. For the network structure, see Figure 5-2.
Figure 5-2 Network Architecture of EFM Connection Establishment
5-6

Configuration Flow
1. Configure the EFM function for the interface of R1 connecting to R2 directly, enable
the EFM and link-monitor switch for a specified interface, and then enable the EFM
function globally.
2. Configure the EFM function for the interface of R2 connecting to R1 directly, enable
the EFM and link-monitor switch for a specified interface, and then enable the EFM
function globally.
3. Run the show ethernet-oam discovery command on R1 and R2 to check the EFM con-
nection establishment.
4. Run the show ethernet-oam link-monitor command on R1 and R2 to check the count
of link errors between R1 and R2.
R1#configure terminal
R1(config)#efm
R1(config-efm-if)#set ethernet-oam link-monitor function enable
R1(config-efm)#set ethernet-oam oui R1
R1(config-efm)#exit

R2(config)#efm
R2(config-efm-if)# set ethernet-oam link-monitor function enable
R2(config-efm)#exit
1. Run the show ethernet-oam discovery command on R1 to check the link EFM
negotiation, which is displayed as follows:
R1(config-efm)#show ethernet-oam gei-0/0/1/1 discovery
Local DTE
----------
Config:
Mode :active
5-7


Status: /*local state*/

Parse :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 Revision :1 /*Local configuration is modified once.*/
Remote DTE
-----------
Config:
Mode :active
Link Monitor :support
Remote Loopback :support
PDU max size :1518
Status: /*remote state*/

Parse :forward /*forwarding mode*/
Multiplexer :forward /*forwarding mode*/
Stable :yes /*Remote link state is "stable".*/
Mac Address :0001.12ac.121a /*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 number of link
errors, which is displayed as follows:
R1(config-efm)#show ethernet-oam gei-0/0/1/1 link-monitor
Link Monitoring of Port: 32
Link Monitoring enable
Error Symbol Period Event:
Symbol Window :1(million symbols)
Error Symbol Threshold :1
Total Error Symbols :0
Local Total Error Events :0
Remote Total Error Events :0
Error Frame Event:
Period Window : 1(s)
Error Frame Threshold : 1
Total Error Frames : 0
Local Total Error Events : 0
Remote Total Error Events : 0
5-8

Error Frame Period Event:

Frame Window : 1(ten thousand frames)
Error Frame Seconds Event:
Error Seconds Window : 1(s)
Error Seconds Threshold : 1(s)
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, which is displayed as follows:
R2(config)#show ethernet-oam gei-0/0/0/1 discovery
Local DTE
----------
Config:
Mode :active
Status:
Parse :forward
Stable :yes
Discovery :done
Loopback :off
PDU Revision :0
Remote DTE
-----------
Config:
Mode :active
Link Monitor :support
Remote Loopback :support
PDU max size :1518
Status:
Parse :forward
5-9

Stable :yes
Mac Address : 0020.231d.0e0e

PDU Revision :1
4. Run the show ethernet-oam link-monitor command on R2 to check the number of link
errors, which is displayed as follows:
R2(config)#show ethernet-oam gei-0/0/0/1 link-monitor
Link Monitoring of Port: 66
Link Monitoring enable
Error Symbol Period Event:
Symbol Window :1(million symbols)
Error Symbol Threshold :1
Total Error Symbols :0
Local Total Error Events :0
Remote Total Error Events :0
Error Frame Event:
Period Window : 1(s)
Error Frame Period Event:
Frame Window : 1(ten thousand frames)
Error Frame Seconds Event:

Error Seconds Window : 1(s)
Error Seconds Threshold : 1(s)
Total Error Frame Seconds : 0(s)
Local Total Error Frame Seconds Events : 0
Remote Total Error Frame Seconds Events : 0
5.4.2 EFM Remote Loopback

R1 and R2 are connected directly. The EFM function is configured for the
directly-connected interfaces of R1 and R2, and the remote loopback function is enabled
for R1. R2 loops back the packets. For the network structure, see Figure 5-3.
5-10

Figure 5-3 EFM Remote Loopback
Configuration Flow
1. Configure the EFM function for the interface of R1 connecting to R2 directly, and enable
the EFM function globally.
2. Configure the EFM function for the interface of R2 connecting to R1 directly, and en-
able the EFM function globally.
3. After the EFM connection is established on R1 and R2, enable remote loopback for
R1.
4. Run the show ethernet-oam discovery command on R1 and R2 to check the EFM
connection establishment.
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 for R1:
R1(config)#efm
R1(config-efm-if)#set ethernet-oam rmt-loopback start
5-11

R1(config-efm)#exit
On the link where the EFM connection is established, R1 sends packets to R2 except OAM
Protocol Data Units (OAMPDUs). When R2 receives these packets, it will loop them back
to R1 directly.
5-12

Chapter 6
CFM Configuration
Table of Contents
CFM Overview ...........................................................................................................6-1
Configuring CFM ........................................................................................................6-3
CFM Maintenance ......................................................................................................6-5
CFM Configuration Instances .....................................................................................6-6
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 10–gigabit
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).
l 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

l 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 The gray points on the edge devices are the services ports connecting to devices
outside the domain. These points are defined as MEPs.
l 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
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.
6-2

Chapter 6 CFM Configuration
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.
6.2 Configuring CFM

To configure CFM on the ZXR10 M6000, perform the following steps:
1 ZXR10(config)#cfm Enters CFM configuration mode.
2 ZXR10(config-cfm)#set cfm enable Enables the CFM function globally.
3 ZXR10(config-cfm)#create md index <index> name-format Creates an maintenance domain

<format>[name <md-name>] level <level> (MD).
<level> refers to the level of the
maintenance domain. Range: 0-7.
The bigger the value, the higher the
level.
4 ZXR10(config-cfm)#md index < index > Enters MD configuration mode.
5 ZXR10(config-cfm-md)#create ma index <index> name-format Creates a maintenance association

<format> name < ma-name>[vid <vid>] (MA)
6 ZXR10(config-cfm-md)#ma index <index> Enters MA configuration mode.
7 ZXR10(config-cfm-ma)#set ccminterval <interval> Configures the CCM interval for

an MA. Range: 1-7. The range
corresponds to 3.3 ms, 10 ms, 100
ms, 1 s, 10 s, 60 s, and 600 s.
8 ZXR10(config-cfm-ma)#create mep mep-id <mepid> direction {down Creates an MEP.

| up} interface <interface-name>
9 ZXR10(config-cfm-ma)#create rmep mepid <mepid > remote-mac Creates an Remote Maintenance

<mac-address> lmep <lmepid> association End Point (RMEP).
10 ZXR10(config-cfm-ma)#create mip session-id <session-id> interface Creates an MIP.

<interface-name>
6-3

11 ZXR10(config-cfm-ma)#set mep <mepid> state {enable|disable} Enables or disables local

management function in an
MEP. For an RMEP, it enables or
disables CCM detection.
12 ZXR10(config-cfm-ma)#set mep <mepid> ccm-send {enable|disable} Enables or disables tthe CCM packet
sending function in an MEP. It is only
effective in the local MEP.
13 ZXR10(config-cfm-ma)#set mep <mepid> alarm-lowest-pri Configures the lowest fault class that
<priority> can trigger alarms in an MEP.
14 ZXR10#cfm loopback md <md-index> ma <ma-index> local-mep Sends LBMs.

<mepid> type unicast <mac-address>[repeat <time>][size
<length>][timeoutt <second>]
15 ZXR10#cfm linktrace md <md-index> ma <ma-index> local-mep < Sends LTMs. By default, the time-out
mepid><mac-address>[timeout <second>][ttl <value>] is 10, and the TTL is 64.
<mepid > MEP ID. Range: 1-8191. The ID of the local MA including the MEP should
be different.
<mac-address> MAC address of RMEP.
<lmepid> Local MEP ID. Range: 1-8191. It identifies the local MEP that has been
created in the MA, and establishes the relationship between the remote
MEP and the local MEP.
<mepid > MEP ID. Range: 1-8191. It sets a local MEP or a remote MEP.
<enable> The MEP starts to send CCMs.
<disable> The MEP stops sending CCMs.
<md-index> MD index. Range: 1-65535.
<ma-index> MA index. Range: 1-65535.
<mepid> Local MEP ID. Range: 1-8191. It is a unique identification for a local MEP
in an MA.
6-4

unicast | multicast Packet type, including unicast or multicast.
<mac-address> Destination MAC address of LBMs.
repeat <time> Number of LBMs sent at a time. Range: 1-200, default: 3.
size <length> Length of Data TLV field in an LBM. Range: 1-400, default: 0.
timeout <second> Interval of LBM time-out. Range: 1-10 seconds, default: 5 seconds.
<md-index> MD index. Range: 1-65535.
<ma-index> MA index. Range: 1-65535.
<mepid> Local MEP ID. Range: 1-8191. It is a unique identification for a local MEP
in an MA.
<mac-address> Destination MAC address of LTMs.
timeout <second> Interval of LTR time-out. Range: 5-10 seconds, default: 10 seconds.
ttl <value> The maximum hops that LTMs can be forwarded. Range: 1-128, default:
64.
6.3 CFM Maintenance

To maintain CFM on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#show cfm status Displays the CFM global configuration state.
ZXR10#show cfm md {<md-index>|all} Displays information of a specific MD.
ZXR10#show cfm ma {<ma-index>|all} md <md-index> Displays the detailed information of a specific

MA.
ZXR10#show cfm mp {<mpid>|all} md <md-index> ma <ma-index> Displays the detailed configuration and state
information of a specific MP.
The following is sample output from the show cfm md all command:
ZXR10#show cfm md all
MD index 1
name format/name: 2(Base string)/vcxzbbdz
level: 1
contain MA numbers: 30
MD index 2
6-5

name format/name: 1(No present)/

level: 1
contain MA numbers: 0
MD index 1 Displays the index value of an MD.
name format/name Format field (meaning) and name value of an MD name.
level Level of an MD.
contain MA numbers The number of MAs that have been created in the current MD.
The following is sample output from the show cfm ma all md 8 command:
ZXR10#show cfm ma all md 8
MA index 2
name-format/name: 2(Char string)/a2
belong to MD: 8
time interval: 3.3ms
vid list: no vids
contain MEP numbers: 4
MA index 2 Displays the index value of an MA.
name-format/name Format field (meaning) and name value of an MA name.
belong to MD The MD to which the current MA belongs.
time interval CCM interval of the MA.
vid list VID list that an MA associated with.
contain MEP numbers The number of MEPs (including local MEP and RMEP) that have been
created in an MA.
6.4 CFM Configuration Instances

6.4.1 CFM Fast Connectivity Detection
The routers R1 and R2 are connected directly. The CFM must be configured for the
directly-connected interfaces of R1 and R2. For the network structure, see Figure 6-2.
6-6

Figure 6-2 CFM Connection Establishment
Configuration Flow
1. Create MDs and MAs with the same name and the same ID on R1 and R2, and enable
CFM globally.
2. Create local MEPs with the same level for the directly-connected interfaces of R1 and
R2, use the peer MAC and MEP ID to create RMEPs for R1 and R2, enable local MEP
and CCM to send packets, and enable RMEP.
3. Run the show cfm mp command on R1 and R2 to check the MEP identification bit and
the CFM connection establishment between R1 and R2.
R1(config)#cfm
R1(config-cfm)#create md index 1 name-format 2 name MD1 level 4
R1(config-cfm-md)#create ma index 1 name-format 2 name MA1
R1(config-cfm-ma)#set ccminterval 1 /*fast detection*/
R1(config-cfm-ma)#create rmep mepid 2 remote-mac 00ee.efab.ede3 lmep 1

R2(config)#cfm
R2(config-cfm)#create md index 1 name-format 2 name MD1 level 4
R2(config-cfm-md)#create ma index 1 name-format 2 name MA1
R2(config-cfm-ma)#set ccminterval 1
R2(config-cfm-ma)#create rmep mepid 1 remote-mac 0016.1514.1312 lmep 2
6-7

1. Run the show cfm mp all md 1 ma 1 command on R1 to check the link information,
R1#show cfm mp all md 1 ma 1
MP type: local mep
Direction : down
MEPID : 1
Level : 4
Primary Vlan : 0
Admin state : enable
CCM send state : enable
CCM interval : 3.3ms
LowestAlarmPriority : 2
AIS disable, LCK disable, AIS/LCK period 1s.
LM disable
DM disable
PresentRDI : 0 /*Local RDI is 0.*/
MAdefect indication : 0
Assign port : gei-0/2/0/6
TotalSendCCMs : 49097
TotalRcvdCCMs : 10461
RightRcvdCCMs : 10461
DiscardCCMs : 0
DefErrorCCMs : 0
DefXconCCMs : 0
TotalSendLBMs : 0
TotalRcvdLBMs : 0
TotalSendLBRs : 0
TotalRcvdLBRs : 0
MP type: remote mep

MEPID : 2
Level : 4
ReferLmep : 1
LastRDI : 0 /*Remote RDI is 0.*/
Lost CCM defect : false /*Receives remote CCMs*/
Remote mac : 00ee.efab.ede3
LMFrameLostRemote : 0
LMFrameLostLocal : 0
1DMFrameTimeDelay : 0(s), 0(ns)
1DMFrameTimeDelayChg: 0(s), 0(ns)
DMMFrameTimeDelay : 0(s), 0(ns)
6-8

DMMFrameTimeDelayChg: 0(s), 0(ns)
R1#
2. Run the show cfm mp all md 1 ma 1 command on R2 to check the link information,
R2#show cfm mp all md 1 ma 1
MP type: local mep
Direction : down
MEPID : 2
Level : 4
Primary Vlan : 0
CCM send state : enable
LowestAlarmPriority : 2
AIS disable, LCK disable, AIS/LCK period 1s.
LM disable
DM disable
PresentRDI : 0 /*Local RDI is 0.*/
MAdefect indication : 0
Assign port : gei-0/2/0/3
TotalSendCCMs : 81644
TotalRcvdCCMs : 76092
RightRcvdCCMs : 76092
DiscardCCMs : 0
DefErrorCCMs : 0
DefXconCCMs : 0
TotalSendLBMs : 0
TotalRcvdLBMs : 0
TotalSendLBRs : 0
TotalRcvdLBRs : 0
MP type: remote mep

MEPID : 1
Level : 4
ReferLmep : 2
LastRDI : 0 /*Remote RDI is 0.*/
Lost CCM defect : false /*Receives remote CCMs*/
Remote mac : 0016.1514.1312
LMFrameLostRemote : 0
LMFrameLostLocal : 0
1DMFrameTimeDelay : 0(s), 0(ns)
1DMFrameTimeDelayChg: 0(s), 0(ns)
6-9

DMMFrameTimeDelay : 0(s), 0(ns)

DMMFrameTimeDelayChg: 0(s), 0(ns)
R2#
6.4.2 Cross-L2 VPN Connectivity Detection

In an L2 VPN network environment, the CFM MEPs are configured on CE1, PE1, PE2, and
CE2 to detect the connectivity of link CE1 – PE1 – PE2 – CE2. For the network structure,
see Figure 6-3.
Figure 6-3 Cross-L2 VPN Connectivity Detection
Configuration Flow
1. Create MDs and MAs with the same name and the same ID for CE1, PE1, PE2 and
CE2.
2. Set the interfaces on CE1 and CE2 as a CFM connectivity detection group, and enable
alarm on CE1 and CE2. For the configuration, refer to the configuration example of
CFM Fast Connectivity Detection.
3. Configure MIPs on the interfaces of PE1 and PE2 on the public network side and the
AC side, and enable the CFM function globally.
4. Configure CE1 to execute CFM linktrace and CFM loopback towards MIPs and MEPs
on PE1, PE2, and CE2, and check the link connectivity.
Run the following commands on CE1:
CE1(config)#cfm
CE1(config-cfm)#set cfm enable
6-10

CE1(config-cfm)#create md index 1 name-format 2 name MD1 level 4

CE1(config-cfm)#md index 1
CE1(config-cfm-md)#create ma index 1 name-format 2 name MA1
CE1(config-cfm-md)#ma index 1
CE1(config-cfm-ma)#create mep mepid 1 direction down interface gei-0/2/0/6
CE1(config-cfm-ma)#set ccminterval 1 /*fast detection*/
CE1(config-cfm-ma)#set mep 1 state enable
CE1(config-cfm-ma)#create rmep mepid 2 remote-mac 00ee.efab.ede3 lmep 1
CE1(config-cfm-ma)#exit
CE1(config-cfm-md)#exit
CE1(config-cfm)#exit
CE1(config)#logging on
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)#create ma index 1 name-format 2 name MA1
CE2(config-cfm-md)#ma index 1
CE2(config-cfm-ma)#create mep mepid 2 direction down interface gei-0/2/0/3
CE2(config-cfm-ma)#set ccminterval 1
CE2(config-cfm-ma)#set mep 2 ccm-send enable
CE2(config-cfm-ma)#create rmep mepid 1 remote-mac 0016.1514.1312 lmep 2
CE1(config-cfm-ma)#exit
CE1(config-cfm-md)#exit
CE1(config-cfm)#exit
CE1(config)#logging on
Run the following commands on PE1:

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

PE2#configure terminal
PE2(config)#cfm
PE2(config-cfm)#set cfm enable
PE2(config-cfm)#create md index 1 name-format 2 name MD1 level 4
PE2(config-cfm)#md index 1
PE2(config-cfm-md)#create ma index 1 name-format 2 name MA1
PE2(config-cfm-md)#ma index 1
PE2(config-cfm-ma)#end
The 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, CFM alarms will generate on both CE1 and
CE2. The operations (trace and ping) executed by CE2 towards CE1 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 linktrace md 1 ma 1 local-mep 1 0016.1514.1312

Type Ctrl+C to abort. Ttrace the link to 0016.1514.1312,
Per-Hop timeout is 10 seconds.
Trace sent via gei-0/2/0/3 on level 4.
--------------------------------------------------------------
Ingress Egress Relay
Hops MAC ADDRESS Forwarded Action Action Action
--------------------------------------------------------------
F 1 1622.30c4.e999 Forwarded IngOk EgrOk RlyFDB
F 2 00d0.d011.3377 Forwarded IngOk EgrOk RlyFDB
! 3 0016.1514.1312 Not Forwarded IngOk RlyHit
Trace complete
6-12

Chapter 7
BFD Configuration
Table of Contents
BFD Overview ............................................................................................................7-1
BFD Configuration......................................................................................................7-2
BFD Maintenance ......................................................................................................7-6
BFD Configuration Instances......................................................................................7-7
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.
7-1

The forwarding engine and the control engine are isolated. This not only binds the
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.
7.2 BFD Configuration

Configuring Example BFD
To configure an example BFD on the ZXR10 M6000, perform the following steps:
1 ZXR10(config)#bfd Enters BFD configuration mode.
2 ZXR10(config-bfd)#session <session-name>{l2link-bfd interface Configures an example BFD in BFD

<interface-name>[source <src-ip-address>]| link-bfd {ipv4|ipv6}<src-ip- configuration mode.
address><dst-ip-address> interface <interface-name >[vrf <vrf-name>]|
peer-bfd {ipv4|ipv6}<src-ip-address><dst-ip-address>[vrf <vrf-name>]}
3 ZXR10(config-bfd-session-session1)#active Submits a created session.
4 ZXR10(config-bfd)#interface <interface-name> Specifies an interface that needs

to be configured with session
parameters in BFD configuration
mode.
5 ZXR10(config-bfd)#bfd interval <interval> min_rx <min_rx> Configures the package transceiver

multiplier <multiplier> interval and the detection multiplier
for the BFD session under the
interface.
Description of parameters in Step 2 is as follows:
<src-ip-address> Establishes the source address for the session (It must be the local
address).
<dst-ip-address> Establishes the destination address for the session (It is not limited
to the directed address).
<interface-name> Specifies the egress interface for the session. (If the egress interface
is not specified, the packet may be sent locally instead of to the
egress interface.)
Description of parameters in Step 5 is as follows:
7-2

Chapter 7 BFD Configuration
<interval> The interval to send detection packes. Range: 10–990, unit: ms.
<min-rx-interval> The interval to receive detection packets. Range: 10–990, unit: ms.
<multiplier> The detection multiplier. Range: 3–50.
Configuring a Static Route BFD

To configure a static route BFD on the ZXR10 M6000, run the following commands:
Command Function
ZXR10(config)#ip route vrf <vrf-name><prefix><net-mask>{<forwarding-ro Configures a static route for a private

uter's-address>[globle]|<interface-name>[<forwarding-router's-address>]}[<dis network, and enables the BFD detection
tance-metric>][metric <metric-number>] bfd enable function for this link.
ZXR10(config)#ip route <prefix><net-mask>{<forwarding-router's-address Configures a static route for a public

>|<interface-name>[<forwarding-router's-address>]}[<distance-metric>][m network, and enables the BFD detection
etric <metric-number>] bfd enable function for this link.
<prefix> The destination network prefix in dotted decimal notation.
<net-mask> The network mask in dotted decimal notation.
<forwarding-router's-address> The next-hop address in dotted decimal notation.
globle The next-hop of a specific public network for the private network.
This parameter and thebfd enable parameter are mutually exclusive.
<interface-name> The name of a specific egress interface.
<distance-metric> The distance metric. Range: 1 to 255, default: 1.
<metric-number> The route metric. Range: 0 to 255, default: 1.
During the static route configuration, you need to confirm the unique link to the destination
end, and run the bfd enable command to enable the BFD detection function for this link.
Configuring OSPF BFD

To configure Open Shortest Path First (OSPF) BFD on the ZXR10 M6000, perform the
following steps:
1 ZXR10(config)#router ospf <process-id> Creates an OSPF process with a specified

process ID or enters a specified OSPF
process.
7-3

2 ZXR10(config-ospfv2)#bfd [area <area-id >] Enables the BFD function for all interfaces,
or enables the BFD function for all
interfaces in a specified area.
3 ZXR10(config-ospfv2)#interface <interface-name> Selects an interface for which the BFD

function must be enabled.
4 ZXR10(config-ospfv2-if)#bfd Enables the BFD function for the current

interface.
It is allowed to enable the BFD function for all interfaces in OSPF route configuration mode,
or enable the BFD function for all interfaces bounded to a specified area, or enter OSPF
interface configuration mode to enable the BFD function for current interfaces.
Configuring IS-IS BFD

To configure Intermediate System-to-Intermediate System (IS-IS) BFD on the ZXR10
M6000, perform the following steps:
1 ZXR10(config)#router isis [<process-id>][vrf <vrf-name>] Creates an IS-IS process or enters a

specified IS-IS process.
2 ZXR10(config-isis)#interface <interface-name> Specifies the interface on which the

BFD needs to be enabled in IS-IS route
configuration mode.
3 ZXR10(config-isis-if)#bfd-enable Enable IS-IS BFD.
Enable the BFD function on an interface that runs the IS-IS protocol. When the interface
establishes the IS-IS neighbor relationship with a remote interface, the BFD session based
on IS-IS is established on the directly-connected link between this pair of interfaces.
Configuring BGP BFD

To configure Border Gateway Protocol (BGP) BFD on the ZXR10 M6000, perform the
following steps:
1 ZXR10(config)#router bgp <as-number> Configures the BGP module for the router.
2 ZXR10(config-bfd)#neighbor {<ipv4-address>|<ipv6-address Enables the BFD link failure detection

>|<peer-group-name>} fall-over bfd mechanism.
Single-hop (directly-connected link) BFD or multi-hop (indirectly-connected link) BFD can

be configured in accordance with the connection mode of the BGP neighbor (directly or
indirectly).
7-4

Configuring LDP BFD

To configure LDP BFD on the ZXR10 M6000, perform the following steps:
1 ZXR10(config)#mpls ldp instance <1-65535>[vrf <vrf-name>] Enables LDP to establish an LSP along
with the ordinary hop-by-hop routes and
enters LDP configuration mode.
2 ZXR10(config-ldp)#bfd <FEC address><mask length> Configures parameters related to LDP

interval <interval> min-rx <min-rx> multiplier LSP BFD and triggers to establish an LDP
<multiplier>[source <IP address>] BFD session.
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.
<FECaddress> The LSP address to establish a BFD session, normally a remote

network segment.
<masklength> The mask length of the remote address. Range: 0-32.
<interval> The minimum intervals of sending packets. Range: 10-990

milliseconds.
<min_rx> The minimum interval of receiving packets. Range: 10-990

milliseconds.
<multiplier> Multiplier of detection time-out. Range: 3–50.
<IP address> The source LSP address that is used for establish the BFD. In
general, it is the address of the local LDP.
Configuring RSVP BFD

To configure RSVP BFD on the ZXR10 M6000, run the following command:
Command Function
ZXR10(config-mpls-te-if)#bfd Enables BFD in MPLS-TE real-interface

mode.
Configuring RSVP LSP BFD

To configure RSVP LSP BFD on the ZXR10 M6000, run the following command:
Command Function
ZXR10(config-mpls-te-if)#tunnel mpls traffic-eng bfdinterval Enables tunnel lsp BFD in tunnel interface mode
<interval> min_rx <min-rx> multiplier <multiplier> of MPLS-TE.
7-5

<interval> The minimum interval to send specified BFD control packets. Range:
10 to 990 milliseconds.
<min-rx> The minimum interval to receive specified BFD control packets.

Range: 10 to 990 milliseconds.
<multiplier> Multiplier of specified BFD control packets. Range: 3 to 50.
Configuring LOCAL/REMOTE Descriptor

To configure LOCAL/REMOTE descriptor for the static BFD session on the ZXR10 M6000,
run the following command:
Command Function
ZXR10(config-bfd-session-l2session)#discriminator ld Configures the LOCAL/REMOTE descriptor for a

<ld> rd <rd> static session.
Parameter descriptions of the command are as follows:
<ld> Specifies the local identification of a session. Range: 1-4096.
<rd> Specifies the remote identification of a session. Range: 1-4096.
7.3 BFD Maintenance

To maintain BFD on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#debug bfd packet Displays the brief information of packets sent and received
during the BFD session establishment.
ZXR10#debug bfd event Displays the state information change of the BFD session
during BFD session establishment.
ZXR10#debug bfd byte Displays the information of the packets (packets in the
UDP data area) sent and received during the BFD session
establishment.
ZXR10#show bfd neighbors ip detail Displays the detailed information of the IP-type BFD
session.
ZXR10#show bfd neighbors ip brief Displays the brief information of IP-type BFD session.
ZXR10#show bfd neighbors ldp brief Displays the brief information of LDP-type BFD session.
ZXR10#show bfd neighbors ldp detail Displays the detailed information of LDP-type BFD session.
ZXR10#show bfd neighbors rsvp brief Displays the brief information of RSVP-type BFD session.
7-6

Command Function
ZXR10#show bfd neighbors rsvp detail Displays the detailed information of RSVP-type BFD
session.
7.4 BFD Configuration Instances

7.4.1 Configuring IS-IS BFD
It is required to run the IS-IS protocol between R1 and R2, and enable the BFD function
for interfaces of R1 and R2, see Figure 7-1.
Figure 7-1 IS-IS BFD Configuration Example
Configuration Planning
1. Run the IS-IS protocol between R1 and R2.
2. Enable the BFD function for interfaces of R1 and R2
R1(config)#interface xgei-0/5/0/3
R1(config-if)#exit
R1(config)#router isis
R1(config-isis)#area 49.0172
R1(config-isis)#system-id 0020.0096.0001
R1(config-isis)#interface xgei-0/5/0/3
R1(config-isis-if)#ip router isis
R1(config-isis-if)#bfd-enable
R1(config-isis-if)#end
R2(config-if)#exit
7-7

R2(config-isis-if)#bfd-enable
After the configuration, an IS-IS BFD session should be established successfully. Run the
following command to check the configuration results.
Run the show bfd neighbors [ip brief|ip detail] command to check whether the IS-IS BFD
configuration takes effect.
Check the IS-IS BFD configuration on R1, which is displayed as follows:
R1(config)#show bfd neighbors ip brief

LocalAddr PeerAddr LD RD Hold State interface
172.20.130.213 172.20.130.21 1 3 150 UP xgei-0/5/0/3
R1(config)#show bfd neighbors ip detail

---------------------------------------------------------------------------
LocalAddr: 172.20.130.213
PeerAddr : 172.20.130.214
Local Discr: 1 Remote Discr: 3 State: UP
Interface: xgei-0/5/0/3
Instance Name:
Local Diag: 0 Demand mode: 0 Poll bit: 0

MinTxInt: 50 MinRxInt: 50 Multiplier: 3
Received MinRxInt: 50 Received Multiplier: 3 Holdown : 150
Rx Count: 149924 Rx Interval (ms) min/max/avg: 36 /37 /37
Tx Count: 129006 Tx Interval (ms) min/max/avg: 43 /43 /43
Registered protocols: ISIS
Uptime: 0 DAY,1 HOUR,32 MINUTE
Last packet: Version: 1 Diagnostic: 0
Demand bit: 0 Poll bit: 0 Final bit: 1
Multiplier: 3 Length: 24
My Discr: 1 Your Discr: 3
Min tx interval: 50 Min rx interval: 50 Min Echo interval: 0
Minpktlen: 0 Maxpktlen: 0
Vpnid:0 Vrf name:
===========================================================================
7-8

7.4.2 Configuring OSPF BFD

It is required to run the OSPF protocol between R1 and R2, and enable the BFD function
for interfaces of R1 and R2. For the network structure, see Figure 7-2.
Figure 7-2 OSPF BFD Configuration Example
Configuration Flow
1. Run the OSPF protocol between R1 and R2.
R1(config-if)#exit
R1(config-ospfv2)#network 172.20.130.0 0.0.0.255 area 0.0.0.0
R1(config-ospfv2)#bfd area 0
R1(config-ospfv2)#end

R2(config-if)#exit
R2(config-ospfv2)#bfd area 0
R2(config-ospfv2)#end
After the configuration, an OSPF BFD session should be established successfully. Run
the following command to check the configuration result.
Run the show bfd neighbors [ip brief|ip detail] command to check whether the OSPF BFD
Check the OSPF BFD configuration on R1, which is displayed as follows:
7-9

LocalAddr PeerAddr LD RD Hold State Interface

172.20.130.213 172.20.130.214 3 3 150 UP xgei-0/5/0/3

----------------------------------------------------------------------------
LocalAddr: 172.20.130.213
PeerAddr : 172.20.130.214
Instance Name:

Registered protocols: OSPF
Vpnid:0 Vrf name:
============================================================================
7.4.3 Configuring BGP Single-Hop BFD

It is required to run the BGP protocol between R1 and R2, and enable the BFD function
for interfaces of R1 and R2. For the network structure, see Figure 7-3.
Figure 7-3 BGP Single-Hop BFD Configuration Example
Configuration Flow
1. Run the BGP protocol between R1 and R2.
7-10

R1(config-if)#exit
R1(config)#router bgp 18004
R1(config-bgp)#neighbor 172.20.130.214 remote-as 18004
R1(config-bgp)#neighbor 172.20.130.214 fall-over bfd
R1(config-bgp)#exit

R2(config-if)#exit
R2(config-bgp)#exit
After the configuration, a BGP BFD session should be established successfully. Run the
following command to check the configuration result.
Run the show bfd neighbors [ip brief|ip detail] command to check whether the BGP BFD
Check the configuration result on R1, which is displayed as follows:
R1#show bfd neighbors ip brief
172.20.130.213 172.20.130.214 4097 4097 150 UP xgei-0/5/0/3
R1#show bfd neighbors ip detail
--------------------------------------------------------------------------
LocalAddr: 172.20.130.213
PeerAddr : 172.20.130.214
Instance Name:
Local Diag: 0 Demand Mode: 0 Poll Bit: 0

Received MinRxInt: 50 Received Multiplier: 3 Holdown: 150
7-11


Registered Protocols: BGP
Last Packet: Version: 1 Diagnostic: 0

Demand Bit: 0 Poll Bit: 0 Final Bit: 1
Min Tx Interval: 50 Min Rx Interval: 50 Min Echo Interval: 0
Vpnid:0 Vrf Name:
==========================================================================
7.4.4 Configuring BGP Multi-Hop BFD

When a fault occurs to a remote link, the local end can detect the remote fault quickly with
the BFD function.
Figure 7-4 shows a typical network structure of BGP multi-hop BFD.
Figure 7-4 BGP Multi-Hop BFD Configuration Example
Configuration Flow
1. Configure routing protocols.
2. Enable the BFD function for protocol interfaces or a specific destination route.
R1(config-if)#exit
R1(config)#interface loopback1
R1(config-if)#exit
7-12


R1(config-bgp)#neighbor 1.1.1.213 remote 200
R1(config-bgp)#neighbor 1.1.1.213 update-source loopback1
R1(config-bgp)#neighbor 1.1.1.213 ebgp-multihop

R2(config-if)#exit
R2(config-if)#exit

R3(config-if)#exit
R3(config-if)#exit
R3(config-bgp)#neighbor 1.1.1.211 remote 100
R3(config-bgp)#neighbor 1.1.1.211 ebgp-multihop
After the configuration, a BGP BFD session should be established successfully. Run the
Run the show bfd neighbors [ip brief | ip detail | ldp-brief | ldp-detail | rsvp-brief | rsvp-detail]
command to check whether the BGP BFD configuration takes effect.
Check the single-hop configuration result on R1, which is displayed as follows:
7-13


1.1.1.211 1.1.1.213 4098 4097 150 UP ---
----------------------------------------------------------------------------
LocalAddr: 1.1.1.211
PeerAddr : 1.1.1.213
Interface: ---
Instance Name:
Local Diag: 0 Demand Mode: 0 Poll Bit: 0

Received MinRxInt: 50 Received Multiplier: 3 Holdown: 150
Registered Protocols: BGP
Last Packet: Version: 1 Diagnostic: 0

Demand Bit: 0 Poll Bit: 0 Final Bit: 1
Min Tx Interval: 50 Min Rx Interval: 50 Min Echo Interval: 0
Vpnid:0 Vrf Name:
============================================================================
7.4.5 Configuring Static Route BFD

It is required to run static route protocol between R1 and R2, and enable static route BFD
on R1 and R2. For the network structure, see Figure 7-5.
Figure 7-5 Static Route BFD Configuration Example
Configuration Flow
1. Run the static route protocol between R1 and R2.
7-14

2. Configure the static route BFD between R1 and R2.
R1(config-if)#exit
R1(config-if)#exit
R1(config)#ip route 172.20.108.1 255.255.255.255 172.20.130.214 bfd enable

R2(config-if)#exit
R2(config-if)#exit
R2(config)#ip route 172.20.96.1 255.255.255.255 172.20.130.213 bfd enable
After the configuration, a static route BFD session should be established successfully. Run
the following command to check the configuration result.
Run the show bfd neighbors [ip brief|ip detail] command to check whether the static route
BFD configuration takes effect.
Check the static route BFD configuration on R1, which is displayed as follows:
172.20.130.213 172.20.130.214 5 32 150 UP ---

---------------------------------------------------------------------------
LocalAddr: 172.20.130.213
PeerAddr : 172.20.130.214
Interface: ---
Instance Name:
7-15


Registered protocols: STATIC
Vpnid:0 Vrf name:
============================================================================
7.4.6 Configuring LDP BFD

After the LDP neighbor relationship is successfully established between R1 and R2, it
is only necessary to set one end as the active party, and the other end as the passive
party. If the BFD versions at both ends are consistent, the BFD session can be created
successfully, see Figure 7-6.
Figure 7-6 LDP BFD Configuration Example
Configuration Flow
1. Configure the LDP between R1 and R2.
2. Set the IP addresses on the loopback interfaces as the LSR Router-IDs.
3. Enable MPLS hop-by-hop forwarding on the links between R1 and R2.
4. Set R1 as the active party and configure an LDP BFD session on R1.
R1(config-if)#exit
R1(config-if)#exit
7-16


R1(config)#mpls ldp instance 1
R1(config-ldp)#router-id loopback1
R1(config-ldp)#interface xgei-0/5/0/3
R1(config-ldp-if)#exit
R1(config-ldp)#bfd 172.20.108.1 32 interval 50 min_rx 50 multiplier 3

R2(config-if)#exit
R2(config-if)#exit
R2(config)#mpls ldp instance 1
R2(config-ldp)#router-id loopback1
R2(config-ldp)#interface xgei-0/0/0/3
R2(config-ldp-if)#exit
After the configuration, an LDP BFD session should be established successfully. Run the
Run the show bfd neighbors [ldp brief|ldp detail] command to check whether the LDP BFD
Check the LDP BFD configuration on R1, which is displayed as follows:
R1(config)#show bfd neighbors ldp brief
PeerAddr PrefixLen LD RD Hold State Interface
172.20.108.1 32 6 34 150 UP ---
R1(config)#show bfd neighbors ldp detail

PeerAddr Prefixlen LD RD Hold Mult State Interface
172.20.108.1 32 6 34 150 3 UP ---
----------------------------------------------------------------------------
BFD Type: LDP[Active]
7-17

Registered protocols: LDP LSP

============================================================================
7.4.7 Configuring Static Single-Hop BFD

At present, both single-hop BFD and static multi-hop BFD are not associated with routes.
For the static single-hop BFD, it is necessary to configure an egress. For the static
multi-hop BFD, it is unnecessary to configure an egress.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. For the network structure, see Figure 7-7.
Figure 7-7 Static Single-Hop BFD Configuration Example
Configuration Flow
1. Configure the static single-hop BFD on R1.
2. Configure the static route BFD on R2.
R1(config-if)#exit
R1(config-if)#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-session-test)#active

7-18


R2(config-if)#exit
R2(config-if)#exit
R2(config)#ip route 172.20.96.1 255.255.255.255 xgei-0/0/0/3
172.20.130.213 bfd enable
/*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 check
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 single-hop BFD configuration on R1, which is displayed as follows:
172.20.130.213 172.20.130.214 1 58 150 UP xgei-0/5/0/3

LocalAddr: 72.20.130.213
PeerAddr : 72.20.130.214
Instance Name:test
---------------------------------------------------------------------------
Registered protocols: INSTANCE
Vpnid:0 Vrf name:
=============================================================================
7-19

Check the static route BFD configuration on R2, which is displayed as follows:
LocalAddr PeerAddr LD RD Hold State interface
172.20.130.214 172.20.130.213 58 1 150 UP xgei-0/0/0/3

-----------------------------------------------------------------------------
LocalAddr: 172.20.130.214
PeerAddr : 172.20.130.213
Instance Name:

Registered protocols: STATIC
Vpnid:0 Vrf name:
============================================================================
7.4.8 Configuring Static Multi-Hop BFD

Both single-hop BFD and static multi-hop BFD are not associated with routes. For the
static single-hop BFD, it is necessary to configure an egress. For the static multi-hop BFD,
it is unnecessary to configure an egress. 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. For
the network structure, see Figure 7-8.
Figure 7-8 Static Multi-Hop BFD Configuration Example
7-20

Configuration Flow
1. Configure the static multi-hop BFD on R1.
2. Configure the BGP multi-hop BFD on R3.
R1(config-if)#exit
R1(config-if)#exit
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)#commit
R1(config-bfd-session-test)#end

R2(config-if)#exit
R2(config-if)#exit
R2(config-if)#exit

R3(config-if)#exit
7-21

R3(config-if)#exit
R3(config-bgp)#exit
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 check
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.
Check the static single-hop BFD configuration on R1, which is displayed as follows:
172.20.96.1 172.20.108.2 6 1 150 UP ---

----------------------------------------------------------------------------
LocalAddr: 172.20.96.1
PeerAddr : 172.20.108.2
Interface: ---
Instance Name:test

Registered protocols: INSTANCE
7-22


Vpnid:0 Vrf name:
============================================================================
Check the BGP multi-hop BFD configuration on R3, which is displayed as follows:
172.20.108.2 172.20.96.1 1 6 150 UP ---

----------------------------------------------------------------------------
LocalAddr: 172.20.108.2
PeerAddr : 172.20.96.1
Interface: ---
Instance Name:

Registered protocols: BGP
Vpnid:0 Vrf name:
============================================================================
7.4.9 Configuring BFD on RSVP Interface

It is required to establish an IS-IS TE tunnel between R1 and R2 and enable BFD for the
RSVP-TE interfaces on R1 and R2. For the network structure, see Figure 7-9.
7-23

Figure 7-9 Configuring BFD on RSVP Interface
Configuration Flow
1. Establish an IS-IS TE tunnel between R1 and R2.
2. Enable the BFD function for the RSVP-TE interfaces on R1 and R2.
R1(config-if)#exit
R1(config-isis)#metric-style wide
R1(config-isis)#mpls traffic-eng router-id loopback1
R1(config-isis)#mpls traffic-eng level-2
R1(config)#interface te_tunnel1
R1(config-if)#ip unnumbered loopback1
R1(config-if)#ex
R1(config)#mpls traffic-eng
R1(config-mpls-te)#tunnel te_tunnel 1
R1(config-mpls-te-if)#tunnel destination ipv4 172.20.108.1
R1(config-mpls-te-if)#tunnel mpls traffic-eng path-option 1 dynamic
R1(config-mpls-te-if)#tunnel mpls traffic-eng fast-reroute facility
R1(config-mpls-te-if)#exit
R1(config-mpls-te)#interface xgei-0/5/0/3
R1(config-mpls-te-if)#bfd

R2(config-if)#exit
R2(config-isis)#metric-style wide
7-24

R2(config-isis)#mpls traffic-eng router-id loopback1

R2(config-isis)#mpls traffic-eng level-2
R2(config-mpls-te)#interface xgei-0/0/0/3
R2(config-mpls-te-if)#bfd
After the configuration, a session of RSVP interface on R1 should be established
successfully. Run the following commands to check the configuration result.
Run the show bfd neighbors [ip-brief|ip-detail] command to check whether the BFD
configuration of the RSVP interface takes effect.
Check the BFD configuration for RSVP interface on R1, which is displayed as follows:

172.20.130.213 172.20.130.214 8 1 150 UP xgei-0/5/0/3

-------------------------------------------------------------
LocalAddr: 172.20.130.213
PeerAddr : 172.20.130.214
Instance Name:

Registered protocols: RSVP
Vpnid:0 Vrf name:
7-25

Vpnid:0 Vrf name:

============================================================================
7.4.10 Configuring RSVP LSP BFD

The RSVP LSP BFD uses the BFD function to detect the LSP of an RSVP tunnel. When it is
combined with the hot standby function and when an invalid LSP becomes to an active LSP,
the tunnel traffic should be switched over to the standby LSP. For the network structure,
see Figure 7-10.
Figure 7-10 RSVP LSP BFD Configuration Example
Configuration Flow
1. Enable the OSPF-TE function among R1, R2 and R3.
2. Configure a hot standby tunnel on R1 (R1-R3-R2) and configure BFD on the tunnel.
R1(config-if)#exit
R1(config-if)#exit
R1(config-if)#exit
R1(config-ospfv2)#mpls traffic-eng area 0
7-26

R1(config-ospfv2)#mpls traffic-eng router-id loopback10

R1(config)#interface te_tunnel1
R1(config-if)#ip unnumbered loopback1
R1(config-if)#exit
R1(config-mpls-te)#interface fei-0/5/0/4
R1(config-mpls-te)#tunnel te_tunnel 1
R1(config-mpls-te-if)#tunnel destination ipv4 10.10.10.2
R1(config-mpls-te-if)#tunnel mpls traffic-eng path-option 1
explicit-path identifier 1
R1(config-mpls-te-if)#tunnel mpls traffic-eng hot
R1(config-mpls-te-if)#tunnel mpls traffic-eng bfd interval 30 min-rx 30
multiplier 5
R1(config-mpls-te)#explicit-path identifier 1 next-address 54.1.1.3 strict
R1(config-mpls-te)#explicit-path identifier 1 next-address 115.1.1.2 strict

R2(config-if)#exit
R2(config-if)#exit
7-27

R3(config-if)#exit
R3(config-if)#exit
After the configuration, the tunnel1 on R1 is in Up status and a hot standby tunnel is
generated. The relation of the hotstandby is ready. The RSVP LSP BFD session on R1
should be established successfully. If the link between R3 and R2 is invalid, LSP BFD
becomes Down and then becomes Up, and the traffic is switched over to the hot standby
tunnel.
Run the show bfd neighbors [rsvp-brief|rsvp-detail] command to check whether the RSVP
interface BFD configuration takes effect.
Check the tunnel on R1, which is displayed as follows:
R1(config)#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
tunnel_1 10.10.10.2 - fei-0/5/0/4 up/up
tunnel_1(hot) 10.10.10.2 - fei-0/5/0/7 up/up
R1(config)#show mpls traffic-eng hot-standby

Primary Lsp Pri_out intf/label Hot-standby Lsp Hot_out intf/label Status
(100,12) fei-0/5/0/4:147456 (100,13) fei-0/5/0/7:0 ready
Check the BFD configuration of the RSVP interface on R1, which is displayed as follows:
7-28

R1(config)#show bfd neighbors rsvp-brief

TunnelId/PeerAddr LD RD Hold State Interface
te_tunnel1 11 71 150 UP --
/*When the R3-R2 link is invalid, the tunnel hotstandby relation is active.
RSVP LSP BFD is Down.*/
R1(config-mpls-te)#show mpls traffic-eng hot-standby
Primary Lsp Pri_out intf/label Hot-standby Lsp Hot_out intf/label Status
(100,12) fei-0/5/0/4:147456 (100,13) fei-0/5/0/7:0 active

te_tunnel1 11 71 150 DOWN --

te_tunnel1 13 73 150 UP --
7-29

7-30

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 Sub-Second: It is the requirement of most IP networks.
l Sub-500 ms: It is an objective that can be reached.
l 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

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. Detect faults quickly: The common technologies include BFD, and physical signal test.
2. Modify the forwarding plane: Hand over the traffic to the recalculated backup path.
3. Perform route re-convergence.
4. 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

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

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

VPN FRR is formed among PE1, PE2, and PE4, and LDP/TE FRR is formed between PE1
and PE2. The VPN FRR protects the node fault, and TE /LDP FRR protects the link fault.
For the network structure, see Figure 8-1.
Figure 8-1 VPN FRR + TE/LDP FRR Application Scenes
As shown above, there are three links from CE1 to CE2 (not considering PE3), including
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 from
PE1 to PE2. After the TE /LDP FRR switchover, the link is from PE1 to PE4 an then to
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, 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 are implemented.
8-3

PWE3/VPWS FRR+TE/LDP FRR

PW FRR is formed among PE1, PE2, and PE3, and LDP/TE FRR is formed between PE1
and PE2. The PW FRR protects the node fault, and TE /LDP FRR protects the link fault.
For the network structure, see Figure 8-2.
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
The IP FRR is formed among PE1, PE2, and PE3, and TE FRR is formed between PE1
and PE2. IP FRR protects the node fault, and TE/LDP FRR protects the link fault. For the
network structure, see Figure 8-2.
8.1.3 Configuring IP FRR

The IP FRR function is normally used together with a routing protocol. Common IP FRR
includes OSPF FRR, IS-IS FRR, and BGP FRR. For the principle and configuration
commands of IP FRR, refer to the related topics in the ZXR10 M6000 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.
8-4

2. Modify the forwarding plane and hand over the traffic to the prepared backup path.
3. Converge the route again.
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 Configuration Guide (IPv4 Route).
8.3 L2 VPN FRR Configuration

8.3.1 L2 VPN FRR Overview
Introduction
With the rapid development of the network, the triple-play requirement becomes more and
more exigent. 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 is the threshold indicator for 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 node is protected. In this way, traffic can pass through
the protected link or node without interruption. At the same time, the head node can initiate
the re-establishment of the active path without affecting data transmission.
Work Flow
The L2 VPN FRR is also called PW FRR. The PW FRR is a link and node protection
handover technology for L2 VPN services encapsulated on the basis 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 L2 VPN FRR
protects the active path by using the standby PW to evade the faulty link or node. The
PW FRR is used on H-VPLS UPEs. In full-mesh PW network, PW FRR is not required.
UPE1 connects to NPE2 and NPE3. The relationship between PW12 and PW13 is
redundant hot backup. The active and standby attributes are specified statically during
8-5

the network plan. Only one PW can forward services at any moment. For the network
structure, see Figure 8-3.
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, traffic if forwarded from CE1 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 triggered 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 the ZXR10
M6000 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

Figure 8-4 L3VPN FRR Network 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 Configuration Guide (VPN).
8.5 TE FRR Configuration

8.5.1 TE FRR Overview
Introduction
To ensure the reliability of the MPLS network, the MPLS Fast ReRoute (FRR) technology
plays an important role. Together with the traffic engineering capability of the MPLS, the
MPLS FRR provides the LSP with quick data protection and handover function. A local
backup path must be established in advance. In this way, the MPLS FRR protects the LSP
link from link fault or node fault. After a fault occurs, the data on the faulty link or device
will be handed over to the backup path to reduce the data loss.
The features of the MPLS FRR are rapid response and quick handover. The MPLS FRR
ensures the smooth handover of service data. At the same time, the head node of the
LSP tries to establish an LSP again with a new path and hands over the data to the new
path. Before a new LSP is established successfully, service data is transferred through
the protection path.
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 with this function.
In this way, traffic can go through the tunnel through the protecting link or node without
interruption. At the same time, the head node can initiate the re-establishment of the active
path without affecting data transmission.
8-7

TE FRR Modes
The MPLS TE FRR is implemented on the basis of RSVP TE. It complies with the Request
For Comments (RFC) 4090.
There are two modes to implement 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.
l Bypass mode: It is facility backup. In this mode, a protecting path protects several
LSPs. The protecting path is called Bypass LSP.
Detour mode implements the protection for each LSP. This costs relatively more. In
practical applications, the Bypass mode is widely used. The Bypass mode is described in
details.
Figure 8-5 shows the Bypass mode . 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. At the same
time, 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 path RTB - RTF - RTD, the LSP uses two layers of labels. When RTD receives a
packet, the label that is distributed for RTF by RTD pops up, and then the label that is
distributed for RTF by RTD forwards the packet.
Related Terms
l Active LSP: For the Detour LSP or the Bypass LSP, it acts as the protected LSP.
l 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.
l 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.
8-8

l 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.
l 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.5.2 TE FRR Work Flow

Figure 8-6 shows the FRR in Bypass mode.
Figure 8-6 FRR in Bypass Mode
The FRR in Bypass mode described here is implemented in accordance with RFC 4090
(called protocol hereinafter) by extending the SESSION_ATTRIBUTE object and the
RECORD_ROUTE object.
Active LSP Establishment

The method of establishing an active LSP is the same as that of a common LSP. 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.
8-9

l 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 protected by a bandwidth, and whether it is protected by a node.
The establishment of an active LSP is triggered by configuring a tunnel on the head
node (RT1) manually. Before the active LSP is established, 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
downstream nodes receive this PATH message, they know that it is an LSP requring FRR
by identifying the local protection flag.
For an LSP requring FRR (identified in accordance with the flags in the previous PATH
message), when the nodes send RESV messages to the upstream, they will record the
egress, LSR ID, and the label of an RESV message in RECORD_ROUTE object. The
information is cumulatively transmitted to each upstream node.
When each node receives the RESV message for the first time, it selects a suitable
Bypass LSP for the LSP in accordance with 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 described 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 used
to protect a physical interface, the LSP it corresponds to becomes the Bypass LSP.
The manual establishment of a Bypass LSP (tunnel12 on RT2) is triggered by the
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.
l 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
8-10

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 these active LSPs.
A Bypass LSP can protect multiple physical interfaces, but it cannot protect the egress of
its own.
The 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). In general, node protection can protect the protected node
and the link between this node and the PLR. It seems that node protection is better.
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 bandwidth of all LSPs to
be protected. Otherwise, when FRR is valid, Bypass cannot provide the protection that
meets the requirements of user services completely.
In general, 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” means to specify a Bypass LSP for a physical interface to be protected. This
is called the binding between a Bypass LSP and a physical interface. A Bypass LSP can
be bound to multiple physical interfaces, and a physical interface can also be bound to
multiple Bypass LSPs.
“Binding” also means to select a suitable Bypass LSP for an active LSP to be protected.
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. The binding results are the data
required for data handover, such as the interface of the Bypass tunnel, the egress and
Next Hop Label Forwarding Entry (NHLFE) of the Bypass LSP, and labels allocated to the
MP. If the binding calculation is successful, the RESV will inform the upstream nodes that
the active LSP has been protected.
The result of the binding calculation includes the following items:

l Protection type (it is link-type protection or node-type protection) and LSR ID of the
MP.
l The label distributed by the MP to the previous hop (This label corresponds to the
label of the MP LSR ID in RECORD_ROUTE object of the active LSP.).
l 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.
8-11

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.
Invalidation detection does not determine 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 in accordance with
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 in accordance with 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 flush messages 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 in
accordance with the following points:
8-12

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.
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 in accordance with 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, and 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 for 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 expiry 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
8-13

the new path is established, a new suitable standby LSP will be selected to form the new
binding relationship.
Data Forwarding
Before the handover of the active LSP, the data forwarding on the active LSP is the same
with that on a common LSP. After the data of the active LSP is handed over to the Bypass
tunnel, the data is forwarded to the MP through the Bypass LSP.
8.5.3 Configuring TE FRR

For the principle and configuration of TE FRR, refer to related topics in the ZXR10 M6000
Carrier-Class Router Configuration Guide (MPLS).
8-14

Chapter 9
Graceful Restart
Configuration
Table of Contents
IP Graceful Restart Configuration ...............................................................................9-1
LDP Graceful Restart Configuration ...........................................................................9-3
9.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 Applying IP GR in OSPF
l Applying IP GR in IS-IS
l 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.
9-1

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 Prevent the neighbor relationship between the neighbor routers and the restarted
router from being oscillated during the restart period.
l 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.
l 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
9-2

Chapter 9 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 Configuration Guide (IPv4 Route).
9.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.
l 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
9-3

two LSRs save the control information of the LDP protocol, so they can be considered
as the auxiliary node.
l 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.
l 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.
9-4

Chapter 9 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 9-1.
Figure 9-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 Configuration Guide (MPLS).
9-5

9-6

Chapter 10
Master/Slave Main Control
Handover
Table of Contents
Master/Slave Plane Handover Overview ..................................................................10-1
Configuring Master/Slave Main-control Handover.....................................................10-2
Maintaining Master/Slave Main-control Handover.....................................................10-2
Master/Slave Main-control Handover Configuration Example ...................................10-6
10.1 Master/Slave Plane 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.
10-1

Therefore, it is necessary to use a mate board scan thread to scan the state of the mate
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.
10.2 Configuring Master/Slave Main-control Handover

Master/slave handover includes command master/slave handover, plugging out and
plugging in the master main-control board, pressing EXCH button to change over,
enabling the master main-control board by pressing the reset button, changing over to
the slave main-control board when a fault occurs on the master main-control board.
To configure master/slave main-control handover on the ZXR10 M6000, run the following
commands:
Command Function
ZXR10#redundancy switch sc force [<Line>] Implements a compulsive handover.
ZXR10#redundancy switch sc grace [<Line>] Implements a graceful handover.
All master/slave handover can be classified into compulsive handover or graceful

handover.
l Compulsive handover: Including the handover caused by executing the command
with the force keyword, plugging out and plugging in the master main-control board,
pressing the reset button, or the master main-control board has a fault.
l Graceful handover: Including the handover caused by executing the command with
the grace keyword and pressing the EXCH button.
The differences between a compulsive handover and a graceful handover are described
below.
l For a compulsive handover, the system does not check whether the conditions to
perform handover are met. No matter which state the board is in at present, the
handover is accomplished by resetting the master main-control board.
l For a graceful handover, the system checks whether the conditions to perform
handover are met, such as 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.
10.3 Maintaining Master/Slave Main-control Handover

The prerequisites to execute master/slave handover correctly are that the master and the
slave main-control boards are online and are working properly, and the synchronization
of the master and the slave database is completed. Therefore, before the master/slave
10-2

Chapter 10 Master/Slave Main Control Handover
handover, run the following commands to check whether the master and the slave
main-control boards are online, and whether the synchronization of the master and the
slave database is completed.
Commands Function
ZXR10#show processor Checks whether the master and the slave

main-control boards are online.
ZXR10#show synchronization Checks whether the synchronization of the master

and the slave database is completed.
The following is sample output from the show processor command:

/*Example 1:*/
ZXR10#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 utility measured in 5 seconds
CPU(1m) : Cpu utility measured in 1 minute
CPU(5m) : Cpu utility measured in 5 minutes
Peak : Cpu peak utility 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/0/0 N/A 11% 11% 10% 15% 2048 781 61.865%
--------------------------------------------------------------------------------
SFU-0/8/0 N/A 18% 19% 18% 21% 256 58 77.344%
--------------------------------------------------------------------------------
MPU-0/12/0 MSC 16% 16% 16% 21% 4096 1759 57.056%
--------------------------------------------------------------------------------
ESU-0/12/0 N/A 33% 33% 33% 37% 256 42 83.594%
--------------------------------------------------------------------------------
ADU-0/13/0 N/A 12% 12% 12% 28% 256 101 60.547%
--------------------------------------------------------------------------------
ZXR10#
/* Backup main-control board.
At this time, the handover cannot be
10-3

executed. If the handover is executed compulsively, the entire device will be reset.*/
/*Example 2:*/
ZXR10#show processor
================================================================================
================================================================================
================================================================================
================================================================================
================================================================================
PFU-0/2/0 N/A 8% 8% 10% 11% 2048 956 53.320%
--------------------------------------------------------------------------------
PFU-0/3/0 N/A 9% 9% 10% 11% 2048 963 52.979%
--------------------------------------------------------------------------------
SFU-0/17/0 N/A 20% 20% 20% 21% 256 87 66.016%
--------------------------------------------------------------------------------
MPU-0/20/0 MSC 18% 17% 22% 20% 4098 2120 48.267%
--------------------------------------------------------------------------------
ESU-0/20/0 N/A 35% 35% 35% 38% 256 103 59.766%
--------------------------------------------------------------------------------
MPU-0/21/0 SSC 11% 12% 12% 15% 4098 2432 40.654%
--------------------------------------------------------------------------------
ESU-0/21/0 N/A 15% 35% 35% 38% 256 53 79.766%
--------------------------------------------------------------------------------
/*The character of MPU-0/12/0 is displayed as an MSC. This means that it is the
master main-control board at present. The character of MPU-0/21/0
is displayed as an SSC. This means that it is the slave main-control board at
present.*/
The following is sample output from the show synchronization command:

/*Example 1:*/
ZXR10#show synchronization
=====================================================================
10-4

LE Location Status Syn-state

=====================================================================
T_MPLS MPU-0/20/0 Master no peer
---------------------------------------------------------------------
T_SC MPU-0/20/0 Master no peer
---------------------------------------------------------------------
/*The slave main-control board of the device is not online.*/
/*Example 2:*/
=====================================================================
=====================================================================
T_MPLS MPU-0/20/0 Slave not finish
---------------------------------------------------------------------
T_SC MPU-0/20/0 Slave not finish
---------------------------------------------------------------------
T_MPLS MPU-0/21/0 Master not finish
---------------------------------------------------------------------
T_SC MPU-0/21/0 Master not finish
/*The slave main-control board of the device is online, but the synchronization
is not completed.*/
/*Example 3:*/
=====================================================================
=====================================================================
T_MPLS MPU-0/20/0 Slave finish
---------------------------------------------------------------------
T_SC MPU-0/20/0 Slave finish
---------------------------------------------------------------------
T_MPLS MPU-0/21/0 Master finish
---------------------------------------------------------------------
T_SC MPU-0/21/0 Master finish
---------------------------------------------------------------------
/*The synchronization is completed. The handover can be executed.*/
10-5

10.4 Master/Slave Main-control Handover Configuration

Example
Three devices operate properly at first. After a period, R2 implements master/slave
handover. For the network structure, see Figure 10-1.
Figure 10-1 Master/Slave Main-control Handover
Configuration Flow
1. When the device operates 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 the master and slave main-control boards flashes at the frequency of 1
Hz, and 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.
To configure master/slave main-control handover, run the following commands:
ZXR10#redundancy switch sc grace
Proceed with redundancy switch sc? [yes/no]:yes
Check the configuration result, which is displayed as follows:
/*Before the handover*/
R2#show processor
================================================================================
================================================================================
10-6


================================================================================
================================================================================
================================================================================
PFU-0/2/0 N/A 8% 8% 10% 11% 2048 956 53.320%
--------------------------------------------------------------------------------
PFU-0/3/0 N/A 9% 9% 10% 11% 2048 963 52.979%
--------------------------------------------------------------------------------
SFU-0/17/0 N/A 20% 20% 20% 21% 256 87 66.016%
--------------------------------------------------------------------------------
MPU-0/20/0 MSC 18% 17% 22% 20% 4098 2120 48.267%
--------------------------------------------------------------------------------
ESU-0/20/0 N/A 35% 35% 35% 38% 256 103 59.766%
--------------------------------------------------------------------------------
MPU-0/21/0 SSC 11% 12% 12% 15% 4098 2432 40.654%
--------------------------------------------------------------------------------
ESU-0/21/0 N/A 10% 35% 35% 38% 256 103 59.766%
--------------------------------------------------------------------------------
/*When the character of MPU-0/20/0 is displayed as an MSC, it means that it is the
master main-control board at present. When the character of MPU-0/21/0 is displayed
as an SSC, it means that it is the slave main-control board at present. The
main-control board is in Slot 20.*/
/*After the handover*/

R2#show processor
================================================================================
================================================================================
================================================================================
10-7

================================================================================
================================================================================
PFU-0/2/0 N/A 8% 11% 9% 94% 2048 956 53.320%
--------------------------------------------------------------------------------
PFU-0/3/0 N/A 9% 11% 9% 93% 2048 963 52.979%
--------------------------------------------------------------------------------
SFU-0/17/0 N/A 22% 21% 20% 61% 256 87 66.016%
--------------------------------------------------------------------------------
MPU-0/20/0 SSC 40% 67% 67% 100% 4098 2436 40.556%
--------------------------------------------------------------------------------
ESU-0/20/0 N/A 35% 36% 36% 96% 256 103 59.766%
--------------------------------------------------------------------------------
MPU-0/21/0 MSC 100% 100% 36% 100% 4098 2130 48.023%
--------------------------------------------------------------------------------
ESU-0/21/0 N/A 10% 35% 35% 38% 256 103 59.766%
--------------------------------------------------------------------------------
/*When the character of MPU-0/20/0 is displayed as an SSC, it means that it is the
master slave control board at present. When the character of MPU-0/21/0 is displayed
as an MSC, it means that it is the master main-control board at present. After the
handover, the main board in Slot 21 becomes master, and the main-control board in
Slot 0 becomes slave.*/
10-8

Chapter 11
Load Sharing Configuration
Table of Contents
Load Sharing Overview ............................................................................................11-1
Configuring the Load Sharing ...................................................................................11-1
Configuring Multicast Load Sharing ..........................................................................11-2
Configuring MPLS VPN Load Sharing ......................................................................11-2
11.1 Load Sharing Overview

The load sharing supported by the ZXR10 M6000 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 LDP
l VRF
l 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.
11.2 Configuring the 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
Configuration Guide (IPv4 Routing).
11-1

11.3 Configuring Multicast Load Sharing

For the principle and configuration commands of the multicast load sharing, refer to related
topics in the ZXR10 M6000 Configuration Guide (IPv4 Multicast).
11.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 Configuration Guide (VPN).
11-2

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-9
Figure 2-4 Link between CFM and VRRP ............................................................... 2-13
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-13
Figure 3-12 Symmetrical VRRP Configuration (IPv4) .............................................. 3-16
Figure 3-13 VRRP Heartbeat Configuration (IPv4) .................................................. 3-18
Figure 3-14 VRRP Track Configuration (IPv4)......................................................... 3-20
Figure 4-1 Application Overview of Ping Detect ........................................................ 4-1
Figure 4-2 Network Structure of Basic Ping Detect Configuration Example .............. 4-4
Figure 4-3 Cooperation Configuration Between a Directly-Connected Route and
the Ping Detect ....................................................................................... 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-11
Figure 6-1 Maintenance Domain ............................................................................... 6-2
Figure 6-2 CFM Connection Establishment............................................................... 6-7
Figure 6-3 Cross-L2 VPN Connectivity Detection .................................................... 6-10
Figure 7-1 IS-IS BFD Configuration Example ............................................................ 7-7
Figure 7-2 OSPF BFD Configuration Example .......................................................... 7-9
Figure 7-3 BGP Single-Hop BFD Configuration Example ........................................ 7-10
Figure 7-4 BGP Multi-Hop BFD Configuration Example .......................................... 7-12

Figure 7-5 Static Route BFD Configuration Example............................................... 7-14

Figure 7-6 LDP BFD Configuration Example ........................................................... 7-16
Figure 7-7 Static Single-Hop BFD Configuration Example....................................... 7-18
Figure 7-8 Static Multi-Hop BFD Configuration Example ......................................... 7-20
Figure 7-9 Configuring BFD on RSVP Interface ...................................................... 7-24
Figure 7-10 RSVP LSP BFD Configuration Example............................................... 7-26
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 Network Structure................................................................ 8-7
Figure 8-5 FRR Though Bypass Mode...................................................................... 8-8
Figure 8-6 FRR in Bypass Mode ............................................................................... 8-9
Figure 9-1 Network Architecture of LDP Graceful Restart Configuration.................... 9-5
Figure 10-1 Master/Slave Main-control Handover ................................................... 10-6
II

Glossary
3G
- The 3rd Generation Mobile Communications
AC
- Access Circuit
APS
- Automatic Protection Switching
ARP
- Address Resolution Protocol
BFD
- Bidirectional Forwarding Detection
BGP
- Border Gateway Protocol
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
IGP
- Interior Gateway Protocol
IP
- Internet Protocol
IPTV
- Internet Protocol Television
III

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
- Medium 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
OAM
- Operation, Administration and Maintenance
IV

Glossary
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
RMEP
- Remote Maintenance association End Point
RSVP
- Resource ReSerVation Protocol
SPF
- Shortest Path First
TCP
- Transmission Control Protocol
TTL
- Time To Live
UDP
- User Datagram Protocol
VLAN
- Virtual Local Area Network
VPN
- Virtual Private Network
VRRP
- Virtual Router Redundancy Protocol
VoIP
- Voice over Internet Protocol
WAN
- Wide Area Network

SJ-20130205142913-019-ZXR10 M6000 (V1.00.60) Carrier-Class Router Configuration Guide (Reliability) PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SJ-20130205142913-019-ZXR10 M6000 (V1.00.60) Carrier-Class Router Configuration Guide (Reliability) PDF

Загружено:

Авторское право:

Доступные форматы

ZXR10 M6000

Revision No. Revision Date Revision Reason

R2.2 2013-02-28 Fourth edition, adding the "Cooperation Configuration Example

R2.0 2012-07-20 Third edition

R1.1 2012-03-30 Second edition

R1.0 2011-12-10 First edition

Serial Number: SJ-20130205142913-019

Publishing Date: 2013-02-28 (R2.2)

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

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

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

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

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

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

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

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

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Chapter 9 Graceful Restart Configuration ............................................... 9-1

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

Chapter 11 Load Sharing Configuration................................................. 11-1

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

What Is in This Manual

2, Service Availability Describes the principle, configuration commands, maintenance

3, VRRP Configuration Describes the principle, configuration commands, maintenance

4, Ping Detect Configuration Describes the principle, configuration commands, maintenance

5, EFM Configuration Describes the principle, configuration commands, maintenance

6, CFM Configuration Describes the principle, configuration commands, maintenance

7, BFD Configuration Describes the principle, configuration commands, maintenance

8, FRR Configuration Describes the principle, configuration commands, maintenance

9, Graceful Restart Describes the principle, configuration commands, maintenance

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

11, Load Sharing Describes the principle, configuration commands, maintenance

| Separates individual parameter in series of parameters.

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

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

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

Note: provides additional information about a certain topic.

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Network Fault Detection Technology

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

Protection Switching Technology

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

2.1 SAMGR Overview

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Linkage Among VRRP, SAMGR, EOAM and BFD

Figure 2-1 Linkage Among VRRP, SAMGR, EOAM and BFD

The network structure descriptions are as follows:

Linkage of Symmetrical Dual-Connection Between CE and PE

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Figure 2-2 Linkage of Symmetrical Dual-Connection Between CE and PE

The network structure descriptions are as follows:

If a fault occurs on the AC between CE1 and PE–1,

If a fault occurs on a PW,

SJ-20130205142913-019|2013-02-28 (R2.2) ZTE Proprietary and Confidential

2.2 SAMGR Configuration

Step Command Function

1 ZXR10(config)#samgr Enters SAMGR configuration mode.

3 ZXR10(config-samgr)#track <name> cfm md Configures a track object with detection type

4 ZXR10(config-samgr)#track <name> ping-detect Configures a track object with detection type

6 ZXR10(config-samgr)#track <name> mpls-oam Configures a track object with detection type

9 ZXR10(config-samgr)#track <name> ldp-bfd Configures a track object with detection type