ZXCTN 9000 MML Configuration Guide (Raliability) V2.08.32 en

ZXCTN 9002/9004/9008
Packet Transport Network Product
MML Configuration Guide ((Raliability))

Version: 2.08.32
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 2011 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 Data
Revision Reason
R1.0
20110730
ZXCTN 9002/9004/9008(V2.08.32) first version issued
Serial Number: SJ-20100901100356-020

Publishing Date: 2011-07-30(R1.0)
About This Manual

Purpose
This manual describes the working principles, configuration commands, and configuration
examples of reliability functions as well as relevant fault handling.
What Is in This Manual

This manual contains the following chapters:
Chapter
Summary
Chapter 1, Safety
Describes safety instructions and signs.
Instructions
Chapter 2, Service
Describes the working principles, configuration commands,
Reliability Management
maintenance commands, and configuration examples of the service
Configuration
reliability manager, as well as the steps for handling common service

reliability manager faults.
Chapter 3, VRRP
Configuration
maintenance commands, and configuration examples of VRRP, as well

as the steps for handling common VRRP faults.
Chapter 4, EFM
Configuration
maintenance commands, and configuration examples of EFM, as well

as the steps for handling common EFM faults.
Chapter 5, CFM
Configuration

maintenance commands, and configuration examples of CFM, as well
as the steps for handling common CFM faults.
Chapter 6, BFD
Configuration
maintenance commands, and configuration examples of BFD, as well

as the steps for handling common BFD faults.
Chapter 7, FRR
Configuration

maintenance commands, and configuration examples of FRR, as well
as the steps for handling common FRR faults.
Chapter 8, IP Graceful
Restart Configuration
maintenance commands, and configuration examples of IP Graceful

Restart, as well as the steps for handling common IP Graceful Restart
faults.
Chapter 9, Load Sharing
Configuration
maintenance commands, and configuration examples of load sharing,

as well as the steps for handling common load sharing faults.
Chapter
Summary
Chapter 10, Tunnel
Protection Group
maintenance commands, and configuration examples of tunnel
Configuration
protection groups, as well as the steps for handling common tunnel

protection group faults.
Chapter 11, MSP
Configuration
maintenance commands, and configuration examples of MSP, as well

as the steps for handling common MSP faults.
Chapter 12, MPLS-TP

OAM Configuration

maintenance commands, and configuration examples of MPLS-TP
OAM, as well as the steps for handling common MPLS-TP OAM faults.
Chapter 13,
Active/Standby Switchover
maintenance commands, and configuration examples of active/standby
Configuration
switchover, as well as the steps for handling common active/standby

switchover faults.
Chapter 14, mcLag
Configuration
maintenance commands, and configuration examples of mcLag, as well

as the steps for handling common mcLag faults.
Intended Audience
This manual is intended for the following engineers:
l
l
l
Network planning engineer

Commissioning engineer
On-duty personnel
Conventions
ZTE documents employ the following typographical conventions.
Typeface
Meaning
Italics
Variables in commands. It may also refers 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.
CAPS
Keys on the keyboard and buttons on screens and company name.
Constant
Text that you type, program codes, filenames, directory names, function names.
width
[]
Optional parameters.
{}
Mandatory parameters.
II
Typeface
Meaning
Separates individual parameter in series of parameters.
Danger: Indicates an imminently hazardous situation, which if not avoided, will result in
death or serious injury.
Warning: Indicates a hazard that, if not avoided, could result in serious injuries,
equipment damages or interruptions of major services.
Caution: Indicates a potential hazard that, if not avoided, could result in moderate
injuries, equipment damages or partial service interruption.
Note: Provides additional information about a certain topic.
Checkpoint: Indicates that a particular step needs to be checked before proceeding

further.
Tip: Indicates a suggestion or hint to make things easier or more productive for the
reader.
Auxiliary Function
Command help function of ZXCTN9000 devices has the following features:
1. By entering a question mark (?) following DOS prompt in any command mode, a list of
available commands in this command mode are displayed. With the context-sensitive
help function, the keywords and parameter list of any commands can be displayed.
l By entering a question mark "?" following DOS prompt in any command mode,
a list of all commands in this mode and brief description of these commands are
displayed.
l Input the question mark following a character or a character string, a list of
commands or keywords beginning with this character or character string is
displayed. Note that there is no space between the character (string) and the
question mark.
l Press Tab key following the character string. If the command or keyword
beginning with this character string is unique, complement the command or
keyword and attach a space to the end. Note that there is no space between the
character string and the Tab key.
l Input a question mark (?) following the command, keyword or parameter. The
next keyword or parameter to be entered is listed, and also a brief description is
given. A space shall be entered before the question mark.
2. If incorrect command, keyword or parameter is entered, the error isolation is offered
with ^ in the user interface after you press Enter key. Character ^ locates below the
first character of the entered incorrect command, keyword or parameter.
III
3. The system allows the command or keyword to be abbreviated to a character or

character string that uniquely identifies this command or keyword. For example, show
command can be abbreviated to sh or sho.
4. User interface supports the function of recording input commands. Maximum ten
history commands can be recorded. This function is very useful in re-invocation of
a long or complicated command or ingress.
To re-invoke a command from the record buffer, conduct one of the following
operations.
Command
Function
Press Ctrl-P or the up arrow
It re-invokes the latest commands in the record buffer. Repress
key
these keys to invoke old commands forwards.
Press Ctrl-N or down arrow
Roll commands downwards. When the last command line is
key
reached, one more operation will roll the commands from the
beginning of the buffer cyclically.
Use show history command in any mode, and the latest several commands in this
mode will be listed.
IV
Chapter 1
Safety Instructions
Table of Contents
Safety Instructions......................................................................................................1-1
Safety Signs ...............................................................................................................1-1
1.1 Safety Instructions

Only trained and qualified professionals are allowed to install, operate and maintain the
equipment.
Abide by local safety codes and related operation procedures during equipment
installation, operation and maintenance. Otherwise, personal injuries or equipment
damage may be caused. The safety precautions mentioned in this manual are only a
supplement to local safety codes.
Running debug commands given in this manual can severely affect equipment
performance. Therefore, do not run these commands unless really necessary. In
particular, all debugging processes will be started if a debug command is run. Do not run
debug commands for devices on which services are running. It is not recommended that
debug commands be run when the network is normal.
ZTE Corporation shall not bear any liabilities for consequences resulting from the violation
of general specifications for safety operations or the violation of safety rules for design,
production and use of equipment.
1.2 Safety Signs

The safety signs to alert users during equipment installation, operation, and maintenance
are highlighted in the following two formats in this manual.
Warning!
Indicates a hazardous situation, which if not avoided, could result in death, serious injury,
or damage to equipment.
1-1
SJ-20100901100356-020|2011-07-30(R1.0)
ZTE Proprietary and Confidential
ZXCTN 9002/9004/9008 MML Configuration Guide ((Raliability))
Caution!
Indicates a hazardous situation, which if not avoided, could result in minor or moderate
injury, or damage to equipment.
Strictly follow relevant instructions during operation.
1-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 2
Service Availability Manager

Configuration
Table of Contents
Overview of the Service Availability Manager .............................................................2-1
Working Principles of the Service Availability Manager ...............................................2-2
Configuring Service Availability Manager....................................................................2-5
Maintaining the Service Availability Manager ..............................................................2-7
Service Availability Manager Instances.......................................................................2-8
Service Availability Manager Troubleshooting...........................................................2-15
2.1 Overview of the Service Availability Manager

Value-added services are widely applied in the Internet along with rocketing development
of the IP technology. The newly-emerging carrier-class services, such as NGN/3G, IPTV
streaming media, private line, and VPN interconnection, all pose very high requirements
on the reliability of IP telecommunication networks. The IP network reliability requirements
of carrier-class services cover the following three aspects:
l
l
l
Device reliability
Link reliability
Network reliability
In the bearer network, the availability of network devices must be up to 99.999%, which is
equivalent to a cumulative downtime less than five minutes due to various reasons during
the continuous running of network devices in a year. High reliability is a basic requirement
for carrier-class equipment as well as a basis for telecommunication operators to construct
networks. The bearer network is a basic network for bearing services, so its reliability is
increasingly attracting eyes.
The key reliability technologies used on ZXCTN9000 include device hardware redundancy
and network reliability. This section focuses on network reliability technologies.
Network reliability technologies include network fault detection and protection switching.
Network fault detection technologies are classified as follows according to the network
hierarchy:
l
l
l
l
Transport layer/Physical layer: APS

Link layer: BFD, MPLS OAM, and Eth-OAM
Network layer: Protocol hello mechanism, VRRP, and BFD
Application layer: Heartbeat of various application layer protocols
2-1
SJ-20100901100356-020|2011-07-30(R1.0)
Protection switching technologies:

l
l
End-to-end protection: 1:1, 1+1, 1:N, M:N tunnel protection switching, MC-LAG,
MC-APS, MVLAN, and hot standby
Local protection: FRR, including IP-FRR, LDP-FRR, TE-FRR, and PW-FRR
The service availability manager is used to manage the relations between services and
service availability. It provides a variety of functions, including track object management,
track group management, OAM binding, and OAM mapping. It implements interactions
between services and detection technologies, ensuring that traffic can be quickly switched
over when a network link fails.
2.2 Working Principles of the Service Availability

Manager
Working Principles
In practice, ZXCTN 9000 supports multiple detection technologies. This, however, gives
rise to a necessity for protection switching applications to monitor the real-time detection
results, so as to meet different reliability requirements of different network topologies.
Therefore, the concept of a service availability manager is introduced to implement
interactions between detection technologies and services.
The service availability manager isolates detection technologies from services, and
reduces coupling between modules. It abstracts a certain detection instance into a track
object. A track object is associated with a certain detection instance using a track name
during the configuration of the track object. Then the track name is directly invoked for
the service whose detection results are to be monitored. When a detection technology
discovers link status changes, it directly notifies the status changes to the service
availability manager, so that the service availability manager notifies the application
service associated with the track object. Then the application service performs status
switching according to the status changes to implement link protection and attain service
availability. In addition, the service availability manager can manage bindings between
track objects and can transmit the local status to the remote peer to implement failure
information transfer and failure restoration.
Network Topology
1. Figure 2-1 shows how the VRRP, service availability manager, EOAM, and BFD
interact with one another.
2-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 2 Service Availability Manager Configuration
Figure 2-1 Interactions Between VRRP, Service Availability Manager, EOAM, and
BFD
The network topology is described as follows:

a. The EOAM detection function is enabled between PB and P, and between PA and
PD to keep links alive. In addition, the BFD function is enabled between PA and
PB.
b. PA and PB form an active/standby relation. They monitor the status of EOAM and
BFD respectively.
c.
The VRRP protocol runs on the direct connection interfaces of PA, PB, and PC,
so that the three nodes form a VRRP group.
d. EOAM detection results and BFD detection results are monitored in real time in
VRRP services to provide reliability guarantee for the VRRP.
When the EOAM mechanism detects a failure, it first reports the failure to the service
availability manager. The service availability manager checks the relations between
track objects and services, and then sends a notification message to the corresponding
service, instructing the service to perform status switching.
When the peer BFD on ZXCTN9000 fails, the service availability manager sends a
status notification message to the service. The service performs switching based on
its policy according to the EOAM status and the BFD status.
2. As shown in Figure 2-2, each CE is symmetrically dual-homed to two PE devices to
implement status interactions between detection technologies.
2-3
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 2-2 Status Interactions of CE Devices Dual-Homed to PE Devices
The network topology is described as follows:

a. PE-1 establishes a PW with PE-3, and so does PE-2 with PE-4.
b. CE1 is dual-homed to PE-1 and PE-2.
c.
CE2 is dual-homed to PE-3 and PE-4.
d. OAM detection is enabled between a CE and a PE (EFM/CFM/Link keepalive).

e. PW detection is implemented via BFD between PE devices, and TE LSP detection
is implemented via MPLS OAM between PE devices.
f.
A mapping/binding relation is established between AC-side link detection and PW

link detection or LDP to facilitate fault information transmission.
Principles of failure detection and switching: Assume the AC between CE1 and PE1
fails.
a. The AC EOAM mechanism on PE1 detects the AC failure, and then notifies the
service availability manager of the AC failure.
b. The service availability manager on PE1 maps the detection track object for the
PW corresponding to AC according to the OAM mapping/binding relation.
c.
If failure detection is implemented via BFD or MPLS-OAM between PE devices,

the OAM failure notification message is transparently transmitted to PE2.
d. PE3 receives the BFD/MPLS OAM/LDP failure notification message. If there is a

protection PW on the remote PE, traffic switching is performed. Otherwise, OAM
mapping/binding is performed to map the AC and notify the failure to CE2.
Principles of failure detection and switching: Assume a PW fails.
a. The BFD/MPLS OAM mechanism on a PE device detects a PW/LSP failure.
b. The PE performs OAM mapping/binding to map the local AC.
c.
If there is a protection PW on the PE, traffic switching is performed. Otherwise,

OAM mapping/binding is performed to map the AC and notify the failure to the
local CE.
2-4
SJ-20100901100356-020|2011-07-30(R1.0)
2.3 Configuring Service Availability Manager

2.3.1 Configuring Track Session Objects
Use the following commands on ZXCTN 9000 to configure track session objects:
Step
Command
Function
ZXCTN9000#track-session < name>
Configures a track session object, and enters

the track configuration mode
ZXCTN9000(config-track)#detect interface
Configures a track session object of the
smartgroup< 1-32>
smartgroup port detection type
ZXCTN9000(config-track)#detect cfm < md>
Configures a track session object of the CFM
< ma> < mep>
detection type
ZXCTN9000(config-track)#detect link-bfd <
Configures a track session object of the link
local-ipv4-address> < remote-ipv4-address > [
BDF detection type
vrf < vrfname> ]

5
ZXCTN9000(config-track)#detect lsp-bfd {
Configures a track session object of the LSP
ldp-lsp < fec-address > < prefixlen> | rsvp-lsp
BDF detection type
< tunnel-id> }
6
ZXCTN9000(config-track)#detect pw-bfd <
Configures a track session object of the PW
peer-id> < vcid>
BDF detection type
ZXCTN9000(config-track)#detect tunnel-bfd
< tunnel-id>
static tunnel BFD detection type
ZXCTN9000(config-track)#detect tmpls-oam
{ tmc| tmp| tms} < meg-index>
TMPLS OAM detection type
The command parameter in step 1 is described as follows:

Parameter
Description
< name>
Name of the track session object to be configured,

which is a string of 1 to 64 characters

Parameter
Description
< 1-32>
Smart group port number
The command parameters in step 3 are described as follows:

Parameter
Description
< md>
CFM MD index in the range of 1 to 32
< ma>
CFM MA index in the range of 1 to 32

2-5
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< mep>
ID of the local MEP in the range of 1 to 8191

Parameter
Description
< local-ipv4-address>
Local IPv4 address of link BFD
< remote-ipv4-address>
Remote IPv4 address of link BFD
< vrfname>
VRF name, which is a string of 1 to 32 characters

Parameter
Description
< fec-address>
FEC address
< prefixlen>
Mask length in the range of 1 to 32
< tunnel-id>
Tunnel ID in the range of 1 to 8192

Parameter
Description
< peer-id>
Peer address of the PW
< vcid>
VC ID of the PW in the range of 1 to 4294967294

Parameter
Description
< tunnel-id>
Tunnel ID in the range of 1 to 8192

Parameter
Description
< meg-index>
MEG index of TMPLS OAM in the range of 1 to

65535
2.3.2 Configuring VRRP Binding

Use the following commands on ZXCTN 9000 to configure the bindings:
Step
Command
Function
ZXCTN9000(config)#interface < vlan-id>
Enters the VRRP interface mode
ZXCTN9000(config-if-vlanX)#vrrp < group
Configures the binding between a track
> track session < name> switch
session object and the VRRP protocol

2-6
SJ-20100901100356-020|2011-07-30(R1.0)

Parameter
Description
< group>
ID of the virtual ZXCTN9000, ranging from 1 to

255
< name>
Name of the track session object to be bound,

which is a string of 1 to 64 characters
2.4 Maintaining the Service Availability Manager

Use the following commands on ZXCTN 9000 to maintain the service availability manager:
Command
Function
ZXCTN9000(config)#show oam-track session all
Shows information about all the configured track

session objects
ZXCTN9000(config)#show oam-track session <
Shows information about the specified track
name>
session object
ZXCTN9000(config)#show vrrp [ < group> ]
Shows information about the specified VRRP

group
The following example shows the outputs of the show oam-track session all command.
ZXCTN9000(config)#show oam-track session all
session name: link-bfd
detect type: LINK BFD
local address 10.1.1.1, peer address 10.1.1.2
session name: cfm
detect type: CFM
md 1, ma 2, mep id 109
The following example shows the outputs of the show oam-track session command.
ZXCTN9000(config)#show oam-track session cfm
session name: cfm
detect type: CFM
The command outputs are described as follows:

Output Item
Description
session name
Name of the track session object
detect type
Detection type for the track session object
The following example shows the outputs of the show vrrp command.
ZXCTN9000#show vrrp
2-7
SJ-20100901100356-020|2011-07-30(R1.0)

vlan100 - Group 1
State is Init
Connection interface is vlan100
Admin none, VGMP none
Virtual IP address is 100.1.1.254
Virtual MAC address is 0000.5e00.0101
Backup route is disabled
Advertisement interval config is 1.000 sec, TTL check
Preemption is enabled, min delay is 0.000 sec
Priority is 150 (config 150)
Authentication is disabled
Track object session cfm switch (up)
Master router is 0.0.0.0, priority is 0
Master advertisement interval is 0.000 sec
Master down interval is 3.414 sec

Output Item
Description
track object session
Name of the bound track session object
2.5 Service Availability Manager Instances

2.5.1 LINK BFD Interacting with VRRP
Configuration Description
The VRRP protocol runs between P2 and P3, as shown in Figure 2-3. The interface
address 10.0.0.1 of P2 is used as the VRRP virtual address, and P2 is the master.
Figure 2-3 LINK BFD Interacting with VRRP
2-8
SJ-20100901100356-020|2011-07-30(R1.0)
Configuration Method
1. Enable the link BFD heartbeat detection function on the direct connection interfaces
of P2 and P3.
2. Configure a track session object on P3, and specify the detection type as LINK BFD.
3. Configure the same VRRP group number and virtual address on P2 and P3. To enable
P2 to become the master, use the interface address 10.0.0.1 of P2 as the VRRP virtual
address, or ensure the priority of the VRRP group on P2 is higher than the priority of
the VRRP group on P3.
4. Bind VRRP to the track session object of link BFD on P3.
5. Shut down the interface gei_3/2 on P2. The status of the VRRP group on P3 changes
to Master. Restore the interface gei_3/2 on P2. The status of the VRRP group on P3
changes to Backup.
Configuration Procedure
Run the following configuration commands on P2:
P2(config)#interface loopback1
P2(config-loopback1)ip add 1.1.1.1 255.255.255.255
P2(config)#vlan 10
P2(config-vlan10)#switchport pvid gei_2/1
P2(config)#interface vlan 10
P2(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
P2(config-if-vlan10)#exit
P2(config)#vlan 20
P2(config-vlan20)#switchport trunk gei_3/2
P2(config)#ip static-bfd 1.1.1.1 2.2.2.2
P2(config)#bfd session bfd11
P2(config)#bind link-bfd peer-ip 11.0.0.2 interface vlan20
P2(config)#discriminator-local 51
P2(config)#discriminator-remote 31
P2(config)#detect-multiplier 3
P2(config)#min-tx-interval 3
P2(config)#min-rx-interval 3
P2(config-if-vlan20)#bfd interval 3 min-rx 3 multiplier 3
P2(config-if-vlan10)#vrrp 1 ip address 10.0.0.1
P2(config-if-vlan10)#vrrp 1 priority 150
P2(config-if-vlan10)#vrrp 1 out-interface vlan 20
P2(config)#
2-9
SJ-20100901100356-020|2011-07-30(R1.0)

P3(config-loopback1)ip add 2.2.2.2 255.255.255.255
P3(config)#vlan 10
P3(config)#vlan 20
P3(config)#bfd session bfd11
P3(config)#bind link-bfd peer-ip 11.0.0.1 interface vlan20
P3(config)#discriminator-local 31
P3(config)#discriminator-remote 51
P3(config)#detect-multiplier 3
P3(config)#min-tx-interval 3
P3(config)#min-rx-interval 3
P3(config)#track-session link-bfd
P3(config-track)#detect
bfd-session
31 51
P3(config)#exit
P3(config-if-vlan10)#vrrp 1 track session link-bfd switch
P3(config)#
Configuration Verification
Check the configurations and validity of VRRP on P2 and P3. P2 is the master device
whereas P3 is the backup device. Run the show oam-track session command on P3. The
track session object of link BFD has been created. Then run the show vrrp command on
P3. The track session object of link BFD has been bound to the VRRP group.
P2#show vrrp b
Interface
vlan10
Grp
Pri
255
VGMP Admin
0
none
Own
Y
Pr State
Y
Master
Master-addr
10.0.0.1
Group-addr
10.0.0.1
2-10
SJ-20100901100356-020|2011-07-30(R1.0)

P3#show vrrp b
Interface
Grp
Pri
VGMP Admin
80
vlan10
Own
none
Pr State
Y
Backup
Master-addr
10.0.0.1
Group-addr
10.0.0.1
P3#show oam-track session link-bfd

session name: link-bfd
detect type: LINK BFD
local address 11.0.0.2, peer address 11.0.0.1
session name: 11
detect type: BFD SESSION
bfd-session ld 51 rd 31
P3(config)#show vrrp 1
vlan100 - Group 1
State is Backup
Track object session link-bfd switch (up)
When the interface gei_3/2 on P2 is shut down, P3 becomes the master device.
P3#show vrrp b
Interface Grp Pri VGMP Admin Own Pr State
vlan10
80
none
Y Master
Master-addr Group-addr
10.0.0.2
10.0.0.1
When the interface gei_3/2 on P2 is restored, P3 becomes the backup device.

P3#show vrrp b
vlan10
80
none
Backup
10.0.0.1
10.0.0.1
2.5.2 CFM Interacting with VRRP

The VRRP protocol runs between P2 and P3, as shown in Figure 2-4. The interface
address 10.0.0.1 of P2 is used as the VRRP virtual address, and P2 is the master.
2-11
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 2-4 CFM Interacting with VRRP
1. Enable the CFM heartbeat detection function on the direct connection interfaces of P2
and P3.
2. Configure a track session object on P3, and specify the detection type as CFM.
3. Configure the same VRRP group number and virtual address on P2 and P3. To enable
P2 to become the master, use the interface address 10.0.0.1 of P2 as the VRRP virtual
address, or ensure the priority of the VRRP group on P2 is higher than the priority of
the VRRP group on P3.
4. Bind VRRP to the track session object of CFM on P3.
5. Shut down the interface gei_3/2 on P2. The status of the VRRP group on P3 changes
to Master. Restore the interface gei_3/2 on P2. The status of the VRRP group on P3
changes to Backup.
P2(config-loopback1)#ip add 1.1.1.1 255.255.255.255
P2(config)#vlan 10
P2(config)#vlan 20
P2(config)#cfm enable
P2(config)#cfm create md session 1 name MD1 level 5
P2(config-md1)#ma create session 1 name MA1
2-12
SJ-20100901100356-020|2011-07-30(R1.0)

P2(config-md1-ma1)#speed fast
P2(config-md1-ma1)#protect vlan
P2(config-md1-ma1)#primary vlan 20
P2(config-md1-ma1)#ccm time-interval 1
P2(config-md1-ma1)#create mep session 1 2 direction down
P2(config-md1-ma1)#assign mep 2 to interface gei_3/2
P2(config-md1-ma1)#mep 2 state enable
P2(config-md1-ma1)#mep 2 ccm-send enable
P2(config-md1-ma1)#mep 2 alarm-lowest-pri 1
P2(config-md1-ma1)#create rmep session 2 1 remote-mac 0818.1a94.0470
P2(config-md1-ma1)#!
P2(config)#

P3(config-loopback1)#ip add 2.2.2.2 255.255.255.255
P3(config)#vlan 10
P3(config)#vlan 20
P3(config-md1-ma1)#create rmep session 2 2 remote-mac 0025.1210.9720
P3(config-md1-ma1)#!
2-13
SJ-20100901100356-020|2011-07-30(R1.0)

P3(config)#track-session cfm
P3(config-track)#detect cfm 1 1 1
P3(config)#exit
P3(config-if-vlan10)#vrrp 1 track session cfm switch
P3(config)#
Check the configurations and validity of VRRP on P2 and P3. P2 is the master device
whereas P3 is the backup device. Run the show oam-track session command on P3. The
track session object of CFM has been created. Then run the show vrrp command on P3.
The track session object of CFM has been bound to the VRRP group.
P2#show vrrp b
Interface
vlan10
Grp
Pri
VGMP
Admin
Own
Pr
State
Master-addr
Group-addr
255
none
Master
10.0.0.1
10.0.0.1
Grp
Pri
VGMP
Admin
Own
Pr
State
255
none
Backup
P3#show vrrp b
Interface
vlan10
10.0.0.1
10.0.0.1
P3#show oam-track session cfm

session name:cfm
detect type: CFM
P3(config)#show vrrp 1
vlan100 - Group 1
State is Backup
Track object session cfm switch (up)
Master router is 10.0.0.1(local), priority is 255
2-14
SJ-20100901100356-020|2011-07-30(R1.0)

When the interface gei_3/2 on P2 is shut down, P3 becomes the master device.
P3#show vrrp b
vlan10
80
none
Master
10.0.0.2
10.0.0.1
When the interface gei_3/2 on P2 is restored, P3 becomes the backup device.

P3#show vrrp b
vlan10
255
none
Backup
10.0.0.1
10.0.0.1
2.6 Service Availability Manager Troubleshooting

2.6.1 Network Topology
A common fault of the service availability manager is as follows: The VRRP does not
perform active/standby switchover when a link is down, or the VRRP does not perform
switching restoration when the failed link is restored. This section describes how to
troubleshoot faults related to the interaction between Ethernet OAM and VRRP by taking
the topology shown in Figure 2-5 as an example.
Figure 2-5 Network Topology for Service Availability Manager Troubleshooting
2.6.2 Fault Analysis

When the interactions between Ethernet OAM detection and the VRRP fail, the following
causes are possible:
1. The detection configurations are incorrect.
2. The Ethernet OAM mechanism fails to detect link status changes.
2-15
SJ-20100901100356-020|2011-07-30(R1.0)
2.6.3 Handling Flow

Figure 2-6 shows a flow chart for handling service availability manager faults.
Figure 2-6 Service Availability Manager Fault Handling Flow
2.6.4 Handling Procedure

To handle common service availability manager faults, perform the following steps:
1. Check whether the link status detected by Ethernet OAM is consistent with the actual
link status. Go to step 2 if the link status is inconsistent, or step 3 if the status is
consistent.
2. Ensure that Ethernet OAM configurations are correct.
3. Check whether the track session object of Ethernet OAM has been correctly created.
Ensure that relevant configurations are correct.
4. Check whether the Ethernet OAM track session object is successfully bound to the
VRRP. Ensure that the binding is correct.
Contact ZTE technical support personnel if the fault still exists.
2-16
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 3
VRRP Configuration
Table of Contents
Overview of VRRP .....................................................................................................3-1
Configuring the VRRP ................................................................................................3-4
Maintaining VRRP ......................................................................................................3-7
VRRP Configuration Instances ...................................................................................3-8
VRRP Troubleshooting.............................................................................................3-16
3.1 Overview of VRRP

In general, the same default route is set on all hosts in an internal network. This default
route points to the egress gateway (Switch A as shown in Figure 3-1) to implement
communications between the hosts and external networks. If the egress gateway fails,
the communications between the hosts and external networks fail.
Figure 3-1 Default Gateway for the LAN
A common method to improve system reliability is to configure multiple egress gateways.

The hosts in a Local Area Network (LAN), however, usually do not support dynamic
routing protocols. Therefore, there arises an issue about routing between multiple egress
gateways.
The Virtual Switch Redundancy Protocol (VRRP) is an error-tolerant protocol. It well
addresses the above issue about routing between multiple egress gateways by separating
physical devices from logical devices.
In an LAN with multicast or broadcast capability, such as the Ethernet, the VRRP provides
a logical gateway to guarantee transmission links of high availability. This not only solves
traffic interruption that may be caused by the failure of a certain gateway device, but also
eliminates the need to change routing protocol configurations.
3-1
SJ-20100901100356-020|2011-07-30(R1.0)
As shown in Figure 3-2, the VRRP organizes a group of switches (Switch A and Switch B)
in an LAN into a virtual switch.
Figure 3-2 Working Principles of the VRRP
This virtual switch has its own IP address 10.100.10.1, which can be the same as the
interface address of a certain switch. Physical switches A and B also have their own IP
addresses. For example, the IP address of Switch A is 10.100.10.2, and that of Switch B
is 10.100.10.3. All hosts in the LAN, however, only know the IP address 10.100.10.1 of the
virtual switch but not the IP addresses of Switch A and Switch B. The hosts set their default
route to the IP address 10.100.10.1 of the virtual switch. In this way, hosts in the LAN can
communicate with other networks using the virtual switch. The working mechanism of the
virtual switch is described as follows:
1. A master switch is elected according to priority. The switch with the highest priority
becomes the master switch, whose status is Master. If two switches have the same
priority, the master IP address of the interface is compared. The switch with a greater
master IP address becomes the master switch to provide the routing service.
2. The rest switches serve as backup switches, which monitor the working status of
the master switch at any time. When the master switch works normally, it sends a
VRRP multicast packet at a certain interval to all backup switches in the VRRP group,
3-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 3 VRRP Configuration
indicating that the master switch is normally working. If a backup switch in the VRRP
group does not receive any packet from the master switch within the specified time,
it sets its own status to Master. Therefore, there may be multiple master switches if
there are multiple backup switches in the VRRP group according to the above principle.
Then each master switch compares the priority in the received VRRP packet with its
own local priority. If the local priority is smaller than the priority in the VRRP packet,
the switch changes its own status to Backup. Otherwise, the switch keeps the Master
status. Therefore, the switch with the highest priority is elected as the new master
switch to implement VRRP backup.
The switches forming a virtual switch may be in one of the following three states: Initialize,
Master, and Backup, as described below:
l
Initialize
A switch enters this status upon start. If the priority of the switch is 255 when the switch
receives a Startup event, the VRRP switch changes to the Master status. Otherwise,
the VRRP switch changes to the Backup status. A switch in Initialize status will not
perform any processing for a VRRP packet.
Master
A switch in Master status will complete the following tasks:
1. Periodically sending the VRRP multicast packet.
2. The switch sends free ARP packets, so that hosts in the network learn the virtual
MAC address corresponding to the virtual IP address.
3. Responding to the ARP requests of the virtual IP address. The switch responds
to the virtual MAC address but not the real MAC address of the interface.
4. Forwarding IP packets whose destination MAC address is the virtual MAC
address.
5. Receiving IP packets whose destination IP address is the virtual IP address if
itself is the owner of the virtual IP address, or simply discarding the IP packets if
otherwise.
A switch in Master status will change to the Backup status only when it receives a
VRRP packet containing a priority value greater than the priority value of the switch
itself. It will change to the Initialize status only when it receives a shutdown event.
Backup
A switch in Backup status will complete the following tasks:
1. Receiving VRRP multicast packets from the master switch so as to learn the status
of the master switch.
2. Not responding to the ARP requests of the virtual IP address.
3. Discarding IP packets whose destination MAC address is the virtual MAC address.
4. Discarding IP packets whose destination IP address is the virtual IP address.
The switch in Backup status will change to the Master status only when it receives the
MASTER_DOWN timer expiry event. When the switch in Backup status receives a
VRRP packet containing a priority value smaller than the priority value of the switch
3-3
SJ-20100901100356-020|2011-07-30(R1.0)
itself, it simply discards the packet and does not reset the timer. Then the switch will
change to the Master status after several times of such timer processing. The switch
in Backup status will change to the Initialize status only when it receives a shutdown
event.
Figure 3-3 shows the transition of the three states.
Figure 3-3 VRRP Status Transition
As can be seen from the above analysis, a host in the network does not perform any extra
tasks and its communications with external networks are not affected by switch faults.
3.2 Configuring the VRRP

Use the following commands on ZXCTN 9000 to enable configure the VRRP:
Step
Command
Function
ZXCTN9000(config)#interface < vlan-id>
Enters the VLAN interface configuration

mode
ZXCTN9000(config-if-vlanX)#vrrp <
Enables the VRRP protocol in interface
group> ip< ip-address> [ secondary]
configuration mode (To disable the VRRP

protocol, use the no form of this command)
Configures the VRRP priority in interface
group> priority < level>
configuration mode (The value of level

ranges from 2 to 254. To restore the
default priority 100, use the no form of this
command)
Configures VRRP group preemption in
group> preempt [ delay < seconds> ]
interface configuration mode (To restore the

default preemption mode and the default
preemption delay of 0, use the no form of
this command)
3-4
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-if-vlanX)#vrrp
Configures the VRRP advertisement
< group> advertise { < 1-25> | msec <
interval (1 second by default) in interface
100-25000> }
configuration mode (To restore the default

interval, use the no form of this command.
The msec parameter is optional and can be
specified to change the interval unit from
seconds to milliseconds)
Configures the learning of the VRRP

advertisement interval in interface
group> learn
configuration mode (By default, the learning

function is disabled. To restore the default
settings, run the no vrrp group timers learn
command)
7
ZXCTN9000(config-if-vlanX)#vrrp < group
Configures VRRP interface tracking in
number> track-vgmp < pri-number>
interface configuration mode (If users do

not specify priority decrement during the
configuration of interface tracking, the priority
decreases by 10. To restore the default
settings, use the no form of this command)
Configures the heartbeat line, and specifies
group> out-interface < interface-name>
the VRRP egress interface in VRRP interface

configuration mode
Configures the VRRP authentication string
group> authentication { md5/text < string> }
in interface configuration mode (The

authentication string is 1 to 8 characters.
This configuration is invalid in VRRP version
2 only but not valid in VRRP version 3)
10
11
12
ZXCTN9000(config-if-vlanX)#vrrp
Configures the event group or event object
< groupnumber> track{ < object> { bfd{
and type for VRRP tracking in interface
priorty-down| switch} | dectement<
configuration mode (To cancel the tracked
pri-number> } | session< word> { decrement<
group or object, use the no form of this
pri-number> | priority-down| switch} }
command)
Enables the TTL check function in interface
group> ttl-check
configuration mode
Configures the VRRP administrative group
group> admin-group { owner | interface <
function in interface configuration mode
interface-name> vrid < 1-255> }
The command parameters in step 2 are described as follows.
3-5
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< group>
ID of the virtual switch, ranging from 1 to 255
ipv4
Indicates that the VRRP IPv4 virtual address is to

be configured
< ip-address>
IP address of the virtual switch
secondary
The other IP address supported by the virtual

switch
The command parameter in step 4 is described as follows.

Parameter
Description
< seconds>
Time delay for a VRRP switch to declare itself as

the master in seconds, ranging from 0 to 3600; 0
by default

Parameter
Description
< interface-name>
Name of the interface to be tracked
priority-decrement < 1-254>
Priority decrement of the tracked link (If

priority decrement is not specified, the priority
decrements by 10 by default)

Parameter
Description
< group>
group
Event tracking group
object
Event tracking object
string
Name of the tracked group or tracked object
link-type
Link type
peer-type
Peer type
priority-decrement < 1-254>
Priority decrement

Parameter
Description
< group>
check-ttl
Whether to enable the TTL check function of the

VRRP
3-6
SJ-20100901100356-020|2011-07-30(R1.0)
3.3 Maintaining VRRP

Use the following commands on ZXCTN 9000 to maintain the VRRP:
Command
Function
ZXCTN9000(config)#show vrrp brief
Shows summary information about all the IPv4

VRRP groups on the switch
ZXCTN9000(config)#show vrrp interface <
Shows details about the VRRP group on a
interface-name>
specific interface
ZXCTN9000(config)#show vrrp [ < group number>
Shows details about the specified VRRP group
(Group number: 1 to 255)
ZXCTN9000(config)#show vrrp all
Shows all the VRRP groups of the local chassis
ZXCTN9000(config)#show vrrp attach-group
Shows the VRRP active/standby relation on an
interface < interface name> vrid < vrid>
interface (The standby group number ranges

from 1 to 255)
The following example shows the outputs of the show vrrp brief command.
ZXCTN9000#show vrrp brief
Interface Grp Pri VGMP Admin Own Pr State Master-addr Group-addr
---------------------------------------------------------------vlan10
100
none
Init
0.0.0.0
10.0.0.3
vlan10
100
none
Init
0.0.0.0
10.0.0.2
The following example shows the outputs of the show vrrp interface < interface-name>
command.
ZXCTN9000(config)#show vrrp interface vlan 10
vlan10 - Group 1
State is Init
Track object session 1 switch (up)
vlan10 - Group 2
State is Init
3-7
SJ-20100901100356-020|2011-07-30(R1.0)

The following example shows the outputs of the show vrrp [ < group number> ] command.
ZXCTN9000(config)#show vrrp 2
vlan2340 - Group 2
State is Init
3.4 VRRP Configuration Instances

3.4.1 Configuring the Basic VRRP
The VRRP protocol runs between S1 and S2, as shown in Figure 3-4. The interface
address 10.0.0.1 of S1 is used as the VRRP virtual address, and P2 is the master.
3-8
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 3-4 Configuring the Basic VRRP
1. Configure the IP addresses of VRRP interfaces. The interface IP addresses configured
on S1 and S2 must belong to the same network segment.
2. Configure the same VRRP group and virtual IP address on S1 and S2. The virtual IP
address must be in the same network segment as the IP addresses of VRRP interfaces.
3. To enable S1 to serve as the master device, first configure S1 according to the above
steps. For devices with the same priority (100 by default), the VRRP-enabled device
that first advertises VRRP packets will become the master device in the VRRP group.
4. If the configured VRRP virtual IP address is the same as an interface IP address, this
VRRP group has the highest priority (255).
Run the following configuration commands on S1:
S1(config)#vlan 10
S1(config-vlan10)#ex
S1(config)#interface vlan 10
S1(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
S1(config-if-vlan10)#vrrp 1 ip 10.0.0.1
S1(config-if-vlan10)#end

S2(config)#vlan 10
3-9
SJ-20100901100356-020|2011-07-30(R1.0)

Check the VRRP configuration results on S1 and verify that the configurations have taken
effect:
S1#show vrrp breif
brief
-----------------------------------------------------------------vlan10
255
none
Master
10.0.0.1
10.0.0.1
S1(config-if-vlan10)#show vrrp interface vlan 10

vlan10 - Group 1
State is Master, Owner
3.4.2 Configuring Symmetrical VRRP

As shown in Figure 3-5, two VRRP groups are configured. PC1 and PC2 use the virtual
device of group 1 as the default gateway (10.0.0.1), whereas PC3 and PC4 use the virtual
device of group 2 as the default gateway (10.0.0.2). S1 and S2 back up each other. The
communications between the four PCs and the external network are interrupted only when
both S1 and S2 fail.
3-10
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 3-5 Configuring Symmetrical VRRP
2. Configure VRRP group 1 and a virtual address on S1. Then configure VRRP group 2
and another virtual address on S2. The virtual IP addresses must belong to the same
network segment as interface IP addresses.
3. S1 becomes the master in group 1, whereas S2 becomes the master in group 2.
4. Add S1 as a backup device to group 2, and S2 as a backup device to group 1.
5. If the configured VRRP virtual IP address is the same as the IP address of the downlink
interface, this VRRP group has the highest priority (255).
S1(config)#vlan 10

S2(config)#vlan 10
3-11
SJ-20100901100356-020|2011-07-30(R1.0)

effect:
S1#show vrrp brief
-----------------------------------------------------------------vlan10
255
none
Y Mastert
10.0.0.1
10.0.0.1
vlan10
100
none
10.0.0.2
10.0.0.2
Slaver
S1(config-if-vlan10)#show vrrp 1
vlan10 - Group 1
State is Master,, Owner
3.4.3 Configuring the VRRP Heartbeat Line (IPv4)

The VRRP protocol runs between S1 and S2, as shown in Figure 3-6. The interface
address 10.0.0.1 of S1 is used as the VRRP virtual address, and P2 is the master.
3-12
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 3-6 Configuring the VRRP Heartbeat Line (IPv4)
2. Configure the same VRRP group and virtual IP address on S1 and S2. The virtual IP
address must be in the same network segment as the IP addresses of VRRP interfaces.
3. To enable S1 to serve as the master device, first configure S1 according to the above
4. Configure the same heartbeat egress interface for the VRRP group in VRRP interface
configuration mode on S1 and S2.
5. If the configured VRRP virtual IP address is the same as the IP address of the downlink
interface, this VRRP group has the highest priority (255).
S1(config)#vlan 10
S1(config)#vlan 20
S1(config-if-vlan20)#ex
S1(config-if-vlan10)#vrrp 1 ipv4 10.0.0.1
S1(config-if-vlan10)#vrrp 1 out-interface vlan 20
3-13
SJ-20100901100356-020|2011-07-30(R1.0)


S2(config)#vlan 10
S2(config)#vlan 20
S2(config-if-vlan20)#ex
S2(config-if-vlan10)#vrrp 1 out-interface vlan 20
effect:
S1#show vrrp brief
----------------------------------------------------------------vlan10
255
none
Y Mastert
10.0.0.1
10.0.0.1
S1(config-if-vlan10)#show vrrp 1
vlan10 - Group 1
State is Init, Master
3.4.4 Configuring VRRP Track

The VRRP protocol runs between PA and PB, as shown in Figure 3-7. The VRRP virtual
IP address is 10.0.0.3.
3-14
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 3-7 Configuring VRRP Track
on PA and PB must belong to the same network segment.
2. Configure the same VRRP group and virtual IP address on PA and PB. The virtual
IP address must be in the same network segment as the IP addresses of VRRP
interfaces.
3. To enable PA to serve as the master device, first configure PA according to the above
4. Configure track session objects on PA and PB.
5. Configure the VRRP tracking function on the VRRP group interfaces of PA and PB.
Run the following configuration commands on PA:
PA(config)#valn 10
PA(config-vlan10)#ex
PA(config)#interface vlan 10
PA(config-if-vlan10)#ip address 10.0.0.1 255.255.0.0
PA(config-if-vlan10)#vrrp 1 ip 10.0.0.3
PA(config-if-vlan10)#vrrp 1 track session 1 switch
/*Here, the track session has been preconfigured in the service
availability manager.*/
PA(config-if-vlan10)#end
Run the following configuration commands on PB:

PB(config)#vlan 10
PB(config-vlan10)#ex
PB(config)#interface vlan 10
PB(config-if-vlan10)#ip address 10.0.0.2 255.255.0.0
3-15
SJ-20100901100356-020|2011-07-30(R1.0)

PB(config-if-vlan10)#vrrp 1 ip 10.0.0.3
PB(config-if-vlan10)#vrrp 1 track session 1 switch
/*Here, the track session object "zte" must be preconfigured in
the service availability manager. For details about the
configuration, refer to the section about service availability
manager configuration.*/
PB(config-if-vlan10)#end
Check the VRRP track configuration results on PA and verify that the configurations have
taken effect:
PA#show vrrp brief
---------------------------------------------------------------vlan10
100
none
Master 10.0.0.1
10.0.0.3
PA(config-if-vlan10)#show vrrp 1
vlan10 - Group 1
State is Master
Backup route is diPAbled
Track object session 1 P(up)
3.5 VRRP Troubleshooting

A common problem with the VRRP in actual networking is that master/slave negotiation
fails or the negotiation is incorrect. This section describes VRRP troubleshooting by taking
the topology shown in Figure 3-8 as an example.
3-16
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 3-8 Network Topology for VRRP Troubleshooting

When VRRP master/slave negotiation fails or the negotiation is incorrect, the hardware
or software may be faulty. First check the hardware, including the main control boards,
line cards, interface boards, and network cables. Check whether the direct connection
interfaces of both devices can ping through each other. After confirming that the hardware
is normal, check the software, including VRRP virtual address, advertisement interval,
VRRP group authentication type, heartbeat line, priority, and preemption.
3.5.3 Handling Flow

Figure 3-9 and Figure 3-10 show two flow charts for handling VRRP faults.
3-17
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 3-9 VRRP Fault Handling Flow 1
3-18
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 3-10 VRRP Fault Handling Flow 2

Check the VRRP according to the handling flow illustrated in the VRRP fault handling flow
chart. If a fault is found, perform the following steps to remove the fault:
1. If the physical link is abnormal, first check whether the administrative status of the
interface is "UP". By default, the interface is shut down. Run the no shutdown
command to enable the interface to be up if the interface is shut down. If the fault
persists, replace the network. If the fault still exists, replace the line card or interface
board.
2. Confirm that the configured network segment address of the interface is correct and
the ARP learning function is normal.
3. Ensure that the VRRP version number is consistent. If authentication is required, the
VRRP version must be Version 2 at both ends and the authentication configurations
at both ends must be consistent.
4. By default, the preemption function is enabled for the VRRP. The switch with the
highest priority becomes the master switch. For two switches with the same priority, the
3-19
SJ-20100901100356-020|2011-07-30(R1.0)
5.
6.
7.
8.
9.
switch with a greater IP address becomes the master switch. Configure a reasonable
preemption delay, or simply keep the default delay.
If it is necessary to configure egress interfaces for heartbeat, ensure that the egress
interfaces at the two ends are direct connection interfaces, the interface addresses
belong to the same network segment, and the two interfaces can ping through each
other.
If authentication is configured, ensure that the authentication configurations at both
ends are consistent.
Ensure that the set advertisement interval is not too great. In general, just keep
the default settings. To restore the default settings, use the no form of a relevant
command.
Ensure that both the master device and the slave device are in learning status.
Ensure that the VRRP virtual addresses configured for the master device and the slave
device as well as the number of virtual addresses are consistent.
3-20
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 4
EFM Configuration
Table of Contents
Overview of EFM........................................................................................................4-1
Configuring EFM ........................................................................................................4-2
Maintaining EFM ........................................................................................................4-5
EFM Configuration Instances .....................................................................................4-8
EFM Troubleshooting ...............................................................................................4-13
4.1 Overview of EFM

Ethernet in the First Mile (EFM) is a standard defined in IEEE 802.3ah for operation,
maintenance, and administration. Designed for link-level management, it can monitor
point-to-point (or virtual point-to-point) Ethernet links in a network and implement relevant
troubleshooting. EFM is significant for last-mile connection management of network users.
As a standard for detecting, monitoring, and maintaining direct connection links, EFM is
mostly used for access link detection and monitoring. In the ZXCTN 9000 system, EFM
provides statistics about the running status of physical point-to-point direct connection
links, such as frame transmission error ratio, link transmitting/receiving rate comparison,
and loss statistics, and maximally monitors the running status of these links. In addition,
EFM can detect and notify emergency fault events occurring in the system, such as
the system unrecoverable fault event, so that the quality of transmission on L2 links is
detected and guaranteed to some extent. EFM monitors and diagnoses the running
status of the links in real time to help network administrators maintain the network at a
lower maintenance cost.
The ZXCTN 9000 supports the following functions:
l
l
l
l
l
Auto negotiation with other devices.

Remote loopback statistics and detection of links.
Detection of erroneous frames or symbols transmitted on a link.
Notification of emergency events.
Selective interactive processing.
EFM enables the local device to check the received protocol packets to determine whether
the EFM function is also enabled on the peer device. It checks the relevant configurations
of the local device and the peer device through protocol packet exchange to determine
whether the negotiation procedure can be completed. After the negotiation procedure is
over, EFM detects the link status through the link monitoring function. For example, it
statistically analyzes the erroneous frames or symbols transmitted on a link in a statistical
period. If the number of erroneous frames or symbols is more than the configured threshold
4-1
SJ-20100901100356-020|2011-07-30(R1.0)
value, EFM triggers an event notification to both the local device and the remote device
so that network administrators timely learn the running status of the link. Furthermore,
the remote loopback function can be enabled for EFM to detect the ratio of lost packets
caused by inconsistent receiving rates between the local device and the remote device or
caused by link faults.
EFM packets are slow protocol packets that cannot be forwarded by devices. Therefore,
EFM can be applied only between two devices physically directly connected to each other,
as shown in Figure 4-1.
Figure 4-1 Working Principles of EFM
The EFM application environment is simple. Packets cannot be forwarded via devices. In
general, EFM is applied between the two ports of the link that directly connects two devices.
It is used for precise link detection and poses certain requirements on the precision of
detection. Ensure that protocol negotiation is successful without link interruption while
keepalive packets are sent between the two devices. The other functions of EFM are
available only after protocol negotiation succeeds. When detecting an event, EFM notifies
the event in a specific packet to the peer device.
4.2 Configuring EFM

Use the following commands on ZXCTN 9000 to configure EFM:
Step
Command
Function
ZXCTN9000(config)#set ethernet-oam <
Sets whether to globally enable the EFM
state>
function
ZXCTN9000(config)#set ethernet-oam oui <
Configures the EFM vendor identifier OUI
word>
field
ZXCTN9000(config)#set ethernet-oam
Configures the timeout time of EFM remote
remote-loopback time-out < value>
loopback
ZXCTN9000(config)#interface <
Enters the EFM interface configuration mode
interface-name>
5
ZXCTN9000(config-[x]gei_x/y[/z])#set
Sets whether to enable the EFM function on
ethernet-oam < state>
the specified interface
Configures the remote discovery period,
ethernet-oam period < level-value> timeout <
timeout time, and mode of EFM
time> mode < mode-value>

7
Enables or disables the EFM remote
ethernet-oam remote-loopback < operation>
loopback function
4-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 4 EFM Configuration
Step
Command
Function
Sets whether to enable the link monitoring
ethernet-oam link-monitor < state>
function on the specified interface
Sets the errored frame summary window
ethernet-oam link-monitor frame threshold <
and errored frame summary threshold for
th-value> window < win-value>
link monitoring
Sets the errored symbol summary window
ethernet-oam link-monitor symbol-period
and errored symbol summary threshold for
threshold < th-value> window < win-value>
link monitoring
Sets the errored frame period summary
10
11
12
ethernet-oam link-monitor frame-period
window and errored frame period summary
threshold for link monitoring
Sets the errored frame second period
ethernet-oam link-monitor frame-second
summary window and errored frame second
period summary threshold for link monitoring

Parameter
Description
< state>
State: "enable" or "disable"

Parameter
Description
< word>
OUI value; 1 to 3 characters; "ZTE" by default

Parameter
Description
< value>
Loopback timeout time in seconds (Range: 1 to

10; 3 by default)

Parameter
Description
< interface-name>
Interface name

Parameter
Description
< state>

4-3
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< level-value>
Sending interval of remote discovery packets in

seconds (Range: 1 to 10; 10 by default)
< time>
Timeout time in seconds (Range: 2 to 20; 5 by

default)
< mode-value>
Working mode: "active" (default) or "passive"

Parameter
Description
< operation>
Loopback operation identifier: "start" or "stop"

(default)

Parameter
Description
< state>

Parameter
Description
< th-value>
Errored frame summary threshold (Range: 1 to

65535; 1 by default)
< win-value>
Errored frame summary window in seconds

(Range: 1 to 60; 1 by default)

Parameter
Description
< th-value>
Errored symbol summary threshold (Range: 1

to 65535; 1 by default)
< win-value>
Errored symbol summary window in millions

(Range: 1 to 65535; 1 by default)

Parameter
Description
< th-value>
Errored frame period summary threshold (Range:

1 to 65535; 1 by default)
< win-value>
Errored frame period summary window in ten

thousand frames (Range: 1 to 600000; 100 by
default)
4-4
SJ-20100901100356-020|2011-07-30(R1.0)

Parameter
Description
< th-value>
Errored frame second period summary threshold

in frame seconds (Range: 1 to 900; 1 by default)
< win-value>
Errored frame second period summary window in

seconds (Range: 10 to 900; 60 by default)
4.3 Maintaining EFM

Use the following commands on ZXCTN 9000 to maintain and diagnose the EFM function:
Command
Function
ZXCTN9000#debug ethernet-oam { interface
Enables the EFM packet sending/receiving
< interface-name> | packet interface <
debugging switch (To disable all the enabled
interface-name> { dual | in | out} type { all
switches, use the no form of this command)
| information| lpbk-ctrl | notify | org-spec |

reqst-varb | respst-varb} mode { all-time | numberr
< num-value> } }
ZXCTN9000(config)#show ethernet-oam [ <
Shows the current global configuration
interface-name> { discovery | link-monitor |
information or interface configuration information
statistics} ]
about EFM and relevant status information
The parameters of the debug command are described as follows:

Parameter
Description
< interface-name>
Interface name
dual
Shows information about the packets sent and

received
in
Shows information about received packets only
out
Shows information about sent packets only
all
Shows information about all types of EFM packets
information
Shows information about EMF information

packets only
lpbk-ctrl
Shows information about EFM loopback control

packets only
notify
Shows information about EFM event notification

packets only
org-spec
Shows information about vendor-defined packets

only
4-5
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
reqst-varb
Shows information about EFM variable request

packets only
respst-varb
Shows information about EFM variable response

packets only
all-time
Shows packet debugging information all the time
< num-value>
Shows information about the specified number of

packets (Range: 10 to 500; 200 by default)
The parameters of the show command are described as follows:

Parameter
Description
< interface-name>
Interface name
discovery
A parameter behind the interface name to show

status information related to EFM negotiation
link-monitor

information related to EFM link monitoring
statistics

EFM packet statistics information including
the statistics about loopback packets sent and
received
The following example shows the outputs of the debug command.

ZXCTN9000#debug ethernet-oam
pakcet interface gei_1/1 dual type information mode all
Nov 21 20:44:22: ETH-OAM:
gei_1/1 Send CODE_INFORMATION Packet:
01 80 C2 00 00 02 00 D0 D0 C7 40 00 88 09 03 00
50 00 01 10 01 00 02 02 1D 05 EE 52 31 00 00 00
00 00 02 10 01 00 02 05 1D 05 EE 52 32 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
The following example shows the outputs of the show command.

ZXCTN9000#show ethernet-oam gei_1/1 discovery
Port
gei_1/1: Ethernet OAM Enable
Local DTE
----------Config:
Mode
: active
Period
: 10*100(ms)
Link TimeOut
: 5(s)
Unidirection
: nonsupport
4-6
SJ-20100901100356-020|2011-07-30(R1.0)

PDU Max Size
: 1518(bytes)
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Discovery
: done
Loopback
: off
PDU Revision
: 1
Remote DTE
----------Config:
Mode
: active
Link Monitor
: support
Unidirection
: nonsupport
Remote Loopback : support

Mib Retrieval
: support
PDU Max Size
: 1518
OUI
: P2
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Mac Address
: 00.d0.d0.c5.6b.80
PDU Revision
: 1
The outputs of the show ethernet-oam gei_1/1 discovery command are described as follows:
Output Item
Description
Mode
EFM working mode
Period Time
Sending interval of remote discovery packets
Link TimeOut
Link timeout
Unidirection
Whether EFM protocol packets can be sent when

the link is unidirectional
PDU Max Size
Maximum size of protocol packets to be sent
Parse
Parser status
Multiplexer
Multiplexer status
Stable
Local and remote satisfaction bit
Discovery
A flag indicating whether discovery is completed
Loopback
A flag indicating whether the loopback function

is enabled
PDU Revision
Revision value in the PDU
4-7
SJ-20100901100356-020|2011-07-30(R1.0)
Output Item
Description
Link Monitor
Whether the link monitoring function is enabled
Remote Loopback
Whether the remote loopback function is

supported
Mib Retrieval
Whether the variable request is supported
Mac Address
MAV address of the remote device
4.4 EFM Configuration Instances

4.4.1 EFM Connection Establishment
As shown in Figure 4-2, P1 and P2 are directly connected to each other. Configure EFM
on the direct connection interfaces of P1 and P2 to establish a connection between P1 and
P2.
Figure 4-2 EFM Connection Establishment
1. Configure EFM on the interface of P1 that directly connects P2, enable the EFM
enabling switch and the link-monitor switch on the specified interface, and globally
enable EFM.
2. Configure EFM on the interface of P2 that directly connects P1, enable the EFM
enabling switch and the link-monitor switch on the specified interface, and globally
enable EFM.
3. Run the show ethernet-oam discovery command on P1 and P2 to check the status of
EFM connection establishment on P1 and P2.
4. Run the show ethernet-oam link-monitor command on P1 and P2 to check the number
of link errors between P1 and P2.
P1#configure terminal
P1(config)#set ethernet-oam enable
P1(config)#set ethernet-oam oui P1
4-8
SJ-20100901100356-020|2011-07-30(R1.0)

P1(config)#interface gei_1/1
P1(config-gei_1/1)#set ethernet-oam enable
P1(config-gei_1/1)#set ethernet-oam link-monitor enable
P1(config-gei_1/1)#exit

1. Run the show ethernet-oam discovery command on P1 to check the EFM negotiation
status of the link.
P1#show ethernet-oam gei_1/1 discovery
Port
Local DTE
----------Config:
Mode
: active
Period
: 10*100(ms)
Link TimeOut
: 5(s)
Unidirection
: nonsupport
PDU Max Size
: 1518(bytes)
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Discovery
: done
Loopback
: off
PDU Revision
: 1
Remote DTE
----------Config:
Mode
: active
Link Monitor
: support
Unidirection
: nonsupport

Mib Retrieval
: support
PDU Max Size
: 1518
4-9
SJ-20100901100356-020|2011-07-30(R1.0)

OUI
: P2
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Mac Address
: 00.d0.d0.c5.6b.80
PDU Revision
: 1
2. Run the show ethernet-oam link-monitor command on P1 to check the number of link
errors.
P1#show ethernet-oam gei_1/1 link-monitor
Link Monitoring of Port: gei_1/1

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
: 0
Error Frame Period Event:

Frame Window
: 100(ten thousand frames)
: 1
Total Error Frames
: 0
: 0
Error Frame Seconds Event:

Error Seconds Window
: 60(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 P2 to check the EFM negotiation
status of the link.
P2#show ethernet-oam gei_2/1 discovery
Port
4-10
SJ-20100901100356-020|2011-07-30(R1.0)

Local DTE
----------Config:
Mode
: active
Period
: 10*100(ms)
Link TimeOut
: 5(s)
Unidirection
: nonsupport
PDU Max Size
: 1518(bytes)
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Discovery
: done
Loopback
: off
PDU Revision
: 1
Remote DTE
----------Config:
Mode
: active
Link Monitor
: support
Unidirection
: nonsupport

Mib Retrieval
: support
PDU Max Size
: 1518
OUI
: P1
Status:
Parser
: forward
Multiplexer
: forward
Stable
: yes
Mac Address
: 00.d0.d0.c7.40.00
PDU Revision
: 1
4. Run the show ethernet-oam link-monitor command on P2 to check the number of link
errors.
P2#show ethernet-oam gei_2/1 link-monitor
Link Monitoring of Port: gei_2/1

Link Monitoring Enable
Error Symbol Period Event:
Symbol Window
: 1(million symbols)
Error Symbol Threshold
: 1
Total Error Symbols
: 0
: 0
4-11
SJ-20100901100356-020|2011-07-30(R1.0)

Error Frame Event:
Period Window
: 1(s)
: 1
Total Error Frames
: 0
: 0
Error Frame Period Event:

Frame Window
: 100(ten thousand frames)
: 1
Total Error Frames
: 0
: 0
Error Frame Seconds Event:

Error Seconds Window
: 60(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
4.4.2 EFM Remote Loopback

As shown in Figure 4-3, P1 and P2 are directly connected to each other. Configure EFM
on the direct connection interfaces of P1 and P2, and enable the remote loopback function
on P1 so that P2 loops back the packets received from P1.
Figure 4-3 EFM Remote Loopback
1. Configure EFM on the interface of P1 that directly connects P2, and globally enable
EFM.
2. Configure EFM on the interface of P2 that directly connects P1, and globally enable
EFM.
3. Enable the remote loopback function on P1 after the EFM connection is established
between P1 and P2.
4. Run the show ethernet-oam discovery command on P1 and P2 to check the status of
EFM connection establishment on P1 and P2.
4-12
SJ-20100901100356-020|2011-07-30(R1.0)

Enable the remote loopback function on P1 after the EFM connection is established.
P1(config-gei_1/1)#set ethernet-oam remote-loopback start
After receiving a packet except for the OAM PDU from P1 on the EFM connection link, P2
directly loops back the packet to P1.
4.5 EFM Troubleshooting

A common problem with EFM in actual networking is that connection establishment and
remote loopback fail. This section describes EFM troubleshooting by taking the topology
shown in Figure 4-4 as an example.
Figure 4-4 Network Topology for EFM Troubleshooting
4-13
SJ-20100901100356-020|2011-07-30(R1.0)

1. When EFM connection establishment fails, the following causes are possible:
l The direct connection interfaces of the two devices are not up.
l The passive negotiation mode is configured on both devices.
l The physical link is abnormal.
2. If EFM remote loopback fails, maybe the loopback function is already enabled before
the EFM connection is established. Therefore, ensure that the EFM connection has
already been established before the loopback function is enabled.
4.5.3 Handling Flow

Figure 4-5 shows a flow chart for handling the EFM connection establishment failure.
Figure 4-5 EFM Fault Handling Flow
4-14
SJ-20100901100356-020|2011-07-30(R1.0)

To handle common EFM faults, perform the following steps:
1. Run the show ip interface brief phy command on P1 and P2 to check whether the
interfaces are up. Ensure that the direct connection interfaces of P1 and P2 are
working properly.
2. Run the show ethernet-oam interface-name discovery command on P1 and P2. Ensure
that the EFM negotiation mode is set to "active" on at least P1 or P2.
3. Check whether the physical line is normal. Ensure that the communication status of
the physical line is normal.
4. Run the debug ethernet-oam packet interface command in privileged mode on P1
and P2 to check information about EFM packets sent and received on the specified
interface. Ensure that EFM packets are normally sent/received on the interface.
Contact ZTE technical support engineers if the fault still exists.
4-15
SJ-20100901100356-020|2011-07-30(R1.0)
This page intentionally left blank.
4-16
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 5
CFM Configuration
Table of Contents
Overview of CFM .......................................................................................................5-1
Configuring CFM ........................................................................................................5-2
Maintaining CFM ........................................................................................................5-9
CFM Configuration Instances ...................................................................................5-12
CFM Troubleshooting ...............................................................................................5-19
5.1 Overview of CFM

Connectivity Fault Management (CFM) defined in IEEE 802.1ag can effectively check,
isolate, and report the connectivity faults of virtual bridge LANs.
Network administrators may plan network services and layers to facilitate network
management and maintenance. They can divide an entire network into multiple
maintenance domains (MDs). Figure 5-1 shows a single MD.
Figure 5-1 MD
In the domain illustrated in the above figure, a series of ports are defined on both
edge devices and internal devices. The gray points on the edge devices indicate
the service ports that directly connect devices outside the domain, and are called
Maintenance-association End Points (MEPs). There are also some black ports (including
those on the intermediate device of the domain), which connect devices inside the
domain and are called the Maintenance-association Intermediate Point (MIPs). Domain
management is implemented by the defined MEPs and MIPs.
5-1
SJ-20100901100356-020|2011-07-30(R1.0)
A network can be divided into multiple domains, such as the user domain, provider domain,
and operator domain. For each created domain, a level is specified. There are totally 8
levels: 0 to 7. The level of a domain determines the inclusive relation of the domain. A
domain with a larger level can include a domain with a smaller level. A domain with a
smaller level, however, cannot include a domain with a larger level. In addition, a domain
cannot include other domains with the same level. In other words, the domain with the
largest range has the highest level. The inclusive relation of a domain can be tangency
(inner or outer tangency) or inclusion but cannot be intersection.
Connectivity Fault Management (CFM) can effectively check, isolate, and report the
connectivity faults of virtual bridge LANs. It is intended for operators' networks but
also effective for customer networks (C-VLANs). IEEE 802.1ag defines the following
mechanism:
1. Configuring multiple nested maintenance domains through a bridge network. Each
domain can be managed by a different management organization.
2. Configuring a maintenance association (MA) identified by a separate MD in any given
bridge and a group of VLANs.
3. The protocols, procedures, and CFM protocol packet formats for detecting, isolating,
and reporting connectivity faults.
4. Configuring and managing the configurations of maintenance points (MPs) in an MA.
An MP is used to generate and receive relevant CFM packets.
5. Instructing MPs to perform the determined fault isolation operation and inspect the
results.
5.2 Configuring CFM

Use the following commands on ZXCTN 9000 to configure CFM:
Step
Command
Function
ZXCTN9000(config)#cfm { enable| disable}
Enables or disables the CFM function

globally
ZXCTN9000(config)#cfm ccm-format { 0| 1}
Sets the format of the CCM packet to be

sent by CFM
ZXCTN9000(config)#cfm create md session
Creates a maintenance domain
< session-id> name < md-name> level <

md-level>
4
ZXCTN9000(config)#cfm delete md<
Deletes a maintenance domain
session-id>
5
ZXCTN9000(config)#cfm md session <
Enters the maintenance domain mode
session-id>
6
ZXCTN9000(config-mdX)#ma create session <
Creates a maintenance association
session-id> name < ma-name>
5-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 5 CFM Configuration
Step
Command
Function
ZXCTN9000(config-mdX)#ma delete { <
Deletes a maintenance association
session-id> | < ma-name> }

8
ZXCTN9000(config-mdX)#ma session <
Enters the maintenance association mode
session-id>
9
ZXCTN9000(config-md-maX)#create mep
Creates an MEP
session < session-id> < index-id> direction {

down | up}
10
ZXCTN9000(config-md-maX)#create rmep
Deletes an MEP
session < session-id> < index-id> remote-mac

< xxxx.xxxx.xxxx>
11
ZXCTN9000(config-md-maX)#create mip
Creates an MIP
session < session-id> name < mip-name>

12
ZXCTN9000(config-md-maX)#delete mep { <
Deletes an MEP
index-id> | all | session < session-id> }

13
ZXCTN9000(config-md-maX)#delete mip { all |
Deletes an MIP
session < session-id> }

14
ZXCTN9000(config-md-maX)#assign mep <
Binds an MEP to a port or CIP
index-id> to { interface < interface> | cip <

cip-index> }
15
ZXCTN9000(config-md-maX)#assign mip <
Binds an MIP to a port or CIP
session-id> { interface < interface> | cip <

cip-index> }
16
ZXCTN9000(config-md-maX)#protect <
Configures the protection type of the MA
protect-type>
17
ZXCTN9000(config-md-maX)#primary vlan
Configures the primary VLAN of the MA
< vlan-id>
18
ZXCTN9000(config-md-maX)#speed { fast |
Configures the sending speed of the MA
slow}
19
20
ZXCTN9000(config-md-maX)#ccm
Configures the CCM packet sending interval
time-interval < interval>
of the MA
ZXCTN9000(config-md-maX)#mep < index-id>
Enables/disables the local management
state { enable | disable}
function of the MEP (Enables/disables the

CCM detection function of the RMEP)
21
Enables/disables the CCM packet sending
ccm-send { enable | disable}
function of the MEP (Valid for the local MEP

only)
5-3
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
22
Configures the lowest fault alarm level of an
alarm-lowest-pri < priority-value>
MEP so as to restrict the fault levels of the

MEP for which an alarm will be triggered
23
Sets the client level of an MEP
client-level < level >

24
25
Enables/disables the AIS function of the local
ais { enable | disable}
MEP
ZXCTN9000(config-md-maX)#l2vpn <
Configures the L2 VPN for CFM detection
l2vpn-name>
26
ZXCTN9000#cfm lbm md < md-session-id> ma <
Configures the sending of Loop Back
ma-session-id> smep-id < smep-id> { dmep-id
Messages (LBMs)
< dmep-id> | dmep-mac < dmep-mac> |

dmip-mac < dmip-mac> } [ repeate < count> ]
[ size < size> ] [ timeout < time> ]
27
ZXCTN9000#cfm ltm md < md-session-id> ma <
Configures the sending of Link Tracing
ma-session-id> smep-id < smep-id> { dmep-id
Messages (LTMs)
< dmep-id> | dmep-mac < dmep-mac> |

dmip-mac < dmip-mac> } [ ttl < ttl-count> ] [
timeout < time> ]

Parameter
Description
{enable|disable}
Whether to enable or disable the CFM function

globally (Disabled by default)

Parameter
Description
{0|1}
Whether the CCM packet to be sent by CFM

carries the MD name: 0 indicates that the CCM
packet does not carry the MD name; 1 indicates
that the CCM packet carries the MD name; 0 by
default

Parameter
Description
< session-id>
MD ID, ranging from 1 to 32, which uniquely

identifies an MD
5-4
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< md-name>
MD name, which is a string of at most 13

characters and starts with a letter
< md-level>
MD level, ranging from 0 to 7 (The greater value,

the higher level)
The command parameter in steps 4 and 5 is described as follows:

Parameter
Description
< session-id>
MD ID, ranging from 1 to 32, which uniquely

identifies an MD
The command parameters in steps 6, 7, and 8 are described as follows:

Parameter
Description
< session-id>
MA ID, ranging from 1 to 64, which uniquely

identifies an MA
< ma-name>
MA name, which is a string of at most 13

characters and starts with a letter

Parameter
Description
< session-id>
Session ID of the MEP to be created, ranging

from 1 to 64
< index-id>
MEP ID, ranging from 1 to 8191 (The MEP IDs

including RMEP IDs cannot repeat in the local
MA)
{down | up}
MEP direction, which controls the direction of

MEP packet sending/receiving and detection
corresponding to the forwarding side and the
link side of the device (Currently "up" is not
supported)

Parameter
Description
< session-id>
Session ID of the RMEP to be created, ranging

from 1 to 64
< index-id>
Index ID of the RMEP to be created, ranging

from 1 to 8191
5-5
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< xxxx.xxxx.xxxx>
MAC address of the RMEP, which is 12

hexadecimal digits with every four digits
separated by a dot (It cannot be all-0s, or any
multicast/broadcast address)

Parameter
Description
< session-id>
Session ID of the MIP to be created, ranging from

1 to 64
< mip-name>
Name of the MIP to be created, which is a string

of at most 13 characters and starts with a letter

Parameter
Description
< index-id>
Index ID of the MEP to be deleted
all
Whether to delete all the MEPs from the current

MA
< session-id>
Session ID of the MEP to be deleted

Parameter
Description
< index-id>
Index ID of the MIP to be deleted
all
Whether to delete all the MIPs from the current

MA

Parameter
Description
< index-id>
Index ID of the specified MEP
< interface>
Name of the interface to which the MEP will be

bound
< cip-index>
Index ID of the CIP to which the MEP will be

bound, ranging from 1 to 16384

Parameter
Description
< session-id>
Session ID of the specified MIP

5-6
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< interface>
Name of the interface to which the MIP will be

bound
< cip-index>
Index ID of the CIP to which the MIP will be

bound, ranging from 1 to 16384

Parameter
Description
< protect-type>
Protection type: "vlan" or "link"

Parameter
Description
< vlan-id>
Primary VLAN ID of the MA: 1 to 4094; 0 by

default, indicating that the MA does not include
any VLAN

Parameter
Description
{fast | slow}
Sending speed of the MA: "fast" or "slow"

Parameter
Description
< interval>
CCM packet sending interval, ranging from 1 to 7

(representing 3.3 ms, 10 ms, 100 ms, 1 s, 10 s,
60 s, and 600 s in turn)

Parameter
Description
< index-id>
{enable | disable}
Whether to enable or disable the CFM function of

the MEP (Disabled by default)

Parameter
Description
< index-id>
{enable | disable}
Whether to enable or disable the CCM packet

sending function of the MEP (Disabled by default)
5-7
SJ-20100901100356-020|2011-07-30(R1.0)

Parameter
Description
< index-id>
< priority-value>
Alarm priority, ranging from 1 to 5; 0 by default

(The greater value, the higher priority)

Parameter
Description
< index-id>
< level>
Client level

Parameter
Description
< index-id>
{enable | disable}
Whether to enable or disable the AIS function of

the local MEP

Parameter
Description
< l2vpn-name>
L2VPN instance name, which is a string of at

most 64 characters and starts with a letter

Parameter
Description
< md-session-id>
Session ID of the MD, ranging from 1 to 32
< ma-session-id>
Session ID of the MA, ranging from 1 to 64
< smep-id>
ID of the source MEP sending the LBM, which

ranges from 1 to 8191 and uniquely identifies a
local MEP in an MA
< dmep-id>
ID of the destination MEP, which is the ID of the

RMEP for the local MEP
< dmep-mac>
MAC address of the destination MEP in

xxxx.xxxx.xxxx hexadecimal format
< dmip-mac>
MAC address of the destination MIP in

< count>
The number of times to repeatedly send the LBM,

ranging from 1 to 200 (5 by default)
5-8
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< size>
Length of the Data TLV field carried in the LBM,

ranging from 1 to 400 (0 by default)
< time>
LBM timeout time in seconds: 1 to 10; 3 by default

Parameter
Description
< md-session-id>
< ma-session-id>
< smep-id>
ID of the source MEP sending the LBM, which

ranges from 1 to 8191 and uniquely identifies a
local MEP in an MA
< dmep-id>
ID of the destination MEP, which is the ID of the

RMEP for the local MEP
< dmep-mac>
MAC address of the destination MEP in

< dmip-mac>
MAC address of the destination MIP in

< ttl-count>
TTL value, ranging from 1 to 64 (64 by default)
< time>
Time to stop receiving the LTR message: 5 to 10

seconds; 5 seconds by default
5.3 Maintaining CFM

Use the following commands on ZXCTN 9000 to maintain and diagnose the CFM function:
Command
Function
ZXCTN9000(config)#show cfm status
Shows the global configuration status of CFM
ZXCTN9000(config)#show cfm md { all | session
Shows information about the specified
< md-session-id> }
maintenance domain
ZXCTN9000(config)#show cfm ma { all | session
Shows details about the specified maintenance
< ma-session-id> } md < md-session-id>
association
ZXCTN9000(config)#show cfm mp { all | session
Shows detailed configuration and status
< mp-session-id> } md < md-session-id> ma <
information about the specified MP
ma-session-id> { brief | detail }

ZXCTN9000(config)#show cfm mep { all |
session < mep-session-id> } md < md-session-id>
information about the specified MEP
ma < ma-session-id> { brief | detail }

5-9
SJ-20100901100356-020|2011-07-30(R1.0)
Command
Function
ZXCTN9000(config)#show cfm rmep { all |
session < rmep-session-id> } md < md-session-id>
information about the specified RMEP
ma < ma-session-id> { brief | detail | alarm}

ZXCTN9000#debug cfm pkt { all | megid md
Enables the CFM packet sending/receiving
< md-session-id> ma < ma-session-id> mep <
debugging switch (To disable all the enabled
mep-session-id> } [ direction { all | rcv | send } ] [
switches, use the no form of this command)
pkt-nums < pkt-num-value> ]
The command parameters are described as follows.

Parameter
Description
< md-session-id>

(Specify this parameter to show information about
the specified MD, or use the all parameter to
show information about all MDs)
< ma-session-id>

(Specify this parameter to show information about
the specified MA, or use the all parameter to show
information about all MAs in the specified MD)
< mp-session-id>
Session ID of the MP
< mep-session-id>
Session ID of the MEP
< rmep-session-id>
Session ID of the RMEP
< pkt-num-value>
The number of packets to be shown, ranging

from 10 to 100
The following example shows the outputs of the show cfm status command. This command
is used to show the global status of CFM.
ZXCTN9000#show cfm status
CFM enabled
CFM CCM format without MD name
The outputs of the show cfm status command are described as follows.
Output Item
Description
CFM enabled
Indicates that CFM is globally enabled
CFM CCM format
Indicates whether the CCM packet to be sent by

CFM carries the MD name
The following example shows the outputs of the show cfm md all command.
ZXCTN9000#show cfm md all
MD session 1
5-10
SJ-20100901100356-020|2011-07-30(R1.0)

name:
level:
md1
5
contain MA numbers: 1
The outputs of the show cfm md all command are described as follows:
Output Item
Description
MD session 1
Shows the index value of an MD
name
Name of the MD
level
Level of the MD
contain MA numbers
The number of MAs in the MD
The following example shows the outputs of the show cfm ma all md 1 command.
ZXCTN9000#show cfm ma all md 1
MA session 1
name:
ma1
belong to MD:
primary vlan:
l2vpn:
protect type:
vlan
time interval:
10(s)
speed:
contain MP numbers:
slow
2
The outputs of the show cfm ma all md 1 command are described as follows:
Output Item
Description
MA session 1
Shows the index value of an MA
name
Name of the MA
belong to MD
The MD to which the MA belongs
primary vlan
Primary VLAN ID of the MA
l2vpn
Whether the MA is bound to any L2VPN instance
protect type
Protection type of the MA
time interval
CCM interval of the MA
speed
Speed of the MA
contain MEP numbers
The number of MEPs in the MA, including local

MEPs and RMEPs
5-11
SJ-20100901100356-020|2011-07-30(R1.0)
5.4 CFM Configuration Instances

5.4.1 CFM Fast Continuity Check
As shown in Figure 5-2, P1 and P2 are directly connected to each other. Configure CFM
on the direct connection interfaces of P1 and P2 to establish a connection between P1 and
P2.
Figure 5-2 CFM Connection Establishment
1. Create an ME and MA with the same name and the same ID on P1 and P2, and globally
enable CFM.
2. Create a local MEP of the same level on the direct connection interfaces of P1 and
P2, and create a remote MEP using the peer MAC and MEP ID. Then enable the local
MEP and CCM packet sending as well as the remote MEP.
3. Run the show cfm mp command on P1 and P2 to check the MEP flag bit and the status
of CFM connection establishment between P1 and P2.
4. Perform cfm linktrace and cfm loopback operations on the MEP of P2 from P1 to
check link connectivity.
P1(config-md1-ma1)#create rmep session 2 2 remote-mac 0025.1210.9720
5-12
SJ-20100901100356-020|2011-07-30(R1.0)

P1(config-md1-ma1)#end

P2(config-md1-ma1)#create rmep session 2 1 remote-mac 0818.1a94.0470
P2(config-md1-ma1)#end
1. Run the show cfm mp all md 1 ma 1 command on P1 to check the status of the link.
P1(config)#show cfm mp all md 1 ma 1 brief
MP session 1
type: local mep
direction: down
mep id: 1
admi state: enable
ccm send state: enable
mep priority: 7
mep client-level: 0
mep ais state: disable
lowest alarm priority: 1
assign port: gei_1/1
MP session 2
type: remote mep
mep id: 2
remote mac: 0025.1210.9720
P1(config)#show cfm mp all md 1 ma 1 detail
MP session 1
type: local mep
direction: down
mep id: 1
5-13
SJ-20100901100356-020|2011-07-30(R1.0)

admi state: enable
mep priority: 7
mep client-level: 0
mep ais local flag: 0
mep ais remote flag: 0
DefXconCCM:0
DefUnexpectedMepId:0
DefUnexpectedPeriod:0
DefRemoteCCM:0
DefRDICCM:0
MP session 2
type: remote mep
mep id: 2
remote mac: 0025.1210.9720
DefRemoteCCM:0
DefRDICCM:0
2. Run the show cfm mp all md 1 ma 1 command on P2 to check the status of the link.
P2(config)#show cfm mp all md 1 ma 1 brief
MP session 1
type: local mep
direction: down
mep id: 2
admi state: enable
mep priority: 7
mep client-level: 0
MP session 2
type: remote mep
mep id: 1
remote mac: 0818.1a94.0470
P2(config)#show cfm mp all md 1 ma 1 detail

MP session 1
type: local mep
direction: down
mep id: 2
5-14
SJ-20100901100356-020|2011-07-30(R1.0)

admi state: enable
mep priority: 7
mep client-level: 0
mep ais local flag: 0

mep ais remote flag: 0
DefXconCCM:0
DefUnexpectedMepId:0
DefUnexpectedPeriod:0
DefRemoteCCM:1
DefRDICCM:0
MP session 2
type: remote mep
mep id: 1
remote mac: 0818.1a94.0470
DefRemoteCCM:0
DefRDICCM:0
3. Run the cfm lbm command on P1 and P2 to check the continuity of the link.
P1#cfm lbm md 1 ma 1 smep-id 1 dmep-id 2
Sending 5 loopback messages to 0025.1210.9720,timeout is 3 seconds.
!!!!!
Success rate is 100 percent(5/5),round-trip min/avg/max= 2/4/7 ms.
P2#cfm lbm md 1 ma 1 smep-id 2 dmep-id 1

Sending 5 loopback messages to 0818.1a94.0470,timeout is 3 seconds.
!!!!!
Success rate is 100 percent(5/5),round-trip min/avg/max= 2/5/8 ms.
4. Run the cfm ltm command on P1 and P2 to check the continuity of the link.
P1#cfm ltm md 1 ma 1 smep-id 1 dmep-id 2
Linktrace to 0025.1210.9720: timeout 5 seconds, 64 hops, trans-id 1.
Please wait 5 seconds to print the result.
-----------------------------------------------------------------------------Hops
MAC ADDRESS
Ingress Action
Egress Action
Relay Action
-----------------------------------------------------------------------------1
0025.1210.9720
IngOK
RlyHit
Destination 0025.1210.9720 reached.
P2#cfm ltm md 1 ma 1 smep-id 2 dmep-id 1
5-15
SJ-20100901100356-020|2011-07-30(R1.0)

Linktrace to 0818.1a94.0470: timeout 5 seconds, 64 hops, trans-id 1.
Please wait 5 seconds to print the result.
-----------------------------------------------------------------------------Hops
MAC ADDRESS
Ingress Action
Egress Action
Relay Action
-----------------------------------------------------------------------------1
0818.1a94.0470
IngOK
RlyHit
Destination 0818.1a94.0470 reached.
5.4.2 Inter-L2VPN Continuity Check

In an L2VPN network as shown in Figure 5-3, CFM MEPs are configured on CE1, PE1,
PE2, and CE2 to detect the connectivity of the CE1-PE1-PE2-CE2 path.
Figure 5-3 Inter-L2VPN Connectivity Check
1. Configure an MD and an MA with the same name and the same ID on CE1, CE2, PE1,
and PE2.
2. Configure the interfaces of CE1 and CE2 as a pair of CFM CC groups with reference
to the configuration instance of CFM fast continuity check as described previously.
Enable the alarm function on CE1 and CE2.
3. Configure MIPs for the public network interface and AC-side interfaces of PE1 and
PE2, and globally enable the CFM function on PE1 and PE2.
4. Perform cfm linktrace and cfm loopback operations on the MIPs and MEPs of PE1,
PE2, and CE2 from CE1 to check link connectivity.
5-16
SJ-20100901100356-020|2011-07-30(R1.0)
Run the following configuration commands on CE1:
CE1#configure terminal
CE1(config)#cfm enable
CE1(config)#cfm create md session 1 name MD1 level 5
CE1(config-md1)#ma create session 1 name MA1
CE1(config-md1-ma1)#speed fast
CE1(config-md1-ma1)#protect vlan
CE1(config-md1-ma1)#primary vlan 2
CE1(config-md1-ma1)#ccm time-interval 2
CE1(config-md1-ma1)#create mep session 1 1 direction down
CE1(config-md1-ma1)#assign mep 1 to interface gei_4/2
CE1(config-md1-ma1)#mep 1 state enable
CE1(config-md1-ma1)#mep 1 ccm-send enable
CE1(config-md1-ma1)#mep 1 alarm-lowest-pri 1
CE1(config-md1-ma1)#create rmep session 2 2 remote-mac 0025.1210.9720
CE1(config-md1-ma1)#end
Run the following configuration commands on CE2:

CE2#configure terminal
CE2(config)#cfm enable
CE2(config)#cfm create md session 1 name MD1 level 5
CE2(config-md1)#ma create session 1 name MA1
CE2(config-md1-ma1)#speed fast
CE2(config-md1-ma1)#protect vlan
CE2(config-md1-ma1)#primary vlan 2
CE2(config-md1-ma1)#ccm time-interval 2
CE2(config-md1-ma1)#create mep session 1 2 direction down
CE2(config-md1-ma1)#assign mep 2 to interface gei_2/2
CE2(config-md1-ma1)#mep 2 state enable
CE2(config-md1-ma1)#mep 2 ccm-send enable
CE2(config-md1-ma1)#mep 2 alarm-lowest-pri 1
CE2(config-md1-ma1)#create rmep session 2 1 remote-mac 0818.1a94.0470
CE2(config-md1-ma1)#end
Run the following configuration commands on PE1:

PE1#configure terminal
PE1(config)#cfm enable
PE1(config)#cfm create md session 1 name MD1 level 5
PE1(config-cfm-md)#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_3/6
PE1(config-cfm-ma)#end
5-17
SJ-20100901100356-020|2011-07-30(R1.0)
Run the following configuration commands on PE2:

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
Perform cfm linktrace and cfm loopback operations on the MIPs and MEPs of PE1, PE2,
and CE2 from CE1 to check link connectivity. If the link is normal, the trace and ping packet
reply should be correct. If the link worsens, CFM alarms will be generated on CE1 and
CE2. The following example shows how to perform ping and trace operations from CE2
to CE1.
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_2/3 on level 4.
---------------------------------------------------------------------------
Hops
MAC ADDRESS
Forwarded
Ingress Action
Egress Action
Relay 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 complet
5-18
SJ-20100901100356-020|2011-07-30(R1.0)
5.5 CFM Troubleshooting

A common problem with CFM in actual networking is that CFM detects link interruption
when the link is actually normal. This section describes the cause of such faults and
relevant solutions by taking the link detection from CE1 to CE2 shown in Figure 5-4 as an
example.
Figure 5-4 Network Topology for CFM Troubleshooting

When link detection between CE1 and CE2 fails, the following causes are possible:
l
l
l
l
The name or ID of the MD/MA configured on CE1 is not the same as that configured
on CE2.
The local MEP level configured on CE1 is not the same as that configured on CE2.
The MAC address corresponding to the remote MEP configured on CE1/CE2 is not
the peer MAC address.
The MIP level configured on PE1/PE2 is higher than that configured on CE1/CE2.
5.5.3 Handling Flow

Figure 5-5 shows a flow chart for handling the CFM connection establishment failure.
5-19
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 5-5 CFM Fault Handling Flow

To handle common CFM faults, perform the following steps:
1. Run the show cfm mp command on CE1 and CE2 to check whether the names of the
MD and MA configured on CE1 are consistent with those on CE2.
2. Run the show cfm mp command on CE1 and CE2 to check whether the level of the
MEP configured on CE1 is consistent with that on CE2.
3. Run the show cfm mp command on CE1 and CE2 to check whether the MIP level is
higher than that configured on CE1 and CE2.
5-20
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 6
BFD Configuration
Table of Contents
Overview of BFD ........................................................................................................6-1
Configuring BFD.........................................................................................................6-1
Maintaining BFD.........................................................................................................6-7
BFD Configuration Instances......................................................................................6-9
BFD Troubleshooting................................................................................................6-28
6.1 Overview of BFD

BFD is a simple hello protocol similar to the hello mechanism of routing protocols. It is much
simpler and more universal. The two systems establishing a BFD session with each other
periodically send packets to each other. If one system does not receive any packet from the
peer system within the negotiated time, it considers that the communication channel with
the peer system fails and the BFD session is down, and so sends a notification packet to
the upper-layer protocol to reselect a route. To alleviate device load, BFD is also designed
with some special application modes. In such application modes, fewer BFD packets are
sent or it is unnecessary to periodically send BFD packets, that is, BFD packets are sent
only when necessary.
6.2 Configuring BFD

6.2.1 Configuring Interface BFD
Use the following commands on ZXCTN 9000 to configure interface BFD:
Step
Command
Function
ZXCTN9000(config)#ip static-bfd <
Statically creates a BFD session
src-ip-address> < dst-ip-address> [ <

interface-name> ] [ vrf < vrf-name> ]
2
Enters the interface for which session
interface-name>
parameters are to be configured
ZXCTN9000(config-if-vlan)#bfd interval
Configures the packet sending/receiving
< interval> min_rx < min_rx> multiplier <
interval and detection multiplier of the BFD
multiplier>
session on the interface

6-1
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< src-ip-address>
Source address of the session, which must be a

local address
< dst-ip-address>
Destination address of the session, which is not

restricted to a direct connection interface address
< interface-name>
Egress interface of the session (If this parameter

is not specified, the local device does not care
about the egress when sending a packet, as long
as the packet can be sent out of the local device)
< vrf-name>
VRF of the interface

Parameter
Description
< interface-name>
Specifies the interface for which the packet

sending/receiving interval and detection multiplier
of the BFD session will be configured

Parameter
Description
< interval>
Time interval at which detection packets are sent
< min-rx-interval>
Minimum time interval at which detection packets

are received
< multiplier>
Detection multiplier
6.2.2 Configuring Static BFD

Use the following commands on ZXCTN 9000 to configure static BFD:
Step
Command
Function
ZXCTN9000(config)#bfd session <
Enters a static BFD session
session-name>
2
ZXCTN9000(config-bfd)#bind < bfd-type>
Configures the session type and egress
peer-ip < peer-address> interface <
interface in BFD configuration mode
interface-name>
3
ZXCTN9000(config-bfd)#discriminator-local
Configures the local discriminator
< ld>
4
ZXCTN9000(config-bfd)#discriminator-rem
Configures the remote discriminator
ote < rd>

6-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 6 BFD Configuration

Parameter
Description
< session-name>
BFD session, which is a string of 1 to 64

characters

Parameter
Description
< bfd-type>
BFD type: "link" or "peer"
< peer-address>
Peer address, which can be the default address

or a multicast address
< interface-name>
Egress interface

Parameter
Description
< ld>
Local discriminator in the range of 1 to 16383

Parameter
Description
< rd>
Remote discriminator in the range of 1 to 16383
6.2.3 Configuring OSPF BFD

Use the following commands on ZXCTN 9000 to configure OSPF BFD:
Step
Command
Function
ZXCTN9000(config)#router ospf < process-id>
Creates an OSPF process or enters the

specified OSPF process
ZXCTN9000(config-router)#bfd-all-interf
Enables the BFD function on all interfaces
ace
3
Enters the specified interface
interface-name>
4
ZXCTN9000(config-if-vlan)#ip ospf bfd [
Enables the BFD function on the specified
disable]
interface (To disable the BFD function on the

specified interface, use the no form of this
command)

6-3
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
process-id
OSPF process ID, that is, the configured OSPF

instance ID, ranging from 1 to 65535

Parameter
Description
interface-name
Name of the interface on which the BFD function

will be enabled
Users can enable the BFD function on all interfaces in OSPF configuration mode, or enter
a certain interface to enable the BFD function on that interface.
6.2.4 Configuring IS-IS BFD

Use the following commands on ZXCTN 9000 to configure IS-IS BFD:
Step
Command
Function
ZXCTN9000(config)#router isis [ vrf <
Creates an IS-IS routing protocol process or
vrf-name> ]
enters the IS-IS routing protocol process if

it already exists
Enters the interface on which the BFD
interface-name>
function will be enabled
ZXCTN9000(config-if-vlan)#isis bfd-enable
Enables the IS-IS BFD function (To disable

the function, use the no form of this
command)

Parameter
Description
< vrf-name>
VRF name, which is a string of 1 to 32 characters

Parameter
Description
< interface-name>
Name of the interface on which the BFD will be

enabled
The BFD function can be enabled on an IS-IS-enabled interface. When the interface
establishes an IS-IS adjacency with the peer interface, a BFD session based on the IS-IS
protocol is established on the direct link composed of the two neighboring interfaces.
6-4
SJ-20100901100356-020|2011-07-30(R1.0)
6.2.5 Configuring BGP BFD

Use the following commands on ZXCTN 9000 to configure the BGP BFD function:
Step
Command
Function
ZXCTN9000(config)#router bgp < as-number>
Configures the BGP module
ZXCTN9000(config-router)#neighbor
Enables the Bidirectional Forwarding
{ < ipv4-address> | < ipv6-address> | <
Detection (BFD) mechanism (To disable the
peer-group-name> } fall-over bfd [ interval<
BFD mechanism, use the no form of this
interval r> min-rx< min-rx-interval >
command)
multiplier< multiplier> ]

Parameter
Description
< as-number>
The number of the AS to which ZXCTN9000,

ranging from 1 to 65535

Parameter
Description
< ipv4-address>
IPv4 address of the neighbor in dotted decimal

format
< ipv6-address>
IPv6 address of the neighbor
< peer-group-name>
Name of the peer group
< interval>
Time interval at which detection packets are sent
< min-rx-interval>
Minimum time interval at which detection packets

are received
< multiplier>
Detection multiplier
The single-hop BFD mechanism (for a direct connection link) or the multi-hop BFD
mechanism (for non-direct connection links) can be configured, depending on whether
BGP neighbors are directly connected or not directly connected.
6.2.6 Configuring LDP BFD

Use the following command on ZXCTN 9000 to configure LDP BFD:
Step
1
Command
Function
ZXCTN9000(config)#mpls ldp bfd < FEC
Configures parameters related to LDP
address> < mask length> interval < interval>
LSP BFD and triggers LSP BFD session
min_rx < min_rx> multiplier < multiplier>
establishment
6-5
SJ-20100901100356-020|2011-07-30(R1.0)
It is only necessary to unidirectionally configure LDP BFD. Specify the LSP remote
address during the configuration. The LDP BFD session in the reverse direction will be
automatically established, with the destination being the remote LDP discovery source.
Parameter
Description
< FEC address>
LSP address for BFD establishment, which is

generally a remote address segment
< masklength>
Subnet mask length of the remote network

segment in the range of 1 to 32
< interval>
Expected minimum packet sending interval in ms

in the range of 3 to 999
< min_rx>
Expected minimum packet receiving interval in

ms in the range of 3 to 999
< multiplier>
Detection timeout multiplier in the range of 3 to 50
6.2.7 Configuring RSVP Interface BFD

Use the following commands on ZXCTN 9000 to configure RSVP interface BFD:
Step
Command
Function
Specifies the interface on which the BFD
interface-name>
function will be enabled
ZXCTN9000(config-if-vlan)#ip rsvp bfd
Triggers RSVP BFD session establishment

Parameter
Description
< interface-name>
Name of the interface on which the BFD function

will be enabled
6.2.8 Configuring RSVP LSP BFD

Use the following command on ZXCTN 9000 to configure RSVP LSP BFD:
Step
Command
Function
ZXCTN9000(config)#tunnel < tunnel-id>
Specifies the tunnel interface on which the

BFD function will be enabled
ZXCTN9000(config-tunnel)#tunnel mpls
Triggers RSVP BFD session establishment
traffic-eng bfd interval < interval> min_rx <

min_rx> multiplier < multiplier>
6-6
SJ-20100901100356-020|2011-07-30(R1.0)

Parameter
Description
< tunnel-id>
Tunnel ID

Parameter
Description
< interval>
Sending interval of detection packets in ms in the

range of 3 to 999
< min-rx-interval>
Minimum receiving interval of detection packets

in ms in the range of 3 to 999
< multiplier>
Detection multiplier in the range of 3 to 50
6.2.9 Configuring PW BFD

Use the following command on ZXCTN 9000 to configure PW BFD:
Command
Function
ZXCTN9000(config)#mpls pw bfd < peer address>
Configures parameters related to PW BFD and
< vcid> interval < interval> min-rx < min-rx>
triggers PW BFD session establishment
multiplier < multipiler>

Parameter
Description
< peer address>
Peer address of the PW
< vcid>
VC ID in the range of 1 to 4294967294
< interval>
Expected minimum packet sending interval in ms

in the range of 3 to 999
< min_rx>
Expected minimum packet receiving interval in

ms in the range of 3 to 999
< multiplier>
Detection timeout multiplier in the range of 3 to 50
6.3 Maintaining BFD

Use the following commands on ZXCTN 9000 to maintain and diagnose the BFD function:
6-7
SJ-20100901100356-020|2011-07-30(R1.0)
Command
Function
ZXCTN9000#debug bfd packet
Shows summary information about the packets

sent and received for link establishment during
BFD session establishment
Shows information about BFD session status
ZXCTN9000#debug bfd event
changes during BFD session establishment

Shows information about the packets sent
ZXCTN9000#debug bfd byte
and received for link establishment (Packets

in the UDP data area) during BFD session
establishment
Shows summary information about BFD sessions
ZXCTN9000#show bfd neighbors pw
of the PW type
ZXCTN9000#show bfd neighbors ldp-lsp
of the LDP type

ZXCTN9000#show bfd neighbors rsvp-lsp
of the RSVP type

ZXCTN9000#show bfd neighbors tunnel
of the tunnel type
The following example shows the outputs of the BFD-related commands.

ZXCTN9000#show bfd neighbors detail
OurAddr
NeighAddr
12.12.12.1 12.12.12.2
LD
RD
Hold
364 150
State
UP
Int
vlan10
------------------------------------------------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: 85
Rx Interval (ms) min/max/avg: 50
/50
/50
Tx Count: 169
Tx Interval (ms) min/max/avg: 50
/50
/50
Registered protocols: STATIC

Session name: N/A
Uptime: 0 DAYS,0 HOURS,0 MINUTES
Last packet: Version: 1 Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 7
Your Discr: 364
Min tx interval: 50
Min rx interval: 50
Min Echo interval: N/A
Delay up status: OFF
Long packet transmit: OFF

Transmit:IP length 1~256:
Long packet receive: OFF

N/A
IP length 257~512:
IP length 513~1024: N/A
N/A
6-8
SJ-20100901100356-020|2011-07-30(R1.0)

Received:IP length 1~256:
N/A
IP length 257~512:
N/A
====================================================================
ZXCTN9000#debug bfd byte

BFD byte debugging has been turned on
BFD:02:08:51:OUT,
20 40 03 18 00 00 00 05 00 00 00 00 00 11 CA B0
00 11 CA B0 00 00 00 00
Nov 17 02:08:51:
BFD:02:08:51:IN,
45 00 00 34 CB 3C 00 00 FF 11 C0 61 0C 0C 0C 02
0C 0C 0C 01 C1 6A 0E C8 00 20 87 56 20 80 03 18
00 00 01 6B 00 00 00 05 00 19 29 68 00 19 29 68
00 00 00 00
ZXCTN9000#debug bfd packet

BFD packet debugging has been turned on
Nov 17 02:07:14:
BFD:02:07:14:IN,src:12.12.12.2,dst:12.12.12.1,plen:24,
BFD:diag 0,D/P/F:0/0/0,mult 3,len 24,loc/rem disc 361/0,
tx 1370000,rx 1370000,state DOWN
Nov 17 02:07:14:
BFD:02:07:14:OUT,src:12.12.12.1,dst:12.12.12.2,plen:24,
tx 1837000,rx 1837000,state INIT
Nov 17 02:07:14:
BFD:02:07:14:IN,src:12.12.12.2,dst:12.12.12.1,plen:24,
tx 50000,rx 50000,state UP
Nov 17 02:07:14:
BFD:02:07:14:OUT,src:12.12.12.1,dst:12.12.12.2,plen:24,
tx 50000,rx 50000,state UPrx: 50
6.4 BFD Configuration Instances

6.4.1 Interface BFD Configuration Example
As shown in Figure 6-1, interface BFD is configured on both P1 and P2.
6-9
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 6-1 Interface BFD
1. Configure interface BFD on P1.
2. Configure interface BFD on P2.
P1(config)#interface
loopback1
P1(config-loopback1)#ip address 172.20.96.1 255.255.255.255

P1(config-loopback1)#exit

loopback1

A BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether static BFD has taken effect.
Check whether static BFD has taken effect on P1:
P1(config)#show bfd
OurAddr
172.20.130.213
neighbors detail
NeighAddr
172.20.130.214
LD
RD
Hold
150
State
UP
Int
vlan99
------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Holdown : 150
6-10
SJ-20100901100356-020|2011-07-30(R1.0)

Rx Count: 55
/50
/50
Tx Count: 68
/50
/50
Registered protocols: STATIC

Session name: N/A
Last packet: Version: 1
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 1
Your Discr: 1
Min tx interval: 50
Min rx interval: 50


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
===========================================================================
6.4.2 Static BFD Configuration Example

As shown in Figure 6-2, static BFD is configured on both P1 and P2.
Figure 6-2 A Configuration Example of Static BFD
1. Configure static BFD on P1.
2. Configure static BFD on P2.
P1(config)#bfd session 1
P1(config-bfd)#bind link-bfd peer-ip default-ip interface gei_2/1
P1(config-bfd)#discriminator-local 250
6-11
SJ-20100901100356-020|2011-07-30(R1.0)

P1(config-bfd)#discriminator-remote 500

P2(config)#bfd session 1
P2(config-bfd)#bind link-bfd peer-ip default-ip interface gei_1/1
P2(config-bfd)#discriminator-local 500
P2(config-bfd)#discriminator-remote 250
Run the show bfd neighbors detail command to check whether static BFD has taken effect.
Check whether static BFD has taken effect on P1:
P1(config)#show bfd neighbors detail
OurAddr
NeighAddr
1.1.1.1
172.20.130.214
LD
RD
500
250
Hold
0
State Int
up
gei_4/4
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 1890
MinRxInt: 1890
Multiplier: 3
Holdown : 0
Rx Count: 254441
/50
/50
Tx Count: 339315
/50
/50
Registered protocols: STATIC-SESSION

Session name: 1
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 500
Your Discr: 250
Min tx interval: 1890
Min rx interval: 1890


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
===========================================================================
6-12
SJ-20100901100356-020|2011-07-30(R1.0)
6.4.3 OSPF BFD Configuration Example

As shown in Figure 6-3, the OSPF protocol runs between P1 and P2, and the BFD function
is enabled on the protocol interfaces of P1 and P2.
Figure 6-3 A Configuration Example of OSPF BFD
1. Run the OSPF protocol between P1 and P2.
2. Enable the BFD function on the protocol interfaces of P1 and P2.
P1(config)#router ospf 1
P1(config-router)#network 172.20.130.0 0.0.0.255 area 0.0.0.0
P1(config-router)#bfd-all-interface
P1(config-router)#exit
P1(config-if-vlan11)#ip ospf bfd

P2(config-router)#bfd-all-interface
P2(config-if-vlan11)#ip ospf bfd
6-13
SJ-20100901100356-020|2011-07-30(R1.0)
An OSPF BFD session can be successfully established after the configuration.
Run the show bfd neighbors brief command to check whether OSPF BFD has taken effect.
Check whether OSPF BFD has taken effect on P1:
P1(config)#show bfd neighbors brief
OurAddr
NeighAddr
LD
172.20.130.213 172.20.130.214 9
RD
Hold
150
State
UP
Int
vlan11
Check whether OSPF BFD has taken effect on P2:

OurAddr
172.20.130.214
NeighAddr
172.20.130.213
LD
RD
Hold
150
State
Int
UP
vlan11
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Holdown : 150
Rx Count: 0
/0
/0
Tx Count: 0
/0
/0
Registered protocols: OSPF

Session name: N/A
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 14
Your Discr: 14
Min tx interval: 50
Min rx interval: 50


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
6.4.4 IS-IS BFD Configuration Example

As shown in Figure 6-4, the IS-IS protocol runs between P1 and P2, and the BFD function
6-14
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 6-4 A Configuration Example of IS-IS BFD
1. Run the IS-IS protocol between P1 and P2.
P1(config)#router isis
P1(config-router)#area 49.0172
P1(config-router)#system-id 0020.0096.0001
P1(config-if-vlan11)#ip router isis
P1(config-if-vlan11)#isis bfd-enable
P1(config-if-vlan11)#end

P2(config)#router isis
P2(config-router)#area 49.0172
P2(config-router)#system-id 0020.0096.0002
P2(config-if-vlan11)#ip router isis
P2(config-if-vlan11)#isis bfd-enable
P2(config-if-vlan11)#end
An IS-IS BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether IS-IS BFD has taken effect.
Check whether IS-IS BFD has taken effect on P1:
6-15
SJ-20100901100356-020|2011-07-30(R1.0)

OurAddr
NeighAddr
172.20.130.213
172.20.130.214
LD
RD
Hold
State
Int
150
UP
vlan11
-----------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Holdown : 150
Rx Count: 124
/50
/50
Tx Count: 98
/50
/50
Registered protocols: ISIS

Session name: N/A
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
My Discr: 2
Your Discr: 2
Min tx interval: 50
Min rx interval: 50
Final bit: 0


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
============================================================================
6.4.5 BGP BFD Configuration Example

As shown in Figure 6-5, the BGP protocol runs between P1 and P2, and the BFD function
Figure 6-5 A Configuration Example of BGP Single-Hop BFD
1. Run the BGP protocol between P1 and P2.
6-16
SJ-20100901100356-020|2011-07-30(R1.0)
loopback1

P1(config)#router bgp 100
P1(config-bgp)#neighbor 10.1.1.2 remote-as 200
P1(config-bgp)#network 172.20.96.1 255.255.255.255
P1(config-bgp)#neighbor 172.20.96.2
fall-over bfd
P1(config-bgp)#exit

loopback1

P2(config)#router bgp 200
P2(config-bgp)#neighbor 10.1.1.1 remote-as 100
P2(config-bgp)#network 172.20.96.2 255.255.255.255
P2(config-bgp)#neighbor 172.20.96.1
fall-over bfd
P2(config-bgp)#exit
A BGP BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether BGP BFD has taken effect.
Check whether BGP BFD has taken effect on P1:
P1(config-router)#show bfd neighbors detail
OurAddr
NeighAddr
LD
RD
10.1.1.2
10.1.1.1
Hold
State
30
UP
Int
vlan10
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 3
Multiplier: 3
Holdown : 30
Rx Count: 1317
/3
/3
Tx Count: 1411
/10
/10
Registered protocols: BGP

Session name: N/A
6-17
SJ-20100901100356-020|2011-07-30(R1.0)

Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 1
Your Discr: 3
Min tx interval: 10
Min rx interval: 3


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
============================================================================
6.4.6 LDP BFD Configuration Example

As shown in Figure 6-6, it is only necessary to enable the BFD function on one of the nodes
that have established an LDP adjacency with each other in LDP mode. The BFD-enabled
node is the session initiator, and the other node is the supplicant. If the BFD versions on
the two nodes are consistent, a BFD session can be successfully established.
Figure 6-6 A Configuration Example of LDP BFD
1.
2.
3.
4.
Enable the MPLS hop-by-hop forwarding function on the link between P1 and P2.
Configure LDP label distribution between P1 and P2.
Specify the IP address of the loopback interface as the LSR ID.
LDP BFD configuration is required on only one node. Therefore, specify P1 as the
initiator and configure an LDP BFD session on P1.
6-18
SJ-20100901100356-020|2011-07-30(R1.0)

P1(config)#mpls ip
P1(config-if-vlan11)#mpls ip
P1(config)#mpls ldp bfd 172.20.130.214 32 interval 10 min-rx 3 multiplier 3

P2(config)#mpls ip
P2(config-if-vlan11)#mpls ip
P2(config)#mpls ldp bfd 172.20.130.213 32 interval 10 min-rx 3 multiplier 3
An LDP BFD session can be successfully established after the configuration.
Run the show bfd neighbors detail command to check whether LDP BFD has taken effect.
Check whether LDP BFD has taken effect on P1:
P1#show bfd n d
Dest
18.18.18.18
Prefixlen
32
LD
RD
Hold
35
41
150
State
Int
UP
vlan11
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 10
Multiplier: 3
Holdown : 150
Rx Count: 422
/10
/10
Tx Count: 673
/50
/50
Registered protocols: LDP LSP

Session name: N/A
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Final bit: 0
6-19
SJ-20100901100356-020|2011-07-30(R1.0)

Multiplier: 3
Length: 24
My Discr: 35
Your Discr: 41
Min tx interval: 10
Min rx interval: 10


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
IP length 1025~1500: N/A:
6.4.7 RSVP Interface BFD Configuration Example

As shown in Figure 6-7, an IS-IS TE tunnel is established between P1 and P2, and the
BFD function is enabled on the RSVP TE interfaces of P1 and P2.
Figure 6-7 A Configuration Example of RSVP Interface BFD
1. Establish an IS-IS TE tunnel between P1 and P2.
2. Enable the BFD function on the TE interfaces of P1 and P2.
P1(config-router)#mpls traffic-eng router-id loopback1
P1(config-router)#mpls traffic-eng area 0.0.0.0
P1(config)#vlan 10
P1(config-vlan10)#exit
6-20
SJ-20100901100356-020|2011-07-30(R1.0)

P1(config-if-vlan10)#mpls traffic-eng tunnels
P1(config)#mpls ip
P1(config)#mpls traffic-eng tunnels
P1(config)#ip explicit-path identifier 1 next-address 10.1.1.2 strict
P1(config)#interface tunnel4000
P1(config-tunnel4000)#tunnel mode mpls traffic-eng
P1(config-tunnel4000)#ex
P1(config-if-vlan10)#mpls traffic-eng backup-path tunnel4000
P1(config-if-vlan10)#ip rsvp bfd
P1(config-if-vlan10)#ex

P2(config)#vlan 10
P2(config)#mpls ip
P2(config-if-vlan10)#mpls traffic-eng backup-path tunnel4000
P2(config-if-vlan10)#ip rsvp bfd
P2(config-if-vlan10)#ex
An RSVP interface BFD session can be successfully established on P1 after the
configuration.
6-21
SJ-20100901100356-020|2011-07-30(R1.0)
Run the show bfd neighbors detail command to check whether RSVP interface BFD has
taken effect.
Check whether RSVP interface BFD has taken effect on P1:
OurAddr
NeighAddr
LD
RD
Hold
10.1.1.1
10.1.1.2
30
State
UP
Int
vlan10
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 10
Multiplier: 3
Holdown : 30
Rx Count: 50130
/10
/10
Tx Count: 50179
/10
/10
Registered protocols: RSVP

Session name: N/A
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
Final bit: 0
My Discr: 1
Your Discr: 1
Min tx interval: 10
Min rx interval: 10


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
===========================================================================
6.4.8 RSVP LSP BFD Configuration Example

As shown in Figure 6-8, the RSVP LSP BFD mechanism uses BFD to detect RSVP LSPs.
It can be combined with the hot standby function to switch tunnel traffic to the protection
LSP when the working LSP fails.
6-22
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 6-8 A Configuration Example of RSVP LSP BFD
1. Enable OSPF TE between P1 and P2.
2. Configure a tunnel on P1, and enable the BFD function on this tunnel.
P1(config)#vlan 10
P1(config)#mpls ip
P1(config)#tunnel 4000
P1(config-tunnel4000)#tunnel mpls traffic-eng bfd interval 10 min_rx 3 multiplier 3
6-23
SJ-20100901100356-020|2011-07-30(R1.0)


P2(config)#vlan 10
P2(config)#mpls ip
P2(config-tunnel4000)#tunnel mode traffic-engineer dynamic
P2(config-tunnel4000)#tunnel mpls traffic-eng bfd interval 10 min_rx 3 multiplier 3
Tunnel 1 on P1 is up, and an RSVP LSP BFD session can be successfully established on
P1 after the configuration is completed.
Run the show bfd neighbors detail command to check whether RSVP LSP BFD has taken
effect.
Check whether RSVP LSP BFD has taken effect on P1:
Tunnel
LD
RD
Hold
State Int
tunnel2
150
UP
vlan10
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 3
Multiplier: 3
Holdown : 150
Rx Count: 70
/3
/3
Tx Count: 46
/50
/50
Registered protocols: RSVP LSP

Session name: N/A
Diagnostic: 0
6-24
SJ-20100901100356-020|2011-07-30(R1.0)

Demand bit: 0
Poll bit: 0
Final bit: 0
Multiplier: 3
Length: 24
My Discr: 2
Your Discr: 2
Min tx interval: 10
Min rx interval: 3


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
============================================================================
OurAddr
NeighAddr
LD
RD
Hold
State Int
10.1.1.1
10.1.1.2
150
UP
vlan10
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 50
MinRxInt: 50
Multiplier: 3
Holdown : 150
Rx Count: 77403
/50
/50
Tx Count: 77329
/50
/50
Registered protocols: RSVP

Session name: N/A
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
My Discr: 1
Your Discr: 1
Min tx interval: 50
Min rx interval: 50
Final bit: 0


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
============================================================================
6.4.9 PW BFD Configuration Example

As shown in Figure 6-9, PW BFD is configured on both P1 and P2.
6-25
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 6-9 A Configuration Example of PW BFD
1. Configure PW BFD on P1.
2. Configure PW BFD on P2.
P1(config)#vlan 10
P1(config)#vlan 20
P1(config)#mpls ip
P1(config-tunnel4000)#tunnel enable
P1(config-tunnel4000)#tunnel destination 2.2.2.2
6-26
SJ-20100901100356-020|2011-07-30(R1.0)

P1(config-tunnel4000)#tunnel mpls traffic-eng path-option 1 explicit-path identifier 2
P1(config-tunnel4000)#exit
P1(config)#pw 1
P1(config-pw)#mode dynamic pwe3
P1(config-pw)#pwtype ethernet
P1(config-pw)#apply pw-class 1
P1(config-pw)#peer 2.2.2.2 vcid
P1(config-pw)#tunnel 4000
P1(config-pw)#exit

P2(config)#vlan 10
P2(config)#vlan 20
P2(config)#mpls ip
P2(config-tunnel4000)#tunnel enable
P2(config-tunnel4000)#tunnel destination 1.1.1.1
P2(config-tunnel4000)#tunnel mpls traffic-eng path-option 1 explicit-path identifier 2
P2(config-tunnel4000)#exit
P2(config)#pw 1
6-27
SJ-20100901100356-020|2011-07-30(R1.0)

P2(config-pw)#mode dynamic pwe3
P2(config-pw)#pwtype ethernet
P2(config-pw)#apply pw-class 1
P2(config-pw)#peer 1.1.1.1 vcid
P2(config-pw)##exit
Run the show bfd neighbors brief command to check whether PW BFD has taken effect.
Check whether PW BFD has taken effect on P1:
VcId
PeerAddr
LD
RD
Hold
State
2.2.2.2
30
UP
Int
--
---------------------------------------------------------------------------Local Diag: 0
Demand mode: 0
Poll bit: 0
MinTxInt: 10
MinRxInt: 3
Multiplier: 3
Holdown : 30
Rx Count: 2
/3
/3
Tx Count: 2557
/10
/10
Registered protocols: PW
Session name: N/A
Diagnostic: 0
Demand bit: 0
Poll bit: 0
Multiplier: 3
Length: 24
My Discr: 1
Your Discr: 1
Min tx interval: 10
Min rx interval: 3
Final bit: 0


N/A
IP length 257~512:

N/A
N/A
IP length 257~512:
N/A
============================================================================
6.5 BFD Troubleshooting

This section describes BFD troubleshooting by taking the topology shown in Figure 6-10
as an example.
6-28
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 6-10 Network Topology for BFD Troubleshooting

When BFD session creation fails, first check whether the routing protocol has successfully
established neighbors and then whether BFD is bidirectionally configured. Ensure that
BFD is bidirectionally configured. For single-hop BFD, ensure that BFD is bidirectionally
configured. For multi-hop BFD, first check whether neighbors are successfully established
and then whether BFD is bidirectionally configured. For static multi-hop BFD, check
whether routes are bidirectionally configured on the intermediate node. For LSP
BFD session establishment, BFD can be unidirectionally configured, provided that the
destination address of the BFD session configured on the BFD-enabled node (the session
initiator) can be pinged through.
6.5.3 Handling Flow

Figure 6-11 shows a flow chart for handling BFD faults.
6-29
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 6-11 BFD Fault Handling Flow

To handle common BFD faults, perform the following steps:
1. Check whether the BFD session is up and whether the BFD session creation protocol
is up.
2. Check whether the session to be established is a routing protocol BFD or LSP BFD
session.
6-30
SJ-20100901100356-020|2011-07-30(R1.0)
3. For a routing protocol BFD session, check whether the BFD session is bidirectionally
configured. For an LSP BFD session, check whether the destination address of the
session can be pinged through.
6-31
SJ-20100901100356-020|2011-07-30(R1.0)
6-32
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 7
FRR Configuration
Table of Contents
Configuring IP FRR ....................................................................................................7-1
Configuring L2VPN FRR ............................................................................................7-3
Configuring L3VPN FRR ............................................................................................7-5
Configuring TE-FRR...................................................................................................7-6
Configuring LDP FRR...............................................................................................7-14
Configuring TE-Hotstandby ......................................................................................7-15
Configuring Interface FRR........................................................................................7-16
7.1 Configuring IP FRR

In general, IP FRR is used with routing protocols, such as OSPF, IS-IS, and BGP. For
details about the working principles and configuration commands of OSPF FRR, IS-IS
FRR, and BGP FRR, refer to relevant sections in the Configuration Guide IPv4 Routing
Volume.
7.1.1 Overview of IP FRR

When a link or node in the network fails, packets forwarded by the failed node to
the destination may be discarded or form a loop to inevitably cause temporary traffic
interruption or a traffic loop, till the network reconverges and recomputes a new topology
and a new route. In general, the interruption lasts about several seconds. Currently,
certain new technologies in the routing device field can be used to ensure that the route
convergence time be cut to less than one second.
As the network scale increases and new applications keep emerging one after another,
however, some applications such as voice and video services are rather sensitive to traffic
interruption. Therefore, rapid traffic recovery becomes especially important in the case a
node fails. Currently, the network convergence time can reach the following three levels
in the industry:
l
l
l
Sub-Second: It can meet the requirements of most IP networks.

Sub-500ms: It is a goal that can be attained.
Sub-50ms: It can meet special business requirements of IP networks.
In general, the network convergence time is spent in the following aspects:

1. The time taken to discover a link or node failure. It takes a dozen milliseconds to
detect a physical link layer fault, whereas it may taken dozens of seconds to detect a
neighbor failure in the protocol layer.
7-1
SJ-20100901100356-020|2011-07-30(R1.0)
2. The time taken to notify a link failure event to the control layer of the routing device. It
is usually several milliseconds to a dozen milliseconds.
3. The time taken for the local routing device to respond to a link or node failure. For
example, the local routing device may trigger and flood a new link status update packet
as a response. The time is usually several milliseconds to a dozen milliseconds.
4. The time taken for the local routing device to notify a link failure message to the other
nodes in the network. It is usually a dozen milliseconds to a hundred milliseconds per
node.
5. The time taken to trigger route recomputation. For the IGP protocol using the Dijkstra
algorithm, this time is usually a dozen milliseconds.
6. The time taken for the new route information computed through interactions with line
cards to form a forwarding table. It is usually hundreds of milliseconds depending on
the specific number of route entries.
7. The time taken to write the computed new route entries into hardware. It is usually a
dozen milliseconds.
Traffic loss will occur during the recovery of a link failure as described above. The traffic
loss process can be further divided into two stages:
1. Stage 1: The routing device fails to immediately discover the failure of a link connected
to itself, and still forwards traffic to the failed link.
2. Stage 2: The routing device discovers the link failure but the network is still ongoing
with route convergence. As a result, the forwarding tables on the other routing devices
in the network are inconsistent with the forwarding table on the local routing device,
causing a micro loop in the forwarding layer.
For this purpose, a mechanism with the following functions must be provided to shorten
the duration of traffic interruption in the network:
l
l
l
Quickly discovering a link failure.

Rapidly providing a recovery path when a link fails.
Avoiding micro loops during subsequent network recovery.
This mechanism is called the IP Fast Rerouting (IP FRR) technology.
7.1.2 Working Principles of IP FRR

The working process of IP FRR is described as follows:
1. Fast fault detection: Common technologies include BFD and physical signal detection.
2. The forwarding plane is modified to switch traffic over to the backup path calculated in
advance.
3. Route re-convergence.
4. After route re-convergence is over, traffic is switched over again to the optimal path.
Therefore, the function of the backup path is fill the route re-convergence gap and
guarantee uninterrupted services by quickly switching over traffic to the next hop.
Certain conditions must be met for OSPF and IS-IS to form FRR relations. To form an
FRR relation in the default LFAs detection mode, the algorithm must meet this condition:
7-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 7 FRR Configuration
Distance_opt(Ni, D)<Distance_opt(Ni, S)+Distance(S, D), that is, the distance from the
next hop of the backup link to the destination node must be smaller than the sum of the
distance from the next hop of the backup link to the source node and the distance from the
source node of the working link to the destination node.
To form an FRR relation in the downstream mode, the algorithm must meet this condition:
Distance_opt(Ni, D)<Distance(S, D), that is, the distance from the next hop of the backup
link to the destination node must be smaller than the distance from the source node of the
working link to the destination node.
The formation of a BGP FRR relation is quite simpler. The BGP FRR relation can be
formed as long as there are two different next hops to the same destination.
7.2 Configuring L2VPN FRR

For details about the working principles and configuration commands of L2VPN FRR, refer
to relevant sections in the Configuration Guide VPN Volume.
7.2.1 Overview of L2VPN FRR

As networks are experiencing rocketing development, an integrated network is in urgent
need. Currently, telecom operators attach great importance to service convergence speed
in the event of network faults. When a node fails at any time, traffic switchover to adjacent
nodes must be completed within 50 ms and end-to-end service convergence must be
completed within one second. These have already become threshold indexes of a bearer
network.
To accomplish traffic switchover to adjacency nodes within 50 ms and end-to-end
service convergence within one second, a technology called L2VPN-FRR has emerged.
L2VPN-FRR is a set of link protection and node protection mechanisms in L2VPN. When
an LSP link or node fails, the node that detects the fault is protected so that traffic can
continue to take the protection link or the tunnel of the protection node to avoid data
transmission interruption. Furthermore, the source node can continue to initiate the
re-establishment of a working path while its data transmission is not affected.
7.2.2 Working Principles of L2VPN FRR

L2VPN-FRR is also called PW-FRR, a link/node protection switching technology based
on PWE3 encapsulation for L2VPN services. It uses a pre-established PW to protect a
PW and implement PW redundancy. The pre-established PW is called the backup PW,
whereas the protected PW is called the master PW. The ultimate objective of L2VPN FRR
is to bypass the faulty link or node through the backup PW to protect the working path.
PW FRR is a feasible solution to improving L2VPN network reliability. It provides an OAM
mechanism and a BFD mechanism to detect L2VPN faults, notify faults, and implement
fast traffic switching.
PW FRR is applied in the following two networking modes:
7-3
SJ-20100901100356-020|2011-07-30(R1.0)
1. Dual-homing symmetrical access of CE devices: The CE devices at both ends

symmetrically access PE devices via two ACs. Figure 7-1 shows the implementation.
CE1 and CE2 access PE devices via Ethernet links. A PW is established between
PE1 and PE4 as well as between PE2 and PE3. MPLS LSPs are used as tunnels.
Figure 7-1 Dual-Homing Symmetrical Access of CE Devices
Implementation method: CE1 and CE2 access PE devices via Ethernet links. A PW
is established between PE1 and PE4 as well as between PE2 and PE3. MPLS LSPs
are used as tunnels.
Configure Ethernet OAM on PE devices and CE devices, configure AC OAM detection
and notification on PE devices, and enable the OAM mapping function. Establish a
BFD for PW session between PE1 and PE3 as well as between PE2 and PE4.
Switching is implemented by CE devices. PE devices are responsible for forwarding
only. Therefore, the forwarding process of PE devices is the same as that in common
PWE3.
2. Asymmetrical access of CE devices: The CE at one end accesses a PE via a single
AC, and the CE at the other end accesses PE devices via two ACs. Figure 7-2 shows
the implementation.CE1 and CE2 access PE devices via Ethernet links. A PW is
established between PE1 and PE3, called the master PW. A PW is also established
between PE1 and PE2, called the backup PW.
Figure 7-2 Asymmetrical Access of CE Devices
The master/backup attribute of a PW is statically specified during network planning.

There is only one PW for practical service forwarding at any moment. When the
master PW fails, PW-FRR switching can be rapidly triggered via a link fault detection
7-4
SJ-20100901100356-020|2011-07-30(R1.0)
technology such as BFD to switch over traffic to the backup PW. The master PW and
the backup PW may belong to the same tunnel or different tunnels. When the master
PW is restored, PW-FRR switchback is triggered to fast switch traffic back to the master
PW.
7.3 Configuring L3VPN FRR

For details about the working principles and configuration commands of L3VPN FRR, refer
to relevant sections in the Configuration Guide VPN Volume.
7.3.1 Overview of L3VPN FRR

In an MPLS/VPN network as shown in Figure 7-3, usually IBGP neighbors are established
between two PE devices to switch VPN private network routes. The next hop of such a
private network route is a PE. In addition, IGP/LDP neighbors are established between
PE-P and P-P devices directly connected to each other so as to establish outer layer
tunnels. For the ultimate VPN route forwarding entries, the next hop of a VPN BGP route
and the LGP/LDP outer layer tunnel must be iterated to generate the ultimate VPN FIB
entry to guide the forwarding of VPN traffic on the PE.
Figure 7-3 shows a typical network topology. The BGP protocol runs between PE1 and
PE2, whereas OSPF and LDP protocols run between PE1, P1 and PE2 as well as between
PE1, P2 and PE2 to provide BGP routes.
Figure 7-3 VPN/BGP Neighbors
VPN FRR is a technology most commonly used for fast traffic switching in the event of
faults. It establishes an end-to-end channel between two PE devices and pre-establishes
a backup channel for the working channel to be protected. When the device detects that
the working channel is unavailable due to a node or link failure, it switches over traffic to
7-5
SJ-20100901100356-020|2011-07-30(R1.0)
the backup channel, thus rapidly implementing traffic switchover and avoiding VPN traffic
loss.
In an IP/MPLS VPN multi-service bearer network, VPN FRR can be deployed to implement
the fast convergence of public network routes and LSPs in the event of a PE-P link failure,
P-P link failure, or P device failure.
7.3.2 Working Principles of L3VPN FRR

The working process of VPN FRR is similar to that of IP FRR:
1. Fast fault detection: Common technologies include BFD and physical signal detection.
2. The forwarding plane is modified to switch traffic over to the backup path calculated in
advance.
3. Route re-convergence.
4. After route re-convergence is over, traffic is switched over again to the optimal path.
7.4 Configuring TE-FRR

For details about the working principles and configuration commands of TE FRR, refer to
relevant sections in the Configuration Guide MPLS Volume.
7.4.1 Overview of TE FRR

Conventional IP networks are based on a "best effort" service model. Along with
continuous development of network services, there arises a need for IP networks bearing
multiple services to reach the same reliability as with a conventional telecommunication
network. For example, protection switching must be completed within 50 ms to meet
carrier-class service requirements.
The MPLS technology has gained long-term
development due to its numerous merits, such as fast forwarding, QoS guarantee, and
multi-service support since it merged in the middle of 1990s. It is playing a more and
more important role in next-generation telecommunication networks.
To guarantee the reliability of MPLS networks, the MPLS FRR technology has played an
important role. MPLS FRR utilizes the capabilities of MPLS Traffic Engineering (MPLS TE)
to provide fast protection switching for LSPs. The MPLS FRR mechanism creates a local
backup path in advance to protect LSPs against link or node failures. When a link or node
fails, the device detecting the link or node failure can rapidly switch traffic from the faulty
link to the backup path, thus reducing data loss as much as possible.
Quick response and timely switching are two features of the MPLS FRR technology to
guarantee smooth transition of service data without service interruption. In addition, the
source node of the LSP will try to find a new path to re-establish the LSP and switch data
traffic to the new path. Service data is always forwarded on the protection path before the
new LSP is successfuly established.
7-6
SJ-20100901100356-020|2011-07-30(R1.0)
7.4.2 Working Principles of TE FRR

Working Principles
MPLS TE FRR is a set of link protection and node protection mechanisms in MPLS TE.
When an LSP link or node fails, the node that detects the fault is protected so that traffic
can continue to take the protection link or the tunnel of the protection node to avoid
data transmission interruption. Furthermore, the source node can continue to initiate the
re-establishment of a working path while its data transmission is not affected.
MPLS TE FRR uses a pre-established LSP to protect one or multiple LSPs. The
pre-established LSP is called the FRR LSP, whereas a protected LSP is called a working
LSP. The ultimate objective of TE FRR is to bypass the faulty link or node through the
FRR tunnel to protect the working path.
MPLS TE FR is implemented on the basis of RSVP TE, and complies with RFC 4090.
There are two means to implement FRR:
1.
Detour mode: One-to-one backup. Protection is provided for each protected LSP.
A protection path is created for each protected LSP. The protection path is called a
detour LSP.
2.
Bypass mode: Facility backup. A protection path protects multiple LSPs. The
protection path is called a bypass LSP.
The detour mode protects each LSP, and thus involves larger overheads. In practice, the
bypass mode is more widely applied. Therefore, the subsequent descriptions focus on the
bypass mode.
Figure 7-4 shows the bypass mode of FRR. The blue LSP is the working LSP, whereas
the red LSP is the bypass LSP. When the RTB-RTC link fails or the node RTC fails, data
on the working LSP is switched to the bypass LSP. The label allocated by RTF to RTB is
added in the top layer of the packet header sent out of RTB, and the egress label of RTC
is pressed into the label stack to serve as the next layer.
7-7
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 7-4 Bypass Mode of FRR
The LSP uses two layers of labels on the RTB-RTF-RTD path. For a packet received by
RTD, the label allocated by RTD to RTF pops out, and the packet is forwarded using the
label allocated by RTD to RTC.
Several concepts are involved:
l
l
l
l
Working LSP: For the detour LSP or bypass LSP, the working LSP is the protected
LSP.
Point of Local Repair (PLR): It is the source node of the detour LSP or bypass LSP. It
must be on the path of the working LSP and cannot be the sink node.
Merge Point (MP): It is the sink node of the detour LSP or bypass LSP. It must be on
the path of the working LSP and cannot be the source node.
Link protection: There is a direct link to connect the PLR and the MP. The working
LSP passes this direct link. When the link fails, traffic can be switched to the detour
or bypass LSP. This mechanism is called link protection.
Node protection: There is a routing device to connect the PLR and the MP. The
working LSP passes this routing device. When the routing device fails, traffic can
be switched to the detour or bypass LSP. This mechanism is called node protection.
Key Technologies
Figure 7-5 shows the bypass mode of FRR.
7-8
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 7-5 Bypass Mode of FRR
The bypass mode of FRR as described in this section is implemented using objects
SESSION_ATTRIBUTE and RECORD_ROUTE in compliance with RFC 4090 (hereinafter
referred to as the protocol).
Establishment of the Working LSP

The establishment of the working LSP is the same as that of a common LSP. The RSVP
sends a PATH message from the source node (RT1) to downstream nodes hop by
hop (RT1-RT2-RT3-RT4-RT5), and sends a RESV message from the sink node (RT5)
to upstream nodes hop by hop. It allocates a label and reserves resource for LSP
establishment during RESV message handling.
In the protocol draft, several flag bits are expanded in objects SESSION_ATTRIBUT and
RECORD_ROUTE for FRR. The difference between the establishment of the protected
LSP and the establishment of a common LSP lies in the handling of these flag bits.
In the SESSION_ATTRIBUT object of the PATH message, the added flag bits indicate
whether local protection is required for the LSP, whether to record the label, whether the
style is SE, and whether any protection bandwidth is required.
In the RECORD_ROUTE object of the RESV message, the added flag bits indicate
whether the LSP is already protected, whether switching has taken place, whether the
bandwidth is protected, and whether node protection is applied to the LSP.
The establishment of the working LSP is triggered by manually configuring the tunnel on
the source node (RT1). If the FRR attribute is specified for the LSP through a configuration
command before the working LSP is established, the RSVP adds a local protection flag, a
label recording flag, and an SE style flag to the SESSION_ATTRIBUTE object of the PATH
message. If bandwidth is also specified for the LSP, the RSVP also adds a bandwidth
protection flag to the object. Upon receipt of the PATH message, the downstream node
7-9
SJ-20100901100356-020|2011-07-30(R1.0)
checks the local protection flag to determine whether the LSP is an LSP requiring FRR
protection.
If the LSP requires FRR protection according to the local protection flag in the received
PATH message, the downstream node records the egress interface, LSR ID, and label
of the RESV message in RRO, and then sends the RESV message to the upstream
node. The information is cumulatively calculated hop by hop and further transmitted to
the upstream node.
When a node receives the RESV message for the first time, it selects a proper bypass
LSP for the LSP according to the information recorded in RRO. The process of selecting
a proper bypass LSP for the working LSP is called binding. For details about the binding
algorithm, refer to subsequent descriptions.
After a node performs FRR binding computation for the working LSP, it sends an RESV
message to the upstream node. In the RESV message, there is a RECORD_ROUTE
object, indicating whether the LSP is already protected. If the LSP is already protected,
the node records the protected egress interface address (the eth1 interface of RT2) and
the egress interface of the RESV message (the eth3 interface of RT2). If the LSP is
not protected, the relevant flag in RRO is cleared and the node records only the egress
interface of the RESV message (the eth3 interface of RT2). The egress does not perform
binding computation, but clears all flags recorded in RRO for the RESV message.
The establishment of the working LSP with FRR protection is almost the same as that of a
common LSP, except that binding computation is performed as mentioned previously and
several flags and sub-objects are added in the PATH message and RESV message.
Establishment of the Bypass LSP

The bypass LSP can be established in either manual mode or automatic mode.
In manual mode, the corresponding LSP becomes the bypass LSP when a tunnel without
the FRR attribute is specified to protect a physical interface. The manual establishment of
the bypass LSP (tunnel 2 on RT2) is triggered by manual configuration on the PLR (RT2).
The configuration of the bypass LSP is almost the same as that of a common LSP, except
that the bypass LSP does not have the FRR attribute. In other words, the bypass LSP
cannot be the working LSP at the same time, and LSPs do not support nested protection.
The automatic mode of bypass LSP establishment is a simplification of the manual
configuration mode. When the working LSP needs to be protected by FRR, the PLR can
select or automatically create a bypass LSP to protect the working LSP. This is called the
automatic mode of bypass LSP establishment. In automatic mode, the bypass LSP can
protect multiple working LSPs, provided that it meets the requirements of these working
LSPs.
The bypass LSP can protect multiple physical interfaces but cannot protect its own egress
interface.
FRR supports link protection or node protection. When protection by a bypass LSP is
needed, the link or node to be protected by the bypass LSP must be well planned. In
addition, the protection mode (link protection or node protection) should be determined.
7-10
SJ-20100901100356-020|2011-07-30(R1.0)
In general, node protection can protect the protected node and the link between the PLR
and the protected node, so it seems to be better than link protection.
The bandwidth of the bypass tunnel is usually used to protect the working LSP. All the
resources on the bypass tunnel are for use only after protection switching. Users should
ensure that the configured bandwidth is greater than or equal to the sum of bandwidth
requested by each protected LSP during configuration. Otherwise, the bypass LSP cannot
provide satisfactory protection after FRR takes effect.
In general, the bypass LSP is in idle status and does not bear any data service. If
users hope that the bypass LSP also undertakes an ordinary data forwarding task while
protecting the working LSP, they must configure a sufficient bandwidth for the bypass LSP.
Binding Computation
Binding can be considered as specifying a bypass tunnel to protect a physical interface.
This is called the binding between a bypass tunnel and a physical interface. One bypass
tunnel can be bound to multiple physical interfaces, and one physical interface can also
be bound to multiple bypass tunnels.
Binding can also be considered as selecting a proper bypass LSP to protect a working LSP.
This is called the binding between a working LSP and a bypass LSP. Binding computation
is a process through which a working LSP is bound to a bypass LSP. The result of binding
computation is to obtain data necessary for forwarding during protection switching, such
as the bypass tunnel interface, the egress interface and NHLFE of the bypass LSP, and
the label allocated by the MP. If the binding computation is successful, an RESV message
is sent to the upstream node, indicating that the working LSP is already protected.
The result of binding computation covers the following items, which are used for sending
data and signaling messages on the bypass tunnel after protection switching:
l
l
l
Protection type (Link protection or node protection) and MP LSR ID.

The label allocated by the MP to the preceding hop. It is the label corresponding to
the MP LSR ID in the RRO of the working LSP.
Bypass tunnel interface and NHLFE of the bypass LSP.
The result of binding computation will be saved for instant use when a local failure occurs.
This is also the reason why MPLS TE FRR can quickly respond to failures.
Failure Detection
The objective of failure detection is to discover link (RT2-RT3) failures and node (RT3)
failures at the earliest possible time and trigger switching to reduce data packet loss.
The failure detection mechanism does not determine whether a failure is a link or node
failure but ultimately summarizes the failure as an interface failure (a failure of the eth1
interface on RT2).
The interface failure triggers all the LSPs using the failed interface as the egress interface
to implement FRR switching. If the protection type of an LSP is link protection according
to binding computation, it switches to link protection. If the failure is actually a node failure,
7-11
SJ-20100901100356-020|2011-07-30(R1.0)
however, protection will fail and the LSP will be ultimately deleted. If the protection type of
an LSP is node protection according to binding computation, it switches to node protection.
If the failure is actually a link failure, however, the next-hop node will be neglected by the
bypass tunnel, even though the next-hop node is available.
Some link or node failures can be detected by the link layer protocol. The speed of failure
detection of the link layer directly relates to the type of the interface. The other failures are
detected by the hello mechanism of RESV. The hello detection is quite slow.
The hello detection function can be enabled on each physical interface to be protected.
If the hello detection function is also enabled on the peer interface, hello messages and
replies will be periodically sent between the two routing devices. When a link or node fails,
the hello message or reply message will be lost. If the message is lost for three consecutive
times, a failure is considered as having taken place.
Switching Procedure
In the switching procedure, the bypass LSP is enabled so that the data and RSVP
messages of the working LSP are no longer sent on the original path but on the protection
path.
The switching procedure can be triggered by shutting down the interface (eth1 on RT2)
or when an interface failure (eth1 on RT2) is detected through failure detection. Then the
forwarding service and signaling of the protected LSP on the failed interface is switched to
the bypass LSP, and a notification message is sent to the upstream node, indicating that
a switching event has taken place.
LSP Maintenance After Switching

The original link is no longer unavailable after switching. To prevent the original LSP from
being deleted upon expiry, the RSVP must keep message updating between the PLR (RT2)
and the MP (MT4).
The updated PATH message is sent through the bypass tunnel (Tunnel 2 on RT2) to the
MP. Upon receipt of the PATH message, the MP confirms that itself is the MP node. The
RESV message is also modified and forwarded via multiple-hop IP forwarding (passing
RT4-RT7-RT2) to the PLR node.
After the switching takes place, the PATH message sent by the PLR to the MP will also be
modified as follows:
1. The PHOP field is filled in with the egress interface (eth2 on RT2) address of the
bypass LSP on the PLR.
2. In SENDERTEMPLATE, Ingress lsr id is changed to the egress interface (eth2 on RT2)
address of the bypass LSP on the PLR.
3. The PLR address recorded in RRO is changed to the egress interface (eth2 on RT2)
address of the bypass LSP on the PLR.
4. All nodes before the MP are deleted from ERO, and the first address of the MP is
changed to the LSR ID of the MP.
7-12
SJ-20100901100356-020|2011-07-30(R1.0)
The MP receives the PATH message sent via the bypass tunnel. Because the session
does not change but the Ingress lsr id (It should be the LSR ID of RT1 instead) in
SENDERTEMPLATE has been changed to the egress interface (eth2 on RT2) address of
the bypass LSP on the PLR, the MP considers that this a PATH after FRR switching and
itself is the MP node.
The PATH message sent by the MP to the downstream will not change with switching.
The RESV message sent by the MP to the upstream will be modified as follows:
1. The Filter Spec source address in the message is changed to the PHOP address (the
address of eth2 on RT2) of the PATH message.
2. NHOP in the message is changed to the ingress interface (eth2 on RT4) address of
the bypass tunnel on the MP.
3. The RRO object in the RESV message records the ingress interface (eth2 on RT4)
address of the bypass tunnel on the MP.
4. The destination address in the IP header of the message is the egress interface (eth2
on RT2) address of the bypass tunnel on the PLR.
5. The TTL value in the message is set to 255, and the TTL value of the protocol message
header is set to 1.
The RESV message sent by the PLR to the upstream after switching will also change. The
egress interface (eth2 on RT2) address of the bypass LSP will be added to RRO.
The paths on which the PTEAR, RERR, RTEAR, and PERR messages of the working LSP
are sent will change accordingly after switching.
After the node protection switching, the protected node (RT3) may send a PATHTEAR
message to the downstream node upon PATH message timeout. The MP (RT4) will ignore
this message. In addition, an ResvTear message will be sent on the ingress interface (eth3
on RT4) of the original LSP during MP switching, so that the protected node (RT3) can
release relevant resources at the earliest possible time.
MBB
For FRR, another function of MBB is to restore the tunnel (Tunnel 1 on RT1) protected
by the bypass LSP to the normal status. When switching occurs on the working LSP,
the source node starts the MBB procedure to recompute an available path. After the
new path is successfully established, a proper backup LSP is re-selected to form a new
working-protection binding relation.
Forwarding
The data forwarding process before the switching of the working LSP is the same as that
of a common LSP. When the working LSP is switched over to the bypass tunnel, data on
the working LSP is forwarded via the bypass tunnel to the MP.
7-13
SJ-20100901100356-020|2011-07-30(R1.0)
7.5 Configuring LDP FRR

For details about the working principles and configuration commands of LDP FRR, refer
to relevant sections in the Configuration Guide MPLS Volume.
7.5.1 Overview of LDP FRR

A link node failure in the MPLS domain will cause a LSP failure and result in MPLS traffic
interruption. To guarantee MPLS network reliability, usually a technology called MPLS
FRR is applied to provide fast protection switching capability for LSPs. The MPLS FRR
mechanism establishes a local backup path in advance to protect LSPs against link or
node failures. When a link or node failure occurs, the routing device detecting the link or
node failure can quickly switch over traffic from the faulty link or node to the backup path,
thus alleviating data loss.
7.5.2 Working Principles of LDP FRR

LDP FRR is based on the LDP widely applied in the industry. By default, LDP FRR works
in a downstream unsolicited (DU) label distribution and free label retention mode, and
allocates labels to routes instead of allocating a label to an end-to-end connection. In this
case, LSRs can quickly respond to route changes to meet the 50-ms protection switching
requirement.
The working process of LDP FRR is described in detail as follows:
1. The LDP runs in the network. LDP FRR works in a mode combining DU label
distribution, ordered label control and free label retention.
In DU label distribution mode, the egress Label Edge Router (LER) does not require
a label distribution request from the upstream Label Switching Router (LSR), but
actively allocates FEC-label binding and sends the message to the upstream device.
A Forwarding Equivalent Class (FEC) is generally a route.
In free label retention mode, an LSR can receive an FEC-label mapping message from
any neighboring LSR. No matter whether the neighboring LSR that sends this message
is the next hop of the route corresponding to the FEC in the specific FEC-label mapping
message advertised by itself, the LSR retains all the label mappings it has received.
Of all the label mappings, a label forwarding table (hereinafter referred to as the main
label forwarding table) is generated for only the label mapping sent from the next hop
of the route corresponding to the FEC. If a label forwarding table is also generated for
the other label mappings and serves as the backup of the main label forwarding table,
backup LSPs will be established equivalently and then the LSR can quickly respond
to link changes.
2. A port of the LSR is specified as the backup port of another port. The two ports can
be either physical ports or logical ports, provided that the LDP runs on the ports.
3. The device maintains the label forwarding tables. When port backup is not
implemented, a label forwarding table has only one next hop and one label. The label
is allocated by the LDP peer connected to the next hop of the route corresponding
7-14
SJ-20100901100356-020|2011-07-30(R1.0)
to the FEC for the FEC. After port backup is implemented, if the next hop in a label
forwarding table is the protected port, an additional next hop and a label will be added
for this forwarding entry. The added label is the label allocated by the LDP peer
connected to the next hop of the backup route for the FEC.
4. The device maintains the working status (Normal or Invalid) of each port. When detecting that a certain port cannot work properly (for example, the physical link fails or
the port is manually shut down), the device immediately updates the working status of
the port. The device can check the label forwarding table during packet forwarding to
obtain the next-hop port of the packet. If the port status is invalid, the device switches
to the backup port and sets a label before delivering the packet.
The packet reaches the next hop. because the label is allocated by the device itself, there
is surely a label forwarding table for this next hop. Therefore, the packet can continue to
be forwarded to the specified destination address.
7.6 Configuring TE-Hotstandby

For details about the working principles and configuration commands of TE Hotstandby,
refer to relevant sections in the Configuration Guide MPLS Volume.
7.6.1 Overview of TE-Hotstandby

While TE FRR protection is applied to protect certain segments in a large-scale network,
the TE-Hotstandby technology can be used to provide global end-to-end protection for
LSPs.
TE-Hotstandby is an end-to-end protection technology. It directly establishes two LSPs
based on different paths during the establishment of a tunnel to implement end-to-end
protection.
The establishment of the hot standby tunnel LSP is initiated after the working tunnel LSP
is established. When a message about the failure of the working tunnel LSP reaches the
ingress router, traffic is switched over to the hot standby tunnel LSP. When the working
tunnel LSP is restored, traffic is switched back to the working tunnel LSP.
It should be noted that the working tunnel LSP (inuse_lsp) is not necessarily the working
path. The working tunnel LSP is recomputed through the MBB procedure after switching.
This feature appears when multiple path options are configured for a tunnel.
The hot standby tunnel LSP (hsb_lsp) replaces the original working tunnel LSP during hot
standby switching. Then the MBB procedure is started to restore the working tunnel LSP.
After the MBB successfully creates a new working tunnel LSP, the hot standby tunnel LSP
is replaced.
7.6.2 Working Principles of TE Hot Standby

The principles of TE tunnel establishment, protection LSP establishment, and TE hot
standby are similar to the principles of TE FRR.
7-15
SJ-20100901100356-020|2011-07-30(R1.0)
7.7 Configuring Interface FRR

Enabling Interface FRR
Use the following commands on ZXCTN 9000 to enable the interface FRR function:
Step
Command
Function
ZXCTN9000(config)#interface vlan < vlan id>
Enters the L3 interface configuration mode
ZXCTN9000(config-if-vlan)#interface frr
Enables the interface FRR function
enable
3
ZXCTN9000(config-if-vlan)#exit
Exits from the configuration mode
ZXCTN9000(config)#ip route vrf < vrfname>
Configures an interface FRR protection
< ip-address> < mask> < next-hop> slave
group

Parameter
Description
< vlan id>
VLAN ID

Parameter
Description
< vrfname>
VRF name of the private network route
< ip-address>
IP address of the L3 interface on which the

interface FRR function will be enabled
< mask>
The mask corresponding to the IP address of the

L3 interface on which the interface FRR function
will be enabled
< next-hop>
Next-hop IP address of the protection link
Disabling Interface FRR

Step
Command
Function
ZXCTN9000(config)#interface vlan < vlan id>
Enters the L3 interface configuration mode
ZXCTN9000(config-if-vlan)#interface frr
Disables the interface FRR function
disable
3
ZXCTN9000(config-if-vlan)#exit
Exits from the configuration mode
ZXCTN9000(config)#no ip route vrf<
Deletes the interface FRR protection group
vrfname> < ip address> < mask>

7-16
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< vlan id>
VLAN ID

Parameter
Description
< vrfname>
VRF name of the private network route; 1 to 32

characters
< ip address>
IP address of the L3 interface on which the

interface FRR function will be enabled
< mask>
The mask corresponding to the IP address of the

L3 interface on which the interface FRR function
will be enabled
7.7.1 Overview of Interface FRR

When a certain detection mechanism, such as BFD for Process Interface Status (BFD
for PIS) is applied, BFD behaviors can be associated with interface states to improve the
sensitivity of link failure detection on the interface and reduce problems caused by failures
of non-direct links. The VLAN L3 interface may be down as a result of port failures.
If the L3 interface is down but routes are not yet converged, all the data packets originally
destined to the L3 interface segment will be discarded, because there is not any egress
interface.
As shown in Figure 7-6, when the port of PE1 fails, the status of the L3 interface 10.1.1.2
changes to DOWN and all the data packets destined to the SGW 10.1.1.100 will be
discarded. To guarantee uninterrupted route forwarding in that case, it is necessary
to specify the next hop of the L3 interface 10.1.1.2 as 20.1.1.2, so that data packets
destined to the SGW can reach PE2 and are then forwarded by PE2 to the sGW after
PE2 searches and finds an available route.
Figure 7-6 An Application Scenario of Interface FRR
7-17
SJ-20100901100356-020|2011-07-30(R1.0)
7.7.2 Working Principles of Interface FRR

The interface FRR function is implemented using the concept of IP FRR:
There are two routes for the L3 interface segment on PE1, for example:
10.1.1.0/24 |-> CPU Working route
|->20.1.1.2 Protection route
When the status of the interface 10.1.1.2 is DOWN, IP FRR is triggered for the interface
route 10.1.1.0/24 so that the next hop of the route points to 20.1.1.2.
The principles of VPN L3 interface route backup are the same as the implementation
principles of the above public network.
7-18
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 8
IP Graceful Restart
Configuration
Table of Contents
Overview of IP Graceful Restart .................................................................................8-1
Configuring IP Graceful Restart ..................................................................................8-1
Maintaining IP Graceful Restart ..................................................................................8-5
IP Graceful Restart Instances...................................................................................8-11
IP Graceful Restart Troubleshooting.........................................................................8-14
8.1 Overview of IP Graceful Restart

Accidental interruption is unpredictable on a routing device in many cases. This causes
the interruption of data traffic forwarding and route oscillation. If the control function of the
routing device is separated from the forwarding function, a certain policy can be applied
to minimize the influence of the interruption event on the restarted routing device and its
neighbors. This policy is called graceful restart (GR).
IP graceful restart can be applied in the following three fields:
l
l
l
IP graceful restart in the OSPF protocol

IP graceful restart in the IS-IS protocol
IP graceful restart in the BGP protocol
8.2 Configuring IP Graceful Restart

8.2.1 Configuring OSPF Graceful Restart
Use the following commands on ZXCTN 9000 to configure the OSPF GR function:
Step
Command
Function
ZXCTN9000(config)#router ospf < id>
Enters the OSPF configuration mode
ZXCTN9000(config-router)#nsf
Enables OSPF GR (If the device is the

helper, the neighbor switching function is
enabled)
8-1
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config-router)#grace-period <
Sets the OSPF GR time, which is 120
time>
seconds by default (This configuration is

optional. The time can be set to a greater
value if there are quite many route entries on
the switching router)

Parameter
Description
< id>
OSPF instance ID in hexadecimal format

Parameter
Description
< time>
The time taken to complete OSPF GR, which

ranges from 120 to 180 seconds and is 120
seconds by default
8.2.2 Configuring IS-IS Graceful Restart

Use the following commands on ZXCTN 9000 to configure the IS-IS GR function:
Step
Command
Function
ZXCTN9000(config)#router isis
Enters the IS-IS configuration mode
ZXCTN9000(config-router)#area <
Configures the IS-IS area address.
area-address>
3
ZXCTN9000(config-router)#system-id <
Configures the IS-IS system ID.
system-id> [ range < range-number> ]

4
ZXCTN9000(config-router)#restart enable
Enables IS-IS GR
ZXCTN9000(config-router)#restart t2-timer
Configures the IS-IS T2 timer
< t2-interval> [ level-1 | level-2]

6
ZXCTN9000(config-router)#restart t3-timer
Configures the IS-IS T3 timer
{ adjacency | manual < t3-interval> }

7
Enters the VLAN L3 interface configuration
interface-name>
mode
ZXCTN9000(config-if-vlanX)#ip router isis
Enables the IS-IS protocol on VLAN

interfaces

8-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 8 IP Graceful Restart Configuration
Parameter
Description
< area-address>
Area address; 1-13 bytes of hexadecimal

characters

Parameter
Description
< system-id>
System ID of the instance, which is a hexadecimal

string of 6 bytes in the form of xxxx.xxxx.xxxx
< range-number>
Extension range of system ID; range: 0 to 32;

0 by default. An instance will use an ID ranging
from SystemID to SystemID+range-number

Parameter
Description
t2-timer
Database synchronization timer for graceful start
< t2-interval>
T2 timer interval in seconds, ranging from 5 to

65535
[level-1 | level-2]
The level of areas on which the command will act

(If this parameter is not specified, the command
acts on both level-1 and level-2)

Parameter
Description
t3timer
Graceful restart completion timer
adjacency
Indicates that the completion time of graceful

start is determined by the hold time carried in the
hello packet advertised by the neighbor
manual
Indicates that the completion time of graceful

start is determined by manual configuration
< t3-interval>
T3 timer interval in seconds, ranging from 1 to

65535

Parameter
Description
< multiplier>
Hello multiplier; range: 3 to 1000; 3 by default
level-1
Indicates that ZXCTN9000 is located in a level-1

area
8-3
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
level-2

area

Parameter
Description
< retry-timers>
T1 reset times, ranging from 1 to 65535; 3 by

default
level-1

area
level-2

area

Parameter
Description
< interval>
Timer interval in seconds, ranging from 1 to

65535; 3 seconds by default
level-1

area
level-2

area
8.2.3 Configuring BGP Graceful Restart

Use the following commands on ZXCTN 9000 to configure the BGP GR function:
Step
Command
Function
ZXCTN9000(config)#router bgp < as>
Enters the BGP configuration mode
ZXCTN9000(config-router)#bgp
Enables the BGP GR function
graceful-restart
3
Configures the negotiated restart time of the
graceful-restart restart-time < time>
GR router
Configures the time taken to delete the
graceful-restart restart-time < time>
stale route after the helper discovers the

active/standby switchover of the GR router
8-4
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< as>
AS number of the BGP instance

Parameter
Description
< time>
The time that the helper waits for the GR router

to restart, ranging from 1 to 3600

Parameter
Description
< time>
The maximum period of time for which the helper

can keep the stale route, ranging from 1 to 3600
8.3 Maintaining IP Graceful Restart

8.3.1 Maintaining OSPF Graceful Restart
Use the following commands on ZXCTN 9000 to maintain and diagnose the OSPF graceful
restart function:
Command
Function
ZXCTN9000(config)#show ip ospf [ < process-id> ]
Shows configuration information about OSPF

NSF
Shows OSPF status information
ZXCTN9000(config)#show ip ospf nsf
The following example shows the outputs of the show ip ospf command.
ZXCTN9000(config)#show ip ospf 1
OSPF 1 enable
Router ID 47.47.47.47
Domain ID type 0x5,value 0.0.0.1
Enabled for 00:03:18,Debug on
Number of areas 1, Normal 1, Stub 0, NSSA 0
Number of interfaces 3
Number of neighbors 1
Number of adjacent neighbors 1
Number of virtual links 0
Total number of entries in LSDB 4
Number of ASEs in LSDB 0, Checksum Sum 0x00000000
Number of grace LSAs 0
Number of new LSAs received 4
8-5
SJ-20100901100356-020|2011-07-30(R1.0)

Number of self originated LSAs 3
Hold time between consecutive SPF 5 secs
Non-stop Forwarding , last NSF restart
ago (took 1 secs)

Output Item
Description
Non-stop Forwarding
GR has been enabled for the OSPF protocol
last NSF restart time
The time when GR was last restarted
(took time)
The time taken for the last restart of GR
The following example shows the outputs of the show ip ospf nsf command.
ZXCTN9000(config)#show ip ospf nsf
OSPF Router with ID (47.47.47.47) (Process ID 1)
OSPF instance is graceful restarting
Restart reason is switch to redundant control processor
Grace period 120
Start time 00:00:06
Time to leave 86 s
Helper 46.46.46.46
In the area 0.0.0.0
via interface vlan23 23.1.1.2
Neighbor is DR
State FULL

Output Item
Description
Restart reason
Restart reason
Grace period
Maximum duration of uninterrupted forwarding
Start time
Start time of uninterrupted forwarding
Time to leave
Maximum remaining time of uninterrupted

forwarding
Helper
Helper ID
In the area
The area to which the link used for uninterrupted

forwarding belongs
via interface vlan1
Type, sequence number, and IP address of the

interface to which the helper belongs
State
Helper status
The following example shows the outputs of the show ip ospf nsf command.
ZXCTN9000(config-router)#show ip ospf nsf
OSPF Router with ID (46.46.46.46) (Process ID 1)
8-6
SJ-20100901100356-020|2011-07-30(R1.0)

This router is a helper of graceful restart
Restarting router ID 47.47.47.47
In the area 0.0.0.0
via interface vlan23 23.1.1.47
Neighbor is BDR
State FULL
Max grace period 120
Start time 4d13h
Time to leave 104 s

Output Item
Description
Restarting router ID
ID of the restarting router
In the area
The area to which the link used for uninterrupted

forwarding belongs
via interface vlan1
Type, sequence number, and IP address of the

interface to which the restarting router belongs
Neighbor is BDR
Indicates that the restarting router is a BDR
State
Status of the restarting router
Start time
The time when the device enters the help mode
Max grace period
Maximum duration of uninterrupted forwarding
Time to leave
The remaining time for the device to leave the

help mode
8.3.2 Maintaining IS-IS Graceful Restart

Use the following command on ZXCTN 9000 to maintain and diagnose the IS-IS graceful
restart function:
Command
Function
ZXCTN9000(config)#show isis nsf [ < process-id> ]
Shows the status parameters of IS-IS graceful

restart

Parameter
Description
< process-id>
Instance ID ranging from 0 to 65535
The following example shows how to check IS-IS adjacency:

ZXCTN9000(config-router)#show isis adjacency
Interface
System id
State
Lev Holds
SNPA(802.2)
Pri
MT
8-7
SJ-20100901100356-020|2011-07-30(R1.0)

vlan110
ZXCTN9000
UP/UP L1L2 24/24 00D0.D0C6.0721 64/64
The following example shows the outputs of the show isis nsf command.
ZXCTN9000(config)#show isis nsf
Process ID 0:
NSF is ENABLE
NSF mode is Normal
NSF L1 active interface: 0
NSF L2 active interface: 0
NSF L1 T2 remaining: 0 seconds
NSF T3 using Adjacency
NSF T3 remaining: 0 seconds
Interface:xgei_1/1
NSF L1 restart state: Finished
NSF L1 helper in restart state: Other
NSF L1 T1 retransmissions: 0
NSF L2 restart state: Finished
NSF L2 helper in restart state: Other
NSF L2 T1 retransmissions: 0

Parameter
Description
NSF is { ENABLE | DISABLE}
ENABLE: The GR function has been enabled for

IS-IS
DISABLE: The GR function is not enabled for
IS-IS
NSF mode is { Normal | Restart}
Normal: IS-IS is in the normal status

RESTART: IS-IS is in the GR status
NSF L1 active interface
The number of L1 interfaces with active T1 timer
NSF L2 active interface
The number of L2 interfaces with active T1 timer
NSF L1 T2 remaining
Remaining time of the IS-IS L1 T2 timer
NSF L2 T2 remaining
Remaining time of the IS-IS L2 T2 timer
NSF T3 using {Adjacency |Manual }
Adjacency: Automatically adjust the IS-IS T3

timer according to adjacency
Manual: Manually configure the IS-IS T3 timer
8-8
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
NSF L1/l2 restart state: { Finished | Running }
Finished: The IS-IS interface has finished GR or

does not yet start GR
Running: The IS-IS interface is still in the GR
status
L1: IS-IS L1
L2: IS-IS L2
NSF L1/L2 helper in restart state: { Other | Me}
Other: The GR helper is not yet elected on the

interface or another router is elected as the helper
Me): The local end serves as the GR helper
L1: IS-IS L1
L2: IS-IS L2
NSF L1/l2 T1 remaining
Remaining time of the IS-IS GR interface T1 timer

L1: IS-IS L1
L2: IS-IS L2
NSF L1/l2 T1 retransmissions
The remaining times to reset the IS-IS GR

interface T1 timer
L1: IS-IS L1
L2: IS-IS L2
8.3.3 Maintaining BGP Graceful Restart

Use the following command on ZXCTN 9000 to maintain and diagnose the BGP graceful
restart function:
Command
Function
ZXCTN9000(config)#show ip bgp neighbor
Shows whether the BGP neighbors have

negotiated the GR capability
The following example shows the outputs of the show ip bgp neighbor command.
sho ip bgp neighbor
BGP neighbor is 1.9.9.9, remote AS 1, internal link
BGP version 4, remote router ID 1.9.9.9
BGP state = Established, up for 15:49:38
Last read update 15:49:36, hold time is 90 seconds, keepalive
interval is 30 seconds
Neighbor capabilities:
Route refresh: advertised and received
New ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Address family VPNv4 Unicast: advertised and received
8-9
SJ-20100901100356-020|2011-07-30(R1.0)

Graceful Restart Capability: advertised and received
Remote Restart timer is 90 seconds
Address families preserved by peer :
IPv4 Unicast
IPv4 VPN
All received 1820 messages
4 updates, 0 errors
1 opens, 0 errors
1815 keepalives
0 vpnv4 refreshes, 0 ipv4 refreshes, 0 ipv4 multicast refreshes,
0 ipv6 refreshes, 0 errors
0 notifications, 0 other errors
After last established received 1818 messages
4 updates, 0 errors
0 opens, 0 errors
1814 keepalives
0 ipv6 refreshes, 0 errors
0 notifications, 0 other errors
All sent 1862 messages
4 updates, 1 opens, 1857 keepalives
0 ipv6 refreshes, 0 notifications
After last established sent 1860 messages
4 updates, 0 opens, 1856 keepalives
0 ipv6 refreshes, 0 notifications
For address family: IPv4 Unicast

All received nlri 2, unnlri 0, 2 accepted prefixes
All sent nlri 0, unnlri 0, 0 advertised prefixes
Maximum limit 4294967295
Threshold for warning message 75%
Minimum time between advertisement runs is 30 seconds
Minimum time between origin runs is 15 seconds
For address family: IPv4 Multicast no activate

For address family: VPNv4 Unicast

8-10
SJ-20100901100356-020|2011-07-30(R1.0)

For address family: IPv6 Unicast no activate

Connections established 1
Local host: 5.9.9.9, Local port: 1025
Foreign host: 1.9.9.9, Foreign port: 179

Output Item
Description
Address family IPv4 Unicast: advertised and
The information indicates that the BGP supports
received
the GR function in IPv4 unicast and VPN4 unicast
Address family VPNv4 Unicast: advertised and
modes, and the negotiated restart time is 90
received
seconds.
Graceful Restart Capability: advertised and

received
Remote Restart timer is 90 seconds
8.4 IP Graceful Restart Instances

8.4.1 OSPF Graceful Restart Configuration Example
As shown in Figure 8-1, ZXCTN9000 devices P1 and P2 are OSPF neighbors. It is
necessary to enable the graceful restart function on P1 and P2 so that data packets can
still be normally forwarded when P1 or P2 is restarted.
Figure 8-1 A Configuration Example of OSPF Graceful Restart
1. Configure ZXCTN9000 devices P1 and P2 as OSPF neighbors to each other.
8-11
SJ-20100901100356-020|2011-07-30(R1.0)
2. Enable the graceful start function on P1 and P2.
ZXCTN9000(config)#router ospf 1
ZXCTN9000(config-router)#network 25.60.61.60 0.0.0.255 area 0

ZXCTN9000(config)#router ospf 1
ZXCTN9000(config-router)#network 25.60.61.61
0.0.0.255 area 0
Traffic can still be normally forwarded after an active/standby switchover of P1.
8.4.2 IS-IS Graceful Restart Configuration Example

As shown in Figure 8-2, ZXCTN9000 devices P1 and P2 are IS-IS neighbors. Enable the
graceful start function on P1 and P2. One ZXCTN9000 device serves as the GR, and the
other serves as the helper. Data packets can still be normally forwarded when P1 or P2
is restarted.
Figure 8-2 A Configuration Example of IS-IS Graceful Restart
1. Configure ZXCTN9000 devices P1 and P2 as IS-IS neighbors to each other.
ZXCTN9000(config-router)#system-id 0000.0000.0001
8-12
SJ-20100901100356-020|2011-07-30(R1.0)

ZXCTN9000(config-router)#area 00
ZXCTN9000(config-router)#is-type level-2
ZXCTN9000(config-router)#restart t2-timer 100
ZXCTN9000(config-router)#restart t3-timer manual 90
ZXCTN9000(config)#interface vlan 110
ZXCTN9000(config-if-vlan110)#ip router isis
ZXCTN9000(config-if-vlan110)#exit

ZXCTN9000(config-router)#system-id 0000.0000.0002
ZXCTN9000(config-router)#area 00
ZXCTN9000(config-router)#is-type level-2
ZXCTN9000(config-router)#restart t2-timer 100
ZXCTN9000(config-router)#restart t3-timer manual 90
ZXCTN9000(config)#interface vlan 110
ZXCTN9000(config-if-vlan110)#ip router isis
ZXCTN9000(config-if-vlan110)#exit
8.4.3 BGP Graceful Restart Configuration Example

As shown in Figure 8-3, ZXCTN9000 devices P1 and P2 are BGP neighbors. Enable the
graceful start function on P1 and P2. One ZXCTN9000 device serves as the GR, and the
other serves as the helper. Just keep the default configurations when there are not many
routes, so that data packets can still be normally forwarded when P1 or P2 is restarted.
Figure 8-3 A Configuration Example of BGP Graceful Restart
1. Configure ZXCTN9000 devices P1 and P2 as BGP neighbors to each other.
8-13
SJ-20100901100356-020|2011-07-30(R1.0)
ZXCTN9000(config)#router bgp 18004
ZXCTN9000(config-router)#neighbor 25.60.61.61 remote-as 18004
ZXCTN9000(config-router)#neighbor 25.60.61.61 update-source loopback1
ZXCTN9000(config-router)#bgp graceful-restart

ZXCTN9000(config)#router bgp 18004
ZXCTN9000(config-router)#neighbor 25.60.61.60 remote-as 18004
ZXCTN9000(config-router)#neighbor 25.60.61.60 update-source loopback1
ZXCTN9000(config-router)#bgp graceful-restart
8.5 IP Graceful Restart Troubleshooting

This section describes IP Graceful Restart troubleshooting by taking the topology shown
in Figure 8-4 as an example.
Figure 8-4 Network Topology for Troubleshooting IP Graceful Restart Faults

If traffic interruption occurs after active/standby switchover, do as follows:
1. Run the show running-config command to check whether the GR command has been
configured.
2. Check whether the parameters of the GR are correctly configured according to route
information.
8-14
SJ-20100901100356-020|2011-07-30(R1.0)
8.5.3 Handling Flow

Figure 8-5 shows a flow chart for handling IP Graceful Restart faults.
Figure 8-5 IP Graceful Restart Fault Handling Flow

OSPF Graceful Restart
1. Run the show running-config ospf command to check whether the GR command has
been configured.
2. The default value of Grace-period is 120. If the switching time of the restarting router
is rather long, increase the value of Grace-period appropriately.
3. If the switching time of the restarting router is quite long, it is also necessary to
increase the value of the neighbor dead interval of the switching router and the helper
to guarantee successful GR and ensure that the neighbors established with the
restarting router will not be disconnected in the configured time.
IS-IS Graceful Restart

1. Run the show running-config isis command to check whether the GR command has
been configured.
2. The neighbor hold time of the helper must be long to ensure that the helper maintains
the neighbor status of GR during GR switching. In other words, the value of isis
hello-multiplier configured for the interface through which a link is established between
device A and the helper must be large, such as 30. The default value is 3.
3. There is only one criterion to judge whether IS-IS GR is successful: T2 > 0, T3 >
0. Then LSPs are successfully synchronized, T2 is cleared, and T3 (T3 > 0 at this
moment) is also immediately cleared. The GR function is successful. If T2 is already
8-15
SJ-20100901100356-020|2011-07-30(R1.0)
cleared when T3 is cleared, it indicates that the GR function is successful. In general,

the value of T3 is smaller than that of T2. Otherwise, GR success will be always
considered, even if the GR function is not successful. If the number of route entries is
large, T2 and T3 should be set to larger values, such as 300s using commands restart
t2-timer and restart t3-timer.
4. To prevent the T1 timer of an IS-IS-enabled interface without connecting the helper
from affecting GR, generally it is unnecessary to configure the T1 timer for the interface.
Instead, the default values 3s (isis restart t1-timer) and 3 (isis restart t1-retry) can be
kept. For an interface connecting to the helper, the T1 timer can be set to a greater
value such as 20s using the isis restart t1-timer command.
BGP Graceful Restart

1. Run the show running-config bgp command to check whether the GR command has
been configured.
2. Just keep the default settings of GR if there are not many routes.
3. If quite many routes are advertised (for example, 100 thousand routes), set bgp
graceful-restart restart-time and bgp graceful-restart stalepath-time to greater values,
such as 150 and 600 respectively, and set bgp update-delay to 400.
4. It is necessary to first configure the restart-time and stalepath-time of the restart
timer before configuring BGP GR. Otherwise, the BGP automatically reestablishes all
neighbors and negotiates GR capability, whereas the timer configured after BGP GR
does not experience negotiation and cannot take effect. Alternatively, users can reset
IP BGP neighbors after configuring the above command to reestablish neighbors and
negotiate GR capability to validate the timer updates.
5. During GR capability negotiation, the smaller of BGP holdtime and the set bgp
graceful-restart restart-time is taken as bgp graceful-restart restart-time. Therefore, it
is necessary to change the keepalive time and hold time using timers bgp 150 450.
8-16
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 9
Load Sharing Configuration

Table of Contents
Overview of Load Sharing ..........................................................................................9-1
Configuring Route Load Sharing.................................................................................9-1
Configuring Multicast Load Sharing ............................................................................9-1
9.1 Overview of Load Sharing

ZXCTN 9000 supports a variety of load sharing configurations, including route load sharing
and multicast load sharing.
A routing device forwards IP packets according to an IP routing table. In the routing table,
a destination prefix may have multiple paths whose priority can be the same or different.
The routing device always selects the route with the highest priority as the active path.
When multiple paths have the highest priority, the routing device evenly distributes the
traffic of the destination prefix to these paths to attain load sharing.
Load sharing implements two functions:
l Improving link reliability: The network transport layer poses very high stability and
reliability requirements. In terms of reliability, network links must be reliable and the failure
of a certain link should not affect packet forwarding on the other paths or should have little
influence on packet forwarding on the other paths.
l Improving bandwidth: The load sharing function enables the routing device to evenly
distribute traffic to multiple paths to make full use of bandwidth resources. There can be
multiple available route entries for the same destination in the routing table by using routing
protocols or manually configuring static route entries.
9.2 Configuring Route Load Sharing

In general, the route load sharing function is combined with routing protocols. For details
about the working principles and configuration commands of the route load sharing
function, refer to relevant sections in the Configuration Guide IPv4 Routing Volume.
9.3 Configuring Multicast Load Sharing

For details about the working principles and configuration commands of the multicast
load sharing function, refer to relevant sections in the Configuration Guide IPv4 Multicast
Volume.
9-1
SJ-20100901100356-020|2011-07-30(R1.0)
9-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 10
Tunnel Protection Groups

Configuration
Table of Contents
Overview of Tunnel Protection Groups .....................................................................10-1
Configuring the Tunnel Protection Group..................................................................10-3
10.1 Overview of Tunnel Protection Groups

The tunnel protection group module provides 1:1 or 1+1 end-to-end linear protection for
TE tunnels in an IP MPLS system as well as ring protection for static TE tunnels.
When the TMPLS OAM mechanism detects a tunnel failure, it can implement 1+1 or 1:1
end-to-end linear protection or ring protection to trigger protection switching between the
working tunnel and protection tunnel of a tunnel protection group.
Currently, 1+1 or 1:1 end-to-end linear protection and ring protection are available to
implement protection switching between the working tunnel and protection tunnel of a
tunnel protection group. The APS module is invoked to perform switching computation for
tunnel protection switching. 1+1 or 1:1 linear protection can be implemented for dynamic
and static TE tunnels, and ring protection can be implemented for static TE tunnels.
In 1+1 protection mode, traffic is simultaneously sent on the working LSP and the protection
LSP from the protection source. When the working LSP is normal, the protection sink
receives only the traffic on the working LSP. When the working LSP fails, the protection
sink receives only the traffic on the protection LSP.
As shown in Figure 10-1, there are two tunnels from PE1 to PE2. One is the working
tunnel, and the other is the protection tunnel. PE1 is the source node of the tunnels and
the protection source as well. PE2 is the sink node of the tunnels and the protection
sink as well. The OAM function is enabled on both the working tunnel and the protection
tunnel. When a failure as shown in the following figure occurs, PE2 detects the failure
through OAM and can then locally switch from the working tunnel to the protection tunnel
to receive traffic, thus performing protection switching. If the protection mode is revertive,
PE2 detects the restoration of the failure through OAM after the failure is restored, waits
for a certain time, and then locally switches from the protection tunnel to the working tunnel
to receive traffic, thus performing switching restoration.
10-1
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 10-1 1+1 Protection Model
In 1:1 protection mode, if the working LSP is normal, the protection source sends traffic on
only the working LSP, whereas the protection sink receives only the traffic on the working
LSP. If the working LSP fails, the protection source sends traffic on the protection LSP only,
whereas the protection sink receives only the traffic on the protection LSP. For bidirectional
tunnels, a protection end node is both the source node in one direction and the sink node
in the other direction.
As shown in Figure 10-2, there are two tunnels from PE1 to PE2. One is the working
tunnel, and the other is the protection tunnel. PE1 is the source node of the tunnels and
the protection source as well. PE2 is the sink node of the tunnels and the protection sink as
well. The OAM function is enabled on both the working tunnel and the protection tunnel.
When a failure as shown in the following figure occurs, PE2 detects the failure through
OAM, locally switches from the working tunnel to the protection tunnel to receive traffic, and
at the same time sends a switching notification message (an APS protocol packet) to PE1
via the protection tunnel. Upon receipt of the switching notification message, PE1 locally
switches from the working tunnel to the protection tunnel to send traffic, thus performing
protection switching. If the protection mode is revertive, PE1/PE2 detects the restoration
of the failure through OAM after the failure is restored, and sends a switching notification
message to PE2/PE1. Then PE1/PE2 waits for a certain time, and locally switches from
the protection tunnel to the working tunnel to send/receive traffic, thus performing switching
restoration.
Figure 10-2 1:1 Protection Model
10-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 10 Tunnel Protection Groups Configuration
10.2 Configuring the Tunnel Protection Group

For details about the working principles and configuration commands of a tunnel protection
group, refer to relevant sections in the Configuration Guide MPLS Volume.
10-3
SJ-20100901100356-020|2011-07-30(R1.0)
10-4
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 11
MSP Configuration
Table of Contents
Overview of MSP .....................................................................................................11-1
Configuring MSP ......................................................................................................11-2
Maintaining MSP ......................................................................................................11-3
MSP Configuration Example.....................................................................................11-5
MSP Troubleshooting ...............................................................................................11-6
11.1 Overview of MSP

Linear Multiplex Section Protection (MSP) is defined in ITU-T G.841. Applicable
to physical point-to-point networks, linear MSP is a dedicated or shared protection
mechanism to provide protection for the Multiplex Section (MS) layer. It protects a
certain number of working MSs but cannot protect against node failures. MSP can be
single-ended or dual-ended.
MSP is an MS-based protection means. It transmits switching information, including the
switching type, switching reason, the number of the service requesting switching, and
protection mode via the K1/K2 byte, and then summarizes the information to perform
switching to provide protection.
1. 1+1 unidirectional, 1+1 bidirectional, and 1:1 MSP
2. Protection switching between boards or inside a board.
3. MSP group configuration updating, including the updating of protection type and
protection mode configurations.
4. Configuring the revertive/non-revertive mode for various protection types
5. Manual switching (MS), Forced Switching (FS), Lock Protection (LP), and Exercise
Switching (Exer).
6. Switching time less than 50 ms.
7. Card protection STM-1/4 and ATM.
MSP is an automatic protection technology covering automatic detection and automatic
switching. It is necessary to learn the status of links between nodes during the
maintenance of an MSP-enabled network. For example, SF/SD switching in MSP
switching is performed according to the SF/SD indication and thus link detection must
be fast and accurate. In automatic switching mode, however, it is necessary to evaluate
various states (local and remote requests) so as to make a correct decision for switching.
11-1
SJ-20100901100356-020|2011-07-30(R1.0)
11.2 Configuring MSP

Step
Command
Function
ZXCTN9000(config)#interface msp< msp-id>
Enters the MSP configuration mode
ZXCTN9000(config-msp1)#group-type { msp|
Configures the protection type, which is
mc-aps}
"msp" by default
ZXCTN9000(config-msp1)#work-unit<
Configures the working port of MSP
interfacename >
4
Configures the protection port of MSP
ZXCTN9000(config-msp1)#protect-unit<
interfacename >
5
ZXCTN9000(config-msp1)#protect-type {
Configures the MSP protection type, which
1+1uni| 1+1bi| 1:1bi}
is "1+1bi" by default
ZXCTN9000(config-msp1)#protect-mode {
Configures the MSP restoration mode
revertive [ < WTR time> ] | non-revertive}
("revertive" by default) and the WTR time (5

minutes by default)
ZXCTN9000(config-msp1)#protect-switch{ lp|
Configures MSP protection switching
fs work/protect| ms work/protect | exer protect|

clear}

Parameter
Description
msp
The protection group type is "msp"
mc-aps
The protection group type is multi-chassis APS

(This parameter is not applicable to MSP)

Parameter
Description
1+1uni
The MSP protection type is unidirectional 1+1

protection
1+1bi
The MSP protection type is bidirectional 1+1

protection
1:1bi
The MSP protection type is bidirectional 1:1

protection
11-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 11 MSP Configuration
Parameter
Description
revertive
Revertive mode (If it is specified, the WTR time

must be also specified. The WTR time ranges
from 1 to 12 minutes, and is 5 minutes by default)
no-revertive
Non-revertive mode

Parameter
Description
lp
Protection locking; the MSP status machine

switches to the working port to implement link
detection
fs work
Forced switching to the working link; the MSP

status machine switches to the working port to
implement link detection
fs protec
Forced switching to the protection link; the MSP

status machine switches to the protection port to
ms work
Manual switching to the working link; the MSP

status machine switches to the working port to
ms protect
Manual switching to the protection link; the MSP

status machine switches to the protection port to
exer protect
Exercise switching; the MSP status machine

switches to the working port to implement link
detection, and traffic does not switch
clear
Clears all external switching commands, including

LP, FS, and MS commands
11.3 Maintaining MSP

Use the following command on ZXCTN 9000 to maintain and diagnose MSP:
Command
Function
ZXCTN9000(config)#show msp-status msp<
Shows MSP configuration information
msp-id>
11-3
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< msp-id>
ID of the protection group ranging from 1 to 256
The following example shows the outputs of the show msp-status msp< msp-id> command.
ZXCTN9000#show msp-status msp1
MSP Group ID
: 1
Group Type
: MSP
Protect Type
: 1+1 bi
Current State : no request

Running Mode
: work unit
Work Unit
: cstm1_cpos3_7/2/1
Protect Unit
: cstm1_cpos3_6/1/9
RG Group ID
: N/R
RG Link State : N/R

Protect Mode
: revertive
WTR Time
: 5(min)

Output Item
Description
MSP Group ID : 1
ID of the MSP group
Group Type : MSP
Protection group type, which is "msp" by default
Protect Type : 1+1 bi
MSP protection type, which is "1+1bi" by default
Current status of the MSP group
Running Mode : work unit
Running mode of the MSP group
Work Unit : cstm1_cpos3_7/2/1
Working port of MSP
Protect Unit :cstm1_cpos3_6/1/9
Protection port of MSP
RG Group ID : N/R
RG group ID, which is not applicable to MSP
RG Link State : N/R
RG MSP link status, which is not applicable to

MSP
Protect Mode : revertive
MSP restoration mode, which is "revertive" by

default
WTR Time : 5(min)
WTR time, which ranges from 1 to 12 minutes

and is 5 minutes by default
11-4
SJ-20100901100356-020|2011-07-30(R1.0)
11.4 MSP Configuration Example

As shown in Figure 11-1, P1 and P2 are directly connected to each other. It is necessary
to configure MSP protection between P1 and P2.
Figure 11-1 MSP Group Establishment
1. Create a protection group on both P1 and P2.
2. Specify the working port and protection port on P1 and P2.
3. Configure MSP parameters, such as the protection mode and the restoration mode.
By default, the protection type is "1+1bi", the restoration mode is "revertive", and the
WRT time is 5 minutes for a protection group.
4. Run the show msp-status msp< msp-id> command on P1 and P2 to check the current
configuration and status of the protection group.
Run the following configuration command on P1:
P2(config)#interface msp1
P2(config-msp1)#work-unit cstm1-cpos3_7/2/1
P2(config-msp1)#protect-unit cstm1-cpos3_7/2/2
P2(config-msp1)#protect-type 1+1bi
P2(config-msp1)#protect-mode revertive 5
Run the following configuration command on P2:

P1(config)#interface msp1
P1(config-msp1)#work-unit cstm1-cpos3_6/1/9
P1(config-msp1)#protect-unit cstm1-cpos3_6/1/10
P1(config-msp1)#protect-type 1+1bi
P1(config-msp1)#protect-mode revertive 5
P2(config-msp1)#show msp msp1
MSP Group ID
: 1
Group Type
: MSP
Protect Type
: 1+1 bi
11-5
SJ-20100901100356-020|2011-07-30(R1.0)

Running Mode
: work unit
Work Unit
: cstm1-cpos3_7/2/1
Protect Unit
: cstm1-cpos3_7/2/2
RG Group ID
: N/R
RG Link State : N/R

Protect Mode
: revertive
WTR Time
: 5(min)
P1(config-msp1)#show msp msp1

MSP Group ID
: 1
Group Type
: MSP
Protect Type
: 1+1 bi

Running Mode
: work unit
Work Unit
: cstm1-cpos3_6/1/9
Protect Unit
: cstm1-cpos3_6/1/10
RG Group ID
: N/R
RG Link State : N/R

Protect Mode
: revertive
WTR Time
: 5(min)
11.5 MSP Troubleshooting

A common problem with MSP in actual networking is that protection fails, that is, traffic is
interrupted. This section describes MSP troubleshooting by taking the topology shown in
Figure 11-2 as an example.
Figure 11-2 Network Topology for MSP Troubleshooting

When MSP protection fails and the failure causes traffic interruption, the hardware or
software may be faulty. First check the hardware, including whether any line card is
sub-card is improperly installed, and whether the fiber or any optical module is improperly
installed (Check whether all the ports are up). After confirming that the hardware is
11-6
SJ-20100901100356-020|2011-07-30(R1.0)
normal, check the software, including the MSP protection type, protection mode (revertive
or non-revertive), and priority.
11.5.3 Handling Flow

Figure 11-3 shows a flow chart for handling MSP faults.
Figure 11-3 MSP Fault Handling Flow

To handle common MSP faults, perform the following steps:
11-7
SJ-20100901100356-020|2011-07-30(R1.0)
1. Run the show msp-status msp msp-id command on P1 and P2 to check whether the
current status of the protection group is consistent. If the status is consistent, check
whether the link under Running Mode is up.
configured protection type is consistent. If the protection type is inconsistent, modify
the MSP protection type till consistent.
configured protection mode is consistent. If the protection mode is inconsistent, modify
the MSP protection mode till consistent.
4. Check whether the protection group failure or traffic interruption is caused by priority.
If yes, perform the protection switching operation using the correct priority.
11-8
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 12
MPLS-TP OAM Configuration

Table of Contents
Overview of MPLS-TP OAM .....................................................................................12-1
Configuring MPLS-TP OAM......................................................................................12-1
Maintaining MPLS-TP OAM......................................................................................12-7
MPLS-TP OAM Configuration Example ....................................................................12-8
MPLS-TP OAM Troubleshooting ............................................................................12-13
12.1 Overview of MPLS-TP OAM

MPSL-TP is a connection-oriented packet switching network technology. Using MPLS
LSPs, MPSL-TP eliminates MPLS signaling and complex IP functions, and supports
multi-service bearing. Independent of the client layer and the control plane, MPSL-TP
supports multiple physical layer technologies and provides powerful transport capabilities,
including QoS, OAM, and reliability.
The predecessor of MPLS-TP is T-MPLS. The concept of T-MPLS was first put forward
by ITU-T in 2005, aiming to implement simple but efficient packet transmission with the
MPLS technology. T-MPLS uses the same forwarding mechanism as MPLS, but simplifies
the L3 technologies of MPLS irrelevant to transmission, and provides enhanced OAM
and protection mechanisms to make up for the inadequacy of MPLS to support transport
networks.
MPLS-TP OAM is a service-oriented packet transport network OAM technology. Its
technical descriptions cover the OAM technology used in a packet transport network
and PTN OAM mechanisms based on the MPLS-TP technology, such as fault detection,
protection switching, and performance monitoring.
l
l
l
l
Strict GACh+Y.1731 encapsulation for OAM packets

Continuity Check (CC), Remote Defect Indication (RDI), Loop Back (LB), Link Tracing
(LT), Alarm Indication Signal (AIS), Client Signal Failure (CSF), etc.
Performance measurement functions, such as LM frame loss measurement and DM
delay measurement.
Interactive processing.
12.2 Configuring MPLS-TP OAM

Use the following commands on ZXCTN 9000 to configure MPLS-TP OAM:
12-1
SJ-20100901100356-020|2011-07-30(R1.0)
Step
Command
Function
ZXCTN9000(config)#tmpls oam { enable|
Globally enables MPLS-TP OAM
disable}
2
ZXCTN9000(config)#tms < tms-id>
Enters the TMS configuration mode
ZXCTN9000(config)#tunnel < tunnel-id>
Enters the TMP configuration mode
ZXCTN9000(config)#pw < pw-name>
Enters the TMC configuration mode
ZXCTN9000(config-tms)#tmpls oam meg <
Creates an MEG in TMS configuration mode
meg-index>
6
ZXCTN9000(config-tunnel)#tmpls oam meg
Creates an MEG in TMP configuration mode
< meg-index>
7
ZXCTN9000(config-pw)#tmpls oam meg <
Creates an MEG in TMC configuration mode
meg-index>
8
ZXCTN9000(config-instance-meg)#tmpls
Enables MPLS-TP OAM in MEG
oam { enable| disable}
configuration mode
Configures the ID of an MEG
oam meg-id < meg-id>

10
Configures the speed of the MEG
oam meg speed { fast| slow}

11
Configures the local MEP of the MEG
oam meg local-mep < mep-id> type { source |

direction| bidirectional}
12
Configures the peer MEP of the MEG
oam meg peer-mep < mep-id> type { source |

direction| bidirectional}
13
Configures the CV function
oam cv
14
Configures the CC function
oam cv cc
15
16
Configures the sending interval of CV
oam cv period < interval>
packets
Configures the PHB of CV packets
oam cv phb < phb-value>

17
Enables/disables the MIP
oam mip { enable | disable}

18
Configures the attributes of an MIP
oam mip < mip-id> port < port-name>
12-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 12 MPLS-TP OAM Configuration
Step
Command
Function
19
Configures the LB function
oam lb { peer-mep < mep-id> | peer-mip <

mip-id> } phb < phb-value> [ type { connect
| diagnose} | hop-count < hop-count>
| report-interval < report-interval> |
send-interval < send-interval> | send-time
< send-time> ]
20
Configures the LT function
oam linktrace hop-counts-max < hop-value>

[ phb < phb-value> ] [ send-count <
send-count> ] [ send-interval < send-interval> ]
[ loss-thresh < thresh-value> ]
21
Configures the PHB of AIS packets
oam ais phb < phb-value>

22
Configures the PHB of CFS packets
oam csf phb < phb-value>

23
Configures the LM function
oam lm { proactive| on-demand} source-mep

< mep-id> phb < phb-value> [ report-interval
< report-interval> ] [ send-interval <
send-interval> ] [ send-time < send-time> ]
24
Configures the DM function
oam dm mode { one-way| two-way}

source-mep < mep-id> phb < phb-value>
[ report-interval < report-interval> ] [
send-interval < send-interval> ] [ send-time
< send-time> ]

Parameter
Description
{enable|disable}
Whether to globally enable or disable MPLS-TP

OAM (Disabled by default)

Parameter
Description
< tms-id>
TMS ID, ranging from 1 to 65535
12-3
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< tunnel-id>
Tunnel ID, ranging from 1 to 8192

Parameter
Description
< pw-name>
PW name, which is a string of at most 64

characters
The command parameter in steps 5, 6, and 7 is described as follows:

Parameter
Description
< meg-index>
MEG index, ranging from 1 to 65535

Parameter
Description
{enable|disable}
Whether to enable or disable the MPLS-TP OAM

function of the MEG (Disabled by default)

Parameter
Description
< meg-id>
MEG ID, a string of at most 13 characters (By

default, the MEG ID is not configured)

Parameter
Description
{fast|slow}
Speed of the MEG: "fast" or "slow"; "fast" by

default
The command parameters in steps 11 and 12 are described as follows:

Parameter
Description
< meg-id>
ID of the local MEP, ranging from 1 to 8191
{source |direction| bidirectional}
MEP type: source MEP, sink MEP, or bidirectional

MEP

Parameter
Description
< interval>
Sending interval of VC packets: 3.33 ms, 10 ms,

100 ms, 1 s, 10 s, 1 min, or 10 min
12-4
SJ-20100901100356-020|2011-07-30(R1.0)

Parameter
Description
< phb-value>
PHB value in QoS mapping: be, af11, af12, af21,

af22, af31, af32, af41, af42, cs6, cs7, ef

Parameter
Description
{enable|disable}
Whether to enable or disable the MIP (Disabled

by default)

Parameter
Description
< mip-id>
MIP ID, ranging from 1 to 8191
< port-name>
Name of the interface to which the MIP is bound

Parameter
Description
< mep-id>
ID of the peer MEP, ranging from 1 to 8191
< mip-id>
ID of the peer MIP, ranging from 1 to 8191
< phb-value>

{connect | diagnose}
LB type: "connect" or "diagnose" (Currently the

diagnosis mode is not supported)
< mip-id>
ID of the peer MIP, ranging from 1 to 8191
< hop-count>
If the destination is an MEP, the hop count is 1.

If the destination is an MIP, the hop count is the
number of hops from the source MEP to the
destination MIP, that is, 2-N
< report-interval>
The interval at which the LB test result data is

reported, ranging from 1 to 86400 seconds
< send-interval>
Sending interval of LB packets, ranging from 100

to 10000 ms
< send-time>
Total sending time of LB packets, ranging from 10

to 86400 seconds
12-5
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< hop-value>
The maximum hop count of the LT function,

< phb-value>

< send-count>
The number of times to send the LT packet,

< send-interval>
Sending interval of LT packets, ranging from 100

to 10000 ms
< thresh-value>
Packet loss threshold, ranging from 1 to 10
The command parameter in steps 21 and 22 is described as follows:

Parameter
Description
< phb-value>


Parameter
Description
{proactive| on-demand}
LM mode: proactive or on-demand LM
< mep-id>
ID of the source MEP initiating the LM test,

< phb-value>

< report-interval>
The interval at which the LM test result data is

< send-interval>
Sending interval of LM packets, ranging from 100

to 10000 ms
< send -value>
Total sending time of LM packets, ranging from

10 to 86400 seconds

Parameter
Description
{one-way| two-way}
DM mode: one-way or two-way DM
< mep-id>
ID of the source MEP initiating the DM test,

< phb-value>

12-6
SJ-20100901100356-020|2011-07-30(R1.0)
Parameter
Description
< report-interval>
The interval at which the DM test result data is

< send-interval>
Sending interval of DM packets, ranging from

100 to 10000 ms
< send-value>
Total sending time of DM packets, ranging from

10 to 86400 seconds
12.3 Maintaining MPLS-TP OAM

Use the following commands on ZXCTN 9000 to maintain and diagnose the MPLS-TP
OAM function:
Command
Function
ZXCTN9000(config)#show tmpls meg-info [ <
Shows MEG configuration information
meg-index> ]
ZXCTN9000(config)#show tmpls oam lm [ <
Shows LM statistics information about the
meg-index> ]
configured MEG
ZXCTN9000(config)#show tmpls dm megindex
Shows DM statistics information about the
< meg-index>
configured MEG
ZXCTN9000#debug tmpls-oam { all | bytes <
Shows MPLS-TP OAM debugging information
bytes-type> | error | event { all | < meg-index> } |

packet < packet-type> }

Parameter
Description
[ < meg-index> ]
MEG index ranging from 1 to 65535
[ < bytes-type> ]
Shows packet information by bytes (Packet type:

cc, ais, fei, aps, lb, lt, csf, lm, dm, all)
[ < packet-type> ]
Shows packet information by text (Packet type:

cc, ais, fei, aps, lb, lt, csf, lm, dm, all, 1-65535)
The following example shows the outputs of the show tmpls meg-info command.
ZXCTN9000#show tmpls meg-info
Meg_1 Information:
-----------------------------------------MegId
abc
MegSpeed
FAST
MegEnableFlag
ENABLE
12-7
SJ-20100901100356-020|2011-07-30(R1.0)

MegInstanceInfo
TUNNEL_1
------------------------------------------
The outputs of the show tmpls meg-info command are described as follows:
Output Item
Description
MegId
MEG ID
MegSpeed
MEG speed: fast or slow
MegEnableFlag
Whether MEG is enabled
MegInstanceInfo
Information about the instance bound to MEG
The following example shows the outputs of the debug tmpls bytes lb command.
ZXCTN9000#debug tmpls bytes lb
Nov 30 01:05:59: TMPLS-OAM:IN:
E0 03 00 04 00 00 00 0B 21 00 0F 00 12 61 62 63
00 00 00 00 00 00 00 00 00 00 21 00 0F 00 11 61
62 63 00 00 00 00 00 00 00 00 00 00 00
The following example shows the outputs of the debug tmpls packet lb command.
ZXCTN9000#debug tmpls packet lb
Nov 30 01:06:45:
TMPLS-OAM:IN:
E0 03 00 04 00 00 00 15 21 00 0F 00 12 61 62 63
00 00 00 00 00 00 00 00 00 00 21 00 0F 00 11 61
62 63 00 00 00 00 00 00 00 00 00 00 00
Nov 30 01:06:45:
TMPLS-OAM:PANNEL:[5]Received
packet from tmpls-oam:MEGINEX:MEG
ID:MEPID:MIPID [1:abc:18:0]: MEL:VERSION:FLAG [7:0:0],packet type LBM.

Nov 30 01:06:45:
TMPLS-OAM:PANNEL:[5]Send packet to tmpls-oam:MEGINEX:MEGID:MEPI
D:MIPID [1:abc:18:0]: MEL:VERSION:FLAG [7:0:0],packet type LBR.
12.4 MPLS-TP OAM Configuration Example

As shown in Figure 12-1, P1 and P2 are directly connected to each other. Configure
MPLS-TP OAM on the direct connection interfaces of P1 and P2 to establish a connection
between P1 and P2.
12-8
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 12-1 MPLS-TP OAM Connection Establishment
1. Configure static MAC and ARP entries on P1 and P2, and globally enable MPLS-TP
OAM.
2. Create TMS, TMP, and TMC instances on P1 and P2, create an MEG with the same
MEG ID on TMS, TMP, and TMC, configure the attributes and members of the MEG,
and then check the connection establishment status of the MEGs on P1 and P2 to
determine whether there is any Loss of Connectivity (LoC) alarm.
3. Perform loopback operations on the MEP of P2 from P1 to check the continuity of the
link between P1 and P2.
P1(config-gei_1/1)#switchport mode trunk
P1(config-gei_1/1)#switchport trunk vlan 20
P1(config)#interface vlan20
P1(config-if-vlan20)#set arp permanent 20.1.1.2 00d0.d0c7.ffe1
P1(config)#mac add permanent 00d0.d0c7.ffe1 interface gei_1/1 vlan 20
P1(config)#tmpls oam enable
P1(config)#pw-class ControlWordEnable
P1(config-pw-class)#control-word preferred
P1(config-pw-class)#exit
P1(config)#tms 1
P1(config-tms)#local-port gei_1/1 peer-port 20.1.1.2
P1(config-tms)#tmpls oam meg 1
P1(config-instance-meg)#tmpls oam enable
P1(config-instance-meg)#tmpls oam meg-id 1
P1(config-instance-meg)#tmpls oam meg speed fast
P1(config-instance-meg)#tmpls oam local-mep 1 type bidirectional
12-9
SJ-20100901100356-020|2011-07-30(R1.0)

P1(config-instance-meg)#tmpls oam peer-mep 2 type bidirectional
P1(config-instance-meg)#tmpls oam cv
P1(config-instance-meg)#tmpls oam cv cc
P1(config-instance-meg)#tmpls oam cv period 3.33ms
P1(config-instance-meg)#tmpls oam cv phb cs7
P1(config-instance-meg)#exit
P1(config-tms)#exit
P1(config)#tunnel 1
P1(config-tunnel)#tunnel mode traffic-engineer static
P1(config-tunnel)#tunnel id 1
P1(config-tunnel)#tunnel enable
P1(config-tunnel)#oam-propagate auto immediately
P1(config-tunnel)#sd disable
P1(config-tunnel)#flowstat disable
P1(config-tunnel)#tunnel static type bidirectional role ingress
P1(config-tunnel)#tunnel static ingress 1.1.1.1 egress 2.2.2.2 out-port
gei_1/1 out-label 845825 next-hop 20.1.1.2
P1(config-tunnel)#tunnel static ingress 2.2.2.2 egress 1.1.1.1 in-port
gei_1/1 in-label 845824
P1(config-tunnel)#tmpls oam meg 2
P1(config-tunnel)#exit
P1(config)#pw 1
P1(config-pw)#mode static
P1(config-pw)#apply pw-class 1:0:0
P1(config-pw)#peer 2.2.2.2 vcid 100 local-label 584000 remote-label 584001
P1(config-pw)#exit
P1(config)#vll 1
P1(config-vll)#service-type ethernet
P1(config-vll)#mode vlan-all
P1(config-vll)#mpls xconnect pw 1
P1(config-vll)#exit
P1(config)#cip 1
P1(config-cip)#service-type ethernet
P1(config-cip)#xconnect 1
12-10
SJ-20100901100356-020|2011-07-30(R1.0)

P1(config-cip)#exit
P1(config)#pw 1
P1(config-pw)#tmpls oam meg 3
P1(config-pw)#exit

P2(config-gei_2/1)#switchport mode trunk
P2(config-gei_2/1)#switchport trunk vlan 20
P2(config)#interface vlan20
P2(config-if-vlan20)#set arp permanent 20.1.1.1 0818.1a94.0471
P2(config)#mac add permanent 0818.1a94.0471 interface gei_2/1 vlan 20
P2(config)#tmpls oam enable
P2(config)#pw-class ControlWordEnable
P2(config-pw-class)#control-word preferred
P2(config-pw-class)#exit
P2(config)#tms 1
P2(config-tms)#local-port gei_2/1 peer-port 20.1.1.1
P2(config-tms)#tmpls oam meg 1
12-11
SJ-20100901100356-020|2011-07-30(R1.0)

P2(config-tms)#exit
P2(config)#tunnel 1
P2(config-tunnel)#tunnel mode traffic-engineer static
P2(config-tunnel)#tunnel id 1
P2(config-tunnel)#tunnel enable
P2(config-tunnel)#oam-propagate auto immediately
P2(config-tunnel)#sd disable
P2(config-tunnel)#flowstat disable
P2(config-tunnel)#tunnel static type bidirectional role egress
P2(config-tunnel)#tunnel static ingress 2.2.2.2 egress 1.1.1.1 out-port
gei_2/1 out-label 845824 next-hop 20.1.1.1
P2(config-tunnel)#tunnel static ingress 1.1.1.1 egress 2.2.2.2 in-port
gei_2/1 in-label 845825
P2(config-tunnel)#tmpls oam meg 2
P2(config-tunnel)#exit
P2(config)#pw 1
P2(config-pw)#mode static
P2(config-pw)#apply pw-class 1:0:0
P2(config-pw)#peer 1.1.1.1 vcid 100 local-label 584001 remote-label 584000
P2(config-pw)#exit
P2(config)#vll 1
P2(config-vll)#service-type ethernet
P2(config-vll)#mode vlan-all
P2(config-vll)#mpls xconnect pw 1
P2(config-vll)#exit
P2(config)#cip 1
P2(config-cip)#service-type ethernet
P2(config-cip)#xconnect 1
P2(config-cip)#exit
P2(config)#pw 1
P2(config-pw)#tmpls oam meg 3
12-12
SJ-20100901100356-020|2011-07-30(R1.0)

P2(config-pw)#exit
1. Run the show logging current-alarm command on P1 to check whether there is any
LoC alarm for the MEG.
P1(config)#show logging current-alarm typeid tms-mep
P1(config)#show logging current-alarm typeid tmp-mep
P1(config)#show logging current-alarm typeid tmc-mep
/*It indicates that currently there is no LoC alarm and the MEG is normal.*/
2. Run the show logging current-alarm command on P2 to check whether there is any
LoC alarm for the MEG.
P2(config)#show logging current-alarm typeid tms-mep
P2(config)#show logging current -alarm typeid tmp-mep
P2(config)#show logging current -alarm typeid tmc-mep
/*It indicates that currently there is no LoC alarm and the MEG is normal.*/
3. Perform loopback operations on P1 and P2 to check the connectivity of the MEGs on

them.
P1(config-instance-meg)#tmpls oam lb peer-mep 2 phb cs7
Codes: '!' - success, '.' - timeout
!!!!!!!!!!
Success rate is 100 percent(10/10).
P2(config-instance-meg)#tmpls oam lb peer-mep 1 phb cs7
Codes: '!' - success, '.' - timeout
!!!!!!!!!!
Success rate is 100 percent(10/10).
12.5 MPLS-TP OAM Troubleshooting

A common problem with MPLS-TP OAM in actual networking is that the MEG generates
a Loss Of Connectivity (LOC) alarm. The symptom can be one of the following:
l
l
LOC alarms are generated at one end, and RDI alarms are generated at the other
end.
LOC alarms are generated at one end only.
12-13
SJ-20100901100356-020|2011-07-30(R1.0)
LOC alarms are generated at both ends.
All the above symptoms indicate that a link failure occurs. This section describes the cause
of such faults and relevant solutions by taking the topology shown in Figure 12-2 as an
example.
Figure 12-2 Network Topology for MPLS-TP OAM Troubleshooting

When MEG detection fails between P1 and P2, the following causes are possible:
1. The static MAC and ARP entries configured on P1 and/or P2 are incorrect, or some
entries are missing.
2. The TMS, tunnel, and PW configurations on P1 and/or P2 are incorrect, or the creation
fails.
3. The attribute and member configurations of the MEGs on P1 and P2 are incorrect,
the OAM function is not yet enabled for the MEGs, the MEG ID and CV period are
inconsistent, or the local/peer MEP ID is incorrect.

Figure 12-3 shows a flow chart for handling the MPLS-TP OAM connection establishment
failure.
12-14
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 12-3 MPLS-TP OAM Fault Handling Flow

To handle common MPLS-TP OAM faults, perform the following steps:
1. Run commands show arp and show mac on P1 and P2, and then ping the next-hop IP
address. Ensure that the configured static MAC and ARP entries are correct, and the
next-hop IP address can be pinged through.
2. Ping the corresponding tunnel or PW from P1/P2 to check whether the forwarding of
the tunnel or PW is normal. For TMS, it is necessary to ping the next-hop IP address
to check whether route forwarding is normal.
3. Run commands show run | begin tms, show run | begin tunnel, and show run | begin pw
on P1 and P2 to check whether the attribute and member configurations of the MEG
are correct.
12-15
SJ-20100901100356-020|2011-07-30(R1.0)
12-16
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 13
Active/Standby Switchover
Table of Contents
Overview of Active/Standby Switchover....................................................................13-1
Phases in Active/Standby Switchover.......................................................................13-1
Active/Standby Switchover Status Determination .....................................................13-2
Triggering Active/Standby Switchover ......................................................................13-2
Active/Standby Switchover Command ......................................................................13-3
Instructions on Active/Standby Switchover ...............................................................13-3
13.1 Overview of Active/Standby Switchover

PTN equipment plays a rather important role in a network. For this reason, single-point
failures are not allowed. In general, the equipment has two main control boards, called
the master MP and the slave MP. The master MP is the core of the control plane to
communicate with service boards and external units to accomplish the normal functions
of various modules in the system. The slave MP is only a backup of the master MP and
does not communicate with service boards or external units. When the master MP fails,
the system automatically performs active/standby switchover so that the slave MP takes
over the master MP to guarantee normal service operations.
The active/standby MP switchover process consists of three phases: batch backup,
real-time backup, and data smoothing.
13.2 Phases in Active/Standby Switchover

Batch Backup
After the slave MP is started, the master MP synchronizes the data to be backed up to
the slave MP in batch mode, because a great data difference exists between them. This
process is called batch backup. The time taken for batch backup depends on the volume
of the data to be backed up and the communication rate of the transmission channel.
Real-Time Backup
After the batch backup process is over, the system enters a real-time backup process.
When the backup data on the master MP changes in the real-time backup process, the
backup data is synchronized in real time to the slave MP. This usually lasts for a very short
time.
13-1
SJ-20100901100356-020|2011-07-30(R1.0)
Data Smoothing
The slave MP is escalated and becomes the new master MP after active/standby
switchover. Then it sends a notification message to all modules, instructing them to collect
data from and synchronize to service boards. This process is called data smoothing. In
the data smoothing process, all modules actively communicate with service boards to
confirm the hardware status, link layer status, and configuration data with the service
boards and to synchronize to the service boards if inconsistency exists, so as to ensure
that the data and status information maintained by the entire system are consistent to
guarantee normal system running after active/standby switchover. The new master MP
is really active only after the data smoothing phase is over.
13.3 Active/Standby Switchover Status Determination

When two MPs are configured, whether an MP is the master or slave MP shall be
determined by hardware during the start of the MP. In general, the system selects the
MP with a smaller slot number as the master MP. If both MPs are to be started, system
hardware sets a delay for the MP with a greater slot number so that the MP is started later.
Both MPs are slave MPs during initial start, and perform software start respectively. When
the MP with a smaller slot number is started at a certain phase, it sets its own status to
Normal and checks whether the status of the other MP is Normal. For the MP with a greater
slot number, a delay is set before it checks whether the status of the other MP is Normal
and sets its own status to Normal.
Therefore, the status of the MP with a greater slot number is not yet Normal when the
status of the MP with a smaller slot number is already Normal. Then the MP with a smaller
slot number becomes the master MP. When the MP with a greater slot number checks the
status of the other MP after the delay is over, it finds that the status of the other MP is
Normal and thus sets its own status to Slave. In this way, even if the MP with a greater
slot number is the master MP before system restart when two MPs are configured, the MP
with a smaller slot number becomes the master MP instead after system restart.
13.4 Triggering Active/Standby Switchover

If the slave MP in the status of receiving data in real time detects a switchover notification,
it switches over and becomes the master MP. The detection notification is triggered by
an interrupt, and hardware switching is completed within a matter of milliseconds during
the active/standby switchover. After hardware switching is completed, the active/standby
status machines of the new mater MP enter the data smoothing status and the data
smoothing process continues.
Active/standby switchover can be triggered by one of the following factors:
l
l
Forced switchover is triggered when users run a forced active/standby switchover

command.
Switchover is triggered when a hard reset occurs on the master MP, or when the
master MP is manually pulled out.
13-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 13 Active/Standby Switchover
Switchover is triggered when software exceptions occur on the master MP to cause a

restart of the master MP. For example, the hardware watchdog will restart the system
if a certain module occupies the CPU for an excessively long time; the system will
restart as a result of data access exceptions, command access exceptions, or other
system exceptions.
It takes the same time for the slave MP to detect the switchover notification, no matter
what factor triggers the switchover. The detection notification is triggered by a hardware
interrupt, and status switching is completed within a matter of milliseconds.
Both the master MP and the slave MP periodically send handshake messages to each
other. If the master or slave MP does not receive a handshake message from the peer
within the specified time, it considers that the master-slave communications fail. Then the
slave MP is reset.
13.5 Active/Standby Switchover Command

1. To perform forced active/standby switchover, run the following command in privileged
mode:
ZXCTN9000#redundancy force-switchover
2. The system gives the following prompt:

Proceed with switchover to standby MSC? [yes/no]:y
3. Type the letter "y". If the slave MP board is not online, the system gives the following
prompt:
%Error 27604: Slave board is not online
4. If the slave MP is online but data is not yet completely synchronized, the system gives
the following prompt:
%Error 6552: Database sync is not Ready!
5. If the system gives the prompt as described in step 4, manually synchronize the
database using the following command in privileged mode:
ZXCTN9000#syncdb
Repeat step 1 after the synchronization is complete.
13.6 Instructions on Active/Standby Switchover

1. Save configuration information before active/standby switchover using the following
command in privileged mode:
ZXCTN9000#write
After confirming that the configuration information is successfully saved, export it for
backup as much as possible and then run the active/standby switchover command.
After the active/standby switchover is completed, compare the configuration
information with the backup configuration information. If the configuration information
is consistent and services are normal, the active/standby switchover is successful.
Otherwise, contact technical personnel for help.
13-3
SJ-20100901100356-020|2011-07-30(R1.0)
2. Line cards will not restart during active/standby switchover. If the line cards restart and
services are abnormal after the restart, contact technical personnel for help.
3. Do not forcibly perform switchover. Otherwise, services can be abnormal due to system configuration data loss or data exceptions after the switchover. If the active/standby switchover is unsuccessful, contact technical personnel for help.
13-4
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 14
MCLAG Configuration
Table of Contents
Overview of mcLag...................................................................................................14-1
Configuring mcLag ...................................................................................................14-2
Maintaining mcLag ...................................................................................................14-4
mcLag Configuration Instances ................................................................................14-4
mcLag Troubleshooting ............................................................................................14-7
14.1 Overview of mcLag

The Multi-Chassis Link Aggregation Group (mcLag) technology provides a link backup
and recovery mechanism based on the original LACP to implement inter-chassis link
protection. An active link and a standby link (instead of load sharing) are configured in
a link aggregation group. When the active link is down, traffic is switched over to the
standby link within 50 ms.
As shown in Figure 14-1, the CE-PE1 link is the active link whereas the CE-PE2 link is
the standby link. In normal cases, the active link is working and the standby link serves
as a backup of the active link. If the active link is down, traffic is switched over to the
standby link. When the active link is recovered, traffic can be switched back to the active
link depending on the specific configurations.
Figure 14-1 Working Principles of mcLag
Link faults on the CE side can be detected by means such as CFM, EFM, or ZFID. The
system supports both a static mode and a dynamic mode for selecting the active link and
14-1
SJ-20100901100356-020|2011-07-30(R1.0)
the standby link. In static mode, the standby link is specified through manual configuration.
In dynamic mode, the active link and the standby link are selected through LACP packet
exchange between the CE and the two PE devices. The selection is based on the chassis
addresses and priority of the two peer PE devices.
14.2 Configuring mcLag

14.2.1 Configuring Static mcLag
Use the following commands on ZXCTN 9000 to configure static mcLag:
Step
Command
Function
ZXCTN9000(config)#interface smartgroup<
Creates an LACP group
lacp-id>
2
ZXCTN9000(config-smartgroup1)#smartgr
Sets the smart group to static mode
oup mode on
3
interface-name>
4
ZXCTN9000(config-[x]gei_x/y[/z])#smart
Adds a port to the smart group
group < lacp-id> mode on

5
ZXCTN9000(config-[x]gei_x/y[/z])#lacp
Configures the port as a backup port
protection

Parameter
Description
< lacp-id>
LACP group ID

Parameter
Description
< interface-name>
Name of the interface to be added to the smart

group

Parameter
Description
< lacp-id>
LACP group ID
14-2
SJ-20100901100356-020|2011-07-30(R1.0)
Chapter 14 MCLAG Configuration
Parameter
Description
< interface-name>

group

Parameter
Description
< lacp-id>
LACP group ID
14.2.2 Configuring Dynamic mcLag

Use the following commands on ZXCTN 9000 to configure dynamic mcLag:
Step
1
Command
Function
ZXCTN9000(config)#interface smartgroup<
Creates an LACP group
lacp-id>
2
Sets the smart group to dynamic mode
oup mode 802.3ad

3
Sets the MAC address of the smart group
oup sys-mac < sys-mac>

4
Sets the priority of the smart group
oup sys-priority < sys-priority>

5
interface-name>
6
ZXCTN9000(config-[x]gei_x/y[/z])#smart
Adds a port to the smart group
group < lacp-id> mode active

Parameter
Description
< lacp-id>
LACP group ID

Parameter
Description
< sys-mae>
System MAC address of the smart group

Parameter
Description
< sys-priority>
System priority of the smart group

14-3
SJ-20100901100356-020|2011-07-30(R1.0)

Parameter
Description
< interface-name>

group

Parameter
Description
< lacp-id>
LACP group ID
14.3 Maintaining mcLag

Use the following command on ZXCTN 9000 to maintain and diagnose mcLag:
Command
Function
ZXCTN9000#show lacp < lacp-id> internal
Shows mcLag interface configuration information

and status
The command parameters are described as follows:

Parameter
Description
< lacp-id>
LACP group ID
14.4 mcLag Configuration Instances

14.4.1 Static mcLag Configuration Example
As shown in Figure 14-2, static mcLag is configured on P1.
14-4
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 14-2 A Configuration Example of Static mcLag
Configure mcLag on P1.
ZXCTN9000(config)#interface smartgroup1
ZXCTN9000(config-smartgroup1)#smartgroup mode on
ZXCTN9000(config-smartgroup1)#ex
ZXCTN9000(config)#interface gei_4/4
ZXCTN9000(config-gei_4/4)#smartgroup 1 mode on
ZXCTN9000(config-gei_4/4)#ex
ZXCTN9000(config-gei_4/2)#smartgroup 1 mode on
ZXCTN9000(config-gei_4/2)#lacp protection
ZXCTN9000(config-gei_4/2)#exit
A smart group can be successfully established after the configuration. Run the following
command to check the configuration results.
ZXCTN9000(config)#show lacp 1 internal
Smartgroup:1
Switch attribute:TRUE
Mode:on
Flag *--Loop is TRUE

Actor
Agg
LACPDUs
Port
Oper
Port
State
Interval Priority Key
Port
RX
Mux
State Machine
Machine
---------------------------------------------------------------------gei_4/4
active
30
32768
0x111
0x3d
N/A
N/A
14-5
SJ-20100901100356-020|2011-07-30(R1.0)

gei_4/2
inactive
30
32768
0x111
0x45
N/A
N/A
14.4.2 Dynamic mcLag Configuration Example

As shown in Figure 14-3, static mcLag is configured on P1, P2, and P3.
Figure 14-3 A Configuration Example of Dynamic mcLag
Configure mcLag on P1, P2, and P3.
ZXCTN9000(config-smartgroup1)#smartgroup mode 802.3ad
ZXCTN9000(config-gei_1/1)#smartgroup 1 mode active
ZXCTN9000(config-gei_1/1)#ex
ZXCTN9000(config-gei_1/2)#exit

ZXCTN9000(config-smartgroup1)#smartgroup sys-priority 2
14-6
SJ-20100901100356-020|2011-07-30(R1.0)


ZXCTN9000(config-smartgroup1)#smartgroup sys-priority 1
A smart group can be successfully established after the configuration. Run the following
command to check the configuration results.
ZXCTN9000(config)#show lacp 1 internal
Smartgroup:3
Switch attribute:TRUE
Mode:802.3ad
Flag *--Loop is TRUE

ActorPort AggState LACPDUsInterval PortPri OperKey PortState RXMachine MuxMachine
--------------------------------------------------------------------------------gei_4/4
active
30
32768
0x311
0x3d
current
distributing
gei_4/2
inactive
30
32768
0x321
0x5
current
defaulte
14.5 mcLag Troubleshooting

This section describes mcLag troubleshooting by taking the topology shown in Figure 14-4
as an example.
14-7
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 14-4 Network Topology for mcLag Troubleshooting

For static mcLag, check whether ports have been added to the aggregation group and
whether the aggregation group successfully aggregates the ports. If a port fails to normally
forward data, check whether the Spanning Tree Protocol (STP) status of the port is normal.
For dynamic mcLag, also check whether LCAP packets are normally sent and received.

Figure 14-5 shows a flow chart for handling mcLag faults.
14-8
SJ-20100901100356-020|2011-07-30(R1.0)
Figure 14-5 mcLag Fault Handling Flow

To handle common mcLag faults, perform the following steps:
1. Check whether the ports have been added to the aggregation group.
2. Check whether the aggregation group successfully aggregates the ports.
3. Check whether L2 forwarding is normal.
14-9
SJ-20100901100356-020|2011-07-30(R1.0)
14-10
SJ-20100901100356-020|2011-07-30(R1.0)
Figures
Figure 2-1 Interactions Between VRRP, Service Availability Manager, EOAM, and
BFD ........................................................................................................ 2-3
Figure 2-2 Status Interactions of CE Devices Dual-Homed to PE Devices ................ 2-4
Figure 2-3 LINK BFD Interacting with VRRP ............................................................. 2-8
Figure 2-4 CFM Interacting with VRRP ................................................................... 2-12
Figure 2-5 Network Topology for Service Availability Manager
Troubleshooting .................................................................................... 2-15
Figure 2-6 Service Availability Manager Fault Handling Flow .................................. 2-16
Figure 3-1 Default Gateway for the LAN.................................................................... 3-1
Figure 3-2 Working Principles of the VRRP............................................................... 3-2
Figure 3-3 VRRP Status Transition ........................................................................... 3-4
Figure 3-4 Configuring the Basic VRRP .................................................................... 3-9
Figure 3-5 Configuring Symmetrical VRRP ............................................................. 3-11
Figure 3-6 Configuring the VRRP Heartbeat Line (IPv4) ......................................... 3-13
Figure 3-7 Configuring VRRP Track ........................................................................ 3-15
Figure 3-8 Network Topology for VRRP Troubleshooting......................................... 3-17
Figure 3-9 VRRP Fault Handling Flow 1.................................................................. 3-18
Figure 3-10 VRRP Fault Handling Flow 2................................................................ 3-19
Figure 4-1 Working Principles of EFM ....................................................................... 4-2
Figure 4-2 EFM Connection Establishment ............................................................... 4-8
Figure 4-3 EFM Remote Loopback ......................................................................... 4-12
Figure 4-4 Network Topology for EFM Troubleshooting ........................................... 4-13
Figure 4-5 EFM Fault Handling Flow....................................................................... 4-14
Figure 5-1 MD........................................................................................................... 5-1
Figure 5-2 CFM Connection Establishment............................................................. 5-12
Figure 5-3 Inter-L2VPN Connectivity Check ............................................................ 5-16
Figure 5-4 Network Topology for CFM Troubleshooting........................................... 5-19
Figure 5-5 CFM Fault Handling Flow....................................................................... 5-20
Figure 6-1 Interface BFD ........................................................................................ 6-10
Figure 6-2 A Configuration Example of Static BFD.................................................. 6-11
Figure 6-3 A Configuration Example of OSPF BFD ................................................. 6-13
Figure 6-4 A Configuration Example of IS-IS BFD................................................... 6-15
Figure 6-5 A Configuration Example of BGP Single-Hop BFD................................. 6-16

Figure 6-6 A Configuration Example of LDP BFD.................................................... 6-18
Figure 6-7 A Configuration Example of RSVP Interface BFD .................................. 6-20
Figure 6-8 A Configuration Example of RSVP LSP BFD ......................................... 6-23
Figure 6-9 A Configuration Example of PW BFD ..................................................... 6-26
Figure 6-10 Network Topology for BFD Troubleshooting ......................................... 6-29
Figure 6-11 BFD Fault Handling Flow ..................................................................... 6-30
Figure 7-1 Dual-Homing Symmetrical Access of CE Devices .................................... 7-4
Figure 7-2 Asymmetrical Access of CE Devices........................................................ 7-4
Figure 7-3 VPN/BGP Neighbors................................................................................ 7-5
Figure 7-4 Bypass Mode of FRR............................................................................... 7-8
Figure 7-5 Bypass Mode of FRR............................................................................... 7-9
Figure 7-6 An Application Scenario of Interface FRR .............................................. 7-17
Figure 8-1 A Configuration Example of OSPF Graceful Restart .............................. 8-11
Figure 8-2 A Configuration Example of IS-IS Graceful Restart ................................ 8-12
Figure 8-3 A Configuration Example of BGP Graceful Restart................................. 8-13
Figure 8-4 Network Topology for Troubleshooting IP Graceful Restart Faults ........... 8-14
Figure 8-5 IP Graceful Restart Fault Handling Flow ................................................ 8-15
Figure 10-1 1+1 Protection Model ........................................................................... 10-2
Figure 10-2 1:1 Protection Model ............................................................................ 10-2
Figure 11-1 MSP Group Establishment ................................................................... 11-5
Figure 11-2 Network Topology for MSP Troubleshooting ......................................... 11-6
Figure 11-3 MSP Fault Handling Flow ..................................................................... 11-7
Figure 12-1 MPLS-TP OAM Connection Establishment .......................................... 12-9
Figure 12-2 Network Topology for MPLS-TP OAM Troubleshooting ...................... 12-14
Figure 12-3 MPLS-TP OAM Fault Handling Flow .................................................. 12-15
Figure 14-1 Working Principles of mcLag................................................................ 14-1
Figure 14-2 A Configuration Example of Static mcLag ............................................ 14-5
Figure 14-3 A Configuration Example of Dynamic mcLag ....................................... 14-6
Figure 14-4 Network Topology for mcLag Troubleshooting...................................... 14-8
Figure 14-5 mcLag Fault Handling Flow.................................................................. 14-9
II
Glossary
BFD
- Bidirectional Forwarding Detection
BGP
- Border Gateway Protocol
CFM
- Connectivity Fault Management
EFM
- Ethernet in the First Mile
FRR
- Fast Reroute
IBGP
- Interior Border Gateway Protocol
IGP
- Interior Gateway Protocol
IS-IS
- Intermediate System-to-Intermediate System
LACP
- Link Aggregation Control Protocol
LDP
- Label Distribution Protocol
LSP
- Label Switched Path
MC-LAG
- Multi-Chassis Link Aggregation Group
MPLS
- Multi Protocol Label Switching
MVLAN
- Multicast Virtual Local Area Network
OAM
- Operation, Administration and Maintenance
OSPF
- Open Shortest Path First
PW
- Pseudo Wire
III
QoS
- Quality of Service
VPN
- Virtual Private Network
VRRP
- Virtual Router Redundancy Protocol
IV

ZXCTN 9000 MML Configuration Guide (Raliability) V2.08.32 en

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ZXCTN 9000 MML Configuration Guide (Raliability) V2.08.32 en

Hochgeladen von

Copyright:

Verfügbare Formate

ZXCTN 9002/9004/9008

Packet Transport Network Product

MML Configuration Guide ((Raliability))

Additionally, the contents of this document are protected by

contractual confidentiality obligations.

ZXCTN 9002/9004/9008(V2.08.32) first version issued

Serial Number: SJ-20100901100356-020

About This Manual

What Is in This Manual

Describes safety instructions and signs.

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of the service

reliability manager, as well as the steps for handling common service

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of VRRP, as well

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of EFM, as well

Describes the working principles, configuration commands,

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of BFD, as well

Describes the working principles, configuration commands,

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of IP Graceful

Chapter 9, Load Sharing

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of load sharing,

Chapter 10, Tunnel

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of tunnel

protection groups, as well as the steps for handling common tunnel

Chapter 11, MSP

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of MSP, as well

Chapter 12, MPLS-TP

Describes the working principles, configuration commands,

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of active/standby

switchover, as well as the steps for handling common active/standby

Chapter 14, mcLag

Describes the working principles, configuration commands,

maintenance commands, and configuration examples of mcLag, as well

Network planning engineer

Keys on the keyboard and buttons on screens and company name.

Separates individual parameter in series of parameters.

Checkpoint: Indicates that a particular step needs to be checked before proceeding

3. The system allows the command or keyword to be abbreviated to a character or

Press Ctrl-P or the up arrow

It re-invokes the latest commands in the record buffer. Repress

these keys to invoke old commands forwards.

Press Ctrl-N or down arrow

Roll commands downwards. When the last command line is

1.1 Safety Instructions

1.2 Safety Signs

ZTE Proprietary and Confidential

ZXCTN 9002/9004/9008 MML Configuration Guide ((Raliability))

Strictly follow relevant instructions during operation.

ZTE Proprietary and Confidential

Service Availability Manager

2.1 Overview of the Service Availability Manager

Transport layer/Physical layer: APS

ZTE Proprietary and Confidential

ZXCTN 9002/9004/9008 MML Configuration Guide ((Raliability))

Protection switching technologies: