SJ-20121213142710-016-ZXR10 8900E (V3.01.01) Series Core Switch Configuration Guide (Reliablity) - 548073

ZXR10 8900E
Series Core Switch

Configuration Guide (Reliablity)
Version: 3.01.01
ZTE CORPORATION
No. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright 2013 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by
contractual confidentiality obligations.
All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided as is, and all express, implied, or statutory warranties, representations or conditions
are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No. Revision Date Revision Reason
R1.0 20130624 First edition
Serial Number: SJ-20121213142710-016
Publishing Date: 2013-06-24 (R1.0)
SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

Contents
About This Manual ......................................................................................... I
Chapter 1 VRRP Configuration ................................................................. 1-1
1.1 VRRP Overview ................................................................................................. 1-1
1.2 Configuring VRRP .............................................................................................. 1-8
1.3 VRRP Maintenance .......................................................................................... 1-12
1.4 VRRP Configuration Examples.......................................................................... 1-16
Chapter 2 Active/Standby Main Control Changeover ............................. 2-1

2.1 Active/Standby Main Control Changeover Overview ............................................. 2-1
2.2 Configuring Active/Standby Main Control Changeover .......................................... 2-2
2.3 Active/Standby Main Control Changeover Configuration Example ......................... 2-2
Chapter 3 EFM Configuration.................................................................... 3-1

3.1 EFM Overview ................................................................................................... 3-1
3.2 Configuring EFM ................................................................................................ 3-2
3.3 Maintaining EFM ................................................................................................ 3-5
3.4 EFM Configuration Example ............................................................................... 3-7
Chapter 4 CFM Configuration.................................................................... 4-1

4.1 CFM Overview ................................................................................................... 4-1
4.2 Configuring CFM ................................................................................................ 4-3
4.3 Maintaining CFM ................................................................................................ 4-7
4.4 CFM Configuration Examples.............................................................................. 4-9
Chapter 5 SAMGR Configuration .............................................................. 5-1

5.1 SAMGR Overview .............................................................................................. 5-1
5.2 Configuring SAMGR ........................................................................................... 5-4
5.3 SAMGR Maintenance ......................................................................................... 5-8
5.4 SAMGR Configuration Examples....................................................................... 5-12
Chapter 6 BFD Configuration .................................................................... 6-1

6.1 BFD Overview.................................................................................................... 6-1
6.2 Configuring BFD ................................................................................................ 6-2
6.3 Maintaining BFD ................................................................................................ 6-7
6.4 BFD Configuration Examples .............................................................................. 6-8
Chapter 7 FRR Configuration .................................................................... 7-1

7.1 IP FRR Configuration ......................................................................................... 7-1

7.1.1 IP FRR Overview ..................................................................................... 7-1
7.1.2 Configuring IP FRR .................................................................................. 7-3
7.1.3 Maintaining IP FRR .................................................................................. 7-4
7.1.4 IP FRR Configuration Example.................................................................. 7-6
7.2 L2 VPN FRR Configuration ................................................................................. 7-9
7.2.1 L2 VPN FRR Overview ............................................................................. 7-9
7.2.2 Configuring L2 VPN FRR ........................................................................ 7-10
7.2.3 L2 VPN FRR Maintenance .......................................................................7-11
7.2.4 L2 VPN FRR Configuration Example ........................................................7-11
7.3 L3 VPN FRR Configuration ............................................................................... 7-14
7.3.1 L3 VPN FRR Overview ........................................................................... 7-14
7.3.2 Configuring L3 VPN FRR ........................................................................ 7-15
7.3.3 L3 VPN FRR Maintenance ...................................................................... 7-16
7.3.4 L3 VPN FRR Configuration Example ....................................................... 7-17
7.4 TE FRR Configuration ...................................................................................... 7-24
7.4.1 TE FRR Overview .................................................................................. 7-24
7.4.2 Configuring TE-FRR ............................................................................... 7-31
7.4.3 TE-FRR Maintenance ............................................................................. 7-32
7.4.4 TE-FRR Configuration Example .............................................................. 7-33
Chapter 8 Route Load Sharing Configuration ......................................... 8-1

8.1 Route Load Sharing Overview............................................................................. 8-1
8.2 Configuring Route Load Sharing.......................................................................... 8-2
8.3 Route Load Sharing Maintenance ....................................................................... 8-5
8.4 Route Load Sharing Configuration Examples ....................................................... 8-6
Chapter 9 Multicast Load Sharing Configuration.................................... 9-1

9.1 Multicast Load Sharing Overview ........................................................................ 9-1
9.2 Configuring Multicast Load Sharing ..................................................................... 9-2
9.3 Multicast Load Sharing Maintenance ................................................................... 9-2
9.4 Multicast Load Sharing Configuration Example..................................................... 9-3
Chapter 10 SQA Configuration................................................................ 10-1

10.1 SQA Overview ............................................................................................... 10-1
10.2 Configuring SQA ............................................................................................ 10-1
10.3 SQA Maintenance .......................................................................................... 10-4
10.4 SQA Configuration Examples .......................................................................... 10-6
Chapter 11 UDLD Configuration.............................................................. 11-1

11.1 UDLD Overview...............................................................................................11-1
11.2 Configuring UDLD ...........................................................................................11-2
II

11.3 UDLD Maintenance .........................................................................................11-4
11.4 UDLD Configuration Examples .........................................................................11-5
Figures............................................................................................................. I
Glossary ........................................................................................................ III
III

IV

About This Manual
Purpose
This manual is the ZXR10 8900E (V3.01.01) Series Core Switch Configuration Guide
(Reliability ), which is applicable to the ZXR10 8900E (V3.01.01) series switches.
Intended Audience
This manual is intended for:
l Network planning engineer
l Debugging engineer
l Attendant
What Is in This Manual

This manual contains the following chapters:
Chapter Summary
1, VRRP Configuration Describes the VRRP principle, and the configuration commands,
maintenance commands, configuration examples of the ZXR10 8900E.
2, Active/Standby Main Describes the principle of active/standby main control changeover, and
Control Changeover the configuration commands, maintenance commands, configuration
examples of the ZXR10 8900E.
3, EFM Configuration Describes the EFM principle, and the configuration commands,
4, CFM Configuration Describes the CFM principle, and the configuration commands,
5, SAMGR Configuration Describes the SAMGR principle, and the configuration commands,
6, BFD Configuration Describes the BFD principle, and the configuration commands,
7, FRR Configuration Describes the FRR principle, and the configuration commands,
8, Route Load Sharing Describes the principle of route load sharing, and the configuration
Configuration commands, maintenance commands, configuration examples, and fault
troubleshooting of the ZXR10 8900E.
9, Multicast Load Sharing Describes the principle of multicast load sharing, and the configuration
Configuration commands, maintenance commands, configuration examples of the
ZXR10 8900E.

Chapter Summary
10, SQA Configuration Describes the SQA principle, and the configuration commands,
11, UDLD Configuration Describes the UDLD principle, and the configuration commands,
Conventions
This manual uses the following typographical conventions:
Typeface Meaning
Italics Variables in commands. It may also refer to other related manuals and documents.
Bold Menus, menu options, function names, input fields, option button names, check boxes,
drop-down lists, dialog box names, window names, parameters, and commands.
Constant Text that you type, program codes, filenames, directory names, and function names.
width
[] Optional parameters.
{} Mandatory parameters.
| Separates individual parameter in series of parameters.
Note: provides additional information about a certain topic.
II

Chapter 1
VRRP Configuration
Table of Contents
VRRP Overview .........................................................................................................1-1
Configuring VRRP ......................................................................................................1-8
VRRP Maintenance..................................................................................................1-12
VRRP Configuration Examples.................................................................................1-16
1.1 VRRP Overview

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

gateways. Because hosts in LANs normally do not support dynamic routing protocols, it is
a problem to select a route among multiple egress network gateways.
VRRP is a fault-tolerant protocol. VRRP can implement routing among multiple egress
network gateways by isolating physical devices from logical devices. After that, the
problem is solved.
1-1

ZXR10 8900E Configuration Guide (Reliablity)
In LANs with multicasting or broadcasting ability (such as Ethernet), VRRP provides a

logical network gateway to ensure that transmission links are used fully. This not only
avoids service interruption due to faults on a network gateway device, but also avoids
modification of routing protocol configuration.
VRRP Principle
l Working Principle
VRRP forms a virtual switch with the Switch A and Switch B in a LAN, see Figure 1-2.
Figure 1-2 VRRP Working Principle
The virtual switch has its own IP address 10.100.10.1 (this IP address can be the same
with an interface address on a switch). Physical route A and switch B also have their
own IP addresses (IP address of switch A is 10.100.10.2 and IP address of switch B is
10.100.10.3). Hosts in the LAN only knows the IP address 10.100.10.1 of the virtual
switch. Hosts do not know the IP addresses of switch A and switch B. Switch A and
switch B set the IP address 10.100.10.1 of the virtual switch as their default routes.
Therefore, hosts in the LAN communicates with other networks through this virtual
switch. The virtual switch need to do the following operations:
1. The virtual switch selects a master switch in accordance with the priority. The
switch with the highest priority becomes the master switch and its state is Master.
If the priorities are the same, the master IP addresses on interfaces are compared.
The switch with the greater master IP address on an interface becomes the master
switch. The master switch provides routing service.
2. The other switch operates as a backup switch. It detects the state of the master
switch at any time.
1-2

Chapter 1 VRRP Configuration
When the master switch works properly, it sends a VRRP multicasting

message at a certain interval to inform the backup switch in the group that
the master switch works properly.
If the backup switch in the group does not receive messages from the master
switch for a long time, the backup switch changes its state to Master.
When there are several backup switches in the group, there might be several
master switches at this time. In this situation, each master switch compares
the priorities in the VRRP messages with its local priority. If its local priority is
smaller than the priorities in the VRRP messages, the master switch changes
its state to Backup. Otherwise, the master keeps its state.
In this way, the switch with the highest priority becomes the new master switch.
The VRRP backup function is finished.
The switches that form the virtual switch has three states, Initialize, Master and
Backup. The states descriptions are as follows:
Initialize
A switch enters this state after the system is started. When an interface receives
a startup message, the switch becomes Backup state (when the priority is not
255) or Master state (when the priority is 255). In Initialize state, the switch does
not handle VRRP messages.
Master
When a switch is in Master state, it performs the following operations:
1. It sends VRRP multicasting messages periodically.
2. It sends free Address Resolution Protocol (ARP) messages to make virtual
Medium Access Control (MAC) address that corresponds to the virtual IP
address known by all hosts in the network.
3. It replies to the ARP request for the virtual IP address with the virtual MAC
address instead of the real MAC address on the interface.
4. It forwards IP messages of which the destination MAC address is the virtual
MAC address.
In Master state, when the switch receives a VRRP message in which the priority
is higher than the priority of the switch, the switch enters the Backup state. When
it receives a Shutdown event, the switch enters the Initialize state.
Backup
When a switch is in Backup state, it does the following work:
1. It receives VRRP multicasting messages from the master switch to know the
state of the master switch.
2. It does reply to the ARP requests for the virtual IP address.
3. It drops IP messages of which the destination MAC address is the virtual
MAC address.
1-3

4. It drops IP messages of which the destination IP address is the virtual IP

address.
When a switch in Backup state receives an event indicating that the
MASTER_DOWN timer expires, the switch state becomes Master. When the
switch receives VRRP messages in which the priorities are smaller than its own
priority, it will drop the messages, so it does not reset the timer. After several
times, the timer expires, and the switch state becomes Master. When the switch
receives a Shutdown event, the Switch Becomes Initialize state.
The state conversion is shown in Figure 1-3.
Figure 1-3 State Conversion in VRRP
In accordance with the above analysis, the hosts in the network do not have any extra
operations, and the communications with external network will not be affected due to
the faults on a switch.
l Practical Network Application

1. VRRP monitoring interface state
VRRP provides a function to monitor interface states. That is, VRRP provides the
backup function not only if a fault occurs on an interface in the backup group, but
also if a fault occurs on another interface on switches.
When the monitored interface state is down, the priority of the switch decreases
by a certain value automatically, which makes the priorities of other switches in the
backup group be higher than the priority of this switch. This urges master/slave
switch changeover.
The switch with the highest priority becomes the master switch and the
changeover is finished.
For an application of VRRP monitoring interface, see Figure 1-4.
1-4

Figure 1-4 Application of VRRP Monitoring Interface
In Figure 1-4, VRRP Group 1 monitors the interface marked with a red point on
router A. When the interface works properly, router A acts as the master router.
When the interface is down, the priority of router A is decreased. As a result,
the priority of router A is lower than that of router B. In this way, master/backup
changeover is finished.
2. VRRP load sharing
Load sharing means that several switches bear services at the same time to avoid
occurrence of idle switches. Therefore, it is necessary to create two or more
backup groups to implement load sharing, see Figure 1-5.
Figure 1-5 Application of VRRP Load Sharing
The load sharing function has the following features:

Each backup group contains a Master device and several Backup devices.
The Master devices in the backup groups can be different.
A switch can be added into different backup groups, and the switch has
different priorities in these backup groups.
a. Application scene descriptions of VRRP load sharing
In Figure 1-6, VRRP Group 1 (with virtual IP address 10.0.0.1) and VRRP
Group 2 (with virtual IP address 10.0.0.100) are configured on the same
interfaces on router A and router B.
The real IP address of physical router A is 10.0.0.2, and the real IP
address of physical router B is 10.0.0.3.
1-5

The default gateway of a part of hosts in the LAN is 10.0.0.1, and the
default gateway of the other part of hosts in the LAN is 10.0.0.100.
b. Working mechanism
Router A and router B have the following agreements during VRRP
negotiation through priority configuration of the backup groups on router A
and router B:
Router A operates as the master router in Group 1 and operates as a
backup router in Group 2.
Router B operates as the master router in Group 2 and operates as a
backup router in Group 1.
A part of hosts uses the backup group 1 as the gateway and the traffic is
sent through router A. The other part of hosts uses the backup group 2
as the gateway and the traffic is sent through router B.
In this way, the data flows are shared and backed up.
3. VRRP heartbeat configuration
VRRP protocol messages can be transmitted through heartbeat, so the messages
are not necessarily transmitted by the interface configured with a VRRP group.
If heartbeat is configured in a VRRP group, designate the out-interface sending
messages as the heartbeat interface. If heartbeat is not configured in a VRRP
group, the out-interface is the interface configured VRRP.
4. VRRP track configuration
There are three applications of VRRP link detection.
Application one
As shown in Figure 1-6, the VRRP protocol is used between router A
and router B. These two routers are used for master/backup selection.
EOAM (including Ethernet in the First Mile (EFM) and Connectivity Fault
Management (CFM)) is used to detect the link state between the switch and
the router.
Figure 1-6 EOAM for VRRP Application (1)
For the state transfer of EOAM for VRRP, see Figure 1-7. EOAM monitors
the link state between the router and the switch. When receiving the link
1-6

fault notified by EOAM in the master or backup state, VRRP transfers to the
initialize state directly. When all VRRP interfaces are in up state and VRRP
is in initialize state, VRRP receives link recovery notified by EOAM, and the
backup group is the IP Owner, the state will transfer to the master state,
otherwise, the state will transfer to the backup state.
Figure 1-7 VRRP and EOAM State Transfer
Application two
The VRRP protocol is used between Router A and Router B, and these two
routers are used for master/backup selection, see Figure 1-8. The EOAM
(including EFM and CFM) is used to detect the link state between the switches
and the routers. BFD is used to detect the link state between routers. In this
application, the EOAM can be replaced by the link BFD.
Figure 1-8 EOAM for VRRP Application (2)
For the state transfer of EOAM (or link BFD) + peer BFD for VRRP, see
Figure 1-9. When receiving the link fault notified by EOAM in the master or
backup state, VRRP transfers to the initialize state directly. When all VRRP
interfaces are up, VRRP is in initialize state, VRRP receives link recovery
notified by EOAM, and the group is the IP Owner, the state will transfer to the
master state, otherwise, the state will transfer to the backup state. If VRRP
is in backup state, and VRRP receives the link fault notified by peer BFD,
the VRRP will transfer to the master state.
1-7

Figure 1-9 VRRP and EOAM + Peer BFD State Transfer
Application three
The VRRP protocol is used between Router A and Router B, see Figure
1-10. These two routers are used for master/backup selection. The EOAM
(including EFM and CFM) is used to detect the link states between Router
A and Router C, and between Router B and Router C. The state of EOAM
for VRRP transfers in accordance with the VRRP protocol negotiation. When
receiving the link fault notified by EOAM, VRRP decreases the priority based
on configuration and triggers master/slave router changeover.
Figure 1-10 EOAM for VRRP Application Three
1.2 Configuring VRRP

To configure VRRP on ZXR10 8900E, perform the following steps.
Step Command Function
1 ZXR10(config)#vrrp Enters VRRP configuration

mode.
2 ZXR10(config-vrrp)#interface <interface-name> Enters VRRP interface

configuration mode.
1-8

3 ZXR10(config-vrrp-if)#vrrp <group>{ipv4|ipv6}<ip-add Enables VRRP in VRRP

ress>[secondary] interface configuration mode.
Use the no vrrp group [ipv4|ipv6
ipaddress][secondary] command
to disable VRRP.
4 ZXR10(config-vrrp-if)#vrrp <group> priority <level> Configures VRRP priority in

VRRP interface configuration
mode. The range of <level> is
1-254. Use the no format of this
command to restore the default
priority (100).
5 ZXR10(config-vrrp-if)#vrrp <group> preempt [delay Configures VRRP group

<seconds>] preemption in VRRP interface
configuration mode. Use the
no format of this command to
restore the default preemption
mode. The default preemption
delay is 0.
6 ZXR10(config-vrrp-if)#vrrp <group> timers advertise Configures the interval to

<1-40>[msec <50-40000>] send VRRP advertisements in
mode. Use the no format of
this command to restore the
default interval (1 second). The
parameter msec is optional
and it is to change the unit of
the interval to millisecond from
second.
7 ZXR10(config-vrrp-if)#vrrp <group> timers learn Configures the learning of

the interval to send VRRP
advertisements in VRRP
interface configuration mode.
Use the no vrrp group timers
learn command to restore
the default configuration (not
learning).
1-9

8 ZXR10(config-vrrp-if)#vrrp <group> track interface Configures a VRRP track

<interface-name>[priority-decrement <1-254>| rapid-down] interface in VRRP interface
configuration mode. When
the priority decrement is not
configured, the default value
(10) is used.
If the option is set to
rapid-down, the priority is
switched to 1 immediately. If
the option is Master, a packet
with the priority being 0 will be
sent. In this case, the backup
router will be switched to a
master router immediately.
Use the no format of this
command to restore the default
configuration (not trace any link
state).
9 ZXR10(config-vrrp-if)#vrrp <group> out-interface Configures VRRP heartbeat in

<interface-name> VRRP interface configuration
mode, that is, configuring a
VRRP out-interface.
10 ZXR10(config-vrrp-if)#vrrp <group> text-authenticat Configures a VRRP

ion <string> authentication string in VRRP
The string can contain 1-8
characters. (This configuration
is only valid in VRRP version 2.)
11 ZXR10(config-vrrp-if)#vrrp <group> track { group | Configures an event group or

object}<string>{ link-type | peer-type | priority-decrement an event object and the type
<1-254>} tracked by VRRP in VRRP
Use the no format of this
command to delete the tracked
group or object.
12 ZXR10(config-vrrp-if)#vrrp <group> version {2|3} Configures VRRP version in

mode.
13 ZXR10(config-vrrp-if)#vrrp <group> accept Enables the accept function in

mode.
1-10

14 ZXR10(config-vrrp-if)#vrrp <group> check-ttl Enables tje check-ttl function in

mode.
15 ZXR10(config-vrrp-if)#vrrp <group> admin-group { Configures VRRP

owner | interface <interface-name> vrid <1-255>} administration group function in
mode.
Descriptions of parameters in Step 3:
Parameter Description
<group> The ID number of the virtual switch, in the range of 1-255
ipv4 Specifies the VRRP IPv4 virtual address
ipv6 Specifies the VRRP IPv6 virtual address
< ip-address> The IP address of the virtual switch
secondary A secondary IP address supported by the virtual switch
Descriptions of parameter in Step 5:
<seconds> The delay of a VRRP switch to declare itself as a master switch, in

the unit of second
<interface-name> The track interface name
priority-decrement <1-254> The priority decrement, with default value 10
rapid-down If the option is set to rapid-down, the priority is switched to 1

immediately. If the option is Master, a packet with the priority
being 0 will be sent. In this case, the backup router will be
switched to a master router immediately.
group Tracked event group
object Tracked event object
string The name of the event group or object tracked
1-11

link-type Link-type
peer-type Peer-type
priority-decrement <1-254> The priority decrement
<group> The ID number of the virtual router, in the range of 1-255
version VRRP version
2 VRRP v2 supports IPv4 configuration.
3 VRRP v3 supports IPv4 and IPv6 configuration.
accept Enables accept function of VRRP
check-ttl Enables check-ttl function of VRRP
owner Specifies the current group as the owner of the administration

group that is responsible for receiving and sending packets
<interface-name> Interface name of the administration group owner
vrid <1-255> The virtual switch ID number of the administration group owner, in
the range of 1-255
1.3 VRRP Maintenance

ZXR10 8900E provides the following commands to maintain VRRP.
1-12

Command Function
ZXR10#show vrrp {ipv4|ipv6} brief This views the brief information of

all IPv4 or IPv6 VRRP groups on
a switch.
ZXR10#show vrrp {ipv4|ipv6} brief interface <interface-name> This views the brief information of
all IPv4 or IPv6 VRRP groups on a
specific interface.
ZXR10#show vrrp interface <interface-name>[vrid <1-255>] This views the detailed information
of all VRRP groups or a specified
group on a specified interface.
An example of the show vrrp ipv4 brief command output is shown below.
ZXR10#show vrrp ipv4 brief
Interface vrID Pri Time A P L State Master addr VRouter addr
vlan30 255 254 999 P Master 192.168.1.10 15.15.15.1
supervlan1 100 200 10000 P Master 35.35.35.1 1.1.1.1
supervlan2 120 255 157 A P L Master 35.35.35.1 35.35.35.1
An example of the show vrrp ipv6 brief command output is shown below.
ZXR10#show vrrp ipv6 brief
supervlan5 5 100 1000 P Init 0:0:0:0:0:0:0:0 FE80:0:0:0:0:0:0:1
Output descriptions:
Output Item Description
Time Local configuration time, in unit of millisecond
A The owner of an address
P Preemption mode
L Learning mode
An example of the show vrrp ipv4 brief interface command output is shown below.
ZXR10#show vrrp ipv4 brief interface vlan30

The total of vrrp group on this Interface is 2.
======================================================================
vlan30 100 200 10000 P Master 35.35.35.1 1.1.1.1
vlan30 120 255 157 A P L Master 35.35.35.1 35.35.35.1
An example of the show vrrp ipv6 brief interface command output is shown below.
1-13

ZXR10#show vrrp ipv6 brief interface supervlan5

The total of vrrp group on this Interface is 1.
======================================================================
vrID The ID of a VRRP group, in the range of 1-255
Pri The current priority
Master addr The IP of the Master router
VRouter addr The virtual IP configured for a VRRP group
An example of the show vrrp interface command output is shown below.

ZXR10#show vrrp interface supervlan4
supervlan4 - vrID 4
Vrrp configure info:
IP version 6, VRRP version 3
Virtual IP address is FE80:0:0:0:0:1:2:3
Secondary Virtual IP address is 1:0:0:0:0:0:2:0
Virtual MAC address is 0000.5e00.0204
Advertise time is 1.000 sec
Configured priority is 100
Preemption enable, delay 0 secs
Authentication data is None
Check ttl enable
Vrrp accept mode enable
Out-interface(heartbeat line) is None
Tracked interface items: 0
Interface State Decrement-Priority
Tracked detect items: 1
Track name: test1 Track type: group
Decrement priority: 35
Track state: up
Admin-group is Owner, vrrp member items: 0
Vrrp run info:
State is Init
0 state changes, last state change 00:00:00
Current priority is 100
1-14

Master router is local

Master router address is 0:0:0:0:0:0:0:0
Master router priority is 0
Master Advertisement interval is 0.000 sec
Master Down interval is 3.609 sec, no learn
supervlan4 - vrID 8
Virtual IP address is 8.9.7.1
Check ttl enable
Out-interface(heartbeat line) is supervlan5
supervlan2 DOWN 25
Track name: zte1 Track type: object Detect type: vrrp
Policy type: link
Track state: local-down
Admin-group is None
Vrrp run info:
State is Init
Master router is unknown
Master router address is 0.0.0.0
Decrement-Priority The priority decrement after the track interface is shut down
Tracked interface The interface that is traced
Tracked type The tracked group or object
local It means that the local switch is a Master switch.
An example of the show vrrp interface vrid command output is shown below.
1-15

ZXR10#show vrrp interface supervlan4 vrid 8

supervlan4 - vrID 8
Check ttl enable
Out-interface(heartbeat line) is supervlan5
supervlan2 DOWN 25
Track name: zte1 Track type: object Detect type: vrrp
Policy type: link
Track state: local-down
Admin-group is None
Vrrp run info:
State is Init
1.4 VRRP Configuration Examples

Basic VRRP Configuration Example (IPv4)
l Configuration Description
As shown in Figure 1-11, VRRP is run between R1 and R2. The VRRP virtual address
is the interface address 10.0.0.1 on R1. R1 works as the master switch.
1-16

Figure 1-11 Basic VRRP Configuration (IPv4)
l Configuration Thought
1. Enter the interfaces on which VRRP should be enabled and configure IP ad-
dresses.
2. Enter VRRP configuration mode from global configuration mode and then enter
the interfaces to configure VRRP.
3. Configure the same VRRP group ID and virtual addresses for R1 and R2. To
make R1 as the master switch, configure related commands on R1 first. When
the priorities (the default priority is 100) are the same, the switch on which VRRP
is enabled first and messages are advertised first will become the master switch
in the group.
l Configuration Commands
Configuration of R1:
R1(config)#interface vlan30
R1(config-if)#ip address 10.0.0.1 255.255.0.0
R1(config)#vrrp
R1(config-vrrp)#interface vlan30
R1(config-vrrp-if)#vrrp 1 ipv4 10.0.0.1
R2(config)#vrrp
l Configuration Verification
View the VRRP information and configuration result on R1, as shown below.
R1#show vrrp ipv4 brief

vlan30 1 255 1000 A P Master 10.0.0.1 10.0.0.1
/*A: whether the switch is the address owner.
1-17

P: whether preemption is configured.

L: whether to learn the interval to advertise VRRP messages on the
master.*/
ZXR10_R1# show vrrp interface vlan30 vrid 1

vlan30 - vrID 1
Vrrp configure info: /*VRRP configuration information*/
Check ttl enable
Admin-group is None
Vrrp run info:
/*Running information of VRRP on current interface*/
State is Master
/*VRRP running state*/
/*Number of state changes and time*/
/*Current priority, the largest priority of the Owner is 255*/
Symmetrical VRRP Configuration Example (IPv4)

As shown in Figure 1-12, two VRRP groups are configured. PC1 and PC2 use the
virtual switch in Group 1 as the default network gateway, and the address is 10.0.0.1.
PC3 and PC4 use the virtual switch in Group 2 as the default network gateway, and
the address is 10.0.0.2. R1 and R2 are backups for each other. When both switches
are invalid, the communications between the hosts and external network will be
interrupted.
1-18

Figure 1-12 Symmetrical VRRP Configuration (IPv4)
dresses.
3. Configure VRRP Group 1 and corresponding virtual address on R1. Configure
VRRP Group 2 and corresponding virtual address on R2. Therefore, R1 becomes
the master switch in Group 1, and R2 becomes the master switch in Group 2.
Add R1 to Group 2, and add R2 to Group 1, so R1 and R2 become the backup
switches.
Configuration of R1,
R1(config)#vrrp
R1(config-vrrp-if)end
R2(config)#vrrp
R2(config-vrrp-if)#end
1-19

vlan30 1 255 1000 A P Master 10.0.0.1 10.0.0.1

vlan30 2 100 1000 P Backup 10.0.0.2 10.0.0.2
master.*/
R1#show vrrp interface vlan30 vrid 1

vlan30 - vrID 1
Check ttl enable
Admin-group is None
Vrrp run info:
State is Master
/*current priority, the largest priority of the Owner is 255*/
VRRP Heartbeat Configuration Example (IPv4)

1-20

Figure 1-13 VRRP Heartbeat Configuration (IPv4)
dresses.
make R1 as the master router, configure related commands on R1 first. When
in the group.
4. In VRRP interface configuration mode, configure the same out-interface of the
heartbeat link in the VRRP group on R1 and R2.
R1(config)#vrrp
R1(config-vrrp-if)#vrrp 1 out-interface vlan40
R2(config)#vrrp
1-21

vlan30 1 255 1000 A P Master 10.0.0.1 10.0.0.1
/*A: whether the router is the address owner.
master.*/
R1#show vrrp interface vlan30 vrid 1

vlan30 - vrID 1
Check ttl enable
Out-interface(heartbeat line) is vlan40
Admin-group is None
Vrrp run info:
State is Master
VRRP Track Configuration Example (IPv4)

As shown in Figure 1-14, VRRP is run between switch A and switch B. The VRRP
virtual IP address is 10.0.0.3.
1-22

Figure 1-14 VRRP Track Configuration (IPv4)
1. Enter the interfaces on which VRRP will be configured and configure IP addresses
on the interfaces.
2. Enter VRRP configuration mode from global configuration mode, and then enter
the interface on which VRRP will be configured.
3. Configure the same VRRP group ID and virtual IP address for switch A and switch
B. To set switch A as the active switch, execute the above steps on switch A first.
When priorities (by default, the priority is 100) are the same, the switch on which
VRRP is configured first and advertise packets first will work as the active switch
in the VRRP group.
4. Enter VRRP configuration mode on switch A and switch B to configure tracks with
the same object name. And then enter VRRP interface configuration mode to
enable track of VRRP.
The configuration of switch A:
RA(config)#interface vlan30
RA(config-if)#ip address 10.0.0.1 255.255.0.0
RA(config)#vrrp
RA(config-vrrp)#interface vlan30
RA(config-vrrp-if)#vrrp 1 ipv4 10.0.0.3
RA(config-vrrp-if)#vrrp 1 track object zte peer-type
The object named zte of the track should be configured in the SAMGR module in
advance. For the detailed configuration, please refer to the SAMGR Configuration
chapter.
The configuration of switch B:
RB(config)#interface vlan30
RB(config-if)#ip address 10.0.0.2 255.255.0.0
RB(config)#vrrp
RB(config-vrrp)#interface vlan30
RB(config-vrrp-if)#vrrp 1 ipv4 10.0.0.3
RB(config-vrrp-if)#vrrp 1 track object zte peer-type
1-23

The object named zte of the track should be configured in the SAMGR module. For
the detailed configuration, please refer to the SAMGR Configuration chapter.
View the VRRP track information on switch A, as shown below.
RA#show vrrp ipv4 brief
Interface vrID Pri Time A P L State Master addr Vswitch addr
vlan30 1 100 1000 A P Master 10.0.0.1 10.0.0.3
/*A: whether the router is the address owner.
master.*/
RA#show bfd neighbors ip-brief

OurAddr NeighAddr LD RD Hold State Interface
10.0.0.1 10.0.0.2 1 0 150 up vlan30
/*OurAddr: local IP, NeighAddr: remote IP, LD: BFD local identifier
RD: BFD remote identifier
Hold: session holding period, in the unit of ms
State: BFD session state, Interface: BFD session interface*/
RA#show vrrp interface vlan30

vlan30 - vrID 1
Check ttl enable
Track name: zte Track type: object Detect type: peer-bfd
Policy type: peer
Track state: unknow
Admin-group is None
Vrrp run info:
State is Master
1-24

Master switch is local

Master switch address is 10.0.0.3
Master switch priority is 100
Basic VRRP Configuration Example (IPv6)

As shown in Figure 1-15, R1 and R2 run VRRP (V3-IPv6). The VRRP virtual address
is the interface address FE80::1:1 on R1. R1 works as the master switch.
Figure 1-15 Basic VRRP Configuration (IPv6)
1. Enter the interfaces on which VRRP should be enabled. Enable IPv6 and
configure IPv6 addresses.
make R1 as the master router, configure related commands on R1 first. When
the priorities (the default priority is 100) are the same, the router on which VRRP
in the group.
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address link-local fe80::1:1
R1(config)#vrrp
R1(config-vrrp-if)#vrrp 1 ipv6 fe80::1:1
1-25

R2(config)#vrrp
R1(config-if)#show vrrp ipv6 brief
vlan30 1 255 1000 A P Master FE80:0:0:0:0:0: FE80:0:0:0:0:0:1
1:1 :1
master.*/
R1(config-if)#show vrrp interface vlan30 vrid 1

vlan30 - vrID 1
/*IPv4 physical address is 0000.5e00.01XX*/
Check ttl enable
Admin-group is None
Vrrp run info:
State is Master
1-26

Master router address is FE80:0:0:0:0:0:1:1

Symmetrical VRRP Configuration Example (IPv6)

As shown in Figure 1-16, two VRRP groups are configured. PC1 and PC2 use
the virtual router in Group 1 as the default network gateway, and the address is
FE80::1:1. PC3 and PC4 use the virtual switch in Group 2 as the default network
gateway, and the address is FE80::1:2. R1 and R2 are backups for each other.
When both switches are invalid, the communications between the hosts and external
network will be interrupted.
Figure 1-16 Symmetrical VRRP Configuration (IPv6)
3. Configure VRRP Group 1 and corresponding virtual address on R1. Configure
VRRP Group 2 and corresponding virtual address on R2. Therefore, R1 becomes
the master switch in Group 1, and R2 becomes the master switch in Group 2 (note
that use the link-local address as the virtual address that uses FE80:: as prefix).
Add R1 to Group 2, and add R2 to Group 1, so R1 and R2 become the backup
switches.
R1(config)#vrrp
1-27

R2(config)#vrrp
1:1 :1
vlan30 2 100 1000 P Backup FE80:0:0:0:0:0: FE80:0:0:0:0:0:1
1:2 :2
master.*/
R1#show vrrp interface vlan30
vlan30 - vrID 1
Check ttl enable
Admin-group is None
Vrrp run info:
State is Master /*VRRP running state*/
1-28


/*current priority, the largest priority of the Owner is 255*/
VRRP Heartbeat Configuration Example (IPv6)

is the interface address FE80::1:1 on R1. R1 works as the master switch.
Figure 1-17 VRRP Heartbeat Configuration (IPv6)
make R1 as the master switch, configure related commands on R1 first. When
is enabled first and messages are advertised first will become the master router
in the group.
4. In VRRP interface configuration mode, configure the same out-interface of the
heartbeat link in the VRRP group on R1 and R2, and enable IPv6 on the heartbeat
link interface.
1-29

R1(config)#vrrp
R2(config)#vrrp
R1#show vrrp ipv6 b
1:1 :1
master.*/
R1#show vrrp interface vlan30

vlan30 - vrID 1
Check ttl enable
Out-interface(heartbeat line) is vlan40
1-30


Admin-group is None
Vrrp run info:
State is Master /*VRRP running state*/
VRRP BFD Configuration Example (IPv6)

As shown in Figure 1-18, VRRP is run between switch A and switch B. The VRRP
virtual IP address is FE80::1:1.
Figure 1-18 VRRP Track Configuration (IPv6)
1. Enter the interfaces on which VRRP will be configured. Enable IPv6 and configure
IPv6 addresses on the interfaces.
2. Enter VRRP configuration mode from global configuration mode, and then enter
the interfaces on which VRRP will be configured.
3. Configure the same VRRP group ID and virtual IP address for switch A and switch
B. To set switch A as the active router, execute the above steps on switch A first.
When priorities (by default, the priority is 100) are the same, the router on which
VRRP is configured first and advertise packets first will work as the active router
in the VRRP group.
1-31

4. Enter VRRP configuration mode on switch A and switch B to configure tracks with
the same object name. And then enter VRRP interface configuration mode to
enable track of VRRP.
The configuration of switch A:
RA(config)#interface vlan30
RA(config-if)#ipv6 enable
RA(config-if)#ipv6 address link-local fe80::1:1
RA(config)#vrrp
RA(config-vrrp)#interface vlan30
RA(config-vrrp-if)#vrrp 1 ipv6 fe80::1:1
RA(config-vrrp-if)#vrrp 1 track object zte peer-type
Note:
The object named zte of the track should be configured in the SAMGR module in
advance. For the detailed configuration, please refer to the SAMGR Configuration.
The configuration of switch B:

RB(config)#interface vlan30
RB(config-if)#ipv6 enable
RB(config-if)#ipv6 address link-local fe80::1:2
RB(config)#vrrp
RB(config-vrrp)#interface vlan30
RB(config-vrrp-if)#vrrp 1 ipv6 fe80::1:1
RB(config-vrrp-if)#vrrp 1 track object zte peer-type
Note:
The object named zte of the track should be configured in the SAMGR module. For
the detailed configuration, please refer to the SAMGR Configuration.
View the VRRP track information on switch A, as shown below.
RA#show vrrp ipv6 brief

1:1 :1
1-32


master.*/
ZXR10_R1#show bfd neighbors ip-brief
OurAddr NeighAddr LD RD Hold State Interface
FE80:0:0:0:0:0: 1234:0:0:0:0:0: 1 0 0 UP
1:1 1:2
/*OurAddr: local IP, NeighAddr: remote IP, LD: BFD local identifier
RD: BFD remote identifier
Hold: session holding period, in the unit of ms
State: BFD session state, Interface: BFD session interface*/
RA#show vrrp interface vlan30

vlan30 - vrID 1
Check ttl enable
Track name: zte Track type: object Detect type: peer-bfd
Policy type: peer
Track state: unknow
Admin-group is None
Vrrp run info:
State is Master
1-33

This page intentionally left blank.
1-34

Chapter 2
Active/Standby Main Control
Changeover
Table of Contents
Active/Standby Main Control Changeover Overview...................................................2-1
Configuring Active/Standby Main Control Changeover ...............................................2-2
Active/Standby Main Control Changeover Configuration Example ..............................2-2
2.1 Active/Standby Main Control Changeover Overview

Master/slave handover means the handover between the master main control board and
the slave main control board. When the master main control board operates improperly
(powered off or reset manually), if the slave main control board is online, the system will
implement handover automatically. This handover is transparent to applications at upper
layer.
Master/slave main control board handover shields off the influence due to the faults on
the main switching board. Applications at upper layer are not affected, which ensures the
timely handling of system data information.
When the active main control board is powered off, or a key processes are suspended, or
the board is plugged out by some person, active/standby changeover will be performed
automatically.
The master/slave handover is implemented by the process modules running on the main
control board. The flow of master/slave handover is as follows:
1. Control the handover order of application process, and then send slave-to-master and
master-to-slave messages to application processes, that is, the master/slave handover
of application programs.
2. Set the master/slave state of boards, and interact with communication modules for
handover of communication links with periphery boards, that is, the communication
link handover.
During this period, the intermediate state handover of application processes and data
synchronization (including the time when data is synchronized) are completed by
application processes themselves.
For the boards with master/slave configuration, if a fault occurs on the master mother
board, the slave board needs to know the fault quickly and implement the handover.
Therefore, it is necessary to use a mate board scan thread to scan the state of the mate
board in real time. When the master/slave state or in-place state changes, the scan
2-1

thread will inform the corresponding main control process to trigger the master/slave
handover flow quickly.
When the thread scans that the master board operates improperly and the slave board
operates properly, it will trigger the handover. The procedure of handover is implemented
by the corresponding process module of the main control.
2.2 Configuring Active/Standby Main Control

Changeover
Active/standby changeover includes command active/standby changeover, plugging out
and plugging in the active main control board, pressing EXCH button to change over,
enabling the active main control board through the reset button, changing over to the
standby main control board when a fault occurs on the active main control board.
To configure active/standby main control changeover on ZXR10 8900E, use the following
command.
Command Function
ZXR10#redundancy This implements active/standby

main control changeover.
ZXR10#redundancy check Checks active/standby

changeover.
ZXR10#redundancy force-switchover Forces active/standby

changeover.
2.3 Active/Standby Main Control Changeover

Configuration Example
Configuration Description
As shown in Figure 2-1, the three devices work properly at first. After a period, R2
implements active/standby changeover.
Figure 2-1 Active/Standby Main Control Changeover
2-2

Chapter 2 Active/Standby Main Control Changeover
Configuration Commands
1. When the device work properly, the ACT indicator for the active main control board is
on, and the ACT indicator for the standby main control board is off. The RUN indicator
for the active main control board flashes at the frequency of 1 Hz. The ALM indicators
for the active and standby main control boards are off.
2. Use one of the following operations to implement active/standby changeover:
l Configure the active/standby main control changeover command.
l Press the reset button on the active main control board.
l Plug out the active main control board and then plug it in.
l Press the EXCH button on the active main control board.
3. After the active/standby changeover, the RUN indicator for the new active main control
board is on. Besides the alarm indicating the active/standby changeover, there is no
other alarm.
The command used to configure active/standby main control changeover is shown below.
R2#redundancy
?
check Show checking result of redundancy condition
force-switchover Switchover between master and slave
<cr>
C12_6.99#redundancy
Are you sure to switch system?[yes/no]:yes
</cr>
Configuration Verification
View the configuration result, as shown below.
R2#show processor
=====================================================================
=====================================================================
M : Master cpu
S : Slave cpu
Character: Cpu current character in system
MSC : Master-SC in Cluster System
SSC : Slave-SC in Cluster System
N/A : None-SC in Cluster System
CPU(5s) : Cpu utility measured in 5 seconds
CPU(1m) : Cpu utility measured in 1 minute
CPU(5m) : Cpu utility measured in 5 minutes
Peak : Cpu peak utility measured in 1 minute
PhyMem : Physical memory (megabyte)
FreeMem : Free memory (megabyte)
Mem : Memory usage ratio
=====================================================================
=====================================================================
2-3

Character CPU(5s) CPU(1m) CPU(5m) Peak PhyMem FreeMem Mem

====================================================================
PFU-0/0/0 N/A 15% 15% 16% 19% 2048 503 75.439%
---------------------------------------------------------------------
PFU-0/3/0 N/A 12% 12% 13% 14% 2048 507 75.244%
---------------------------------------------------------------------
PFU-0/5/0 N/A 12% 12% 13% 14% 2048 512 75.000%
---------------------------------------------------------------------
PFU-0/7/0 N/A 8% 13% 18% 99% 2048 1318 35.645%
---------------------------------------------------------------------
SFU-0/9/0 N/A 21% 20% 20% 23% 256 74 71.094%
---------------------------------------------------------------------
MPU-0/11/0(M) N/A 19% 18% 20% 21% 4096 1564 61.816%
---------------------------------------------------------------------
ESU-0/11/0 N/A 30% 31% 32% 40% 256 65 74.609%
---------------------------------------------------------------------
ADU-0/13/0 N/A 10% 11% 10% 57% 256 114 55.469%
--------------------------------------------------------------------
2-4

Chapter 3
EFM Configuration
Table of Contents
EFM Overview............................................................................................................3-1
Configuring EFM ........................................................................................................3-2
Maintaining EFM ........................................................................................................3-5
EFM Configuration Example.......................................................................................3-7
3.1 EFM Overview

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

l Supporting remote loopback statistics detection on the links
l Supporting detection of link error frames and symbols
l Supporting emergency event advertisement
l Supporting linkage function handling selectively
The EFM features are as follows:
1. The EFM detects whether the EFM function on the peer device is enabled through its
protocol packets. It interacts with packets to know whether the negotiation procedure
is completed in accordance with the related configurations on two devices.
2. After the negotiation, the EFM collects statistics of link operation information (such as
error frames or symbols) in accordance with the link monitoring in a cycle.
3. When the number of error frames or symbols exceeds the threshold, the EFM triggers
related event notification to inform the local device and the remote device. In this way,
the network administrators know the operation information of the link.
3-1

The EFM can also enable remote loopback function to detect the packet loss caused by
the difference between the local receiving rate and the remote receiving rate or the link
fault.
EFM packets are low-speed protocol packets. The packets cannot be forwarded by
devices. Therefore, th EFM can only be applied on the direct connected device, see
Figure 3-1.
Figure 3-1 EFM Principle
The packets cannot be forwarded across devices. The application environment is simple.
The EFM has accuracy requirements for detection. Two devices send keepalive packets
periodically to each other to keep successful protocol negotiation. Other functions of EFM
can be enabled after the successful negotiation.
When detecting an event, the EFM notifies the peer device through specific packets.
3.2 Configuring EFM

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

globally.
3 ZXR10(config-efm)#set ethernet-oam oui <word> Sets the OUI field of an EFM

vendor. Default: ZTE.
4 ZXR10(config-efm)#set ethernet-oam remote-timeout Configures the timeouts for the

<value> EFM overall loopback control.
Default: 3 s.
5 ZXR10(config-efm)#interface <interface-name> Enters EFM interface

configuration mode.
6 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Enables EFM on a specific

function <state> interface.
7 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Enables the link monitoring

link-monitor function <state> function on a specific interface.
3-2

Chapter 3 EFM Configuration
8 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Configures the error frame

link-monitor frame threshold <th-value> window statistics window value and
<win-value> threshold for the link monitoring.
9 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Configures the error symbol

link-monitor symbol-period threshold <th-value> window statistics window value and
10 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Configures the error frame cycle

link-monitor frame-period threshold <th-value> window statistics window value and
11 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Configures the error frame

link-monitor frame-second threshold <th-value> window second-cycle statistics window
<win-value> value and threshold for the link
monitoring.
12 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Configures the link timeout

link-timeout {<value>|fast <fast-value> period <fast-period>} time.
13 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Sets the EFM configuration

mode <mode> mode.
14 ZXR10(config-efm-if-gei-0/0/1/1)#set ethernet-oam Enables or disables the EFM

rmt-loopback <operation> link loopback function manually.
For a description of the parameter in Step 2, refer to the following table:
<state> State value, enable and disable.
<word> OUI identifier value, length: 1-3 characters, default: ZTE.
<value> Timeout time for the loopback control, range: 1-10, default: 3 s.
<interface-name> Name of a specific interface.
3-3

<state> State value, enable or disable.
<state> Link monitoring state, enable or disable.
For a description of the parameters in Step 8, refer to the following table:
<th-value> Threshold of error frames, range: 1-65535, unit: frame, default: 1.
<win-value> Window value of error frames, range: 1-60, default: 1 s.
<th-value> Threshold of error symbols, unit: symbol, range: 1-65535, default:

1.
<win-value> Window value of error symbols, range: 1-65535, unit: million

symbols, default: 1.
<th-value> Threshold of error frame cycles, range: 1-65535, unit: frame,

default: 1.
<win-value> Window value of error frame cycles, range: 1-65535, unit: million
frames, default: 1.
<th-value> Threshold of error frame second-cycles, range: 1-900, default: 1 s.
<win-value> Window value of error frame second-cycles, range: 1-900, default:

1 s.
<value> Timeout time of EFM links, range: 3-20, default: 5 s.
3-4

<fast-value> Time-out time of a link when the EFM supports the EFM supports
the quick detection, range: 3-200, unit: 100 ms, default: 50.
<fast-period> Interval of sending packets when the EFM supports the quick
detection, range: 1-10, unit: 100ms, default: 10.
<mode> EFM configuration mode, active or passive, default: active.
For a description of the parameter in Step 14:
<operation> Loopback function action identifier, start or stop, indicating

enable or disable
3.3 Maintaining EFM

To maintain EFM on the ZXR10 8900E, run the following command:
Command Function
ZXR10#show ethernet-oam [<interface>{discovery|link-monitor| Displays the global EFM

statistics}] configuration, or the interface
EFM configuration and state.
For a description of the parameters in the show command, refer to the following table:
<interface> Interface name.
discovery Parameter after the interface name. It displays the state

information related to the EFM negotiation.
link-monitor Parameter after the interface name. It displays the information

related to the EFM link monitoring.
statistics Parameter after the interface name. It displays the information

relating to the EFM packet statistics, including the sending and
receiving packet statistics of loopback.
The following is sample output from the show command:
3-5

ZXR10#show ethernet-oam gei-0/0/1/1 discovery

PortId 2: Ethernet Oam enable
Local DTE
----------
Config:
Mode :active
Period Time :10*(100ms)
Link time out :50*(100ms)
Status:
Parser :forward
Multiplexer :forward
Stable :no
Discovery :undone
Loopback :off
PDU max size :1518
PDU Revision :0
Unidirection :nonsupport
Remote DTE
-----------
Remote DTE does not exist.
For a description of the parameters in the execution result, refer to the following table:
Mode EFM working mode.
Period Time Interval of sending link detection packets.
Link time out Link timeout time.
Parse Parser state.
Multiplexer Multiplexer state.
Stable Local and remote stable bit.
Discovery Identifier of discovery complete.
Loopback Identifier of loopback enabling.
PDU max size Maximum number of OAMPDU bytes supported by the DTE.
PDU Revision Revision in a packet.
Unidirection Whether to support the unidirectional function.
3-6

3.4 EFM Configuration Example

EFM Connection Establishment
l Scenario Description
R1 and R2 are directly connected. To establish a connection, the EFM function is
configured for the interfaces connecting R1 and R2, see Figure 3-2.
Figure 3-2 EFM Connection Establishment Configuration Example
l Configuration Flow
1. Configure the EFM function for the interface directly connecting to R2 on R1. To
be specific, enable the EFM switch and the link-monitor switch for the specified
interface, and enable the EFM function globally.
2. Configure the EFM function for the interface directly connecting to R1 on R2. To
be specific, enable the EFM switch and the link-monitor switch for the specified
interface, and enable the EFM function globally.
3. Run the show ethernet-oam discovery command on R1 and R2 to check the EFM
connection establishment between R1 and R2.
4. Run the show ethernet-oam link-monitor command on R1 and R2 to check the
number of link errors between R1 and R2.
Run the following commands on R1:
R1#configure terminal
R1(config)#efm
R1(config-efm)#interface gei-0/0/1/1
R1(config-efm-if-gei-0/0/1/1)#set ethernet-oam function enable
R1(config-efm-if-gei-0/0/1/1)#set ethernet-oam link-monitor function enable
R1(config-efm-if-gei-0/0/1/1)#exit
R1(config-efm)#set ethernet-oam oui R1
R1(config-efm)#set ethernet-oam function enable
R1(config-efm)#exit

R2(config)#efm
3-7


R2(config-efm)#exit
1. Run the show ethernet-oam discovery command on R1 to check the negotiation
result of the EFM connection. The execution result is displayed as follows:
R1(config-efm)#show ethernet-oam gei-0/0/1/1 discovery
Local DTE
----------
Config:
Mode :active
Status: /*local state*/

Parser :forward /*forwarding state of receiver*/
Multiplexer :forward /*forwarding state of sender*/
Stable :yes /*Local link state is "stable".*/
Discovery :done /*Link discovery is done.*/
Loopback :off /*Loopback is off.*/
PDU max size :1518 /*Maximum number of OAMPDU bytes supported by the DTE.*/
PDU Revision :1 /*Local configuration is modified once.*/
Unidirection :nonsupport /*This interface does not support the unidirectional functi
Remote DTE
-----------
Config:
Mode :active
Link Monitor :support
Remote Loopback :support
Mib Retrieval :nonsupport
PDU max size :1518
Remote OUI(hex) :5a-54-45 /*Remote OUI.*/
Status: /*remote state*/

Parser :forward /*in forwarding mode*/
Multiplexer :forward /*in forwarding mode*/
Stable :yes /*Remote link state is "stable".*/
Mac Address :1622.30c4.e999 /*MAC of remote device*/
PDU Revision :2 /*Remote configuration is modified for 2 time.*/
2. Run the show ethernet-oam link-monitor command on R1 to check the number of
link errors. The execution result is displayed as follows:
R1(config)#show ethernet-oam gei-0/0/1/1 link-monitor
Link Monitoring of Port: 32
3-8

Link Monitoring enable

Error Symbol Period Event:
Symbol Window : 1(million symbols)
Error Symbol Threshold : 1
Error Symbols : 0
Local Total Error Symbols : 0
Remote Total Error Symbols : 0
Local Total Error Events : 0
Remote Total Error Events : 0
Error Frame Event:
Frame Window : 1(s)
Error Frame Threshold : 1
Error Frames : 0
Local Total Error Frames : 0
Remote Total Error Frames : 0
Error Frame Period Event:
Period Window : 1(ten thousand frames)
Error Frames : 0
Error Frame Seconds Event:
Error Seconds Window : 1(s)
Error Seconds Threshold : 1(s)
Error Frame Seconds : 0(s)
Local Total Error Frame Seconds : 0(s)
Remote Total Error Frame Seconds : 0(s)
Local Total Error Frame Seconds Events : 0
Remote Total Error Frame Seconds Events : 0
3. Run the show ethernet-oam discovery command on R2 to check the negotiation
result of the EFM connection. The execution result is displayed as follows:
R2(config)#show ethernet-oam gei-0/0/1/1 discovery
Local DTE
----------
Config:
Mode :active
Status:
3-9

Parser :forward
Stable :yes
Discovery :done
Loopback :off
PDU max size :1518
PDU Revision :2
Remote DTE
-----------
Config:
Mode :active
Link Monitor :support
Remote Loopback :support
Mib Retrieval :nonsupport
PDU max size :1518
Remote OUI(hex) :5a-54-45
Status:
Parser :forward
Stable :yes
Mac Address :1210.1210.1211
PDU Revision :1
4. Run the show ethernet-oam link-monitor command on R2 to check the number of
link errors. The execution result is displayed as follows:
Error Symbols : 0
Error Frame Event:
Frame Window : 1(s)
Error Frames : 0
3-10


Error Frames : 0
EFM Remote Loopback

R1 and R2 are connected directly. The EFM function is configured for the direct
connected interfaces of R1 and R2. R1 is configured with the remote loopback, and
R2 loops back packets, see Figure 3-3.
Figure 3-3 EFM Remote Loopback Configuration Example
1. Configure EFM for the interface of R1 connecting to R2 directly and enable EFM
globally.
2. Configure EFM for the interface of R2 connecting to R1 directly and enable EFM
globally.
3. After the EFM connection is established on R1 and R2, enable remote loopback
on R1.
4. Run the show ethernet-oam discovery command on R1 and R2 to check the EFM
connection establishment.
3-11


R1(config-efm)#exit

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

R1(config-efm-if-gei-0/0/1/1)#set ethernet-oam rmt-loopback start
R1(config-efm)#exit
On the link where the EFM connection is established, R1 sends packets (except
OAMPDU) to R2. When R2 receives the packets, it loops them back to R1 directly.
EFM Link Monitor

After the EFM connection is configured in accordance with the description in the "EFM
Connection Establishment" section, do as follows if it is required to configure the link
monitor for an interface.
1. Complete the configuration in accordance with the description in the "EFM
Connection Establishment" section.
2. Configure the maximum value and window value for the link monitor event on the
interface to be monitored.
The monitor events include the error symbol period event, error frame event, error
frame period event, and error frame second event. This section uses the error
frame event as an example.
3-12

R1(config)#efm
R1(config-efm-if-gei-0/0/1/1)#set ethernet-oam link-monitor frame threshold 2 window 30
R1(config-efm)#
Run the show ethernet-oam link-monitor command on R1 to check the number of error
frames on the link. The execution result is displayed as follows:
Error Symbols : 1
Error Frame Event:
Frame Window : 30(s)
Error Frames : 1
Error Frames : 1
3-13

3-14

Chapter 4
CFM Configuration
Table of Contents
CFM Overview ...........................................................................................................4-1
Configuring CFM ........................................................................................................4-3
Maintaining CFM ........................................................................................................4-7
CFM Configuration Examples.....................................................................................4-9
4.1 CFM Overview

Introduction to CFM
Ethernet technology becomes the leading technology gradually due to its simpleness and
low cost since it was born. In recent years, with the applications of gigabit and 10gigabit
Ethernet technology, Ethernet has been extended towards Metropolitan Area Network
(MAN) and Wide Area Network (WAN).
Ethernet was mainly applied in LAN in early time. Compared with MAN and WAN, LAN
has lower requirements for reliability and stability. As a result, Ethernet was lack of OAM
mechanism, which became a serious obstruction to use Ethernet as operator networks.
Therefore, implementing OAM in Ethernet became an inevitable development trend. In
this case, a series of standard technologies were generated, such as IEEE 802.3ah
(Operations, Administration, and Maintenance - OAM), IEEE 802.1ag (Connectivity
Fault Management) and International Telecommunications Union (ITU) - T Y.1731 (OAM
functions and mechanisms for Ethernet based networks).
IEEE 802.1ag (CFM) provides connectivity detection on point-to-point links in logic. It
detects the connectivity between two logical points, supporting functions such as loopback,
link trace and ITU-T Y1731. CFM can check, isolate, and report connectivity faults in
Virtual Local Area Networks (VLANs) effectively. CFM is the main protocol used for link
monitoring, detection, and troubleshooting at the data link layer. It can implement link
detection of Ethernet data link layer on most full-duplex point-to-point links and analogical
point-to-point links, without depending on specific system interfaces.
The CFM mainly has three functions:
l Fault detection: An MEP sends and receives Continuity Check Messages (CCMs)
periodically to detect the connectivity of the network. It can discover connectivity
failures and non-consensual connectivity (situations of wrong connections).
l Fault confirmation and isolation: This function belongs to the management behavior.
Network administrators confirm the faults through Loopback Messages (LBMs) or
Loopback Replies (LBRs), and then isolate the faults.
4-1

l Path discovery: An MEP uses Linktrace Messages (LTMs) or Linktrace Replies (LTRs)
to discover paths and trace the path from an MEP to another MEP or the path between
Maintenance domain Intermediate Points (MIPs).
CFM Principle
CFM can check, isolate, and report connectivity faults in VLANs effectively.
To manage and maintain the network, network administrators make a plan for the network
services and levels, and divide the entire network into several MDs. For the sketch map
of an MD, see Figure 4-1.
Figure 4-1 Maintenance Domain
A series of ports are defined for the edge devices and the internal device, see Figure 4-1.
l The gray points on the edge devices are the services ports connecting to devices
outside the domain. These points are defined as MEPs.
l The black points on the devices (including the internal device) are ports connecting to
devices inside the domain. These points are defined as MIPs.
The management function is implemented through the MEPs and MIPs.
A network can be divided into user domain, provider domain, and operator domain. Each
domain is specified to a level. There are levels from 0 to 7. The level of a domain decides
the inclusion relation of domains. A domain of a higher level may include domains of lower
levels. However, a domain of a lower level cannot include a domain of a higher level. The
domains of the same level cannot include each other. Therefore, the domain of the largest
range has the highest level. The inclusion relation of domains can be tangent (internally
tangent or externally tangent) and inclusive, but it cannot be intersecting.
4-2

Chapter 4 CFM Configuration
The main target of CMF is the networks of service operators. CFM is also effective for
Customer VLANs (C-VLANs). IEEE 802.1ag standard defines the following mechanism:
1. Several nesting MDs configured through a bridge network or a network of a bridge
network. The domains may be managed by different management organizations.
2. An MA identified by an individual MD in a specific bridge and a group of VLANs.
3. The protocol, flow, and formats of CFM protocol packets that are used to detect and
isolate connectivity faults.
4. Configuration ability to configure and manage Maintenance Points (MPs) in an MA. An
MP is used to generate and receive CFM packets.
5. MPs ordered to execute isolation and result inspection for confirmed faults.
4.2 Configuring CFM

To configure CFM on the ZXR10 8900E, perform the following steps:
1 ZXR10(config)#cfm Enters CFM configuration

mode.
2 ZXR10(config-cfm)#set cfm {enable|disable} Enables/Disables CFM globally.
3 ZXR10(config-cfm)#create md index <md-index> Creates an MD.

name-format {1|2 name <md-name>|3 name <md-name>|4
name <md-name>} level <md-level>
4 ZXR10(config-cfm)#md index < md-index> Enters MD configuration mode.
5 ZXR10(config-cfm-md)#create ma index <ma-index> Creates an MA.

name-format {1 name <ma-name>|2 name <ma-name>|3
name <ma-name>|32 name <ma-name>}[vid <vlan-id>]
6 ZXR10(config-cfm-md)#ma index <ma-index> Enters MA configuration mode.
7 ZXR10(config-cfm-ma)#set ccminterval <ccm-interval> Configures the interval of

sending CCM packets in the
maintenance association.
8 ZXR10(config-cfm-ma)#create mep mepid <mepid> Creates a local MEP.

direction {down|up} interface <interface-name>
9 ZXR10(config-cfm-ma)#create rmep mepid <mepid > Creates a remote MEP.

remote-mac <mac-address> lmep <lmepid>
10 ZXR10(config-cfm-ma)#create mip session-id Creates an MIP.

<mip-session-id> interface <interface name>
11 ZXR10(config-cfm-ma)#set mep <mepid> state Configures the MEP status.

{enable|disable}
12 ZXR10(config-cfm-ma)#set mep <mepid> ccm-send Configures the sending flag of

{enable|disable} CCM packets in the MEP.
4-3

13 ZXR10(config-cfm-ma)#set mep <mepid> alarm-lowest-pr Configures the lowest alarm

i<lowest-alarm-priority> priority for the local MEP.
14 ZXR10(config-cfm-ma)#set mep <mepid> priority<ccm- Configures the CCM message

ltm-priority> sending priority for the local
MEP.
15 ZXR10#cfm loopback md <md-index> ma <ma-index> Sends a loopback message.

local-mep<local-mepid> type {unicast <mac-address>|mult
icast}[{[repeat <repeat-range>],[size <tlv-length>],[timeout
<timeout>]}]
16 ZXR10#cfm linktrace md <md-index> ma <ma-index> Sends a link trace message.

local-mep<local-mepid><mac-address>[{[ttl
<ttl-range>],[timeout <timeout>]}]
enable Enables CFM globally.
disable Disables CFM globally.
<md-index> MD index, unique, range: 1-65535.
1 Identifies that the MD name can be empty. When 1 is selected, it

is not required to set the MD name.
2 Basic character string.
<md-name> Length: less than 9 characters.
3 MAC+ 2-byte integer.
<md-name> 2-byte integer.
4 Character string regulated in RF C2579.
<md-name> Length: less than 9 characters.
<md-level> Level of a maintenance domain, range: 07. The bigger the

range, the higher the level.
4-4

<ma-index> MA index, identifying an MA in an MD uniquely, range: 1-65535.
1 MA name is the vlan bound to the MA. During the MA

configuration, the ma-name and the vid should be the same.
<ma-name> Integer. The MA name should be the bound vlan during the MA
configuration.
2 MA name is a character string.
<ma-name> Length: less than 5 characters.
3 MA name is a 2-byte integer.
<ma-name> 2-byte integer.
32 MA name is a character string in ICC format.
<ma-name> Character string in ICC format, length: less than 5 characters.
<vlan-id> Primary VID bound to the MA, default: 0, identifying that the MA
does not include any VLAN.
When a switch creates an MA, the vlan-id must be included.
<ccm-interval> Interval of sending CCMs, range: 1-7, corresponding to 3.3 ms,

10 ms, 100 ms, 1 s, 10 s, 60 s, and 600 s.
<mepid> MEPID, range: 18191. The MEPID in the MA should be unique,

including the local and remote MEPs.
down MEP direction. It controls the sending, receiving, and detection

direction of MEP packets. It corresponds to the link side of the
device.
up MEP direction. It controls the sending, receiving, and detection

direction of MEP packets. It corresponds to the forwarding side
of the device.
<interface-name> Interface name.
4-5

<mepid > MEP ID, range: 1-8191. The MEP ID in the MA should be unique,
including the local MEP and the remote MEP.
<mac-address> MAC address of the remote MEP.
<mip-session-id> MIP index, range: 1-8191.
<interface-name> Interface name.
<mepid > MEP ID, range: 1-8191, used for local MEP and remote MEP.
enable Enables the MEP function.
disable Disables the MEP function.
<mepid > MEPID, which should be unique in the MA.
<enable> Enables the CCM packet sending function of the local MEP.
<disable> Disables the CCM packet sending function of the local MEP.
<mep-id> MEPID, which should be unique in the MA.
<lowest-alarm-priority> Lowest alarm priority, range: 1-9.
<0-7> Packet priority, range: 0-7
md MD.
4-6

ma MA.
local-mep Local MEP index.
<local-mepid> Loal MEPID, identifying a local MEP in an MA, range: 1-8191.
type LBM type.
unicast Unicast LBM.
<mac-address> Destination MAC address.
multicast Multicast LBM.
<repeat-range> Number of LBMs sent at a time, range: 1-200, default: 3.
<tlv-length> Length of the Data TLV field carried by the LBM, optional, range:
1400. If this parameter is not configured, it means that the LBM
does not carry the Data TLV field.
<timeout> Time of waiting for an LBR after an LBM is sent, range: 110,
default: 5 s.
md MD.
ma MA.
local-mep Local MEP index.
<local-mepid> Local MEPID, identifying a local MEP in an MA uniquely, range:

1-8191.
<mac-address> Destination address where an LTM is sent to.
<ttl-range> Maximum number of hops that an LTM can be forwarded, range:

1-64, default: 64.
<timeout> Times of each hop waiting for an LTR after an LTM is sent, range:
510, default: 5 s.
4.3 Maintaining CFM

To maintain CFM on the ZXR10 8900E, run the following commands:
4-7

Command Function
ZXR10#show cfm status Displays the CFM global

configuration state.
ZXR10#show cfm md {<md-index>|all} Displays the MD information.
ZXR10#show cfm ma {<ma-index>|all} md <md-index> Displays the detailed information

of an MA in an MD.
ZXR10#show cfm mp {<mp-id>|all} md <md-index> ma <ma-index> Displays the specific MPs

information in an MA.
For a descriptions of the parameters, refer to the following table:
<md-index>|all md-index: identifies an MD and displays the information a specific

MD, range: 1-65535.
all: displays the information of all current MDs.
<ma-index>|all ma-index: identifies a specific M and displays the information of a

specific MA, range: 1-65535.
all: Displays the information of all current MAs.
<md-index> Identifies a specific MD, range: 1-65535.
<mp-id>|all mp-id: identifies an MEP in an MA uniquely, range: 1-8191.

all: displays all MPs in an MA MPs, including MIPs, local MEPs,
and RMEPs.
<ma-index> Identifies a specific MA, range: 1-65535.
The following is sample output from the show cfm status command (checking the CFM
global state):
ZXR10#show cfm status
CFM enabled
CFM version:0
CFM enabled CFM is enabled globally.
CFM version:0 Version of CFM protocol, default: 0.
The following is sample output from the show cfm md all command:
ZXR10#show cfm md all
MD index 8
name format/name: 2(Base string)/md8
level: 7
contain MA numbers:1
4-8

MD index 1 Index value of an MD.
name format/name Format field (meaning) and name of an MD name.
level Level of an MD.
contain MA numbers Number of MAs created in the current MD.
The following is sample output from the show cfm ma all md 1 command:
ZXR10#show cfm ma all md 1
MA index 1
name-format/name: 1(Primary VID)/4094
belong to MD: 1
CCM interval: 10s
Vlan list: 4094(pvid)
Contained MEP numbers: 24
MA index 2
name-format/name: 1(Primary VID)/0
belong to MD: 1
CCM interval: 10s
Vlan list: no vids
Contained MEP numbers: 0
MA index 2 Index value of an MA.
name-format/name Format field (meaning) and name value of an MA name.
belong to MD MD to which the current MA belongs.
CCM interval CCM interval of the MA.
Vlan list Vlan list of an MA.
Contained MEP numbers Number of MEPs (including local MEP and RMEP) created in
an MA.
4.4 CFM Configuration Examples

CFM Fast Connectivity Detection
R1 and R2 are connected directly, and the CFM function is configured for the directly
connected interfaces of R1 and R2 to establish a connection, see Figure 4-2.
4-9

Figure 4-2 CFM Connection Establishment
1. Create MDs and MAs on R1 and R2. The MDs have the same ID and name, and
the MAs have the same ID and name. Enable the CFM function globally.
2. Create local MEPs for the directly connected interfaces of R1 and R2. The MEPs
are of the same level. Use the peer MAC and MEP ID to create RMEPs on R1
and R2. Enable the local MEP, CCM sending and RMEP.
3. Run the show cfm mp command on R1 and R2 to check the MEP identification bit
to check the CFM connection establishment of R1 and R2.
R1(config)#cfm
R1(config-cfm)#set cfm enable
R1(config-cfm)#create md index 1 name-format 2 name md1 level 1
R1(config-cfm)#md index 1
R1(config-cfm-md)#create ma index 1 name-format 2 name ma1 vid 100
R1(config-cfm-md)#ma index 1
R1(config-cfm-ma)#create mep mepid 1 direction down interface gei-0/1/0/1
R1(config-cfm-ma)#set ccminterval 1 /*fast detection*/
R1(config-cfm-ma)#set mep 1 state enable
R1(config-cfm-ma)#set mep 1 ccm-send enable
R1(config-cfm-ma)#create rmep mepid 2 remote-mac 00ee.ff10.2000
R1(config-cfm-ma)#end

R2(config)#cfm
R2(config-cfm-md)#create ma index 1 name-format 2 name ma1 vid 100
R2(config-cfm-ma)#set ccminterval 1
R2(config-cfm-ma)#create rmep mepid 1 remote-mac 00ee.ff10.1000
4-10

R2(config-cfm-ma)#end
1. Run the show cfm mp all md 1 ma 1 command on R1 to check the link information.
The execution result is displayed as follows:
RP1(config)#show cfm mp all md 1 ma 1
MP type : Local MEP
Direction : down
MEPID : 1
MEPIndex : 1
Level : 1
Primary VID : 100
Assign port : gei-0/1/0/1
Priority : 7
LowestAlarmPriority : 1
Client level : 7
Admin state : enable
CCM state/interval : enable/3.3ms
AIS state/interval : disable/1s
LCK state/interval : disable/1s
DM state : disable
LM state : disable
-------------------------------------------------------------------
PresentRDI : 0 MADefectIndication : 0
SomeRDIDefect : 0 SomeRMEPCCMDefect : 0
ErrorCCMDefect : 0 UnexpectedLevelDefect : 0
UnexpectedPeriodDefect : 0 UnexpectedMACDefect : 0
UnexpectedMEPIDDefect : 0 XconCCMDefect : 0
AISRcvdFlag : 0 LCKRcvdFlag : 0
--------------------------------------------------------------------
TotalSendCCMs : 0 TotalRcvdCCMs : 0
RightRcvdCCMs : 0 DefErrorCCMs : 0
DiscardCCMs : 0 DefXconCCMs : 0
TotalSendLBMs : 0 TotalRcvdLBRs : 0
TotalRcvdLBMs : 0 TotalSendLBRs : 0
---------------------------------------------------------------------
MP type : Remote MEP

MEPID : 2
MEPIndex : 2
Level : 1
RemoteMAC : 00ee.ff10.2000
CCM interval : 3.3ms
------------------------------------------------------------------------
RMEPLastRDI : 0 RMEPCCMdefect : false
4-11

------------------------------------------------------------------------
1DMFrameTimeDelay : 0s, 0ns
1DMFrameTimeDelayChg : 0s, 0ns
DMMFrameTimeDelay : 0s, 0ns
DMMFrameTimeDelayChg : 0s, 0ns
LMMCount : 0 DLMCount : 0
LMMFrameSendRemote : 0 DLMFrameSendRemote : 0
LMMFrameSendLocal : 0 DLMFrameSendLocal : 0
LMMFrameLossRemote : 0 DLMFrameLossRemote : 0
LMMFrameLossLocal : 0 DLMFrameLossLocal : 0
LMMAveFrameLossRemote : 0 DLMAveFrameLossRemote : 0
LMMAveFrameLossLocal : 0 DLMAveFrameLossLocal : 0
LMMHighFrameLossRemote : 0 DLMHighFrameLossRemote : 0
LMMHighFrameLossLocal : 0 DLMHighFrameLossLocal : 0
LMMTotalFrameLossRemote : 0 DLMTotalFrameLossRemote : 0
LMMTotalFrameLossLocal : 0 DLMTotalFrameLossLocal : 0
LMMFrameLossRatioRemote : 0.000000 DLMFrameLossRatioRemote : 0.000000
LMMFrameLossRatioLocal : 0.000000 DLMFrameLossRatioLocal : 0.000000
------------------------------------------------------------------------
2. Run the show cfm mp all md 1 ma 1 command on R2 to check the link information.
The execution result is displayed as follows:
RP2(config)#show cfm mp all md 1 ma 1
MP type : Local MEP
Direction : down
MEPID : 2
MEPIndex : 1
Level : 1
Primary VID : 100
Assign port : gei-0/1/0/1
Priority : 7
LowestAlarmPriority : 1
Client level : 7
CCM state/interval : enable/3.3ms
AIS state/interval : disable/1s
LCK state/interval : disable/1s
DM state : disable
LM state : disable
------------------------------------------------------------------
PresentRDI : 0 MADefectIndication : 0
SomeRDIDefect : 0 SomeRMEPCCMDefect : 0
ErrorCCMDefect : 0 UnexpectedLevelDefect : 0
UnexpectedPeriodDefect : 0 UnexpectedMACDefect : 0
UnexpectedMEPIDDefect : 0 XconCCMDefect : 0
AISRcvdFlag : 0 LCKRcvdFlag : 0
4-12

-------------------------------------------------------------------
TotalSendCCMs : 0 TotalRcvdCCMs : 0
RightRcvdCCMs : 0 DefErrorCCMs : 0
DiscardCCMs : 0 DefXconCCMs : 0
TotalSendLBMs : 0 TotalRcvdLBRs : 0
TotalRcvdLBMs : 0 TotalSendLBRs : 0
-------------------------------------------------------------------
MP type : Remote MEP

MEPID : 1
MEPIndex : 2
Level : 1
RemoteMAC : 00ee.ff10.1000
CCM interval : 3.3ms
------------------------------------------------------------------------
RMEPLastRDI : 0 RMEPCCMdefect : false
------------------------------------------------------------------------
1DMFrameTimeDelay : 0s, 0ns
1DMFrameTimeDelayChg : 0s, 0ns
DMMFrameTimeDelay : 0s, 0ns
DMMFrameTimeDelayChg : 0s, 0ns
LMMCount : 0 DLMCount : 0
LMMFrameSendRemote : 0 DLMFrameSendRemote : 0
LMMFrameSendLocal : 0 DLMFrameSendLocal : 0
LMMFrameLossRemote : 0 DLMFrameLossRemote : 0
LMMFrameLossLocal : 0 DLMFrameLossLocal : 0
LMMAveFrameLossRemote : 0 DLMAveFrameLossRemote : 0
LMMAveFrameLossLocal : 0 DLMAveFrameLossLocal : 0
LMMHighFrameLossRemote : 0 DLMHighFrameLossRemote : 0
LMMHighFrameLossLocal : 0 DLMHighFrameLossLocal : 0
LMMTotalFrameLossRemote : 0 DLMTotalFrameLossRemote : 0
LMMTotalFrameLossLocal : 0 DLMTotalFrameLossLocal : 0
LMMFrameLossRatioRemote : 0.000000 DLMFrameLossRatioRemote : 0.000000
LMMFrameLossRatioLocal : 0.000000 DLMFrameLossRatioLocal : 0.000000
------------------------------------------------------------------------
Cross-L2 VPN Connectivity Detection

In an L2 VPN network, the MEP of the CFM is configured for PE1 and PE2, and the
link between PE1 and PE2 is connected, see Figure 4-3.
4-13

Figure 4-3 Cross-L2 VPN Connectivity Detection Configuration Example
1. Create MDs and MAs on PE1 and PE2. The MDs have the same ID and name,
and the MAs have the same ID and name.
2. Configure the UP MEP for the interfaces on the AC side of PE1 and PE2
separately, and the MIP for the interfaces on the public network side of PE1 and
PE2.
3. PE1 performs the cfm linktrace and cfm loopback operations on MIP and MEP of
PE2 to check the link connection.
Run the following commands on PE1:
PE1#configure terminal
PE1(config)#cfm
PE1(config-cfm)#set cfm enable
PE1(config-cfm)#create md index 1 name-format 2 name MD1 level 4
PE1(config-cfm)#md index 1
PE1(config-cfm-md)#create ma index 1 name-format 2 name MA1
PE1(config-cfm-md)#ma index 1
PE1(config-cfm-ma)#create mep mepid 1 direction up interface gei-0/3/0/1
PE1(config-cfm-ma)#set mep 1 stat en
PE1(config-cfm-ma)#set mep 1 ccm en
PE1(config-cfm-ma)#create rmep mepid 2 remote 00ee.efab.ede3
PE1(config-cfm-ma)#create mip session-id 1 interface gei-0/2/0/1
PE1(config-cfm-ma)#end
Run the following 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)#create mep mepid 2 direction up interface gei-0/3/0/1
PE2(config-cfm-ma)#set mep 2 ccm en
4-14

PE2(config-cfm-ma)#create rmep mepid 1 remote 0016.1514.1312

PE2(config-cfm-ma)#end
PE1 performs the cfm linktrace and cfm loopback operations on PE2. If the link is
normal, the response to the trace and ping operations are correct. If the link status
changes from abnormal to normal, the corresponding alarms are generated on both
PE1 and PE2.
PE1#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
PE2#cfm linktrace md 1 ma 1 local-mep 1 0016.1514.1312

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

4-16

Chapter 5
SAMGR Configuration
Table of Contents
SAMGR Overview ......................................................................................................5-1
Configuring SAMGR...................................................................................................5-4
SAMGR Maintenance.................................................................................................5-8
SAMGR Configuration Examples..............................................................................5-12
5.1 SAMGR Overview

Introduction to SAMGR
With the rapid development of IP technology, various value-added services are widely
used on the Internet. Some important carrier class services, such as Next Generation
Network (NGN)/The 3rd Generation Mobile Communications (3G), Internet Protocol
Television (IPTV) stream media, special line and VPN, have high requirement for reliability
on the IP network. The requirements of the carrier class services for reliability on the IP
network include:
l Device reliability
l Link reliability
l Network reliability
On the bearer network, the requirement for network device availability is 99.999%, that is,
the time for maintenance of a stop-running device due to faults caused by various reasons
during continuous running in a whole year is only about 5 minutes. High reliability is a
basic requirement of a carrier class device, and it is a basic requirement of operators to
construct networks. The basic network works as the bearer body of various services, so
its reliability is becoming a focus.
On a switch or a Packet Transport Network (PTN) device, reliability technology includes
device hardware redundancy and network reliability technology. Here introduces network
reliability technology.
Network reliability technology includes network fault detection technology and protection
switching technology.
On different network layers, network fault detection technology has the following detection
mechanisms.
l Transport layer/physical layer: Automatic Protection Switching (APS)

l Link layer: BFD, MPLS OAM and Eth-OAM
l Network layer: Hello mechanism of protocols, VRRP and BFD
5-1

l Application layer: heartbeats of various application protocols

There are the following protection switching technologies.
l End-to-end protection: 1:1, 1+1, 1:N, M:N - tunnel protection switching, MC-LAG,
MC-APS, MVLAN and hotstandby
l Local protection: FRR, including IP-FRR, LDP-FRR, TE-FRR and PW-FRR
Service Availability Manager (SAMGR) is used to manage the relationship between
services and the availability. The SAMGR has the following functions:
l Track object management
l Track group management
l OAM binding management
l OAM mapping management
The SAMGR implements the linkage between services and the detection technology. It
switches the services from a network link quickly if the network link is faulty.
SAMGR Principle
l SAMGR Working Principle
In practical applications, switches support several detection technologies. The
protection switching applications also need to monitor the real-time detection state
to meet the reliability requirements in different network structures. Therefore,
the SAMGR is introduced to implement the linkage between various detection
technologies and services.
The SAMGR isolates detection technologies from services, and reduces the coupling
between modules. The working principles are as follows:
1. The SAMGR abstracts a detection example to a track object. It associates the

track object with the detection example by configuring a trackname for the track
object. The trackname is called directly in the service where the detection result
needs to be monitored..
2. When detecting that the link state changes, the detection technology advertises
the state change to the SAMGR directly.
3. The SAMGR informs the application service associated with the track object. The
application service performs state switching in accordance with the state change
to protection the link.
At the same time, the SAMGR also can manage the binding relation between racks
and send the local state to the remote end. In this way, fault transmission and recovery
is accomplished.
l Practical Network Structures

1. Figure 5-1 displays the linkage among VRRP, SAMGR, EOAM, and BFD.
5-2

Chapter 5 SAMGR Configuration
Figure 5-1 Linkage Between VRRP, SAMGR, or EOAM and BFD
The network structure descriptions are as follows:

a. EOAM is configured between the switches and the switches to keep links
alive. BFD is configured between Router A and Router B.
b. Router A and Router B operate in active/standby mode. The switches monitor
the states of EOAM and BFD separately.
When EOAM detects a fault, it reports the fault to the SAMGR. The SAMGR
informs the service to switch the state directly in accordance with the relation
between the track object and the service.
When a fault of the pee-type BFD occurs on the switch, the SAMGR advertises
the state to the service, and then the service performs switching in accordance
with its policy on the basis of the EOAM state and the BFD state.
2. A CE connects to two PEs symmetrically to perform linkage of states between
detections, see Figure 5-2.
Figure 5-2 Linkage of Symmetrical Dual-Connection Between CE and PE
The network structure descriptions are as follows:
a. A PW is established between PE-1 and PE-3, and a PW is established

between PE-2 and PE-4.
b. CE1 connects to PE-1 and PE-2.
c. CE2 connects to PE-3 and PE-4.
5-3

d. OAM detection (Ethernet in the First Mile (EFM)/Connectivity Fault

Management (CFM)/link keepalive) is enabled between CEs and PEs.
e. BFD is enabled between PEs to detect PWs. MPLS OAM is enabled between
PEs to detect TE Label Switched Paths (LSPs).
f. OAM mapping/binding is associated between the Access Circuit (AC)-side
link detection and PW link detection (or between LDPs) to transmit a fault.
The principle of fault detection and switching is as follows:
If a fault occurs on the AC between CE1 and PE1,
a. AC EOAM of PE1 detects the AC fault and informs the SAMGR.
b. The SAMGR of PE1 maps the detection track object of PW corresponding
to the AC in accordance with the OAM mapping/binding configuration.
c. If BFP or MPLS-OAM is configured between PEs, PE-1 transmits the OAM
fault to PE-2 transparently.
d. When PE3 receives the BFD/MPLS OAM/LDP fault, if there is a standby
PW on the remote PE, PE3 switches the traffic. Otherwise, PE3 performs
OAM mapping/binding to map the corresponding AC and advertises the fault
to CE2.
If a fault occurs on a PW,
a. BFD/MPLS OAM on a PE detects the PW/LSP fault.
b. The PE performs OAM mapping/binding to map the corresponding local AC.
c. If there is a standby PW on the PE, the PE switches traffic. Otherwise, the PE
performs OAM mapping/binding to map the corresponding AC and advertises
the fault to the local CE.
5.2 Configuring SAMGR

Configuring a Track Object
To configure a track object on ZXR10 8900E, perform the following steps.
1 ZXR10(config)#samgr Enters SAMGR configuration

mode.
2 ZXR10(config-samgr)#track <name> efm interface Configures a track object of

<ifname> which the detection type is
EFM.
3 ZXR10(config-samgr)#track <name> cfm md <1-65535> Configures a track object of

ma <1-65535> local-mep <1-8191> remote-mep <1-8191> which the detection type is
CFM.
5-4

4 ZXR10(config-samgr)#track <name> ping-detect group Configures a track object of

<1-10> which the detection type is
ping-detect.
5 ZXR10(config-samgr)#track <name> sqa instance Configures a track object of

<1-150> which the detection type is
SQA.
6 ZXR10(config-samgr)#track <name> mpls-oam tunnel-id Configures a track object of

<1-4000> ingress-id <ingress vlaue> which the detection type is
MPLS OAM.
7 ZXR10(config-samgr)#track <name> link-bfd { ipv4 Configures a track object of

<local-ipv4-address>< remote-ipv4-address >| ipv6 < which the detection type is
local-ipv6-address >< remote-ipv6-address >} interface link-bfd.
<ifname>[vrf <vrfname>]
8 ZXR10(config-samgr)#track <name> peer-bfd { ipv4 Configures a track object of

<local-ipv4-address><remote-ipv4-address>| ipv6 < which the detection type is
local-ipv6-address><remote-ipv6-address>}[vrf <vrfname>] peer-bfd.
9 ZXR10(config-samgr)#track <name> ldp-bfd fec-address Configures a track object of

< fec-address > mask-length <0-32> interval <10-990> which the detection type is
min-rx <10-990> multiplier <3-50> ldp-bfd.
10 ZXR10(config-samgr)#track <name> rsvp-bfd tunnel-id Configures a track object of

<1-4000> interval <10-990> min-rx <10-990> multiplier which the detection type is
<3-50> rsvp-bfd.
11 ZXR10(config-samgr)#track <name> pw-bfd vcid Configures a track object of

<1-4294967295> peerid <peer-id>{aal1|aal2|atm-aal5|atm- which the detection type is
cell|atm-vcc|atm-vpc|cem|ceop| cesopsn-basic | cesopsn-cas pw-bfd.
|hdlc | e1 |e3| ether | ether-vlan | fr-dlci-martini | fr-dlci |
fr-port | ip | ppp | t1 |t3}
12 ZXR10(config-samgr)#track <name> pw vcid Configures a track object of

<1-4294967295> peerid <peer-id>{aal1|aal2|atm-aal5|atm- which the detection type is PW.
cell|atm-vcc|atm-vpc|cem|ceop| cesopsn-basic | cesopsn-cas (Rosng11 does not support this
| hdlc | e1 |e3| ether | ether-vlan | fr-hdlci-martini | fr-dlci | now.)
fr-port | ip | ppp | t1 |t3}
13 ZXR10(config-samgr)#track <name> vrrp interface Configures a track object of

<ifname> vrid <1-255> which the detection type is
VRRP.
14 track <name> l2-bfd session <session name> Configures a track object of

which the detection type is
l2_bfd.
5-5

<name> The name of the track object, with 1-31 characters
<ifname> The interface on which EFM function is enabled
<1-65535> CFM MD index parameter
<1-65535> CFM MA index parameter
local-mep <1-8191> Local MEP parameter
remote-mep <1-8191> Remote RMEP parameter
<1-10> Ping detection group number
<1-150> SQA detection instance number
<1-4000> MPLS OAM tunnel number
ingress-id <ingress vlaue> Ingress node address
egress-id <egress value> Egress node address
<local-ipv4-address> Link-BFD local IPv4 address
<remote-ipv4-address> Link-BFD remote IPv4 address
<local-ipv6-address> Link-BFD local IPv6 address
<remote -ipv6-address> Link-BFD remote IPv6 address
<ifname> Egress interface name
<vrfname> VRF name
5-6

<fec-address> FEC address
<0-32> Mask length
interval <10-990> The minimum interval to send BFD packets
min-rx <10-990> The minimum interval to receive BFD packets
<3-50> Detection multiple
<1-4294967295> PW VCID range
<peer-id> PW remote address
{aal1|aal2|atm-aal5|atm-cell PW type
|atm-vcc|atm-vpc|cem|ceop|
cesopsn-basic | cesopsn-cas |
hdlc | e1 |e3| ether | ether-vlan |
fr-dlci-martini | fr-dlci | fr-port |
ip | ppp | t1 |t3}
<ifname> The name of the interface on which the VRRP group is configured
<1-255> Virtual switch ID
<session name> The name of the L2_bfd, with 1-31 characters
Configuring a Track Group

To configure a track group on ZXR10 8900E, perform the following steps.

mode.
2 ZXR10(config-samgr)#track-group <groupname> Configures a track group and

enters track group configuration
mode.
3 ZXR10(config-samgr-track-group)#track <trackname> This adds a track object to the

track group.
5-7

4 ZXR10(config-samgr-track-group)#inactive-number Configures the policy of a track

<1-10> group.
<groupname> Track group name
<trackname> The name of the track object added to the track group
<1-10> Track group policy that describes the number of down tracks that
will results in the track group down
Configuring Binding Relation

To configure binding relation on ZXR10 8900E, perform the following steps.

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

track-group}<name> between track objects or
between track groups.
track<name> The name of the passive track object, that is, the name of the
track object that receives state transmission
{track | track-group}<name> The name of the active track object or track group, that is,
the name of the track object or track group that starts state
transmission
5.3 SAMGR Maintenance

On the ZXR10 8900E, use the following commands to maintain the SAMGR.
5-8

Command Function
ZXR10#show samgr brief This shows the brief information

related to track objects.
ZXR10#show samgr track [<trackname>[verbose]] Displays the detailed information

of a track object, for example, the
state change information.
ZXR10#show samgr track-group [<trackname>[verbose]] Displays the detailed information

of a track group, for example, the
state change information.
An example of the show samgr brief command output is shown below.

ZXR10#show samgr brief
The total of track at this Router is 7
======================================================
Track-name Detect-type App-num State
vrrp2 vrrp 0 up
oam1 mpls-oam 1 up
ping1 ping-detect 0 L-down
vrrp1 vrrp 0 up
efm1 efm 1 T-down
ping2 ping-detect 0 up
vrrp2 vrrp 0 up
Track-name The name of a track object
Detect-type The detection type of track object
App-num Number of applications that use the track object
State The state of the track object
An example of the show samgr track command output is shown below.

ZXR10#show samgr track
Track name is xx
Detect type : peer-bfd
Track parameter
Local IP: 1.1.1.1 Remote IP: 1.1.1.3 Vrf name: zte
App number : 0
Active track : none
Passive track: none
Oam-mapping : no
Track state : unknow
State change : 0 state changes, last state change 00-00-00 00:00:00
5-9

Track name is bfd1

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

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

Detect type : mpls-oam
Track parameter
Tunnel Id: 1 Ingress Id: 1.2.3.4 Egress Id: 5.6.7.8
App number : 1
Active track : none
Passive track: none
Oam-mapping : no
Track state : up
ZXR10(config)#show samgr track sqa verbose
Track name is sqa
State change record:
old state new state change time
1 unknown local down 2010-07-19 02:57:28
2 local down up 2010-07-19 03:05:16
3 up local down 2010-07-19 03:06:24
4 local down up 2010-07-19 03:08:00
5 up local down 2010-07-19 03:08:13
5-10

Track name The name of a track object
Detect type The detection type of track object
Track parameter Track object parameter
App number Number of applications that use the track object
Active track Whether to work as an active track to send state to the passive
track
Passive track Whether to work as a passive track to receive the state sent by
the active track
Oam-mapping Whether the track has the OAM mapping ID
Track state The state of the track object
State change The state change information of the track object
old state The original state of the track object before the state is changed.
new state The current state of the track object after the state is changed.
change time The state change time of the track object.
An example of the show samgr track-group command output is shown below.
ZXR10#show samgr track-group

Track-group name: aaa
Set inactive number: all
App number: 0
Track-group state: up
Track-group member: 0
-------------------------------
Track-group name: group1
Set inactive number: 1
App number: 0
Track-group state: local down
Track-group member: 3
Track name: ping3 State: up
Track name: ping2 State: up
Track name: ping1 State: local down
ZXR10(config)#show samgr track-group 1 verbose
Track-group name is 1
State change record:
old state new state change time
1 up local down 2010-07-19 03:14:43
2 local down up 2010-07-19 03:14:50
3 up local down 2010-07-19 03:14:56
4 local down up 2010-07-19 03:15:01
5-11

Track-group name The name of a track group
Set inactive number The policy of a track group
App number Number of applications that use the track object
Track-group member Track group member
Track name Name of track objects that are bound to the track group
State The state of the track object
old state The original state of the track group before the state is changed.
new state The current state of the track group after the state is changed.
change time The state change time of the track group.
5.4 SAMGR Configuration Examples

Linkage Between EFM and VRRP
Figure 5-3 Linkage Between EFM and VRRP
1. Configure an EFM connection on the direct-connected interfaces of the link
between R1 and R2.
2. Configure a track object of which the detection type is EFM on the
direct-connected interface of R2 in SAMGR configuration mode.
3. Configure the same VRRP group number and virtual address on R2 and R3. To
make R2 work as a master switch, bind VRRP on R2 to the track object of EFM.
5-12

4. Disable EFM on R1, the VRRP on R2 becomes Init state, and the VRRP on R3
becomes Backup state. Enable EFM on R1, the VRRP on R2 becomes Master
state, and the VRRP on R3 becomes Backup state.
The configuration of R1:
R1(config)#efm
R1(config-efm-if)#set ethernet-oam function enable
R1(config-efm-if)#exit

R2(config)#switchvlan-configuration
R2(config -swvlan)#interface gei-0/2/0/1
R2(config-swvlan-intf)#sw trunk vlan 20
R2(config-swvlan-intf)#exit
R2(config-swvlan)#exit
R2(config-if)#exit
R2(config-if)#exit
R2(config)#efm
R2(config-efm-if)#set ethernet-oam function enable
R2(config-efm-if)#exit
R2(config-efm)#exit
R2(config)#samgr
R2(config-samgr)#track efm efm interface gei-0/2/0/1
R2(config-samgr)#exit
R2(config)#vrrp
R2 (config-vrrp)#interface vlan20
R2(config-vrrp-if)#vrrp 1 track object efm link-type
R2(config-vrrp-if)#exit
5-13

R3(config-if)#exit
R3(config-if)#exit
R3(config)#vrrp
Check the VRRP configuration results on R2 and R3. The results show that R2 is a
master router and R3 is a bBackup router. The output of the show samgr command
on R2 shows that the EFM track object is in up state.
vlan20 1 100 1000 P Master 10.0.0.1 10.0.0.1
R2#show samgr brief
The total of track at this Router is 1.
============================================================================
efm efm 1 up

vlan20 1 100 1000 P Backup 10.0.0.2 10.0.0.1
When EFM is disabled on R1, the VRRP becomes Init from Master on R2, and the
VRRP becomes Master on R3. The output of the show samgr command on R2 shows
that the EFM track object is in loacl down state.
R1(config)#efm
R1(config-efm)#set ethernet-oam function disable
5-14


vlan20 1 100 1000 P Init 0.0.0.0 10.0.0.1
R2#show samgr brief
============================================================================
efm efm 1 L-down

vlan20 1 100 1000 P Master 10.0.0.2 10.0.0.1
When EFM is enabled on R1 again, the VRRP on R2 becomes Master, and the VRRP
on R3 becomes Backup. The EFM track object is in up state on R2.
R1(config)#efm

vlan20 1 100 1000 P Master 10.0.0.1 10.0.0.1
R2#show samgr brief
============================================================================
efm efm 1 up

vlan20 1 100 1000 P Backup 10.0.0.2 10.0.0.1
Linkage Between CFM and VRRP

As shown inFigure 5-4 VRRP is run between R2 and R3. The VRRP virtual address
5-15

Figure 5-4 Linkage Between CFM and VRRP
1. Configure CFM on the direct-connected interfaces of the link between R1 and R2.
2. Configure a track object of which the detection type is CFM on the
direct-connected interface of R2 in SAMGR configuration mode.
3. Configure the same VRRP group number and virtual address on R2 and R3. To
make R2 work as a master router, bind VRRP on R2 to the track object of CFM.
4. Disable CFM on R1, the VRRP on R2 becomes Init state, and the VRRP on R3
becomes Backup state. Enable CFM on R1, the VRRP on R2 becomes Master
state, and the VRRP on R3 becomes Backup state.
R1(config)#cfm
R1(config-cfm-md)#create ma index 4 name-format 2 name a4 vid 0
R1(config-cfm-ma)#create rmep mepid 16 remote-mac 00d0.d011.3377 lmep 8

R2(config-if)#exit
5-16


R2(config-if)#exit
R2(config)#cfm
R2(config-cfm-md)#create ma index 4 name-format 2 name a4 vid 0
R2(config-cfm-ma)#create rmep mepid 8 remote-mac 00a1.1122.0011 lmep8
R2(config-cfm-ma)#exit
R2(config-cfm-md)#exit
R2(config-cfm)#exit
R2(config)#samgr
R2(config-samgr)#track cfm cfm md 2 ma 4 local-mep 16 remote-mep 8
R2(config)#vrrp
R2(config-vrrp-if)#vrrp 1 track object cfm link-type
R2(config-vrrp-if)#exit

R3(config-if)#exit
5-17


R3(config-if)#exit
R3(config)#vrrp
R3(config-vrrp)#interface
Check the VRRP configuration results on R2 and R3. The results show that R2 is a
master router and R3 is a bBackup router. The output of the show samgr command
on R2 shows that the CFM track object is in up state.
vlan20 1 100 1000 P Master 10.0.0.1 10.0.0.1
R2(config-samgr)#show samgr brief
============================================================================
cfm cfm 1 up

vlan10 1 100 1000 P Backup 10.0.0.2 10.0.0.1
When CFM is disabled on R1, the VRRP becomes Init from Master on R2, and the
VRRP becomes Master on R3. The output of the show samgr command on R2 shows
that the CFM track object is in loacl down state.
R1(config)#cfm
R1(config-cfm)#set cfm disable

vlan20 1 100 1000 P Init 0.0.0.0 10.0.0.1
R2#show samgr brief
============================================================================
cfm cfm 1 L-down

vlan10 1 100 1000 P Master 10.0.0.2 10.0.0.1
5-18

When CFM is enabled on R1 again, the VRRP on R2 becomes Master, and the VRRP
on R3 becomes Backup. The CFM track object is in up state on R2.
R1(config)#cfm

vlan20 1 100 1000 P Master 10.0.0.1 10.0.0.1
R2#show samgr brief
============================================================================
cfm cfm 1 up

vlan10 1 100 1000 P Backup 10.0.0.2 10.0.0.1
5-19

5-20

Chapter 6
BFD Configuration
Table of Contents
BFD Overview ............................................................................................................6-1
Configuring BFD.........................................................................................................6-2
Maintaining BFD.........................................................................................................6-7
BFD Configuration Examples .....................................................................................6-8
6.1 BFD Overview

Introduction to BFD
For network devices, an important feature is to detect the communication failures between
adjacent systems rapidly. Therefore, when failures occur, the devices can establish
alternative paths or hand over services to other links more quickly.
BFD provides a solution to the above problem. BFD protocol can detect failures on any
types of paths between adjacent systems, including direct-connected physical link, virtual
circuit, tunnel, MPLS LSP, multi-hop routing channel, and indirect-connected tunnel.
Because of its simpleness and unitary, BFD can focus on fast detection of forwarding
failures. It helps networks to implement transmission of voice, video, and other services
with good Quality of Service (QoS), thus helps service providers to provide real-time
services (such as Voice over Internet Protocol (VoIP) on the base of IP network.
BFD Principle
BFD is a simple Hello protocol. It is similar to the Hello mechanisms of routing protocols.
BFD is simpler and universal. The two systems that establish a BFD session send packets
to each other periodically. If one system does not receive any packet from the peer in a
specific period, it considers that there is a failure on the communication path. The BFD
session will be down, and BFD will inform the upper layer protocol to select another path.
To reduce the loads of devices, some special application modes are designed in BFD. In
these modes, devices can reduce the number of BFD packets sent to the peers; or it is
unnecessary for the devices to send BFD packets periodically. The devices can send the
packets only when it is necessary.
BFD protocol aims at fast failure detection (including failures on interfaces, data links, and
even forwarding engines) on a bidirectional tunnel between forwarding engines. Another
aim is to provide a single detection mechanism that can be applied to any type of medium
and any protocol layer. BFD detects failures in the forwarding engines between a device
and the next hop. It is likely to work in some parts of a system forwarding engine. The
6-1

forwarding engine and the control engine are isolated. This not only binds the protocol to
the forwarding plane, but also isolates the protocol from the routing protocol engine (control
plane). Therefore, BFD can take effect in non-interrupt forwarding and run in the control
engine.
BFD provides failure detection between systems, including direct connected physical links,
virtual links, tunnels, MPLS LSPs, and multi-hop routing paths.
6.2 Configuring BFD

Configuring a BFD Session
To configure a BFD session on the ZXR10 8900E, perform the following steps:
1 ZXR10(config)#bfd Enters BFD configuration mode.
2 ZXR10(config-bfd)#session <session-name>{ link-bfd Configures a BFD session in

{ipv4 | ipv6}<src-ip-address><dst-ip-address> interface BFD configuration mode.
<interface-name>[vrf <vrf-name>]| peer-bfd {ipv4 |
ipv6}<src-ip-address><dst-ip-address>[vrf <vrf-name>]|
ldp-bfd fec-address <src-ipv4-address><mask-length>[vrf
<vrf-name>]| pw-bfd pw-name <pw-name>}
3 ZXR10(config-bfd)#interface <interface-name> Specifies an interface that is

to be configured with the BFD
session in BFD configuration
mode.
4 ZXR10(config-bfd-interface-name)#time-negotiation Configures the interval of

interval <interval> min-rx < min-rx> multiplier <multiplier> sending detection packets,
minimum interval of receiving
detection packets, and
detection multiplier for the
BFD session.
<src-ip-address> Source IP address used for establishing the BFD session. The
source IP address must be a local IP address.
<dst-ip-address> Destination IP address used for establishing the BFD session.

The destination IP address is not limited to a directly connected
IP address.
<interface-name> Specific outgoing interface of the BFD session. The outgoing

interface is not cared if it is not specified, so it is only required to
ensure that the packet is sent from the local successfully.
6-2

Chapter 6 BFD Configuration
<interval> Interval (ms) of sending detection packets, range: 10-990.
<min-rx-interval> Minimum interval (ms) of receiving detection packets, range:

10-990.
<multiplier> Packet detection multiplier, range: 3-50.
Configuring BFD for a Static Route

To configure BFD for a static route on the ZXR10 8900E, perform the following steps:
Command Function
ZXR10(config)#ip route vrf <vrf-name><prefix><net-mask>{<fo Configures a static route for a

rwarding-router's-address>[globle]|<interface-name>[<forwarding- private network and enables BFD
router's-address>]}[<distance-metric>][metric <metric-number>] for this link.
bfd enable
ZXR10(config)#ip route <prefix><net-mask>{<forwarding-router's Configures a static route for a

-address>|<interface-name>[<forwarding-router's-address>]}[<distan public network and enables BFD
ce-metric>][metric <metric-number>] bfd enable for this link.
For a description of the parameters, refer to the following table:
<prefix> Prefix of the destination network, in dotted decimal notation.
<net-mask> Network mask, in dotted decimal notation.
<forwarding-router's-address> IP address of the next hop, in dotted decimal notation.
globle The next hop of the private-network route is an IP address of the

public network. This parameter and the bfd enable command are
mutually exclusive.
<interface-name> Specific outgoing interface.
<distance-metric> Administrative distance, range: 1-255, default:1.
<metric-number> Route metric, range: 1-255, default: 1.
During the static route configuration, you need to confirm the unique link to the destination
and enable BFD for this link by running the bfd enable command.
Configuring BFD for the OSPF Route

To configure BFD for the OSPF on the ZXR10 8900E, perform the following steps:
6-3

1 ZXR10(config)#router ospf <process-id> Configures the OSPF process

ID and then enters OSPF
protocol configuration mode.
2 ZXR10(config-ospf-id)#bfd [area <area-id>] Enables BFD for all interfaces

or enables BFD for all interfaces
bound to the specific area.
3 ZXR10(config-ospf-id)#interface <interface-name> Selects an interface to be

enabled with BFD.
4 ZXR10(config-ospf-id-if-interface-name)#bfd Enables BFD for the current

interface.
Configuring BFD for the IS-IS Route

To configure BFD for the IS-IS route on the ZXR10 8900E, perform the following steps:
1 ZXR10(config)#router isis [<process-id>][vrf <vrf-name>] Creates an IS-IS process ID.
2 ZXR10(config-isis-id)#interface <interface-name> Specifies the interface to be

enabled with BFD in IS-IS route
configuration mode.
3 ZXR10(config-isis-id-if-interface-name)#bfd-enable Enables BFD for the IS-IS

route.
You can enable BFD for the interface that uses the IS-IS protocol. When the IS-IS neighbor
relationship is established between this interface and the peer interface, a BFD session
based on the IS-SI protocol is generated on the link that connects these two interfaces
directly.
Configuring BFD Function for the BGP Route

To configure BFD for the BGP route on the ZXR10 8900E, perform the following steps:
1 ZXR10(config)#router bgp <as-number> Configures the BGP module for

the router.
2 ZXR10(config-bgp)#neighbor {<ipv4-address>|<ipv6-addr Configures the BFD link

ess>|<peer-group-name>} fall-over bfd detection function.
If the BGP neighbor is directly connected, configure a single-hop BFD detection mode; If
the BFP neighbor is not directly connected, configure a multihop BFD detection mode.
6-4

Configuring BFD Function for Interfaces Using the LDP Protocol

To configure BFD for interfaces using the LDP protocol on the ZXR10 8900E, perform the
following steps:
1 ZXR10(config)#mpls ldp instance <1-65535>[vrf Enables LDP, and enters LDP

<vrf-name>] configuration mode.
2 ZXR10(config-ldp)#bfd <FEC address><mask Configures the BFD function for the LSP
length> interval <interval> min-rx < min-rx> generated by the LDP protocol, and
multiplier <multiplier>[ source <ip-address>] creates a BFD session for the LSP.
The LDP BFD session only needs to be configured locally. During the configuration, a
reverse LDP BFD session is established automatically after you specify the address of the
remote LSP.
<FEC address> Specifies the LSP address that is used to establish a BFD session.
In general, it is a remote IP address.
<mask length> Specifies the length of the sub-net mask of the remote IP address,
range: 0-32.
<interval> Configures the expected minimum packet sending interval (ms),

range: 10-990.
<min_rx> Configures the expected minimum packet receiving interval (ms),

range: 10-990.
<multiplier> Packet detection multiplier, range: 3-50.
Configuring BFD for Interfaces Using the RSVP Protocol

To configure BFD Function for interfaces using the RSVP protocol on the ZXR10 8900E,
perform the following steps:
Command Function
ZXR10(config-mpls-te-if-interface-name)#b Enables BFD for interfaces in real-interface

fd mode of the MPLS-TE.
Configuring the RSVP LSP BFD

To configure the RSVP LSP BFD on the ZXR10 8900E, perform the following steps:
Command Function
ZXR10(config-mpls-te-tunnel-te_tunnel- Enables the tunnel LSP BFD function in tunnel

number)#tunnel mpls traffic-eng bfd interval interface mode of the MPLS-TE.
<interval> min-rx < min-rx > multiplier <multiplier>
6-5

<interval> Minimum sending interval (ms) of BFD control packets, range:

10-990.
<min-rx> Minimum receiving interval (ms) of BFD control packets, range:

10-990.
<multiplier> Detection multiplier of BFD control packets, range: 3-50.
Configuring the LOCAL/REMOTE Descriptor

To manually configure the LOCAL/REMOTE descriptor for a BFD session on the ZXR10
8900E, run the following command:
Command Function
ZXR10(config-bfd-l2-instance-name)#discri Configures the LOCAL/REMOTE descriptor for a

minator ld <ld> rd <rd> static BFD session manually.
<ld> Configures the local identifier for the BFD session, range: 1-2048.
<rd> Configures the remote identifier for the BFD session, range:
1-2048.
Configuring the Link BFD or Peer BFD Related to the VRRP

To configure the link BFD or peer BFD related to the VRRP on the ZXR10 8900E, perform
the following steps:
Command Function
ZXR10(config-samgr)#track <track-object-name> Configure a track object in SAMGR mode.

bfd session <bfd-session-name>
ZXR10(config-vrrp-if-interface-name)#vrrp Configures the VRRP detection event group,

<vrid> track {group | object}<string>{link-type | detection object, and policy type in VRRP
peer-type | priority-decrement <1-254>} interface configuration mode.
Configuring the VPWS BFD

To configure the VPWS BFD on the ZXR10 8900E, run the following command:
Command Function
ZXR10(config-vpws-vpws-name-pw-pw- Configures the VPWS BFD in VPWS configuration

number-neighbour-peer-router-id)#vccv bfd mode.
capability {basic | status} encapsulation {raw | ip}
6-6

Configuring the Detection Length for BFD Packets

To configure the detection for BFD packets on the ZXR10 8900E, run the following
commands:
Command Function
ZXR10(config-bfd)#session <session-name> Configures a BFD session in BFD configuration

link-bfd ipv4 | ipv6 < src-ip-address >< mode.
dst-ip-address > interface <interface-name>[vrf
<vrf-name>]
ZXR10(config-bfd-link-session-name)#pkt- Configures the detection length for BFD packets

len min <24-512> max <24-512> in BFD session configuration mode.
6.3 Maintaining BFD

To maintain BFD on the ZXR10 8900E, run the following commands:
Command Function
ZXR10#debug bfd packet Displays the brief information about sent or

received link establishment packets when a BFD
session is established.
ZXR10#debug bfd event Displays the status change information about

a BFD session when the BFD session is
established.
ZXR10#debug bfd byte Displays the information about sent and received
link establishment packets when a BFD session
is established (packets in the UDP data area).
ZXR10#show bfd neighbors ip detail Displays the detailed information about a BFD
session whose type is IP.
ZXR10#show bfd neighbors ip brief Displays the brief information about a BFD
session whose type is IP.
ZXR10#show bfd neighbors ldp brief Displays the brief information about a BFD
session whose type is LDP.
ZXR10#show bfd neighbors ldp detail Displays the detailed information about a BFD
ZXR10#show bfd neighbors rsvp {lsp | passive } brief Displays the brief information about a BFD
ZXR10#show bfd neighbors rsvp {lsp | passive } Displays the detailed information about a BFD
detail session whose type is RSVP.
ZXR10#show bfd neighbors pw brief Displays the brief information about a BFD
session whose type is PW.
6-7

Command Function
ZXR10#show bfd neighbors pw detail Displays the detailed information about a BFD
session whose type is PW.
ZXR10#show bfd neighbors local-disc Displays the detailed information about a BFD
session in accordance with the local disc.
6.4 BFD Configuration Examples

Configuring ISIS BFD
The IS-IS neighbor relationship is established between R1 and R2, and BFD is
enabled for interfaces of R1 and R2, see Figure 6-1.
Figure 6-1 ISIS BFD Configuration Example
1. Establish the IS-IS neighbor relationship between R1 and R2.
2. Enable BFD for interfaces of R1 and R2.
R1(config-if-vlan1)#ip address 172.20.130.213 255.255.255.0
R1(config-if-vlan1)#exit
R1(config)#router isis
R1(config-isis-0)#area 49.0172
R1(config-isis-0)#system-id 0020.0096.0001
R1(config-isis-0)#interface vlan1
R1(config-isis-0-if-vlan1)#ip router isis
R1(config-isis-0-if-vlan1)#bfd-enable
R1(config-isis-0-if-vlan1)#end

6-8

R2(config-isis-0-if-vlan2)#bfd-enable
Run the show bfd neighbors [ip brief | ip detail] command to check whether the
ISIS-BFD session is established successfully on R1. The execution result is
displayed as follows:
R1(config)#show bfd neighbors ip brief
LocalAddr PeerAddr LD RD Hold State interface
172.20.130.213 172.20.130.214 1 3 150 UP vlan1
R1(config)#show bfd neighbors ip detail

-----------------------------------------------------------------------
LocalAddr:172.20.130.213
PeerAddr :172.20.130.214
Local Discr:1 Remote Discr:3 State:UP
Holdown(ms):150 Interface: vlan1
Vpnid:0 VRF Name:---
BFD Type:SingleHop
Instance Name:
-------------------------------------------------------------------------
Version:1 Dest UDP Port:3784 Final Bit:1
Local Diag:0 Demand Mode:0 Poll Bit:1
MinTxInt:50 MinRxInt:50 Multiplier:3
Received MinTxInt:50 Received MinRxInt:50 Received Multiplier:3
Length:24 Min Echo Interval:0
Min BFD Length:24 Max BFD Length:24
Registered Protocols:ISIS
Uptime:0 day(s),0 hour(s),0 minute(s)
Control Plane Rcv Phy Interface Name: vlan1
==========================================================================
Configuring OSPF BFD

The OSPF neighbor relationship is established between R1 and R2, and BFD is
enabled for interfaces of R1 and R2, see Figure 6-2.
6-9

Figure 6-2 OSPF BFD Configuration Example
1. Establish the OSPF neighbor relationship between R1 and R2.
2. Enable the BFD function for interfaces of R1 and R2.
R1(config)#router ospf 1
R1(config-ospf-1)#network 172.20.130.0 0.0.0.255 area 0.0.0.0
R1(config-ospf-1)#bfd area 0
R1(config-ospf-1)#end

R2(config-ospf-1)#bfd area 0
Run the show bfd neighbors [ip brief | ip detail] command to check whether the OSPF
BFD session is established successfully on R1. The execution result is displayed as
follows:
LocalAddr PeerAddr LD RD Hold State Interface
172.20.130.213 172.20.130.214 3 3 150 UP vlan1

-------------------------------------------------------------------------
LocalAddr:172.20.130.213
PeerAddr :172.20.130.214

6-10

BFD Type:SingleHop
Instance Name:
------------------------------------------------------------------------
Registered Protocols:OSPF
==========================================================================
Configuring RIP BFD

The BFD function is enabled in RIP mode, see Figure 6-3.
Figure 6-3 RIP BFD Configuration Example
1. Configure the IP address for the interfaces of R1 and R2.
2. Configure the RIP protocol
3. Enable the configuration related to the RIP protocol for the interfaces.
4. Test the configuration result to confirm that the neighbor relationship is established
between two devices and the notify route can be learnt from each other.
5. Enable the BFD function in RIP mode.
R1(config)#router rip
R1(config-rip)#network 192.168.1.0 0.0.0.255
R1(config-rip)#bfd
R1(config-rip)#exit
6-11


R2(config)#router rip
R2(config-rip)#bfd
R2(config-rip)#end
After the above configuration, when the following information is displayed on both
ends of the device, it means that the neighbor relationship is successfully established
between two parties, and the route of the peer end can be successfully learnt and
pinged.
Run the show running-config rip command to check whether the RIP configuration is
correct on R1. The execution result is displayed as follows:
R1(config-rip)#show running-config rip
!<rip>
router rip
bfd
network 192.168.1.0 0.0.0.255
network 10.1.0.0 0.0.0.255
$
!</rip>
R1(config)#show ip rip database

Routes of rip:
h : is possibly down,in holddown time
f : out holddown time before flush
Dest Metric RtPrf InstanceID Time From

*> 10.0.0.0/8 2 120 0 00:00:12 192.168.1.2
* 10.1.0.0/24 1 254 0 00:00:29 0.0.0.0
*> 192.0.0.0/8 0 0 0 00:00:00 0.0.0.0
*> 192.168.1.0/24 0 0 0 00:00:00 0.0.0.0
R1(config)#show ip rip neighbors

neighbor address interface
192.168.1.2 vlan1
6-12


192.168.1.1 192.168.1.2 2052 2053 150 UP vlan1

----------------------------------------------------------------------------
LocalAddr: 192.168.1.1
PeerAddr : 192.168.1.2
BFD Type:SingleHop
Instance Name:
----------------------------------------------------------------------------
Registered Protocols:RIP
==========================================================================
Run the show running-config rip command to check whether the RIP configuration is
correct on R2. The execution result is displayed as follows:
R2(config)#show running-config rip
!<rip>
router rip
bfd
network 192.168.1.0 0.0.0.255
network 10.2.0.0 0.0.0.255
$
!</rip>
R2(config)#show ip rip database

Routes of rip:
h : is possibly down,in holddown time
f : out holddown time before flush
Dest Metric RtPrf InstanceID Time From

*> 10.0.0.0/8 1 254 0 00:00:03 0.0.0.0
*> 10.2.0.0/24 0 0 0 00:00:00 0.0.0.0
6-13

*> 192.168.1.0/24 0 0 0 00:00:00 0.0.0.0
R2(config)#show ip rip neighbors

neighbor address interface
192.168.1.1 vlan1
R2(config-rip)#show bfd neighbors ip brief

192.168.1.2 192.168.1.1 2053 2052 150 UP vlan1

----------------------------------------------------------------------------
PeerAddr : 192.168.1.1
BFD Type:SingleHop
Instance Name:
------------------------------------------------------------------------
Registered Protocols:RIP
==========================================================================
Configure a Single-hop BFD for the BGP Route

The BGP neighbor relationship is established between R1 and R2, and the BFD
function is enabled for R1 and R2, see Figure 6-4.
Figure 6-4 Configuring a Single-hop BFD for the BGP Route
6-14

1. Establish the BGP neighbor relationship between R1 and R2.
2. Enable the BFD function for interfaces of R1 and R2.
R1(config)#router bgp 18004

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


R2(config-bgp)#exit
Run the show bfd neighbors [ip brief | ip detail] command to check whether the BGP
BFD session is established successfully on R1. The execution result is displayed as
follows:
R1(config-bgp)#show bfd neighbors ip brief
172.20.130.213 172.20.130.214 4 25 150 UP vlan1
R1(config-bgp)#show bfd neighbors ip detail

---------------------------------------------------------------------------
LocalAddr:172.20.130.213
PeerAddr :172.20.130.214

BFD Type:SingleHop
Instance Name:
----------------------------------------------------------------------------
6-15


Registered Protocols:BGP
==========================================================================
Configuring a Multihop-BFD for the BGP Route

When a remote link becomes invalid, the local end can detect the remote link fault
quickly with the BFD function. For the configuration example of a multihop-BFD, see
Figure 6-5.
Figure 6-5 Configuring a Multihop-BFD for the BGP Route
1. Configure the protocol for each route.
2. Enable the BFD function in protocol interface mode or for the specific destination
route.
R1(config)#interface loopback1
R1(config-if-loopback1)#ip address 1.1.1.211 255.255.255.255
R1(config-if-loopback1)#exit
R1(config-ospf-1)#network 100.1.1.0 0.0.0.255 area 0
R1(config-ospf-1)#exit

R1(config-bgp)#neighbor 1.1.1.213 remote 200
R1(config-bgp)#neighbor 1.1.1.213 update-source loopback1
6-16

R1(config-bgp)#neighbor 1.1.1.213 ebgp-multihop

R1(config)#bfd
R1(config-bfd)#session 1 peer-bfd ipv4 1.1.1.211 1.1.1.213
R1(config-bfd)#exit



R3(config-bgp)#neighbor 1.1.1.211 remote 100
R3(config-bgp)#neighbor 1.1.1.211 ebgp-multihop
R3(config)#bfd
R3(config-bfd)#exit
Run the show bfd neighbors [ip brief | ip detail ] command to check whether the BFD
session is established successfully on R1. The execution result is displayed as
follows:
R1#show bfd neighbors ip brief
6-17


1.1.1.211 1.1.1.213 56 57 150 UP vlan1
R1#show bfd neighbors ip detail

----------------------------------------------------------------------------
LocalAddr:1.1.1.211
PeerAddr :1.1.1.213
Local Discr: 56 Remote Discr:57 State:UP
Holdown(ms):150 Interface:---
BFD Type:MultiHop
Instance Name:1
----------------------------------------------------------------------------
Registered Protocols:BGP INSTANCE

Control Plane Rcv Phy Interface Name:vlan1
==========================================================================
Configuring BFD for a Static Route

The static route relationship is established between R1 and R2, and the static route
of R1 and R2 is enabled with the BFD function, see Figure 6-6.
Figure 6-6 Configuring a Static Route BFD
1. Run the static route protocol between R1 and R2.
2. Configure the BFD function for the static route of R1 and R2.
6-18

R1(config)#ip route 172.20.108.1 255.255.255.255 172.20.130.214 bfd enable

R2(config)#ip route 172.20.96.1 255.255.255.255 172.20.130.213 bfd enable
Run the show bfd neighbors [ip brief | ip detail] command to check whether the static
route BFD session is establish successfully on R1. The execution result is displayed
as follows:
172.20.130.213 172.20.130.214 5 32 150 UP vlan1

---------------------------------------------------------------------------
LocalAddr: 172.20.130.213
PeerAddr : 172.20.130.214
BFD Type:SingleHop
Instance Name:
----------------------------------------------------------------------------
Registered Protocols: STATIC

6-19


==========================================================================
Configuring PIM BFD

The BFD function is enabled in PIM interface configuration mode, see Figure 6-7.
Figure 6-7 Configuring PIM BFD
1. Configure the IP address for the corresponding interfaces.
2. Enter multicast configuration mode.
3. Enter PIM configuration mode.
4. Set the loopback5 interface of R2 to CRP and BSR.
5. Enter PIM-SM interface configuration mode.
6. Enable the BFD function in PIM-SM interface configuration mode.
R1(config)#ip multicast-routing
R1(config-mcast)#router pim
R1(config-mcast-pim)#interface vlan1
R1(config-mcast-pim-if-vlan1)#pimsm
R1(config-mcast-pim-if-vlan1)#bfd-enable
R1(config-mcast-pim-if-vlan1)#exit
R1(config-mcast-pim-if-vlan2)#dr-priority 20

6-20


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

----------------------------------------------------------------------------
PeerAddr : 199.1.1.2
6-21


BFD Type:SingleHop
Instance Name:
----------------------------------------------------------------------------
Registered Protocols:PIM
==========================================================================
Run the show ip pim neighbor command to check the neighbor status on R2. The
R2(config)#show ip pim neighbor
Neighbor Address Interface DR Priority Uptime Expires Ver
199.1.1.1 vlan1 1 00:07:48 00:01:23 V2
Run the show bfd neighbor ip brief command to check the BFD status on R2. The
R2(config)#show bfd neighbor ip brief
199.1.1.2 199.1.1.1 2055 2054 150 UP vlan1
RP3(config)#show bfd neighbor ip detail

----------------------------------------------------------------------------
PeerAddr : 199.1.1.1
BFD Type:SingleHop
Instance Name:
----------------------------------------------------------------------------
Registered Protocols:PIM
6-22


==========================================================================
Configuring LDP BFD

The LDP neighbor between two devices is established successfully and the version of
both ends of the BFD is the same. To create a BFD session successfully, it is required
to set one end of one device to the active party of the BFD and the other end to the
standby party of the BFD in LDP configuration mode, see Figure 6-8.
Figure 6-8 Configuring the LDP BFD
1. Enable the LDP function for R1 and R2.
2. Set the IP address of the loopback interface as the ID of the LSR.
3. Enable the MPLS hop-by-hop forwarding function for the link between R1 and R2.
4. The LDP BFD configuration is performed on one end. Set R1 as the active party,
and configure the LDP BFD session for R1.
R1(config)#mpls ldp instance 1

R1(config-ldp-1)#router-id loopback1
R1(config-ldp-1)#interface vlan1
R1(config-ldp-1-if-vlan1)#exit
R1(config-ldp-1)#bfd 172.20.108.1 32 interval 50 min_rx 50 multiplier 3
6-23



Run the show bfd neighbors [ldp brief | ldp detail] command on R1 to check whether
the LDP BFD session is established successfully. The execution result is displayed
as follows:
R1(config)#show bfd neighbors ldp brief
PeerAddr PrefixLen LD RD Hold State
172.20.108.1 32 6 34 150 UP
R1(config)#show bfd neighbors ldp detail

PeerAddr :172.20.108.1
Prefixlen:32
Holdown(ms):150 Vpnid:0 VRF Name:--

BFD Type:LDP[Active]
Instance Name:
----------------------------------------------------------------------------
Registered Protocols:LDP LSP

==========================================================================
6-24

Configuring PEER BFD

The LDP neighbor relationship is established between R1 and R2, and the PEER BFD
configuration instance is configured, see Figure 6-9.
Figure 6-9 Configuring the PEER BFD
1. Configure the IGP function for R1 and R2 in loopback interface mode.
2. Enable the MPLS function for the interfaces that connect R1 and R2 directly.
3. Set the IP address of the Loopback interface to the ID of the LSR.
4. Enable PEER BFD.
R1(config-if-vlan10/7)#exit
R1(config)#router isis 1
R1(config-isis-1-if-vlan1)#exit
R1(config-isis-1)#interface loopback1
R1(config-isis-1-if-loopback1)#ip router isis
R1(config-isis-1-if-loopback1)#exit
R1(config-isis-1)#exit

/*Configuring the Router-ID and interface for the LDP*/
R1(config-ldp-1)#peer bfd remote-routerid 1.1.1.35
R1(config-ldp-1)#exit
6-25

R1(config)#bfd
R1(config-bfd)#exit

R2(config-isis-1)#interface loopback1
R2(config-isis-1-if-loopbck1)#ip router isis
R2(config-isis-1-if-loopbck1)#exit
R2(config-isis-1)#exit

R2(config-ldp-1)#peer bfd remote-routerid 1.1.1.34
R2(config)#bfd
R2(config-bfd)#exit
Note:
In the above configuration, the purpose of running the IS-IS dynamic route protocol is
to notify the Route-id, that is the route of the Loopback interface, of each LSR.
When the address of the loopback interface is set as the route-id of the LDP instance,
it is good for the steady operation of the LDP ID because the address status of the
loopback interface cannot change (except that you disable this interface manually).
6-26

Run the following commands to check the establishment of the LDP neighbor on R2:
R2(config)#show mpls ldp neighbor detail instance 1
Peer LDP Ident: 1.1.1.34:0; Local LDP Ident 1.1.1.35:0
TCP connection: 1.1.1.34.646 - 1.1.1.35.1069
state: Oper; Msgs sent/rcvd: 47/48; Downstream
Up Time: 00:00:30
LDP discovery sources:
vlan1; Src IP addr: 100.100.100.1
holdtime: 15000 ms, hello interval: 5000 ms
Addresses bound to peer LDP Ident:
2.2.2.34 3.3.3.34 1.1.1.34 10.1.1.2
40.1.1.1 192.12.1.1 192.11.1.1 100.1.1.1
184.1.1.34 16.1.1.1 16.1.1.2 192.2.1.1
100.100.100.1
Session holdtime: 180000 ms; KA interval: 60000 ms
LDP Peer BFD not register.
LDP dynamic capability enable:
LDP send capability:
LDP dynamic capability
LDP Typed Wildcard FEC Cap
LDP Unrecognized Noti Cap
LDP received capability:
LDP dynamic capability negotiate success
LDP Typed Wildcard FEC Cap negotiate success
LDP Unrecognized Noti Cap negotiate success
If the session is in Oper (state: Oper) status, it means that the parameter negotiation
is correct and the neighbor relationship with R1 (1.1.1.34) is established successfully.
Run the following commands to check the PEER BFD neighbor on R1. The execution
result is displayed as follows:
R1(config-ldp-1)#show bfd neighbors ip brief
1.1.1.34 1.1.1.35 2087 2085 150 UP --
R1(config-ldp-1)#show bfd neighbors ip detail

----------------------------------------------------------------------------
LocalAddr:1.1.1.34
PeerAddr :1.1.1.35
BFD Type:MultiHop
Instance Name:1
6-27

----------------------------------------------------------------------------
Registered Protocols:LDP INSTANCE

==========================================================================
Configuring the Static Single-Hop BFD

At present, the static single-hop BFD and static multihop BFD are not related to
the route. The difference is that the static single-hop BFD must be configured with
outgoing interfaces and the static multihop BFD is configured with no outgoing
interface. The static single-hop BFD configured for R1 has no relationship with the
route, but the BFD function is configured for the static route of R2, see Figure 6-10.
Figure 6-10 Configuring the Static Single-Hop BFD
1. Configure the static single-hop BFD for R1.
2. Configure the static single-hop BFD for R2.
R1(config-if-vlan1)#no shutdown
R1(config)#bfd
R1(config-bfd)#session test link-bfd ipv4 172.20.130.213 172.20.130.214
interface vlan1
R1(config-bfd-link-test)#!
6-28


R2(config)#ip route 172.20.96.1 255.255.255.255 vlan2 172.20.130.213
bfd enable/*The static single-hop BFD must be configured with outgoing interfaces*/
single-hop BFD configuration on R1 takes effect. The execution result is displayed as
follows:
172.20.130.213 172.20.130.214 1 58 150 UP vlan1

LocalAddr:172.20.130.213
PeerAddr :172.20.130.214

BFD Type:SingleHop
Instance Name:test
----------------------------------------------------------------------------
Registered Protocols:INSTANCE
==========================================================================
Run the show bfd neighbors ip brief command to check whether the single-hop BFD
function is configured for the static route of R2. The execution result is displayed as
follows:
6-29

LocalAddr PeerAddr LD RD Hold State interface

172.20.130.214 172.20.130.213 58 1 150 UP vlan2

-----------------------------------------------------------------------------
LocalAddr:172.20.130.214
PeerAddr :172.20.130.213

BFD Type:SingleHop
Instance Name:
----------------------------------------------------------------------------
Registered Protocols:STATIC
==========================================================================
Configuring the Static MultiHop BFD

At present, the static single-hop BFD and static multihop BFD are not related to
the route. The difference is that the static single-hop BFD must be configured with
outgoing interfaces and the static multihop BFD is configured with no outgoing
interface. The static multihop BFD configured for R1 has no relationship with the
route, but the BFD function is configured for the BGP route of R3, see Figure 6-11.
Figure 6-11 Configuring the Static MultiHop BFD
1. Configure the static multihop BFD for R1.
2. Configure the multihop BFD for the BGP route of R3.
6-30

R1(config-if-vlan 1)#no shutdown
R1(config-if-vlan 1)#ip address 172.20.130.18 255.255.255.0
R1(config-if-vlan 1)#exit

R1(config-bgp)#exit
R1(config)#bfd
R1(config-bfd)#session test peer-bfd ipv4 172.20.96.1 172.20.108.2
R1(config-bfd-session-test)#end


6-31


R3(config-bgp)#exit
R3(config-bfd)#session test peer-bfd ipv4 172.20. 108.2 172.20.96.1

R3(config-bfd-session-test)#end
multihop BFD is configured for R1. The execution result is displayed as follows:

172.20.96.1 172.20.108.2 6 1 150 UP ---

----------------------------------------------------------------------------
PeerAddr : 172.20.108.2
Vpnid:0 VRF Name:
BFD Type:MultiHop
Instance Name:test
----------------------------------------------------------------------------
6-32

Registered Protocols:INSTANCE
Control Plane Rcv Phy Interface Name:
==========================================================================
Run the show bfd neighbors ip brief command to check whether the multihop BFD
function is configured for the BGP route of R3. The execution result is displayed as
follows:
172.20.108.2 172.20.96.1 1 6 150 UP -----

----------------------------------------------------------------------------
LocalAddr:172.20.108.2
PeerAddr :172.20.96.1
BFD Type:MultiHop
Instance Name: test
----------------------------------------------------------------------------
Registered Protocols:BGP INSTANCE

==========================================================================
Configuring BFD for the RSVP Interface

The ISIS-TE tunnel is established between R1 and R2, and the BFD function is
enabled for the RSVP-TE interfaces of R1 and R2, see Figure 6-12.
6-33

Figure 6-12 Configuring the BFD Function for the RSVP Interface
1. Establish the ISIS-TE tunnel between R1 and R2.
2. Enable the BFD function for interfaces of R1 and R2 in TE mode.
R1(config-isis-0)#metric-style wide
R1(config-isis-0)#mpls traffic-eng level-2
R1(config)#interface te_tunnel1
R1(config-if-te_tunnel1)#ip unnumbered loopback1
R1(config-if-te_tunnel1)#exit
R1(config)#mpls traffic-eng
R1(config-mpls-te)#interface loopback1
R1(config-mpls-te-if-loopback1)#exit
R1(config-mpls-te)#router-id 172.20.96.1
R1(config-mpls-te)#tunnel te_tunnel 1
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel destination ipv4 172.20.108.1
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng
path-option 1 dynamic
R1(config-mpls-te-tunnel-te_tunnel1)#exit
R1(config-mpls-te)#interface vlan1
R1(config-mpls-te-if-vlan1)#bfd
6-34

R2(config-isis-0)#metric-style wide
R2(config-isis-0)#mpls traffic-eng level-2
R2(config-mpls-te-if-vlan2)#bfd
Run the show bfd neighbors [ip brief | ip detail] command to check whether the BFD
function is configured for the RSVP interface of R1. The execution result is displayed
as follows:

172.20.130.213 172.20.130.214 8 1 150 UP vlan1

-------------------------------------------------------------
LocalAddr:172.20.130.213
PeerAddr :172.20.130.214

BFD Type:SingleHop
Instance Name:
----------------------------------------------------------------------------
6-35


Registered Protocols:RSVP
==========================================================================
Configuring RSVP LSP BFD

The RSVP LSP BFD uses the BFD function to detect the LSP of the RSVP tunnel.
When the hotstandby function is configured for the tunnel and the invalid LSP acts as
the active LSP, the tunnel traffic must be switched over to the standby LSP, see Figure
6-13.
Figure 6-13 Configuring the RSVP LSP BFD
1. Enable the OSPF-TE function among R1, R2, and R3.
2. Configure the hotstandby tunnel (R1-R3-R2) on R1, and then enable the BFD
function for this tunnel.
6-36



R1(config-ospf-100)#mpls traffic-eng area 0
R1(config)#interface te_tunnel1
R1(config-if-te_tunnel1)#ip unnumbered loopback10
R1(config-if-te_tunnel1)#exit
R1(config-mpls-te-if-vlan3)#exit
R1(config-mpls-te)#tunnel te_tunnel1
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel destination ipv4 10.10.10.2
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng path-option 1
explicit-path identifier 1
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng record-route
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng hot-standby
protect 1 dynamic
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng bfd interval 30
min-rx 30 multiplier 5
R1(config-mpls-te-tunnel-te_tunnel1)#exit
R1(config-mpls-te)#explicit-path identifier 1
R1(config-mpls-te-expl-path-id-1)#next-address strict 54.1.1.3
R1(config-mpls-te-expl-path-id-1)#next-address strict 115.1.1.2

6-37



un the following commands on R3:


6-38

After the above configuration, the tunnel1 of R1 is in up status, and a hotstandby
tunnel is generated. The hotstandby relationship is ready, and the RSVP LSP BFD
session on R1 should be established successfully. When the link between R2 and
R3 becomes invalid, the status of the LSP BFD session becomes down and then up
again, and the traffic is switched to the hotstandby tunnel.
Run the show bfd neighbors [rsvp lsp brief | rsvp lsp detail] command to check whether
the BFD function is configured for the RSVP interface.
The tunnel1 of R1 is in up status.
R1(config)#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
tunnel_1 10.10.10.2 - vlan3 up/up
tunnel_1(hot) 10.10.10.2 - vlan1 up/up
R1#show mpls traffic-eng fast-reroute

Tunnel head end item information
Protected Tunnel LspID In-label Out intf/label FRR intf/label Status
Tunnel1 9 Tun hd vlan1:14745 Tu1:3 ready
6
LSP midpoint frr information:

LSP identifier In-label Out intf/label FRR intf/label Status
R1#show mpls traffic-eng tunnels hot-standby

Name: tunnel_1 (Tunnel1) Destination: 10.10.10.2
Status:
Admin: up Oper: up Path: valid Signalling: connected
Fast Reroute Protection: None
Hot-standby Protection: Ready
InLabel: -
OutLabel: vlan1, 3
RSVP Signalling Info :
Src 10.10.10.1, Dst 10.10.10.2, Tun_Id 1, Tun_Instance 10
RSVP Path Info:
Explicit Route: 57.1.1.1 57.1.1.2 10.10.10.2
Exclude Route: 10.10.10.3 115.1.1.2
Record Route: NULL
Tspec: ave rate= 0 kbits, burst= 1000 bytes, peak rate= 0 kbits
RSVP Resv Info:
6-39

Record Route: 10.10.10.2 57.1.1.2

Fspec: ave rate= 0 kbits, burst= 1000 bytes, peak rate= 0 kbits
Run the show bfd neighbors rsvp lsp brief command to check whether the BFD function
is configured for the RSVP interface of R1. The execution result is displayed as
follows:
R1#show bfd neighbors rsvp lsp brief
TunnelId LspId LD RD Hold State
te_tunnel1 16 33053 2662 150 UP
R1#show bfd neighbors rsvp lsp detail

-----------------------------------------------
TunnelId:te_tunnel1
LspId:16
LspRole:master
Holddown(ms):150 BFD Type:RSVP LSP[Active]
Instance Name:
---------------------------------------------------
Local Diag: 0 Demand Mode:0 Poll Bit:0
MinTxInt: 50 MinRxInt:50 Multiplier:3
Received MinTxInt: 10 Received MinRxInt:10 Received Multiplier:3
Registered Protocols:RSVP LSP

==========================================================================
/*When the link between R3 and R2 becomes invalid, the hotstandby relationship of the tunnel is i
R1#show mpls traffic-eng fast-reroute
Protected Tunnel LspID In-label Out intf/label FRR intf/label Status
Tunnel1 9 Tun hd vlan2:14745 Tu1:3 active
6
R1#show mpls traffic-eng tunnels hot-standby
Name: tunnel_1 (Tunnel1) Destination: 10.10.10.2
Status:
Admin: up Oper: up Path: valid Signalling: connected
Fast Reroute Protection: None
Hot-standby Protection: Backup lsp in use
6-40

R1(config)#show bfd neighbors rsvp lspbrief

TunnelId/PeerAddr LD RD Hold State
te_tunnel1 11 71 150 DOWN
Configuring the Link BFD Relating to the VRRP

The link BFD function relating to the VRRP is configured for R1 and R2, see Figure
6-14.
Figure 6-14 Configuring the Link BFD Relating to the VRRP
1. Configure the track object for R1 and R2 in SAMGR mode.
2. Relate this object on R1 and R2 in VRRP configuration mode.
R1(config)#samgr
R1(config-samgr)#track 1 bfd session bfd
R1(config)#vrrp
R1(config-vrrp-if-vlan1)#vrrp 1 track object 1 link-type
R1(config-vrrp-if-vlan1)#exit
R1(config-vrrp)#exit

R2(config)#samgr
R2(config-samgr)#track 1 bfd session bfd
R2(config)#vrrp
R2(config-vrrp-if-vlan2)#vrrp 1 track object 1 link-type
R2(config-vrrp-if-vlan2)#exit
R2(config-vrrp)#exit
Run the show vrrp interface command to check whether the link BFD is configured on
R1. The execution result is displayed as follows:
R1 (config)#show vrrp interface vlan1
6-41

vlan1 - vrID 1
Advertise time is 1.000 (s)
Preemption enable, delay 0 (s)
Reload delay 0 (s)
No authentication data
Check ttl enable
Out-interface send-mode is all
Interface State Policy Reduce-Priority
Track name: 1 Track type: object Detect type: bfd
Policy type: link
Track state: unknown
Admin-group is None
Vrrp run info:
State is Init
Master Advertisement interval is 0.000 (s)
Master Down interval is 3.609 (s), no learn
Run the show vrrp interface command to check whether the link BFD is configured on
R2. The execution result is displayed as follows:
R2 (config)#show vrrp interface vlan2
vlan2 - vrID 1
Advertise time is 1.000 (s)
Preemption enable, delay 0 (s)
Reload delay 0 (s)
No authentication data
Check ttl enable
6-42


Out-interface send-mode is all
Interface State Policy Reduce-Priority
Track name: 1 Track type: object Detect type: bfd
Policy type: link
Track state: unknown
Admin-group is None
Vrrp run info:
State is Init
Master Advertisement interval is 0.000 (s)
Master Down interval is 3.609 (s), no learn
Configuring VPWS BFD

R1 and R2 are configured with the VPWS instance, and the BFD function is enabled
on R1 and R2 in VPWS configuration mode, see Figure 6-15.
Figure 6-15 Configuring the VPWS BFD
1. Configure the VPWS instance for R1 and R2.
2. Enable the BFD function for R1 and R2 in VPWS configuration mode.
6-43



R1(config-ldp-1-vlan1)#exit
R1(config)#pw pw1
R1(config)#vpws vpws-bfd
R1(config-vpws-vpws-bfd)#access-point vlan2
R1(config-vpws-vpws-bfd-ac-vlan2)#access-params ethernet
R1(config-vpws-vpws-bfd-ac-vlan2-eth)#exit
R1(config-vpws-vpws-bfd-ac-vlan2)#exit
R1(config-vpws-vpws-bfd)#pseudo-wire pw1
R1(config-vpws-vpws-bfd-pw-pw1)#neighbour 100.1.1.3 vcid 1
R1(config-vpws-vpws-bfd-pw-pw1-neighbour-100.1.1.3)#vccv bfd capability
basicencapsulation ip
R1(config-vpws-vpws-bfd-pw-pw1-neighbour-100.1.1.3)#exit
R1(config-vpws-vpws-bfd-pw-pw1)#exit
R1(config-vpws-vpws-bfd)#exit
R1(config)#bfd
R1(config-bfd)#session pw-bfd pw-bfd pw-name pw1
R1(config-bfd-pw-pw-bfd)#exit
R1(config-bfd)#exit


6-44

R2(config)#pw pw1
R2(config)#vpws vpws-bfd
R2(config-vpws-vpws-bfd)#access-point vlan4
R2(config-vpws-vpws-bfd-ac-vlan4)#access-params ethernet
R2(config-vpws-vpws-bfd-ac-vlan4-eth)#exit
R2(config-vpws-vpws-bfd-ac-vlan4)#exit
R2(config-vpws-vpws-bfd)#pseudo-wire pw1
R2(config-vpws-vpws-bfd-pw-pw1)#neighbour 100.1.1.2 vcid 1
R2(config-vpws-vpws-bfd-pw-pw1-neighbour-100.1.1.2)#vccv bfd capability basic
encapsulation ip
R2(config-vpws-vpws-bfd-pw-pw1-neighbour-100.1.1.2)#exit
R2(config-vpws-vpws-bfd-pw-pw1)#exit
R2(config-vpws-vpws-bfd)#exit
R2(config)#bfd
R2(config-bfd)#session pw-bfd pw-bfd pw-name pw1
R2(config-bfd-pw-pw-bfd)#exit
R2(config-bfd)#exit
Run the show l2vpn forwardinfo vpnname command to check whether the VPWS
instance is configured and the show bfd neighbors pw brief command to check whether
the VPWS BFD function is configured on R1. The execution result is displayed as
follows:
R1(config)#show l2vpn forwardinfo vpnname vpws-bfd
Headers: PWType - Pseudowire type and Pseudowire connection mode
Llabel - Local label, Rlabel - Remote label
VPNowner - owner type and instance name
Codes : H - HUB mode, S - SPOKE mode, L - VPLS, W - VPWS, M - MSPW
$pw - auto_pw
PWName PeerIP FEC PWType State Llabel Rlabel VPNowner
pw1 100.1.1.3 128 Ethernet UP 81922 81921 W:vpws-bfd
R1(config)#show bfd neighbors pw brief

Pwname LD RD Hold State
pw1 33233 2981 150 UP
Run the show l2vpn forwardinfo vpnname command to check whether the VPWS
instance is configured and the show bfd neighbors pw brief command to check whether
the VPWS BFD function is configured on R2. The execution result is displayed as
follows:
R2(config)#show l2vpn forwardinfo vpnname vpws-bfd
6-45


Codes : H - HUB mode, S - SPOKE mode, L - VPLS, W - VPWS, M - MSPW
$pw - auto_pw
PWName PeerIP FEC PWType State Llabel Rlabel VPNowner
pw1 100.1.1.2 128 Ethernet UP 81921 81922 W:vpws-bfd
R2(config)#show bfd neighbors pw brief
Pwname LD RD Hold State
pw1 2981 33233 150 UP
6-46

Chapter 7
FRR Configuration
Table of Contents
IP FRR Configuration .................................................................................................7-1
L2 VPN FRR Configuration ........................................................................................7-9
L3 VPN FRR Configuration ......................................................................................7-14
TE FRR Configuration ..............................................................................................7-24
7.1 IP FRR Configuration

7.1.1 IP FRR Overview
Introduction to IP FRR
When a link or a node in the network becomes invalid, the packet passing through the
invalid nodes to the destination may be dropped or cause loops. Therefore, transient flow
interruption or traffic loopback is inevitable in network until the network calculates out the
new topology and routes. The interruption duration is about a few seconds. At present,
some new technologies in the switch field can shorten the convergence time within one
second.
With the development of Internet technologies and applications of different complicated
services, some applications (such as voice and video) are extremely sensitive to the traffic
interruption. Once the network is not steady, there will be serious effect to those services.
When a node becomes invalid, the rapid recovery of traffic is very important. At present, the
communication industry considers that the network convergence period has three levels,
including:
l Sub-Second: It is the requirement of most IP networks.
l Sub-500ms: It is an objective that can be reached.
l Sub-50ms: This is a business requirement for some specified parts in the IP network.
The convergence time normally is cost in the following aspects:
1. The time that is used to discover invalid nodes and links. The detection time is tens of
milliseconds for an invalid physical link. The detection time is dozens of seconds for
invalidations in protocol plane.
2. The time that is used to notice the invalid event to the control plane of a switch. It costs
several milliseconds to tens of milliseconds.
3. The time that is used to take the corresponding responses to the invalid node and
link. The response includes triggering and flooding the new link state, and updating
packets. Usually it is several milliseconds to tens of milliseconds.
7-1

4. The time that is used to notice other nodes in network that the local switch link is invalid.
Usually it is tens of milliseconds to a hundred seconds normally on each node.
5. The time that is used to recalculate the triggering route. For Interior Gateway Protocol
(IGP) protocols that use Dijkstra algorithm, the time is tens of milliseconds.
6. The time that is used to interact with line interface cards to calculate the new routing
information and form the new forwarding table. The time varies in accordance with the
number of routing entries. Usually it is several hundred milliseconds.
7. The time that is used to load the new forwarding route entries into hardware. Usually
it is tens of milliseconds.
The traffic loss may occur in the above mentioned steps. The traffic loss can be divided
into two stages, including:
1. Stage 1: The switch fails to discover the invalid link immediately, and it still forwards
the traffic to the invalid link.
2. Stage 2: The route discovers the invalid link, but the network is in convergence
process. The local forwarding table is different with that of other switches, which
causes micro-loop in forwarding plane.
To shorten the traffic interruption duration, a mechanism must be provided to implement
the following functions:
1. Discover the invalid link quickly.
2. When the link is invalid, provide a recovery path quickly.
3. Prevent forwarding micro-loop during the further recovery process.
This mechanism is the IP Fast-Reroute (FRR).
IP FRR Principle
The working procedure of IP FRR is as follows:
1. Detect faults quickly: The common technologies include BFD, and physical signal test.
2. Modify the forwarding plane: Hand over the traffic to the recalculated backup path.
3. Perform route re-convergence.
4. After finishing the re-convergence, hand over the route to the optimal path.
Obviously, the backup path is to fill the FRR gap up, which hands over the traffic to the
backup next hop, to guarantee that the service will not be interrupted.
There are some conditions to form the OSPF FRR or IS-IS FRR relationship. To form
the FRR relationship of default LFAs test mode, the algorithm should meet the condition
Distance_opt (Ni, D) < Distance_opt (Ni, S) + Distance (S, D). That is, the distance from
the next hop on the backup link to the destination should be shorter than the sum of the
distance from the next hop on the backup link to the source node and the distance from
the source node on the primary link to the destination node.
To form the FRR relationship of down-stream-path mode, the algorithm should meet the
condition Distance_opt (Ni, D) < Distance (S, D). That is, the distance from the next hop
on the backup link to the destination should be shorter than that from the source node on
the primary link to the destination node.
7-2

Chapter 7 FRR Configuration
The establishment of BGP FRR relationship is relatively simpler. It only needs two different
next hops to the same destination.
7.1.2 Configuring IP FRR

Configuring OSPF FRR
To configure the OSPF FRR on the ZXR10 8900E, perform the following steps:
1 ZXR10(config)#router ospf <process-id>[ vrf < vrf-name>] Enters OSPF route

configuration mode.
2 ZXR10(config-ospfv2)#fast-reroute alternate-protect-type Configures the route

{ default| down-stream-path} backup mode, default and
down-stream-path.
ZXR10(config-ospfv2)#interface < interface-name> Enters protocol interface

configuration mode.
ZXR10(config-ospfv2-if)#fast-reroute [backup-interf Configures the OSPF FRR

ace <interface-name>] recalculation type.
Configuring IS-IS FRR

To configure the IS-IS FRR on the ZXR10 8900E, perform the following steps:
1 ZXR10(config)#router isis [ vrf <vrf-name>] Enters IS-IS configuration

mode.
2 ZXR10(config-isis)#fast-reroute enable Enables the IS-IS FRR function.
3 ZXR10(config-isis)#fast-reroute alternate-protect-type Changes the IS-IS FRR

down-stream-path calculation mode from
default mode (LFAs mode) to
down-stream-path.
Run the no fast-reroute
alternate-protect-type command
to restore the default LFAs
mode.
4 ZXR10(config-isis)#interface < interface-name> Enters protocol interface

configuration mode.
5 ZXR10(config-isis-if)#fast-reroute block Forbids this interface to be on

the backup path during backup
path calculation.
7-3

Configuring BGP FRR

To configure BGP FRR on the ZXR10 8900E, perform the following steps:
1 ZXR10(config)#router bgp <as-number> Enters BGP route configuration

mode.
2 ZXR10(config-bgp)#bgp frr Enables the BGP FRR function.
7.1.3 Maintaining IP FRR

To maintain the IP FRR on the ZXR10 8900E, run the following commands:
Command Function
ZXR10#show isis fast-reroute-topology [ level-1 | level-2] Displays the IS-IS backup

topology.
ZXR10#show ip ospf border-lsfas [ process < process-id>] Displays the routes on the backup
switch for the OSPF primary
switch.
ZXR10#show ip forwarding backup route {<network>} Displays the backup routing table.
The following is sample output from the show isis fast-reroute-topology command:
ZXR10(config)#show isis fast-reroute-topology level-1
IS-IS ipfrr paths to Level-1 routers
System id Interface Ipfrr interface Ipfrr type metric
AAAA.AAAA.AAAA vlan1 valn2 Link/ECMP 10
AAAA.AAAA.AAAA vlan3 vlan4 Link/ECMP 10
AAAA.AAAA.AAAA vlan5 vlan6 Link/ECMP 10
System id System ID of the next hop that is protected.
Interface Primary link out-interface.
Ipfrr interface Backup link out-interface.
Ipfrr type Protection type.
metric Metric of the backup link.
The following is sample output from the show ip ospf border-lsfas command:
ZXR10#show ip ospf border-lfas
Protect Type: link-protect 0x80000001, ecmp-protect 0x80000004
node-protect 0x80000002, stat-protect 0x80000008
7-4

OSPF Router with ID (4.4.4.9) (Process ID 1)
OSPF internal LFA Table

Destination Next Hop Cost Type RteType Area ProtectType
Primary NextHop
1.1.1.35 11.22.10.2 402 ASBR INTRA 0.0.0.0 80000001
Vlan10
Destination Router ID of the next hop that is protected.
Next Hop Backup next hop address.
Cost Cost of the backup link.
Type Switch type.
RteType Route type.
Area Area.
ProtectType Protection type.
Primary NextHop Out-interface of the primary next hop.
The following is sample output from the show ip forwarding backup route command:
ZXR10#show ip forwarding backup route
IPv4 Routing Table:
Headers: Dest: Destination, Gw: Gateway, Pri: Priority, M/S: Master/Slave,
Sta: Status;
Codes : BROADC: Broadcast, USER-I: User-ipaddr, USER-S: user-special,
MULTIC: Multicast, USER-N: User-network, DHCP-D: DHCP-DFT,
ASBR-V: ASBR-VPN, STAT-V: Static-VRF, DHCP-S: DHCP-static,
GW-FWD: PS-BUSI, NAT64: Stateless-NAT64, LDP-A: LDP-area,
GW-UE: PS-USER, P-VRF: Per-VRF-label, TE: RSVP-TE;
Status codes: *valid, >best, M: Master, S: Slave, I: Inuse, U: Unuse;
Dest Gw Interface Owner Pri Metric M/S Sta
*> 17.17.17.17/32 25.1.1.1 vlan25 ISIS_LEVEL1 115 20 M I
* 17.17.17.17/32 24.1.1.1 vlan24 ISIS_LEVEL1 115 40 S U
*> 20.20.20.20/32 14.1.1.1 vlan14 ISIS_LEVEL1 110 2 M I
* 20.20.20.20/32 24.1.1.1 vlan24 ISIS_LEVEL1 110 6 S U
Dest IP address of the destination.
Gw IP address of the next hop on the backup link.
7-5

Interface Outgoing interface of the backup link.
Owner Source of a route, that is, a routing protocol or a keyword.
Pri Administrative distance of the information source, that is, the

priority.
Metric Metric of the backup link.
M/S Master/standby link of FRR.

l M refers to the master link of the FRR.
l S refers to the standby link of the FRR.
Sta Route status, including I and U.

l I refers to Inuse.
l U refers to Unuse.
7.1.4 IP FRR Configuration Example

FRR is to provide backup protection for important nodes and links when the nodes or links
become invalid in the network. It realizes fast re-routing, thus decreases the influence to
the traffic caused by the invalid nodes or links to make the traffic recovered quickly.
There are two typical network structures of FRR, as shown below.
1. The typical network structure of node protection is shown in Figure 7-1.
Figure 7-1 Network Structure of FRR Node Protection
2. The typical network structure of link protection is shown in Figure 7-2. IS-IS neighbor
topology is established on the two links. One of the link has high priority and the other
link has lower priority.
Figure 7-2 Network Structure of FRR Link Protection
7-6

Configuration Thought
1. Configure routing protocols.
2. On the nodes forming FRR relationship, there are more than two next hops reachable
to the same route.
3. Enable FRR function in related routing protocol on corresponding devices.
The detailed configuration is described below.
1. Configuration of FRR node protection
Take BGP in Figure 7-1 as an example. First, establish EBGP neighbor relationship
between the routers through real interfaces. Enable FRR function on R1. Set the
routes advertised by R3 that go through the path R1R2R3 as the optimal routes.
R1(config-bgp)#bgp frr
R1(config-bgp)#exit
R1(config)#route-map lt
R1(config-route-map)#set local-preference 200
R1(config-router)#exit
R1(config-bgp)#neighbor 172.16.1.2 route-map lt in
R1(config-bgp)#exit
R2(config-bgp)#exit
R3(config-bgp)#exit
2. Configuration of FRR link protection
Take IS-IS protocol in Figure 7-2 as an example.
R1(config-isis)#area 01
R1(config-isis-1)#system-id 00D0.D0C7.5460
7-7

R1(config-isis-1)#fast-reroute enable
R1(config-isis-1-if-vlan47)#metric 20
R2(config-isis)#area 01
R2(config-isis-1)#system-id 00D0.D0C7.6788
Use the show ip forwarding backup route command to check whether the FRR
configuration takes effect.
The result of BGP FRR on R1 is shown below.

R1#show ip forwarding backup route
IPv4 Backup Routing Table:
*>1.1.1.150/32 172.16.20.2 vlan1 BGP 20 0 M U
The result of IS-IS FRR on R1 is shown below.

R1#show isis fast-reroute-topology
00D0.D0C7.6788 vlan47 vlan24 Link 20
00D0.D0C7.6788 vlan47 vlan24 Link 20
R1#show ip forwarding backup route

*>1.1.1.0/24 190.1.1.200 vlan12 ISIS_LEVEL1 115 30 M U
7-8

7.2 L2 VPN FRR Configuration

7.2.1 L2 VPN FRR Overview
Nowadays, network develops rapidly. The triple-play requirement becomes more and more
exigent. The operators pay much attention to the service convergence speed when faults
occur. When any node has a fault, the service handover on the adjacent nodes should be
finished within 50 ms, and the point-to-point service convergence should be finished within
1 s. This has been the threshold indicator of the bearer network.
To meet the requirement that the service handover on the adjacent nodes is finished within
50 ms and the point-to-point service convergence is finished within 1 second, L2 VPN
FRR comes into being. L2 VPN FRR is a set of protection mechanisms applied to links
and nodes. When an LSP link or a node has a fault, the faulty place is protected. In this
way, traffic can pass through the protected link or node without interruption. Meanwhile,
the head node can initiate the reestablishment of the active path without affecting data
transmission.
L2 VPN FRR is also called PW FRR. PW FRR is a link and node protection handover
technology for L2 VPN services encapsulated on the base of Pseudo Wire Emulation
Edge-to-Edge (PWE3). Its basic principle is to protect a PW with another PW that is
established in advance, that is, PW redundancy. The PW established in advance is called
the standby PW, and the protected PW is called the active PW. The final goal of L2 VPN
FRR is to protect the active path by using the standby PW to evade the faulty link or node.
PW FRR is used on H-VPLS UPEs. In full-mesh PW network, it is unnecessary to use PW
FRR.
As shown in Figure 7-3, UPE1 connects to NPE2 amd NPE3. PW12 and PW13 are of
redundant hot backup relation. The active and standby attributes are specified statically
during network plan. There is only one PW of them can forward services at any moment.
When the active PW has a fault, with the link failure detection technology such as BFD,
PW FRR handover will be triggered. For example, CE forwards traffic to CE2. When the
active PW (PW12) or NPE2 has a fault, PW FRR handover is triggered. Traffic on UPE1 is
handed over to the standby PW (PW13) quickly. When the active PW recovers, PW FRR
handover is traggered again and traffic is handed over back to the active PW.
7-9

Figure 7-3 L2VPN FRR Principle
7.2.2 Configuring L2 VPN FRR

To configure L2 VPN FRR on ZXR10 8900E, perform the following steps.
1 ZXR10(config-vpls-spoke-sdu)#peer <ip-address1>[<1-4 Configures the peerid and vcid

294967295>] of the active PW for an L2VPN
instance.
2 ZXR10(config-vpls-spoke-sdu)#redundancy-manager Configures the redundancy

<pw_redundancy> group for a SDU.
3 ZXR10(config-vpls-spoke-sdu)#peer <ip-address>[<1- Configures the peerid and

4294967295>]backup vcid of the standby PW for the
L2VPN instance.
4 ZXR10(config-vpls)#mac-withdraw Configures MAC withdraw.

When a PW is down, MAC
withdraw messages are sent.
5 ZXR10(config-vpls-spoke-sdu-rm)#force-switch Forced switch of the

active/standby PWs.
6 ZXR10(config-vpls-spoke-sdu-rm)#switch-back-policy Sets the switch-back policy to

immediately immediately.
Parameter descriptions:
<ip-address1> The remote IP address of a PW
<1-4294967295> The VCID of a PW, in the range of 1-4294967295. By default,

the VCID is default-vcid.
7-10

ether | ether-vlan PW type, ether or ether-vlan

When the PW type is ethernet, the delivery mode of Virtual Private
Wire Service (VPWS) is transparent, that is, PE does not check
and handle the Virtual Local Area Network (VLAN) tags in user
packets. Instead, PE just forwards the packets. The VLAN tag is
considered as an identifier for users to manage private networks.
(In this mode, the access interfaces provided for users can only
be actual interfaces.)
When the PW type is ethernet-vlan, the delivery mode of VPWS
is rewrite. In this mode, the ingress PE will remove the VLAN
tags in user packets and then send the packets to the PW. The
egress PE will add corresponding VLAN tags to user packets and
then send them to users.
<pw_redundancy> PW redundancy group interface.
7.2.3 L2 VPN FRR Maintenance

The maintenance of L2 VPN FRR is similar with that of VPLS and VPWS. For details,
please refer to corresponding information about VPLS or VPWS in ZXR10 8900E
(V3.00.01) Seriel Switch User Guide(VPN Volume).
7.2.4 L2 VPN FRR Configuration Example

The main function of L2 VPN FRR is to ensure that L2 VPN traffic can be handed over
to the standby link by establishing an active PW and a standby PW when the active link
has a fault. This ensures the reliability of L2 VPN communication. It is mainly applied to
the Spoke-PW protection between the UPEs at the user side and the NPEs at the network
side. The detection of PW ensures the fast handover of L2 VPN FRR. Meanwhile, the
MAC withdraw signaling completes the update of VPLS MACs on the entire network. A
typical VPLS FRR network topology is shown in Figure 7-4.
7-11

Figure 7-4 VPLS FRR Configuration Example
1. Configure IGP routes on UPE1, NPE2, NPE3 and NPE4 to make them ping through
each other. The router-ids are listed below.
Device Route-id
UPE1 1.1.1.1
NPE2 2.2.2.2
NPE3 3.3.3.3
NPE4 4.4.4.4
2. Establish Label Distribution Protocol (LDP) neighbor relationship between the four
devices (UPE1, NPE2, NPE3 and NPE4).
3. Create a VPLS instance named zte among NPE2, NPE3 and NPE4. The VCID is 100,
Meanwhile, CE2 connects to NPE4 as an Access Circuit (AC).
4. Associate the VPLS FRR function. Enter VPLS instance configuration mode on
UPE1 to configure the information related to the VPLS instance test, and configure
the addresses of the active PW and the standby PW. The link between UPE1 and
NPE2 is the active PW. The link between UPE1 and NPE3 is the standby PW. CE1
connects to UPE1 as an AC.
The VPLS FRR configuration on UPE1:
UPE1(config)#mpls l2vpn enable
UPE1(config)#sdu sdu1
UPE1(config)#pw-redundancy-manager pw_redundancy1
UPE1(config)#vpls test
UPE1(config-vpls)#mac-withdraw
UPE1(config-vpls)#spoke-sdu sdu1
7-12

UPE1(config-vpls-spoke-sdu)#neighbour 2.2.2.2 100

UPE1(config-vpls-spoke-sdu-pw)#exit
UPE1(config-vpls-spoke-sdu)#redundancy-manager pw_redundancy1
UPE1(config-vpls-spoke-sdu-rm)#
UPE1(config-vpls-spoke-sdu-rm)#exit
UPE1(config-vpls-spoke-sdu)#neighbour 3.3.3.3 100 backup
The VPLS FRR configuration on NPE2:

NPE2(config)#mpls l2vpn enable
NPE2(config)#sdu sdu1
NPE2(config)#vpls test
NPE2(config-vpls)#spoke-sdu sdu1
NPE2(config-vpls-spoke-sdu)#neighbour 1.1.1.1 100
The VPLS FRR configuration on NPE3:

NPE3(config)#mpls l2vpn enable
NPE3(config)#sdu sdu1
NPE3(config)#vpls test
NPE3(config-vpls)#spoke-sdu sdu1
NPE3(config-vpls-spoke-sdu)#neighbour 1.1.1.1 100
Check the result of the configuration on UPE1. The PW information is shown below.
UPE1(config-vpls)#show running-config l2vpn
!
<L2VPN>
mpls l2vpn enable
vpls test
mac-withdraw
spoke-sdu sdu1
redundancy-manager pw_redundancy1
$
neighbour 2.2.2.2 100
$
neighbour 3.3.3.3 100 backup
$
$
!
! </L2VPN>
UPE1(config-vpls)#show l2vpn forwardinfo vpnname test
Codes: H - HUB mode, S - SPOKE mode, L - VPLS, W - VPWS, M - MSPW
PeerIP VCID PWType State Llabel Rlabel VPNowner
7-13

3.3.3.3 100 ETH S UP 81925 81920 L: test

2.2.2.2 100 ETH S UP 81922 81921 L: test
7.3 L3 VPN FRR Configuration

7.3.1 L3 VPN FRR Overview
In an MPLS/VPN network, as shown in Figure 7-5, usually Interior Border Gateway
Protocol (IBGP) neighbor relationship is established between the PE devices to switch
VPN routes. The next hop of the private network is a PE device. In addition, it is
necessary to establish IGP/LDP neighbor relationship between the PE devices and the P
devices, as well as between the P devices, to establish an outer layer tunnel. It is also
necessary to iterate the remote next hop of VPN BGP routes and IGP/LDP outer layer
tunnel to generate the final VPN Forwarding Information Base (FIB) entries. The VPN FIB
entries are used to guide the forwarding of VPN services on PE devices.
As shown in Figure 7-5, BGP is run between PE1 and PE2. OSPF and LDP are run among
PE1, P1 and PE2, as well as among PE1, P2 and PE2, to provide route channels for BGP.
Figure 7-5 VPN/BGP Neighbors
VPN FRR is one the most widely used technologies used to solve fast changeover faults
. Its basic thought is to establish an end-to-end channel between PE devices and provide
a backup channel established in advance for the protected primary channel. When the
devices detect that the primary channel is not available due to a node fault or a link fault,
traffic is changed over to the backup channel. This realizes the fast changeover of services,
which ensures that VPN traffic will not lose.
7-14

In an IP/MPLS VPN multi service bearer network, when it is necessary to implement fast
public routes and LSP convergence after faults occur on the links between PE devices and
P devices, on the links between P devices or on P devices, it is recommended to deploy
VPN FRR.
The working procedure of VPN FRR is similar with that of IP FRR, as described below.
1. Detect faults quickly. The common technologies include BFD, physical signal test and
so on.
2. Modify the forwarding plane. Hand over the traffic to the recalculated backup path.
3. Perform route re-convergence.
4. After finishing the re-convergence, hand over the route to the optimal path.
7.3.2 Configuring L3 VPN FRR

To configure L3 VPN FRR on ZXR10 8900E, perform the following steps.
1. Configure OSPF FRR
1 ZXR10(config)#router ospf <process-id>[ vrf < Enters OSPF route

vrf-name>] configuration mode.
2 ZXR10(config-ospfv2)#fast-reroute alternate-protect-t Configures route backup

ype { default| down-stream-path} mode. There are two modes.
3 ZXR10(config-ospfv2)#interface < interface-name> Enters protocol interface

configuration mode.
4 ZXR10(config-ospfv2-if)#fast-reroute This specifies the backup

[backup-interface <interface-name>] interface statically.
2. Configure BGP
1 ZXR10(config)#router bgp<as-number>[ vrf < vrf-name>] Enters BGP route

configuration mode. The
parameter <as-number> is the
AS number.
2 ZXR10(config-bgp)#neighbor <ip-address> remote-as Configures a BGP neighbor.

<as-number> The parameter <ip-address> is
the IP address of the neighbor.
3. Configure LDP FRR
LDP FRR is on the base of IGP FRR. After LDP is enabled on the base of IGP FRR,
LDP FRR is configured.
7-15

7.3.3 L3 VPN FRR Maintenance

ZXR10 8900E provides the following commands to maintain L3 VPN FRR.
Command Function
ZXR10#show ip bgp neighbor This views BGP neighbor

information.
ZXR10# show ip ospf neighbor This views OSPF neighbor

information.
An example of the show ip bgp neighbor command output is shown below.

ZXR10#show ip bgp neighbor
BGP neighbor is 129.213.1.2, remote AS 65001, external link
BGP version 4, remote router ID 129.213.1.2
BGP state = Established, up for 00:04:21
hold time is 90 seconds, keepalive interval is 30 seconds
Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received
All received 10 messages
0 updates, 0 errs
1 opens, 0 errs
9 keepalives
0 vpnv4 refreshs, 0 ipv4 refreshs, 0 ipv4 multicast refreshs,
0 ipv6 refreshs, 0 errs
......
BGP neighbor is 129.213.1.2, The IP address is the peer address of the TCP connection
remote AS 65001, external link between BGP neighbors. The peer is in AS 65001. It is an EBGP
connection.
BGP version 4, remote router ID It means that BGP-4 is used. The peer BGP router ID is
129.213.1.2 129.213.1.2.
BGP state = Established, up for It means that the neighbor state is Established. The session has
00:04:21 been established for 4 minutes and 21 seconds.
hold time is 90 seconds, It means that the holding time is 90 seconds, and the Keepalive
keepalive interval is 30 seconds interval is 30 seconds.
An example of the show ip ospf neighbor command output is shown below.

ZXR10(config)#show ip ospf neighbor
OSPF Router with ID (100.100.100.20) (Process ID 1)
7-16

Neighbor ID Pri State DeadTime Address Interface

100.100.100.14 1 FULL/DR 00:00:34 100.100.100.14 vlan1
100.100.100.14 1 FULL/DR 00:00:35 1.1.1.1 vlan2
Neighbor ID The neighbor ID
In the area The area which the neighbor is in
via interface fei_1/1 The type, number and IP address of the neighbor interface
DR The router ID of the DR
BDR The router ID of the BDR
State The neighbor state
Priority The neighbor priority
Cost The neighbor cost
Queue count The length of different queues
Retransmit The length of the retransmission queue
DD The length of the DD queue
LS Req The length of the request queue
Dead Time The shortest time to when the neighbor is down
Options Options of a neighbor
In Full State The time that the device has been in full state
7.3.4 L3 VPN FRR Configuration Example

As shown in Figure 7-6, it is necessary to establish MP-BGP neighbor relationship between
PE devices, and establish MPLS LDP neighbor relationship in the public network.
7-17

Figure 7-6 L3 VPN FRR Configuration Example
The addresses on the interfaces are listed in Table 7-1.
Table 7-1 Interface Addresses
Device Interface Address
CE1 vlan1 40.0.0.2 255.255.255.0
loopback1 12.1.2.1 255.255.255.0
CE2 vlan1 60.0.0.2 255.255.255.0
loopback1 12.1.2.5 255.255.255.0
PE1 vlan1 40.0.0.2 255.255.255.0
vlan2 10.0.0.2 255.255.255.0
vlan3 11.0.0.2 255.255.255.0
loopback1 1.1.1.2 255.255.255.255
PE2 vlan1 60.0.0.2 255.255.255.0
vlan2 15.0.0.2 255.255.255.0
vlan3 14.0.0.2 255.255.255.0
loopback1 1.1.1.3 255.255.255.255
P1 vlan2 10.0.0.1 255.255.255.0
vlan3 14.0.0.1 255.255.255.0
loopback1 1.1.1.4 255.255.255.255
P2 vlan3 11.0.0.1 255.255.255.0
vlan2 15.0.0.1 255.255.255.0
loopback1 1.1.1.5 255.255.255.255
1. Configure IGP routes between PE1 and PE2 to make that PE1 and PE2 can ping
through each other.
2. Configure MP-BGP neighbor relationship.
7-18

3. Configure LDP neighbor relationship.

4. Enable routing protocol FRR on PE1. VPN FRR can be realized on the base of the
neighbor relationships configured above.
Suppose that CE1 connects to the network through OSPF; CE2 connects to the network
through IS-IS; the intermediate routing protocol is IGP. The configuration is shown below.
Configuration of CE1:
CE1(config)#interface vlan1
CE1(config-if)#ip address 40.0.0.2 255.255.255.0
CE1(config-if)#exit
CE1(config)#interface loopback1
CE1(config-if)#exit
CE1(config)#router ospf 1
CE1(config-ospfv2)#network 40.0.0.0 0.0.0.255 area 16
CE1(config-ospfv2)#network 12.1.2.1 0.0.0.0 area 16
Configuration of CE2:
CE2(config)#interface vlan1
CE2(config-if)#exit
CE2(config)#interface loopback1
CE2(config-if)#exit
CE2(config)#router isis
CE2(config-isis)#area 10
CE2(config-isis)#system-id 0000.0000.0001
CE2(config-isis)#interface loopback1
CE2(config-isis-if)#ip router isis
CE2(config-isis)#exit
CE2(config-isis)#interface vlan1
CE2(config-isis-if)#ip router isis
CE2(config-isis)#exit
Configuration of PE1:
PE1(config)#ip vrf zte1
PE1(config-vrf)#rd 100:1
PE1(config-vrf)#route-target import 100:1
PE1(config-vrf)#route-target export 100:1
PE1(config-vrf)#address-family ipv4
PE1(config-vrf-af)#exit-address-family
PE1(config-vrf)#exit
PE1(config)#interface loopback1
7-19

PE1(config-if)#ip address 1.1.1.2 255.255.255.255

PE1(config-if)#exit
PE1(config)#interface vlan1
PE1(config-if)#ip vrf forwarding zte1
PE1(config-if)#exit
PE1(config-if)#exit
PE1(config-if)#exit
PE1(config)#mpls ldp instance1
PE1(config-ldp)#interface vlan2
PE1(config-ldp-if)#exit
PE1(config-ldp)#exit
PE1(config)#router bgp 100
PE1(config-bgp)#neighbor 1.1.1.3 remote-as 100
PE1(config-bgp)#neighbor 1.1.1.3 update-source loopback1
PE1(config-bgp)#address-family vpnv4
PE1(config-bgp-af)#neighbor 1.1.1.3 activate
PE1(config-bgp-af)#exit-address-family
PE1(config-bgp)#address-family ipv4 vrf zte1
PE1(config-bgp-af)#redistribute ospf-int1
PE1(config-bgp)#exit
PE1(config)#router ospf 1 vrf zte1
PE1(config-ospfv2)#network 40.0.0.0 0.0.0.255 area 16
PE1(config-ospfv2)#exit
PE1(config)#router isis
PE1(config-isis)#area 10
PE1(config-isis)#system-id 0000.70d0.c200
PE1(config-isis)#interface vlan2
PE1(config-isis-if)#ip router isis
PE1(config-isis-if)#exit
PE1(config-isis-if)#metric 20
PE1(config-isis)#fast-reroute enable
PE1(config-isis)#interface loopback1
7-20

Configuration of PE2:
PE2(config)#ip vrf zte1
PE2(config-vrf)#rd 100:1
PE2(config-vrf)#route-target import 100:1
PE2(config-vrf)#route-target export 100:1
PE2(config-vrf)#address-family ipv4
PE2(config-vrf-af)#exit-address-family
PE2(config-vrf)#exit
PE2(config)#interface loopback1
PE2(config-if)#exit
PE2(config-if)#ip vrf forwarding zte1
PE2(config-if)#exit
PE2(config-if)#exit
PE2(config-if)#exit
PE2(config)#mpls ldp instance1
PE2(config-ldp)#exit
PE2(config)#router bgp 100
PE2(config-bgp)#neighbor 1.1.1.2 remote-as 100
PE2(config-bgp)#neighbor 1.1.1.2 update-source loopback1
PE2(config-bgp)#address-family ipv4 vrf zte1
PE2(config-bgp-af)#redistribute isis-1-2 0
PE2(config-bgp)#address-family vpnv4
PE2(config-bgp-af)#neighbor 1.1.1.2 activate
PE2(config)#router isis vrf zte1
PE2(config-isis)#system-id 0000.0000.0002
PE2(config-isis)#exit
PE2(config)#router isis 1
7-21

PE2(config-isis)#system-id 0000.dd00.0002
PE2(config-isis)#interface loopback1
Configuration of P1:
P1(config)#interface loopback1
P1(config-if)#ip address 1.1.1.4 255.255.255.255
P1(config-if)#exit
P1(config)#interface vlan2
P1(config-if)#exit
P1(config-if)#exit
P1(config)#router isis
P1(config-isis)#area 10
P1(config-isis)#system-id 0000.dd00.1000
P1(config-isis)#interface vlan2
P1(config-isis-if)#ip router isis
P1(config-isis-if)#exit
P1(config-isis)#interface loopback1
P1(config-isis)#exit
P1(config)#mpls ldp instance1
P1(config-ldp)#interface vlan2
P1(config-ldp-if)#exit
Configuration of P2:
P2(config-if)#exit
7-22


P2(config-if)#exit
P2(config-if)#exit
P2(config)#router isis
P2(config-isis)#area 10
P2(config-isis)#system-id 0000.dd00.3000
P2(config-isis)#interface loopback1
P2(config)#mpls ldp
P2(config-ldp-if)#end
Use the show ip forwarding backup route command to check whether the configuration
makes FRR function take effect.
The result of IS-IS FRR on PE1 is shown below.
PE1#show isis fast-reroute-topology

0000.dd00.0002 vlan2 vlan3 node 30
0000.dd00.0002 vlan2 vlan3 node 30
PE1#show ip forwarding backup route

Dest Gw Interface Owner Pri Metric
1.1.1.3/32 11.0.0.2 vlan3 ISIS_LEVEL1 115 40
View the information of the IBGP connection between PE1 and PE2, as shown below.
PE1#show ip bgp summary

Neighbor Ver As MsgRcvd MsgSend Up/Down(s) State
1.1.1.3 4 100 195 201 01:37:23 2
7-23

PE1#
View the LDP neighbor relationship in the public network, as shown below.
PE1#show mpls ldp neighbor
TCP connection: 10.0.0.2.1025 - 10.0.0.1.646
Up Time: 02:53:09
vlan2; Src IP addr: 10.0.0.1
10.0.0.2 11.0.0.2
TCP connection: 11.0.0.2.1025 - 11.0.0.1.646
Up Time: 02:53:09
vlan3; Src IP addr: 11.0.0.1
10.0.0.2 11.0.0.2
7.4 TE FRR Configuration

7.4.1 TE FRR Overview
Instruction to TE-FRR
At present, the traditional IP network is a best-effort service module. With the development
of network services, as the uniform carrier of multi-service, IP network must reach the class
of the traditional carrier networks in the reliability aspect. For example, according to the
requirement of carrier-class services, the protection handover time should be less than
50 ms. MPLS technology appeared in 1990s. Since then, MPLS has been developed
greatly as it has a lot of advantages (such as fast forwarding, QoS guarantee, support for
multi-service, and so on). Therefore, MPLS plays a more and more important role in the
next generation carrier network.
To ensure the reliability of MPLS network, MPLS FR plays an important role. MPLS FRR
provides fast handover protection ability for LSPs with the help of MPLS TE. MPLS FRR
establishes a local standby path in advance to prevent the LSP from being affected by
failures of links or nodes. When a fault occurs, the device that detects the fault will hand
over the service quickly to the standby path from the faulty link. This reduces data loss.
Fast response and timely handover are the characteristics of MPLS FRR. They can ensure
the smooth transition of service data without interruption. Meanwhile, the head node of
LSP tries to find a new path to reestablish the LSP and hand over the data back to the new
7-24

path. Before the new LSP is established, service data is forwarded through the protecting
path.
TE FRR Principle
l Basic Principle
MPLS TE FRR is a set of link and node protection handover mechanism in MPLS TE.
when an LSP link or a node has a fault, the faulty node is protected. In this way, traffic
can go through the tunnel through the protecting link or node without interruption.
Meanwhile, the head node can initiate the reestablishment of the active path without
affecting data transmission.
The basic principle of MPLS FRR is to protect one or more LSPs with another LSP
that is established in advance. The LSP established in advance is called the FRR
LSP, and the protected LSP is called the active LSP. The final goal of MPLS TE FRR
is to protect the active path by using the FRR tunnel to evade the faulty link or node.
MPLS TE FRR is realized on the base of Resource ReSerVation Protocol (RSVP) TE.
It complies with the Request For Comments (RFC) 4090.
There are two modes to realize MPLS TE FRR.
Detour mode: It is one-to-one backup. In this mode, the device provides
protection for each protected LSP and establishes a protecting path for each
protected LSP. The protecting path is called Detour LSP.
Bypass mode: It is facility backup. In this mode, a protecting path is used to

protect several LSPs. The protecting path is called Bypass LSP.
Detour mode realizes the protection for each LSP. This needs relatively more cost. In
practical applications, Bypass mode is widely used. The following contents describe
Bypass mode is described in details.
Bypass mode is shown in Figure 7-7. The blue arrows indicate the active LSP, and
the red arrows indicate the Bypass LSP. When the link between RTB and RTC or the
node RTC is invalid, the data on the active LSP will be handed over to the Bypass
LSP. The packet sent by RTB uses the label distributed by RTF in the top layer of the
header. Meanwhile, the out-label of RTC is input into the label stack to be used as
the next layer label.
7-25

Figure 7-7 FRR Though Bypass Mode
On the path RTB - RTF - RTD, the LSP uses two layers of labels. When RTD receives
a packet, it pops out the label that is distributed for RTF by RTD, and then it uses the
label that is distributed for RTF by RTD to forward the packet.
Some main concepts are described as follows.
Active LSP: It is relative to the Detour LSP or the Bypass LSP. It is the protected
LSP.
Point of Local Repair (PLR): It is the head node of the Detour LSP or the Bypass
LSP. It must be on the active LSP, and it should not be the tail node.
Merge Point (MP): It is the tail node of the Detour LSP or the Bypass LSP. It must
be on the active LSP, and it should not be the head node.
Link protection: The PLR and the MP are connected through a direct connection.
The active LSP passes through this link. When this link is invalid, the data can
be handed over to the Detour LSP or the Bypass LSP.
Node protection: The PLR and the MP are connected through a router. The active
LSP passes this router. When this router is invalid, the data can be handed over
to the Detour LSP or the Bypass LSP.
l Key Technology
FRR in Bypass mode is shown in Figure 7-8.
7-26

Figure 7-8 FRR in Bypass Mode
FRR in Bypass mode described here is realized according to RFC 4090 (called
protocol hereinafter) by extending the SESSION_ATTRIBUTE object and the
RECORD_ROUTE object.
l Establishment of the Active LSP
The establishment of an active LSP is the same with that of a common LSP. RSVP
sends the PATH message from the head node (RT1) to the downstream hop by hop
(passing by RT1 - RT2 - RT3 - RT4 - RT5). And then RSVP sends the RESV message
from the tail node (RT5) to the upstream hop by hop. When the devices handle the
RESV message, they distribute labels and reserve resources to establish the LSP.
The protocol draft extends some flag bits in SESSION_ATTRIBUT object and object
RECORD_ROUTE for FRR. The differences between the establishment of a protected
LSP and a common LSP lie in the handling of these flag bits.
In the SESSION_ATTRIBUT object of a PATH message, the flag bits added include
whether the LSP needs local protection, whether to record labels, whether to use
Share-Explicit (SE) style, and whether to protect bandwidth.
In the RECORD_ROUTE object of an RESV message, the flag bits added include
whether the LSP has been protected, whether the data has been handed over,
whether it is the bandwidth that has been protected, and whether it is protected by
a node.
The establishment of an active LSP is triggered by configuring a tunnel on the head
node (RT1) manually. Before the establishment, if the FRR attribute of the LSP has
been specified through commands, RSVP will add the flag bits (whether the LSP
needs local protection, whether to record labels and whether to use SE style) to the
SESSION_ATTRIBUTE object of the PATH message. If bandwidth has been specified
for the LSP, the flag bit for bandwidth protection will also be added to the object.
When the downstream nodes receive this PATH message, they know that it is an LSP
needing FRR by identifying the local protection flag.
7-27

For an LSP needing FRR (identified according to the flags in the previous PATH
message), when the nodes send RESV messages to the upstream, they will record
the egress, LSR ID and label of an RESV message in RECORD_ROUTE object. The
information is cumulatively transmitted to the upstream nodes.
When the node receive the RESV message for the first time, they select a suitable
Bypass LSP for the LSP according to the information in the RECORD_ROUTE object.
The procedure to select a suitable Bypass LSP for the active LSP is called binding.
The algorithm of the binding is introduced in details later.
After the binding FRR calculation for the active LSP, the RECORD_ROUTE object in
the RESV message sent to the upstream will point out whether the LSP has been
protected. If it is protected, the protected egress address (eth1 on RT2) and the
egress address (eth3 on RT2) of the RESV message will be recorded. If it is not
protected, the corresponding flags in the RECORD_ROUTE object will be cleared,
and only the egress address (eth3 on RT2) of the RESV message will be recorded.
Binding calculation is not supported on egresses. The flags in the RECORD_ROUTE
object of an RESV message sent to the upstream on the egresses are cleared.
The establishment of an active LSP with FRR protection is basically consistent with
that of a common LSP. The binding calculation is added to the establishment of an
active LSP, and some flags and sub-objects are added to the PATH message and
RESV message.
l Bypass LSP Establishment
There are two modes to establish a Bypass LSP, manual mode and automatic mode.
In manual Bypass LSP establishment, when a tunnel without FRR attribute is
specified to protect a physical interface, the LSP it corresponds to becomes the
Bypass LSP. The manual establishment of a Bypass LSP (tunnel12 on RT2) is
triggered by configuration on the PLR (RT2). The configuration has no difference
from that of a common LSP basically, except that FRR attribute cannot be configured
for a Bypass LSP. That is, a Bypass LSP cannot be an active LSP at the same time,
and LSPs cannot be nested-protected.
Automatic Bypass LSP is a simplification of the manual mode. When the active LSP
needs FRR protection, the PLR can select a Bypass LSP or establish a Bypass
LSP automatically to protect the active LSP. This mode is called automatic Bypass.
An automatic Bypass can protect multiple active LSPs as long as it meets the
requirements of the active LSPs.
A Bypass LSP can protect multiple physical interfaces, but it cannot protect the egress
of its own.
FRR can protect a link or a node. When Bypass LSP protection is needed, it is
necessary to plan the link or node to be protected and specify the protection mode (link
protection or node protection). Generally, node protection can protect the protected
node and the link between this node and the PLR. It seems that node protection is
better.
7-28

Generally, the bandwidth of a Bypass LSP is used to protect the active LSP. All
resources on the tunnel are only used after handover. During configuration, it is
necessary to make sure that the bandwidth configured is not less than the sum of
all LSPs to be protected. Otherwise, when FRR is valid, Bypass cannot provide the
protection that meets the requirements of user services completely.
Generally, Bypass LSP is in idle state, and it does not carry over data services. If the
Bypass LSP is intended to protect the active LSP and forward data at the same time,
it is required to configure enough bandwidth.
l Binding Calculation
Binding can mean to specify a Bypass LSP to protect a physical interface. This is
called the binding between a Bypass LSP and a physical interface. A Bypass LSP
can be bound to multiple physical interfaces. A physical interface can also be bound
to multiple Bypass LSPs.
Binding can also mean to select a suitable Bypass LSP to protect an active LSP.
This is called the binding between an active LSP and a Bypass LSP. The binding
calculation is the procedure to bind an active LSP to a Bypass LSP. If the binding
calculation succeeds, the RESV message will inform the upstream nodes that the
active LSP has been protected.
The result of the binding calculation includes the following items:

Protection type (it is link-type protection or node-type protection) and LSR ID of
the MP
The label distributed by the MP for the previous hop (This label corresponds to
the label of the MP LSR ID in RECORD_ROUTE object of the active LSP.)
Bypass LSP interface and the NHLFE information of the Bypass LSP
The binding calculation result is saved. When local invalidation occurs, the result can
be used immediately. This is the reason why MPLS TE FRR can make fast responses
to invalidations.
l Invalidation Detection
Invalidation detection aims at discovering the invalidation of the link (between RT2
and RT3) or the node (RT3) as soon as possible, thus to trigger handover to reduce
packet loss.
Invalidation detection does not judge whether it is an invalidation of a link or a node.
It is considered as an interface invalidation (eth1 of RT2) at last.
Interface invalidation triggers all LSPs that use this interface as egress to execute
FRR handover as soon as possible. If an LSP has been protected by a link according
to the binding calculation result, the data will be handed over to the protecting link.
When it is a node invalidation in fact, the protection will not succeed, and this LSP
will be deleted. If the LSP has been protected by a node according to the binding
calculation result, the data will be handed over to the protecting node. When it is a
7-29

link invalidation in fact, the Bypass LSP will be overleaped even if the next hop node
is available.
A part of link invalidations and node invalidations can be detected by link layer
protocols. The speed of the link layer protocols to discover an invalidation is related
to the interface type. Other invalidations are discovered through the Hello mechanism
of RESV. The speed of the Hello mechanism to discover an invalidation is relatively
slower.
It is possible to enable Hello mechanism on each physical interface that needs
protection. When Hello mechanism is also enabled on the peer interface, Hello
messages and responses will be sent periodically between two routers. When a link
or a node is invalid, the Hello message or response will be lost. If the message or
response is lost for continual three times, it is considered that an invalidation occurs.
l Handover Procedure
Handover means to enable the Bypass LSP. The data and RSVP messages on the
active LSP will not be forwarded along the previous path.
Handover can be triggered when the interface (eth1 of RT2) is closed by a command
or when invalidation detection discovers an interface (eth1 of RT2) invalidation. The
data and signaling of the protected LSP on the invalid interface will be handed over
to the Bypass LSP. The upstream nodes are informed that the handover occurs.
l LSP Maintenance After Handover
After the handover, the previous LSP is unavailable. To prevent the LSP from being
deleted when it expires, RSVP needs to keep message flush between PLR (RT2) and
MP (RT4).
The PATH message is sent to the MP through the Bypass LSP (Tunnel12 on RT2)
after modification. When the MP receives the PATH message, it confirms that itself
is the MP node. The RESV message is sent to the PLR node through multi-hop IP
forwarding (passing by RT4 - RT7 - RT2) after the modification.
After the handover, the PATH message sent to the MP by the PLR is changed
according to the following points:
1. The egress interface (eth2 on RT2) address of the PLR on the Bypass LSP is
filled in the PHOP field.
2. The ingress LSR ID in SENDERTEMPLATE is changed to the egress interface
(eth2 on RT2) address of the PLR on the Bypass LSP.
3. The PLR address recorded in RECORD_ROUTE object is changed to the egress
interface (eth2 on RT2) address of the PLR on the Bypass LSP.
4. All nodes previous to the MP are deleted in an Explicit Route Object (ERO). The
address first belonging to the MP is changed to the MP LSR ID.
The MP receives the PATH message through the Bypass LSP. As the SESSION is not
changed, but the ingress LSR ID (it is RT1 LSR ID previously) in SENDERTEMPLATE
is changed to the egress interface (eth2 on RT2) address of the PLR on the Bypass
7-30

LSP, MP will know that this is a PATH message after the FRR handover and the local
node is the MP.
The PATH message sent to downstream by the MP does not change with the
handover.
The RESV message sent to upstream by the MP is changed according to the following
points:
1. The Filter Spec source address in the message is changed to the PHOP address
(address of eth2 on RT2) in the PATH message.
2. The NHOP in the message is changed to the ingress interface (eth2 on RT4)
address of the MP on the Bypass LSP.
3. The RECORD_ROUTE object in the RESV message records the ingress interface
(eth2 on RT4) address of the MP on Bypass LSP.
4. The destination in the IP header of the message is the egress interface (eth2 on
RT2) address of the PLR on the Bypass LSP.
5. The Time To Live (TTL) value in the RESV message is set to 255. The TTL value
in the header of the protocol message is set to 1.
After the handover, the RESV message sent to upstream by the PLR also has some
changes. The egress interface (eth2 on RT2) address of the PLR on the Bypass LSP
is added to the RECORD_ROUTE object.
After the handover, the forwarding paths of PTEAR message, RERR message,
RTEAR message and PERR message of the active LSP also change.
After the handover of node protection, the protected node (RT3) may send the PTEAR
message to downstream due to the expiration of the PATH message. The MP (RT4)
will ignore this message. In addition, the MP will send the RTEAR message on the
previous LSP ingress interface (eth3 on RT4) during the handover. This is to make
the protected node (RT3) release corresponding resource as soon as possible.
l MBB
For FRR, a function of Make Before Break (MBB) is to make the LSP (tunnel1 on RT1)
protected by the Bypass LSP recover to normal state. When handover occurs on the
active LSP, the head node starts the MBB procedure to calculate a new available path.
When the new path is established, a new suitable standby LSP will be selected to form
the new binding relationship.
l Forwarding
Before the handover, the data forwarding on the active LSP is the same with that on a
common LSP. After the handover, the data is forwarded to the MP through the Bypass
LSP.
7.4.2 Configuring TE-FRR

Configure two independent tunnels (tunnel1 and tunnel2) on the head node first. Wait until
the two tunnels are up.
7-31

To configure TE-FRR on ZXR10 8900E, perform the following steps.
1 ZXR10(config-mpls-te-if)#tunnel mpls traffic-eng Enables FRR function on the

fast-reroute facility active tunnel (tunnel1).
2 ZXR10(config-mpls-te-if)#backup-path te_tunnel This binds the standby tunnel

<tunnel-number> on the egress interface of the
active tunnel (tunnel1).
7.4.3 TE-FRR Maintenance

ZXR10 8900E provides the following command to maintain TE-FRR.
Command Function
ZXR10(config)#show mpls traffic-eng fast-reroute This shows the FRR relationship

configured globally.
An example of the show mpls traffic-eng fast-reroute command output is shown below.
ZXR10#show mpls traffic-eng fast-reroute
head end item information
Protected Tunnel In-label Out intf/label FRR intf/label Status
Tunnel1 Tun hd vlan1:2197 Tu2:3 ready
midpoint frr information:identifier
In-label Out intf/label FRR intf/label Status
Protected Tunnel The ID of the tunnel that needs protection
In-label The value of the label advertised to other node by the local node.
Tun hd means that this node is the head node of the tunnel and
no label is advertised.
Out intf/label Out intf: the egress interface of the protected tunnel
Label: It is the value of the label advertised by the next hop on an
intermediate node
FRR intf/label FRR intf: the interface of the standby tunnel

Label: It is the value of the label advertised by the next hop on an
intermediate node
Status FRR current state, ready or active
LSP identifier Including source address, tunnelId and lspId
7-32

7.4.4 TE-FRR Configuration Example

As shown in Figure 7-9, there are two tunnels from P1 to P3, tunnel1 and tunnel2. Tunnel1
passes by P1, P2 and P3. Tunnel2 passes by P1 and P3. Tunnel1 is the active LSP.
Tunnel2 is the standby LSP. The two tunnels form the FRR relationship. When the active
LSP has a fault, the standby LSP protects it. Traffic is handed over to the standby LSP.
Figure 7-9 TE-FRR Configuration Example
1. Establish OSPF neighbor relationship through the direct-connected interfaces on P1,
P2 and P3. Enable OSPF TE.
2. Establish two strict paths. The active path passes by P1, P2 and P3. The standby
path passes by P1 and P3.
3. Enable TE on the interfaces in use on P1, P2 and P3. Configure the standby LSP on
gei-0/2/1/1 of P1.
4. Create the active path and the standby path. Enable FRR on the active path. The
destination is the TE router-id of P3. The path is in strict mode.
The configuration of P1:
P1(config-if)#exit
P1(config-if)#exit
P1(config-if)#exit
7-33

P1(config)#interface te_tunnel1
P1(config-if)#ip unnumbered loopback1
P1(config-if)#exit
P1(config)#interface te_tunnel2
P1(config-if)#ip unnumbered loopback1
P1(config-if)#exit
P1(config)#router ospf 1
P1(config-ospfv2)#router-id 2.1.1.1
P1(config-ospfv2)#network 74.1.1.0 0.0.0.255 area 0
P1(config-ospfv2)#mpls traffic-eng router-id loopback1
P1(config-ospfv2)#mpls traffic-eng area 0
P1(config-ospfv2)#exit
P1(config)#mpls traffic-eng
P1(config-mpls-te)#explicit-path name zte
P1(config-mpls-te-expl-path-name)#next-address strict 74.1.1.1
P1(config-mpls-te-expl-path-name)#exit
P1(config-mpls-te)#interface vlan1
P1(config-mpls-te-if)#backup-path te_tunnel 2
P1(config-mpls-te-if)#exit
P1(config-mpls-te)#tunnel te_tunnel 1
P1(config-mpls-te-if)#tunnel destination ipv4 3.1.1.1
P1(config-mpls-te-if)#tunnel mpls traffic-eng path-option 1
explicit-path_name primary
P1(config-mpls-te-if)#tunnel mpls traffic-eng record-route
P1(config-mpls-te-if)#tunnel mpls traffic-eng fast-reroute facility
P1(config-mpls-te)#tunnel te_tunnel 2
P1(config-mpls-te-if)#tunnel destination ipv4 3.1.1.1
P1(config-mpls-te-if)#tunnel mpls traffic-eng path-option 1 explicit-path
name back

P2(config-if)#exit
7-34

P2(config-if)#exit
P2(config-if)#exit
P2(config-mpls-te)#exit

P3(config-if)#exit
P3(config-if)#exit
P3(config-if)#exit
P3(config-mpls-te)#end
7-35

Note:
Enable FRR on the active LSP. Configure the standby LSP on the ingress interface of the
active LSP. Enable TE on the interfaces of other nodes.
When the tunnel is up, check the FRR information on P1, as shown below.
P1#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
P1#show mpls traffic-eng fast-reroute

Tunnel1 Tun hd vlan1:2197 Tu2:3 ready
When the active LSP has a fault, the traffic will be handed over to the standby LSP. FRR
is in active state. Check the FRR state on P1. When the fault on the active LSP recovers,
the FRR relationship recovers to ready state.
P1#show mpls traffic-eng fast-reroute
Tunnel1 Tun hd vlan1:2197 Tu2:3 active
7-36

Chapter 8
Route Load Sharing
Configuration
Table of Contents
Route Load Sharing Overview....................................................................................8-1
Configuring Route Load Sharing.................................................................................8-2
Route Load Sharing Maintenance ..............................................................................8-5
Route Load Sharing Configuration Examples .............................................................8-6
8.1 Route Load Sharing Overview

Route load sharing has two main functions:
l Improving the link reliability
The transport layer on the network has strict requirements of the stability and reliability.
The links themselves should be reliable. Besides, when a link has a fault, the packet
forwarding on other links should not be affected, or the failure should be reduced to
the minimum extent.
l Improving bandwidth
Route load sharing function makes it possible for routers to share traffic on several
paths, thus to make full use of the bandwidth resources. Through routing protocols
or static configuration, multiple route entities to the same destination are allowed to
exist in the forwarding table.
The forwarding mechanism of load sharing supports two methods, per-packet and
per-destination. The advantages and disadvantages of the two methods are listed below.
Per-destination per-packet
Advantages In this mode, the packets to the same This mode has a high path use rate, as
destination go through the same it uses the round-robin method to select
path. That is, when there are several the paths for the packets. This makes
paths available, packets to different the loads shared on the paths evenly.
destinations can go through different
paths.
8-1

Per-destination per-packet
Disadvantages When there are few destinations, In this mode, the packets to the same
the traffic may gather on few paths. destination may go through different
Therefore, the loads are not balanced. paths. Therefore, there is a sequencing
When there are more destinations, load problem at the receiving end. This
sharing in this mode is more effective. mode is not suitable for traffic that has
requirement of sequence, such as VoIP.
8.2 Configuring Route Load Sharing

Configuring RIP Route Load Sharing
To configure RIP route load sharing on ZXR10 8900E, perform the following steps.
1 ZXR10(config)#router rip Enters RIP route configuration

mode.
2 ZXR10(config-rip)#maximum-paths < number> Configures the count of routes

that support load sharing. It is in
the range of 1-32. The default
value is 1.
3 ZXR10(config)#interface < interface-name> Enters interface configuration

mode.
Configuring RIPng Route Load Sharing

To configure RIPng route load sharing on ZXR10 8900E, perform the following steps.
1 ZXR10(config)#ipv6 router rip Enters Routing Information

Protocol next generation
(RIPng) route configuration
mode.
2 ZXR10(config-ripng)#maximum-paths < number> Configures the count of routes

value is 1.

mode.
Configuring OSPFv2 Route Load Sharing

To configure OSPFv2 route load sharing on ZXR10 8900E, perform the following steps.
8-2

Chapter 8 Route Load Sharing Configuration
1 ZXR10(config)#router ospf < process-id>[ vrf < vrf-name>] Enters OSPF route
configuration mode.
2 ZXR10(config-ospfv2)#maximum-paths < number> Configures the count of routes

value is 1.

mode.
Configuring OSPFv3 Route Load Sharing

There is no related configuration commands for OSPFv3 route load sharing. It is just
necessary to configure OSPFv3 on an interface, create several links (32 links at most)
successfully and advertise the routes. The result of load sharing can be viewed with the
show ipv6 forwading route command and the show ipv6 protocol routing network command.
Configuring IS-IS Route Load Sharing

To configure IS-IS route load sharing on ZXR10 8900E, perform the following steps.
1 ZXR10(config)#router isis [ vrf < vrf-name>] Enters IS-IS route configuration

mode.
2 ZXR10(config-isis)#maximum-paths < number> Configures the count of routes

value is 1.

mode.
Configuring IS-ISv6 Route Load Sharing

To configure IS-ISv6 route load sharing on ZXR10 8900E, perform the following steps.
1 ZXR10(config)#router isis [ vrf < vrf-name>] Enters IS-IS route configuration

mode.
2 ZXR10(config-isis)#maximum-paths < number> Configures the count of routes

value is 1.

mode.
8-3

Configuring BGP Route Load Sharing

To configure BGP route load sharing on ZXR10 8900E, perform the following steps.
1 ZXR10(config)#router bgp < as-number> Enters BGP route configuration

mode.
2 ZXR10(config-bgp)#maximum-paths ibgp< number> Configures the count of routes

that support load sharing. It
is in the range of 1-32. The
default value is 1. (This is for
IBGP route load sharing.)
ZXR10(config-bgp)#maximum-paths < number> Configures the count of routes

value is 1. (This is for EBGP
route load sharing.)

mode.
Configuring BGP4+ Route Load Sharing

To configure BGP4+ route load sharing on ZXR10 8900E, perform the following steps.
1 ZXR10(config)#router bgp < as-number> Enters RIP route configuration

mode.
2 ZXR10(config-bgp)#maximum-paths ibgp< number> Configures the count of routes

that support load sharing. It
is in the range of 1-32. The
default value is 1. (This is for
IBGP route load sharing.)
ZXR10(config-bgp)#maximum-paths < number> Configures the count of routes

value is 1. (This is for EBGP
route load sharing.)

mode.
8-4

8.3 Route Load Sharing Maintenance

Command Function
ZXR10#show ip forwarding route {[vrf <vrf-name>]<network>[<net This shows the forwarding routing
work-mask>]|<protocol>} table.
ZXR10#show ip protocol routing {[vrf <vrf-name>]<network>[<netw This shows the protocol routing
ork-mask>]|<protocol>} table.
ZXR10#show running-config This shows current configuration.
An example of the show ip forwarding route command output is shown below.

ZXR10#show ip forwarding route
IPv4 Routing Table:
1.1.1.200/32 100.2.1.200 vlan2 OSPF 110 20
1.1.1.200/32 101.20.11.20 vlan3 OSPF 110 20
1.1.1.200/32 101.20.12.20 vlan3 OSPF 110 20
1.1.1.200/32 101.20.13.20 vlan3 OSPF 110 20
1.1.1.200/32 101.20.14.20 vlan3 OSPF 110 20
An example of the show ip protocol routing command output is shown below.

ZXR10#show ip protocol routing
Protocol routes:
status codes: *valid, >best, i-internal, s-stale
Dest NextHop RoutePrf RouteMetric Protocol
*> 1.1.1.200/32 100.2.1.200 110 20 ospf-ext
*> 1.1.1.200/32 101.20.11.20 110 20 ospf-ext
*> 1.1.1.200/32 101.20.12.20 110 20 ospf-ext
*> 1.1.1.200/32 101.20.13.20 110 20 ospf-ext
*> 1.1.1.200/32 101.20.14.20 110 20 ospf-ext
Dest IP address of the destination
Gw and NextHop Next hop IP address
Interface IP address of the next hop egress interface
Owner Route source, that is, a routing protocol or keyword
Pri and RoutePrf Management distance of the information source, that is, the priority
Metric and RouteMetric Route metric
An example of the show running-config command output is shown below.

ZXR10(config-router)#show running-config
8-5

router ospf 1
maximum-paths 2
......
maximum-paths 2 OSPF supports 2 route entities for load sharing at most.
8.4 Route Load Sharing Configuration Examples

OSPF Route Load Sharing Configuration Example
Load sharing makes the traffic that exceeds the bandwidth on a single interface be
shared on several links. In this way, traffic can be balanced on the links.
As shown in Figure 8-1, take OSPF as an example. In an area, there are several
links reaching the same destination. The costs of the links are the same. Enable load
sharing to realize OSPF load sharing.
Figure 8-1 OSPFv2 Route Load Sharing Configuration Example
1. Configure an interface and set the load sharing of per-packet mode (By default,
it is per-destination).
2. Enable and configure OSPF
3. Configure OSPF load sharing on R1
R1(config-ospfv2)#network 101.2.1.0 0.0.0.255 area 0
R1(config-ospfv2)#maximum-paths 2
8-6


R2(config-ospfv2)#end
Use the show command to check the configuration result, as shown below.
R1#show ip forwarding route ospf
IPv4 Routing Table:
1.1.1.200/32 101.2.1.200 vlan1 OSPF 110 2
1.1.1.200/32 102.2.1.200 vlan2 OSPF 110 2
BGP4+ Route Load Sharing Configuration Example

Load sharing makes the traffic that exceeds the bandwidth on a single interface be
shared on several links. In this way, traffic can be balanced on the links.
As shown in Figure 8-2, take BGP4+ as an example. In an area, there are several
links reaching the same destination. The costs of the links are the same. Enable load
sharing to realize BGP4+ load sharing.
Figure 8-2 BGP4+ Route Load Sharing Configuration Example
1. Configure an interface and set the load sharing of per-packet mode (By default,
it is per-destination).
2. Enable and configure BGP4+
3. Configure BGP4+ load sharing on R1
8-7


R1(config-if-vlan1)#ipv6 enable
R1(config-if-vlan1)#ipv6 address 2000::1/64
R1(config-bgp)#neighbor 2000::2 remote-as 100
R1(config-bgp)#address-family ipv6
R1(config-bgp-af)#maximum-paths ibgp 16
R1(config-bgp-af)#neighbor 2000::2 activate
R1(config-bgp-af)#ned
R2(config-bgp)#address-family ipv6
R2(config-bgp-af)#maximum-paths ibgp 16
R2(config-bgp-af)#end
Advertise EBGP routes on R2. Use the show command to check the configuration
result, as shown below.
R1#show ipv6 forwarding route bgp
IPv6 Routing Table:
Dest Owner Metric
Interface Gw
2000:0:0:1::/64 bgp 0
vlan1 fe80:12::1
8-8

vlan2 fe80:16::1
8-9

8-10

Chapter 9
Multicast Load Sharing
Configuration
Table of Contents
Multicast Load Sharing Overview ...............................................................................9-1
Configuring Multicast Load Sharing ............................................................................9-2
Multicast Load Sharing Maintenance ..........................................................................9-2
Multicast Load Sharing Configuration Example...........................................................9-3
9.1 Multicast Load Sharing Overview

A switch forwards IP packets according to the IP routing table. In a routing table, when
there are several paths to the same destination prefix, the priorities of the paths may be
the same or different. A switch always selects the routes with the highest priority as the
action path. When there are several path with the same highest priority, the router can
share the traffic to the destination prefix on the paths to perform load sharing.
In multicast applications, there may be a network structure that is shown in Figure 9-1.
On this network, the RPF routes from Router 2 to Source 1 and Source 2 are Equal-Cost
Muti-Path routing (ECMP) (the routes correspond to egress I0 and I1). When multicast
finds the route to Source 1, it may select an equal-cost route (assume that the egress is
I0), and then this routes is recorded. The next time when the protocol triggers to search
for the routes to Source 1, PIM searches the route among the unicast routes recorded
locally. In this way, each time the egress is I0 and all traffic goes through the same route.
However, the other routes is idle.
Figure 9-1 Multicast Load Sharing Principle
To solve the problem described above, L3 multicast load sharing solution is introduced.
9-1

9.2 Configuring Multicast Load Sharing

To configure multicast load sharing on ZXR10 8900E, use the following commands.
Command Function
ZXR10(config-mcast)#multipath Enables load sharing according to

three different Hash algorithms.
ZXR10(config-mcast)#multipath s-g-hash basic
ZXR10(config-mcast)#multipath s-g-hash next-hop-based
ZXR10(config-mcast)#no multipath This disables multicast load

sharing.
9.3 Multicast Load Sharing Maintenance

ZXR10 8900E provides the following command to maintain multicast load sharing.
Command Function
ZXR10#show ip mroute nexthop [<destination-address>] This shows the information of

multicast next hop.
Parameter descriptions:
<destination-address> Destination address, in the dotted decimal notation
An example of the show ip mroute nexthop command output is shown below.

ZXR10(config)#show ip mroute nexthop
IP Multicast Nexthop Table
FLAG of ECMP: L:Local, C:Connect, S:Static
U:Unicast, UR:Unicast unreachable, UG:Unicast no response
SUR:Static unreachable, SNR:Static nexthop should be replaced
Dest address: 10.40.50.24
Owner: /PIMDM Flag : /U/UR/UG
Metric: 4294967295, Preference: 255
Ecmp list:
Dest address: 35.1.1.2
Owner: /PIMDM Flag : /U
Metric: 0, Preference: 1
Ecmp list:
Nexthop: 1.1.1.4, Oif: vlan1
9-2

Chapter 9 Multicast Load Sharing Configuration
FLAG of ECMP ECMP identifier. L: local; C: connection; S: static; U: unicast; UR:

unreachable unicast; UG: no response to unicast; SUR: static
unreachable; SNR: static next hop should be replaced.
9.4 Multicast Load Sharing Configuration Example

When there are more than one routes from the source to the last hop route, multicast load
sharing can be configured to make traffic reach the user along different paths. As shown
in Figure 9-2, the source sends several groups of multicast traffic. There are two paths
form the last-hop switch R2 to the source.
Figure 9-2 Multicast Load Sharing Configuration Example
Assume that the two routes are equal-cost for R2, that is, the two routes are ECMP between
R2 and the source. Multicast load sharing can be configured on R2 to make the multicast
traffic of different groups be shared on the two paths.
1. Configure PIM-SM, BSR and RP on the switches to make the user can receive the
multicast traffic sent by the source properly.
2. Configure multicast load sharing on the downstream switch.
switch Interface IP Address Mask
R1 vlan1 172.1.3.44 255.255.255.0
R1 vlan2 172.1.7.44 255.255.255.0
R1 vlan3 172.1.13.44 255.255.255.0
R1 loopback63 44.63.1.1 255.255.255.255
R2 vlan4 172.1.13.46 255.255.255.0
R2 vlan5 172.1.5.46 255.255.255.0
R2 vlan6 172.1.7.46 255.255.255.0
9-3

Configure multicast protocol on R and R2 to create a multicast tree. Here take PIM-SM as
an example.
The configuration of R1 (enable PIM-SM on the interfaces, and configure BSR and RP on
loopback63 interface):
R1(config-mcast)#router pimsm
R1(config-pimsm)#interface vlan1
R1(config-pimsm-if)#pimsm
R1(config-pimsm-if)#exit
R1(config-pimsm)#bsr-candidate loopback63
R1(config-pimsm)#rp-candidate loopback63
The configuration of R2 (Enable PIM-SM on the interfaces. Configure routes to BSR

and RP so that R2 can receive BSR packets properly and multicast routing table can be
created. Configure routes to the source, and make sure that there are two equal-cast
routes between R2 and the source):
R2(config)#ip route 44.63.1.1 255.255.255.255 172.1.7.44
R2(config)#ip route 172.1.3.0 255.255.255.0 172.1.7.44
R2(config)#ip route 172.1.3.0 255.255.255.0 172.1.13.44
Enable load sharing on R2, here take s-g-hash as an example.

R2(config-mcast)#multipath s-g-hash basic
When the user starts to receive the multicast traffic sent from the source, check the routing
tables on R1 and R2. Pay attention to the ingress and egress of the routes.
The multicast routing table on R1 is shown below:
R1#show ip mroute
9-4

Chapter 9 Multicast Load Sharing Configuration
(*, 238.255.255.0), RP: 44.63.1.1, TYPE: DYNAMIC, FLAGS:

Incoming interface: NULL, flags:
Outgoing interface list:
vlan2, flags: F
(172.1.3.49, 238.255.255.0), RP: 44.63.1.1, TYPE: DYNAMIC, FLAGS:
Incoming interface: vlan1, flags:
vlan3, flags: F
(*, 238.255.255.1), RP: 44.63.1.1, TYPE: DYNAMIC, FLAGS:
Incoming interface: NULL, flags:
vlan2, flags: F
vlan2, flags: F
......
The multicast routing table on R2 is shown below:

R2#show ip mroute
IP Multicast Routing Table
(*, 238.255.255.0), RP: 44.63.1.1, TYPE: DYNAMIC, FLAGS: NS
Incoming interface: vlan6, flags: NS
vlan5, flags: F
vlan5, flags: F
(*, 238.255.255.1), RP: 44.63.1.1, TYPE: DYNAMIC, FLAGS: NS
Incoming interface: vlan6, flags: NS
vlan5, flags: F
vlan5, flags:
......
9-5

9-6

Chapter 10
SQA Configuration
Table of Contents
SQA Overview..........................................................................................................10-1
Configuring SQA ......................................................................................................10-1
SQA Maintenance ....................................................................................................10-4
SQA Configuration Examples ...................................................................................10-6
10.1 SQA Overview

Service Quality Analyzer (SQA) is a measured detection technology. Through SQA, users
can obtain more detailed network quality analysis at IP layer, and can also check whether
the network quality of a specific service meets the requirement of Service Level Agreement
(SLA). The functions of SQA are listed below.
l Users can know the network performance in time and then take corresponding
measures according to different network performances.
l Users can use SQA to diagnose and locate network faults, especially for QoS faults
of some applications.
l SQA supports linkage of some protocols. For example, when the quality of a network
worsens to some extent, SQA can enable linkage with policy routing.
SQA is not used very frequently in most situations. Usually, it is used to diagnose network
faults.
For example, on a mobile IP bearer network, when the quality of phone calls declines
seriously, it is necessary to check whether there is serious voice packet loss, delay and
oscillation at the wireless network side and IP bearer network side at the same time. At
the IP bearer network side, it is necessary to check whether there is any serious network
fault for the transmission of IP packets between CEs. Meanwhile, it is also necessary to
use the parameters (such as UDP packet oscillation and delay ) of SLA to judge whether
the fault is on the bearer network side.
SQA can also be used to detect the network qualities of operators periodically to reflect the
network qualities in real time, so that operators can master the overall network qualities.
SQA is not used very frequently, so it should not be too difficult. Meanwhile, SQA has strict
security limit requirement for the packets forwarded by SLA for handling.
10.2 Configuring SQA

To configure SQA on ZXR10 8900E, perform the following steps.
10-1

1 ZXR10(config)#sqa-test <number> Configures a SQA test instance

and enters SQA configuration
mode. The range of the
<number> parameter is 1-150.
2 ZXR10(config-sqa)#type-icmp [vrf <vrf-name>]<de Configures an ICMP test

stination-address>[{[source <source-address>],[repeat instance in SQA configuration
<repeat-number>],[tos <tos-value>],[ttl <ttl-value>],[size < mode.
size-value>],[interval <interval-value>]}]
ZXR10(config-sqa)#type-udp [ vrf <vrf-name>]<destinatio Configures a UDP test instance

n-address><destination-port>[{[size < size-value>],[interval in SQA configuration mode.
<interval-value>],[repeat <repeat-number>]}]
ZXR10(config-sqa)#type-tcp [ vrf <vrf-name>]<destination-a Configures a TCP test instance

ddress><destination-port>[{[interval <interval-value>],[repeat in SQA configuration mode.
<repeat-number>]}]
ZXR10(config-sqa)#type-ftp copy <destination-address> Configures an FTP test instance

uesr-name <user-name> password <password> file-name in SQA configuration mode.
<file-name> root <local-path>/<file-name>
ZXR10(config-sqa)#type-dns destination-url Configures an DNS test

<destination-url> dns-ip <dns-ip-address>[repeat instance in SQA configuration
<repeat-number>] mode.
3 ZXR10(config-sqa)#sqa-begin {now | timerange This begins a test in SQA

<timerange-name> once} configuration mode.
ZXR10(config-sqa)#sqa-stop This stops a test in SQA

configuration mode.
4 ZXR10(config-sqa)#send-trap {disable|enable}<percent> Enables or disables MIB alarm

in SQA configuration mode.
5 ZXR10(config)#qa-tcp-server [ vrf <vrf-name>]<ipaddres Configures an SQA TCP server.

s><port>
ZXR10(config)#sqa-udp-server [ vrf <vrf-name>]<ipaddres Configures an SQA UDP server.

s><port>
<number> Number of a test example. Range: 1-150.
vrf <vrf-name> VRF name. Range: 1-32.
10-2

Chapter 10 SQA Configuration
<destination-address> For the ICMP, UDP, and TCP detection, it refers to the destination
IP address. For the FTP detection, it refers to the IP address of
the FTP server.
<destination-port> Number of a destination port. Range: 1025-65535.
source <source-address> Source address.
repeat <repeat-number> Number of times that a detection is sent again.

l For the ICMP detection, the range is 1-65535, and the default
value is 1.
l For the UDP detection, the range is 1-1000, and the default
value is 1.
l For the TCP detection, the range is 1-200, and the default
value is 1.
l For the DNS detection, the range is 1-10, and the default
value is 1.
tos <tos-value> ToS value. Range: 0-255, default: 0.
ttl <ttl-value> TTL value. Range: 1-255, default: 255
Size <size-value> Packet size.

l For the ICMP detection packet, the range is 36-8192bytes,
and the default value is 36bytes.
l For the UDP detection packet, the range is 50-1500bytes,
and the default value is 50bytes.
interval <interval-value> Packet sending interval.

l For the ICMP detection packet, the range is 50-65535, and
the default value is 100.
l For the UDP detection packet, the range is 50-2000, and the
default value is 100.
l For the TCP detection packet, the range is 1000-4000, and
the default value is 1000.
uesr-name <user-name> User name of the FTP server. Range: 1-31.
password <password> Password of the FTP server. Range: 1-31.
file-name <file-name> Name of the FTP file. Range: 1-79.
root <local-path>/<file-name> The destination path and name of the destination FTP file. Range:
1-151.
destination-url <destination-url> The name of a domain to be analysed. Range: 1-128.
dns-ip <dns-ip-address> The IP address of a domain server.
10-3

timerange <timerange-name> Name of a Timerange test. Range: 1-31 characters.
now The test is started immediately.
enable <percent> Enables the trap alarm. The range of the alarm threshold is 1-100.
disable Disables the trap alarm. The default value is disable.
vrf <vrf-name> VRF name. Range: 1-32.
<destination-address> The IP address of the server.
<destination-port> The port number of the server. Range: 1025-65535.
10.3 SQA Maintenance

ZXR10 8900E provides the following commands to maintain SQA.
Command Function
ZXR10(config)#show running-config sqa Displays the SQA configuration in other configuration

modes except user configuration mode.
ZXR10(config)#show sqa-test <number> Displays the sqa test configuration information in other
configuration modes except user configuration mode.
Range: 1-150.
ZXR10(config)#show sqa-server Displays the sqa server configuration information in other

{udp|tcp} configuration modes except user configuration mode.
An example of the show running-config sqa command output is shown below.

ZXR10(config)#show running-config sqa
! <SQA>
sqa-test 1
!
sqa-test 2
type-icmp 192.168.1.1 repeat 10
send-trap enable 80
!
sqa-test 50
!
10-4

sqa-test 40
type-icmp 192.168.1.100 repeat 10 source 1.1.1.1
!
sqa-test 10
type-udp 192.168.1.98 10000 repeat 10
send-trap enable 80
!
sqa-test 35
type-tcp 192.168.1.98 10000 repeat 10
!
sqa-test 39
!
! </SQA>
sqa-test 2 The SQA test instance number is 2.
type-icmp 192.168.1.1 repeat 10 The test type is ICMP. The number of retry attempts for the test to
the destination address 192.168.1.1 is 10.
send-trap enable 80 Sending MIB trap information, with the threshold of 80
An example of the show sqa-test 35 command output is shown below.

ZXR10(config)#show sqa-test 35
test type: TCP
destination IP:192.168.1.98
desitnation port:10000
inte-time:100
repeat:10
send trap:disable
test type: TCP The test type is TCP.
destination IP:192.168.1.98 The destination address is 192.168.1.98.
destination port:10000 The destination port number is 10000.
inte-time:100 The interval is 100ms.
repeat:10 The repeated times is 10.
send trap:disable Disables the trap information for the mib.
An example of the show sqa-server udp command output is shown below.

ZXR10(config)#show sqa-server udp
10-5

sqa udp server:

listen IP:192.0.0.100
listen port:1025
An example of the show sqa-server udp command output is shown below.
sqa udp server: The server type is UDP.
listen IP:192.0.0.100 The destination interception address is 192.0.0.100.
listen port:1025 The interception port number is 1025.
10.4 SQA Configuration Examples

ICMP-Type SQA Configuration Example
As shown in Figure 10-1, there is a link between R1 and R3. Packets between R1
and R3 can be forwarded properly.
Figure 10-1 ICMP-Type SQA Configuration Example
1. Create an SQA test instance.
2. Configure the destination address for the ICMP test, and set the ICMP test
attribute.
3. Set the beginning time for the SQA test.
4. Check the test result.
R1(config)#sqa-test 1
R1(config-sqa)#type-icmp 10.1.0.2
R1(config-sqa)#sqa-begin now
The sqa test is starting now, please wait a moment for test result......
R1(config-sqa)#
The configuration and test result are shown below.
R1(config)#show sqa-test 1
test type: ICMP
10-6

destination IP: 10.1.0.2

repeat:1
tos: 0
interval time:100
send trap:disable
R1(config)#show sqa-result icmp
icmp test[1] result
SendPackets:20 ResponsePackets:20
Completion:success Destination IP Address:192.0.0.100
Min/Max/Avg/Sum RTT:29/99/39/787ms
Min/Max/Avg/Sum Positive Jitter:1/7/3/9ms
Min/Max/Avg/Sum Negative Jitter:1/70/35/71ms
Min/Max/Avg/Sum Jitter:1/70/16/80ms
Packet loss rate:0%
Last Probe Time:2011-11-18 01:57:38
FTP-Type SQA Configuration Example

As shown in Figure 10-2, there is a link between R1 and R3. Packets between R1
and R3 can be forwarded properly. Enable FTP server function on R3, and configure
the username and the password.
Figure 10-2 FTP-Type SQA Configuration Example
2. Configure the FTP test attribute, including the address of the FTP server, user
name, password, source file name, destination path, and the name of the
destination file.
R3(config)#ftp-server en
R3(config)#ftp-server top-directory /sysdisk0/
R3(config)#ip ftp username who
R3(config)#ip ftp password who

10-7

R1(config-sqa)#type-ftp copy 10.1.0.2 username who password who

filename abc root /sysdisk0/abc
R1(config-sqa)#
test type: FTP
ftp IP:10.1.0.2
username:who
password:who
filename:abc.txt
path:/sysdisk0/abc.txt
R1(config)#show sqa-result ftp
ftp test[2] result is finished
Last RTT:127..Bytes read:4817497
Last Probe Time:2010-07-29 09:22:58
TCP-Type SQA Configuration Example

As shown in Figure 10-3, there is a link between R1 and R3. Packets between R1 and
R3 can be forwarded properly. Enable a monitoring port pf SQA-TCP-server on R3.
Figure 10-3 TCP-Type SQA Configuration Example
2. Configure the destination address and the port for the TCP test, and set the TCP
test attribute.
R3(config)#sqa-tcp-server 10.1.0.2 10000

R1(config-sqa)#type-tcp 10.1.0.2 10000
10-8

R1(config-sqa)#
test type: TCP
inteinterval time:1000
repeat:1
send trap:disable
R1(config)#show sqa-result tcp
tcp test[3] result is finished
SendPackets:1..ResponsePackets:1
Completion:success....Destination ip IP Aaddress:10.1.0.2
Last Probe Time:2010-07-29 09:45:49
UDP-Type SQA Configuration Example

As shown in Figure 10-4, there is a link between R1 and R3. Packets between R1 and
R3 can be forwarded properly. Enable a monitoring port of SQA-UDP-server on R3.
Figure 10-4 UDP-Type SQA Configuration Example
2. Configure the destination address and the port number for the UDP test, and set
the UDP test attribute.
R3(config)#sqa-udp-server 10.1.0.2 10000

R1(config-sqa)#type-udp 10.1.0.2 10000
10-9

R1(config-sqa)#
test type: UDP
interval time:100
repeat:1
send trap:disable
R1(config)#show sqa-result udp
ZXR10(config)#show sqa-result udp
udp test[2] result
Completion:success Destination IP Address:192.0.0.111
Min/Max/Avg/Sum Positive Jitter:0/0/0/0ms
Min/Max/Avg/Sum Negative Jitter:1/1/1/2ms
Min/Max/Avg/Sum Jitter:1/1/1/2ms
Packet loss rate:0%
Last Probe Time:2011-09-01 23:52:35
DNS-Type SQA Configuration Example

Figure 10-5 shows an SQA test example on the ZXR10 8900E. Connect the server
to the router, and the configure the IP address. To send DNS packets to the server,
configure the router to the server.
Figure 10-5 DNS-Type SQA Configuration Example
2. Configure the name for the domain to be analysed for the DNS test and the IP
address for the DNS server, and set the times for domain analysis.
10-10


R1(config)#ip domain lookup
R1(config)#ip domain name-server ipv4-address 10.1.0.1
R1(config-sqa)#type-dns destination-url abc.cn dns-ip 10.1.0.1
R1(config-sqa)#
test type: DNS
destination-url:abc.cn
dns-ip:10.1.0.1
repeat:1
send trap:disable
R1(config)#show sqa-result dns
dns test[5] result
Completion:success
Destination-url:abc.cn
DNS Interpret IP Address:192.0.0.100
Last Probe Time:2011-07-29 09:49:36
10-11

10-12

Chapter 11
UDLD Configuration
Table of Contents
UDLD Overview .......................................................................................................11-1
Configuring UDLD ....................................................................................................11-2
UDLD Maintenance ..................................................................................................11-4
UDLD Configuration Examples.................................................................................11-5
11.1 UDLD Overview

As the Ethernet technology has been widely applied, the network has higher and higher
requirement on Ethernet reliability. Under such circumstance, various technologies for
ensuring normal operation of the Ethernet emerge. The UniDirectional Link Detection
(UDLD) protocol is one of these protocols.
The UDLD is an L2 protocol working at the upper layer of the LLC. It is used to detect
unidirectional link faults and thus avoids the problems such as Ethernet loop and route
blackhole caused by a unidirectional link fault.
By creating a neighbor and detecting L2 logical connectivity to the neighbor, the UDLD
checks whether a unidirectional link fault exists on an Ethernet interface. The UDLD
protocol works together with interface detection protocols such as FDFI and automatic
negotiation at the physical layer. In this way, they can verify the integrity of an Ethernet
link at the physical layer and the logical layer. In addition, the UDLD performs logical
detection and therefore it has some functions that are not supported by physical-layer
interface detection layers. To be specific, it can detect the faults caused by incorrect
manual configuration or connection.
The UDLD is an L2 logical link detection protocol. It can detect the logical connectivity
of Ethernet links and meanwhile verify the physical connectivity. Different from physical
connectivity detection, the UDLD performs detection based on neighbors. The L1 devices
are transparent to the UDLD.
The UDLD detection firstly creates a neighboring relation with an adjacent L2 device. When
an Ethernet interface whose state is up enables the UDLD function, the interface will send
a Hello packet of neighbor join-in to notify its adjacent device. The interface with the UDLD
function enabled on the adjacent device responds with an Echo packet after receiving the
Hello packet. After receiving the Echo packet, the device has created the neighboring
relation with its peer device.
After the neighboring relation is created, the unidirectional link detection starts. The
Ethernet interface with the UDLD function enabled periodically sends Hello packets
and wait for the Echo packet from the neighbor device. If the Echo packet is received
11-1

normally, it indicates that Ethernet link of this interface is reachable bidirectionally. If the
Echo packet fails to be received or the link is reachable unidirectionally according to the
received packet, the UDLD takes measures according to the configured working mode.
The UDLD supports two working modes: normal mode and aggressive mode. In the
normal mode, the UDLD makes an interface down after the interface receives the Echo
packet and confirms that the link is reachable unidirectionally. The UDLD does not perform
any operation when the interface cannot receive the Echo packet or fails to confirm that the
link is reachable unidirectionally. In the aggressive mode, the UDLD makes an interface
down if the interface cannot confirm that the link is reachable bidirectionally. The common
point of the two modes is that the system generates an alarm if the interface fails to confirm
that the link works normally.
When the interface is down or cannot be used due to other reasons, the device will send
a flush packet to notify the adjacent L2 device to delete the information of this device.
11.2 Configuring UDLD

On the ZXR10 8900E, use the following commands to configure UDLD properties.
Steps Command Function
1 ZXR10(config)#udld Enters the UDLD config mode.
2 ZXR10(config-udld)#interface <interface-name > Enters the UDLD interface

config mode.
3 ZXR10(config-udld)#udld { enable | disabl Enables or disables the

e}<interface_range> UDLD detection function of an
interface.
4 ZXR10(config-udld)#udld message timer Configures the interval of

<timer><interface_range> sending Hello packets.
5 ZXR10(config-udld)#udld mode {aggressive | Configures the UDLD protocol

normal}<interface_range> mode of an interface.
6 ZXR10(config-udld)#udld recovery {enable | Enables the UDLD automatic

disable}<interface_range> recovery function of an
interface.
7 ZXR10(config-udld)#udld recovery timer Configures the interval of

<timer><interface_range> automatic recovery when the
UDLD protocol running on an
interface is in the unidirectional
state.
8 ZXR10#udld reset <interface name> This resets an interface in the

unidirectional state.
11-2

Chapter 11 UDLD Configuration
Steps Command Function
9 ZXR10(config-udld-if)#udld dos protect{ enable | Enables or disables the

disable} anti-DoS attack function in the
interface config mode.
The command parameters in step 2 are described as follows.
<interface name> Configures the interface names.
enable Enables the function of unidirectional link detection.
disable Disables the function of unidirectional link detection.
<interface_range> Configures the range of interface names. Up to 16 interfaces

can be configured at a time.
<time> Configures the interval of sending Hello packets when the

interface works in the bidirectional state. The value of this
parameter ranges from 7 to 90.
<interface_range> Configures the range of interface names. Up to 16 interfaces

can be configured at a time.
aggressive Indicates that the UDLD of an interface works in the

aggressive mode.
normal Indicates that the UDLD of an interface works in the normal

mode.
<interface_range> Configures the range of interface names.
enable Enables the UDLD automatic recovery function.
disable Disables the UDLD automatic recovery function.
11-3

<time> Configures the interval of interface recovery when an

interface works in the unidirectional state. The value of this
parameter ranges from 10 to 600.
interface Re-configure the name of an interface.
11.3 UDLD Maintenance

On the ZXR10 8900E, use the following commands to maintain the UDLD.
Command Function
ZXR10#show udld <interface-name> This shows the UDLD neighbor information of an interface.
An example of the show udld command output is shown below.

ZXR10(config)#show udld gei-0/1/0/1
Interface gei-0/1/0/1
Administrative configuration: Enable
Port mode: Normal
Current state: Bidirection
Recovery configuration: Disable
Auto-recovery time: 30s
Message interval: 15s
Entry 1
--------------------
Device ID: ZTE0000.0100.9902
Device name: ZTE
Port ID: gei-0/1/0/1
Expiration time: 31s
Timeout interval: 5s
Neighbour echo 1 device: ZTE0009.9100.0106

Neighbour echo 1 port: gei-0/1/0/1
11-4

Chapter 11 UDLD Configuration
11.4 UDLD Configuration Examples

UDLD Configuration Example (1): Configuring UDLD Neighbor
As shown in Figure 11-1, enable the UDLD function of an interface.
Figure 11-1 Configuring UDLD Neighbor
1. Enter the UDLD config mode.
2. Enter the config mode of an interface.
3. Enable the UDLD function.
Method 1: In the UDLD config mode, enter the config mode of an interface to enable
the UDLD function.
ZXR10(config)#udld
ZXR10(config-udld)#interface gei-0/1/0/1
ZXR10(config-udld-if)#udld enable
Method 2: In the UDLD config mode, enable the UDLD function of an interface.
ZXR10(config-udld)#udld enable interface gei-0/1/0/1
Use the show udld neighbor command to view the configuration result.
ZXR10(config-udld)#show udld gei-0/1/0/1
Interface gei-0/1/0/1
Administrative configuration: Enable
Port mode: Normal
Current state: Bidirection
Recovery configuration: Disable
Auto-recovery time: 30s
Entry 1
--------------------
Device ID: ZTE0000.0100.9902
Device name: ZTE
Port ID: gei-0/1/0/1
Expiration time: 44s
11-5


Timeout interval: 5s
Neighbour echo 1 device: ZTE0009.9100.0106

Neighbour echo 1 port: gei-0/1/0/1
UDLD Configuration Example (2): Configuring Common Properties of UDLD

Configure common properties of UDLD.
1. Enter the UDLD config mode.
2. Enter the config mode of an interface.
3. Configure the properties of UDLD.
ZXR10(config)#udld
ZXR10(config-udld)#interface gei-0/1/0/1
/*Enter the interface config mode of UDLD*/
ZXR10(config-udld-if)#udld message timer 10
/*Configure the interval of sending Hello packets in the case of bidirectional
UDLD communication*/
ZXR10(config-udld-if)#udld mode aggressive
/*Configure the interface protocol mode of UDLD*/
ZXR10(config-udld-if)#udld recovery timer 100
/*Configure the interval of automatic recovery in the case of unidirectional
UDLD communication*/
ZXR10(config-udld-if)#udld recovery enable
/*Enable automatic recovery function of UDLD*/
Use the show running-config udld command to view the configuration result.
ZXR10(config-udld-if)#show running-config udld
! <UDLD>
udld
interface gei-0/1/0/1
udld enable
udld mode aggressive
udld message timer 10
udld recovery enable
udld recovery timer 100
$
!
! </UDLD>
11-6

Figures
Figure 1-1 Default Network Gateway in LAN ............................................................. 1-1
Figure 1-2 VRRP Working Principle .......................................................................... 1-2
Figure 1-3 State Conversion in VRRP....................................................................... 1-4
Figure 1-4 Application of VRRP Monitoring Interface ................................................ 1-5
Figure 1-5 Application of VRRP Load Sharing........................................................... 1-5
Figure 1-6 EOAM for VRRP Application (1)............................................................... 1-6
Figure 1-7 VRRP and EOAM State Transfer ............................................................. 1-7
Figure 1-8 EOAM for VRRP Application (2)............................................................... 1-7
Figure 1-9 VRRP and EOAM + Peer BFD State Transfer .......................................... 1-8
Figure 1-10 EOAM for VRRP Application Three........................................................ 1-8
Figure 1-11 Basic VRRP Configuration (IPv4) ......................................................... 1-17
Figure 1-12 Symmetrical VRRP Configuration (IPv4) .............................................. 1-19
Figure 1-13 VRRP Heartbeat Configuration (IPv4) .................................................. 1-21
Figure 1-14 VRRP Track Configuration (IPv4)......................................................... 1-23
Figure 1-15 Basic VRRP Configuration (IPv6)......................................................... 1-25
Figure 1-16 Symmetrical VRRP Configuration (IPv6) .............................................. 1-27
Figure 1-17 VRRP Heartbeat Configuration (IPv6) .................................................. 1-29
Figure 1-18 VRRP Track Configuration (IPv6)......................................................... 1-31
Figure 2-1 Active/Standby Main Control Changeover ................................................ 2-2
Figure 3-1 EFM Principle .......................................................................................... 3-2
Figure 3-2 EFM Connection Establishment Configuration Example........................... 3-7
Figure 3-3 EFM Remote Loopback Configuration Example ..................................... 3-11
Figure 4-1 Maintenance Domain ............................................................................... 4-2
Figure 4-2 CFM Connection Establishment............................................................. 4-10
Figure 4-3 Cross-L2 VPN Connectivity Detection Configuration Example................ 4-14
Figure 5-1 Linkage Between VRRP, SAMGR, or EOAM and BFD ............................. 5-3
Figure 5-2 Linkage of Symmetrical Dual-Connection Between CE and PE................ 5-3
Figure 5-3 Linkage Between EFM and VRRP ......................................................... 5-12
Figure 5-4 Linkage Between CFM and VRRP ......................................................... 5-16
Figure 6-1 ISIS BFD Configuration Example ............................................................. 6-8
Figure 6-2 OSPF BFD Configuration Example ........................................................ 6-10
Figure 6-3 RIP BFD Configuration Example ............................................................ 6-11

Figure 6-4 Configuring a Single-hop BFD for the BGP Route .................................. 6-14
Figure 6-5 Configuring a Multihop-BFD for the BGP Route ..................................... 6-16
Figure 6-6 Configuring a Static Route BFD ............................................................. 6-18
Figure 6-7 Configuring PIM BFD ............................................................................. 6-20
Figure 6-8 Configuring the LDP BFD....................................................................... 6-23
Figure 6-9 Configuring the PEER BFD.................................................................... 6-25
Figure 6-10 Configuring the Static Single-Hop BFD ................................................ 6-28
Figure 6-11 Configuring the Static MultiHop BFD .................................................... 6-30
Figure 6-12 Configuring the BFD Function for the RSVP Interface .......................... 6-34
Figure 6-13 Configuring the RSVP LSP BFD .......................................................... 6-36
Figure 6-14 Configuring the Link BFD Relating to the VRRP................................... 6-41
Figure 6-15 Configuring the VPWS BFD ................................................................. 6-43
Figure 7-1 Network Structure of FRR Node Protection .............................................. 7-6
Figure 7-2 Network Structure of FRR Link Protection ................................................ 7-6
Figure 7-3 L2VPN FRR Principle ............................................................................ 7-10
Figure 7-4 VPLS FRR Configuration Example......................................................... 7-12
Figure 7-5 VPN/BGP Neighbors.............................................................................. 7-14
Figure 7-6 L3 VPN FRR Configuration Example ..................................................... 7-18
Figure 7-7 FRR Though Bypass Mode.................................................................... 7-26
Figure 7-8 FRR in Bypass Mode ............................................................................. 7-27
Figure 7-9 TE-FRR Configuration Example............................................................. 7-33
Figure 8-1 OSPFv2 Route Load Sharing Configuration Example .............................. 8-6
Figure 8-2 BGP4+ Route Load Sharing Configuration Example ................................ 8-7
Figure 9-1 Multicast Load Sharing Principle .............................................................. 9-1
Figure 9-2 Multicast Load Sharing Configuration Example ........................................ 9-3
Figure 10-1 ICMP-Type SQA Configuration Example .............................................. 10-6
Figure 10-2 FTP-Type SQA Configuration Example ................................................ 10-7
Figure 10-3 TCP-Type SQA Configuration Example................................................ 10-8
Figure 10-4 UDP-Type SQA Configuration Example ............................................... 10-9
Figure 10-5 DNS-Type SQA Configuration Example ............................................. 10-10
Figure 11-1 Configuring UDLD Neighbor................................................................. 11-5
II

Glossary
3G
- The 3rd Generation Mobile Communications
AC
- Access Circuit
APS
- Automatic Protection Switching
ARP
- Address Resolution Protocol
BFD
- Bidirectional Forwarding Detection
CCM
- Continuity Check Message
CFM
- Connectivity Fault Management
C-VLAN
- Customer VLAN
ECMP
- Equal-Cost Multi-Path routing
EFM
- Ethernet in the First Mile
ERO
- Explicit Route Object
FIB
- Forwarding Information Base
FRR
- Fast Reroute
IBGP
- Interior Border Gateway Protocol
IEEE
- Institute of Electrical and Electronics Engineers
IGP
- Interior Gateway Protocol
IPTV
- Internet Protocol Television
III

ITU
- International Telecommunications Union
LAN
- Local Area Network
LBM
- Loopback Message
LDP
- Label Distribution Protocol
LSP
- Label Switched Path
LTM
- Link Trace Message
LTR
- Link Trace Reply
MAC
- Media Access Control
MAN
- Metropolitan Area Network
MIP
- Maintenance domain Intermediate Point
MP
- Merge Point
NGN
- Next Generation Network
OAM
- Operation, Administration and Maintenance
PDU
- Protocol Data Unit
PLR
- Point of Local Repair
PTN
- Packet Transport Network
PWE3
- Pseudo Wire Emulation Edge-to-Edge
QoS
- Quality of Service
RFC
- Request For Comments
IV

Glossary
RIPng
- Routing Information Protocol next generation
RSVP
- Resource Reservation Protocol
SLA
- Service Level Agreement
TTL
- Time To Live
VLAN
- Virtual Local Area Network
VoIP
- Voice over Internet Protocol
VPWS
- Virtual Private Wire Service
VRRP
- Virtual Router Redundancy Protocol
WAN
- Wide Area Network

SJ-20121213142710-016-ZXR10 8900E (V3.01.01) Series Core Switch Configuration Guide (Reliablity) - 548073

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SJ-20121213142710-016-ZXR10 8900E (V3.01.01) Series Core Switch Configuration Guide (Reliablity) - 548073

Uploaded by

Copyright:

Available Formats

ZXR10 8900E

Series Core Switch

Revision No. Revision Date Revision Reason

R1.0 20130624 First edition

Serial Number: SJ-20121213142710-016

Publishing Date: 2013-06-24 (R1.0)

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

Chapter 2 Active/Standby Main Control Changeover ............................. 2-1

Chapter 3 EFM Configuration.................................................................... 3-1

Chapter 4 CFM Configuration.................................................................... 4-1

Chapter 5 SAMGR Configuration .............................................................. 5-1

Chapter 6 BFD Configuration .................................................................... 6-1

Chapter 7 FRR Configuration .................................................................... 7-1

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

Chapter 8 Route Load Sharing Configuration ......................................... 8-1

Chapter 9 Multicast Load Sharing Configuration.................................... 9-1

Chapter 10 SQA Configuration................................................................ 10-1

Chapter 11 UDLD Configuration.............................................................. 11-1

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

What Is in This Manual

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

| Separates individual parameter in series of parameters.

Note: provides additional information about a certain topic.

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

1.1 VRRP Overview

Figure 1-1 Default Network Gateway in LAN

A common method to improve system reliability is to configure multiple egress network

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

In LANs with multicasting or broadcasting ability (such as Ethernet), VRRP provides a

Figure 1-2 VRRP Working Principle

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

When the master switch works properly, it sends a VRRP multicasting

When a switch is in Backup state, it does the following work:

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

4. It drops IP messages of which the destination IP address is the virtual IP

Figure 1-3 State Conversion in VRRP

l Practical Network Application

For an application of VRRP monitoring interface, see Figure 1-4.

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

Figure 1-4 Application of VRRP Monitoring Interface

Figure 1-5 Application of VRRP Load Sharing

The load sharing function has the following features:

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

Figure 1-6 EOAM for VRRP Application (1)

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

Figure 1-7 VRRP and EOAM State Transfer

Figure 1-8 EOAM for VRRP Application (2)

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

Figure 1-9 VRRP and EOAM + Peer BFD State Transfer

Figure 1-10 EOAM for VRRP Application Three

1.2 Configuring VRRP

Step Command Function

1 ZXR10(config)#vrrp Enters VRRP configuration

2 ZXR10(config-vrrp)#interface <interface-name> Enters VRRP interface

SJ-20121213142710-016|2013-06-24 (R1.0) ZTE Proprietary and Confidential

Step Command Function

3 ZXR10(config-vrrp-if)#vrrp <group>{ipv4|ipv6}<ip-add Enables VRRP in VRRP

4 ZXR10(config-vrrp-if)#vrrp <group> priority <level> Configures VRRP priority in

5 ZXR10(config-vrrp-if)#vrrp <group> preempt [delay Configures VRRP group

6 ZXR10(config-vrrp-if)#vrrp <group> timers advertise Configures the interval to

7 ZXR10(config-vrrp-if)#vrrp <group> timers learn Configures the learning of