Configuration Guide - Reliability (V200R001C00 - 01) PDF

S9700 Core Routing Switch
V200R001C00
Configuration Guide - Reliability
Issue 01
Date 2012-03-15
HUAWEI TECHNOLOGIES CO., LTD.

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

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

Copyright Huawei Technologies Co., Ltd.
Configuration Guide - Reliability About This Document
About This Document
Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the reliability supported by the S9700.
This document describes how to configure the reliability.
This document is intended for:
l Data configuration engineers

l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk, which if not

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

if not avoided, could result in minor or moderate injury.
WARNING
Indicates a potentially hazardous situation, which if not

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

important points of the main text.
Issue 01 (2012-03-15) Huawei Proprietary and Confidential ii

Configuration Guide - Reliability About This Document
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all changes made in previous issues.
Changes in Issue 01 (2012-03-15)

Initial commercial release.
Issue 01 (2012-03-15) Huawei Proprietary and Confidential iii

Configuration Guide - Reliability Contents
Contents
About This Document.....................................................................................................................ii

1 DLDP Configuration.....................................................................................................................1
1.1 Introduction to DLDP.........................................................................................................................................2
1.2 Configuring DLDP Functions............................................................................................................................3
1.2.1 Establishing the Configuration Task.........................................................................................................3
1.2.2 Enabling DLDP.........................................................................................................................................3
1.2.3 (Optional) Setting the Operating Mode of DLDP.....................................................................................4
1.2.4 (Optional) Enabling DLDP Compatible Mode..........................................................................................5
1.2.5 (Optional) Setting the Interval for Sending Advertisement Packets.........................................................6
1.2.6 (Optional) Setting the Delay Down Timer................................................................................................6
1.2.7 (Optional) Setting the Interface Blocking Mode.......................................................................................7
1.2.8 (Optional) Setting the Authentication Mode of DLDP Packets................................................................8
1.2.9 Checking the Configuration.......................................................................................................................8
1.3 Resetting the DLDP Status.................................................................................................................................9
1.3.1 Establishing the Configuration Task.........................................................................................................9
1.3.2 Resetting the DLDP Status Globally.........................................................................................................9
1.3.3 Resetting the DLDP Status of an Interface..............................................................................................10
1.3.4 Checking the Configuration.....................................................................................................................10
1.4 Maintaining DLDP...........................................................................................................................................11
1.4.1 Clearing the Statistics of DLDP..............................................................................................................11
1.5 Configuration Examples...................................................................................................................................12
1.5.1 Example for Configuring DLDP.............................................................................................................12
2 Smart Link and Monitor Link Configuration........................................................................15

2.1 Smart Link and Monitor Link...........................................................................................................................16
2.2 Configuring a Smart Link Group......................................................................................................................16
2.2.1 Establishing the Configuration Task.......................................................................................................16
2.2.2 Creating and Enabling a Smart Link Group............................................................................................18
2.2.3 Configuring the Master and Slave Interfaces in a Smart Link Group.....................................................18
2.2.4 Enabling the Sending of Flush Packets...................................................................................................19
2.2.5 (Optional) Configuring Load Balancing in a Smart Link Group............................................................20
2.2.6 (Optional) Enabling Revertive Switching and Setting the WTR Time...................................................21
2.2.7 (Optional) Enabling the Receiving of Flush Packets...............................................................................22
Issue 01 (2012-03-15) Huawei Proprietary and Confidential iv

2.2.8 (Optional) Enabling a Physical Interface to Notify the VPLS orVLL Module When Receiving a Flush
Packet................................................................................................................................................................23
2.2.9 (Optional) Setting the Holdtime of the Smart Link Switchover..............................................................23
2.2.10 Enabling the Functions of the Smart Link Group..................................................................................24
2.2.11 Checking the Configuration...................................................................................................................24
2.3 Configuring a Flow Control Policy in a Smart Link Group.............................................................................25
2.3.2 Locking Data Flows on the Master Interface..........................................................................................26
2.3.3 Locking Data Flows on the Slave Interface.............................................................................................27
2.3.4 Switching Data Flows Manually.............................................................................................................27
2.4 Configuring a Monitor Link Group..................................................................................................................28
2.4.2 Creating a Monitor Link Group...............................................................................................................30
2.4.3 Configuring the Uplink and Downlink Interfaces in a Monitor Link Group..........................................30
2.4.4 Setting the Revertive Switching Interval of a Monitor Link group.........................................................31
2.5 Maintaining the Smart Link..............................................................................................................................32
2.5.1 Debugging the Smart Link......................................................................................................................32
2.6.1 Example for Configuring Load Balancing Between Active and Standby Links of a Smart Link Group
..........................................................................................................................................................................33
2.6.2 Example for Connecting the CE to the VPLS in Dual-Homing Mode Through Smart Link..................37
2.6.3 Example for Associating Smart Link with Multicast Services................................................................41
2.6.4 Example for Applying the Smart Link Functions...................................................................................47
3 ERPS (G.8032) Configuration....................................................................................................53

3.1 Overview of ERPS............................................................................................................................................54
3.2 ERPS Features Supported by the S9700...........................................................................................................56
3.3 Configuring ERPS............................................................................................................................................59
3.3.2 Creating an ERPS Ring...........................................................................................................................60
3.3.3 Configuring Control VLAN....................................................................................................................61
3.3.4 Configuring the Mapping Between Protected Instances and VLANs.....................................................62
3.3.5 Adding Layer 2 Ports to ERPS Ring and Configuring Port Roles..........................................................63
3.3.6 (Optional) Configuring Timers of an ERPS Ring...................................................................................64
3.3.7 (Optional) Configuring the MEL Value of an ERPS Ring......................................................................65
3.4 Maintaining EPRS............................................................................................................................................67
3.4.1 Clearing ERPS Statistics.........................................................................................................................67
3.5.1 Example for Configuring ERPS..............................................................................................................68
4 RRPP Configuration...................................................................................................................77
Issue 01 (2012-03-15) Huawei Proprietary and Confidential v

4.1 Overview of RRPP...........................................................................................................................................78

4.2 RRPP Features Supported by the S9700..........................................................................................................78
4.3 Configuring RRPP Functions...........................................................................................................................84
4.3.2 Creating Instances....................................................................................................................................84
4.3.3 Configuring Interfaces on the RRPP Ring..............................................................................................85
4.3.4 Creating the RRPP Domain.....................................................................................................................86
4.3.5 Creating the Control VLAN....................................................................................................................87
4.3.6 Specifying Protected VLANs..................................................................................................................88
4.3.7 (Optional) Setting the Operation Mode of RRPP....................................................................................88
4.3.8 Creating an RRPP Ring...........................................................................................................................89
4.3.9 Enabling the RRPP Ring.........................................................................................................................90
4.3.10 Enabling RRPP......................................................................................................................................91
4.3.11 (Optional) Setting the Values of RRPP Domain Timers.......................................................................91
4.4 Configuring RRPP Multi-Instance...................................................................................................................93
4.4.2 Creating Instances....................................................................................................................................95
4.4.3 Configuring Interfaces on the RRPP Ring..............................................................................................96
4.4.4 Creating an RRPP Domain......................................................................................................................97
4.4.5 Specifying Protected VLANs..................................................................................................................98
4.4.6 Creating a Control VLAN.......................................................................................................................99
4.4.7 Creating an RRPP Ring...........................................................................................................................99
4.4.8 Enabling the RRPP Ring.......................................................................................................................101
4.4.9 Enabling the RRPP Protocol..................................................................................................................101
4.4.10 (Optional) Creating a RRPP Ring Group............................................................................................102
4.4.11 (Optional) Configuring the Delay for Link Restoration......................................................................102
4.4.12 (Optional) Setting the Hello Timer and Fail Timer of an RRPP Domain...........................................103
4.4.13 Checking the Configuration.................................................................................................................104
4.5 Maintaining RRPP..........................................................................................................................................105
4.5.1 Clearing RRPP Running Information....................................................................................................105
4.5.2 Debugging RRPP...................................................................................................................................106
4.6 Configuration Examples.................................................................................................................................106
4.6.1 Example for Configuring a Single RRPP Ring.....................................................................................106
4.6.2 Example for Configuring Crossed RRPP Rings with a Single Instance (GB version).........................111
4.6.3 Example for Configuring Crossed RRPP Rings with a Single Instance (Huawei Version)..................121
4.6.4 Example for Configuring Tangent RRPP Rings....................................................................................130
4.6.5 Example for Configuring a Single RRPP Ring with Multiple Instances..............................................139
4.6.6 Example for Configuring Crossed RRPP Rings with Multiple Instances (GB version).......................151
4.6.7 Example for Configuring Crossed RRPP Rings with Multiple Instances (HW version)......................173
4.6.8 Example for Configuring Tangent RRPP Rings with Multiple Instances.............................................194
5 Ethernet OAM Configuration.................................................................................................211
Issue 01 (2012-03-15) Huawei Proprietary and Confidential vi

5.1 Introduction to Ethernet OAM.......................................................................................................................213

5.2 Ethernet OAM Supported by the S9700.........................................................................................................213
5.3 Configuring Basic EFM OAM.......................................................................................................................217
5.3.1 Establishing the Configuration Task.....................................................................................................217
5.3.2 Enabling EFM OAM Globally..............................................................................................................218
5.3.3 Configuring the Working Mode of EFM OAM on an Interface...........................................................218
5.3.4 (Optional) Setting the Maximum Size of an EFM OAMPDU..............................................................219
5.3.5 Enabling EFM OAM on an Interface....................................................................................................220
5.4 Configuring EFM OAM Link Monitoring.....................................................................................................221
5.4.2 (Optional) Detecting Errored Frames of EFM OAM............................................................................222
5.4.3 (Optional) Detecting Errored Codes of EFM OAM..............................................................................223
5.4.4 (Optional) Detecting Errored Frame Seconds of EFM OAM...............................................................224
5.4.5 (Optional) Associating a Threshold Crossing Event with an Interface.................................................224
5.5 Testing the Packet Loss Ratio on the Physical Link......................................................................................226
5.5.2 Enabling EFM OAM Remote Loopback...............................................................................................227
5.5.3 Sending Test Packets.............................................................................................................................229
5.5.4 Checking the Statistics on Returned Test Packets.................................................................................229
5.5.5 (Optional) Manually Disabling EFM OAM Remote Loopback............................................................230
5.6 Configuring Associating between EFM OAM and an Interface....................................................................231
5.6.2 Associating EFM OAM with an Interface.............................................................................................232
5.6.3 (Optional) Setting the Faulty-State Hold Timer....................................................................................234
5.7 Configuring Association Between an EFM OAM Session and an Interface (Triggering the Physical Status of
the Interface Associated with the EFM OAM Session to Become Down)...........................................................235
5.7.2 Configuring Association Between an EFM OAM Session and an Interface.........................................237
5.8 Configuring Association Between EFM OAM Sessions...............................................................................238
5.8.2 Configuring Association Between EFM OAM Sessions......................................................................240
5.9 Configuring Basic Ethernet CFM...................................................................................................................241
5.9.2 Enabling Ethernet CFM Globally..........................................................................................................242
5.9.3 Creating an MD.....................................................................................................................................243
5.9.4 (Optional) Creating the Default MD.....................................................................................................243
5.9.5 Creating an MA.....................................................................................................................................244
Issue 01 (2012-03-15) Huawei Proprietary and Confidential vii

5.9.6 Creating a MEP.....................................................................................................................................245

5.9.7 Creating an RMEP.................................................................................................................................246
5.9.8 (Optional) Setting the MIP Creation Rule.............................................................................................247
5.9.9 Enabling CC Detection..........................................................................................................................248
5.9.10 (Optional) Creating a VLAN...............................................................................................................249
5.10 Configuring Related Parameters of Ethernet CFM......................................................................................251
5.10.1 Establishing the Configuration Task...................................................................................................251
5.10.2 (Optional) Configuring the RMEP Activation Time...........................................................................252
5.10.3 (Optional) Configuring the Anti-Jitter Time During Alarm Restoration............................................253
5.10.4 (Optional) Configuring the Anti-Jitter Time During Alarm Generation.............................................253
5.11 Fault Verification on the Ethernet................................................................................................................254
5.11.2 (Optional) Implementing 802.1ag MAC Ping.....................................................................................255
5.11.3 (Optional) Implementing Gmac ping..................................................................................................256
5.12 Locating the Fault on the Ethernet...............................................................................................................257
5.12.2 (Optional) Implementing 802.1ag MAC Trace...................................................................................258
5.12.3 (Optional) Implementing Gmac trace..................................................................................................259
5.13 Configuring Association Between Ethernet CFM and an Interface.............................................................260
5.13.2 Associating Ethernet CFM with an Interface......................................................................................263
5.14 Configuring Association Between Ethernet CFM and an Interface (Triggering the Physical Status of the
Interface Associated with Ethernet CFM to Become Down)...............................................................................264
5.14.2 Configuring Association Between Ethernet CFM and an Interface....................................................265
5.15 Associating EFM OAM with Ethernet CFM................................................................................................268
5.15.2 Associating EFM OAM with Ethernet CFM.......................................................................................269
5.16 Configuring Association Between Ethernet CFM and Ethernet CFM.........................................................270
5.16.2 Configuring Association Between Ethernet CFM and Ethernet CFM................................................271
5.17 Configuring Association Between Ethernet CFM and SEP.........................................................................272
5.17.2 Configuring Association Between Ethernet CFM and SEP................................................................273
5.18 Configuring Association Between Ethernet OAM and BFD.......................................................................274
5.18.2 Configuring Ethernet OAM Functions................................................................................................275
Issue 01 (2012-03-15) Huawei Proprietary and Confidential viii

5.18.3 Associating Ethernet OAM with BFD.................................................................................................275

5.19 Maintaining Ethernet OAM..........................................................................................................................276
5.19.1 Debugging EFM OAM........................................................................................................................276
5.20 Configuration Examples...............................................................................................................................277
5.20.1 Example for Configuring EFM OAM.................................................................................................277
5.20.2 Example for Testing the Packet Loss Ratio on a Link........................................................................280
5.20.3 Example for Configuring Basic Functions of Ethernet CFM..............................................................283
5.20.4 Example for Configuring the Default MD for Ethernet CFM.............................................................292
5.20.5 Example for Configuring Association Between an EFM OAM Module and an Interface.................298
5.20.6 Example for Associating EFM OAM with BFD for IP.......................................................................301
5.20.7 Example for Configuring Association Between EFM OAM Modules...............................................321
5.20.8 Example for Configuring Association Between an Ethernet CFM Module and an Interface.............324
5.20.9 Example for Configuring Association Between an EFM OAM Module and an Ethernet CFM Module
........................................................................................................................................................................327
5.20.10 Example for Configuring Association Between Ethernet CFM with Ethernet CFM........................331
5.20.11 Example for Associating Ethernet CFM with RRPP.........................................................................335
5.20.12 Example for Associating Ethernet CFM with MSTP........................................................................348
6 ITU-T Recommendation Y.1731 Configuration...................................................................356

6.1 Introduction to ITU-T Recommendation Y.1731...........................................................................................357
6.2 ITU-T Recommendation Y.1731 Features Supported by the S9700..............................................................357
6.3 Configuring the One-way Frame Delay Measurement in a VLAN................................................................359
6.3.2 Binding an MA to a VLAN...................................................................................................................360
6.3.3 (Optional) Setting an Alarm Threshold for the One-way Frame Delay Measurement.........................360
6.3.4 Configuring DM Frame Reception on a Remote MEP.........................................................................361
6.3.5 Enabling the One-way Frame Delay Measurement in a VLAN............................................................362
6.4 Configuring the Two-way Frame Delay Measurement in a VLAN...............................................................363
6.4.3 (Optional) Setting an Alarm Threshold for the Two-way Frame Delay Measurement.........................365
6.4.4 Configuring Two-Way DMM Packet Receiving...................................................................................365
6.4.5 Enabling the Two-way Frame Delay Measurement in a VLAN...........................................................366
6.5 Configuring VLAN AIS.................................................................................................................................367
6.5.3 Configuring the AIS Function...............................................................................................................369
6.5.4 Configuring Alarm Suppression............................................................................................................370
6.6 Configuration Examples.................................................................................................................................372
Issue 01 (2012-03-15) Huawei Proprietary and Confidential ix

6.6.1 Example for Configuring the One-way Frame Delay Measurement in a VLAN..................................372
6.6.2 Example for Configuring the Two-way Frame Delay Measurement in a VLAN.................................376
7 BFD Configuration....................................................................................................................382
7.1 BFD Overview................................................................................................................................................384
7.2 BFD Features Supported by the S9700..........................................................................................................384
7.3 Configuring Single-hop BFD.........................................................................................................................388
7.3.2 Enabling BFD Globally.........................................................................................................................389
7.3.3 (Optional) Setting the Multicast IP Address of BFD............................................................................389
7.3.4 Creating a BFD Session.........................................................................................................................390
7.4 Configuring the Multi-Hop BFD....................................................................................................................392
7.4.3 Creating a BFD Session.........................................................................................................................393
7.5 Configuring a BFD Session with Automatically Negotiated Discriminators.................................................396
7.5.3 Configuring a Static BFD Session with Automatically Negotiated Discriminators.............................397
7.6 Adjusting BFD Parameters.............................................................................................................................398
7.6.2 Adjusting the BFD Detection Time.......................................................................................................399
7.6.3 Adding the Description of a BFD Session.............................................................................................400
7.6.4 Configuring the BFD WTR...................................................................................................................401
7.6.5 Setting the Priority of BFD Packets......................................................................................................401
7.7 Globally Configuring the Destination Port Number for the Multi-Hop BFD Control Packet.......................403
7.7.2 Globally Configuring the Destination Port Number..............................................................................404
7.8 Configuring the Delay of a BFD Session to Go Up.......................................................................................406
7.8.2 Configuring the Delay for BFD Session Status Change to Up..............................................................406
7.9 Configuring a BFD Session with the One-Arm Echo Function.....................................................................408
7.9.2 Enable BFD Globally............................................................................................................................409
7.9.3 Establishing a BFD Session...................................................................................................................409
7.10 Configuring the TTL Function Globally......................................................................................................411
Issue 01 (2012-03-15) Huawei Proprietary and Confidential x


7.10.2 Configuring the TTL Globally............................................................................................................412
7.11 Configuring the Interval for Trap Messages Are Sent..................................................................................413
7.11.2 Configuring the Interval at Which Trap Messages Are Sent...............................................................414
7.12 Configuring Association Between a BFD Session and an Interface (Triggering the Physical Status of the
Interface Associated with the BFD Session to Become Down)...........................................................................415
7.12.2 Configuring Association Between a BFD Session and an Interface...................................................417
7.13 Configuring Association Between BFD Sessions........................................................................................418
7.13.2 Configuring Association Between BFD sessions................................................................................419
7.14 Maintaining BFD..........................................................................................................................................420
7.14.1 Clearing BFD Statistics.......................................................................................................................421
7.14.2 Debugging BFD...................................................................................................................................421
7.15.1 Example for Configuring Single-Hop BFD on a Layer 2 Interface....................................................422
7.15.2 Example for Configuring Single-Hop BFD on a VLANIF Interface..................................................424
7.15.3 Example for Configuring Multi-Hop BFD..........................................................................................427
7.15.4 Example for Associating the BFD Status with the Interface Status....................................................431
7.15.5 Example for Configuring Association Between a BFD Session and an Interface..............................435
7.15.6 Example for Configuring Association Between the Status of BFD Sessions.....................................442
8 VRRP and VRRP6 Configuration...........................................................................................451

8.1 VRRP Overview.............................................................................................................................................453
8.2 VRRP Features Supported by the S9700........................................................................................................453
8.3 Configuring the VRRP Backup Group...........................................................................................................456
8.3.2 Creating a Backup Group and Configuring a Virtual IP Address.........................................................457
8.3.3 Configuring Priorities for Interfaces Where a Backup Group Is Created.............................................459
8.3.4 (Optional) Configuring the Mode of Sending VRRP Packets in Super-VLAN....................................460
8.4 Configuring VRRP to Track the Status of an Interface..................................................................................462
8.4.2 Configuring VRRP to Track the Status of an Interface.........................................................................463
8.5 Configuring a Fast VRRP Switchover............................................................................................................466
8.5.2 Tracking the BFD Session Status..........................................................................................................467
Issue 01 (2012-03-15) Huawei Proprietary and Confidential xi

8.5.3 Associating a VRRP Backup Group with an NQA Test Instance.........................................................469

8.5.4 Associating VRRP with a Route to Implement a Rapid Master/Backup VRRP Switchover................471
8.6 Configuring VRRP Security...........................................................................................................................472
8.6.2 Configuring the Authentication Mode of VRRP Packets......................................................................473
8.7 Configuring VRRP Smooth Switching...........................................................................................................475
8.7.2 Configuring VRRP Smooth Switching..................................................................................................475
8.8 Adjusting and Optimizing VRRP...................................................................................................................477
8.8.2 Configuring the Interval for Sending VRRP Advertising Messages.....................................................478
8.8.3 Configuring the Preemption Delay Time of Backup Group Switch s...................................................479
8.8.4 Enabling the Reachability Test of the Virtual IP Address.....................................................................481
8.8.5 Disabling a Switch from Checking Number of Hops in VRRP Packets...............................................482
8.8.6 Configuring the Timeout Time of Sending Gratuitous ARP Packets by the Master router..................483
8.9 Configuring mVRRP Backup Groups............................................................................................................484
8.9.2 Configuring mVRRP Backup Group.....................................................................................................486
8.9.3 (Optional) Configuring Member VRRP Backup Groups and Binding them to the mVRRP Backup Group
........................................................................................................................................................................487
8.10 Configuring VRRP Version Upgrade...........................................................................................................489
8.10.2 Configuring VRRPv3..........................................................................................................................490
8.11 Maintaining VRRP.......................................................................................................................................491
8.11.1 Debugging VRRP................................................................................................................................491
8.12.1 Example for Configuring VRRP in Master/Backup Mode.................................................................492
8.12.2 Example for Configuring VRRP in Load Balancing Mode................................................................497
8.12.3 Example for Configuring VRRP Fast Switchover..............................................................................502
8.12.4 Example for Configuring VRRP6 on an Interface..............................................................................507
8.12.5 Example for Configuring VRRP6 in Load Balancing Mode..............................................................510
9 Collection of Configuration Examples of Association.......................................................516

10 MAC Swap Loopback Configuration..................................................................................517
10.1 MAC Swap Loopback Overview.................................................................................................................518
10.2 MAC Swap Loopback Features Supported by the S9700............................................................................518
10.3 Configuring Local MAC Swap Loopback....................................................................................................519
Issue 01 (2012-03-15) Huawei Proprietary and Confidential xii


10.3.2 Configuring Local MAC Swap Loopback...........................................................................................520
10.3.3 Enabling the MAC Swap Loopback Function.....................................................................................521
10.3.4 Disabling the MAC Swap Loopback Function....................................................................................521
10.4 Configuring Remote MAC Swap Loopback................................................................................................523
10.4.2 Configuring Remote MAC Swap Loopback.......................................................................................524
10.4.3 Enabling the MAC Swap Loopback Function.....................................................................................524
10.4.4 Disabling the MAC Swap Loopback Function....................................................................................525
10.5.1 Example for Configuring Local MAC Swap Loopback......................................................................526
10.5.2 Example for Configuring Remote MAC Swap Loopback..................................................................528
11 Hot Backup and Active/Standby Switchover Configuration..........................................531

11.1 Introduction to Hot Backup and Active/Standby Switchover......................................................................532
11.2 Hot Backup and Active/Standby Switchover Features Supported by the S9700.........................................532
11.3 Configuring the Slave Main Control Board.................................................................................................534
11.3.2 (Optional) Specifying the Slot ID of the Slave Main Control Board..................................................535
11.3.3 Resetting the Slave Main Control Board.............................................................................................535
11.4 Performing Active/Standby Switchover.......................................................................................................536
11.4.2 Enabling Active/Standby Switchover..................................................................................................536
11.4.3 Performing Active/Standby Switchover..............................................................................................537
11.5 Maintaining Active/Standby Switchover......................................................................................................538
11.5.1 Viewing the Status of the Master and Slave Main Control Boards.....................................................538
11.5.2 Debugging Active/Standby Switchover..............................................................................................538
11.6.1 Example for Configuring Hot Backup and Active/Standby Switchover.............................................539
Issue 01 (2012-03-15) Huawei Proprietary and Confidential xiii

Configuration Guide - Reliability 1 DLDP Configuration
1 DLDP Configuration
About This Chapter
This chapter describes the principle, configuration procedure, and configuration example of the
Device Link Detection Protocol (DLDP).
1.1 Introduction to DLDP

This section describes the concept of DLDP.
1.2 Configuring DLDP Functions
This section describes how to configure DLDP functions.
1.3 Resetting the DLDP Status
This section describes how to reset the DLDP status.
1.4 Maintaining DLDP
This section describes how to maintain DLDP.
1.5 Configuration Examples
This section provides a configuration example of DLDP.
Issue 01 (2012-03-15) Huawei Proprietary and Confidential 1

1.1 Introduction to DLDP

This section describes the concept of DLDP.
On a network, unidirectional link faults often occur. That is, the local device can receive packets
from the remote device through the link layer, but the remote device cannot receive packets from
the local device.
Take the fiber as an example. The fault of unidirectional link may be caused by crossed
connection of fibers or disconnection of one fiber.
Figure 1-1 Crossed connection of fibers

SwitchA
GE2/0/1 GE2/0/2
GE2/0/1 GE2/0/2
SwitchB
Figure 1-2 Disconnection of one fiber

SwitchA
TX RX
GE2/0/1
GE2/0/1
RX TX
SwitchB
DLDP can detect the link status of fibers or copper twisted pairs. If a unidirectional link exists,
DLDP automatically disables the interface or prompts the user to manually disable the interface.
This prevents network faults. Currently, the S9700 supports DLDP detection for up to 4096
neighbors.
As a link layer protocol, DLDP works with the physical layer protocol to detect the link status.
The auto negotiation mechanism on the physical link detects physical signals and faults on the

physical link, and DLDP identifies the remote device and unidirectional link and disables
unreachable interfaces. The auto negotiation mechanism and DLDP work together to detect and
close unidirectional links on the physical and logical interfaces. If the interfaces on both ends
of the link work normally on the physical layer, DLDP checks the connection and packet
exchange between the two interfaces on the link layer. This process cannot be implemented
through the auto negotiation mechanism.
1.2 Configuring DLDP Functions

This section describes how to configure DLDP functions.
1.2.1 Establishing the Configuration Task
Applicable Environment
On a network, unidirectional link faults often occur. To prevent network faults caused by
unidirectional links, you can enable DLDP on interfaces at two ends of a pair of fibers or a copper
twisted pair to monitor the link status. If a unidirectional link exists, DLDP automatically
disables the interface connected to the link or prompts you to manually disable the interface.
Unidirectional links can be tested only when the devices on both ends of the fibers and copper
twisted pairs support DLDP functions.
Pre-configuration Tasks
Before configuring DLDP, complete the following task:
l Configuring the interfaces at both ends to work in non-auto-negotiation mode
Data Preparation
To configure DLDP, you need the following data.
No. Data
1 Type and number of each interface
2 (Optional)Name of the interface group
3 (Optional) Interval for sending Advertisement packets
4 (Optional) Value of the Delay Down timer
1.2.2 Enabling DLDP
Procedure
Step 1 Run:
system-view

The system view is displayed.

Step 2 Run:
dldp enable
DLDP is enabled globally.

Step 3 Run:
interface interface-type interface-number
The Ethernet interface view is displayed.

Or run:
port-group port-group-name
The interface group view is displayed.
NOTE
DLDP cannot be enabled on sub-interfaces or Layer 3 interfaces.
Step 4 Run:
dldp enable
DLDP is enabled on the interface.

By default, DLDP is disabled globally and on each interface.
----End
1.2.3 (Optional) Setting the Operating Mode of DLDP
Context
If DLDP works in normal mode, the system can identify only one type of unidirectional link,
that is, the crossed connection of fibers. In this mode, the system does not use any timer, so it
cannot detect that a bidirectional link changes to a unidirectional link.
If DLDP works in enhanced mode, the system can identify two types of unidirectional links,
that is, the crossed connection of fibers and the connection where one fiber is disconnected. To
detect the unidirectional link caused by disconnection of one fiber, you need to manually set the
rate and full-duplex mode of the interconnected ports; otherwise, DLDP does not take effect
even if it is enabled. When a bidirectional link changes to a unidirectional link, the port where
the Tx fiber receives optical signals is in Disable state, and the port where the Tx fiber receives
no optical signals is in Inactive state.
Procedure
Step 1 Run:
system-view

Step 2 Run:
dldp work-mode { enhance | normal }
The operation mode of DLDP is set.

By default, the operation mode of DLDP is enhance mode.
----End
1.2.4 (Optional) Enabling DLDP Compatible Mode
Context
If the S9700 needs to work with the following Huawei switches to provide the DLDP function,
this task is required. The software versions of the following switches must support the DLDP
function:
l S8500
l S7800
l S6500
l S5600
l S5100-EI
l S3900
l S3500
l S3100
Procedure
Step 1 Run:
system-view

Step 2 Run:
bpdu mac-address mac-address [ mac-address-mask ]
The S9700 is configured to use the BPDU MAC address 010F-E200-0001 to send DLDP packets.
The MAC addresses used for sending DLDP packets on the S9700 and on the old Huawei
switches are different. Therefore, the S9700 must be configured to use BPDU MAC address
10F-E200-0001 to send DLDP packets.
Step 3 Run:
The interface view is displayed.

Or run:
The port group view is displayed.

Step 4 Run:
dldp compatible-mode enable
The DLDP compatible mode is enabled.

If two devices are connected by using two links, the DLDP compatible mode must be enabled
or disabled on both the two interfaces.

If devices at both ends are S9700s, the interfaces at both ends must use the same DLDP
compatible mode. That is, you must enable or disable the DLDP compatible mode
simultaneously on the interfaces.
Step 5 Run:
dldp compatible-mode local-mac mac-address
The DLDP packets sent in the DLDP compatible mode contain MAC addresses.
After the DLDP compatible mode is enabled on the S9700, the peer device of the S9700 may
discover multiple neighbors, causing DLDP flapping. The dldp compatible-mode local-mac
command can prevent this problem.
NOTE
At least one bit in the MAC address must be 0, and the MAC address cannot be a multicast MAC address.
----End
1.2.5 (Optional) Setting the Interval for Sending Advertisement

Packets
Context
Do as follows on the S9700 that needs to run DLDP.
Procedure
Step 1 Run:
system-view

Step 2 Run:
dldp interval time
The interval for sending Advertisement packets is set.

By default, the interval for sending Advertisement packets is 5 seconds.
The interval for sending Advertisement packets must be smaller than one third of the STP
convergence time. If the interval is too long, STP loops occur before a unidirectional link is shut
down on a DLDP interface. If the interval is too short, traffic on the network increases.
NOTE
Ensure that the interval for sending Advertisement packets is the same on the local and remote devices that
are connected through fibers or copper twisted pairs.
----End
1.2.6 (Optional) Setting the Delay Down Timer
Procedure
Step 1 Run:

system-view

Step 2 Run:
dldp delaydown-timer time
The Delay Down timer is set.

By default, the Delay Down timer is 1 second.
If DLDP receives a Port-Down event when it is in Active, Advertisement, or Probe state, DLDP
will enter Inactive state and clear the neighbor information. In certain cases, the port is Down
for a very short time. For example, failure of the Tx fiber on a port may cause jitter of optical
signals on the Rx fiber, that is, the port becomes Down and then becomes Up again. To prevent
the neighbor information from being deleted immediately in this case, DLDP first enters the
DelayDown state and starts the DelayDown timer. Before the DelayDown timer times out, DLDP
retains the neighbor information and responds to only Port-Up events.
l If DLDP does not receive any Port-Up event when the DelayDown timer times out, it deletes
the neighbor information and enters the Inactive state.
l If DLDP receives the Port-Up event before the DelayDown timer times out, it returns to the
previous state.
The Delay Down timer applies to all DLDP interfaces.
----End
1.2.7 (Optional) Setting the Interface Blocking Mode
Context
When a unidirectional link is detected, DLDP blocks the corresponding interface in either of the
following ways:
l Manual mode: This mode can prevent DLDP from blocking the interface immediately to
affect packet forwarding when the network performance is poor. It is a compromise mode
used to prevent an interface from being blocked because of incorrect judgment of the
system. In this mode, DLDP detects the unidirectional link, and the network administrator
blocks the interface manually. When the DLDP state machine detects a unidirectional link,
the system records the log and sends trap messages to prompt you the network administrator
to block the interface manually. Then the DLDP state machine changes to the Disable state.
l Automatic mode: It is the default mode. When a unidirectional link is detected, the DLDP
state machine changes to the Disable state, and the system records the log, sends trap
messages, and sets the interface state to Blocking.
Procedure
Step 1 Run:
system-view

Step 2 Run:
dldp unidirectional-shutdown { auto | manual }
The mode of blocking interfaces when a unidirectional link fault is detected is set.

By default, DLDP automatically blocks the interface when a unidirectional link fault is detected.
An interface in DLDP Down state still sends RecoverProbe packets periodically. If correct
RecoverEcho packets are received, it indicates that the unidirectional link changes to the
bidirectional link and the DLDP status becomes Up.
----End
1.2.8 (Optional) Setting the Authentication Mode of DLDP Packets
Procedure
Step 1 Run:
system-view

Step 2 Run:
dldp authentication-mode { md5 md5-password | none | simple simple-password }
The DLDP authentication mode used between the interfaces of the S9700 and the remote device
is set.
By default, the DLDP authentication mode used between the interfaces of the S9700 and the
remote device is none. That is, DLDP packets are not authenticated.
NOTE
Ensure that the local and remote devices use the same authentication mode and same authentication
password; otherwise, the DLDP authentication fails. DLDP works normally only after the DLDP
authentication succeeds.
----End
1.2.9 Checking the Configuration
Procedure
Step 1 Run the display dldp [ interface interface-type interface-number ] command to check the DLDP
configuration and neighbor entries.
----End
Example
Run the display dldp command, and you can view the operation mode of DLDP, interval for
sending Advertisement packets, value of the Delay Down timer, interface disabling mode, and
authentication mode of DLDP packets.
<Quidway> display dldp
DLDP global status : enable
DLDP interval : 5s
DLDP work-mode : enhance
DLDP authentication-mode : simple, password is 123
DLDP unidirectional-shutdown : auto
DLDP delaydown-timer : 2s
The number of enabled ports is : 2.

The number of global neighbors is: 2.
Interface GigabitEthernet2/0/1
DLDP port state : advertisement
DLDP link state : up
The neighbor number of the port is : 1.
Neighbor mac address : 0000-0000-0100
Neighbor port index : 21
Neighbor state : two way
Neighbor aged time : 13
1.3 Resetting the DLDP Status

This section describes how to reset the DLDP status.
When a unidirectional link is detected, the corresponding interface enters the Disable state. The
system prompts you to disable the interface or sets the interface state to DLDP Down
automatically according to the configuration. To enable the interface to detect unidirectional
links again, you can reset the DLDP state of the interface. The DLDP status of the interface after
recovery depends on the physical status of the interface. If the physical status is Down, the DLDP
status of the interface changes to Inactive. If the physical status is Up, the DLDP status changes
to Active.
None.
Data Preparation
To reset the DLDP status, you need the following data.
No. Data
1 Type and number of each interface
2 Name of the interface group
1.3.2 Resetting the DLDP Status Globally

Context
The dldp reset command takes effect only when DLDP is enabled globally and on interfaces.
When you reset the DLDP status globally, the DLDP status is reset for all the disabled interfaces
on the S9700.
Procedure
Step 1 Run:
system-view

Step 2 Run:
dldp reset
The DLDP status is reset globally.
----End
1.3.3 Resetting the DLDP Status of an Interface
Context
If you reset the DLDP status on an interface or interface group, the DLDP status is reset for the
interface or all the disabled interfaces in the interface group.
The dldp reset command takes effect only when DLDP is enabled globally and on interfaces.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The Ethernet interface view is displayed.

Or run:
The interface group view is displayed.

Step 3 Run:
dldp reset
The DLDP status is reset on the interface or interface group.
----End

Procedure
Step 1 Run the display dldp [ interface interface-type interface-number ] command to check the DLDP
configuration and neighbor entries.
----End
Example
Run the display dldp command, and you can view the status of an interface after the DLDP
status is reset.
<Quidway> display dldp
DLDP global status : enable
DLDP interval : 5s
DLDP work-mode : enhance
DLDP authentication-mode : simple, password is : 123
DLDP unidirectional-shutdown : auto
DLDP delaydown-timer : 2s
The number of enabled ports is 2.
The number of global neighbors is : 2.
1.4 Maintaining DLDP

This section describes how to maintain DLDP.
1.4.1 Clearing the Statistics of DLDP
Context
CAUTION
Statistics of DLDP cannot be restored after you clear them. So, confirm the action before you
use the command.

Procedure
Step 1 Run the reset dldp statistics [ interface interface-type interface-number ] command in the user
view to clear the statistics of DLDP packets on an interface.
----End

This section provides a configuration example of DLDP.
1.5.1 Example for Configuring DLDP
Networking Requirements
As shown in Figure 1-3, two S9700s are connected through a pair of optical fibers. On a fiber,
RX indicate the receive end, and TX indicates the transmit end. DLDP is enabled on the
interconnected interfaces. If the Rx fiber on Switch A fails, Switch A cannot receive optical
signals. In this case, GE 2/0/1 of Switch A becomes Down and cannot send or receive any
packets. However, the Tx fiber on Switch B still sends optical signals, and Switch B can receive
optical signals because the Tx fiber on Switch A is working normally. Therefore, the link status
on Switch B is still Up. If Switch B does not receive any DLDP packet from Switch A within
the neighbor aging time, GE 2/0/1 of Switch B changes to unidirectional state. To prevent
network faults, DLDP disables GE 2/0/1 of Switch B.
Figure 1-3 Disconnection of one fiber

SwitchA
TX RX
GE2/0/1
GE2/0/1
RX TX
SwitchB
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure the interfaces at both ends to work in non-auto-negotiation mode.
2. Enable DLDP.
3. Set the operation mode of DLDP.
4. Set the interval for sending Advertisement packets.

5. Set the Delay Down timer.

6. Set the mode of disabling the interface when a unidirectional link is detected.
7. Set the authentication mode of DLDP packets.
Data Preparation
To complete the configuration, you need the following data:
l Type and number of each interface
l Interval for sending Advertisement packets
l Value of the Delay Down timer
Procedure
Step 1 Configure the interface on Switch A to work in non-auto negotiation mode.
<Quidway> system-view
[Quidway] sysname SwitchA
[SwitchA] interface gigabitethernet 2/0/1
[SwitchA-GigabitEthernet2/0/1] undo negotiation auto
[SwitchA-GigabitEthernet2/0/1] quit
Step 2 Enable DLDP globally

[SwitchA] dldp enable
Step 3 Enable DLDP on the interface.

[SwitchA-GigabitEthernet2/0/1] dldp enable
Step 4 Configure DLDP to work in enhanced mode.

[SwitchA] dldp work-mode enhance
Step 5 Set the interval for sending Advertisement packets to 80 seconds.

[SwitchA] dldp interval 80
Step 6 Set the timeout interval of the DelayDown timer to 4 seconds.

[SwitchA] dldp delaydown-timer 4
Step 7 Configure DLDP to automatically shut down the interface where a unidirectional link is detected.
[SwitchA] dldp unidirectional-shutdown auto
Step 8 Set the authentication mode of DLDP packets to simple password authentication and set the
password to 123456.
[SwitchA] dldp authentication-mode simple 12345
Repeat the preceding steps on Switch B.

Step 9 Verify the configuration.
After the configuration, run the display dldp command in the interface view, and you can find
that the DLDP status of the interface is advertisement.
[SwitchA] display dldp interface gigabitethernet 2/0/1
DLDP port state: advertisement
DLDP link state: up
The neighbor number of the port is: 1.
Neighbor mac address:781d-ba57-c24a

Neighbor port index:52

Neighbor state:two way
Neighbor aged time:165
Remove the Rx fiber from Switch A to simulate a unidirectional link between GE 2/0/1 ofSwitch
A and GE 2/0/1 of Switch B, as shown in Figure 1-3. You find that DLDP blocks the GE
2/0/1 interface of Switch B.
# Run the display dldp on Switch A, and you can find that the DLDP status of GE 2/0/1 is
inactive. Run the display dldp on Switch B, and you can find that the DLDP status of GE
2/0/1 is disable.
[SwitchA] display dldp interface gigabitethernet 2/0/1
DLDP port state: inactive
DLDP link state: down
The neighbor number of the port is: 0
[SwitchB] display dldp interface gigabitethernet 2/0/1
DLDP port state: disable
DLDP link state: up
The neighbor number of the port is: 0
----End
Configuration Files
l Configuration file of Switch A
#
sysname SwitchA
#
dldp enable
dldp interval 80
dldp delaydown-timer 4
dldp authentication-mode simple 12345
#
interface GigabitEthernet2/0/1
dldp enable
undo negotiation auto
#
return
l Configuration file of Switch B
#
sysname SwitchB
#
dldp enable
dldp interval 80
dldp delaydown-timer 4
dldp authentication-mode simple 12345
#
dldp enable
undo negotiation auto
#
return

Configuration Guide - Reliability 2 Smart Link and Monitor Link Configuration
2 Smart Link and Monitor Link Configuration
About This Chapter
This chapter describes the principle, configuration procedure, and configuration example of the
Smart Link and Monitor Link.
2.1 Smart Link and Monitor Link

This section describes the concepts of Smart Link and Monitor Link.
2.2 Configuring a Smart Link Group
This section describes how to create a Smart Link group, enable the Smart Link group, configure
the master and slave interfaces, enable the revertive switching, and configure functions related
to Flush packets.
2.3 Configuring a Flow Control Policy in a Smart Link Group
This section describes how to configure the advanced functions of the Smart Link group, such
as lock of data flows and manual switchover between links.
2.4 Configuring a Monitor Link Group
This section describes how to create a Monitor Link group, configure the uplink and downlink
interfaces, and enable the revertive switching.
2.5 Maintaining the Smart Link
This section describes how to debug the Smart Link.
This section provides several configuration examples of the Smart Link.

2.1 Smart Link and Monitor Link

This section describes the concepts of Smart Link and Monitor Link.
The dual-homing networking is often used. In this networking, STP blocks redundant links,
providing redundancy. When the active link fails, the traffic is switched to the standby link.
Although this scheme can implement redundancy, the performance cannot meet the requirements
of users. Route convergence is performed within several seconds even if the Rapid Spanning
Tree Protocol (RSTP) is used. The convergence speed is unfavorable for the high-end Ethernet
switch used on the core of the carrier-class network.
To address the preceding problem, Huawei introduces Smart Link in dual-homing networking
to implement redundancy of active and standby links and fast transition. In this manner, the high
performance is ensured and the configuration is simplified. In addition, cooperation of interfaces
is used.
The Monitor Link is introduced as a supplement to the Smart Link. This technology supports
the association of interfaces. A Monitor Link group consists of an uplink interface and several
downlink interfaces. If the uplink interface fails, the Monitor Link group automatically disables
the downlink interfaces. When the uplink interface recovers, the downlink interfaces also
recover.
2.2 Configuring a Smart Link Group

This section describes how to create a Smart Link group, enable the Smart Link group, configure
the master and slave interfaces, enable the revertive switching, and configure functions related
to Flush packets.

As shown in Figure 2-1, each device at the access and convergence layer is connected to two
uplink devices. This networking mode provides higher security and reduces the duration of
service interruption caused by the link failure.

Figure 2-1 Application scenario of the Smart Link
IP/MPLS
core
network
SwitchA
SwitchB SwitchC
Smart Link group Smart Link group

SwitchD SwitchE
User1 User 2 User 3
Active link
Inactive link
As shown in Figure 2-1, Switch D and Switch E are connected to user devices, and both are
connected to Switch B and Switch C. Configure the Smart Link on Switch D and Switch E and
add the two uplink interfaces to the respective Smart Link group to avoid loops. In this manner,
interrupted services can be restored in milliseconds.
Before configuring the basic functions of a Smart Link group, complete the following task:
l Ensuring that the Multiple Spanning Tree Protocol (MSTP), Rapid Ring Protection
Protocol (RRPP), and Smart Ethernet Protection (SEP) are not enabled on the master and
slave interfaces of the Smart Link group
Data Preparation
To configure basic functions of the Smart Link group, you need the following data.
No. Data
1 Number of the interface added to the Smart Link group

No. Data
2 ID of the Smart Link group
3 IDs of VLANs bound to the instance
4 Control VLAN ID contained in the Flush packet
5 (Optional) Password contained in the Flush packet
2.2.2 Creating and Enabling a Smart Link Group

Context
Do as follows on the S9700.
Procedure
Step 1 Run:
system-view

Step 2 Run:
smart-link group group-id
A Smart Link group is created and the Smart Link group view is displayed.
The S9700 supports a maximum of 16 Smart Link groups.
Step 3 (Optional)Run:
protected-vlan reference-instance { instance-id1 [ to instance-id2 ] }&<1-10>
An instance is bound to the Smart Link group as the protected instance. The functions of the
Smart link group take effect only on the VLANs bound to the protected instance. For details
about STP instance configuration, see Configuring and Activating an MST Region.
----End
2.2.3 Configuring the Master and Slave Interfaces in a Smart Link

Group
Context
The slave interface of a Smart Link group is blocked when the group is started.
An interface cannot be added to a Smart Link group in the following situations:
l The interface is a Rapid Ring Protection Protocol (RRPP) interface.
l Spanning Tree Protocol (STP) is enabled on the interface.
l The interface has been added to an Eth-Trunk.
l The interface has been added to a Monitor Link group.

l The interface has been added to another Smart Link group.

l STP is configured on the interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
stp disable
STP is disabled on the interface.
Step 4 Run:
quit
Return to the interface view.
Step 5 Run:
The Smart Link group view is displayed.
Step 6 Run:
port interface-type interface-number master
An interface is added to the Smart Link group and is specified as the master interface.
Step 7 Run:
port interface-type interface-number slave
Another interface is added to the Smart Link group and is specified as the slave interface.
A Smart Link group consists of a master interface and a slave interface. By default, a Smart Link
group does not have interfaces.
----End
2.2.4 Enabling the Sending of Flush Packets
Context
When the active and standby links of the Smart Link group switch, the existing forwarding
entries no longer apply to the new topology. All the MAC address entries and ARP entries on
the network need to be updated. Then the Smart Link group sends Flush packets to ask other
devices to update the MAC address table and ARP entries.
Because manufacturers define the format of Flush packets differently, the Flush packets
described here are used only for the intercommunication between Huawei S-series switches. In
addition, the function of receiving Flush packets must be enabled on the remote switch.

If you run flush send control-vlan vlan-id [ password simple password ] command in the Smart
Link group view, the Smart Link group is enabled to send Flush packets that contain the specified
control VLAN ID and password. The VLAN ID specified by vlan-id must already exist on the
S9700. If the specified VLAN ID does not exist on the S9700, Flush packets cannot be sent.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
flush send control-vlan vlan-id [ password simple password ]
The S9700 is enabled to send Flush packets, and the control VLAN ID and password contained
in Flush packets are set.
A control VLAN cannot be a VLAN mapping a load-balancing instance.
The control VLAN ID and password contained in Flush packets on both devices must be the
same. That is, the control VLAN ID and password in Flush packets sent by the device must be
the same as the control VLAN ID and password in Flush packets received by the device.
NOTE
After the flush send control-vlan command is run, the interface cannot be added to the control VLAN. You need
to configure the interface to allow the packets of the control VLAN to pass through.
----End
2.2.5 (Optional) Configuring Load Balancing in a Smart Link Group
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
stp region-configuration
The Multiple Spanning Tree (MST) region view is displayed.

Step 3 Run:
instance instance-id vlan { vlan-id1 [ to vlan-id2 ] }&<1-10>

The mapping between an instance and VLANs is set.
A domain supports up to 49 instances, among which Instance 0 is the default instance and does
not need to be created.
By default, all VLANs are mapped to instance 0.
Step 4 Run:
active region-configuration
The configuration of the MST region is activated.
After configuring the domain name, VLAN mapping table, or MSTP revision level, you must
run the active region-configuration command for the configuration to take effect.
Step 5 Run:
quit
Return to the system view.
Step 6 Run:
Step 7 Run:
load-balance instance { instance-id1 [ to instance-id2 ] } &<1-10> slave
Packets of the VLANs bound to the specified instance are sent from the slave interface to
implement load balancing.
----End
2.2.6 (Optional) Enabling Revertive Switching and Setting the WTR

Time
Context
When the active link in a Smart Link group fails, the traffic is automatically switched to the
standby link. The original active link does not preempt the traffic but remains blocked after
recovering from the fault. To switch the traffic back to the active link, you can adopt either of
the following methods:
l Enable the revertive switching of a Smart Link group. The switching is automatically
performed after the revertive switching timer times out.
l Run the smart-link manual switch command to perform the link switching forcibly.
NOTE
The link switching is performed only when the two member interfaces in a group are both Up.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
restore enable
Revertive switching is enabled for the Smart Link group.
By default, the revertive switching of the Smart Link group is disabled.
Step 4 (Optional) Run:

timer wtr wtr-time
The wait to recover (WTR) time of the Smart Link group is set.
By default, the WTR time of a Smart Link group is 60 seconds.
----End
2.2.7 (Optional) Enabling the Receiving of Flush Packets
Context
An interface receives Flush packets only when it is configured with the control VLAN ID and
added to this VLAN.
Do as follows on SwitchA, SwitchB, and SwitchC shown in Figure 2-1.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the downlink interface of the SwitchA, SwitchB, or SwitchC is displayed.
Step 3 Run:
smart-link flush receive control-vlan vlan-id [ password simple password ]
The interface is enabled to receive Flush packets, and the control VLAN ID and password
contained in Flush packets are set.
The password is optional. If no password is specified, no password is used for authentication.

When the control VLAN ID is changed, the password must also be changed.
The control VLAN ID and password contained in Flush packets on both devices must be the
same. That is, the control VLAN ID and password in Flush packets sent by the device must be
the same as the control VLAN ID and password in Flush packets received by the device.
----End

2.2.8 (Optional) Enabling a Physical Interface to Notify the VPLS

orVLL Module When Receiving a Flush Packet
Context
If a CE is dual-homed to the VPLS or VLL network through VLANIF interfaces, dot1q sub-
interfaces or QinQ sub-interfaces of PEs, you can associate Smart Link with VPLS or VLL on
the corresponding physical interfaces of PEs. If a VLANIF interface, dot1q sub-interface or
QinQ sub-interface of a PE connected to the CE is bound to a VSI instance, you can run the
smart-link flush receive and smart-link { vpls-notify | vll-notify } enable commands on the
corresponding physical interface to enable the physical interface to notify the VPLS or VLL
module after receiving a Flush packet. After the VPLS or VLL module receives the notification,
it deletes the MAC address in the bound VSI instance and sends a notification to the remote
device, requesting the remote device to update the corresponding MAC address entry.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
smart-link { vpls-notify | vll-notify } enable
The interface is enabled to notify the VPLS or VLL module when receiving a Flush packet.
By default, an interface does not notify the VPLS or VLL module when receiving a Flush packet.
NOTE
You can associate Smart Link with VPLS only when a CE is connected to the VPLS network through a
VLANIF interface, dot1q sub-interfaces or QinQ sub-interfaces of a PE.
----End
2.2.9 (Optional) Setting the Holdtime of the Smart Link Switchover
Context
If the Smart Link switchover is performed because of temporary interruption, packet forwarding
and system performance are affected. To address this problem, you can set the holdtime of the
Smart Link switchover. If the interface of the Smart Link group repeatedly alternates between
Up and Down states, the status of the Smart Link group is not immediately changed, but is
changed according to the Up or Down status obtained by an interface of the Smart Link group
until the holdtime expires. In this manner, Smart Link switchover caused by link interruption is
suppressed.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
smart-link hold-time hold-time
The holdtime of the Smart Link switchover is set.
----End
2.2.10 Enabling the Functions of the Smart Link Group
Context
After the functions of the Smart Link group are enabled, the standby interface in the group is
blocked. After the functions of the Smart Link group are disabled, the blocked standby interface
is recovered.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
smart-link enable
The functions of the Smart Link group are enabled.
----End
Procedure
l Run the display smart-link group { all | group-id } command to check information about
a Smart Link group.
l Run the display smart-link flush command to check information about the received Flush
packets.
----End

Example
Run the display smart-link group { all | group-id } command to check information about a
Smart Link group. The following information is displayed:
<Quidway> display smart-link group 1
Smart Link group 1 information :
Smart Link group was enabled
Wtr-time is: 30 sec.
Load-Balance Instance: 1 to 2
There is no protected-vlan reference-instance
DeviceID: 0018-2000-0083 Control-vlan ID: 20
Member Role State Flush Count Last-Flush-Time
------------------------------------------------------------------------
GigabitEthernet1/0/1 Master Active 1 2008/11/21 16:37:20 UTC
+05:00
GigabitEthernet1/0/2 Slave Inactive 2 2008/11/21 17:45:20 UTC
+05:00
If the configuration is correct, the following information is displayed:

l The functions of the Smart Link group are enabled. Therefore, "Smart link group was
enabled" is displayed.
l The status of the interfaces in the Smart Link group is displayed, including the role of each
interface in the group, number of sent Flush packets, and time when the last Flush packets
are sent. As shown in the preceding information, GE 1/0/1 is the master interface in the
Smart Link group; this interface is in the Forwarding state; it sent a Flush packet at 16:37
on 2008-11-21.
l The control VLAN ID contained in the sent Flush packets is 20.
Run the display smart-link flush command, and you can view information about received Flush
packets.
<Quidway> display smart-link flush
Receive flush packets count: 1191
Receive last flush interface: GigabitEthernet1/0/1
Receive last flush packet time: 16:48:53 UTC+05:00
2009/02/23
Receive last flush packet source mac: 0018-0202-0088
Receive last flush packet control vlan ID: 20
2.3 Configuring a Flow Control Policy in a Smart Link

Group
This section describes how to configure the advanced functions of the Smart Link group, such
as lock of data flows and manual switchover between links.

As shown in Figure 2-2, the basic functions and revertive switching of the Smart Link group
are enabled on Switch D. During maintenance, the active link in the Smart Link group needs to
be inspected. To prevent the inspection from affecting normal services, you need to configure
a flow control policy for the Smart Link group. Through the configuration, you can forcibly lock
the data flows to the standby link and switch them back to the active link after the inspection is
complete.

Figure 2-2 Data flow control policy

SwitchA
SwitchB SwitchC
Smart Link
group
Active link
SwitchD SwitchE
Inactive link
Before configuring a flow control policy for the Smart Link group, complete the following task:
l 2.2 Configuring a Smart Link Group
Data Preparation
None.
2.3.2 Locking Data Flows on the Master Interface

Context
CAUTION
If data flows are locked on the master interface, they cannot be switched to the slave interface
automatically when the master interface fails. As a result, traffic is interrupted.
Do as follows on SwitchD shown in Figure 2-2.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
smart-link lock

Data flows are locked on the master interface.
----End
2.3.3 Locking Data Flows on the Slave Interface

Context
CAUTION
If data flows are locked on the slave interface, they cannot be switched to the master interface
automatically when the slave interface fails. As a result, traffic is interrupted.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
smart-link force
Data flows are locked on the slave interface.
----End
2.3.4 Switching Data Flows Manually

Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
smart-link manual switch

Data flows are switched to the other link.

To implement active/standby switchover between links, ensure that:
l The master interface and slave interface exist and are both in Up state.
l The smart-link command is not run to lock data streams.
The smart-link manual switch command can be repeatedly used in the Smart Link group view.
Each time you run the command, the active/standby switchover is performed between links.
Packet loss occurs during the switchover. The duration is measured in milliseconds.
----End
Procedure
Step 1 Run the display smart-link group { all | group-id } command to check information about a
Smart Link group.
----End
Example
Run the display smart-link group { all | group-id } command. If lock is displayed, it indicates
that data flows are locked on the master interface. If force is displayed, it means that data flows
are locked on the slave interface.
<Quidway> display smart-link group 1
Link status:lock
Load-Balance Instance: 1 to 2
------------------------------------------------------------------------
+05:00
+05:00
2.4 Configuring a Monitor Link Group

This section describes how to create a Monitor Link group, configure the uplink and downlink
interfaces, and enable the revertive switching.

As shown in Figure 2-3, the uplink of Switch A is faulty. Although Smart Link is enabled on
Switch C, link switching is not performed because the active link is not faulty. In this case,
services are interrupted. To enable the Smart Link group to respond more quickly to the faults

of the uplink, you need to configure the Monitor Link function on the device connected to the
active link to monitor the status of the uplink. When a fault occurs on an uplink, the active link
of the Smart Link group is rapidly blocked. In this way, the Smart Link group can detect the
fault and switch the traffic to the standby link to reduce the service interruption duration.
When the uplink interface belongs to a Smart Link group, the uplink interface is considered as
faulty only if the maser and slave interfaces of the Smart Link group are in standby state
(including the Down state).
Figure 2-3 Application scenario of the Monitor Link
IP/MPLS
core
network
Smart Link group

GE1/0/1 GE1/0/1
GE1/0/2
Monitor Link group Monitor Link group
GE2/0/1
SwitchA GE2/0/1 SwitchB
Smart Link group GE1/0/1 GE1/0/2
SwitchC
Active link
User1 User2 Inactive link
As shown in Figure 2-3, the link between Switch A and Router breaks. Although Smart Link
is enabled on Switch C and Switch D, link switching is not performed because the active link
does not fail. In this case, services are interrupted. To enable the Smart Link group to respond
more quickly to the faults of the uplink, you need to configure the Monitor Link function on the
device connected to the active link Monitor Link to monitor the status of the uplink. When a
fault occurs, the active link of the Smart Link group is blocked quickly. The Smart Link group
can then detect the fault and switch the traffic to the inactive link. This shortens the service
interruption duration.

Before configuring the basic functions of the Monitor Link group, complete the following tasks:
l 2.2 Configuring a Smart Link Group.
l Ensuring that no interface in the Monitor Link group is added to an Eth-Trunk, Smart Link
group and other Monitor Link group.
Data Preparation
To configure the basic functions of the Monitor Link group, you need the following data.
No. Data
1 ID of the Monitor Link group
2 Number of each interface added to the Monitor Link group
3 Revertive switching interval of the Monitor Link group
4 ID of the Smart Link group
2.4.2 Creating a Monitor Link Group

Context
Do as follows on SwitchA and SwitchB.
Procedure
Step 1 Run:
system-view

Step 2 Run:
monitor-link group group-id
A Monitor Link group is created and the Monitor Link group view is displayed.
----End
2.4.3 Configuring the Uplink and Downlink Interfaces in a Monitor

Link Group
Context
Procedure
Step 1 Run:

system-view
Step 2 Run:
The Monitor Link group view is displayed. The S9700 supports a maximum of 16 Monitor Link
groups.
Step 3 Run:
port interface-type interface-number { downlink [ downlink-id ] | uplink }
An interface is configured as the uplink interface or downlink interface of the Monitor Link
group.
Or run:
smart-link group group-id uplink
An interface cannot be added to a Monitor Link group in the following situations:
l The interface is added to an Eth-Trunk.

l The interface is added to a Smart Link group.
l The interface is added to another Monitor Link group.
A Smart Link group is configured as the uplink interface of the Monitor Link group.
NOTE
The status of the uplink interface determines the status of the Monitor Link group. Therefore, after the
downlink interface is added to the Monitor Link group, the result of the shutdown or undo shutdown
command can be retained before the status of the uplink interface changes. When the status of the uplink
interface changes, the status of the downlink interfaces changes as follows:
l When an uplink interface in Up state is added to the Monitor Link group or when an uplink interface
in Down state becomes Up, all the downlink interfaces in the Monitor Link group become Up.
l When an uplink interface is deleted from the Monitor Link group or when an uplink interface in Up
state becomes Down, all the downlink interfaces in the Monitor Link group become Down.
To add a Smart Link group to a Monitor Link group, you need to delete the existing uplink interface of the
Monitor Link group. The Smart Link group and common interfaces are incompatible when serving as the
uplink interface for a Monitor Link group.
----End
2.4.4 Setting the Revertive Switching Interval of a Monitor Link

group
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
The Monitor Link group view is displayed.
Step 3 Run:
timer recover-time recover-time
The interval of revertive switching is set.
By default, the revertive switching of a Monitor Link group is enabled and the interval of
revertive switching is 3 seconds.
----End
Procedure
Step 1 Run the display monitor-link group { all | group-id } command to check information about a
Monitor Link group.
----End
Example
Run the display monitor-link group { all | group-id } [ | count ] [ | { begin | include |
exclude } regular-expression ], and you can view basic information about the interfaces in the
Monitor Link group, including the role and status of the interfaces and the time when the
interfaces become Up or Down for the last time.
<Quidway> display monitor-link group 1
Monitor Link group 1 information :
Recover-timer is 5 sec.
Member Role State Last-up-time Last-down-
time
GigabitEthernet1/0/1 UpLk UP 0000/00/00 00:00:00 UTC+00:00 0000/00/00
00:00:00 UTC+00:00
GigabitEthernet1/0/2 DwLk[1] DOWN 0000/00/00 00:00:00 UTC+00:00 0000/00/00
00:00:00 UTC+00:00
2.5 Maintaining the Smart Link

This section describes how to debug the Smart Link.
2.5.1 Debugging the Smart Link
Context
NOTE
Debugging affects the performance of the system. So, after debugging, run the undo debugging all
command to disable it immediately.

Procedure
l Run the debugging smart-link { all | error | event | fsm-machine } [ group group-id ] to
enable debugging of the Smart Link.
l Run the debugging smart-link flush { all | receive | send } command to enable debugging
of Flush packets.
----End

This section provides several configuration examples of the Smart Link.
2.6.1 Example for Configuring Load Balancing Between Active and

Standby Links of a Smart Link Group
As shown in Figure 2-4. To ensure network reliability, the customer network is dual-homed to
the WAN. Packets of VLAN 100 and VLAN 500 are transmitted through the standby link, and
packets of other VLANs are transmitted through the active link. When the active link fails,
packets on the active link can be switched to the standby link quickly. When the standby link
fails, packets of VLAN 100 and VLAN 500 can be switched to the active link quickly. The
service interruption duration is restricted to millisecond level.
Figure 2-4 Networking diagram for configuring load balancing between active and standby links
of a Smart Link group
SwitchB SwitchC
GE1/0/2 GE1/0/2
GE1/0/1 GE1/0/1
Smart Link
group
GE1/0/1 GE1/0/2
SwitchA Active link
Inactive link
VLAN
100 500

1. On Switch A, configure Smart Link multi-instance and add the uplink interfaces to the
Smart Link group.
2. Configure load balancing on Switch A.
3. Enable revertive switching on Switch A.
4. Enable Switch A to send Flush packets.
5. Enable Switch B and Switch C to receive Flush packets.
6. Enable Smart Link on Switch A.
Data Preparation
l IDs of instances and IDs of the VLANs bound to the instances on Switch A
l ID of a Smart Link group
l Numbers of the uplink interfaces on Switch A
l Control VLAN ID and password contained in Flush packets
Procedure
Step 1 On Switch A, configure the control VLAN and add the interfaces to the control VLAN.
<SwitchA> system-view
[SwitchA] vlan batch 10 100 500
[SwitchA-GigabitEthernet1/0/1] port link-type trunk
[SwitchA-GigabitEthernet1/0/1] port trunk allow-pass vlan 10 100 500
[SwitchA-GigabitEthernet1/0/2] port trunk allow-pass vlan 10 100 500
The configurations of Switch B and Switch C are similar to the configuration of Switch A, and
are not mentioned here.
Step 2 Configure VLAN mapping on Switch A.
[SwitchA] stp region-configuration
[SwitchA-mst-region] instance 10 vlan 100 500
[SwitchA-mst-region] active region-configuration
[SwitchA-mst-region] quit
Step 3 Add the uplink interfaces to the Smart Link group and specify the master and slave interfaces.
Ensure that STP is disabled on the uplink interfaces.
# Configure Switch A.
[SwitchA-GigabitEthernet1/0/1] stp disable

[SwitchA] smart-link group 1

[SwitchA-smlk-group1] port gigabitethernet 1/0/1 master
[SwitchA-smlk-group1] port gigabitethernet 1/0/2 slave
Step 4 Configure load balancing on Switch A.

[SwitchA-smlk-group1] load-balance instance 10 slave
Step 5 Enable the revertive switching and set the wait-to-restore (WTR) time.
[SwitchA-smlk-group1] restore enable
[SwitchA-smlk-group1] timer wtr 30
Step 6 Enable the sending of Flush packets.

[SwitchA-smlk-group1] flush send control-vlan 10 password simple 123
Step 7 Enable Smart Link on Switch A.

[SwitchA-smlk-group1] smart-link enable
Step 8 Enable the receiving of Flush packets.

# Configure Switch B.
[SwitchB] interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] smart-link flush receive control-vlan 10 password
simple 123
[SwitchB-GigabitEthernet1/0/1] quit
simple 123
# Configure Switch C.
[SwitchC] interface gigabitethernet 1/0/1
[SwitchC-GigabitEthernet1/0/1] smart-link flush receive control-vlan 10 password
simple 123
[SwitchC-GigabitEthernet1/0/1] quit
[SwitchC-GigabitEthernet1/0/2] smart-link flush receive control-vlan 10 password
simple 123

# Run the display smart-link group command to view information about the Smart Link group
on Switch A. If the following information is displayed, the configuration is successful.
l The Smart Link function is enabled.
l The interval of revertive switching is 30 seconds.
l The control VLAN ID is 10.
l GE 1/0/1 is the master interface and is in Active state, and GE 1/0/2 is the slave interface
and is in Inactive state. The load balancing function is configured.
<SwitchA> display smart-link group 1
Load-Balance Instance: 10

------------------------------------------------------------------------
+05:00
+05:00
# Run the shutdown command to shut down GE 1/0/1, and you can find that GE 1/0/1 is in
Inactive state and GE 1/0/2 is in Active state.
[SwitchA-GigabitEthernet1/0/1] shutdown
[SwitchA-GigabitEthernet1/0/1] display smart-link group 1
------------------------------------------------------------------------
GigabitEthernet1/0/1 Master Inactive 1 2009/01/05 10:33:46 UTC
+05:00
GigabitEthernet1/0/2 Slave Active 1 2009/01/05 10:34:46 UTC
+05:00
# Run the undo shutdown command to enable GE 1/0/1 and wait for 30 seconds. Then you can
find that GE 1/0/1 is in Active state and GE 1/0/2 is in Inactive state.
[SwitchA-GigabitEthernet1/0/1] undo shutdown
------------------------------------------------------------------------
+05:00
+05:00
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 100 500
#
instance 10 vlan 100 500
#
port link-type trunk
port trunk allow-pass vlan 10 100 500
stp disable
#
stp disable
#
smart-link group 1
load-balance instance 10 slave

restore enable
smart-link enable
port GigabitEthernet1/0/1 master
port GigabitEthernet1/0/2 slave
timer wtr 30
flush send control-vlan 10 password simple 123
#
return

#
sysname SwitchB
#
#
smart-link flush receive control-vlan 10 password simple 123
#
#
return
l Configuration file of Switch C

#
sysname SwitchC
#
#
#
#
return
2.6.2 Example for Connecting the CE to the VPLS in Dual-Homing

Mode Through Smart Link
As shown in Figure 2-5, CE-A is dual homed to the VPLS network through dot1q sub-interfaces
of PE-D and PE-C. Smart Link runs between two interfaces of CE-A; only the primary link
transmits service data.
If the primary link fails, Smart Link unblocks the blocked interface. Then, service data is
transmitted to the connected PE from this interface. After receiving Flush packets of CEs, the
PEs notifies the VPLS module of clearing the forwarding entries of the local VSI. In addition,
the PEs notifies the devices connected to the PEs of clearing the forwarding entries of the VSI
by sending LDP MAC WITHDRAW messages. In this case, the returning traffic of CE-B can
be switched to the normal link.

Figure 2-5 Networking diagram for connecting the CE to the VPLS in dual-homing mode
through Smart Link
PE-D PE-E
Smart Link GE1/0/1.5
GE1/0/1.5
GE1/0/1
GE1/0/2 VPLS
User1 GE1/0/1 User2
GE1/0/2 GE1/0/2.5
GE1/0/2.5 CE-B
CE-A
PE-C PE-F
Active link
Inactive link
1. Configure VPLS.
2. Enable Smart Link on CE-A.
3. Enable revertive switching on CE-A.
4. Enable CE-A to send Flush packets.
5. Enable PE-C and PE-D to receive Flush packets and enable their interfaces to notify the
VPLS module when receiving Flush packets.
6. Enable VPLS functions on PEs.
Data Preparation
l IDs of the VSIs on CE-A and IDs of the VLANs bound to the VSIs
l IDs of the Smart Link groups
l Number of the uplink interface of CE-A
Procedure
Step 1 Configure the dot1q sub-interfaces.
For details, see "QinQ Configuration" in the S9700 Core Routing Switch Configuration Guide
- Ethernet.
Step 2 On CE-A, create a VLAN and add the uplink interface to the VLAN.
For details, see "VLAN Configuration" in the S9700 Core Routing Switch Configuration Guide
- Ethernet.
Step 3 Add the uplink interfaces to the Smart Link group and specify the active and standby interfaces.
Ensure that STP is disabled on the uplink interfaces.
# Disable STP on interfaces.

[CE-A] interface gigabitethernet 1/0/1

[CE-A-GigabitEthernet1/0/1] stp disable
[CE-A-GigabitEthernet1/0/1] quit
[CE-A] interface gigabitethernet 1/0/2
[CE-A-GigabitEthernet1/0/2] stp disable
[CE-A-GigabitEthernet1/0/2] quit
# Specify the active and standby interfaces in a Smart Link group.

[CE-A-smlk-group1] port gigabitethernet 1/0/1 master
[CE-A-smlk-group1] port gigabitethernet 1/0/2 slave
Step 4 Enable revertive switching and set the interval of revertive switching.
[CE-A-smlk-group1] restore enable
[CE-A-smlk-group1] timer wtr 30
Step 5 Enable the sending of Flush packets.

[CE-A-smlk-group1] flush send control-vlan 10 password simple 123
Step 6 Configure the Smart Link group.

[CE-A-smlk-group1] smart-link enable
[CE-A-smlk-group1] quit
Step 7 Enable PE-C and PE-D to receive Flush packets and enable the interface to notify the VPLS
module when receiving Flush packets.
# Configure PE-C.
[PE-C] interface gigabitethernet 1/0/2
[PE-C-GigabitEthernet1/0/2] smart-link flush receive control-vlan 10 password
simple 123
[PE-C-GigabitEthernet1/0/2] smart-link vpls-notify enable
[PE-C-GigabitEthernet1/0/2] quit
[PE-C] interface gigabitethernet 1/0/1
[PE-C-GigabitEthernet1/0/1] smart-link flush receive control-vlan 10 password
simple 123
[PE-C-GigabitEthernet1/0/1] quit
# Configure PE-D.
[PE-D] interface gigabitethernet 1/0/1
[PE-D-GigabitEthernet1/0/1] smart-link flush receive control-vlan 10 password
simple 123
[PE-D-GigabitEthernet1/0/1] smart-link vpls-notify enable
[PE-D-GigabitEthernet1/0/1] quit
[PE-D] interface gigabitethernet 1/0/2
[PE-D-GigabitEthernet1/0/2] smart-link flush receive control-vlan 10 password
simple 123
[PE-D-GigabitEthernet1/0/2] quit
Step 8 Configure the VPLS network on PE-C, PE-D, PE-E, and PE-F.
The configuration procedures are not mentioned here. For details, see "VPLS Configuration" in
the S9700 Core Routing Switch Configuration Guide - VPN.
on CE-A. If the following information is displayed, the configuration is successful.
l The functions of the Smart Link group are enabled.

l The control VLAN ID is 10.
l GE 1/0/1 is the active interface and is in Active state, and GE 1/0/2 is the standby interface
and is in Inactive state.

<CE-A> display smart-link group 1

There is no Load-Balance
------------------------------------------------------------------------
+05:00
+05:00
[CE-A-GigabitEthernet1/0/1] shutdown
[CE-A-GigabitEthernet1/0/1] display smart-link group 1
------------------------------------------------------------------------
+05:00
+05:00
# After a period, run the display mac-address command on CE-B to check MAC addresses,
and you can find that the outgoing interface of CE-A is GE 1/0/1. This indicates that the active
and standby switchover on CE-A triggers the switching of returning services on the link of CE-
B.
----End
Configuration Files
NOTE
For the configurations related to VPLS, see "QinQ Configuration" in the S9700 Core Routing Switch
Configuration Guide - Ethernet.
l Configuration file of CE-A
#
sysname CE-A
#
vlan batch 10
#
port trunk allow-pass vlan 10
stp disable
#
stp disable
#
smart-link group 1
restore enable
smart-link enable

timer wtr 30
#
return
l Configuration file of PE-C

#
sysname PE-C
#
vlan batch 10
#
smart-link vpls-notify enable
#
#
interface GigabitEthernet1/0/2.5
dot1q termination vid 20
l2 binding vsi vsi1
#
return
l Configuration file of PE-D

#
sysname PE-D
#
vlan batch 10
#
smart-link vpls-notify enable
#
#
l2 binding vsi vsi1
#
return
2.6.3 Example for Associating Smart Link with Multicast Services
As shown in Figure 2-6, Switch A is connected to Switch B and Switch C through two links;
Smart Link is run between GE 1/0/2 and GE 1/0/3 of Switch A; multicast users access GE 1/0/1.
At the beginning, multicast data is sent to multicast users through the primary link. When the
primary link fails, the active and standby switchover of the Smart Link group occurs. Then,
multicast data is sent to users through the slave link.

Figure 2-6 Networking diagram for associating Smart Link with multicast services
SwitchB
Monitor Link
Smart Link GE1/0/3
GE1/0/2
GE1/0/1 GE1/0/2
GE1/0/4 Internet
GE1/0/5
LSW SwitchA GE1/0/3 SwitchD Multicast
GE1/0/3 GE1/0/4 Source
Monitor Link
SwitchC Active link
Inactive link
1. Configure Smart Link and IGMP snooping on Switch A.
2. Enable Switch B, Switch C, and Switch D to receive Flush packets and configure IGMP
snooping.
3. Enable the IGMP snooping querier function on Switch D.
Data Preparation
l IDs of the VSIs on Switch A and IDs of the VLANs bound to the VSIs
l Number of the uplink interface of Switch A
l Addresses of static multicast groups, 225.1.1.1, 225.1.1.2, and 225.1.1.3
l VLAN ID of multicast users being 3
Procedure
Step 1 Configure Switch A.
1. Create a VLAN and add interfaces to the VLAN.
[SwitchA] vlan 3
[SwitchA-vlan3] quit
[SwitchA-GigabitEthernet1/0/2] port trunk allow-pass vlan 3


[SwitchA-GigabitEthernet1/0/1] port hybrid tagged vlan 3
2. Configure Smart Link.


[SwitchA-smlk-group1] quit
3. Configure IGMP snooping.

# Enable IGMP snooping globally and enable Switch A to send IGMP Query messages.
[SwitchA] igmp-snooping enable
[SwitchA] igmp-snooping send-query enable
# Enable IGMP snooping in VLAN 3.

[SwitchA] vlan 3
[SwitchA-vlan3] igmp-snooping enable
Step 2 Configure Switch B.

[SwitchB] vlan 3
[SwitchB-vlan3] quit
[SwitchB-GigabitEthernet1/0/2] port link-type trunk
[SwitchB-GigabitEthernet1/0/2] port trunk allow-pass vlan 3

[SwitchB-GigabitEthernet1/0/2] smart-link flush receive control-vlan 3
password simple 123
3. Configure functions of a Monitor Link group.

[SwitchB] monitor-link group 1
[SwitchB-mtlk-group1] port gigabitethernet 1/0/3 uplink
[SwitchB-mtlk-group1] port gigabitethernet 1/0/2 downlink 1
[SwitchB-mtlk-group1] quit

# Enable IGMP snooping globally and enable Switch B to send IGMP Query messages.
[SwitchB] igmp-snooping enable
[SwitchB] igmp-snooping send-query enable

[SwitchB] vlan 3
[SwitchB-vlan3] igmp-snooping enable
Step 3 Configure Switch C.


[Quidway] sysname SwitchC
[SwitchC] vlan 3
[SwitchC-vlan3] quit
[SwitchC-GigabitEthernet1/0/3] port link-type trunk
[SwitchC-GigabitEthernet1/0/3] port trunk allow-pass vlan 3

[SwitchC-GigabitEthernet1/0/3] smart-link flush receive control-vlan 3
password simple 123
3. Configure functions of a Monitor Link group.

[SwitchC] monitor-link group 1
[SwitchC-mtlk-group1] port gigabitethernet 1/0/4 uplink
[SwitchC-mtlk-group1] port gigabitethernet 1/0/3 downlink 1
[SwitchC-mtlk-group1] quit

# Enable IGMP snooping globally and enable Switch C to send IGMP Query messages.
[SwitchC] igmp-snooping enable
[SwitchC] igmp-snooping send-query enable

[SwitchC] vlan 3
[SwitchC-vlan3] igmp-snooping enable
Step 4 Configure Switch D.

[Quidway] sysname SwitchD
[SwitchD] vlan 3
[SwitchD-vlan3] quit
[SwitchD] interface gigabitethernet 1/0/4
[SwitchD-GigabitEthernet1/0/4] port link-type trunk
[SwitchD-GigabitEthernet1/0/4] port trunk allow-pass vlan 3
[SwitchD-GigabitEthernet1/0/4] quit

[SwitchD-GigabitEthernet1/0/4] smart-link flush receive control-vlan 3
password simple 123
[SwitchD-GigabitEthernet1/0/5] smart-link flush receive control-vlan 3
password simple 123

# Enable IGMP snooping globally and enable Switch D to send IGMP Query messages.
[SwitchD] igmp-snooping enable
[SwitchD] igmp-snooping send-query enable


[SwitchD] vlan 3
[SwitchD-vlan3] igmp-snooping enable

on Switch A. You can find that GE 1/0/2 is the active interface and is in Active state, and GE
1/0/3 is the standby interface and is in Inactive state.
------------------------------------------------------------------------
+05:00
+05:00
# Users connected to the LSW can receive multicast channels with the IP addresses as 225.1.1.1,
225.1.1.2, and 225.1.1.3.
------------------------------------------------------------------------
+05:00
+05:00
# Users connected to the LSW can still receive multicast channels with the IP address as
225.1.1.1, 225.1.1.2, and 225.1.1.3. This indicates that the active and standby switchover of the
Smart Link group on Switch A results in the switching of the transmission path of multicast data
on Switch D.
----End
Configuration Files
#
sysname SwitchA
#
igmp-snooping enable
igmp-snooping send-query enable
#
vlan 3

#
port hybrid tagged vlan 3
#
stp disable
#
stp disable
#
smart-link group 1
restore enable
smart-link enable
timer wtr 30
#
return
#
sysname SwitchB
#
#
vlan 3
#
#
#
monitor-link group 1
port GigabitEthernet1/0/3 uplink
port GigabitEthernet1/0/2 downlink 1
#
return
#
sysname SwitchC
#
#
vlan 3
#
#
#


#
return
l Configuration file of Switch D

#
sysname SwitchD
#
#
vlan 3
#
#
#
return
2.6.4 Example for Applying the Smart Link Functions

As shown in Figure 2-7, Switch C is connected to user networks. It accesses the backbone
network through uplink devices Switch A and Switch B in dual-homed mode.
Switch A and Switch C are connected to uplink devices in dual-homed mode. One out of each
link pair needs to be blocked to prevent loops. When the active link fails, the data flows can be
rapidly switched to the standby link to ensure normal services.
In addition, a monitoring mechanism is required to prevent service interruption caused by faults
of the uplink. This monitoring mechanism enables the downlink to quickly detect the fault of
the uplink. When the uplink fails, link switching can be performed immediately to shorten the
duration of service interruption.

Figure 2-7 Networking of Smart Link application
IP/MPLS
core
network
Smart Link group

GE1/0/1 GE1/0/1
GE1/0/2
GE2/0/2
Monitor Link group Monitor Link group
GE2/0/2
SwitchA
GE2/0/1 GE2/0/1 SwitchB
Smart Link group GE1/0/1 GE1/0/2
SwitchC
Active link
User1 User2 Inactive link
1. Configure Smart Link groups on Switch A and Switch C, and add uplink interfaces to the
groups.
2. Configure Monitor Link groups on Switch A and Switch B.
3. Enable Switch A and Switch C to send Flush packets.
4. Enable Switch A and Switch C to receive Flush packets.
Data Preparation
l Numbers of interfaces on Switch A, Switch B, and Switch C


l IDs of the Monitor Link groups and the numbers of the downlinks
Procedure
Step 1 Configure the same control VLAN on Switch A, Switch B, and Switch C. Add the interfaces of
the Smart Link group or Monitor Link group to this VLAN.
The configuration procedures are not mentioned here. For details, see VLAN Configuration in
the S9700 Core Routing Switch Configuration Guide - Ethernet.
Step 2 Create Smart Link groups and enable the functions of the groups.
<SwitchC> system-view
[SwitchC] smart-link group 2
[SwitchC-smlk-group1] quit
Step 3 Add interfaces to Smart Link groups and specify the master and slave interfaces of each Smart
Link group
[SwitchA] interface gigabitethernet1/0/1
[SwitchA]smart-link group 1
[SwitchC] interface gigabitethernet1/0/1
[SwitchC-GigabitEthernet1/0/1] stp disable
[SwitchC-smlk-group2] port gigabitethernet 1/0/1 master
[SwitchC-smlk-group2] port gigabitethernet 1/0/2 slave
Step 4 Enable revertive switching and set the interval of revertive switching.
[SwitchC-smlk-group2] restore enable
[SwitchC-smlk-group2] timer wtr 30
Step 5 Enable the sending and receiving of Flush packets.

[SwitchA-GigabitEthernet2/0/1] smart-link flush receive control-vlan 10 password
simple 123
[SwitchA-GigabitEthernet2/0/2] smart-link flush receive control-vlan 10 password
simple 123
<SwitchB> system-view
simple 123
simple 123
[SwitchC-smlk-group2] flush send control-vlan 10 password simple 123
Step 6 Enabling the Functions of the Smart Link Group

[SwitchC-smlk-group2] smart-link enable
[SwitchC-smlk-group2] quit
Step 7 Create Monitor Link groups and add the uplink and downlink interfaces to the Monitor Link
groups.
[SwitchA] monitor-link group 1
[SwitchA-mtlk-group1] smart-link group 1 uplink
[SwitchA-mtlk-group1] port gigabitethernet 2/0/1 downlink 1
[SwitchB] monitor-link group 2
[SwitchB-mtlk-group2] port gigabitethernet 1/0/1 uplink
[SwitchB-mtlk-group2] port gigabitethernet 2/0/1 downlink 1
Step 8 Set the revertive switching interval of the Monitor Link groups.
[SwitchA-mtlk-group1] timer recover-time 10
[SwitchB-mtlk-group2] timer recover-time 10


------------------------------------------------------------------------
+05:00
+05:00
<SwitchA> display monitor-link group 1
Monitor Link group 1 information :
Recover-timer is 3 sec.
Member Role State Last-up-time Last-down-tim
e
Smart-link1 UpLk UP 0000/00/00 00:00:00 UTC+05:00 0000/0
0/00 00:00:00 UTC+05:00
GigabitEthernet2/0/1 DwLk[1] UP 0000/00/00 00:00:00 UTC+05:00 0000/0
0/00 00:00:00 UTC+05:00
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
stp disable
#
stp disable
#
#
#
smart-link group 1
smart-link enable
timer wtr 30
restore enable
#
smart-link group 1 uplink
timer recover-time 10
#
return

#
sysname SwitchB
#

vlan batch 10
#
#
#
#
timer recover-time 10
#
return

#
sysname SwitchC
#
vlan batch 10
#
stp disable
#
stp disable
#
smart-link group 2
restore enable
smart-link enable
timer wtr 30
#
return

Configuration Guide - Reliability 3 ERPS (G.8032) Configuration
3 ERPS (G.8032) Configuration
About This Chapter
Ethernet Ring Protection Switching (ERPS) is a standard protocol issued by the ITU-T to prevent
loops on ring networks. ERPS provides carrier-class relaibility with a fast convergence speed.
ERPS takes effect on a ring network if all devices on a ring network support it.
3.1 Overview of ERPS

ERPS is a standard protocol issued by the ITU-T to prevent loops on ring networks. It takes
effect on a ring network if all devices on a ring network support it.
3.2 ERPS Features Supported by the S9700
This section describes ERPS features supported by the S9700. Familiarizing yourself with these
features helps you complete the configuration tasks quickly and efficiently.
3.3 Configuring ERPS
If there is no link fault on the ring network, ERPS can eliminate Ethernet redundant links. If a
link fault occurs on the ring network, ERPS can quickly restore the communication links between
the nodes on the ring network.
3.4 Maintaining EPRS
The section describes how to maintain ERPS, such as the method to clear statistics on an EPRS
ring.
This section provides an example showing how to configure ERPS functions. In this
configuration example, the networking requirements, configuration roadmap, data preparation,
and configuration files are provided.

3.1 Overview of ERPS

Background
On a complex network, loops are inevitable. With the requirement for network redundancy
backup, network designers tend to deploy multiple physical links between two devices, one of
which is the master and the others are the backup. Loops are likely or bound to occur in such a
situation.
To prevent loops from occuring, the S9700 provided by Huawei supports the ring network
protocols shown in Table 3-1. At present, Ethernet networks must have a shorter failover time
to meet service requirements. The Spanning Tree Protocol (STP), however, does not meet the
requirement in terms of the convergence performance. The Rapid Ring Protection Protocol
(RRPP) and Smart Ethernet Protection (SEP) are proprietary ring protocols, which cannot be
used for communication between Huawei and non-Huawei devices on a ring network.
Table 3-1 Ring network protocols suupported by the S9700 of Huawei
Ring Network Advantage Disadvantage

Protocol
RRPP Fast convergence speed, l Only one level subring is

meeting the requirement of supported in the RRPP ring
carrier'class reliability networking.
l RRPP is a proprietary
protocol that cannot be used
for communication between
Huawei and non-Huawei
devices.
STP/RSTP/MSTP l Applicable to all Layer 2 STP/RSTP/MSTP provides a

networks low convergence speed for a
l STP/RSTP/MSTP is a large network. It cannot meet the
standard IEEE protocol that requirement of carrier' class
helps Huawei devices reliability.
communicate with non-
Huawei devices.
SEP l Applicable to all Layer 2 SEP is a proprietary protocol that

networks can be used for communication
l Fast convergence speed, between Huawei and non-
meeting the requirement of Huawei devices.
carrier'class reliability.
l SEP can be used to display
the topology of an entire
ring, facilitating fault
location and maintenance.

Ring Network Advantage Disadvantage

Protocol
ERPS l Fast convergence speed, ERPS supports only single-ring

meeting the requirement of networking.
carrier'class reliability.
l ERPS is a standard ITU-T
protocol that helps Huawei
devices communicate with
non-Huawei devices.
ERPS Overview
Loops will cause broadcast storms, thereby exhausting network resources and paralyzing the
network. Loops also cause flapping of the MAC address table and damages MAC address entries.
ERPS is a protocol defined by the ITU-T to block specified ports to prevent loops at Layer 2.
ERPS provides carrier-class relaibility with a fast convergence speed.
Figure 3-1 ERPS single-ring networking
Network
NPE1 NPE2
LSW1 LSW4
ERPS
LSW2 RPL
LSW3
RPL Owner
CE
Blocked Port

Basic ERPS Concepts

Figure 3-1 shows a typical ERPS single-ring network. The following part describes ERPS based
on this networking. ERPS concepts include the ERPS ring, node, port role, and port status.
l ERPS ring
An ERPS ring consists of interconnected Layer 2 switching devices configured with the
same control VLAN. An ERPS ring is the basic unit for ERPS.
l Node
A node refers to a Layer 2 switching device added to an ERPS ring. A maximum of two
ports on a node can be added to the same ERPS ring.
l Port role
As defined in ERPS, a port can be an RPL Owner port or an ordinary port. The link where
the RPL Owner port resides is a ring protection link (RPL).
RPL Owner port
An ERPS ring has only one RPL Owner port, which is configured by a user. Blocking
the RPL Owner port prevents loops on the ERPS ring.
When the node where the RPL Owner port resides receives an RAPS PDU indicating
that a link or a node on the ring fails, it unblocks the RPL Owner port to allow the port
to send and receive traffic. This mechanism ensures non-stop traffic forwarding.
Ordinary port
On an ERPS ring, the ports other than the RPL Owner port are ordinary ports.
An ordinary port monitors the status of the directly-connected ERPS link, and sends
RAPS PDUs to inform the other ports if the link status changes.
l Port status
On an ERPS ring, an ERPS-enabled port can be in either of the following states:
Forwarding: In this state, the port forwards user traffic, and sends and receives ERPS
PDUs.
Discarding: In this state, the port only sends ERPS PDUs.
3.2 ERPS Features Supported by the S9700

This section describes ERPS features supported by the S9700. Familiarizing yourself with these
features helps you complete the configuration tasks quickly and efficiently.
ERPS is a protocol defined by the ITU-T to block specified ports to prevent loops at Layer 2.
Note the following aspects when configuring ERPS:
1. ERPS breaks loops only if an ERPS ring is created, the control VLAN and protected
instance are configured on the ERPS ring, and ports are added to and port roles are specified
on the the ERPS ring.
2. The WTR timer and guard timer need to be configured differently for the ERPS ring
according to real-world situations.
3. The ERPS ring can be assotiated with a fault detection protocol to reduce the traffic
interruption time.

Control VLAN
A control VLAN is configured for an ERPS ring to transmit ERPS packets.
Each ERPS ring must be configured with a control VLAN. After an interface is added to an
ERPS ring configured with a control VLAN, the interface is added to the control VLAN
automatically.
Different EPRS rings cannot be configured with the same control VLAN ID.
Unlike control VLANs, data VLANs are used to transmit data packets.
Protected instance
On a Layer 2 device running ERPS, the VLAN in which ERPS packets and data packets are
transmitted must be mapped to a protected instance so that ERPS forwards or blocks these
packets based on rules. Otherwise, VLAN packets probably cause broadcast storms on the ring
network. This will cause the network to be unavailable.
Timer
There are three timers used by ERPS: guard timer, WTR timer, and WTR timer.
l Guard Timer
After a faulty link or a faulty node recovers, the nodes on the two ends of the link or the
faulty node sends RAPS packets to inform the other nodes of the link or node recovers and
starts a Guard timer. Before the timer expires, each involved node does not process any
RAPS packet to avoid receiving out-of-date RAPS packets indicating that the link or node
fails. If the involved node receives an RAPS packet indicating that another port fails , the
local port enters the Forwarding state.
l WTR Timer
If the RPL owner port is unblocked owning to a link or node failure, the involved port may
not go Up immediately after the link or node recovers. To prevent the RPL owner port
alternates between the Up and Down states, the node where the RPL owner port resides
starts a WTR timer after receiving an RAPS packet indicating the link or node recovery. If
the node receives an RAPS packet indicating that another port fails before the timer expires,
it terminates the WTR timer. If the node does not receive any RAPS packet indicating that
another port fails before the timer expires, it unblocks the RPL owner port when the timer
expires and sends an RAPS packet indicating that the RPL owner port is blocked. After
receiving this RAPS packet, the other nodes set their ports on the ring to the Forwarding
state.
l Holdoff Timer
On different Layer 2 networks running EPRS, there may be different requirements on
protective switchover. For example, if multiple services are provided, you may hope that
the protective switchover is not performed immidiately after a server fails, ensuring that
clients do not sense the failure. In this case, you can set a Holdoff timer. If the fault occurs,
the fault is not immediately sent to ERPS untill the Holdoff timer times out.
ERPS Multi-instance
On a common ERPS network, a physical ring can be configured with a single ERPS ring and a
single blocked port can be specified on the ring. If the ERPS ring is complete, the blocked port
prevents all user data from passing through. As a result, all user data travels through a single

path over the ERPS ring, and the other link on the blocked port becomes idle, causing bandwidth
wastes.
The ERPS multi-instance allows two logical ERPS rings on a physical ring. On the ERPS ring
shown in Figure 3-2, all devices, ports, and control VLANs work based on basic ERPS rules.
A physical ring has two blocked ports. Each blocked port verifies the completeness of the
physical ring and blocks or forwards data without affecting others.
One or two ERPS rings can be configured over a physical ring. Each ERPS ring is configured
with an EPRS protected instance. Each protected instance represents a range of VLANs. The
topology calculated for a specific ERPS ring does not apply to another ERPS ring and does not
affect other rings.
With a specific protected instance for each ERPS ring, a blocked port takes effect only on VLANs
of a specific ERPS ring. Different VLANs can use separate paths, implementing traffic load
balancing and link backup.

Figure 3-2 Networking diagram for the ERPS multi-instance
Network
NPE1 NPE2
LSW3 GE1/0/1
LSW4
GE1/0/2
GE1/0/1
GE1/0/2
ERPS
GE1/0/2
GE1/0/1
LSW1 GE1/0/2
GE1/0/1
P2 LSW2
P1
CE1
CE2
VLAN: VLAN:
100~200 300~400
ERPS ring1
ERPS ring2
Blocked Port1
Blocked Port2
Data Flow1
Data Flow2
3.3 Configuring ERPS

If there is no link fault on the ring network, ERPS can eliminate Ethernet redundant links. If a
link fault occurs on the ring network, ERPS can quickly restore the communication links between
the nodes on the ring network.


Before configuring ERPS, familiarize yourself with the applicable environment, complete the
pre-configuration tasks, and obtain the required data. This can help you complete the
configuration task quickly and accurately.
Generally, redundant links are used to access an upper-layer network to provide link backup and
enhance network reliability. The use of redundant links, however, may produce loops. causing
broadcast storms and rendering the MAC address table unstable. As a result, the communication
quality deteriorates, and communication services may even be interrupted. ERPS can be
deployed on the ring network to block redundant links and unblock them if a link fault occurs.
NOTE
Only one protocol, that is, RRPP, STP, SEP, or ERPS, can be configured on one port.
Before configuring ERPS functions, complete the following tasks:
l Set up a physical ring network.

l Connect interfaces and configure physical parameters for the interfaces to allow the
physical status of the interfaces to be Up.
Data Preparation
To configure ERPS functions, you need the following data.
No. Data
1 ERPS ring ID
2 Control VLAN ID (Optional) ERPS ring description information
3 Port number and port role
4 Protected instance ID
5 (Optional) WTR timer, guard timer, and holdoff timer
6 (Optional) MEL value of the ERPS ring
7 (Optional) Ports associated with CFM
3.3.2 Creating an ERPS Ring

An ERPS ring is a basic unit of ERPS. An ERPS ring consists of interconnected Layer 2
switching devices configured with the same control VLAN.

Procedure
Step 1 Run:
system-view
Step 2 Run:
erps ring ring-id
An ERPS ring is created and the view of the ERPS ring is displayed.
If an ERPS ring needs to be deleted, ensure that no interfaces are added to the ERPS ring. If any
interface is added to the ERPS ring, a prompt message is displayed when the ERPS ring is being
deleted. In this case, run the undo erps ring command in the interface view or the undo port
command in the ERPS ring view to remove the interface. and run the undo erps ring command
to delete the ERPS ring.
----End
Follow-up Procedure
To facilitate the maintenance of devices on the ERPS ring, run the description command to
configure description information such as ERPS ring ID for these devices.
3.3.3 Configuring Control VLAN

The control VLAN is a concept relative to the data VLAN. In an ERPS ring, a control VLAN
is used to transmit ERPS packets rather than service packets of users to enhance the security of
ERPS.
Context
The same control VLAN must be configured for all devices on an ERPS ring, and different
control VLANs must be configured for different ERPS rings.
Procedure
Step 1 Run:
system-view
Step 2 Run:
erps ring ring-id
The view of the created ERPS ring is displayed.
Step 3 Run:
control-vlan vlan-id
The control VLAN is configured for the ERPS ring to forward ERPS protocol packets.
The control VLAN specified by the parameter vlan-id must be newly created. It can neither be
referenced by RRPP or SEP, nor be used in port trunk, default, VLAN mapping, or VLAN
stacking mode.

l If any interface has been added to the ERPS ring, the control VLAN cannot be modified. If
the configured control VLAN needs to be deleted, run the undo erps ring command in the
interface view or the undo port command in the ERPS ring view, and run the undo control-
vlan command to delete the control VLAN.
l If no interface is added to the ERPS ring, you can modify the control VLAN for multiple
times. Only the latest configuration takes effect.
l After the control VLAN is correctly created, the command to create ordinary VLANs vlan
batch vlan-id1 [ to vlan-id2 ] &<1-10> is automatically displayed in the configuration file.
After an interface is added to an ERPS ring configured with a control VLAN, the interface
is added to the control VLAN automatically. Note the following information:
If the type of the interface added to the ERPS ring is trunk, the port trunk allow-pass
vlan vlan-id command is displayed automatically in the configuration file.
If the type of the interface added to the ERPS ring is hybrid, the port hybrid tagged
vlan vlan-id command is displayed automatically in the configuration file.
----End
3.3.4 Configuring the Mapping Between Protected Instances and

VLANs
Interfaces can be added to an ERPS ring only after a protected instance is created. Data VLANs
can be mapped to the protected instance to implement service traffic load balancing.
Procedure
Step 1 Run:
system-view

Step 2 Run:
erps ring ring-id
The view of the ERPS ring is displayed.

Step 3 Run:
protected-instance { all | { instance-id1 [ to instance-id2 ] &<1-10>
} }
A protected instance is created on the ERPS ring.

By default, no protected instance is configured on an ERPS ring.
Running a new protected-instance command does not overide the previously configured
protected instances.
If any interface has been added to the ERPS ring, no protected instance can be modified. If a
configured protected instance needs to be deleted, run the undo erps ring command in the
interface view or the undo port command in the ERPS ring view, and run the undo protected-
instance command to delete the protected instance.
Step 4 Configure the mapping between protected instances and VLANs. Specific procedures are as
follows:
1. Run:

system-view

2. Run:
The MST region view is displayed.

3. Run:
instance instance-id vlan { vlan-id [ to vlan-id ] } &<1-10>
The mapping relationships between protected intances and VLANs are specified.
The parameter instance-id in this command must the same as the parameter instance-id in
the protected-instance command.
4. Run:
The mapping relationships are activated.
----End
3.3.5 Adding Layer 2 Ports to ERPS Ring and Configuring Port Roles
After an ERPS ring is created, ERPS breaks loops only if Layer 2 ports are added to the ERPS
ring and port roles are configured.
Prerequisites
Before adding interfaces to an ERPS ring, ensure that:
l STP and RRPP are not enabled on Layer 2 interfaces that are added to the ERPS ring.
If STP is enabled on these interfaces, run the stp disable command to disable STP.
If RRPP is enabled on these interfaces, run the rrpp disable command to disable RRPP.
l The control VLAN and protected instance are configured using the control-vlan and
protected-instance commands.
Context
As defined in ERPS, a port can be an RPL owner port or an ordinary port. The link where the
RPL owner port resides is the ring protection link.
l RPL Owner port
An ERPS ring has only one RPL Owner port, which is configured by a user. Blocking the
RPL Owner port prevents loops on the ERPS ring.
When the node where the RPL owner port resides receives an RAPS packet indicating that
a link or a node on the ring fails, it unblocks the RPL owner port to allow the port to send
and receive traffic. This mechanism ensures non-stop traffic forwarding.
l Ordinary port
On an ERPS ring, the ports other than the RPL owner port are ordinary ports.
An ordinary port monitors the status of the directly-connected ERPS link, and sends RAPS
packets to inform the other ports if the link status changes.
There are two methods to add a Layer 2 port to an ERPS ring:

l In the ERPS ring view, specify the port number and port role.

l In the interface view, add the interface to the ERPS ring and configure the port role.
NOTE
At presnet, as MAC address Update packets cannot be independantly sent, configuring the direct link
between two upstream nodes as an RPL is not recommended.
Before changing the port role, use the shutdown command to disable the port; after the role changing is
completed, use the undo shutdown command to enable the port. Otherwise, the traffic is interrupted.
Procedure
Step 1 Run:
system-view

Step 2 Select the method to add a Layer 2 port to an ERPS ring:
l In the ERPS ring view, specify the port number and port role:
1. Run:
erps ring ring-id
The view of a created ERPS ring is displayed.

2. Run:
port interface-type interface-number [ rpl owner ]
The port is added to the ERPS ring and the port role is specified.
l In the interface view, add the port to the ERPS ring and configure the port role.
1. Run:
The view of the port to be added to the ERPS ring is displayed.

2. Run:
erps ring ring-id [ rpl owner ]
The port is added to the ERPS ring and the port role is specified.
----End
3.3.6 (Optional) Configuring Timers of an ERPS Ring

After a node or a link recovers from a fault on the ERPS ring, ERPS timers are used to prevent
traffic flapping on blocked node or link, reducing the service traffic interruption time.
Context
ERPS timers consists of:
l Guard Timer
After a faulty link or a faulty node recovers, the nodes on the two ends of the link or the
faulty node sends RAPS packets to inform the other nodes of the link or node recovers and
starts a Guard timer. Before the timer expires, each involved node does not process any
RAPS packet to avoid receiving out-of-date RAPS packets indicating that the link or node
fails. If the involved node receives an RAPS packet indicating that another port fails , the
local port enters the Forwarding state.
l WTR Timer
If the RPL owner port is unblocked owning to a link or node failure, the involved port may
not go Up immediately after the link or node recovers. To prevent the RPL owner port

alternates between the Up and Down states, the node where the RPL owner port resides
starts a WTR timer after receiving an RAPS packet indicating the link or node recovery. If
the node receives an RAPS packet indicating that another port fails before the timer expires,
it terminates the WTR timer. If the node does not receive any RAPS packet indicating that
another port fails before the timer expires, it unblocks the RPL owner port when the timer
expires and sends an RAPS packet indicating that the RPL owner port is blocked. After
receiving this RAPS packet, the other nodes set their ports on the ring to the Forwarding
state.
l Holdoff Timer
On different Layer 2 networks running EPRS, there may be different requirements on
protective switchover. For example, if multt-layer services are provided, users hope that
the protective switchover is not performed immidiately after a server fails, ensuring that
clients do not sense the failure. In this case, you can set a Holdoff timer. If the fault occurs,
the fault is not immediately sent to ERPS until the Holdoff timer times out.
Procedure
Step 1 Run:
system-view
Step 2 Run:
erps ring ring-id
The view of the ERPS ring is displayed.
Step 3 Configure any of of ERPS timers as needed:

l Run:
wtr-timer time-value
The WTR timer is configured.

By default, the WTR timer is 5 minutes for the ERPS ring.
l Run:
guard-timer time_value_cs
The guard timer is configured.

By default, the guard timer is 200 centiseconds for the ERPS ring.
l Run:
holdoff-timer time-value
The holdoff timer is configured.

By default, the holdoff timer is 0 second for the ERPS ring.
----End
3.3.7 (Optional) Configuring the MEL Value of an ERPS Ring

The Maintenance Entity Level (MEL) field is contained in a protocol packet to mark the level
of the protocol packet and determine whether the protocol packet can be forwarded. If an ERPS
packet has the MEL field value smaller than the MEL value of the fault detection protocol, this
ERPS packet has a lower level and will be discarded.

Context
In addition to determining whether packets can be forwarded, the MEL value of an ERPS ring
can also be used to facilitate the communications with other vendors' devices. The same MEL
value ensures smooth communications between devices.
Procedure
Step 1 Run:
system-view

Step 2 Run:
erps ring ring-id
The view of the created ERPS ring is displayed.

Step 3 Run:
raps-mel level-id
The MEL value of the ERPS ring is set.

By default, the MEL value of ERPS packets is 7.
----End

After ERPS is configured, you can view information about the ERPS ring, such as the port
number, port role, control VLAN, protected intsnace, WTR timer, and guard timer.
Prerequisites
All configurations of the ERPS ring are complete.
Procedure
l Run the display erps [ ring ring-id ] [ verbose ] command to check information about the
ERPS ring.
----End
Example
Run the display erps [ ring ring-id ] command to view information about the ERPS ring. For
example:
<Quidway> display erps ring 1
D : Discarding
F : Forwarding
R : RPL Owner
Ring Control WTR Timer Guard Timer Port 1 Port 2
ID VLAN (min) (csec)
-----------------------------------------------------------------------
1 10 6 100 (F)GE1/0/1 (D,R)GE1/0/2
-----------------------------------------------------------------------
Run the display erps [ ring ring-id ] [ verbose ] command to view detailed information about
the ERPS ring. For example:

<Quidway> display erps ring 1 verbose

Ring ID : 1
Description : Ring 1
Control Vlan : 10
Protected Instance : 1
WTR Timer Setting (min) : 6 Running (s) : 0
Guard Timer Setting (csec) : 100 Running (csec) : 0
Holdoff Timer Setting (deciseconds) : 0 Running (deciseconds) : 0
Ring State : Idle
RAPS_MEL : 7
Time since last topology change : 0 days 0h:33m:4s
-----------------------------------------------------------------------
Port Port Role Port Status Signal Status
-----------------------------------------------------------------------
GE1/0/1 Common Forwarding Non-failed
GE1/0/2 RPL Owner Discarding Non-failed
3.4 Maintaining EPRS

The section describes how to maintain ERPS, such as the method to clear statistics on an EPRS
ring.
3.4.1 Clearing ERPS Statistics

You can run the reset commands to reset ERPS statistics to 0.
Context
CAUTION
ERPS statistics cannot be restored after being reset. Therefore, exercise caution when resetting
ERPS statistics.
Procedure
Step 1 Run:
display erps [ ring ring-id ] statistics
Statistics of the packets sent and received on ERPS interfaces are displayed. Note that the
command is run in the user view.
Step 2 Run:
reset erps [ ring ring-id ] statistics
ERPS statistics are cleared. Note that the command is run in the user view.
----End

This section provides an example showing how to configure ERPS functions. In this
configuration example, the networking requirements, configuration roadmap, data preparation,
and configuration files are provided.

3.5.1 Example for Configuring ERPS

The Ethernet Ring Protection Switching (ERPS) blocks the ring protection link (RPL) owner
port to prevent loops on a ring network. This example illustrates how to configure ERPS.
As shown in Figure 3-3, Switches A to E form a ring network on the aggregation layer. They
aggregate Layer 2 traffic from customer networks to the Layer 3 network. The Switches on the
ring network run the ERPS protocol to implement Layer 2 protection switching.
Packets sent from customer networks belong to VLANs 100 through 200. To prevent loops on
the ring network, specify an RPL owner port so that data packets from the CEs are transmitted
as follows:
l Packets sent from CE1 are forwarded through SwitchB and SwitchA.
l Packets sent from CE2 are forwarded through SwitchC, SwitchB, and SwitchA.
l Packets sent from CE3 are forwarded through SwitchD and SwitchE.

Figure 3-3 Networking diagram of a single ERPS ring
Network
NPE1 NPE2
GE1/0/2 SwitchE
SwitchA
GE1/0/1
GE1/0/1 GE1/0/2
GE1/0/2
GE1/0/1 ERPS SwitchD
SwitchB
GE1/0/1
GE1/0/2 RPL
GE1/0/1
GE1/0/2
RPL Owner CE3
CE1 SwitchC
VLAN100-
VLAN100- 200
200 CE2
VLAN100-
200
Blocked Port
Data Flow1
Data Flow2
Data Flow3
1. Create an ERPS ring, and configure a control VLAN and protected instance.
2. Add Layer 2 ports connecting the Switches to the ERPS ring and configure a port as the
RPL owner.
3. Set the guard timer and WTR timer for the ERPS ring.
4. Create VLANs and add ports to VLANs on Switches A to E to implement Layer 2
forwarding.
Data Preparation

l ERPS ring ID, control VLAN ID, and protected instance ID

l Values of the guard timer and WTR timer
l Service VLAN IDs for Layer 2 forwarding
Procedure
Step 1 Create VLANs and add ports to VLANs on Switches A to E to implement Layer 2 forwarding.
# Configure SwitchA.
[SwitchA] vlan batch 100 to 200
[SwitchA-GigabitEthernet1/0/1] port trunk allow-pass vlan 100 to 200
# Configure SwitchB.
[Quidway] sysname SwitchB
[SwitchB] vlan batch 100 to 200
[SwitchB-GigabitEthernet1/0/1] port trunk allow-pass vlan 100 to 200
# Configure SwitchC.
[SwitchC] vlan batch 100 to 200
[SwitchC-GigabitEthernet1/0/1] port trunk allow-pass vlan 100 to 200
# Configure SwitchD.
[SwitchD] vlan batch 100 to 200
[SwitchD-GigabitEthernet1/0/1] port trunk allow-pass vlan 100 to 200
# Configure SwitchE.
[Quidway] sysname SwitchE

[SwitchE] vlan batch 100 to 200

[SwitchE] interface gigabitethernet 1/0/1
[SwitchE-GigabitEthernet1/0/1] port link-type trunk
[SwitchE-GigabitEthernet1/0/1] port trunk allow-pass vlan 100 to 200
[SwitchE-GigabitEthernet1/0/1] quit
[SwitchE-GigabitEthernet1/0/2] port link-type trunk
[SwitchE-GigabitEthernet1/0/2] port trunk allow-pass vlan 100 to 200
Step 2 Create an ERPS ring, configure VLAN 10 as the control VLAN to transmit ERPS protocol
packets, and bind VLANs 100 through 200 to a protected instance.
[SwitchA] erps ring 1
[SwitchA-erps-ring1] control-vlan 10
[SwitchA-erps-ring1] protected-instance 1
[SwitchA-erps-ring1] quit
[SwitchA-mst-region] instance 1 vlan 10 100 to 200
[SwitchB] erps ring 1
[SwitchB-erps-ring1] control-vlan 10
[SwitchB-erps-ring1] protected-instance 1
[SwitchB-erps-ring1] quit
[SwitchB] stp region-configuration
[SwitchB-mst-region] instance 1 vlan 10 100 to 200
[SwitchB-mst-region] active region-configuration
[SwitchB-mst-region] quit
[SwitchC] erps ring 1
[SwitchC-erps-ring1] control-vlan 10
[SwitchC-erps-ring1] protected-instance 1
[SwitchC-erps-ring1] quit
[SwitchC] stp region-configuration
[SwitchC-mst-region] instance 1 vlan 10 100 to 200
[SwitchC-mst-region] active region-configuration
[SwitchC-mst-region] quit
[SwitchD] erps ring 1
[SwitchD-erps-ring1] control-vlan 10
[SwitchD-erps-ring1] protected-instance 1
[SwitchD-erps-ring1] quit
[SwitchD] stp region-configuration
[SwitchD-mst-region] instance 1 vlan 10 100 to 200
[SwitchD-mst-region] active region-configuration
[SwitchD-mst-region] quit
[SwitchE] erps ring 1
[SwitchE-erps-ring1] control-vlan 10
[SwitchE-erps-ring1] protected-instance 1
[SwitchE-erps-ring1] quit
[SwitchE] stp region-configuration
[SwitchE-mst-region] instance 1 vlan 10 100 to 200
[SwitchE-mst-region] active region-configuration
[SwitchE-mst-region] quit
Step 3 Add ports to the ERPS ring and configure GE1/0/2 of SwitchC as the RPL owner.

[SwitchA-GigabitEthernet1/0/1] erps ring 1
[SwitchA-GigabitEthernet1/0/2] erps ring 1
[SwitchB-GigabitEthernet1/0/1] stp disable
[SwitchB-GigabitEthernet1/0/1] erps ring 1
[SwitchB-GigabitEthernet1/0/2] erps ring 1
[SwitchC-GigabitEthernet1/0/1] erps ring 1
[SwitchC-GigabitEthernet1/0/2] erps ring 1 rpl owner
[SwitchD-GigabitEthernet1/0/1] stp disable
[SwitchD-GigabitEthernet1/0/1] erps ring 1
[SwitchD-GigabitEthernet1/0/2] erps ring 1
[SwitchE-GigabitEthernet1/0/1] stp disable
[SwitchE-GigabitEthernet1/0/1] erps ring 1
[SwitchE-GigabitEthernet1/0/2] erps ring 1
Step 4 Set the guard timer and WTR timer for the ERPS ring.
[SwitchA] erps ring 1
[SwitchA-erps-ring1] wtr-timer 6
[SwitchA-erps-ring1] guard-timer 100
[SwitchA-erps-ring1] quit
[SwitchB] erps ring 1
[SwitchB-erps-ring1] wtr-timer 6
[SwitchB-erps-ring1] guard-timer 100
[SwitchB-erps-ring1] quit

[SwitchC] erps ring 1
[SwitchC-erps-ring1] wtr-timer 6
[SwitchC-erps-ring1] guard-timer 100
[SwitchC-erps-ring1] quit
[SwitchD] erps ring 1
[SwitchD-erps-ring1] wtr-timer 6
[SwitchD-erps-ring1] guard-timer 100
[SwitchD-erps-ring1] quit
[SwitchE] erps ring 1
[SwitchE-erps-ring1] wtr-timer 6
[SwitchE-erps-ring1] guard-timer 100
[SwitchE-erps-ring1] quit

After completing the preceding configurations, perform the following operations to verify the
configuration. SwitchC is used as an example.
l Run the display erps ring 1 command to view brief information about the ERPS ring, and
ports of SwitchC that have been added to the ring.
[SwitchC] display erps ring 1
D : Discarding
F : Forwarding
R : RPL Owner
Ring Control WTR Timer Guard Timer Port 1 Port 2
ID VLAN (min) (csec)
-------------------------------------------------------------------------------
-
1 10 6 100 (F)GE1/0/1 (D,R)GE1/0/2
-------------------------------------------------------------------------------
-
l Run the display erps ring 1 verbose command to view detailed information about the ERPS
ring, and ports of SwitchC that have been added to the ring.
[SwitchC] display erps ring 1 verboseRing ID : 1
Description : Ring 1
Control Vlan : 10
Protected Instance : 1
WTR Timer Setting (min) : 6 Running (s) : 0
Guard Timer Setting (csec) : 100 Running (csec) : 0
Holdoff Timer Setting (deciseconds) : 0 Running (deciseconds) : 0
Ring State : Idle
RAPS_MEL : 7
Time since last topology change : 0 days 0h:33m:4s
-------------------------------------------------------------------------------
-
Port Port Role Port Status Signal Status
-------------------------------------------------------------------------------
-
GE1/0/1 Common Forwarding Non-failed
GE1/0/2 RPL Owner Discarding Non-failed
----End
Configuration Files
l Configuration file of SwitchA
#
sysname SwitchA

#
vlan batch 10 100 to 200
#
instance 1 vlan 10 100 to 200
#
erps ring 1
control-vlan 10
protected-instance 1
wtr-timer 6
guard-timer 100
#
port trunk allow-pass vlan 10 100 to 200
stp disable
erps ring 1
#
stp disable
erps ring 1
#
return
l Configuration file of SwitchB
#
sysname SwitchB
#
#
#
erps ring 1
control-vlan 10
wtr-timer 6
guard-timer 100
#
stp disable
erps ring 1
#
stp disable
erps ring 1
#
return
l Configuration file of SwitchC
#
sysname SwitchC
#
#
#
erps ring 1
control-vlan 10

wtr-timer 6
guard-timer 100
#
stp disable
erps ring 1
#
stp disable
erps ring 1 rpl owner
#
return
l Configuration file of SwitchD
#
sysname SwitchD
#
#
#
erps ring 1
control-vlan 10
wtr-timer 6
guard-timer 100
#
stp disable
erps ring 1
#
stp disable
erps ring 1
#
return
l Configuration file of SwitchE
#
sysname SwitchE
#
#
#
erps ring 1
control-vlan 10
wtr-timer 6
guard-timer 100
#
stp disable
erps ring 1
#

stp disable
erps ring 1
#
return

Configuration Guide - Reliability 4 RRPP Configuration
4 RRPP Configuration
About This Chapter
The Rapid Ring Protection Protocol (RRPP) features fast convergence, because the convergence
time is irrelevant to the number of the nodes on the ring.
4.1 Overview of RRPP

RRPP is a link layer protocol applied to an Ethernet ring. RRPP features fast convergence and
can prevent broadcast storms caused by data loops.
4.2 RRPP Features Supported by the S9700
This section describes the RRPP features supported by the S9700.
4.3 Configuring RRPP Functions
Through RRPP, devices on an Ethernet ring are configured to be the nodes with different roles
on RRPP rings. The nodes on an RRPP ring detect the ring status and transmit topology changes
by sending and receiving RRPP protocol packets. The master node on an RRPP ring blocks or
opens secondary ports according to the ring status. In this manner, if a fault occurs on a node or
a link on the RRPP ring, traffic can be fast switched to the backup link and data loops can be
prevented.
4.4 Configuring RRPP Multi-Instance
RRPP multi-instance is based on domains. Multiple RRPP domains can be configured on a
physical ring. In a domain, all ports, nodes, and topologies must comply with basic RRPP
principles. Therefore, a physical ring has multiple master nodes. Each master node independently
detects the completeness of the physical ring and blocks or unblocks its own secondary ports
accordingly.
4.5 Maintaining RRPP
Commands of clearing statistics helps to locate the RRPP faults on a device.
This section provides several configuration examples of RRPP.

4.1 Overview of RRPP

RRPP is a link layer protocol applied to an Ethernet ring. RRPP features fast convergence and
can prevent broadcast storms caused by data loops.
For most LANs, the ring network is adopted to provide high reliability. A fault of any single
node on the ring, however, affects the service. In general, the technology of the ring network is
the Resilient Packet Ring (RPR) or Ethernet ring. A special hardware is required to adopt RPR,
which increases the costs. Therefore, increasing number of LANs are moving towards adopting
the Ethernet ring as it is technologically advanced and the costs involved are comparatively less.
The RSTP/MSTP and Rapid Ring Protection Protocol (RRPP) are generally adopted to address
the Layer 2 network loop. RSTP/MSTP is highly adaptable; however, the convergence time is
measured in seconds.
RRPP is a link layer protocol used for Ethernet rings. RRPP can prevent broadcast storms caused
by data loops on a complete Ethernet ring. When a link on the Ethernet ring fails, nodes on the
ring can restore communication immediately through the backup link.
Compared with other Ethernet ring technologies, RRPP has the following features:
l Convergence time is not related to the number of nodes on a ring network. Thus, RRPP
can be applied to a large-scale network.
l RRPP can prevent broadcast storm caused by loops when an Ethernet ring network is
complete.
l On an Ethernet ring network, when a link is disconnected, a backup link immediately
resumes the normal communication between nodes.
NOTE
The S9700 supports the RRPP version defined by Huawei and RRPP version defined by the national
standards of China. The Huawei version supports certain proprietary protocols of Huawei. The RRPP
version defined by the national standards of China is mainly provided for users in China, and the Huawei
version is used for users in other countries.
4.2 RRPP Features Supported by the S9700

This section describes the RRPP features supported by the S9700.
Basic RRPP Functions

The concepts of RRPP are described based on Figure 4-1.

Figure 4-1 Application of crossed RRPP rings
RRPP Domain
Master SwitchB
Node Edge Transit
SwitchD Node Transit Node
RRPP Sub-Ring 1
SwitchA
RRPP Major-Ring
SwitchC Master Node

Edge Transit
Master Node Transit Node
Node
RRPP Sub-Ring 2
SwitchE
l RRPP domain
An RRPP domain consists of a group of interconnected switches with the same domain ID
and control VLAN ID. An RRPP domain consists of the elements such as the RRPP major
ring and subring, control VLAN, master node, transit node, and primary port and secondary
port.
An RRPP domain is identified by its ID, which is an integer.
l RRPP ring
Physically, an RRPP ring corresponds to an Ethernet ring. An RRPP ring is a part of its
RRPP domain. An RRPP domain consists of one RRPP ring or multiple crossed RRPP
rings.
l RRPP major ring and subring
If an RRPP domain consists of multiple crossed RRPP rings, you can configure one ring
as the major ring and other rings as subrings by setting their levels.
An RRPP domain has only one major ring.
Protocol packets of subrings are transmitted in the major ring as data packets, and protocol
packets of the major ring are transmitted only in the major ring.
l Control VLAN
A VLAN that transmits RRPP protocol packets in an RRPP domain is called a control
VLAN. A control VLAN can contain only RRPP ports.
An RRPP domain is configured with two control VLANs: the primary control VLAN and
the sub control VLAN. You need to specify only the primary control VLAN. The VLAN
whose ID is one more than the ID of the primary control VLAN becomes the sub control
VLAN.

Different from a control VLAN, a data VLAN is used to transmit data packets. The data
VLAN can contain both the RRPP ports and non-RRPP ports.
l Master node
On an Ethernet ring, each switch is called a node. Each RRPP ring must have only one
master node.
l Transit node
On an RRPP ring, all nodes except the master node are transit nodes.
A transit node monitors the status of its directly connected RRPP links. When the link status
changes, the transit node informs the master node. The master node then determines the
policy for reacting to the change of the link status.
l Edge transit node
Edge transit node is a role of a switch on a subring. On the major ring, the switch functions
as a transit node or the master node. A switch can be configured as the master node on the
major ring and the edge transit node simultaneously.
The two edge transit nodes on two crossed rings are of the same level.
l Edge node and assistant edge node (supported by the RRPP version defined by Huawei)
An edge node or assistant edge node is configured on a subring. It functions as a transit
node on the major ring.
On a subring, either of the two nodes that are on the crossed points of the major ring and
subring can be configured as the edge node. A subring must have only one edge node. Then,
the other node is the assistant edge node.
l Primary interface and secondary interface
On the master node and transit nodes, you can configure one of the two interfaces connected
to the Ethernet ring as the primary interface and the other as the secondary interface.
l Common interface and edge interface (supported by the RRPP version defined by Huawei)
On an edge node or an assistant edge node, the interface shared by the subring and major
ring is called the common interface. An interface located only on a subring is called an
edge interface.
Hello Timer and Fail Timer

When RRPP detects the link status on the Ethernet ring, the master node sends Hello packets
according to the Hello timer and determines whether the secondary interface receives the Hello
packets according to the Fail timer.
l The value of the Hello timer specifies the interval at which the master node sends Hello
packets from the primary interface.
l The Fail timer specifies the maximum interval between two Hello packets received on the
secondary interface.
RRPP Snooping
As shown in Figure 4-2, UPE A, UPE B, and NPE D comprise an RRPP ring. UPE A functions
as the master node, UPE B functions as the transit node, and VLAN 100 functions as the control
VLAN.
The RRPP ring accesses the VPLS network through sub-interfaces GE 1/0/0.100 and GE
2/0/0.100 on NPE D. Sub-interfaces allow only packets in the control VLAN of the RRPP ring
to pass through. In this manner, NPE D can transparently transmit RRPP control packets through

the sub-interfaces at both ends to ensure the structure integrity of the RRPP ring. The RRPP
protocol, however, is not run on NPE D.
NPE D transmits data packets of VLANs 10 to 20 on the RRPP ring through sub-interfaces, or
the VLANIF interface. Data packets on the RRPP ring are transparently transmitted to the upper-
layer network through the VPLS network. For details on access and transmission principle, see
S9700 Core Routing Switch Configuration Guide - VPN.
Figure 4-2 Networking diagram of RRPP and VPLS

NPEF
NPEE VPLS NPEC
GE1/0/0.100 GE2/0/0.100
NPED
GE RRPP ring
Control VLAN:100
P User VLAN:10~20
UPEA UPEB
S
data packet P : primary port

hello packet S : secondary port
The change of the RRPP ring status cannot be detected on the VPLS network because NPE nodes
cannot respond to the RRPP control packets. When the RRPP ring topology changes, each node
on the VPLS network forwards outgoing data according to the MAC address table generated
before the RRPP ring topology changes. As a result, the outgoing traffic cannot be forwarded.
After RRPP snooping is enabled on the sub-interfaces GE 1/0/0.100 and GE 2/0/0.100 of NPE
D, NPE D can respond to the RRPP control packets. Then, NPE D can synchronize the change
of the RRPP ring status and refresh the MAC address table of the VSI. This ensures that outgoing
traffic is forwarded.
RRPP Multi-Instance
l Multi-instance
In the RRPP networking, one RRPP ring contains only one master node. When the master
node is in Complete state, the blocked secondary interface rejects all the data packets. In
this manner, all the data packets are transmitted through the same path on the RRPP ring.
The link of the secondary interface on the master node is idle, which wastes bandwidth.
The RRPP multi-instance feature is implemented based on domains. In the RRPP domain,
all the interfaces, nodes, and topologies conform to the RRPP principle. In the RRPP multi-
instance networking, multiple domains can be configured on an RRPP ring.

Each domain contains one or more instances, and each instance represents a VLAN range.
The VLANs in a domain are protected VLANs in the RRPP domain. A protected VLAN
can be a data VLAN, the control VLAN on the major ring, or the control VLAN on a subring
in the RRPP domain.
In the RRPP multi-instance networking, a ring can contain multiple master nodes. Load
balancing and link backup can be implemented based on the blocking state of the secondary
interface on the master node.
As shown in Figure 4-3, Switch A, Switch B, Switch C, Switch D, and Switch E form a
ring with multiple instances. Two domains are configured on the ring. Switch C is the
master node in domain 2 and Switch D is the master node in domain 1. The primary and
secondary interfaces on each master node are marked in Figure 4-3.
Domain 1 is configured with instance 1, which represents VLANs 100 to 200. When Switch
D is in Complete state, its secondary interface is blocked. Therefore, packets of VLANs
100 to 200 are transmitted though the path Switch A -> Switch C -> Switch E.
Domain 2 is configured with Instance 2, which represents VLANs 201 to 400. When Switch
C is in Complete state, its secondary interface is blocked. Therefore, packets of VLANs
201 to 400 are transmitted though the path Switch B -> Switch D -> Switch E.
Figure 4-3 Networking diagram of RRPP multi-instance

SwitchC
S(Block) Master 2
SwitchA P
Instance1:
VLAN 100-200
SwitchE
Backbone
network
Instance2:
VLAN 201-400
SwitchB P
S(Block) Master 1
SwitchD
Block
P Primary port
S Secondary port
Instance1: VLAN 100-200
Instance2: VLAN 201-400
l Ring group (supported by the RRPP version defined by Huawei)

A ring group is configured for the subrings in the networking of crossed rings with multiple
RRPP instances.

In the networking of crossed rings with multiple RRPP instances, if multiple subrings exist,
the following may occur:
Multiple subrings share the same edge node and the same assistant edge node. In addition,
the edge node and assistant edge node are located on the same major ring. That is, the Edge-
Hello packets of the edge node are transmitted to the assistant edge node along the same
path.
Figure 4-4 Ring group in RRPP multi-instance application
SwitchE
Master
SwitchA SwitchC
Domain 1 sub ring 2

Edge
Domain 2 sub ring 2
Domain 1 Major ring 1
Domain 1 sub ring 3 Domain 2 Major ring 1
Domain 2 sub ring 3

Assistant
Master SwitchB
SwitchD
SwitchF
domain 1
domain 2
To reduce the number of Edge-Hello packets sent and received on a switch and improve
the system performance, you can add the subrings with the same edge node and same
assistant edge node to a ring group. Then configure a member subring to add Edge-Hello
packets to check the channel of protocol packets on the major ring.
There are four subrings in Figure 4-4, namely, ring 2 in domain 1, ring 3 in domain 1, ring
2 in domain 2, and ring 3 in domain 2. The subrings have the same major ring; therefore,
they can be added to a ring group. After the subrings are added to a ring group, only one
subring sends Edge-Hello packets, reducing the number of Edge-Hello packets.
l Link-Up-Delay timer
To avoid flapping on the ring caused by frequent changes of transmission paths, you can
set a Link-Up-Delay timer on the master node.
If master node receives its own Hello packet before the Failed timer expires, it transits to
the Complete state after a certain delay. This reduces link flapping on the ring.
The master node processes the Hello packets received from the secondary interface only
after the Link-Up-Delay timer expires.

4.3 Configuring RRPP Functions

Through RRPP, devices on an Ethernet ring are configured to be the nodes with different roles
on RRPP rings. The nodes on an RRPP ring detect the ring status and transmit topology changes
by sending and receiving RRPP protocol packets. The master node on an RRPP ring blocks or
opens secondary ports according to the ring status. In this manner, if a fault occurs on a node or
a link on the RRPP ring, traffic can be fast switched to the backup link and data loops can be
prevented.

If you have already enabled RRPP on a port, you cannot enable STP on it. That is, the two
protocols cannot coexist on a port.
RRPP is used for the networking of the single-ring or multiple crossed rings. When configuring
RRPP, you must configure all nodes on the RRPP ring.
NOTE
The RRPP or the STP can not coexist on a port.

RRPP contains no auto election mechanism. Therefore, to ensure the detection and protection of the ring
network through RRPP, you must correctly configure each node on the ring.
Pre-Configuration Tasks
Before configuring RRPP functions, complete the following tasks:
l Establishing the ring topology

l Configuring the link attributes of the interface
Data Preparation
To configure RRPP functions, you need the following data.
No. Data
1 ID of the RRPP domain
2 ID of the control VLAN in the RRPP domain
3 IDs of all RRPP rings in the RRPP domain
4 Values of the Hello timer and Fail timer in the RRPP domain
5 Port name of the RRPP ring
4.3.2 Creating Instances

Context
Do as follows on the S9700 that you want to add to an RRPP domain with multiple instances.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run the following commands as required.

l Run:
The mapping between an instance and VLANs is configured.

l Run:
vlan-mapping modulo modulo
The default algorithm is used to determine the mapping between instances and VLANs.
The vlan-mapping modulo command is used to map a VLAN to the instance with the ID being
(VLAN ID - 1)%modulo + 1. Assume that modulo is set to 16. The S9700 maps VLAN 1 to
instance 1, VLAN 2 to instance 2, VLAN 16 to instance 16, and so forth.
The control VLANs of the major ring and the subrings must be contained in the VLAN list.
A domain supports up to 49 instances, among which instance 0 is the default instance and does
Step 4 Run:
----End
4.3.3 Configuring Interfaces on the RRPP Ring
Context
Do as follows on the S9700 on which interfaces need to be added to the RRPP ring.
Procedure
Step 1 Run:
system-view

Step 2 Run:
RRPP rings can be configured only on Ethernet interfaces, GE interfaces, and Eth-Trunk
interfaces.
An interface cannot be configured as an RRPP interface if the Smart Link, LDT, MUX VLAN
or MSTP is configured on the interface.

The interface is configured as a trunk interface.
By default, an interface is a hybrid interface.
An RRPP interface needs to allow packets of control VLANs and data VLANs to pass through;
therefore, the RRPP interface must be configured as a trunk interface or hybrid interface.
Step 4 Run:
port trunk allow-pass vlan { { vlan-id1 [ to vlan-id2 ] } &<1-10> | all }
or run:
port hybrid tagged vlan { { vlan-id1 [ to vlan-id2 ] }&<1-10> | all }
IDs of the data VLANs whose packets are allowed to pass through the RRPP interface are
specified.
After you specify the control VLAN by running the control-vlan command in the RRPP domain
view and run the ring node-mode command, all the interfaces on the RRPP ring allow packets
of this control VLAN to pass through. Therefore, you need only to specify the data VLANs in
this step.
NOTE
If RRPP snooping is enabled on the VLANIF interface of a VLAN, the RRPP interfaces cannot be added
to the VLAN.
Step 5 Run:
stp disable
STP is disabled on the RRPP interface.
By default, STP is enabled on all interfaces of the S9700. Before creating an RRPP ring, disable
STP on the interfaces that need to be added to the RRPP ring.
----End
4.3.4 Creating the RRPP Domain

A group of connected switches that have the same domain ID and the same control VLANs
constitute an RRPP domain. An RRPP domain mainly consists of RRPP rings, control VLANs,
and master nodes.
Context
Do as follows on all switches in the RRPP domain:

Procedure
Step 1 Run:
system-view
Step 2 Run:
rrpp domain domain-id
The RRPP domain is created.
When creating the RRPP domain, you must specify the domain ID. If the domain exists, the
domain view is directly displayed.
You can create up to 64 domains on S9700.
----End
4.3.5 Creating the Control VLAN

Each RRPP ring has two control VLANs. The major control VLAN transmits mainly the protocol
packets of the major ring; the sub-control VLAN transmits mainly the protocol packets of the
sub-rings.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
The domain view is displayed.
Step 3 Run:
The control VLAN is created.
The control VLAN specified by vlan-id and the sub-control VLAN specified by vlan-id+1 must
be uncreated and not used in port trunk, mapping, or stacking mode.
An RRPP domain is configured with two control VLANs: the primary control VLAN and the
sub control VLAN. You need to specify only the primary control VLAN. The VLAN whose ID
is one more than the ID of the primary control VLAN becomes the sub control VLAN.
After configuring the control VLAN, you cannot directly modify it. You can only delete the
control VLAN by deleting the domain, and then reconfigure the control VLAN. The sub-control
VLAN is also deleted when you delete the domain.

NOTE
DHCP cannot be configured for a control VLAN.
----End
4.3.6 Specifying Protected VLANs
Context
Do as follows on all S9700s in the RRPP domain.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The RRPP domain view is displayed.

Step 3 Run:
protected-vlan reference-instance { { instance-id1 [ to instance-id2 ] } &<1-10> |
all }
A list of protected VLANs in the RRPP domain is specified.

All the VLANs whose packets need to pass through an RRPP interface, including the control
VLANs and data VLANs, must be configured as protected VLANs.
NOTE
When configure the list of protected VLANs, pay attention to the following points:
l Protected VLANs must be configured before you configure an RRPP ring.
l You can delete or change existing protected VLANs before configuring an RRPP ring. The protected
VLANs cannot be changed after the RRPP ring is configured.
l In the same physical topology, the control VLAN of a domain cannot be configured as a protected
VLAN of another domain.
l The control VLAN must be included in the protected VLANs; otherwise, the RRPP ring cannot be
configured.
l The control VLAN can be mapped to other instances before the RRPP ring is created. After the RRPP
ring is created, the mapping cannot be changed unless you delete the RRPP domain.
l When the mapping between an instance and VLANs changes, the protected VLANs of the RRPP
domain also change.
l All the VLANs allowed by an RRPP interface should be configured as protected VLANs.
----End
4.3.7 (Optional) Setting the Operation Mode of RRPP
Context
Do as follows on the master node in the RRPP domain.

Procedure
Step 1 Run:
system-view

Step 2 Run:
rrpp working-mode { hw | gb }
The operation mode of RRPP is set.

When the operation mode is set to hw, the RRPP version defined by Huawei is used. When the
operation mode is set to gb, the RRPP version defined by the national standard of China is used.
By default, the RRPP version defined by Huawei is used.
----End
4.3.8 Creating an RRPP Ring
Context
NOTE
By default, STP is enabled on all interfaces of the S9700. RRPP and STP cannot be enabled on the same
interface. Therefore, before creating an RRPP ring, you need to use the stp disable command to disable
STP on the interfaces to be added to the RRPP ring.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ring ring-id node-mode { master | transit } primary-port interface-type interface-
number secondary-port interface-type interface-number level level-value
An RRPP ring is created.

interfaces.
The level 0 indicates the major ring, and the level 1 indicates the subring.
A domain can contain only one major ring. Before creating a subring, you must create the major
ring.
In the standard RRPP version, the master node on a subring cannot function as an edge transit
node.

In the Huawei RRPP version, the master node on a subring cannot function as an edge node or
an assistant edge node.
You can create up to 64 rings on S9700.
An S-series, an F-series or X-series board supports 8 rings, and an E-series board supports 12
rings, including major rings and subrings.

l For the standard RRPP version:
Run:
ring ring-id node-mode transit secondary-port interface-type interface-number
The edge transit node of a subring is configured.
The system automatically sets the level of the ring where the edge node is located to 1.
NOTE
The secondary-port parameter is available only when the RRPP standard version is specified using the
rrpp working-mode command.
l For the Huawei RRPP version:
Run:
ring ring-id node-mode { edge | assistant-edge } common-port interface-type
interface-number edge-port interface-type interface-number
The edge node and assistant edge node of a subring are configured.
The common port of the edge node and assistant edge node must be on the major ring.
The system automatically sets the level of the ring where the edge node and assistant edge node
reside to 1.
----End
4.3.9 Enabling the RRPP Ring

The protocol packets of sub-rings are transmitted on the major ring as data packets; the protocol
packets of the major ring are transmitted on only the major ring. An RRPP ring can take effect
only when it is enabled.
Context
NOTE
l The RRPP ring can be activated only when both the RRPP ring and RRPP protocol are enabled.
l RRPP and RRPP snooping cannot be configured on the same interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ring ring-id enable
The RRPP ring is enabled.
----End
4.3.10 Enabling RRPP

To activate an RRPP ring, you must enable RRPP and the RRPP ring.
Context
NOTE
The RRPP ring can be activated only when both the RRPP ring and RRPP protocol are enabled.
Procedure
Step 1 Run:
system-view

Step 2 Run:
rrpp enable
The RRPP protocol is enabled.
----End
4.3.11 (Optional) Setting the Values of RRPP Domain Timers

Two timers, that is, the Hello timer and the Fail timer are used when master nodes are sending
and receiving RRPP protocol packets. The Hello timer is used when primary ports are sending
Hello packets. The Fail timer is used when secondary ports are receiving the Hello packets sent
by the local node.
Context
Do as follows on the master node in the RRPP domain:
Procedure
Step 1 Run:
system-view

Step 2 Run:


Step 3 Run:
timer hello-timer hello-value fail-timer fail-value
The values of RRPP domain timers are set.

The value of the Fail timer is equal to or more than three times the value of the Hello timer.
The value of the Edge-hello timer defaults to half the value of the Hello timer of the master node
on the major ring.
Set consistent Hello timers and Fail timers on all the nodes in the same RRPP ring domain;
otherwise, the edge ports of the edge nodes might be unstable.
----End
Procedure
l Run the display stp region-configuration command to check the mapping between MSTIs
and VLANs.
l Run the display rrpp brief [ domain domain-id ] command to check brief information
about an RRPP domain.
l Run the display rrpp verbose domain domain-id [ ring ring-id ] command to check
detailed information about an RRPP domain.
l Run the display rrpp statistics domain domain-id [ ring ring-id ] command to check the
statistics of packets in an RRPP domain.
----End
Example
Run the display stp region-configuration command, and you can view the mapping between
MSTIs and VLANs. The following is an example:
<Quidway> display stp region-configuration
Oper configuration
Format selector :0
Region name :00e0cd568d00
Revision level :0
Instance Vlans Mapped

0 3 to 99, 301 to 4094
1 1, 100 to 200
2 2, 201 to 300
Run the display rrpp brief command, and you can view information such as the node mode,
RRPP status, control VLAN, protected VLAN, and values of timers. The following is an
example:
<Quidway> display rrpp brief
Abbreviations for Switch Node Mode :
M - Master , T - Transit , E - Edge , A - Assistant-Edge
RRPP Protocol Status: Disable

RRPP Working Mode: HW
RRPP Linkup Delay Timer: 1 sec (0 sec default).

Number of RRPP Domains: 1
Domain Index : 1
Control VLAN : major 30 sub 31
Protected VLAN : Reference Instance 10
Hello Timer : 1 sec(default is 1 sec) Fail Timer : 6 sec(default is 6 sec)
Ring Ring Node Primary/Common Secondary/Edge Is
ID Level Mode Port Port Enabled
-------------------------------------------------------------------------------
1 0 M GigabitEthernet1/0/2 GigabitEthernet1/0/3 No
Run the display rrpp verbose command, and you can view detailed information such as the
control VLAN, protected VLAN, timers, node mode, and port status. The following is an
example:
<Quidway> display rrpp verbose domain 1 ring 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
Ring State : Complete
Is Enabled : Enable Is Active : Yes
Primary port : GigabitEthernet1/0/1 Port status: UP
Secondary port : GigabitEthernet1/0/2 Port status: BLOCKED
Run the display rrpp statistics command, and you can view the statistics of sent and received
packets. The following is an example:
<Quidway> display rrpp statistics domain 1 ring 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
Is Active : Yes
Primary port : GigabitEthernet1/0/1
Packet LINK COMMON COMPLETE EDGE MAJOR Packet
Direct HEALTH DOWN FDB FDB HELLO FAULT Total
-------------------------------------------------------------------------------
Send 2934 0 1 1 0 0 2936
Rcv 0 1 0 0 0 0 1
Secondary port: GigabitEthernet1/0/2
-------------------------------------------------------------------------------
Send 0 0 1 0 0 0 1
Rcv 2928 1 0 0 0 0 2929
4.4 Configuring RRPP Multi-Instance

RRPP multi-instance is based on domains. Multiple RRPP domains can be configured on a
physical ring. In a domain, all ports, nodes, and topologies must comply with basic RRPP
principles. Therefore, a physical ring has multiple master nodes. Each master node independently
detects the completeness of the physical ring and blocks or unblocks its own secondary ports
accordingly.


RRPP does not support auto-selection mechanism. Therefore, you need to correctly configure
each node on the ring to achieve detection and protection of the ring.
RRPP multi-instance can be applied to a more complicated networking. As shown in Figure
4-5, two RRPP sub-rings are formed after CEs are dual-homed to UPEs, and an RRPP ring is
constructed by four UPEs and one PE-AGG. The PE-AGG delivers the user data to the backbone
network.
Figure 4-5 Networking diagram of RRPP multi-instance
Backbone
network
PE-AGG
UPEC
UPED
domain 1 ring 1
IPTV VLAN101-200
domain 2 ring 1
HSI VLAN601-800 UPEB
UPEA
domain 1 ring2: domain 1 ring 3:
IPTV VLAN101-200 IPTV VLAN101-200
domain 2 ring 2: domain 2 ring 3:

HSI VLAN601-800 HSI VLAN601-800
CEA
CEC
IPTV HSI
IPTV HSI
VLAN101-200 VLAN600-800 VLAN101-200 VLAN600-800
domain 1
domain 2
CE: indicates Customer Edge UPE: indicates Underlayer Provider Edge
PE-AGG: indicates PE-Aggregation IPTV: indicates Internet Protocol Television

HSI: indicates High Speed Internet
In the preceding figure, the IPTV service and HSI service are respectively carried in two domains
that share the same RRPP ring. By applying RRPP multi-instance, you can realize balanced
traffic loads for both services, that is, the IPTV service is carried in domain 1, and the HSI service
is carried in domain 2.
NOTE
Only either RRPP or STP can be configured on one port.

RRPP has no auto-selection mechanism. Ring detection and protection can be enabled in the corresponding
protocol only when each node in the ring is correctly configured. Therefore, make sure that all the
configurations are correct.
Before configuring RRPP multi-instance, complete the following tasks:
l Establishing the ring networking

l Configuring link attributes for interfaces
Data Preparation
To configure RRPP multi-instance, you need the following data.
No. Data
1 IDs of RRPP domains
2 IDs of control VLANs in RRPP domains
3 IDs of protected VLANs in RRPP domains
4 IDs of RRPP rings in RRPP domains
5 Names of the ports in RRPP rings
6 (Optional) IDs of the ring groups
7 (Optional) Delay for link restoration
8 (Optional) Values of the Hello timer and Fail timer in RRPP domains
4.4.2 Creating Instances
Context
Do as follows on the S9700 that you want to add to an RRPP domain with multiple instances.

Procedure
Step 1 Run:
system-view

Step 2 Run:

l Run:
The mapping between an instance and VLANs is configured.

l Run:
vlan-mapping modulo modulo
The default algorithm is used to determine the mapping between instances and VLANs.
The vlan-mapping modulo command is used to map a VLAN to the instance with the ID being
(VLAN ID - 1)%modulo + 1. Assume that modulo is set to 16. The S9700 maps VLAN 1 to
instance 1, VLAN 2 to instance 2, VLAN 16 to instance 16, and so forth.
The control VLANs of the major ring and the subrings must be contained in the VLAN list.
A domain supports up to 49 instances, among which instance 0 is the default instance and does
Step 4 Run:
----End
4.4.3 Configuring Interfaces on the RRPP Ring
Context
Do as follows on the S9700 on which interfaces need to be added to the RRPP ring.
Procedure
Step 1 Run:
system-view

Step 2 Run:

interfaces.
An interface cannot be configured as an RRPP interface if the Smart Link, LDT, MUX VLAN
or MSTP is configured on the interface.

The interface is configured as a trunk interface.
By default, an interface is a hybrid interface.
An RRPP interface needs to allow packets of control VLANs and data VLANs to pass through;
therefore, the RRPP interface must be configured as a trunk interface or hybrid interface.
Step 4 Run:
port trunk allow-pass vlan { { vlan-id1 [ to vlan-id2 ] } &<1-10> | all }
or run:
port hybrid tagged vlan { { vlan-id1 [ to vlan-id2 ] }&<1-10> | all }
IDs of the data VLANs whose packets are allowed to pass through the RRPP interface are
specified.
After you specify the control VLAN by running the control-vlan command in the RRPP domain
view and run the ring node-mode command, all the interfaces on the RRPP ring allow packets
of this control VLAN to pass through. Therefore, you need only to specify the data VLANs in
this step.
NOTE
If RRPP snooping is enabled on the VLANIF interface of a VLAN, the RRPP interfaces cannot be added
to the VLAN.
Step 5 Run:
stp disable
STP is disabled on the RRPP interface.
By default, STP is enabled on all interfaces of the S9700. Before creating an RRPP ring, disable
STP on the interfaces that need to be added to the RRPP ring.
----End
4.4.4 Creating an RRPP Domain

A group of connected switches that have the same domain ID and the same control VLANs
constitute an RRPP domain. An RRPP domain mainly consists of RRPP rings, control VLANs,
and master nodes.
Context
Procedure
Step 1 Run:
system-view


Step 2 Run:
The RRPP domain is created.

When creating the RRPP domain, you must specify the domain ID. If the domain exists, the
domain view is directly displayed.
You can create up to 64 domains on S9700.
----End
4.4.5 Specifying Protected VLANs
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
protected-vlan reference-instance { { instance-id1 [ to instance-id2 ] } &<1-10> |
all }
A list of protected VLANs in the RRPP domain is specified.

All the VLANs whose packets need to pass through an RRPP interface, including the control
VLANs and data VLANs, must be configured as protected VLANs.
NOTE
When configure the list of protected VLANs, pay attention to the following points:
l Protected VLANs must be configured before you configure an RRPP ring.
l You can delete or change existing protected VLANs before configuring an RRPP ring. The protected
VLANs cannot be changed after the RRPP ring is configured.
l In the same physical topology, the control VLAN of a domain cannot be configured as a protected
VLAN of another domain.
l The control VLAN must be included in the protected VLANs; otherwise, the RRPP ring cannot be
configured.
l The control VLAN can be mapped to other instances before the RRPP ring is created. After the RRPP
ring is created, the mapping cannot be changed unless you delete the RRPP domain.
l When the mapping between an instance and VLANs changes, the protected VLANs of the RRPP
domain also change.
l All the VLANs allowed by an RRPP interface should be configured as protected VLANs.
----End

4.4.6 Creating a Control VLAN

Each RRPP ring has two control VLANs. The major control VLAN transmits mainly the protocol
packets of the major ring; the sub-control VLAN transmits mainly the protocol packets of the
sub-rings.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
The control VLAN is created.
The control VLAN specified by vlan-id and the sub-control VLAN specified by vlan-id+1 must
be uncreated and not used in port trunk, mapping, or stacking mode.
An RRPP domain is configured with two control VLANs: the primary control VLAN and the
sub control VLAN. You need to specify only the primary control VLAN. The VLAN whose ID
is one more than the ID of the primary control VLAN becomes the sub control VLAN.
After configuring the control VLAN, you cannot directly modify it. You can only delete the
control VLAN by deleting the domain, and then reconfigure the control VLAN. The sub-control
VLAN is also deleted when you delete the domain.
NOTE
DHCP cannot be configured for a control VLAN.
----End
4.4.7 Creating an RRPP Ring
Context
NOTE
By default, STP is enabled on all interfaces of the S9700. RRPP and STP cannot be enabled on the same
interface. Therefore, before creating an RRPP ring, you need to use the stp disable command to disable
STP on the interfaces to be added to the RRPP ring.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ring ring-id node-mode { master | transit } primary-port interface-type interface-
number secondary-port interface-type interface-number level level-value
An RRPP ring is created.

interfaces.
The level 0 indicates the major ring, and the level 1 indicates the subring.
A domain can contain only one major ring. Before creating a subring, you must create the major
ring.
In the standard RRPP version, the master node on a subring cannot function as an edge transit
node.
In the Huawei RRPP version, the master node on a subring cannot function as an edge node or
an assistant edge node.
You can create up to 64 rings on S9700.
An S-series, an F-series or X-series board supports 8 rings, and an E-series board supports 12
rings, including major rings and subrings.
l For the standard RRPP version:
Run:
ring ring-id node-mode transit secondary-port interface-type interface-number
The edge transit node of a subring is configured.

The system automatically sets the level of the ring where the edge node is located to 1.
NOTE
The secondary-port parameter is available only when the RRPP standard version is specified using the
rrpp working-mode command.
l For the Huawei RRPP version:
Run:
ring ring-id node-mode { edge | assistant-edge } common-port interface-type
interface-number edge-port interface-type interface-number
The edge node and assistant edge node of a subring are configured.
The common port of the edge node and assistant edge node must be on the major ring.

The system automatically sets the level of the ring where the edge node and assistant edge node
reside to 1.
----End
4.4.8 Enabling the RRPP Ring

The protocol packets of sub-rings are transmitted on the major ring as data packets; the protocol
packets of the major ring are transmitted on only the major ring. An RRPP ring can take effect
only when it is enabled.
Context
NOTE
l The RRPP ring can be activated only when both the RRPP ring and RRPP protocol are enabled.
l RRPP and RRPP snooping cannot be configured on the same interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ring ring-id enable
The RRPP ring is enabled.
----End
4.4.9 Enabling the RRPP Protocol

To activate an RRPP ring, you must enable RRPP and the RRPP ring.
Context
NOTE
The RRPP ring can be activated only when both the RRPP ring and RRPP protocol are enabled.
Procedure
Step 1 Run:
system-view

Step 2 Run:
rrpp enable
The RRPP protocol is enabled.
----End
4.4.10 (Optional) Creating a RRPP Ring Group

To reduce the Edge-Hello packets to be sent and received, you can add a group of sub-rings with
the same edge nodes or assistant edge nodes to an RRPP ring group.
Context
Do as follows on the edge node or assistant edge node:
Procedure
Step 1 Run:
system-view
Step 2 Run:
rrpp ring-group ring-group-id
An RRPP ring group is created.
The ring group can be only created on edge nodes or assistant edge nodes.
In an RRPP ring group, the nodes of all sub-rings must have the same type. That is, all of them
must be all edge nodes or assistant edge nodes.
Step 3 Run:
domain domain-id ring { ring-id1 [ to ring-id2 ] } &<1-10>
A sub-ring is added to the ring group.
The edge nodes of sub-rings in a ring group are the same device. Similarly, the assistant edge
nodes of sub-rings in a ring group are the same device.
A sub-ring can belong to only one ring group.
When creating a sub-ring or deleting a sub-ring, pay attention to the following:
l To add activated sub-rings in the ring group, configure relevant commands firstly on the
assistant edge node and then on the edge node.
l To delete activated sub-rings from the ring group, configure relevant commands firstly on
the edge node and then on the assistant edge node.
----End
4.4.11 (Optional) Configuring the Delay for Link Restoration

After the delay for link recovery is configured, the block port on the RRPP ring is not switched
immediately. Instead, the block port is switched when the delay timer expires, thus reducing the
flapping of the link status.

Context
The delay can take effect only when it is configured on a master node.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rrpp linkup-delay-timer linkup-delay-timer-value
The delay timer for the switchover of block port is set.
The value of linkup-delay-timer-value must be smaller than or equal to the value of the Fail timer
minus 2 times HELLO timer in any domain.
----End
4.4.12 (Optional) Setting the Hello Timer and Fail Timer of an RRPP
Domain
Two timers, that is, the Hello timer and the Fail timer are used when master nodes are sending
and receiving RRPP protocol packets. The Hello timer is used when primary ports are sending
Hello packets. The Fail timer is used when secondary ports are receiving the Hello packets sent
by the local node.
Context
Do as follows on the master node in the RRPP domain:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
timer hello-timer hello-value fail-timer fail-value
The values of RRPP domain timers are set.
The value of the Fail timer is equal to or more than three times the value of the Hello timer.
The value of the Edge-hello timer defaults to half the value of the Hello timer of the master node
on the major ring.

Set consistent Hello timers and Fail timers on all the nodes in the same RRPP ring domain;
otherwise, the edge ports of the edge nodes might be unstable.
----End
Procedure
l Run the display stp region-configuration command to check the mapping between MSTIs
and VLANs.
l Run the display rrpp brief [ domain domain-id ] command to check brief information
about an RRPP domain.
l Run the display rrpp verbose domain domain-id [ ring ring-id ] command to check
detailed information about an RRPP domain.
l Run the display rrpp statistics domain domain-id [ ring ring-id ] command to check the
statistics of packets in an RRPP domain.
----End
Example
Run the display stp region-configuration command, and you can view the mapping between
MSTIs and VLANs. The following is an example:
<Quidway> display stp region-configuration
Oper configuration
Format selector :0
Revision level :0

0 3 to 99, 301 to 4094
1 1, 100 to 200
2 2, 201 to 300
Run the display rrpp brief command, and you can view information such as the node mode,
RRPP status, control VLAN, protected VLAN, and values of timers. The following is an
example:
<Quidway> display rrpp brief
RRPP Protocol Status: Disable

Domain Index : 1
-------------------------------------------------------------------------------
1 0 M GigabitEthernet1/0/2 GigabitEthernet1/0/3 No
Run the display rrpp verbose command, and you can view detailed information such as the
control VLAN, protected VLAN, timers, node mode, and port status. The following is an
example:

<Quidway> display rrpp verbose domain 1 ring 1

Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
Run the display rrpp statistics command, and you can view the statistics of sent and received
packets. The following is an example:
<Quidway> display rrpp statistics domain 1 ring 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
Is Active : Yes
Primary port : GigabitEthernet1/0/1
-------------------------------------------------------------------------------
Send 2934 0 1 1 0 0 2936
Rcv 0 1 0 0 0 0 1
Secondary port: GigabitEthernet1/0/2
-------------------------------------------------------------------------------
Send 0 0 1 0 0 0 1
Rcv 2928 1 0 0 0 0 2929
4.5 Maintaining RRPP

Commands of clearing statistics helps to locate the RRPP faults on a device.
4.5.1 Clearing RRPP Running Information

You can run the reset command to reset the RRPP statistics before recollecting RRPP statistics.
Context
CAUTION
RRPP statistics cannot be restored once cleared. Therefore, confirm the action before you use
the command.
To clear the RRPP statistics, run the following reset command in the user view:

Procedure
Step 1 Run the reset rrpp statistics domain domain-id [ ring ring-id ] command in the user view to
clear the statistics of RRPP.
----End
4.5.2 Debugging RRPP

Debugging information facilitates fault location. RRPP debugging includes event debugging
and packet debugging.
Context
CAUTION
Debugging affects the performance of the system. Therefore, after debugging, run the undo
debugging all command to disable it immediately.
When there is an RRPP running fault, run the following debugging command in the user view
to view the debugging information. The debugging information helps to locate and analyze the
fault.
Procedure
Step 1 Run the debugging rrpp [ domain domain-id [ ring ring-id ] ] { error | event | packet | all }
command in the user view to debug RRPP.
----End

This section provides several configuration examples of RRPP.
4.6.1 Example for Configuring a Single RRPP Ring

As shown in Figure 4-6, SwitchA, SwitchB, and SwitchC support the RRPP function. SwitchA,
SwitchB, and SwitchC are on ring 1 of RRPP domain 1. The data of VLANs 100 to 300 needs
to be protected. Main control VLAN is VLAN 20.

Figure 4-6 Networking diagram of a single RRPP ring

SwitchB
GE2/0/2
GE2/0/1 GE2/0/1
Ring 1
GE2/0/2 GE2/0/2
SwitchC
GE2/0/1
SwitchA
Primary Port
Secondary port
1. Map instance 1 to VLANs 100 to 300.

2. Locate SwitchA, SwitchB, and SwitchC on ring 1 of RRPP domain 1.
3. Configure SwitchA as the master node on ring 1, and configure SwitchB and SwitchC as
transit nodes on ring 1.
Data Preparation
l Numbers of the RRPP interfaces

l Control VLAN ID of ring 1
Procedure
Step 1 Map instance 1 to VLANs 100 to 300.
[SwitchA-mst-region] instance 1 vlan 20 21 100 to 300
The configurations of SwitchB and SwitchC are similar to the configuration of SwitchA. The
detailed configurations are omitted here.
Step 2 Create an RRPP domain and the control VLAN.
# On the master node of ring 1, namely SwitchA, create RRPP domain 1 and configure VLAN
20 as the main control VLAN.
[SwitchA] rrpp domain 1
[SwitchA-rrpp-domain-region1] control-vlan 20
[SwitchA-rrpp-domain-region1] quit

# On the transit node of ring 1, namely SwitchB, create RRPP domain 1 and configure VLAN
[SwitchB] rrpp domain 1
[SwitchB-rrpp-domain-region1] control-vlan 20
[SwitchB-rrpp-domain-region1] quit
# On the master node of ring 1, namely SwitchC, create RRPP domain 1 and configure VLAN
[SwitchC] rrpp domain 1
[SwitchC-rrpp-domain-region1] control-vlan 20
[SwitchC-rrpp-domain-region1] quit
Step 3 Configure the interfaces to be added to the RRPP ring as trunk interfaces, allow VLANs 100 to
300 on the interfaces, and disable STP on the interfaces.
Step 4 Configure a protection VLAN and create the RRPP ring.

# Configure the protection VLAN on SwitchA and configure SwitchA as the master node of
RRPP ring 1 and specify the primary interface and secondary interface.
[SwitchA-rrpp-domain-region1] protected-vlan reference-instance 1
[SwitchA-rrpp-domain-region1] ring 1 node-mode master primary-port gigabitethernet

2/0/1 secondary-port gigabitethernet 2/0/2 level 0

[SwitchA-rrpp-domain-region1] ring 1 enable
# Configure the protection VLAN on SwitchB and configure SwitchB as the transit node of
[SwitchB-rrpp-domain-region1] protected-vlan reference-instance 1
[SwitchB-rrpp-domain-region1] ring 1 node-mode transit primary-port
gigabitethernet 2/0/1 secondary-port gigabitethernet 2/0/2 level 0
[SwitchB-rrpp-domain-region1] ring 1 enable
# Configure the protection VLAN on SwitchC and configure SwitchC as the transit node of
[SwitchC-rrpp-domain-region1] protected-vlan reference-instance 1
[SwitchC-rrpp-domain-region1] ring 1 node-mode transit primary-port
[SwitchC-rrpp-domain-region1] ring 1 enable
Step 5 Enable RRPP.
After configuring an RRPP ring, enable RRPP on each node on the ring so that the RRPP ring
can be activated.
# Enable RRPP on SwitchA.

[SwitchA] rrpp enable
# Enable RRPP on SwitchB.

[SwitchB] rrpp enable
# Enable RRPP on SwitchC.

[SwitchC] rrpp enable
After the configurations are complete and network become stable, run the following commands
to verify the configuration. Take SwitchA for example.
l Run the display rrpp brief command on SwitchA. The following information is displayed:
<SwitchA> display rrpp brief
RRPP Protocol Status: Enable

Domain Index : 1
ID Level Mode Port Port
Enabled
---------------------------------------------------------------------------
1 0 M GigabitEthernet2/0/1 GigabitEthernet2/0/2 Yes

You can find that RRPP is enabled on SwitchA. The main control VLAN of domain 1 is
VLAN 20 and the sub control VLAN is VLAN 21. SwitchA is the master node of ring 1. GE
2/0/1 is the primary interface, and GE 2/0/2 is the secondary interface.
l Run the display rrpp verbosedomain command on SwitchA. Detailed information about
RRPP domain 1 is displayed as follows:
<SwitchA> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 20 to 21 100 to 300
#
rrpp enable
#
stp region-
configuration
instance 1 vlan 20 to 21 100 to
300
active region-
configuration
#
rrpp domain 1
control-vlan 20
protected-vlan reference-instance 1
ring 1 node-mode master primary-port GigabitEthernet 2/0/1 secondary-port
GigabitEthernet 2/0/2 level 0
ring 1 enable
#
port trunk allow-pass vlan 20 to 21 100 to 300
stp disable
#
stp disable
#

#
sysname SwitchB
#
#
rrpp enable
#
stp region-
configuration


300
active region-
configuration
#
rrpp domain 1
control-vlan 20
ring 1 node-mode transit primary-port GigabitEthernet 2/0/1 secondary-port
ring 1 enable
#
stp disable
#
stp disable
#
return
l Configuration file of the SwitchC

#
sysname SwitchC
#
#
rrpp enable
#
stp region-
configuration
300
active region-
configuration
#
rrpp domain 1
control-vlan 20
ring 1 enable
#
stp disable
#
stp disable
#
return
4.6.2 Example for Configuring Crossed RRPP Rings with a Single

Instance (GB version)
As shown in Figure 4-7, Switch A, Switch B, Switch C, and Switch D support the RRPP
function. Switch A, Switch B, and Switch D are on ring 1 of domain 1, which is the major ring.

Switch A, Switch C, and Switch D are on ring 2 of domain 1, which is the subring. Switch A
and Switch D are edge transit nodes on ring 2 of domain 1.
The main control VLAN ID is 10. The RRPP rings transmit data of VLAN 2 to VLAN 9.
Figure 4-7 Networking diagram of crossed RRPP rings with a single instance (GB version)
SwitchC
GE1/0/2 GE1/0/3
subring
GE1/0/1
SwitchA
GE1/0/1 GE1/0/2
GE1/0/2
GE1/0/3 SwitchD
GE1/0/1
SwitchB GE2/0/1 major ring
GE2/0/2
1. Configure ring 1 (major ring) of domain 1 on Switch A, Switch B, and Switch C. Configure
VLAN 10 as the main control VLAN. Add the interfaces on the major ring and subring to
VLAN 2 to VLAN 9 so that the interfaces allow service packets of these VLANs to pass
through.
2. Configure ring 2 (subring) of domain 1 on Switch A, Switch B, and Switch D.
3. Configure Switch B as the master node of the major ring and configure Switch A and Switch
D as transit nodes of the major ring.
4. Configure Switch B as the master node of the major ring and configure Switch A and Switch
D as edge transit nodes of the major ring.
Data Preparation
l Numbers of the interfaces to be added to the RRPP rings
l Control VLAN IDs and data VLAN IDs
Procedure
Step 1 Configure Switch B as the master node of the major ring.
# Create data VLANs 2 to 9 on Switch B.

Configure instance 1, and map it to the VLANs allowed by the RRPP interfaces and protected
VLANs.
[SwitchB-mst-region] instance 1 vlan 2 to 11
# On Switch B, configure domain 1. Then configure VLAN 10 as the main control VLAN and
instance 1 as the protected instance of domain 1.
# Disable STP on the interfaces to be added to the RRPP rings, configure the interfaces as trunk
interfaces, and configure the interfaces to allow service packets of VLAN 2 to VLAN 9 to pass
through.
[SwitchB] interface gigabitethernet2/0/1
# Configure Switch B to use the international RRPP version.

[SwitchB] rrpp work-mode gb
# Configure the primary interface and secondary interface of the master node on the major ring.
[SwitchB-rrpp-domain-region1] ring 1 node-mode master primary-port gigabitethernet
Step 2 Configure Switch C as the master node of the subring.

# Create data VLANs 2 to 9 on Switch C.
VLANs.
[SwitchC-mst-region] instance 1 vlan 2 to 11
# On SwitchC, configure domain 1. Then configure VLAN 10 as the main control VLAN and

through.
# Configure Switch C to use the international RRPP version.

[SwitchC] rrpp work-mode gb
# Configure the primary interface and secondary interface of the master node on the RRPP
subring.
[SwitchC-rrpp-domain-region1] ring 2 node-mode master primary-port gigabitethernet
Step 3 Configure Switch A as the transit node of the major ring and the edge node of the subring.
# Create data VLANs 2 to 9 on Switch A.
VLANs.
[SwitchA-mst-region] instance 1 vlan 2 to 11
# On SwitchA, configure domain 1. Then configure VLAN 10 as the main control VLAN and
through.


# Configure Switch A to use the international RRPP version.

[SwitchA] rrpp work-mode gb
# Configure the primary interface and secondary interface of the transit node on the major ring.
[SwitchA-rrpp-domain-region1] ring 1 node-mode transit primary-port
# Configure the edge interface of the edge transit node on the sub ring.
[SwitchA-rrpp-domain-region1] ring 2 node-mode transit secondary-port
gigabitethernet 1/0/3
Step 4 Configure Switch D as the transit node of the major ring and the edge node of the subring.
# Create data VLANs 2 to 9 on Switch D.
VLANs.
[SwitchD-mst-region] instance 1 vlan 2 to 11
# On Switch D, configure domain 1. Then configure VLAN 10 as the main control VLAN and
[SwitchD] rrpp enable
[SwitchD] rrpp domain 1
[SwitchD-rrpp-domain-region1] control-vlan 10
[SwitchD-rrpp-domain-region1] protected-vlan reference-instance 1
[SwitchD-rrpp-domain-region1] quit
through.
[SwitchD] interface gigabitethernet1/0/1

# Configure Switch D to use the international RRPP version.

[SwitchD] rrpp work-mode gb
# Configure the primary interface and secondary interface of the transit node on the major ring.
[SwitchD-rrpp-domain-region1] ring 1 node-mode transit primary-port
[SwitchD-rrpp-domain-region1] ring 1 enable
# Configure the edge interface of the edge transit node on the sub ring.
[SwitchD-rrpp-domain-region1] ring 2 node-mode transit secondary-port
to verify the configuration:
l Run the display rrpp brief command on Switch B. The following information is displayed:
<SwitchB> display rrpp brief
M - Master , T - Transit , EM - Edge Master, ET - Edge Transit

RRPP Working Mode: GB
Domain Index : 1

Ring Ring Node Primary Secondary/Edge Is
------------------------------------------------------------------------------
The output information indicates that RRPP is enabled on Switch B. The main control VLAN
is VLAN 10, and the sub control VLAN is VLAN 11. Switch B is the master node on the
major ring, with GE 2/0/1 as the primary interface and GE 2/0/2 as the secondary interface.
l Run the display rrpp verbosedomain command on Switch B. The following information
is displayed:
<SwitchB> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
Secondary port: GigabitEthernet2/0/2 Port status: BLOCKED
You can find that the ring is in the Complete state, and the secondary interface of the master
node is blocked.

l Run the display rrpp brief command on Switch C. The following information is displayed:
<SwitchC> display rrpp brief

Domain Index : 1
-------------------------------------------------------------------------
The output information indicates that RRPP is enabled on Switch C. The main control VLAN
is VLAN 10, and the sub control VLAN is VLAN 11. Switch C is the master node on the
subring, with GE 1/0/1 as the primary interface and GE 1/0/2 as the secondary interface.
l Run the display rrpp verbosedomain command on Switch C. The following information
is displayed:
<SwitchC> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 2
Ring Level : 1
Node Mode : Master
You can find that the subring is in Complete state, and the secondary interface of the master
node on the subring is blocked.
l Run the display rrpp brief command on Switch A. The following information is displayed:

Domain Index : 1
-------------------------------------------------------------------------
1 0 T GigabitEthernet1/0/2 GigabitEthernet1/0/1 Yes
2 1 ET GigabitEthernet1/0/2 GigabitEthernet1/0/3 Yes
GigabitEthernet1/0/1
You can find that RRPP is enabled on Switch A. The main control VLAN is VLAN 10, and
the sub control VLAN is VLAN 11. Switch A is the transit node of the major ring, with GE
1/0/2 as the primary interface and GE 1/0/1 as the secondary interface.
Switch A is also an edge transit node on ring 2, with GE 1/0/3 as the edge interface.

l Run the display rrpp verbosedomain command on Switch A. The following information
is displayed:
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : Linkup
Secondary port: GigabitEthernet1/0/1 Port status: UP
RRPP Ring : 2
Ring Level : 1
Node Mode : Edge Transit
Ring State : Linkup
l Run the display rrpp brief command on Switch D. The following information is displayed:
<SwitchD> display rrpp brief

Domain Index : 1
-------------------------------------------------------------------------
You can find that RRPP is enabled on Switch D. The main control VLAN is VLAN 10, and
the sub control VLAN is VLAN 11. Switch D is the transit node of the major ring, with GE
1/0/2 as the primary interface and GE 1/0/1 as the secondary interface. Switch D is also the
edge transit node of the major ring, with GE 1/0/3 as the edge interface.
l Run the display rrpp verbosedomain command on Switch D. The following information
is displayed:
<SwitchD> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : Linkup
RRPP Ring : 2
Ring Level : 1

Node Mode :Edge Transit

Ring State :Linkup
Is Enabled :Enable Is Active : Yes
Primary port :GigabitEthernet1/0/2 Port status: UP
GigabitEthernet1/0/1 Port status: UP
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 1 to 11
#
rrpp enable
rrpp working-mode GB
#
stp region-
configuration
instance 1 vlan 2 to
11
active region-
configuration
#
rrpp domain 1
control-vlan 10
ring 1 node-mode transit primary-port Gigabitethernet1/0/2 secondary-port
Gigabitethernet1/0/1 level 0
ring 1 enable
ring 2 node-mode transit secondary-port Gigabitethernet1/0/3
ring 2 enable
#
port trunk allow-pass vlan 2 to 11
stp disable
#
stp disable
#
port trunk allow-pass vlan 2 to 9 11
stp disable
#
return

#
sysname SwitchB
#
vlan batch 1 to 11
#
rrpp enable
#
stp region-
configuration
11
active region-
configuration

#
rrpp domain 1
control-vlan 10
ring 1 node-mode master primary-port Gigabitethernet2/0/1 secondary-port
ring 1 enable
#
stp disable
#
stp disable
#
return
l Configuration file of the Switch C
#
sysname SwitchC
#
vlan batch 1 to 11
#
rrpp enable
#
stp region-
configuration
11
active region-
configuration
#
rrpp domain 1
control-vlan 10
ring 2 node-mode master primary-port GigabitEthernet1/0/1 secondary-port
GigabitEthernet1/0/2 level 1
ring 2 enable
#
stp disable
#
stp disable
#
return
#
sysname SwitchD
#
vlan batch 1 to 11
#
rrpp enable
#
stp region-
configuration
11
active region-
configuration

#
rrpp domain 1
control-vlan 10
ring 1 node-mode transit primary-port GigabitEthernet1/0/2 secondary-port
ring 1 enable
ring 2 node-mode transit secondary-port GigabitEthernet1/0/3
ring 2 enable
#
stp disable
#
stp disable
#
stp disable
#
return
4.6.3 Example for Configuring Crossed RRPP Rings with a Single

Instance (Huawei Version)
As shown in Figure 4-8, SwitchA, SwitchB, SwitchC, and SwitchD support the RRPP function.
SwitchA, SwitchB, and SwitchD are on ring 1 of domain 1, which is the major ring. SwitchA,
SwitchC, and SwitchD are on ring 2 of domain 1, which is the subring. SwitchA is the edge node
on ring 2 of domain 1, and SwitchD is the assistant edge node on ring 2 of domain 1.
The main control VLAN ID is 10. The RRPP rings transmit data of VLAN 2 to VLAN 9.
Figure 4-8 Networking diagram of crossed RRPP rings with a single instance (Huawei version)
SwitchC
GE1/0/2 GE1/0/3
subring
GE1/0/1
SwitchA
GE1/0/1 GE1/0/2
GE1/0/2
GE1/0/3 SwitchD
GE1/0/1
SwitchB GE2/0/1 major ring
GE2/0/2

1. Configure ring 1 (major ring) of domain 1 on SwitchA, SwitchB, and SwitchC. Configure
VLAN 10 as the main control VLAN. Add the interfaces on the major ring and subring to
VLAN 2 to VLAN 9 so that the interfaces allow service packets of these VLANs to pass
through.
2. Configure ring 2 (subring) of domain 1on SwitchA, SwitchB, and SwitchD.
3. Configure SwitchB as the master node of the major ring and configure SwitchA and
SwitchD as transit nodes of the major ring.
4. Configure SwitchC as the master node of the subring; configure SwitchA as the edge node
of the subring; configure SwitchD as the assistant edge node of the subring.
Data Preparation
l Numbers of the interfaces to be added to the RRPP rings
l Control VLAN IDs and data VLAN IDs
Procedure
Step 1 Configure SwitchB as the master node of the major ring.
# Create data VLANs 2 to 9 on SwitchB.
VLANs.
# On SwitchB, configure domain 1. Then configure VLAN 10 as the main control VLAN and
through.

# Configure the primary interface and secondary interface of the master node on the RRPP major
ring.
[SwitchB-rrpp-domain-region1] ring 1 node-mode master primary-port gigabitethernet
Step 2 Configure SwitchC as the master node of the subring.

# Create data VLANs 2 to 9 on SwitchC.
VLANs.
# On SwitchC, configure domain 1. Then configure VLAN 10 as the main control VLAN and
through.
# Configure the primary interface and secondary interface of the master node on the RRPP
subring.
[SwitchC-rrpp-domain-region1] ring 2 node-mode master primary-port gigabitethernet
Step 3 Configure SwitchA as the transit node of the major ring and the edge transit node of the subring.
# Create data VLANs 2 to 9 on SwitchA.
VLANs.


# On SwitchA, configure domain 1. Then configure VLAN 10 as the main control VLAN and
through.
# Configure the primary interface and secondary interface of the transit node on the RRPP major
ring.
[SwitchA-rrpp-domain-region1] ring 1 node-mode transit primary-port
# Configure the common interface and edge interface of the edge transit node on the subring.
[SwitchA-rrpp-domain-region1] ring 2 node-mode edge common-port gigabitethernet
1/0/2 edge-port gigabitethernet 1/0/3
Step 4 Configure SwitchD as the transit node of the major ring and the assistant edge node of the subring.
# Create data VLANs 2 to 9 on SwitchD.

VLANs.
# On SwitchD, configure domain 1. Then configure VLAN 10 as the main control VLAN and


through.
# Configure the primary interface and secondary interface of the transit node on the RRPP major
ring.
# Configure the common interface and edge interface of the assistant edge node on the RRPP
subring.
[SwitchD-rrpp-domain-region1] ring 2 node-mode assistant-edge common-port
gigabitethernet 1/0/2 edge-port gigabitethernet 1/0/3
to verify the configuration:
l Run the display rrpp brief command on SwitchB. The following information is displayed:
<SwitchB> display rrpp brief

Domain Index : 1
------------------------------------------------------------------------------

You can find that RRPP is enabled on SwitchB. The main control VLAN is VLAN 10, and
the sub control VLAN is VLAN 11.SwitchB is the master node of the major ring, with GE
l Run the display rrpp verbose domain command on SwitchB. The following information
is displayed:
<SwitchB> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
You can find that the ring is in Complete state, and the secondary interface of the master
node is blocked.
l Run the display rrpp brief command on SwitchC. The following information is displayed:
<SwitchC> display rrpp brief

Domain Index : 1
-------------------------------------------------------------------------
The output information indicates that RRPP is enabled on SwitchC. The main control VLAN
is VLAN 10, and the sub control VLAN is VLAN 11. SwitchC is the master node on the
subring, with GE 1/0/1 as the primary interface and GE 1/0/2 as the secondary interface.
l Run the display rrpp verbose domain command on SwitchC. The following information
is displayed:
<SwitchC> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 2
Ring Level : 1
Node Mode : Master
You can find that the subring is in Complete state, and the secondary interface of the master
node on the subring is blocked.
l Run the display rrpp brief command on SwitchA. The following information is displayed:


Domain Index : 1
-------------------------------------------------------------------------
2 1 E GigabitEthernet1/0/2 GigabitEthernet1/0/3 Yes
You can find that RRPP is enabled on SwitchA. The main control VLAN is VLAN 10, and
the sub control VLAN is VLAN 11. SwitchA is the transit node of the major ring, with GE
SwitchA is also an edge of the subring, with GE 1/0/2 as the common interface and GE 1/0/3
as the edge interface.
l Run the display rrpp verbose domain command on SwitchA. The following information
is displayed:
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : Linkup
RRPP Ring : 2
Ring Level : 1
Node Mode : Edge
Ring State : Linkup
Common port : GigabitEthernet1/0/2 Port status: UP
Edge port : GigabitEthernet1/0/3 Port status: UP
l Run the display rrpp brief command on SwitchD. The following information is displayed:
<SwitchD> display rrpp brief

Domain Index : 1
-------------------------------------------------------------------------
2 1 A GigabitEthernet1/0/2 GigabitEthernet1/0/3 Yes

You can find that RRPP is enabled on SwitchD. The main control VLAN is VLAN 10, and
the sub control VLAN is VLAN 11. SwitchD is the transit node of the major ring, with GE
1/0/2 as the primary interface and GE 1/0/1 as the secondary interface. SwitchD is also the
assistant edge node of the major ring, with GE 1/0/2 as the common interface and GE 1/0/3
as the edge interface.
l Run the display rrpp verbose domain command on SwitchD. The following information
is displayed:
<SwitchD> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : Linkup
RRPP Ring : 2
Ring Level : 1
Node Mode : Assistant-edge
Ring State : Linkup
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 2 to 11
#
rrpp enable
#
stp region-
configuration
11
active region-
configuration
#
rrpp domain 1
control-vlan 10
ring 1 node-mode transit primary-port Gigabitethernet1/0/2 secondary-port
ring 1 enable
ring 2 node-mode edge common-port Gigabitethernet1/0/2 edge-port
Gigabitethernet1/0/3
ring 2 enable
#
stp disable
#


stp disable
#
stp disable
#
return
#
sysname SwitchB
#
vlan batch 2 to 11
#
rrpp enable
#
stp region-
configuration
11
active region-
configuration
#
rrpp domain 1
control-vlan 10
ring 1 node-mode master primary-port Gigabitethernet2/0/1 secondary-port
ring 1 enable
#
stp disable
#
stp disable
#
return
#
sysname SwitchC
#
vlan batch 2 to 11
#
rrpp enable
#
stp region-
configuration
11
active region-
configuration
#
rrpp domain 1
control-vlan 10
ring 2 enable
#
stp disable

#
stp disable
#
return

#
sysname SwitchD
#
vlan batch 2 to 11
#
rrpp enable
#
stp region-
configuration
11
active region-
configuration
#
rrpp domain 1
control-vlan 10
ring 1 enable
ring 2 node-mode assistant-edge common-port GigabitEthernet1/0/2 edge-port
ring 2 enable
#
stp disable
#
stp disable
#
stp disable
#
return
4.6.4 Example for Configuring Tangent RRPP Rings
As shown in Figure 4-9, SwitchA, SwitchB, SwitchC, SwitchD, and SwitchE support the RRPP
function. SwitchA, SwitchB, and SwitchC are on ring 2 of domain 2, configure VLAN 20 as the
main control VLAN. SwitchC, SwitchD, and SwitchE are on ring 1 of domain 1, configure
VLAN 10 as the main control VLAN. SwitchC is the tangent point of the two rings.

Figure 4-9 Networking diagram of tangent RRPP rings
Domain 2 Domain 1
SwtichB GE2/0/2 GE1/0/1 SwtichE
GE2/0/1 GE2/0/1 GE1/0/2 GE1/0/2
Ring 2 SwtichC Ring 1

GE2/0/2 GE1/0/1
GE2/0/2 GE1/0/1
SwtichA GE2/0/1 GE1/0/2 SwtichD
1. Create an instance and add the control VLANs added to the list of protected VLANs.
2. Configure ring 2 of domain 2 on SwitchA, SwitchB, and SwitchC.
3. Configure ring 1 of domain 1 on SwitchC, SwitchD, and SwitchE.
4. Configure SwitchA as the master node on ring 2, and configure SwitchB and SwitchC as
5. Configure SwitchE as the master node on ring 1, and configure SwitchC and SwitchD as
Data Preparation
To complete the configuration, you need the following data.
l Control VLAN IDs of ring 1 and ring 2
Procedure
Step 1 Create an instance and add the control VLANs added to the list of protected VLANs.


[Quidway] sysname SwitchE
[SwitchE] stp region-configuration
[SwitchE-mst-region] instance 1 vlan 10 to 11
[SwitchE-mst-region] active region-configuration
[SwitchE-mst-region] quit
Step 2 Create RRPP domains and configure the control VLANs and protected VLANs of the domains.
# Configure domain 1 on SwitchE, which is the master node of ring 1. Configure VLAN 10 as
the main control VLAN of domain 1, and configure the list of protected VLANs mapping
instance 1.
[SwitchE] rrpp domain 1
[SwitchE-rrpp-domain-region1] control-vlan 10
[SwitchE-rrpp-domain-region1] protected-vlan reference-instance 1
[SwitchE-rrpp-domain-region1] quit
# Configure domain 1 on SwitchC, which is the transit node of ring 1. Configure VLAN 10 as
instance 1.
# Configure domain 1 on SwitchD, which is the transit node of ring 1. Configure VLAN 10 as
the main control VLAN of domain 1, and configure the list of protected VLANs of instance 1.
# Configure domain 2 on SwitchE, which is the master node of ring 2. Configure VLAN 20 as
instance 1.


# Configure domain 2 on SwitchB, which is the transit node of ring 2. Configure VLAN 20 as
# Configure domain 2 on SwitchC, which is the transit node of ring 2. Configure VLAN 20 as
Step 3 Set the timers of the RRPP domains

NOTE
You can set two timers for the tangent point because the two tangent rings reside in different domains.
# Set the Hold timer and Fail timer for SwitchE, the master node on ring 1.
[SwitchE-rrpp-domain-region1] timer hello-timer 2 fail-timer 7
# Set the Hold timer and Fail timer for SwitchD, the transit node on ring 1.
[SwitchD-rrpp-domain-region1] timer hello-timer 2 fail-timer 7
# Set the Hold timer and Fail timer for SwitchC, the transit node on ring 1.
[SwitchC-rrpp-domain-region1] timer hello-timer 2 fail-timer 7
# Set the Hold timer and Fail timer for SwitchA, the master node on ring 2.
[SwitchA-rrpp-domain-region2] timer hello-timer 3 fail-timer 10
# Set the Hold timer and Fail timer for SwitchB, the transit node on ring 2.
[SwitchB-rrpp-domain-region2] timer hello-timer 3 fail-timer 10
# Set the Hold timer and Fail timer for SwitchC, the transit node on ring 2.
[SwitchC-rrpp-domain-region2] timer hello-timer 3 fail-timer 10
Step 4 Disable STP on the interfaces to be added to the RRPP rings.

# Disable STP on the interfaces to be added to the RRPP ring on SwitchA.
# Disable STP on the interfaces to be added to the RRPP ring on SwitchB.


# Disable STP on the interfaces to be added to the RRPP ring on SwitchC.

# Disable STP on the interfaces to be added to the RRPP ring on SwitchE.

# Disable STP on the interfaces to be added to the RRPP ring on SwitchD.

Step 5 Create RRPP rings.
Configure nodes on ring 2. The configuration procedure is as follows:
# Configure SwitchA as the master node of ring 2 and specify the primary and secondary
interfaces.
[SwitchA-rrpp-domain-region2] ring 2 node-mode master primary-port gigabitethernet
# Configure SwitchB as a transit node of ring 2 (major ring) and specify the primary and
secondary interfaces.
[SwitchB-rrpp-domain-region2] ring 2 node-mode transit primary-port
# Configure SwitchC as a transit node of RRPP ring 2 and specify the primary and secondary
interfaces.

Configure nodes on ring 1. The configuration procedure is as follows:

# Configure SwitchE as the master node of ring 1 (major ring) and specify the primary and
secondary interfaces.
[SwitchE-rrpp-domain-region1] ring 1 node-mode master primary-port gigabitethernet
[SwitchE-rrpp-domain-region1] ring 1 enable
[SwitchE-rrpp-domain-region1] quit
# Configure SwitchC as a transit node of ring 1 and specify the primary and secondary interfaces.
# Configure SwitchD as a transit node of ring 1 and specify the primary and secondary interfaces.
Step 6 Enable RRPP.

After configuring an RRPP ring, enable RRPP on each node on the ring. Then the RRPP ring
can be activated.
# Enable RRPP on SwitchA.
# Enable RRPP on SwitchB.

# Enable RRPP on SwitchC.

# Enable RRPP on SwitchE.

[SwitchE] rrpp enable
# Enable RRPP on SwitchD.


to verify the configuration. Take the tangent point SwitchC for example.
l Run the display rrpp brief command on SwitchC. The following information is displayed:
[SwitchC] display rrpp brief

Domain Index : 1


---------------------------------------------------------------------------
Domain Index : 2
---------------------------------------------------------------------------
You can find that RRPP is enabled on SwitchC. The main control VLAN of domain 1 is
VLAN 10 and the sub control VLAN is VLAN 11. SwitchC is the master node of ring 1,
with GE 1/0/1 as the primary interface and GE 1/0/2 as the secondary interface.
The main control VLAN of domain 2 is VLAN 20, and the sub control VLAN is VLAN 21.
SwitchC is a transit node on ring 2, with GE 2/0/1 as the primary interface and GE 2/0/1 as
the secondary interface.
l Run the display rrpp verbosedomain command on SwitchC to view the domain
information.
# View detailed information about domain 1.
[SwitchC] display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : Linkup
# View detailed information about domain 2.

[SwitchC] display rrpp verbose domain 2
Domain Index : 2
RRPP Ring : 2
Ring Level : 0
Node Mode : Transit
Ring State : Linkup
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 20 to 21

#
rrpp enable
#
stp region-
configuration
21
#
rrpp domain 2
control-vlan 20
timer hello-timer 3 fail-timer 10
ring 2 enable
#
port hybrid tagged vlan 20 to 21
stp disable
#
stp disable
#
#
sysname SwitchB
#
vlan batch 20 to 21
#
rrpp enable
#
stp region-
configuration
21
#
rrpp domain 2
control-vlan 20
ring 2 enable
#
stp disable
#
stp disable
#
return
#
#
sysname SwitchC
#
#
rrpp enable
#
stp region-
configuration
instance 1 vlan 10 to 11

21
#
rrpp domain 1
control-vlan 10
ring 1 enable
#
rrpp domain 2
control-vlan 20
ring 2 enable
#
stp disable
#
stp disable
#
stp disable
#
stp disable
#
return

#
sysname SwitchD
#
vlan batch 10 to 11
#
rrpp enable
#
stp region-
configuration
11
#
rrpp domain 1
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return

l Configuration file of SwitchE

#
sysname SwitchE
#
vlan batch 10 to 11
#
rrpp enable
#
stp region-
configuration
11
#
rrpp domain 1
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return
4.6.5 Example for Configuring a Single RRPP Ring with Multiple

Instances
As shown in Figure 4-10, UPE A, UPE B, UPE C, and PE-AGG form a multi-instance RRPP
ring.
Two rings are involved in the networking, ring 1 in domain 1 and ring 1 in domain 2.
VLANs 100 to 300 are configured on CE. Domain 1 and domain 2 share the traffic of packets
from VLANs 100 to 300. Packets from VLANs 100 to 200 are transmitted through domain 1,
and packets from VLANs 201 to 300 are transmitted through domain 2.
Table 4-1 shows the mapping between protected VLANs and instances in domain 1 and domain
2.
Table 4-1 Mapping between protected VLANs and instances

Domai Control VLAN Instance ID of Data VLAN ID Instance ID of
n ID ID Control VLAN Data VLAN
Domain VLAN 5, VLAN 6 Instance 1 VLAN 100-200 Instance 1

1
Domain VLAN 10, VLAN Instance 2 VLAN 201-300 Instance 2

2 11

Table 4-2 shows the master node of each ring, and the primary port and secondary port on the
master node.
Table 4-2 Master nodes, and primary and secondary ports on the master nodes
Ring ID Master Node Primary Port Secondary Port
Ring 1 in domain 1 PE-AGG GE 1/0/0 GE 2/0/0
Figure 4-10 Networking diagram of single RRPP ring with multiple instances
UPE B
GE1/0/0 GE2/0/0
CE 1
VLAN 100-300
PE-AGG
GE2/0/0 GE1/0/0
Ring 1 Master 1 Backbone
UPEA network
Master 2
GE1/0/0 GE2/0/0
CE 2
VLAN 100-300
Domain 1 ring 1
GE2/0/0 GE1/0/0
Domain 2 ring 1
UPEC
1. Map instance 1 to VLANs 100 to 200. Map instance 2 to VLANs 201 to 300.
2. Add UPE A, UPE B, UPE C, and PE-AGG to ring 1 in domain 1.
3. Add UPE A, UPE B, UPE C, and PE-AGG to ring 1 in domain 2.
4. Configure protected VLANs in domain 1 and domain 2.
5. Configure control VLANs in domain 1 and domain 2.
6. Configure PE-AGG as the master node on ring 1 in domain 1 and configure UPE A, UPE
B, and UPE C as transit nodes.
7. Configure PE-AGG as the master node on ring 1 in domain 2 and configure UPE A, UPE
B, and UPE C as transit nodes.

Data Preparation
l Instance IDs
l Range of the protected VLANs
l IDs of the control VLANs
Procedure
Step 1 Create instances.
l Configure UPE A.
# Create data VLANs 100 to 300 on UPE A.
[Quidway] sysname UPEA
[UPEA] vlan batch 100 to 300
# Create instance 1 and map it to control VLANs VLAN 5 VLAN 6 and data VLANs 100 to
200 in domain 1.
[UPEA] stp region-configuration
[UPEA-mst-region] instance 1 vlan 5 6 100 to 200
# Create instance 2 and map it to control VLANs VLAN 10 and VLAN 11 and data VLANs 201
to 300 in domain 2.
# Activate the configuration.

[UPEA-mst-region] active region-configuration
[UPEA-mst-region] quit
l # Configure UPE B.
# Create data VLANs 100 to 300 on UPE B.
[Quidway] sysname UPEB
[UPEB] vlan batch 100 to 300
to 200 in domain 1.
[UPEB] stp region-configuration
[UPEB-mst-region] instance 1 vlan 5 6 100 to 200
to 300 in domain 2.

[UPEB-mst-region] active region-configuration
[UPEB-mst-region] quit
l Configure UPE C.
# Create data VLANs 100 to 300 on UPE C.

[Quidway] sysname UPEC
[UPEC] vlan batch 100 to 300
to 200 in domain 1.
[UPEC] stp region-configuration
[UPEC-mst-region] instance 1 vlan 5 6 100 to 200
to 300 in domain 2.

[UPEC-mst-region] active region-configuration
[UPEC-mst-region] quit
l Configure PE-AGG.
# Create data VLANs 100 to 300 on PE-AGG.
[Quidway] sysname PE-AGG
[PE-AGG] vlan batch 100 to 300
to 200 in domain 1.
[PE-AGG] stp region-configuration
[PE-AGG-mst-region] instance 1 vlan 5 6 100 to 200
to 300 in domain 2.

[PE-AGG-mst-region] active region-configuration
[PE-AGG-mst-region] quit
l Verify the configuration.

Run the display stp region-configuration command on the devices to view the mapping
between instances and VLANs. The displayed information on UPE A is as follows:
[UPEA] display stp region-configuration
Oper configuration
Format selector :0
Revision level :0

0 1 to 4, 7 to 9, 12 to 99, 301 to 4094
1 5 to 6, 100 to 200
2 10 to 11, 201 to 300
Step 2 Configure RRPP interfaces.

l Configure UPE A.
# Disable STP on the interfaces that need to be added to the RRPP ring on UPE A. Configure
the RRPP interfaces to allow packets of VLANs 100 to 300 to pass through.
[UPEA] interface gigabitethernet 1/0/0
[UPEA-GigabitEthernet1/0/0] port link-type trunk

[UPEA-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300

[UPEA-GigabitEthernet1/0/0] stp disable
[UPEA-GigabitEthernet1/0/0] quit
# Disable STP on the interfaces that need to be added to the RRPP ring on UPE B. Configure
[UPEB] interface gigabitethernet 1/0/0
[UPEB-GigabitEthernet1/0/0] port link-type trunk
[UPEB-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300
[UPEB-GigabitEthernet1/0/0] stp disable
[UPEB-GigabitEthernet1/0/0] quit
l Configure UPE C.
# Disable STP on the interfaces that need to be added to the RRPP ring on UPE C. Configure
[UPEC] interface gigabitethernet 1/0/0
[UPEC-GigabitEthernet1/0/0] port link-type trunk
[UPEC-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300
[UPEC-GigabitEthernet1/0/0] stp disable
[UPEC-GigabitEthernet1/0/0] quit
l Configure PE-AGG.
# Disable STP of the interfaces that need to be added to the RRPP ring on PE-AGG. Configure
[PE-AGG] interface gigabitethernet 1/0/0
[PE-AGG-GigabitEthernet1/0/0] port link-type trunk
[PE-AGG-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300
[PE-AGG-GigabitEthernet1/0/0] stp disable
[PE-AGG-GigabitEthernet1/0/0] quit
Step 3 Create RRPP domains and configure the protected VLANs and control VLANs.
l Configure UPE A.
# Configure the VLANs mapping instance 1 as the protected VLANs in domain 1. Configure
VLAN 5 as the control VLAN.
[UPEA] rrpp domain 1
[UPEA-rrpp-domain-region1] protected-vlan reference-instance 1
[UPEA-rrpp-domain-region1] control-vlan 5
[UPEA-rrpp-domain-region1] quit

[UPEB] rrpp domain 1
[UPEB-rrpp-domain-region1] protected-vlan reference-instance 1
[UPEB-rrpp-domain-region1] control-vlan 5
[UPEB-rrpp-domain-region1] quit
l Configure UPE C.
[UPEC] rrpp domain 1
[UPEC-rrpp-domain-region1] protected-vlan reference-instance 1
[UPEC-rrpp-domain-region1] control-vlan 5
[UPEC-rrpp-domain-region1] quit
l Configure PE-AGG.
[PE-AGG] rrpp domain 1
[PE-AGG-rrpp-domain-region1] protected-vlan reference-instance 1
[PE-AGG-rrpp-domain-region1] control-vlan 5
[PE-AGG-rrpp-domain-region1] quit

l Configure UPE A.
# Configure UPE A as a transit node of ring 1 in domain 1 and specify primary and secondary
ports on UPE A.


[UPEA-rrpp-domain-region1] ring 1 node-mode transit primary-port gigabitethernet
[UPEA-rrpp-domain-region1] ring 1 enable
ports on UPE A.
# Configure UPE B as a transit node of ring 1 in domain 1 and specify primary and secondary
ports on UPE B.
[UPEB-rrpp-domain-region1] ring 1 node-mode transit primary-port gigabitethernet
[UPEB-rrpp-domain-region1] ring 1 enable
ports on UPE B.
l Configure UPE C.
# Configure UPE C as a transit node of ring 1 in domain 1 and specify primary and secondary
ports on UPE C.
[UPEC-rrpp-domain-region1] ring 1 node-mode transit primary-port gigabitethernet
[UPEC-rrpp-domain-region1] ring 1 enable
ports on UPE C.
l Configure PE-AGG.
# Configure PE-AGG as the master node of ring 1 in domain 1. Configure GE 1/0/0 as the
primary port and GE 2/0/0 as the secondary port.
[PE-AGG-rrpp-domain-region1] ring 1 node-mode master primary-port gigabitethernet
[PE-AGG-rrpp-domain-region1] ring 1 enable


Step 5 Enable the RRPP protocol.

After configuring an RRPP ring, you need to enable RRPP on each node on the ring to activate
the RRPP ring. The configuration procedure is as follows:
l Configure UPE A.
# Enable the RRPP protocol.
[UPEA] rrpp enable
[UPEB] rrpp enable
l Configure UPE C.
[UPEC] rrpp enable
l Configure PE-AGG.
[PE-AGG] rrpp enable

After the preceding configurations are complete and the network topology becomes stable,
perform the following operations to verify the configuration. Here, UPE A and PE-AGG are
used as examples.
l Run the display rrpp brief command on UPE A. The following information is displayed:
[UPEA] display rrpp brief

Domain Index : 1
----------------------------------------------------------------------------
Domain Index : 2
----------------------------------------------------------------------------

You can see that the RRPP protocol is enabled on UPE A.

In domain 1, VLAN 5 is the control VLAN; VLANs mapping instance 1 are the protected
VLANs; UPE A is a transit node on ring 1. The primary port is GE 1/0/0, and the secondary port
is GE 2/0/0.
VLANs; UPE A is a transit node on ring 1. The primary port is GE 1/0/0, and the secondary port
is GE 2/0/0.
l Run the display rrpp brief command on PE-AGG. The following information is displayed:
[PE-AGG] display rrpp brief

Domain Index : 1
---------------------------------------------------------------------------
Domain Index : 2
Protected VLAN: Reference Instance 2
---------------------------------------------------------------------------
The preceding information shows that the RRPP protocol is enabled on PE-AGG.
VLANs; PE-AGG is the master node on ring 1. The primary port is GE 1/0/0, and the secondary
port is GE 2/0/0.
port is GE 1/0/0.
l Run the display rrpp verbose domain command on UPE A. You can obtain the following
results:
# View detailed information about UPE A in domain 1.
[UPEA] display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : LinkUp

The preceding information shows that VLAN 5 is the control VLAN in domain 1 and VLANs
mapping instance 1 are the protected VLANs. UPE A is a transit node in domain 1 and is in
LinkUp state.
# View detailed information about UPE A in domain 2.

[UPEA] display rrpp verbose domain 2
Domain Index : 2
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : LinkUp
The preceding information shows that VLAN 10 is the control VLAN in domain 2, and VLANs
mapping instance 2 are the protected VLANs. UPE A is a transit node in domain 2 and is in
LinkUp state.
l Run the display rrpp verbose domain command on PE-AGG. You can obtain the following
results:
# View detailed information about PE-AGG in domain 1.

[PE-AGG] display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
mapping instance 1 are the protected VLANs.
PE-AGG is the master node in domain 1 and is in Complete state.
The primary port is GE 1/0/0, and the secondary port is GE 2/0/0.

Domain Index : 2
RRPP Ring : 1
Ring Level : 0
Node Mode : Master

----End
Configuration Files
l Configuration file of UPE A
#
sysname UPEA
#
vlan batch 5 to 6 10 to 11 100 to 300
#
rrpp enable
#
instance 1 vlan 5 to 6 100 to 200
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
port trunk allow-pass vlan 5 to 6 10 to 11 100 to 300
stp disable
#
stp disable
#
return
l Configuration file of UPE B

#
sysname UPEB
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5

ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return
l Configuration file of UPE C
#
sysname UPEC
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
Return
l Configuration file of PE-AGG
#
sysname PE-AGG
#
#
rrpp enable
#

#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return
4.6.6 Example for Configuring Crossed RRPP Rings with Multiple

Instances (GB version)
As shown in Figure 4-11, UPE A, UPE B, UPE C, UPE D, and PE-AGG form two multi-instance
major rings: ring 1 in domain 1 and ring 1 in domain 2.
CE1, UPE B, and UPE C form two subrings: ring 2 in domain 1 and ring 2 in domain 2. CE1 is
connected to the major rings through GE 3/0/0 of UPE B and GE 3/0/0 of UPE C. UPE B and
UPE C are edge transit nodes.
connected to the major rings through GE 3/0/1 of UPE B and GE 3/0/1 of UPE C. UPE B and
UPE C are edge transit nodes.
VLANs 100 to 300 are configured on the CE devices. Domain 1 and domain 2 share the traffic
of packets from VLANs 100 to 300. Packets from VLANs 100 to 200 are transmitted through
domain 1, and packets from VLANs 201 to 300 are transmitted through domain 2.
2.
Domain Control VLAN Instance ID of Data VLAN Instance ID of

ID Control Data VLAN
VLAN
Domain 1 VLAN 5, VLAN Instance 1 VLAN 100-200 Instance 1

6

Domain Control VLAN Instance ID of Data VLAN Instance ID of

ID Control Data VLAN
VLAN
Domain 2 VLAN 10, Instance 2 VLAN 201-300 Instance 2

VLAN 11
Table 4-4 shows the master node of each ring, and the primary port and secondary port on each
master node.
Ring ID Master Node Primary Port Secondary Port Ring Type
Ring 1 in PE-AGG GE 1/0/0 GE 2/0/0 Major ring

domain 1
Ring 1 in PE-AGG GE 2/0/0 GE 1/0/0 Major ring

domain 2
Ring 2 in CE1 GE 1/0/0 GE 2/0/0 Subring

domain 1

domain 2

domain 1

domain 2
Table 4-5 shows the edge transit nodes and edge nodes on the subrings.
Table 4-5 Edge transit nodes and edge nodes on the subrings
Ring ID Edge-Transit Edge Port Edge-Transit Edge Port

Node Node
Ring 2 in UPE B GE 3/0/0 UPE C GE 3/0/0

domain 1
Ring 3 in UPEB GE 3/0/1 UPEC GE 3/0/1

domain 1

domain 2

domain 2

To prevent topology flapping, you need to set the Link-Up timer on the master nodes.
Figure 4-11 Networking diagram of crossed RRPP rings with multiple instances
Backbone
network
GE1/0/0 GE2/0/0
PE-
AGG
Master 1
GE2/0/0 Master 2 GE1/0/0
UPEA Domain 1 ring 1
UPED
GE1/0/0
GE2/0/0
Domain 2 ring 1
Edge Edge
GE2/0/0 Transit Transit GE1/0/0
UPEB GE1/0/0 GE2/0/0 UPEC
GE3/0/0 GE3/0/1
GE3/0/1 GE3/0/0
Domain 2 ring 2 Domain 2 ring 3

GE1/0/0 GE2/0/0
Master 1 Master 1
Master 2 Master 2
GE2/0/0 Domain 1 ring 2 Domain 1 ring 3 GE1/0/0
CE 1 CE 2
VLAN 100-300 VLAN 100-300
Domain 1
Domain 2
2. Add UPE A, UPE B, UPE C, UPE D, and PE-AGG to ring 1 in domain 1 and ring 1 in
domain 2.
domain 2.
domain 2.


7. Configure PE-AGG as the master node and configure UPE A, UPE B, UPE C and UPE D
as transit nodes on ring 1 in domain 1 and ring 1 in domain 2.
8. Configure CE1 as the master node and configure UPE B and UPE C as transit nodes on
ring 2 in domain 1 and ring 2 in domain 2.
10. Set the link-Up-Delay timer.
Data Preparation
l Instance IDs
l Link-Up timer
Procedure
l Configure CE1.
# Create data VLANs 100 to 300 on CE1.
[Quidway] sysname CE1
[CE1] vlan batch 100 to 300
to 200 in domain 1.
[CE1] stp region-configuration
[CE1-mst-region] instance 1 vlan 5 6 100 to 200
# Create instance 2 and map it control VLANs VLAN 10 and VLAN 11 and data VLANs 201
to 300 in domain 2.

[CE1-mst-region] active region-configuration
[CE1-mst-region] quit
l Configure CE2.
to 200 in domain 1.


to 300 in domain 2.

l Configure UPE A.
to 200 in domain 1.
to 300 in domain 2.

[Quidway] sysname UPEB[UPEB] vlan batch 100 to 300
to 200 in domain 1.
to 300 in domain 2.

l Configure UPE C.
to 200 in domain 1.


to 300 in domain 2.

l Configure UPE D.
# Create data VLANs 100 to 300 on UPE D.
[Quidway] sysname UPED
[UPED] vlan batch 100 to 300
to 200 in domain 1.
[UPED] stp region-configuration
[UPED-mst-region] instance 1 vlan 5 6 100 to 200
to 300 in domain 2.

[UPED-mst-region] active region-configuration
[UPED-mst-region] quit
l Configure PE-AGG.
to 200 in domain 1.
to 300 in domain 2.


Oper configuration
Format selector :0


Revision level :0

0 1 to 4, 7 to 9, 12 to 99, 301 to 4094
1 5 to 6, 100 to 200
2 10 to 11, 201 to 300

l Configure CE1.
# Disable STP on the interfaces that need to be added to the RRPP ring on CE1. Configure the
RRPP interfaces to allow packets of VLANs 100 to 300 to pass through.
[CE1] interface gigabitethernet 1/0/0
[CE1-GigabitEthernet1/0/0] port link-type trunk
[CE1-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300
[CE1-GigabitEthernet1/0/0] stp disable
[CE1-GigabitEthernet1/0/0] quit
l Configure CE2.
# Disable STP on the interfaces that need to be added to the RRPP ring on CE2. Configure the
l Configure UPE A.


l Configure UPE C.
l Configure UPE D.
# Disable STP on the interfaces that need to be added to the RRPP ring on UPE D. Configure
[UPED] interface gigabitethernet 1/0/0
[UPED-GigabitEthernet1/0/0] port link-type trunk
[UPED-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300
[UPED-GigabitEthernet1/0/0] stp disable
[UPED-GigabitEthernet1/0/0] quit
l Configure PE-AGG.


l Configure CE1.
[CE1] rrpp working-mode gb
[CE1] rrpp domain 1
[CE1-rrpp-domain-region1] protected-vlan reference-instance 1
[CE1-rrpp-domain-region1] control-vlan 5
[CE1-rrpp-domain-region1] quit
[CE1] rrpp domain 2
l Configure CE2.
[CE2] rrpp working-mode gb
[CE2] rrpp domain 1
[CE2] rrpp domain 2
l Configure UPE A.
[UPEA] rrpp working-mode gb
[UPEB] rrpp working-mode gb


l Configure UPE C.
[UPEC] rrpp working-mode gb
l Configure UPE D.
[UPED] rrpp working-mode gb
[UPED] rrpp domain 1
[UPED-rrpp-domain-region1] protected-vlan reference-instance 1
[UPED-rrpp-domain-region1] control-vlan 5
[UPED-rrpp-domain-region1] quit
l Configure PE-AGG.
[PE-AGG] rrpp working-mode gb


l Configure CE1.
# Configure CE1 as the master node of ring 2 in domain 1. Configure GE 1/0/0 as the primary
port and GE 2/0/0 as the secondary port.
[CE1] rrpp domain 1
[CE1-rrpp-domain-region1] ring 2 node-mode master primary-port gigabitethernet
[CE1-rrpp-domain-region1] ring 2 enable
[CE1] rrpp domain 2
l Configure CE2.
[CE2] rrpp domain 1
[CE2] rrpp domain 2
l Configure UPE A.
ports on UPE A.
ports on UPE A.
<UPEA> system-view
ports on UPE B.


ports on UPE B.
# Configure UPE B as an edge transit node on ring 2 in domain 1 and configure GE 3/0/0 as the
edge port.
[UPEB-rrpp-domain-region1] ring 2 node-mode transit secondary-port gigabitethernet
3/0/0
edge port.
3/0/0
edge port.
3/0/1
edge port.
3/0/1
l Configure UPE C.
ports on UPE C.
ports on UPE C.

# Configure UPE C as an edge transit node on ring 2 in domain 1 and configure GE 3/0/0 as the
edge port.
[UPEC-rrpp-domain-region1] ring 2 node-mode transit secondary-port gigabitethernet
3/0/0
edge port.
3/0/0
edge port.
3/0/1
edge port.
3/0/1
l Configure UPE D.
# Configure UPE D as a transit node of ring 1 in domain 1 and specify primary and secondary
ports on UPE D.
[UPED-rrpp-domain-region1] ring 1 node-mode transit primary-port gigabitethernet
[UPED-rrpp-domain-region1] ring 1 enable
ports on UPE D.
l Configure PE-AGG.


l Configure CE1.

[CE1] rrpp enable
l Configure CE2.

[CE2] rrpp enable
l Configure UPE A.

[UPEA] rrpp enable

[UPEB] rrpp enable
l Configure UPE C.

[UPEC] rrpp enable
l Configure UPE D.

[UPED] rrpp enable
l Configure PE-AGG.

Step 6 Set the link-Up timer.

l Configure CE1.
# Set the link-Up timer to 1 seconds.

[CE1] rrpp linkup-delay-timer 1
l Configure CE2.

l Configure PE-AGG.

[PE-AGG] rrpp linkup-delay-timer 1

perform the following operations to verify the configuration. Here, UPE B and PE-AGG are
used as examples.
l Run the display rrpp brief command on UPE B. The following information is displayed:
[UPEB] display rrpp brief

Domain Index : 1
----------------------------------------------------------------------------
Domain Index : 2
----------------------------------------------------------------------------
The preceding information shows that the RRPP protocol is enabled on UPE B.
In domain 1:
VLAN 5 is the control VLAN and VLANs mapping instance 1 are the protected VLANs.
UPE B is a transit node on ring 1; GE 1/0/0 is the primary port; GE 2/0/0 is the secondary port.
UPE B is an edge transit node on ring 2. GE 3/0/0 is the edge port.
In domain 2:
UPE B is a transit node on ring 1. The primary port is GE 1/0/0, and the secondary port is GE
2/0/0.


Domain Index : 1
---------------------------------------------------------------------------
Domain Index : 2
---------------------------------------------------------------------------
The preceding information shows that the RRPP protocol is enabled on PE-AGG, and the link-
Up timer is 1 second.
port is GE 2/0/0.
port is GE 1/0/0.
l Run the display rrpp verbose domain command on UPE B. You can obtain the following
results:
# View detailed information about UPE B in domain 1.
[UPEB] display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : LinkUp
Is Enabled : Enable Is Active: Yes
Secondary port : GigabitEthernet2/0/0 Port status: UP
RRPP Ring :
2
Ring Level :
1
Node Mode :
Edge Transit
Ring State :
LinkUp
Is Enabled :
Enable Is Active: Yes
Primary port :

RRPP Ring :
3
Ring Level :
1
Node Mode :
Edge Transit
Ring State :
LinkUp
Is Enabled :
Primary port :
UPE B is a transit node on ring 1 in domain 1 and is in LinkUp state.
UPE B is a transit node on ring 2 in domain 1 and is in LinkUp state. GE 3/0/0 is the edge port.
UPE B is an edge transit node on ring 3 in domain 1 and is in LinkUp state. GE 3/0/1 is the edge
port.

[UPEB] display rrpp verbose domain 2
Domain Index : 2
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : LinkUp
RRPP Ring :
2
Ring Level :
1
Node Mode :
Edge Transit
Ring State :
LinkUp
Is Enabled :
Primary port :
RRPP Ring :
3
Ring Level :
1
Node Mode :
Edge Transit
Ring State :
LinkUp
Is Enabled :
Primary port :
UPE B is a transit node in domain 2 and is in LinkUp state.
UPE B is a transit node on ring 2 in domain 2 and is in LinkUp state. GE 3/0/0 GE 3/0/0 is the
edge port.
UPE B is an edge transit node on ring 3 in domain 2 and is in LinkUp state. GE 3/0/1 is the edge
port.

results:
<PE-AGG> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
Domain Index : 2
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
----End
Configuration Files
l Configuration file of CE1
#
sysname CE1
#
#
rrpp enable
rrpp linkup-delay-timer 1
#


#
rrpp domain 1
control-vlan 5
ring 2 enable
rrpp domain 2
control-vlan 10
ring 2 enable
#
port trunk allow-pass vlan 6 11 100 to 300
stp disable
#
stp disable
#
return

#
sysname CE2
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 3 enable
rrpp domain 2
control-vlan 10
ring 3 enable
#
stp disable
#
stp disable
#
Return

#
sysname UPEA
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return
#
sysname UPEB
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
ring 2 enable
ring 3 enable
rrpp domain 2
control-vlan 10
ring 1 enable
ring 2 enable


ring 3 enable
#
stp disable
#
stp disable
#
stp disable
#
stp disable
#
return
#
sysname UPEC
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
ring 2 enable
ring 3 enable
rrpp domain 2
control-vlan 10
ring 1 enable
ring 2 enable
ring 3 enable
#
stp disable
#
stp disable
#

stp disable
#
stp disable
#
Return
l Configuration file of UPE D
#
sysname UPED
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return
#
sysname PE-AGG
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5

ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return
4.6.7 Example for Configuring Crossed RRPP Rings with Multiple

Instances (HW version)
As shown in Figure 4-12, UPE A, UPE B, UPE C, UPE D, and PE-AGG form two multi-instance
major rings: ring 1 in domain 1 and ring 1 in domain 2.
connected to the major rings through GE 3/0/0 of UPE B and GE 3/0/0 of UPE C. UPE B is an
edge node, and UPE is an assistant edge node.
connected to the major rings through GE 3/0/1 of UPE B and GE 3/0/1 of UPE C. UPE B is an
edge node, and UPE is an assistant edge node.
2.

Domain ID Control Instance ID Data VLAN ID Instance ID of
VLAN ID of Control Data VLAN
VLAN

VLAN 6

VLAN 11
master node.

Ring ID Master Primary Secondary Port Ring Type
Node Port
Ring 1 in PE-AGG GE1/0/0 GE2/0/0 Major ring

domain 1
Ring 1 in PE-AGG GE2/0/0 GE1/0/0 Major ring

domain 2
Ring 2 in CE1 GE1/0/0 GE2/0/0 Sub ring

domain 1

domain 2

domain 1

domain 2
Table 4-8 shows the edge nodes, assistant edge nodes, public port, and edge port of the subrings.
Table 4-8 Edge nodes, assistant edge nodes, public port, and edge port of the subrings
Ring Edge Comm Edge Port Edge- Common Edge Port
ID Node on Port Assistant Port
Node
Ring 2 UPE B GE GE 3/0/0 UPE C GE 2/0/0 GE 3/0/0

in 1/0/0
domain
1

in 1/0/0
domain
1

in 1/0/0
domain
2

in 1/0/0
domain
2
To reduce the Edge-Hello packets sent on the major ring and increase available bandwidth, you
can add the four subrings to a ring group.

To prevent topology flapping, you need to set the Link-Up timer on the master nodes.
Figure 4-12 Networking diagram of crossed RRPP rings with multiple instances
Backbone
network
GE1/0/0 GE2/0/0
PE-AGG
Master 1
GE2/0/0 Master 2 GE1/0/0
UPE A Domain 1 ring UPED
GE1/0/0 1
GE2/0/0
Domain 2 ring
1
Assistan
GE2/0/0 Edge GE1/0/0
t
UPE B GE1/0/0 GE2/0/0 UPEC
GE3/0/0 GE3/0/1
GE3/0/1 GE3/0/0
Domain 2 ring Domain 2 ring

GE1/0/0 2 3
GE2/0/0
Master 1 Master 1
Master 2 Domain 1 ring Domain 1 ring Master 2
GE2/0/0 GE1/0/0
2 3
CE 1 CE 2
VLAN 100-300 VLAN 100-300
Domain 1
Domain 2
domain 2.
3. Add CE1, UPE B, and UPE C to ring 2 in domain 1 and ring 2 in domain 2.
4. Add CE2, UPE B, and UPE C to ring 3 in domain 1 and ring 3 in domain 2.


7. Configure PE-AGG as the master node and configure UPE A, UPE B, and UPE C as transit
nodes on ring 1 in domain 1 and ring 1 in domain 2.
10. Configure a ring group.
11. Set the link-Up timer.
Data Preparation
l Instance IDs
l ID of the ring group
l Link-Up-Delay timer
Procedure
l Configure CE1.
# Create instance 1 and map it to control VLANs VLAN 5 and VLAN 6 and data VLANs
100 to 200 in domain 1.

l Configure CE2.


l Configure UPE A.


l Configure UPE C.


l Configure UPE D.

l Configure PE-AGG.


View the mapping between instances and VLANs. The displayed information on UPE A is
as follows:
Oper configuration
Format selector :0
Revision level :0

0 1 to 4, 7 to 9, 12 to 99, 301 to 4094
1 5 to 6, 100 to 200
2 10 to 11, 201 to 300

l Configure CE1.
# Disable STP on the interfaces that need to be added to the RRPP ring on CE1. Configure

l Configure CE2.
# Disable STP on the interfaces that need to be added to the RRPP ring on CE2. Configure
l Configure UPE A.
l Configure UPE C.


l Configure UPE D.
l Configure PE-AGG.
l Configure CE1.
[CE1] rrpp domain 1
[CE1] rrpp domain 2
l Configure CE2.

[CE2] rrpp domain 1

[CE2] rrpp domain 2
l Configure UPE A.
l Configure UPE C.
l Configure UPE D.

l Configure PE-AGG.
Step 4 Create an RRPP ring.

l Configure PE-AGG.
[PE-AGG-rrpp-domain-region1] ring 1 node-mode master primary-port
l Configure UPE A.
ports on UPE A.
[UPEA-rrpp-domain-region1] ring 1 node-mode transit primary-port
ports on UPE A.
l Configure UPE D.
ports on UPE D.
[UPED-rrpp-domain-region1] ring 1 node-mode transit primary-port


ports on UPE D.
[UPED-rrpp-domain-region2] ring 1 node-mode transit primary-port
ports on UPE B.
[UPEB-rrpp-domain-region1] ring 1 node-mode transit primary-port
ports on UPE B.
# Configure UPE B as an edge node of ring 2 in domain 1. Configure GE 1/0/0 as the public
port and GE 3/0/0 as the edge port.
[UPEB-rrpp-domain-region1] ring 2 node-mode edge common-port gigabitethernet
l Configure UPE C.
ports on UPE C.
<UPEC> system-view

[UPEC-rrpp-domain-region1] ring 1 node-mode transit primary-port

ports on UPE C.
[UPEC-rrpp-domain-region1] ring 2 node-mode assistant-edge common-port
# Configure UPE C as an edge node of ring 3 in domain 1. Configure GE 1/0/0 as the public
# Configure UPE C as an edge node of ring 3 in domain 2. Configure GE 2/0/0 as the public
l Configure CE1.
[CE1] rrpp domain 1
[CE1] rrpp domain 2
l Configure CE2.

[CE2] rrpp domain 1

[CE2] rrpp domain 2

l Configure PE-AGG.
l Configure UPE A.
[UPEA] rrpp enable
l Configure UPE D.
[UPED] rrpp enable
[UPEB] rrpp enable
l Configure UPE C.
[UPEC] rrpp enable
l Configure CE1.
[CE1] rrpp enable
l Configure CE2.
[CE2] rrpp enable
Step 6 Configure a ring group.

l Configure UPE C (assistant edge node).
# Create ring group 1, which consists of four subrings: ring 2 in domain 1, ring 3 in domain
1, ring 2 in domain 2, and ring 3 in domain 2.
[UPEC] rrpp ring-group 1
[UPEC-rrpp-ring-group1] domain 1 ring 2 to 3
[UPEC-rrpp-ring-group1] domain 2 ring 2 to 3
[UPEC-rrpp-ring-group1] quit
l Configure UPE B (edge node).

# Create ring group 1, which consists of four subrings: ring 2 in domain 1, ring 3 in domain
1, ring 2 in domain 2, and ring 3 in domain 2.

[UPEB] rrpp ring-group 1

[UPEB-rrpp-ring-group1] domain 1 ring 2 to 3
[UPEB-rrpp-ring-group1] domain 2 ring 2 to 3
[UPEB-rrpp-ring-group1] quit
Step 7 Set the link-Up timer.

l Configure CE1.
# Set the link-Up timer to 1 second.
l Configure CE2.
l Configure PE-AGG.
[PE-AGG] rrpp linkup-delay-timer 1

perform the following operations to verify the configuration. Here, UPE B and PE-AGG are
used as examples.
l Run the display rrpp brief command on UPE B. The following information is displayed.
[UPEB] display rrpp brief

RRPP Linkup Delay Timer: 0 sec(default is 0 sec)
Domain Index : 1
Enabled
-------------------------------------------------------------------------------
--
Domain Index : 2
Enabled
-------------------------------------------------------------------------------
--
You can see that the RRPP protocol is enabled on UPE B.

In domain 1:

UPE B is a transit node on ring 1; GE 1/0/0 is the primary port; GE 2/0/0 is the secondary
port.
UPE B is an edge transit node on ring 2. GE 1/0/0 is the public port and GE 3/0/0 is the edge
port.
port.
In domain 2:
UPE B is a transit node on ring 1. GE 1/0/0 is the primary port, and GE 2/0/0 is the secondary
port.
port.
port.

RRPP Linkup Delay Timer: 1 sec(default is 0 sec)
Domain Index : 1
Enabled
-------------------------------------------------------------------------------
--
Domain Index : 2
Enabled
-------------------------------------------------------------------------------
--
The preceding information shows that the RRPP protocol is enabled on PE-AGG, and the
link-Up timer is 2 seconds.
VLANs; PE-AGG is the master node on ring 1. GE 1/0/0 is the primary port, and GE 2/0/0
is the secondary port.
VLANs; PE-AGG is the master node on ring 1. GE 2/0/0 is the primary port, and GE 1/0/0
is the secondary port.

l Run the display rrpp verbose domain command on UPE B. You can obtain the following
results:
<[UPEB] display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : LinkUp
RRPP Ring : 2
Ring Level : 1
Node Mode : Edge
Ring State : LinkUp
RRPP Ring : 3
Ring Level : 1
Node Mode : Edge
Ring State : LinkUp
UPE B is a transit node on ring 1 in domain 1 and is in LinkUp state.
UPE B is a transit node on ring 2 in domain 1 and is in LinkUp state. GE 1/0/0 is the public
port, and GE 3/0/0 is the edge port.
<UPEB> display rrpp verbose domain 2
Domain Index : 2
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : LinkUp
RRPP Ring : 2
Ring Level : 1
Node Mode : Edge
Ring State : LinkUp
RRPP Ring : 3

Ring Level : 1
Node Mode : Edge
Ring State : LinkUp
The preceding information shows that VLAN 10 is the control VLAN in domain 2, and
VLANs mapping instance 2 are the protected VLANs.
UPE B is a transit node in domain 2 and is in LinkUp state.
results:
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
GE 1/0/0 is the primary port, and GE 2/0/0 is the secondary port.
Domain Index : 2
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
The preceding information shows that VLAN 10 is the control VLAN in domain 2, and
VLANs mapping instance 2 are the protected VLANs.
GE 2/0/0 is the primary port, and GE 1/0/0 is the secondary port.
l Run the display rrpp ring-group command on UPE B to view the configuration of the ring
group.
# View the configuration of ring group 1.
[UPEB] display rrpp ring-group 1
Ring Group 1:

domain 1 ring 2 to 3
domain 1 ring 2 send Edge-Hello packet
----End
Configuration Files
#
sysname CE1
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 2 enable
rrpp domain 2
control-vlan 10
ring 2 enable
#
stp disable
#
stp disable
#
return

#
sysname CE2
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 3 enable

rrpp domain 2
control-vlan 10
ring 3 enable
#
stp disable
#
stp disable
#
return
#
sysname UPEA
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return
#
sysname UPEB
#
#
rrpp enable
#
#

rrpp domain 1
control-vlan 5
ring 1 enable
ring 2 node-mode edge common-port GigabitEthernet1/0/0 edge-port
ring 2 enable
ring 3 enable
rrpp domain 2
control-vlan 10
ring 1 enable
ring 2 enable
ring 3 enable
#
rrpp ring group 1
#
stp disable
#
stp disable
#
stp disable
#
stp disable
#
return
#
sysname UPEC
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable


ring 2 enable
ring 3 enable
rrpp domain 2
control-vlan 10
ring 1 enable
ring 2 enable
ring 3 enable
#
rrpp ring group 1
#
stp disable
#
stp disable
#
stp disable
#
stp disable
#
return
#
sysname UPED
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable

#
stp disable
#
stp disable
#
return

#
sysname PE-AGG
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return
4.6.8 Example for Configuring Tangent RRPP Rings with Multiple

Instances
As shown in Figure 4-13, UPE A, UPE B, UPE C, and UPE D form two multi-instance rings:
ring 1 in domain 1 and ring 1 in domain 2. UPE D, UPE E, UPE F, and UPE G form ring 1 in
domain 3. Packets of the data VLANs connected to CE are forwarded to the backbone network
through the two tangent rings.
The tangent point of the two rings is UPE D.

Table 4-9 shows the mapping between protected VLANs and instances in domain 1, domain 2,
and domain 3.

Domain ID Control VLAN Instance ID Protected VLAN Instance ID
Domain 1 VLAN 5, 6 Instance 1 VLAN 100-200 Instance 1
Domain 3 (on VLAN 20, 21 Instance 3 VLAN 100-300 Instance 1 and

UPE D) instance 2
master node.
Ring ID Master Node Primary Port Secondary Port
Ring 1 in domain 1 UPE D GE 1/0/0 GE 2/0/0
Ring 1 in domain 2 UPE D GE 2/0/0 GE 1/0/0
Ring 1 in domain 3 UPE F GE 1/0/0 GE 2/0/0
Figure 4-13 Networking diagram of tangent RRPP rings with multiple instances
UPEB UPEE
GE1/0/0 GE2/0/0 GE1/0/0 GE2/0/0
Domain 1 ring 1
GE2/0/0 GE1/0/0 GE1/0/1 GE1/0/0

Master 1 UPEF
UPEA UPED Master 3
Master 2
CE GE1/0/0 GE2/0/0 GE2/0/1 GE2/0/0
VLAN 100-300 Domain 2 ring 1 Domain 3 ring 1
GE2/0/0 GE1/0/0 GE2/0/0 GE1/0/0

UPEC UPEG
domain 1
domain 2
domain 3

2. Add UPE A, UPE B, UPE C, and UPE D to ring 1 in domain 1 and ring 1 in domain 2.
3. Add UPE D, UPE E, UPE F, and UPE G to ring 1 in domain 3.
6. Configure the control VLAN in domain 3.
7. Configure UPE D as the master node and configure UPE A, UPE B, and UPE C as transit
nodes on ring 1 in domain 1 and ring 1 in domain 2.
8. Configure UPE F as the master node and configure UPE D, UPE E, and UPE G as transit
nodes on ring 1 in domain 3.
Data Preparation
l Instance IDs
Procedure
l Configure UPE A.
to 200 in domain 1.
to 300 in domain 2.


to 200 in domain 1.
to 300 in domain 2.

l Configure UPE C.
to 200 in domain 1.
to 300 in domain 2.

l Configure UPE D.
to 200 in domain 1.
to 300 in domain 2.
# Create instance 3 and map it to control VLANs VLAN 20 and VLAN 21 in domain 3.
[UPED-mst-region] instance 3 vlan 20 21


l Configure UPE E.
# Create data VLANs 100 to 300 on UPE E.
[Quidway] sysname UPEE
[UPEE] vlan batch 100 to 300
to 300 in domain 3.
[UPEE] stp region-configuration
[UPEE-mst-region] instance 1 vlan 20 21 100 to 300

[UPEE-mst-region] active region-configuration
[UPEE-mst-region] quit
l Configure UPE F.
# Create data VLANs 100 to 300 on UPE F.
[Quidway] sysname UPEF
[UPEF] vlan batch 100 to 300
to 300 in domain 3.
[UPEF] stp region-configuration
[UPEF-mst-region] instance 1 vlan 20 21 100 to 300

[UPEF-mst-region] active region-configuration
[UPEF-mst-region] quit
l Configure UPE G.
# Create data VLANs 100 to 300 on UPE G.
[Quidway] sysname UPEG
[UPEG] vlan batch 100 to 300
to 300 in domain 3.
[UPEG] stp region-configuration
[UPEG-mst-region] instance 1 vlan 20 21 100 to 300

[UPEG-mst-region] active region-configuration
[UPEG-mst-region] quit

Oper configuration
Format selector :0
Revision level :0


0 1 to 4, 7 to 9, 12 to 99, 301 to 4094
1 5 to 6, 100 to 200
2 10 to 11, 201 to 300

l Configure UPE A.
l Configure UPE C.
l Configure UPE D.

l Configure UPE E.
# Disable STP on the interfaces that need to be added to the RRPP ring on UPE E. Configure
[UPEE] interface gigabitethernet 1/0/0
[UPEE-GigabitEthernet1/0/0] port link-type trunk
[UPEE-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300
[UPEE-GigabitEthernet1/0/0] stp disable
[UPEE-GigabitEthernet1/0/0] quit
[UPEE] interface gigabitethernet 2/0/0
[UPEE-GigabitEthernet2/0/0] port link-type trunk
[UPEE-GigabitEthernet2/0/0] port trunk allow-pass vlan 100 to 300
[UPEE-GigabitEthernet2/0/0] stp disable
[UPEE-GigabitEthernet2/0/0] quit
l Configure UPE F.
# Disable STP on the interfaces that need to be added to the RRPP ring on UPE F. Configure
[UPEF] interface gigabitethernet 1/0/0
[UPEF-GigabitEthernet1/0/0] port link-type trunk
[UPEF-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300
[UPEF-GigabitEthernet1/0/0] stp disable
[UPEF-GigabitEthernet1/0/0] quit
[UPEF] interface gigabitethernet 2/0/0
[UPEF-GigabitEthernet2/0/0] port link-type trunk
[UPEF-GigabitEthernet2/0/0] port trunk allow-pass vlan 100 to 300
[UPEF-GigabitEthernet2/0/0] stp disable
[UPEF-GigabitEthernet2/0/0] quit
l Configure UPE G.
# Disable the STP function on the interfaces to be added to the RRPP ring on UPE G. Configure
[UPEG] interface gigabitethernet 1/0/0
[UPEG-GigabitEthernet1/0/0] port link-type trunk
[UPEG-GigabitEthernet1/0/0] port trunk allow-pass vlan 100 to 300
[UPEG-GigabitEthernet1/0/0] stp disable
[UPEG-GigabitEthernet1/0/0] quit
[UPEG] interface gigabitethernet 2/0/0
[UPEG-GigabitEthernet2/0/0] port link-type trunk
[UPEG-GigabitEthernet2/0/0] port trunk allow-pass vlan 100 to 300
[UPEG-GigabitEthernet2/0/0] stp disable
[UPEG-GigabitEthernet2/0/0] quit
l Configure UPE A.

l Configure UPE C.
l Configure UPE D.
# Configure the VLANs mapping instances 1 to 3 as the protected VLANs in domain 3.

Configure VLAN 20 as the control VLAN.


[UPED-rrpp-domain-region3] protected-vlan reference-instance 1 2 3
l Configure UPE E.
# Configure VLAN 20 as the control VLAN in domain 3.
[UPEE] rrpp domain 3
[UPEE-rrpp-domain-region3] protected-vlan reference-instance 1
[UPEE-rrpp-domain-region3] control-vlan 20
[UPEE-rrpp-domain-region3] quit
l Configure UPE F.
[UPEF] rrpp domain 3
[UPEF-rrpp-domain-region3] protected-vlan reference-instance 1
[UPEF-rrpp-domain-region3] control-vlan 20
[UPEF-rrpp-domain-region3] quit
l Configure UPE G.
[UPEG] rrpp domain 3
[UPEG-rrpp-domain-region3] protected-vlan reference-instance 1
[UPEG-rrpp-domain-region3] control-vlan 20
[UPEG-rrpp-domain-region3] quit

l Configure UPE A.
ports on UPE A.
ports on UPE A.
ports on UPE B.
ports on UPE B.


l Configure UPE C.
ports on UPE C.
ports on UPE C.
l Configure UPE D.
# Configure UPE D as the master node of ring 1 in domain 1. Configure GE 1/0/0 as the primary
[UPED-rrpp-domain-region1] ring 1 node-mode master primary-port gigabitethernet
# Configure UPE D as the master node of ring 1 in domain 2. Configure GE 2/0/0 as the primary
[UPED-rrpp-domain-region2] ring 1 node-mode master primary-port gigabitethernet
ports on UPE D.
l Configure UPE E.
# Configure UPE E as a transit node of ring 1 in domain 3 and specify primary and secondary
ports on UPE E.
[UPEE] rrpp domain 3
[UPEE-rrpp-domain-region3] ring 1 node-mode transit primary-port gigabitethernet
[UPEE-rrpp-domain-region3] ring 1 enable
[UPEE-rrpp-domain-region3] quit
l Configure UPE F.
# Configure UPE F as the master node of ring 1 in domain 3. Configure GE 1/0/0 as the primary

[UPEF] rrpp domain 3

[UPEF-rrpp-domain-region3] ring 1 node-mode master primary-port gigabitethernet
[UPEF-rrpp-domain-region3] ring 1 enable
[UPEF-rrpp-domain-region3] quit
l Configure UPE G.
# Configure UPE G as a transit node of ring 1 in domain 3 and specify primary and secondary
ports on UPE G.
[UPEG] rrpp domain 3
[UPEG-rrpp-domain-region3] ring 1 node-mode transit primary-port gigabitethernet
[UPEG-rrpp-domain-region3] ring 1 enable
[UPEG-rrpp-domain-region3] quit
l Configure UPE A.

[UPEA] rrpp enable

<UPEB> system-view
[UPEB] rrpp enable
l Configure UPE C.

[UPEC] rrpp enable
l Configure UPE D.

[UPED] rrpp enable
l Configure UPE E.

[UPEE] rrpp enable
l Configure UPE F.

[UPEF] rrpp enable
l Configure UPE G.

[UPEG] rrpp enable
perform the following operations to verify the configuration. Here, UPE D is taken for example.

l Run the display rrpp brief command on UPE D. The following information is displayed:
[UPED] display rrpp brief

Domain Index : 1
----------------------------------------------------------------------------
Domain Index : 2
----------------------------------------------------------------------------
Domain Index : 3
Protected VLAN : Reference Instance 1 to 3
----------------------------------------------------------------------------
The preceding information shows that the RRPP protocol is enabled on UPE D.
In domain 1:
UPE D is the master on ring 1; GE 1/0/0 is the primary port; GE 2/0/0 is the secondary port.
In domain 2:
UPE D is the master node on ring 1. The primary port is GE 2/0/0, and the secondary port is GE
1/0/0.
In domain 3:
VLAN 20 is the control VLAN and VLANs mapping instance 1 to 3 are the protected VLANs.
UPE D is a transit node on ring 1. The primary port is GE 1/0/1, and the secondary port is GE
2/0/1.
l Run the display rrpp verbose domain command on UPE D. You can obtain the following
results:
# View detailed information about UPE D in domain 1.
[UPED] display rrpp verbose domain 1
Domain Index : 1


RRPP Ring : 1
Ring Level : 0
Node Mode : Master
UPE D is the master node in domain 1 and is in Complete state.

Domain Index : 2
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
UPE D is the master node in domain 2 and is in Complete state.

Domain Index : 3
Protected VLAN : Reference Instance 1 to 3
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : LinkUp
mapping instance 1 to 3 are the protected VLANs.
UPE D is a transit node in domain 3 and is in LinkUp state.

----End
Configuration Files
#
sysname UPEA
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
return

#
sysname UPEB
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10

ring 1 enable
#
stp disable
#
stp disable
#
return
#
sysname UPEC
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
#
stp disable
#
stp disable
#
Return
#
sysname UPED
#
vlan batch 5 to 6 10 to 11 20 to 21 100 to 300
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5

ring 1 enable
rrpp domain 2
control-vlan 10
ring 1 enable
rrpp domain 3
control-vlan 20
protected-vlan reference-instance 1 2 3
ring 1 enable
#
stp disable
#
stp disable
#
stp disable
#
stp disable
#
return
l Configuration file of UPE E

#
sysname UPEE
#
#
rrpp enable
#
#
rrpp domain 3
control-vlan 20
ring 1 enable
#
stp disable
#
stp disable
#
return
l Configuration file of UPE F

#
sysname UPEF
#
#
rrpp enable
#
#
rrpp domain 3
control-vlan 20
ring 1 enable
#
stp disable
#
stp disable
#
return
l Configuration file of UPE G

#
sysname UPEG
#
#
rrpp enable
#
#
rrpp domain 3
control-vlan 20
ring 1 enable
#
stp disable
#
stp disable
#
return

Configuration Guide - Reliability 5 Ethernet OAM Configuration
5 Ethernet OAM Configuration
About This Chapter
This chapter describes Ethernet OAM and its configurations, and how to implement link-level
Ethernet OAM detection and network-level Ethernet OAM detection to improve network
reliability.
5.1 Introduction to Ethernet OAM

Ethernet OAM can effectively improve management and maintenance capabilities on Ethernet
networks, which ensures the stable network operation. Ethernet OAM is applicable mainly to
Ethernet networks.
5.2 Ethernet OAM Supported by the S9700
This section describes the Ethernet OAM features supported by the S9700.
5.3 Configuring Basic EFM OAM
By configuring basic EFM OAM functions, you can detect connectivity of the direct link between
devices.
5.4 Configuring EFM OAM Link Monitoring
By configuring EFM OAM detection for errored codes, errored frames, and errored frame
seconds, you can more effectively detect link layer faults.
5.5 Testing the Packet Loss Ratio on the Physical Link
By testing the packet loss ratio on a physical link, you can take effective measures to ensure
better performance of the link.
5.6 Configuring Associating between EFM OAM and an Interface
After EFM OAM is associated with an interface, services may be greatly affected. For example,
all the Layer 2 and Layer 3 services may be blocked.
5.7 Configuring Association Between an EFM OAM Session and an Interface (Triggering the
Physical Status of the Interface Associated with the EFM OAM Session to Become Down)
After the association between an EFM OAM session and an interface is configured in the OAM
management view, the local EFM OAM session detects a fault and then notifies the OAM
management module of the fault. This triggers the physical status of the interface associated
with the EFM OAM session to become Down. In addition, when the physical status of an
interface becomes Down, the OAM management module notifies the EFM OAM session of the
fault. The EFM OAM session can then send fault information to the remote device.

5.8 Configuring Association Between EFM OAM Sessions

Association between EFM OAM sessions is applicable to the networking where two interfaces
on a device are enabled with EFM OAM. When an EFM OAM session detects a link fault on
an interface of a device, the local EFM OAM session notifies the OAM management module of
the fault. The OAM management module sends fault information to the EFM OAM session on
the remote device through a corresponding outgoing interface. Then, the remote EFM OAM
session notifies the OAM management module on the remote device of the fault. In this manner,
the remote device is notified of the fault.
5.9 Configuring Basic Ethernet CFM
By configuring basic Ethernet CFM functions, you can implement end-to-end detection,
advertisement, verification, and location of connectivity faults.
5.10 Configuring Related Parameters of Ethernet CFM
By adjusting parameters of Ethernet CFM, you can detect connectivity of an Ethernet network
from end to end.
5.11 Fault Verification on the Ethernet
By sending detection packets and waiting for replies, you can test connectivity of the path
between devices.
5.12 Locating the Fault on the Ethernet
By sending test packets and waiting for a reply, you can test connectivity of the path between
devices and locate faults.
5.13 Configuring Association Between Ethernet CFM and an Interface
The association between Ethernet CFM and an interface is used to detect faults of an active link
in the LACP static link aggregation group or in the manually-configured 1:1 active/standby link
aggregation group and then trigger the protection switchover.
5.14 Configuring Association Between Ethernet CFM and an Interface (Triggering the Physical
Status of the Interface Associated with Ethernet CFM to Become Down)
After the association between Ethernet CFM and an interface is configured in the OAM
management view, local Ethernet CFM can detect a fault and then notify the OAM management
module of the fault. This triggers the physical status of the interface associated with Ethernet
CFM to become Down. In addition, when the physical status of an interface becomes Down, the
OAM management module notifies Ethernet CFM of the fault, and Ethernet CFM sends Ethernet
CFM messages carrying fault information to the remote device.
5.15 Associating EFM OAM with Ethernet CFM
This section describes how to associate EFM OAM with Ethernet CFM.
5.16 Configuring Association Between Ethernet CFM and Ethernet CFM
This section describes how to configure association between Ethernet CFM and Ethernet CFM.
5.17 Configuring Association Between Ethernet CFM and SEP
This section describes how to configure association between Ethernet CFM and SEP.
5.18 Configuring Association Between Ethernet OAM and BFD
By associating Ethernet OAM with BFD, you can implement the fault notification.
5.19 Maintaining Ethernet OAM
This section describes how to maintain Ethernet OAM. Detailed operations include deleting
CCM statistics, monitoring Ethernet OAM.
This section provides several configuration examples of Ethernet OAM.

5.1 Introduction to Ethernet OAM

Ethernet OAM can effectively improve management and maintenance capabilities on Ethernet
networks, which ensures the stable network operation. Ethernet OAM is applicable mainly to
Ethernet networks.
Background
The Ethernet has developed as the major Local Area Network (LAN) technology because it
features easy implementation and low cost. Recently, along with the applications of Gigabit
Ethernet and the later 10-Gigabit Ethernet, Ethernet has been extended to the Wide Area Network
(WAN).
Compared with WANs, reliability and stability are not highly required for LANs. Therefore, a
mechanism for network Operations, Administration and Maintenance (OAM) is always required
for the Ethernet. The lack of the OAM mechanism prevents Ethernet from effectively functioning
as the Internet Service Provider (ISP) network. In this manner, Ethernet OAM is becoming a
trend.
Functions
Ethernet OAM has the following functions:
l Fault management
Ethernet OAM can detect the network connectivity by sending detection messages
regularly or through manual triggering.
Ethernet OAM can locate faults on the Ethernet by using means similar to the Packet
Internet Groper (ping) and traceroute tools on IP networks.
Ethernet OAM can work with the Automatic Protection Switching (APS) to trigger
protection switching when detecting connectivity faults. This ensures service
interruption in no more than 50 ms to achieve carrier-class reliability.
l Performance management
Performance management is used to measure the packet loss ratio, delay, and jitter during
the transmission of packets. It also collects statistics on various kinds of traffic.
Performance management is implemented at the access point of users. By using the
performance management tools, the ISP can monitor the network status and locate faults
through the Network Management System (NMS). The ISP checks whether the forwarding
capacity of the network complies with the Service Level Agreement (SLA) signed with
users.
Ethernet OAM improves network management and maintenance capabilities on the Ethernet
and guarantees a steady network.
5.2 Ethernet OAM Supported by the S9700

This section describes the Ethernet OAM features supported by the S9700.
EFM OAM
802.3ah, also referred to as Ethernet in the First Mile (EFM), defines the specifications of the
Ethernet physical layer and OAM used for user access. EFM OAM detects the link in the last

mile. EFM OAM is a link-level OAM mechanism. The S9700 provides the following EFM OAM
functions:
l Peer discovery
When the EFM OAM function is enabled on an interface of the S9700 and the peer interface,
the two interfaces match their EFM OAM configurations by sending and responding to
OAM Protocol Data Units (OAMPDUs). If the EFM OAM configurations on both
interfaces match, the two interfaces start the EFM OAM handshake. During the handshake,
the two interfaces send OAMPDUs periodically to maintain the neighbor relationship.
l Link monitoring
When an interface detects an errored frame event or an errored frame error seconds event,
the interface sends an OAMPDU to notify the peer device of the event.
An errored frame event occurs when the number of errored frames detected on an
interface reaches or exceeds the specified threshold within a certain period.
An errored code event occurs when the number of errored codes reaches or exceeds the
specified threshold within a certain period.
An errored frame seconds occurs when that the number of errored frame seconds
detected on an interface reaches or exceeds the specified threshold within a certain
period.
The detection duration is measured in seconds. If at least one errored frame is detected
within a second, this second is called an errored frame second.
l Fault notification
When an errored frame event or severe fault event occurs on the local device, the local node
sends fault notification messages to notify the peer device. At the same time, the local
device records the fault event in the log and reports the fault to the NMS. Fault events
include the following:
System reboot
LPU reset
Fault of a physical link
Timeout of OAMPDUs
Errors reported by the OAM module
Power off
When receiving the notification message, the peer records the event contained in the
message to the log and reports it to the NMS.
l Remote loopback
When a local interface sends non-OAMPDUs to the peer, the peer does not forward the
non-OAMPDUs according to their destination MAC addresses. Instead, the peer loops back
non-OAMPDUs to the local interface. This is called remote loopback. Remote loopback
can be used to locate the link fault and test the link quality.
Each interface enabled with EFM OAM works in a certain mode. EFM OAM has two operation
modes: active mode and passive mode. OAM discovery and remote loopback are initiated only
by the interface in active mode.
Ethernet CFM
802.1ag, referred to as Connectivity Fault Management (CFM), defines the OAM function used
to detect the connectivity of the Ethernet bearer network.

l Terms
MD
A maintenance domain (MD) is a network or a part of the network where CFM is
performed. Devices in an MD are managed by a single ISP.
Default MD
According to IEEE Standard 802.1ag-2007, each device can be configured with one
default MD. The default MD must be of a higher level than all MDs to which MEPs
configured on the local device belong. In addition, the default MD must be of the same
level as the high-level MD. The default MD transmits high-level CCMs and creates
MIPs to reply LTR packets.
MA
A maintenance association (MA) is a part of an MD. An MD can be divided into one
or multiple MAs. On the S9700, an MA is associated with a VLAN. Ethernet CFM
checks connectivity in each MA.
MEP
A maintenance association end point (MEP) is an edge node of an MA.
For a network device running Ethernet CFM, its MEP is called the local MEP. For the
other devices in the same MA, their MEPs are called the remote maintenance association
end points (RMEPs).
CAUTION
One Trunk interface can be configured with only one MEP.
MIP
A maintenance association intermediate point (MIP) is an internal node of an MA.
MIPs reside on the interfaces on the S9700 and are automatically created by the
S9700.
l Connectivity check
Ethernet CFM divides a network into one MD or multiple MDs. Each MD is divided into
one MA or multiple MAs. The MEPs in an MA exchange Continuity Check messages
(CCMs) periodically to detect the connectivity between them.
l Fault acknowledgement
802.1ag MAC ping
Similar to ping, 802.1ag MAC ping sends test packets and waits for a reply to test
whether the destination device is reachable. 802.1ag MAC ping is initiated by a MEP
and destined for an RMEP or MIP in the same MA.
Gmac ping
Gmac ping works similarly to 802.1ag MAC ping. A MEP, however, is not required to
initiate Gmac ping. The destination node may not be an RMEP or a MIP. Gmac ping
can be implemented without configuring the MD, MA, or MEP on the source device,
the intermediate device, and the destination device.
l Fault location
802.1ag MAC trace

Similar to traceroute (or tracert for short), 802.1ag MAC trace sends test packets and
waits for a reply to test the path between the local device and the destination device and
to locate faults. 802.1ag MAC trace is initiated by a MEP and destined for an RMEP or
MIP in the same MA.
Gmac trace
Gmac trace works similarly to 802.1ag MAC trace. A MEP, however, is not required
to initiate Gmac trace. The destination node may not be an RMEP or a MIP. That is,
Gmac trace can be implemented without configuring the MD, MA, or MEP on the source
device, the intermediate device, and the destination device. All the intermediate devices
can respond with a Linktrace Reply (LTR).
Fault Association
You can configure the following types of association between an EFM OAM module and an
interface.
l After EFM OAM detects a fault, the OAM management module blocks the interface
intermittently. That is, the module shuts down the interface for seven seconds, and then it
unblocks the interface.
l When EFM OAM detects a fault, the interface bound to the EFM OAM module is shut
down or a Port-Down event is sent. When the interface is Down, a fault notification message
is sent to the EFM OAM module of the peer device through association.
l Association between an EFM OAM module and an interface
After association between an EFM OAM module and an interface is configured, when the
EFM OAM module detects a link fault, no packets except OAMPDUs can be forwarded
through the bound interface, and Layer 2 and Layer 3 services are blocked. Therefore, the
association between an EFM OAM module and an interface may greatly affect services.
When the current interface detects link fault recovery through EFM OAM, all packets can
be forwarded on the interface and Layer 2 and Layer 3 services are unblocked.
In addition, you can configure the association between EFM OAM and an interface only
after EFM OAM at both ends are in detect state.
l Association between EFM OAM modules
After a fault is detected, the OAM management module transmits a fault notification
message through association.
An EFM OAM module on an interface transmits a fault message to an EFM OAM
module on the other interface.
EFM OAM modules on the two interfaces report faults to each other.
l Association between an Ethernet CFM module and an interface
You can configure the following types of association between an Ethernet CFM module
and an interface.
When a connectivity fault is detected on the link between the MEP and the RMEP in
an MA, the OAM management module blocks the interface intermittently. That is, the
module shuts down the interface for seven seconds, and then unblocks the interface.
After Ethernet CFM detects a fault, the interface associated with the Ethernet CFM
module is shut down or a Down event is sent. When the interface becomes Down, the
Ethernet CFM status bound to the interface also becomes Down.
l Association between an Ethernet CFM module and an EFM OAM module
When the Ethernet CFM module detects a fault in an MA, the OAM management module
reports the fault to the peer device enabled with EFM OAM through the interface. When

the EFM OAM module detects a fault, the OAM management module reports the fault to
the MA through the interface. The fault report mode can be the following:
An Ethernet CFM module sends a fault notification message to an EFM OAM module.
An EFM OAM module a fault notification message to an Ethernet CFM module.
An Ethernet CFM module and an EFM OAM module report faults to each other.
l Association between Ethernet CFM modules
reports the fault to the bound MA at the other side. The fault report mode can be the
following:
An Ethernet CFM module at one side sends a fault notification message to an Ethernet
CFM module at the other side.
Ethernet CFM modules at both sides report faults to each other.
l Association between an Ethernet CFM module and a BFD session
reports the fault to the bound BFD session. When a BFD session detects a fault, it reports
the fault to the bound MA. The fault report mode can be the following:
An Ethernet CFM module transmits a fault notification message to a BFD session.
The BFD session transmits the fault notification message to the Ethernet CFM module.
An Ethernet CFM module and a BFD session report faults to each other.
l Association between an EFM OAM module and a BFD session
When an EFM OAM module detects a fault in an MA, the OAM management module
reports the fault to the bound BFD session through association. When a BFD session detects
a fault, it reports the fault to the bound MA through association. The fault report mode can
be the following:
An EFM OAM module transmits a fault notification message to a BFD session.
The BFD session transmits the fault notification message to the EFM OAM module.
An EFM OAM module and a BFD session report faults to each other.
You cannot configure association between an Ethernet OAM module and Ethernet 0/0/0.
5.3 Configuring Basic EFM OAM

By configuring basic EFM OAM functions, you can detect connectivity of the direct link between
devices.

Before configuring basic EFM OAM functions, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the required data. This can help
you complete the configuration task quickly and accurately.
As shown in Figure 5-1, you can perform the configuration task to detect the connectivity
between two directly connected devices.

Figure 5-1 Diagram of configuring EFM OAM

EFM OAM
interface 1 interface 2
(Active mode) (Passive mode)
None.
Data Preparation
To configure EFM OAM, you need the following data.
No. Data
1 (Optional) Maximum size of an EFM OAMPDU
5.3.2 Enabling EFM OAM Globally

You must enable EFM OAM globally before configuring EFM OAM functions.
Context
Do as follows on the devices at both ends of the link:
Procedure
Step 1 Run:
system-view
Step 2 Run:
efm enable
EFM OAM is enabled globally.
By default, EFM OAM is disabled globally.
----End
5.3.3 Configuring the Working Mode of EFM OAM on an Interface

EFM OAM working mode is an attribute of an EFM OAM-enabled interface, and consists of
the active mode and the passive mode.

Context
NOTE
The working mode of EFM OAM on the interface can be configured only after EFM OAM is enabled
globally and before EFM OAM is enabled on the interface. The working mode of EFM OAM on the
interface cannot be modified after EFM OAM is configured on the interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The interface view of an interface at one end of the link is displayed.
Step 3 Run:
efm mode { active | passive }
The working mode of EFM OAM on the interface is configured.
By default, EFM OAM on an interface works in active mode.
At least one interface at both ends of the link must be configured to work in active mode. The
interface in active mode initiates OAM discovery after EFM OAM is enabled on the interface.
Instead of initiating OAM discovery, the interface in passive mode waits for an OAMPDU sent
from the interface in active mode. If both interfaces are configured to work in active mode, you
can implement link detection. If both interfaces are configured to work in passive mode, OAM
discovery fails.
NOTE
You must run the bpdu bridge enable command on the interface configured with EFM OAM to enable
the BPDU tunnel function; otherwise, OAM PDUs are discarded.
----End
5.3.4 (Optional) Setting the Maximum Size of an EFM OAMPDU

You can configure the largest size of EFM OAMPDUs. On the current interface, the EFM
OAMPDUs whose sizes exceed the set size are regarded as illegal and thus discarded.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
efm packet max-size size
The maximum size of an EFM OAMPDU is set.

By default, the maximum size of an EFM OAMPDU on an interface is 128 bytes.
EFM OAMPDUs longer than 128 bytes are discarded as invalid packets.
If the maximum size of an EFM OAMPDU on both interfaces of the link is configured
differently, the two interfaces negotiate and determine the value during the OAM discovery
process. The smaller maximum size of an EFM OAMPDU set on the local interface and the peer
is selected.
----End
5.3.5 Enabling EFM OAM on an Interface

You can perform point-to-point EFM link detection only after enabling EFM OAM on interfaces
on both ends of a link.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
efm enable
EFM OAM is enabled on the interface.

By default, EFM OAM on an interface is disabled.
----End

By viewing EFM OAM configurations, you can check whether the configurations are successful.
Prerequisites
The configurations of the EFM OAM function are complete.

Procedure
l Run the display efm { all | interface interface-type interface-number } command to check
information about EFM OAM on an interface.
l Run the display efm session { all | interface interface-type interface-number } command
to check the status of the EFM OAM protocol on an interface.
----End
Example
Run the display efm command. You can view all the EFM OAM configurations on the local
interface and part of the EFM OAM configurations on the remote interface. For example:
<Quidway> display efm interface gigabitethernet2/0/1
Item Value
----------------------------------------------------
Interface: GigabitEthernet2/0/1
EFM Enable Flag: enable
Mode: active
Loopback IgnoreRequest: no
OAMPDU MaxSize: 128
OAMPDU Timeout: 3000
ErrCodeNotification: disable
ErrCodePeriod: 1
ErrCodeThreshold: 1
ErrFrameNotification: disable
ErrFramePeriod: 1
ErrFrameThreshold: 1
ErrFrameSecondNotification: disable
ErrFrameSecondPeriod: 60
ErrFrameSecondThreshold: 1
Hold Up Time: 0
ThresholdEvtTriggerErrDown: disable
TriggerIfDown: disable
TriggerMacRenew: disable
Remote MAC: 00e0-fc7f-724f
Remote EFM Enable Flag: enable
Remote Mode: passive
Remote MaxSize: 128
Remote Loopback IgnoreRequest: no
Remote State: --
Run the display efm session command. If the EFM OAM protocol on the interface is in the
Detect state, it means that the configuration succeeds. The two interfaces succeed in negotiation
and enter the Detect state.
<Quidway> display efm session interface gigabitethernet2/0/1
Interface EFM State Loopback Timeout
--------------------------------------------------------------------
GigabitEthernet2/0/1 detect --
5.4 Configuring EFM OAM Link Monitoring

By configuring EFM OAM detection for errored codes, errored frames, and errored frame
seconds, you can more effectively detect link layer faults.


Before configuring the EFM OAM link monitoring function, familiarize yourself with the
applicable environment, complete the pre-configuration tasks, and obtain the required data. This
can help you complete the configuration task quickly and accurately.
Link monitoring can be used to detect and locate faults at the link layer in different scenarios.
It uses the event notification OAMPDU. When a link fails, the local link notifies the remote
OAM entity of the fault after detecting a fault through events.
Before configuring EFM OAM link monitoring, complete the following tasks:
l Configuring EFM OAM
Data Preparation
To configure EFM OAM link monitoring, you need the following data.
No. Data
1 (Optional) Period and threshold for detecting errored frames of EFM OAM
2 (Optional) Period and threshold for detecting errored codes of EFM OAM
3 (Optional) Period and threshold for detecting errored frame seconds of EFM OAM
5.4.2 (Optional) Detecting Errored Frames of EFM OAM

When an interface is enabled to detect errored frames, the S9700 generates an errored frame
event and notifies the peer, if the number of errored frames reaches or exceeds the threshold
within a set period.
Context
Do as follows on the devices at one end or both ends of the link:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

efm error-frame period period
The period for detecting errored frames on the interface is set.

By default, the period for detecting errored frames on an interface is 1 second.
Step 4 Run:
efm error-frame threshold threshold
The threshold for detecting errored frames on the interface is set.

By default, the threshold for detecting errored frames on an interface is 1.
Step 5 Run:
efm error-frame notification enable
The interface is enabled to detect errored frames.

By default, an interface cannot detect errored frames.
----End
5.4.3 (Optional) Detecting Errored Codes of EFM OAM

When an interface is enabled to detect errored codes, the S9700 generates an errored code event
and notifies the peer, if the number of errored codes reaches or exceeds the threshold within a
set period.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
efm error-code period period
The period for detecting errored codes on the interface is set.

By default, the period for detecting errored codes on an interface is 1 second.
Step 4 Run:
efm error-code threshold threshold
The threshold for detecting errored codes on the interface is set.

By default, the threshold for detecting errored codes on an interface is 1.
Step 5 Run:
efm error-code notification enable

The interface is enabled to detect errored codes.

By default, an interface cannot detect errored codes.
----End
5.4.4 (Optional) Detecting Errored Frame Seconds of EFM OAM

When an interface is enabled to detect errored frame seconds, the S9700 generates an errored
frame seconds summary event and notifies the peer, if the number of errored frame seconds
reaches or exceeds the threshold within a set period.
Context
An errored frame second is a one-second interval during which at least one errored frame is
detected. It specifies the seconds when errored frames are deteced.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
efm error-frame-second period period
The period for detecting errored frame seconds on the interface is set.
By default, the period for detecting errored frame seconds on an interface is 60 seconds.
Step 4 Run:
efm error-frame-second threshold threshold
The threshold for detecting errored frame seconds on the interface is set.
By default, the threshold for detecting errored frame seconds on an interface is 1.
Step 5 Run:
efm error-frame-second notification enable
The interface is enabled to detect errored frame seconds.

By default, an interface cannot detect errored frame seconds.
----End
5.4.5 (Optional) Associating a Threshold Crossing Event with an

Interface
After a threshold crossing event is associated with an interface, the system sets the administrative
state of the interface to Down. In this manner, all services on the interface are interrupted.

Context
When an interface on a link is enabled to detect errored frames, errored codes, or errored frame
seconds, the link is considered unavailable, if the number of errored frames, errored codes, or
errored frame seconds detected by the interface reaches or exceeds the threshold within a set
period. The errored frame event, errored code event, and errored frame seconds summary event
are called threshold crossing events. In this case, you can associate a threshold crossing event
with the interface so that the system sets the administrative state of the interface to Down. As a
result, the link actually goes Down and all services on the interface are interrupted.
Do as follows on the device at one end or devices at both ends of a link:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of an interface at one end of the link is displayed.
Step 3 Run:
efm threshold-event trigger error-down
A threshold crossing event is associated with the interface.
By default, no threshold crossing event is associated with interfaces.
----End
Follow-up Procedure
After a threshold crossing event is associated with an interface, you can configure the interface
to go administratively Up by using either of the following methods:
l Run the efm holdup-timer command in the interface view to configure the interface to go
administratively Up after the auto-recovery delay.
l Run the shutdown command and then the undo shutdown command in the interface view
to restore the administrative state of the interface to Up.

By viewing EFM OAM configurations, you can check whether the configurations are successful.
Prerequisites
The configurations of the EFM OAM link monitoring function are complete.
Procedure
l Run the display efm { all | interface interface-type interface-number } command to check
information about EFM OAM on an interface.

l Run the display efm session { all | interface interface-type interface-number } command
to check the status of the EFM OAM protocol on an interface.
----End
Example
Run the display efm command. You can view information about link monitoring on the
interface. For example:
<Quidway> display efm interface gigabitethernet1/0/0
Item Value
----------------------------------------------------------
Mode: active
OAMPDU MaxSize: 128
ErrCodeNotification: enable
ErrCodePeriod: 1
ErrCodeThreshold: 1
ErrFrameNotification: enable
ErrFramePeriod: 1
ErrFrameSecondNotification: enable
Hold Up Time: 0
ThresholdEvtTriggerErrDown: enable
RemoteMAC 00e0-fc7f-7258
Remote EFM Enable Flag enable
Remote Mode passive
Remote MaxSize 128
Remote State: --
5.5 Testing the Packet Loss Ratio on the Physical Link

By testing the packet loss ratio on a physical link, you can take effective measures to ensure
better performance of the link.

Before testing the packet loss ratio on a physical link, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the data required for the
configuration. This will help you complete the configuration task quickly and accurately.
CAUTION
Forwarding of service data is affected after EFM OAM remote loopback is enabled. Enable EFM
OAM remote loopback on the link that need not forward service data.

You can perform the configuration task to detect the packet loss ratio on a link.
As shown in Figure 5-2, enable EFM OAM on Switch A and SwitchB and enable remote
loopback on GE 1/0/1 on Switch A. Send test packets from Switch A to SwitchB. You can get
the packet loss ratio on the link by observing the receiving of test packets on Switch A.
Figure 5-2 Diagram of testing the packet loss ratio on the link
Test packets
EFM OAM
SwitchA SwitchB
GE 1/0/1 GE2/0/1
(Active mode) (Passive mode)
Flow of test packets
Before testing the packet loss ratio on the link, complete the following tasks:
Data Preparation
To test the packet loss ratio on the link, you need the following data.
No. Data
1 Timeout period for remote loopback
2 Destination MAC address, VLAN ID, outbound interface, size, number, and sending
rate of test packets
5.5.2 Enabling EFM OAM Remote Loopback

You can configure the EFM OAM remote loopback function to locate faults on the remote end
and assess the link quality.
Context
EFM OAM remote loopback is a method of monitoring link performance. Its working process
is as follows:
1. An OAM entity working in active mode initiates a remote loopback request to the remote
OAM entity.
2. The remote OAM entity ignores or accepts the request.

3. The remote loopback function is disabled manually or automatically.
Procedure
Step 1 Enable a device that initiates a request with the remote loopback function.
1. Run:
system-view

2. Run:

3. Run:
efm loopback start [ timeout timeout ]
The remote EFM OAM loopback function is enabled on the interface.
CAUTION
Remote loopback may cause an exception in forwarding of data packets and protocol
packets; therefore, you are not advised to configure other services on the loopback interface.
By default, the timeout period for remote loopback is 20 minutes. After the timeout period,
remote loopback is automatically disabled. You can set the timeout period to 0 for a link
to remain in the remote loopback state.
The following requirements must be met to implement remote loopback:
l The EFM OAM protocols on the local interface and the peer are in the Detect state.
l EFM OAM on the local interface works in active mode.
Before changing the value of timeout timeout, run the efm loopback stop command to
disable remote loopback on the interface.
You can use the display efm session command to check whether the EFM OAM protocols
running on the local interface and the peer are in the Detect state.
Step 2 (Optional) Configure a receiving device to ignore the remote loopback request.
1. Run:
system-view

2. Run:

3. Run:
efm loopback ignore-request
The interface is configured to ignore the remote loopback request.
By default, the interface accepts and processes the remote loopback request.
----End

5.5.3 Sending Test Packets

The sent test packets are a type of Ethernet packets that are constructed for testing the packet
loss ratio on a link. This function can be used with the EFM OAM remote loopback function to
test the packet loss ratio on the link.
Context
Do as follows on the device with an active interface on the link:
Procedure
Step 1 Run:
system-view

Step 2 Run:
test-packet start [ mac mac-address ] [ vlan vlan-id ] interface interface-type
interface-number [ -c count | -s size ] *
Test packets are sent.

By default, the size of a test packet is 64 bytes; the number of test packets sent is 5.
The outbound interface for the test packets is the interface that connects the link to be tested.
----End
Follow-up Procedure
The parameter in this command cannot be modified when test packets are being sent.
Press Ctrl+C to stop sending test packets.
5.5.4 Checking the Statistics on Returned Test Packets

By viewing statistics of returned test packets, you can calculate the packet loss ratio.
Context
Procedure
Step 1 Run:
display test-packet result
Statistics of the returned test packets are displayed.

The displayed information includes:
l Number of sent test packets

l Number of received test packets
l Number of discarded test packets

l Total number of bytes of sent test packets

l Total number of bytes of received test packet
l Total number of bytes of discarded test packet
l Time to start the sending of test packet
l Time to end the sending of test packet
You can obtain the packet loss ratio on the link based on the preceding data.
----End
5.5.5 (Optional) Manually Disabling EFM OAM Remote Loopback

The EFM OAM remote loopback function can automatically time out or be disabled manually.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
efm loopback stop
Remote loopback is disabled on the interface.
If EFM OAM remote loopback is left enabled, the link fails to forward service data for a long
time. To prevent this, EFM OAM remote loopback on the S9700 can be automatically disabled
after a timeout period. By default, the timeout period for remote loopback is 20 minutes. After
20 minutes, remote loopback stops. If you need to disable remote loopback manually, perform
the preceding operation procedures.
----End
Procedure
Step 1 Run the display efm session { all | interface interface-type interface-number } command to
check the status of the EFM OAM session on an interface.
----End

Example
Run the display efm session command on the device with an active interface on the link. If the
EFM OAM protocol on the active interface is in the Loopback (control) state, which indicates
that the active interface initiates remote loopback, the configuration is successful.
<SwitchA> display efm session interface gigabitethernet 1/0/1
----------------------------------------------------------------------
GigabitEthernet1/0/1 Loopback(control) 20
Run the display efm session command on the device with a passive interface on the link. If the
EFM OAM protocol on the passive interface is in the Loopback (be controlled) state, which
indicates that the passive interface responds to remote loopback, it indicates that the
configuration is successful.
<SwitchB> display efm session interface gigabitethernet 2/0/1
----------------------------------------------------------------------
GigabitEthernet2/0/1 Loopback(be controlled) --
Run the display efm session command on either of the devices on the link. If the EFM OAM
protocol on the interface is in the Detect or Discovery state, the configuration is successful.
<SwitchA> display efm session interface gigabitethernet 1/0/1
----------------------------------------------------------------------
5.6 Configuring Associating between EFM OAM and an

Interface
After EFM OAM is associated with an interface, services may be greatly affected. For example,
all the Layer 2 and Layer 3 services may be blocked.

Before configuring the association between EFM OAM and an interface, familiarize yourself
with the applicable environment, complete the pre-configuration tasks, and obtain the required
data. This can help you complete the configuration task quickly and accurately.
As shown in Figure 5-3, EFM OAM is enabled on Switch A and Switch B. EFM OAM is
associated with GE 1/0/1 on Switch A. When the EFM OAM module on Switch A detects a
connectivity fault between Switch A and Switch B, no other packets except EFM protocol
packets can be forwarded on the interface GE 1/0/1 and Layer 2 and Layer 3 services are blocked.
Therefore, the association of EFM OAM and the current interface may greatly affect services.
When the current interface detects the link fault recovery through EFM OAM, all packets can
be forwarded on the interface and Layer 2 and Layer 3 services are unblocked.

Figure 5-3 Diagram of associating EFM OAM with an interface

EFM
OAM
GE1/0/1 GE2/0/1
SwitchB
SwitchA
Interface associated with EFM OAM
Before associating EFM OAM with an interface, complete the following tasks:
Data Preparation
To associate EFM OAM with an interface, you need the following data.
No. Data
1 Type and number of an interface
2 (Optional) Faulty-state hold timer
5.6.2 Associating EFM OAM with an Interface

By associating EFM OAM with a physical interface, you can use the OAM management module
to notify the bound interface management module of fault information after EFM OAM detects
a fault.
Context
After EFM OAM is enabled on an interface, the status of this interface changes when the interface
receives an OAM PDU control request packet with the Link Fault Status flag.
There are two ways to associate EFM OAM with an interface:
l Associating an error event with an interface and setting the interface to the blocking state
when the error event occurs.
l Associating an error event with an interface and setting the interface to the disabled state
when the error event occurs.
l Associating a threshold crossing event with an interface.
Procedure
l Associate an error event with an interface and set the interface to the blocking state when
the error event occurs.

Setting the interface to the blocking state is applicable to a scenario where traffic can be
switched back automatically after the faulty link recovers. After the associated interface is
blocked, all traffic is interrupted except EFM protocol packets.
1. Run:
system-view

2. Run:

3. Run:
efm trigger if-down
EFM OAM is associated with the interface.
By default, EFM OAM is not associated with an interface.
The efm trigger if-down command is valid in the interface view only after EFM OAM
is enabled on the interface with the efm enable command.
When EFM OAM is associated with the current interface and detects a link fault on
the current interface, no other packets except EFM protocol packets can be forwarded
on the interface and Layer 2 and Layer 3 services are blocked. Therefore, the
association between EFM OAM and an interface may greatly affect services. When
EFM OAM on an interface detects link fault recovery, all packets can be forwarded
on the interface and Layer 2 and Layer 3 services are unblocked.
Before configuring the association between EFM OAM and an interface, ensure that
the EFM OAM protocol on both ends of the link is in the detect state.
If Layer 2 and Layer 3 services are blocked due to a misoperation, you can run the
undo efm trigger if-down command in the interface view to restore services.
l Associate an error event with an interface and set the interface to the disabled state when
the error event occurs.
1. Run:
system-view

2. Run:

3. Run:
efm { critical-event | dying-gasp | link-fault | timeout } trigger error-
down
An error event is associated with the interface.
By default, an error event is not associated with an interface.
After the efm trigger error-downcommand is used to associate an error event with
an interface, protocol status of the interface goes Down and all services on the interface
are interrupted when EFM OAM detects faults specified by critical-event, dying-
gasp, link-fault, or timeout. Even if EFM OAM on the interface detects link fault

recovery , protocol status of the interface do not change. Traffic can be switched back
only after you have manually detected link quality.
----End
5.6.3 (Optional) Setting the Faulty-State Hold Timer

By setting the EFM OAM faulty-state hold timer on physical interfaces, you can prevent
interfaces from alternating between the Up and Down states frequently when links are unstable.
Context
Do as follows on the device at one end or devices at both ends of a link:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
efm holdup-timer time
The faulty-state hold timer is set.
By default, the timeout period of the faulty-state hold timer is 0s.
After the efm trigger if-down command is used to associate EFM OAM with an interface, when
EFM OAM detects a connectivity fault, the faulty state displayed on the interface remains
unchanged within the set timeout period of the faulty-state hold timer, even though the fault is
rectified. EFM OAM does not detect whether the connectivity fault is cleared until the timeout
period of the faulty-state hold timer expires.
----End

By viewing the TriggerIfDown field, you can check whether the configurations are successful.
Prerequisites
The configurations of Associating EFM OAM with an Interface function are complete.
Procedure
Step 1 Run the display efm { all | interface interface-type interface-number } command to check the
EFM OAM configuration information on an interface.
----End

Example
Run the display efm command. If the item "TriggerIfDown" is displayed as "enable", it means
that the configuration succeeds.
<Quidway> display efm interface gigabitethernet 1/0/1
Item Value
----------------------------------------------------
Mode: active
OAMPDU MaxSize: 128
ErrCodeNotification: disable
ErrCodePeriod: 1
ErrCodeThreshold: 1
ErrFrameNotification: disable
ErrFramePeriod: 1
ErrFrameSecondNotification: disable
Hold Up Time: 0
ThresholdEvtTriggerErrDown: enable
TriggerIfDown: enable
Remote MAC: 0018-8200-0001
Remote MaxSize: 128
Remote State: --
5.7 Configuring Association Between an EFM OAM Session

and an Interface (Triggering the Physical Status of the
Interface Associated with the EFM OAM Session to Become
Down)
After the association between an EFM OAM session and an interface is configured in the OAM
management view, the local EFM OAM session detects a fault and then notifies the OAM
management module of the fault. This triggers the physical status of the interface associated
with the EFM OAM session to become Down. In addition, when the physical status of an
interface becomes Down, the OAM management module notifies the EFM OAM session of the
fault. The EFM OAM session can then send fault information to the remote device.

Before configuring the association between an EFM OAM session and an interface, you must
enable EFM OAM globally on each device and enable EFM in the interface view of each
outgoing interface.
As shown in Figure 5-4, EFM OAM is enabled on PE1 and PE2. When a fault occurs on a link
between PEs, a CE needs to detect the fault to ensure reliable service transmission. In this case,
the associations between EFM OAM sessions and interfaces can be configured. Take PE2 as an

example. When an EFM OAM session detects a link fault, the EFM OAM session on PE2 notifies
the OAM management module of the fault. This triggers the physical status of GE 1/0/2
associated with the EFM OAM session to become Down. CE2 can then detect the fault and
switch traffic to a backup path, which ensures reliable service transmission.
Figure 5-4 Networking diagram of the association between an EFM OAM session and an
interface
PE1 EFM OAM PE2
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
CE1 CE2
Interface associated with EFM OAM
Interface enabled with EFM OAM
If the bidirectional association between an EFM OAM session and an interface is configured on
a PE, when GE 1/0/2 that connects PE2 to CE2 goes Down, the OAM management module
sends fault information to the EFM OAM session associated with GE 1/0/2. EFM OAMPDUs
carrying the fault information are sent to the OAM management module on PE1, which triggers
the physical status of GE 1/0/2 to become Down. CE1 can then detect the fault and switch traffic
to a backup path, which ensures reliable service transmission.
Before configuring the association between an EFM OAM session and an interface (in the OAM
management view), complete the following task:
l 5.3 Configuring Basic EFM OAM
Data Preparation
To configure the association between an EFM OAM session and an interface (in the OAM
management view), you need the following data.
No. Data
1 Type and number of each interface associated with an EFM OAM session
2 Type and number of each interface enabled with EFM OAM

5.7.2 Configuring Association Between an EFM OAM Session and

an Interface
One EFM OAM session is associated with only one interface. That is, when an interface is
associated with an EFM OAM session, the interface cannot be associated with another EFM
OAM session. In addition, when an EFM OAM session is associated with a specified interface,
the EFM OAM session cannot be associated with another interface.
Context
During the configuration of the association between an EFM OAM session and an interface,
Step 3, Step 4, and Step 5 are optional and can be performed as required.
Performing Step 5 is equal to performing Step 3 and Step 4.
Do as follows on the device that needs the association:
Procedure
Step 1 Run:
system-view
Step 2 Run:
oam-mgr
The OAM management view is displayed.
Step 3 Run:
oam-bind ingress efm interface interface-type1 interface-number1 trigger if-down
egress interface interface-type2 interface-number2
The unidirectional transmission of fault information from an EFM OAM session to an interface
is configured.
When the EFM OAM session detects a fault, the physical status of the interface associated with
the EFM OAM session becomes Down.
interface interface-type1 interface-number1 specifies the interface enabled with EFM OAM.
interface interface-type2 interface-number2 specifies the interface associated with the EFM
OAM session.
Step 4 Run:
oam-bind ingress interface interface-type1 interface-number1 egress efm interface
interface-type2 interface-number2 trigger if-down
The unidirectional transmission of fault information from an interface to an EFM OAM session
is configured.
When an interface associated with an EFM OAM session goes Down, the OAM management
module can send fault information to the EFM OAM session associated with the interface, and
then the EFM OAM session sends the fault information to the remote device.
OAM session.

interface interface-type2 interface-number2 specifies the interface enabled with EFM OAM.
Step 5 Run:
oam-bind efm interface interface-type1 interface-number1 trigger if-down interface
interface-type2 interface-number2
The bidirectional transmission of fault information between an EFM OAM session and an
interface is configured.
interface interface-type1interface-number1 specifies the interface enabled with EFM OAM.
OAM session.
NOTE
If Step 5 is performed, both the oam-bind ingress efm interface md-name ma ma-name trigger if-
down egress interface interface-type interface-number command and the oam-bind ingress interface
interface-type interface-number egress cfm md md-name ma ma-name trigger if-down command are
displayed in the configuration file, indicating fault notification in opposite directions.
----End

After the association between an EFM OAM session and an interface is successfully configured,
you can view the association configuration in the OAM management view.
Prerequisites
All configurations of the association between an EFM OAM session and an interface are
complete.
Procedure
Step 1 Run the display this command in the OAM management view to check whether an EFM OAM
session and an interface are successfully associated.
----End
Example
Run the display this command. You can view all associations between EFM OAM sessions and
interfaces.
[Quidway-oam-mgr] display this
#
oam-mgr
oam-bind ingress interface GigabitEthernet1/0/1 egress efm interface
GigabitEthernet1/0/2 trigger if-down
oam-bind ingress efm interface GigabitEthernet1/0/2 trigger if-down egress
#
return
5.8 Configuring Association Between EFM OAM Sessions

Association between EFM OAM sessions is applicable to the networking where two interfaces
on a device are enabled with EFM OAM. When an EFM OAM session detects a link fault on

an interface of a device, the local EFM OAM session notifies the OAM management module of
the fault. The OAM management module sends fault information to the EFM OAM session on
the remote device through a corresponding outgoing interface. Then, the remote EFM OAM
session notifies the OAM management module on the remote device of the fault. In this manner,
the remote device is notified of the fault.

Before configuring the association between EFM OAM sessions, you must enable the specified
interfaces with EFM OAM.
EFM OAM detects the link between directly-connected devices. As shown in Figure 5-5, EFM
OAM is enabled on Switch 1 and Switch 2, and Switch 3. When a fault occurs on the link between
Switch 2 and Switch 3, Switch 1 needs to detect the fault to ensure reliable service transmission.
In this case, you can configure the association between EFM OAM sessions. When the EFM
OAM session between Switch 2 and Switch 3 detects a link fault, the EFM OAM session on
Switch 2 notifies the OAM management module of the fault. The OAM management module
sends fault information to the remote EFM OAM session through GE 1/0/3. Then, the remote
EFM OAM session notifies Switch 1 of the fault. In this manner, the fault information is
transmitted between EFM OAM sessions, and traffic can be switched to a backup path, which
ensures reliable service transmission.
Figure 5-5 Networking diagram of the association between EFM OAM sessions
Before configuring the association between EFM OAM sessions, complete the following task:
Data Preparation
To configure the association between EFM OAM sessions, you need the following data.
No. Data
1 Type and number of each interface enabled with EFM OAM

5.8.2 Configuring Association Between EFM OAM Sessions

Two EFM OAM sessions can be associated with each other only. That is, when two EFM OAM
sessions are associated with each other, neither of them can be associated with another EFM
OAM session.
Context
During the configuration of the association between EFM OAM sessions, Step 3, and Step 4 are
optional and can be performed as required.
Procedure
Step 1 Run:
system-view
Step 2 Run:
oam-mgr
Step 3 Run:
oam-bind ingress efm interface interface-type interface-number egress efm
The unidirectional transmission of fault information from one EFM OAM session to the other
EFM OAM session is configured.
Step 4 Run:
oam-bind efm interface interface-type interface-number efm interface interface-
type interface-number
The bidirectional transmission of fault information between two EFM OAM sessions is
configured.
NOTE
If Step 4 is performed, two oam-bind ingress efm interface interface-type interface-number egress efm
interface interface-type interface-number commands are displayed in the configuration file, indicating
fault notification in opposite directions.
----End

After the association between EFM OAM sessions is successfully configured, you can view the
association configuration in the OAM management view.
Prerequisites
All configurations of the association between EFM OAM sessions are complete.

Procedure
l Run the display this command in the OAM management view. You can view whether the
association between EFM OAM sessions is configured.
#
oam-mgr
oam-bind ingress efm interface GigabitEthernet1/0/1 egress efm interface
oam-bind ingress efm interface GigabitEthernet1/0/2 egress efm
interfaceGigabitEthernet1/0/1
#
return
----End
5.9 Configuring Basic Ethernet CFM

By configuring basic Ethernet CFM functions, you can implement end-to-end detection,
advertisement, verification, and location of connectivity faults.

Before configuring basic Ethernet CFM functions, familiarize yourself with the applicable
CFM is mainly used to monitor the connectivity of end-to-end links or direct links.
As shown in Figure 5-6, the Layer 2 network is connected to the Layer 3 network through PE3.
l CFM can be deployed to monitor the link connectivity between Layer 2 network devices,
for exmaple, between the CE and PE1 and between PE1 and PE2.
l CFM can be deployed to monitor the link connectivity between a Layer 2 network device
and a device connecting the Layer 2 network to the Layer 3 network, such as the link
connectivity between the CE and PE3 and between PE2 and PE3.
Figure 5-6 Schematic diagram of the CFM function
CE PE1 P PE2 PE3
IP Core
CFM CFM CFM
CFM
MEP
MIP

You need to ensure that the following conditions be met before implementing automatic end-
to-end connectivity detection on the Ethernet:
l MDs are classified based on the ISP that manages the devices. All the devices that are
managed by a single ISP and enabled with CFM can be configured in an MD.
One default MD can be configured on each device, that it transmits high-level CCMs and
generates MIPs to reply LTR packets.
l MAs are classified based on different SIs. An MA is associated with a VLAN. A VLAN
generally maps to an SI. When the MA is classified, fault detection in connectivity can be
carried out on the network where an SI is transmitted.
l You need to determine the interfaces on which devices are located at the edge of the MA,
that is, to determine that MEPs must be configured on the interfaces on which devices.
When implementing automatic connectivity detection on directly connected links, you also need
to ensure that:
l The devices at both ends must be configured in the same MA within an MD.
l An MA can be either associated with a VLAN or not.
l MEPs must be configured on the interfaces at both ends of the directly connected link.
None.
Data Preparation
To configure Ethernet CFM, you need the following data.
No. Data
1 Name and level of an MD
2 (Optional) Name and level of a default MD
3 Name of an MA, ID of the VLAN associated with the MA
4 ID of a MEP, name of the interface on which the MEP resides, type of the MEP
5 (Optional) ID of an RMEP and MAC address of the interface where the RMEP resides
6 Rule for creating a MIP
7 Interval for a MEP sending or detecting CCMs in an MA
8 (Optional) ID of the specified VLAN
5.9.2 Enabling Ethernet CFM Globally

You must enable Ethernet CFM globally before configuring and applying all CFM functions.
Context
Do as follows on the switch that requires Ethernet CFM:

Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm enable
Ethernet CFM is enabled globally.

By default, Ethernet CFM on the switch is disabled globally.
----End
5.9.3 Creating an MD
An MD refers to a network or a part of a network under the management of Ethernet CFM. One
MD is managed by a single ISP.
Context
Do as follows on the switch that requires Ethernet CFM:
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name [ format { no-md-name | dns dns-md-format-name | mac-address mac-md-
format-name | string string-md-format-name } ] [ level level ]
An MD is created and the MD view is displayed.

Parameters format, no-md-name, dns dns-md-format-name,mac-address mac-md-format-
name and string string-md-format-name can be used only on the device running IEEE Standard
802.1ag-2007.
By default, an MD is at level 0. Level 0 is the lowest level.
Repeat Step 2 to create more MDs. Up to 64 MDs can be created on the S9700.
NOTE
The 802.1ag packets from a lower-level MD are discarded when being transmitted through the same level
MD or a higher-level MD. The 802.1ag packets from a higher-level MD can be transmitted through a lower-
level MD.
----End
5.9.4 (Optional) Creating the Default MD

The default MD must be of a higher level than all MDs to which MEPs on the local device
belong. In addition, the default MD must be of the same level as the high-level MD. The high-
level CCMs are transmitted through the default MD.

Context
Do as follows on each S9700 device that requires Ethernet CFM:
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm default md [ level level ]
The default MD is created and the default MD view is displayed.

By default, the default MD is at Level 7, the highest level.
Each device can create only one default MD.
NOTE
The default MD must be of a higher level than all MDs to which MEPs configured on the local device
belong. In addition, the default MD must be of the same level as the high-level MD. The default MD
transmits high-level CCMs and generates MIPs to reply LTR packets.
----End
5.9.5 Creating an MA
An MD can be divided into one or multiple MAs. Ethernet CFM detects connectivity of each
MA separately.
Context
Do as follows on the S9700 that requires Ethernet CFM:
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name
The MD view is displayed.

Step 3 Run:
ma ma-name [ format { icc-based iccbased-ma-format-name | string ma-format-name }]
An MA is created and the MA view is displayed.

You can create a maximum of 4K MAs in an MD of S9706 or S9712. You can create a maximum
of 4K MAs on an S9706 or S9712.
You can create a maximum of 2K MAs in an MD of S9703. You can create a maximum of 4K
MAs on an S9703.

One or multiple MA can map to one VLAN.
Step 4 Perform the following step as needed.

l (Optional) If an MA is created on a Layer 2 device, run: map vlan vlan-id. The MA is
associated with a VLAN.
NOTE
l An AM is not associated with any VLAN by default.

l Ethernet CFM monitors the connectivity of links in each MA. Associating an MA with a VLAN
allows Ethernet CFM to monitor the connectivity of the VLAN.
l An MA used to monitor the connectivity between two directly connected devices does not need to
be associated with a VLAN. An MA used to monitor the connectivity of two indirectly connected
devices must be associated with a VLAN.
l When creating a MEP on a device connecting the Layer 2 network to the Layer 3 network,
specify a VLAN. The VLAN is automatically associated with the MA. For details, see the
section "Creating a MEP."
----End
Follow-up Procedure
An MA is associated with a VLAN only.
l If you need to create multiple MAs in an MD, repeat Step 3 and Step 4.
l If you need to create multiple MAs in multiple MDs, repeat Step 2 to Step 4.
5.9.6 Creating a MEP

A MEP is an edge node of an MA. It is configured on an interface manually.
Context
When creating a MEP in an MA, pay attention to the following points:
l When creating an inward MEP, ensure that the MA has been associated with a VLAN and
the interface on which the MEP is located has been added to the VLAN. An inward MEP
sends 802.1ag packets through all the interfaces in the VLAN associated with the MA
except the interface on which the MEP is located. That is, an inward MEP broadcasts
802.1ag packets in the VLAN associated with the MA.
l Protocol packets sent from the outward MEP are forwarded by this interface.
The requirements for the MEPs created in an MA on the same S9700 are as follows:
l The inward MEP and outward MEP are mutually exclusive.

l Only one outward MEP can be created. Multiple inward MEPs can be created, but only
one inward MEP can be created on an interface.
Do as follows on the edge devices of an MA.
Procedure
Step 1 Run:
system-view


Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name
The MA view is displayed.

Step 4 Run:
mep mep-id mep-id interface interface-type interface-number [ vlan vlan-id | pe-
vid pe-vid ce-vid ce-vid ] { inward | outward }
A MEP is created on an interface.
----End
Follow-up Procedure
Perform the preceding steps as required:
l To create multiple MEPs in an MA, repeat Step 4.
l To create MEPs in multiple MAs, repeat Step 3 and Step 4.
l To create MEPs in multiple MDs, repeat Step 2 to Step 4.
5.9.7 Creating an RMEP

For other devices in the same MA, their MEPs are RMEPs for the local device. By configuring
an RMEP, you can perform connectivity fault detection between the local MEP and the RMEP
in one MA.
Context
If you need to detect the connectivity between a device and an RMEP, you need to create the
RMEP first.
Do as follows on the edge devices of an MA:
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name

Step 4 Run:
remote-mep mep-id mep-id [ mac mac-address ]
An RMEP in the current MA is created.
----End
Follow-up Procedure
l If you need to create multiple RMEPs in an MA, repeat Step 4.
l If you need to create multiple RMEPs in multiple MAs, repeat Step 3 and Step 4.
l If you need to create multiple RMEPs in multiple MDs, repeat Step 2 to Step 4.
5.9.8 (Optional) Setting the MIP Creation Rule
Context
Do as follows on each S9700 where Ethernet CFM needs to be configured.
Procedure
Step 1 Run:
system-view
Step 2 run:
Run:
cfm md md-name [ format { no-md-name | dnsname-and-mdname | mac-address | md-
name } ] [ level level ]
Or, run:
The default MD view is displayed.
You can choose either view.
Step 3 Run:
mip create-type { default | explicit | none }
The MIP creation rule is set.
By default, the global MIP creation rule is none. An interface creates MIPs according to the
global MIP creation rule. If the MIP creation rule is set on an interface, the rule set on the interface
takes effect. The rule is classified into the following types:
l default: A MIP can be created on an interface if neither a MEP of a higher level nor a MIP
of a lower level is configured on the interface.
l explicit: A MIP cannot be created on an interface if no MEP of a lower level exists. A MIP
can be created on an interface if neither a MEP of a higher level nor a MIP of a lower level
exists.
l none: No MIP can be created on an interface.

If the MIP creation rule is default or explicit, a device creates a MIP automatically according
to the rule.
----End
5.9.9 Enabling CC Detection

Through the CC detection, Ethernet CFM can periodically send CCMs between MEPs to detect
connectivity between MEPs.
Context
Do as follows on the edge devices on which MEPs reside within MAs:
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name

Step 4 Run:
ccm-interval interval
The interval for the MEP sending or detecting CCMs within the local MA is set.
By default, the interval for the MEP sending or detecting CCMs within an MA is 1 second.
l The sending of CCMs is enabled by using the mep ccm-send enable command.
l The receiving of CCMs is enabled by using the remote-mep ccm-receive enable command.
If any of the preceding conditions is met in an MA, the interval for sending or detecting CCMs
in the MA cannot be modified. If you want to modify the interval for sending or detecting CCMs
in an MA, you must run the related undo commands to disable the sending or receiving of CCMs.
Step 5 Run:
mep ccm-send [ mep-id mep-id ] enable
The sending of CCMs is enabled on the MEP.

By default, a MEP is disabled to send CCMs.
If mep-id mep-id is not specified, all the MEPs in the MA are enabled to send CCMs.
Step 6 Run:
remote-mep ccm-receive [ mep-id mep-id ] enable
The receiving of CCMs from the RMEP within the same MA is enabled on the local MEP.
By default, the local MEP cannot receive CCMs from the RMEP.

When the local device is enabled to receive CCMs from an RMEP, and if connectivity faults are
detected between the local device and the RMEP through CC detection, the local device prompts
alarms of RMEP connectivity.
If mep-id mep-id is not specified, all the MEPs in the MA are enabled to receive CCMs from
all the RMEPs.
----End
Follow-up Procedure
l If you need to enable the CC detection in multiple MAs, repeat Step 3 to Step 6.
l If you need to enable the CC detection in multiple MDs, repeat Step 2 to Step 6.
5.9.10 (Optional) Creating a VLAN

Through the association between a VLAN and default MDs, all interfaces of the specified VLAN
can generate MIPs based on default MDs.
Context
Do as follows on each device:
Procedure
Step 1 Run:
system-view

Step 2 Run:
The default MD is created and the default MD view is displayed.

Step 3 Run:
vlan { vlan-id1 [ to vlan-id2 ] }&<1-10>
The specified VLAN is created.
----End

Prerequisites
The configurations of basic functions of Ethernet CFM are complete.
Procedure
l Run the display cfm md [ md-name ] command to check the configuration of an MD.
l Run the display cfm ma [ md md-name [ ma ma-name ] ] command to check detailed
information about an MA.
l Run the display cfm mep [ md md-name [ ma ma-name [ mep-id mep-id ] ] ] command
to check detailed information about a MEP.

l Run the display cfm remote-mep md md-name ma ma-name [ mep-id mep-id ] or display
cfm remote-mep [ md md-name [ ma ma-name ] ] [ cfm-state { up | down | disable } ]
command to check detailed information about an RMEP.
l Run the display cfm mip [ interface interface-type interface-number | level level ]
command to check information about a MIP.
----End
Example
If an MD is created successfully, you can view the MD and the level of the MD after running
the display cfm md command.
<Quidway> display cfm md md1
MD Name : md1
MD Name Format : string
Level : 0
MIP Create-type : none
SenderID TLV-type : defer
MA list :
MA Name : ma1
MA Name Format : string
Interval : 1000
Vlan ID : 10
VSI Name : --
L2VC ID : --
MA Name : ma
MA Name Format :
string
Interval : 1000
Vlan ID : --
VSI Name : --
L2VC ID :
--
# Display information about the MEP with the ID being 10 in ma1 of md1.
<Quidway> display cfm mep md md1 ma ma1 mep-id 10
MD Name : md1
MD Name Format : md-name
Level : 0
MA Name : ma1
MEP ID : 11
Vlan ID : 221
VSI Name : --
Interface Name : GigabitEthernet1/0/1
CCM Send : disabled
Direction : inward
MAC Address : 0018-2000-0083
Run the display cfm remote-mep command. If information about the RMEP is displayed, it
indicates that the configuration is successful.
<Quidway> display cfm remote-mep
The total number of RMEPs is : 2
The status of RMEPS : 2 up, 0 down, 0 disable
--------------------------------------------------
MD Name : md2
Level : 7
MA Name : ma3
RMEP ID : 110
Vlan ID : 20
VSI Name : --
MAC : 0000-0121-0222
CCM Receive : enabled
Trigger-If-Down : disabled

CFM Status : up
Alarm Status : None
MD Name : md2
Level : 4
MA Name : ma3
RMEP ID : 30
Vlan ID : --
VSI Name : --
MAC : --
CFM Status : up
Alarm Status : None
Run the display cfm mip command. If information about the MIP is displayed, the configuration
is successful.
<Quidway> display cfm mip
Interface Name Level
-----------------------------------
GigabitEthernet1/0/1GigabitEthernet0/0/1 0
5.10 Configuring Related Parameters of Ethernet CFM

By adjusting parameters of Ethernet CFM, you can detect connectivity of an Ethernet network
from end to end.

Before configuring parameters of Ethernet CFM, familiarize yourself with the applicable
Application Environment
If Ethernet CFM is enabled, you can adjust related parameters according to your requirement.
In different application environments, you can adjust the following parameters:
l RMEP activation time

After the local device is enabled with the function of receiving CCMs from a certain RMEP,
the local device can display RMEP connectivity alarm in one of the following situations:
If the CC detects a connectivity fault between the local MEP and the RMEP, then, the
local device displays the alarm of the RMEP connectivity fault..
The physical link works normally between the local MEP and the RMEP. The peer
device is not configured with a MEP when the CC is performed; or, the MEP
configuration is performed after the CC is performed. In this case, if the local MEP does
not receive any CCMs from the RMEP in three consecutive sending intervals, the local
device considers that a connectivity fault occurs between the local MEP and the RMEP.
According to the preceding description, the RMEP connectivity fault alarm is incorrect.
To solve the problem, you can set the RMEP activation time.
If the local device is configured with the RMEP activation time and enabled with the
function of receiving CCMs from a certain RMEP, the local device can receive CCMs at
the set RMEP activation time. That is, the activation time for receiving CCMs from the
RMEP is the time reserved for configuring the RMEP.

At the set RMEP activation time, if the local MEP does not receive any CCMs in three
consecutive sending intervals, this means that a connectivity fault occurs between the local
MEP and the RMEP. In addition, the local device displays the alarm of the RMEP
connectivity fault.
l Anti-jitter time during alarm restoration
All the RMEPs of each MA use the following timers:
Alarm generation timer: Its interval is set to the anti-jitter time during alarm generation.
Alarm restoration timer: Its interval is set to the anti-jitter time during alarm restoration.
When the RMEP detects an alarm, the alarm generation timer is activated. After the timer
expires, the alarm is notified to the device. When the RMEP detects that the alarm is
restored, the alarm restoration timer is activated. After the timer expires, the alarm
restoration event is notified to the device.
If the RMEP frequently detects the alarm and alarm restoration signals, this means that
alarm flapping occurs.
To suppress alarm flapping, you can set the anti-jitter time during alarm generation.
l VLAN or VLAN chain
All interfaces of the specified VLAN generate MIPs according to the configured MIP
generation rule in the MD.
None.
Data Preparation
To adjust parameters of Ethernet CFM, you need the following data.
No. Data
1 (Optional) RMEP activation time
2 (Optional) Anti-jitter time during alarm restoration
3 (Optional) Anti-jitter time during alarm generation
5.10.2 (Optional) Configuring the RMEP Activation Time

The RMEP activation time is reserved for you to configure an RMEP. After the configuration
of the RMEP activation time, the local device can receive CCMs after the configured RMEP
activation time expires.
Context
Do as follows on each edge device in an MA:
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name
Step 3 Run:
ma ma-name
Step 4 Run:
active time time
The RMEP activation time is configured.
----End
5.10.3 (Optional) Configuring the Anti-Jitter Time During Alarm

Restoration
By configuring the anti-jitter time during alarm restoration, you can suppress alarm flapping.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
cfm md md-name
Step 3 Run:
ma ma-name
Step 4 Run:
alarm finish time time
The anti-jitter time during alarm restoration is configured.
----End
5.10.4 (Optional) Configuring the Anti-Jitter Time During Alarm

Generation
By configuring the anti-jitter time during alarm restoration, you can suppress the alarm flapping.

Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
cfm md md-name
Step 3 Run:
ma ma-name
Step 4 Run:
alarm occur time time
The anti-jitter time during alarm generation is configured.
----End
5.11 Fault Verification on the Ethernet

By sending detection packets and waiting for replies, you can test connectivity of the path
between devices.
When you need to check connectivity between two devices manually, you can configure the
local device to send test packets and wait response packets on the local device to check whether
the remote device is reachable. Based on the type of the link to be tested, you can adopt the
following methods to check the link connectivity:
l To check connectivity of the link between MEPs or between a MEP and a MIP in the same
MA on a network with MDs, MAs, and MEPs, use 802.1ag MAC ping.
l To check connectivity of the link between two devices on a network without MDs, MAs,
and MEPs, use Gmac ping.
Before performing 802.1ag MAC ping, complete the following task:
l Configuring Basic Functions of Ethernet CFM

Data Preparation
To test connectivity of the Ethernet, you need the following data.
No. Data
1 (Optional) MAC address or ID of the destination MEP
2 (Optional) MAC address of the destination MIP
3 (Optional) Number, size, timeout period, and outgoing interface of MAC ping packets
4 (Optional) VLAN that the destination node belongs to
5.11.2 (Optional) Implementing 802.1ag MAC Ping

By performing the 802.1ag MAC ping, you can detect connectivity between MEPs or between
MEPs and MIPs within an MA.
Context
Similar to the ping operation, 802.1ag MAC ping checks whether the destination device is
reachable by sending test packets and receiving response packets. In addition, the ping operation
time can be calculated at the transmitting end for network performance analysis.
Procedure
Step 1 A device is usually configured with multiple MDs and MAs. To precisely detect the connectivity
of a link between two or more devices, perform either of the following operations on the
switch with a MEP at one end of the link to be tested.
l MA view:
1. Run:
system-view

2. Run:
cfm md md-name

3. Run:
ma ma-name

4. Run:
ping mac-8021ag mep mep-id mep-id { md md-name ma ma-name [ mac mac-
address | remote-mep mep-id mep-id ] | mac mac-address | remote-mep mep-id
mep-id } [ -c count | interface interface-type interface-number | -s
packetsize | -t timeout | -p priority-value ] *
The connectivity between a MEP and a MEP or a MIP on other devices is tested.
l All views except the MA view:
Run:

ping mac-8021ag mep mep-id mep-id md md-name ma ma-name { mac mac-address |

remote-mep mep-id mep-id } [ -c count | interface interface-type interface-
number | -s packetsize | -t timeout | -p priority-value ] *
The connectivity between a MEP and a MEP or a MIP on other devices is tested.
When implementing 802.1ag MAC ping, ensure that:
l The MA is associated with a VLAN.

l The MEP is configured in the MA.
l If the outbound interface is specified, it cannot be configured with an inward-facing MEP.
The interface must be added to the VLAN associated with the MA.
l If the destination node is a MEP, either mac mac-address or remote-mep mep-id mep-id
can be selected. If remote-mep mep-id mep-id is selected, the RMEP must already be created
with the remote-mep command.
l If the destination node is a MIP, select mac mac-address.
The intermediate device on the link to be tested only forwards LBMs and LBRs. In this manner,
the MD, MA, or MEP are not required to be configured on the intermediate device.
----End
5.11.3 (Optional) Implementing Gmac ping

By performing the Gmac ping, you can detect connectivity between devices.
Context
Perform Step 1 and Step 2 on the switchs at both ends of the link to be tested. Perform Step 3
on any of the switchs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ping mac enable
Gmac ping is enabled globally.
By default, Gmac ping is disabled.
When Gmac ping is enabled:
l MAC ping can be implemented on the switchs.

l The switchs can respond to LBMs.
Step 3 Run:
ping mac mac-address vlan vlan-id [ interface interface-type interface-number | -c
count | -s packetsize |-t timeout | -p priority-value ] *
The connectivity between the switch and the remote device is tested.

A MEP is not required to initiate Gmac ping. The destination node does not need to be a MEP
or a MIP. Gmac ping can be implemented without configuring the MD, MA, or MEP on the
source device, the intermediate device, and the destination device.
The two devices must be enabled with 802.1ag of the same version. If the local device is enabled
with IEEE 802.1ag Draft 7 and the peer is enabled with IEEE Standard 802.1ag-2007, the local
device cannot ping through the peer device when the ping mac command is run to detect
connectivity of the link between the local and peer devices.
----End
5.12 Locating the Fault on the Ethernet

By sending test packets and waiting for a reply, you can test connectivity of the path between
devices and locate faults.
By sending test packets on the local device and checking the received response packets, you can
check the reachability of the path from the local device to the destination device and locate the
faulty node on the path. You can use different methods according to the type of the link to be
tested:
l To locate faults on the link between MEPs or between a MEP and a MIP in the same MA
on a network where MDs, MAs, and MEPs are configured, use 802.1ag MAC trace.
l To locate faults on the link between two devices on a network where MDs, MAs, or MEPs
are not configured, use the Gmac trace.
Before performing 802.1ag MAC trace, complete the following task:
l Configuring Basic Ethernet CFM Functions
Data Preparation
To perform 802.1ag MAC trace, you need the following data.
No. Data
1 (Optional) MAC address or ID of the destination MEP
2 (Optional) MAC address of the destination MIP
3 (Optional) Outbound interface of MAC trace packets
4 (Optional) Timeout interval for waiting for a response packet
5 (Optional) Maximum number of hops of trace packets
6 (Optional) VLAN that the destination node belongs to

5.12.2 (Optional) Implementing 802.1ag MAC Trace

By performing the 802.1ag MAC trace, you can detect connectivity between MEPs or between
MEPs and MIPs within an MA and locate faults.
Context
Similar to tracerout or tracert, 802.1ag MAC trace tests the path between the local device and a
destination device or locates failure points by sending test packets and receiving reply packets.
Procedure
Step 1 A device is usually configured with multiple MDs and MAs. To determine the forwarding path
for sending packets from a MEP to another MEP or a MIP in an MA or failure points, perform
either of the following operations on the switch with a MEP at one end of the link to be tested.
l MA view
1. Run:
system-view

2. Run:
cfm md md-name

3. Run:
ma ma-name

4. Run:
trace mac-8021ag mep mep-id mep-id { md md-name ma ma-name { mac mac-
address | remote-mep mep-id mep-id } | mac mac-address | remote-mep mep-id
mep-id } [ interface interface-type interface-number | -t timeout | ttl
ttl ] *
The connectivity fault between the local switch and the remote switch is located.
Run the trace mac-8021ag command without md md-name ma ma-name in the MA view
to determine a forwarding path or failure point in a specified MA.
Run the trace mac-8021ag md md-name ma ma-name command in the MA view to
determine a forwarding path or failure point in a specified MA.
l All views except the MA view:
Run:
trace mac-8021ag mep mep-id mep-id md md-name ma ma-name { mac mac-address |
remote-mep mep-id mep-id } [ interface interface-type interface-number | -t
timeout | ttl ttl ] *
The connectivity fault between the switch and the remote switch is located.
When implementing 802.1ag MAC trace, ensure that:
l The MA is associated with a VLAN.

l The MEP is configured in the MA.

l If the outbound interface is specified, it cannot be configured with an inward-facing MEP.

The interface must be added to the VLAN associated with the MA.
l If the destination node is a MEP, either mac mac-address or remote-mep mep-id mep-id
can be selected. If remote-mep mep-id mep-id is selected, the RMEP must already be created
with the remote-mep command.
l If the destination node is a MIP, select mac mac-address.
l If the forwarding entry of the destination node does not exist in the MAC address table,
interface interface-type interface-number must be specified.
The intermediate device on the link to be tested only forwards LTMs and LTRs. In this manner,
the MD, MA, or MEP are not required to be configured on the intermediate device.
----End
5.12.3 (Optional) Implementing Gmac trace

By performing the GMAC trace, you can detect connectivity between devices and locate faults.
Context
You need to configure the switchs at both ends and the intermediate switch on the link to be
tested.
Procedure
Step 1 Configuring the switchs at both Ends and the Intermediate switch
Do as follows on the switchs at both ends and the intermediate switch on the link to be tested:
1. Run:
system-view

2. Run:
trace mac enable
Gmac trace is enabled globally.

By default, Gmac trace is disabled.
The following can be performed only after Gmac trace is enabled:
l Gmac trace can be implemented on the switch.
l The switchs can respond to LTMs of Gmac trace.
Step 2 Implementing Gmac trace
Do as follows on the switch at one end of the link to be tested:
1. Run:
system-view

2. Run:
trace mac mac-address vlan vlan-id [ interface interface-type interface-
number | -t timeout ] *

The connectivity fault between the switch and the remote switch is located.
A MEP is not required to initiate Gmac trace. The destination node does not need to be a
MEP or a MIP. Gmac trace can be implemented without configuring the MD, MA, or MEP
on the source device, the intermediate device, and the destination device.
The two devices must be enabled with 802.1ag of the same version. If the local device is
enabled with IEEE 802.1ag Draft 7 and the peer device is enabled with IEEE Standard
802.1ag-2007, the faulty node cannot be located when the trace mac command is run to
detect connectivity of the link between the local and peer devices.
----End
5.13 Configuring Association Between Ethernet CFM and an

Interface
The association between Ethernet CFM and an interface is used to detect faults of an active link
in the LACP static link aggregation group or in the manually-configured 1:1 active/standby link
aggregation group and then trigger the protection switchover.
After association between an Ethernet CFM module and an interface is configured, if a MEP
detects a connectivity fault between the MEP and a specified RMEP in the same MA, the OAM
management module blocks and then unblocks the interface where the MEP is located so that
other modules can detect the fault.
Figure 5-7 Application scenario of association between an Ethernet CFM module and an
interface (1)
Ethernet CFM
GE1/0/1 GE2/0/1 GE1/0/1 GE2/0/1

SwitchA SwitchC SwitchB
The interface associated with Ethernet CFM

interface (2)
Ethernet CFM
GE1/0/1 Link1 GE1/0/1
GE1/0/2 Link2 GE1/0/2
SwitchA SwitchB
Link3
GE1/0/3 GE1/0/3
Active link
Inactive link MEPs in MA1
MEPs in MA2
Aggregation group in MEPs in MA3
static LACP mode
Figure 5-7 and Figure 5-8 show the application of CFM on a direct link and a multi-hop link
respectively. Ethernet CFM is configured between SwitchA and SwitchB, and the Ethernet CFM
module is associated with GE 1/0/1 of SwitchA. When the CFM OAM module on SwitchA
detects a connectivity fault between SwitchA and SwitchB, the OAM management module
blocks and then unblocks GE 1/0/1 so that the other interfaces on SwitchA can detect the fault.
interface (3)
SwitchC
GE2/0/1 GE2/0/2
M Ethe
rn et C F rn et C
GE1/0/1 Ethe FM GE1/0/1
Eth-Trunk1 Eth-Trunk1
SwitchA SwitchB
rnet C
CFM rnet
Ethe
GE2/0/1 GE2/0/2
SwitchD
Aggregation group in 1:1 Active link MEPs in MA1
active/standby mode Inactive link MEPs in MA2
MEPs in MA3
MEPs in MA4
A link aggregation group (LAG) in static LACP mode is configured on SwitchA and SwitchB.
Ethernet CFM is enabled on SwitchA and SwitchB; SwitchA and SwitchB belong to the same
MD; MEPs are configured on all the member interfaces of the LAG; MEPs on the interfaces of
the same link belong to the same MA; MEPs on interfaces on different links belong to different
MAs. MEPs at both ends of a link send CCMs to check connectivity of the link. The association
between an Ethernet CFM module and an interface is configured.
When a connectivity fault occurs on Link1, the OAM modules on SwitchA and SwitchB block
and unblock their GE 1/0/1 interfaces respectively. In this manner, the LACP module detects

the connectivity fault on Link1 and switches the service data from Link1 to the inactive Link3.
This implements protection switching within 50 ms to achieve carrier-class reliability.
interface (4)
SwitchC
GE2/0/1 GE2/0/2
CFM Ethe
rnet rn et C
Eth-Trunk1 Eth-Trunk1
SwitchA SwitchB
Ethe
GE1/0/2 rnet CFM GE1/0/2
CFM rnet
Ethe
GE2/0/1 GE2/0/2
SwitchD
Aggregation group in 1:1 Active link MEPs in MA1
active/standby mode Inactive link MEPs in MA2
MEPs in MA3
MEPs in MA4
An LAG in 1:1 backup mode is configured on SwitchA and SwitchB. Ethernet CFM is
configured between SwitchA and SwitchC, SwitchA and SwitchD, SwitchB and SwitchC, and
SwitchB and SwitchD. The Ethernet CFM modules are associated with GE 1/0/1 and GE
1/0/2 respectively on SwitchA and SwitchB.
When a connectivity fault occurs on the link between SwitchA and SwitchC, the Ethernet CFM
module detects the fault and reports the fault to the OAM management module. The OAM
management module blocks and then unlocks GE 1/0/1. Then the LAG detects the fault and
switches data to the inactive link. The process of handling faults on other links is similar to that
on the link between SwitchA and SwitchC. This implements protection switching within 50 ms
to achieve carrier-class reliability.
Before configuring association between an Ethernet CFM module and an interface, complete
the following tasks:
l Link Aggregation Configuration

l 5.9 Configuring Basic Ethernet CFM
Data Preparation
To configure association between an Ethernet CFM module and an interface, you need the
following data.
No. Data
1 Type and number of an interface

No. Data
2 Names of the MD and MA and ID of the RMEP
5.13.2 Associating Ethernet CFM with an Interface

Through the configured association between Ethernet CFM and an interface, a MEP in a
specified MA can detect a connectivity fault between the MEP and a specified RMEP within
the same MA. Then, the OAM module blocks and then unblocks the interface on which the MEP
resides so that other modules can sense the fault.
Context
Do as follows on the S9700 configured with the link aggregation group in static LACP mode:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of a member interface of the link aggregation group is displayed.
Step 3 Run:
cfm md md-name ma ma-name remote-mep mep-id mep-id trigger if-down
Ethernet CFM is associated with an interface.
By default, an interface is not associated with Ethernet CFM.
It is required that outward-facing MEPs be created in the specified MA and the current interface
is configured with outward-facing MEPs before you use the cfm md md-name ma ma-name
remote-mep mep-id mep-id trigger if-down command.
An interface can be associated with an RMEP only. You need to delete the current configurations
to modify the mapping between the interface and the RMEP.
If multiple member interfaces exist in the link aggregation group, you should repeat Step 2 and
Step 3 to associate Ethernet CFM with all the member interfaces.
----End

By viewing the Trigger-If-down field, you can check whether the configurations are successful.
Prerequisites
The configurations of Associating Ethernet CFM with an Interface function are complete.

Procedure
Step 1 Run the display cfm remote-mep [ md md-name [ ma ma-name [ mep-id mep-id ] ] ] command
to check detailed information about an RMEP.
----End
Example
Run the display cfm remote-mep command. If the "Trigger If-down" field for the RMEP is
displayed as "enable", it means that the configuration succeeds.
<Quidway> display cfm remote-mep
--------------------------------------------------
MD Name : md110
Level : 0
MA Name : ma110
RMEP ID : 2
VLAN ID : --
VSI Name : --
L2VC ID : 110 tagged
MAC : 0025-9eb1-bce6
CFM Status : down
Alarm Status : RemoteAlarm
5.14 Configuring Association Between Ethernet CFM and an

Interface (Triggering the Physical Status of the Interface
Associated with Ethernet CFM to Become Down)
After the association between Ethernet CFM and an interface is configured in the OAM
management view, local Ethernet CFM can detect a fault and then notify the OAM management
module of the fault. This triggers the physical status of the interface associated with Ethernet
CFM to become Down. In addition, when the physical status of an interface becomes Down, the
OAM management module notifies Ethernet CFM of the fault, and Ethernet CFM sends Ethernet
CFM messages carrying fault information to the remote device.

Before configuring the association between Ethernet CFM and an interface, you must enable
Ethernet CFM globally on each device and enable EFM in the interface view of each outgoing
interface.
As shown in Figure 5-11, Ethernet CFM is enabled on PE1 and PE2. When a fault occurs on a
link between PEs, a CE needs to detect the fault to ensure reliable service transmission. In this
case, the associations between Ethernet CFM and interfaces need to be configured. Take PE2
as an example. When detecting a link fault, Ethernet CFM notifies the OAM management
module of the fault on PE2. This triggers the physical status of GE 1/0/2 associated with Ethernet
CFM to become Down. CE2 can then detect the fault and switch traffic to a backup path, which
ensures reliable service transmission.

Figure 5-11 Networking diagram of the association between Ethernet CFM and an interface
PE1 Ethernet CFM PE2
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
CE1 CE2
Interface associated with Ethernet CFM
Interface enabled with Ethernet CFM
If the bidirectional association between Ethernet CFM and an interface is configured on PE2,
the OAM management module sends fault information to Ethernet CFM associated with GE
1/0/2 when GE 1/0/2 goes Down on PE2 connected to CE2. Ethernet CFM messages carrying
fault information are sent to the OAM module on PE1, which triggers the physical status of GE
1/0/2 on PE1 to become Down. CE1 can then detect the fault and switch traffic to a backup path,
which ensures reliable service transmission.
Before configuring the association between Ethernet CFM and an interface (in the OAM
management view), complete the following task:
Data Preparation
To configure the association between Ethernet CFM and an interface (in the OAM management
view), you need the following data.
No. Data
1 Type and number of each interface associated with Ethernet CFM
2 Type and number of each interface enabled with Ethernet CFM
3 Name of an MD and MA
5.14.2 Configuring Association Between Ethernet CFM and an

Interface
Ethernet CFM can be associated with only one interface. When Ethernet CFM is associated with
an interface, it cannot be associated with another interface. In addition, the interface cannot be
associated with Ethernet CFM on another device.

Context
Do as follows on the device that needs the association.
Procedure
Step 1 Run:
system-view

Step 2 Run:
oam-mgr

Step 3 Configure unidirectional or bidirectional transmission of fault information between Ethernet
CFM and an interface. Choose a configuration scheme according to Table 5-1.
Table 5-1 Configuration schemes for Ethernet CFM and interface association
Scenario Configuration Scheme 1 Configuration Scheme 2
Fault Choose either of the following Run the following commands at a

information commands (the two commands have random order (each command
needs to be the same function): configures fault information
transmitted l If you prefer to specify the MD transmission in a single direction):
bidirectional and MA before the interface, use l oam-bind ingress cfm md ma
ly between the following command: egress interface
Ethernet
CFM and an oam-bind cfm md ma trigger if- When Ethernet CFM detects a
interface. down interface fault, the physical status of the
l If you prefer to specify the interface associated with Ethernet
interface before the MD and MA, CFM becomes Down.
use the following command: l oam-bind ingress interface egress
oam-bind interface cfm md ma cfm md ma trigger if-down
trigger if-down When an interface associated with
NOTE Ethernet CFM goes Down, the
After configuring bidirectional OAM management module sends
transmission of fault information, run the fault information to the associated
display current-configuration Ethernet CFM function, and then
command to check the configuration.
Ethernet CFM sends the fault
The command output displays the oam-
bind ingress cfm md ma egress interface message to the remote device.
and oam-bind ingress interface egress
cfm md ma trigger if-down commands,
but does not display the oam-bind cfm
md ma trigger if-down interface or
oam-bind interface cfm md ma trigger
if-down command. The displayed
commands configure reverse
transmission directions of fault
information.

Scenario Configuration Scheme 1 Configuration Scheme 2
Fault Choose either of the following None

information commands according to the
needs to be transmission direction:
transmitted l If fault information needs to be
unidirection transmitted from Ethernet CFM to
ally between the interface, use the following
Ethernet command:
CFM and an
interface. oam-bind ingress cfm md ma
egress interface
l If fault information needs to be
transmitted from the interface to
Ethernet CFM, use the following
command:
oam-bind ingress interface egress
cfm md ma trigger if-down
----End

After the association between Ethernet CFM and an interface is successfully configured, you
can view the related association configuration in the OAM management view.
Prerequisites
All configurations of the association between Ethernet CFM and an interface are complete.
Procedure
Step 1 Run the display this command in the OAM management view to check whether Ethernet CFM
and an interface are successfully associated.
----End
Example
Run the display this command. You can view all associations between Ethernet CFM and
interfaces.
#
oam-mgr
oam-bind ingress interface GigabitEthernet1/0/1 egress cfm md md1 ma ma1 trigger
if-down
oam-bind ingress cfm md md1 ma ma1 trigger if-down egress interface
#
return

5.15 Associating EFM OAM with Ethernet CFM

This section describes how to associate EFM OAM with Ethernet CFM.
IEEE 802.1ah is designed for the last mile of the Ethernet to detect the direct link between a CE
device and a PE device. IEEE 802.1ag is designed for a group of services or certain network
devices to detect faults on the network. It functions between CE devices, PE devices, or CE and
PE devices. As shown in Figure 5-12, EFM OAM runs between CE1 and PE1, and between
CE2 and PE2; Ethernet CFM runs between CE1 and CE2. After Ethernet OAM is associated
with Ethernet CFM, the Ethernet CFM module can detect faults on the link between CE1 and
PE2 and notify CE2.
Figure 5-12 Association between EFM OAM and Ethernet CFM
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
EFM OAM EFM OAM
CE1 CE2
Before associating EFM OAM and Ethernet CFM, complete the following tasks:

Data Preparation
To associate EFM OAM and Ethernet CFM, you need the following data.
No. Data
1 Interface to be associated
2 Name of the MD and MA

5.15.2 Associating EFM OAM with Ethernet CFM

Context
Do as follows on the CE devices.
Procedure
Step 1 Run:
system-view

Step 2 Run:
oam-mgr

Step 3 Run the following command as required.
l Run:
oam-bind cfm md md-name ma ma-name efm interface interface-type interface-number
The EFM OAM and Ethernet CFM modules are configured to send fault messages to each
other.
l Run:
oam-bind ingress efm interface interface-type interface-number egress cfm md md-
name ma ma-name
The EFM OAM module is configured to send fault messages to the Ethernet CFM module.
l Run:
oam-bind ingress cfm md md-name ma ma-name egress efm interface interface-type
interface-number
The Ethernet CFM module is configured to send fault messages the EFM OAM module.
NOTE
After Ethernet OAM is associated with other functional modules,

l If EFM OAM is disabled on an interface, the association between EFM OAM and other functional
modules is deleted.
l If an MA or MD is deleted, the association between Ethernet CFM and other functional modules is
deleted.
NOTE
If you run oam-bind cfm md md-name ma ma-name efm interface interface-type interface-number
command, two records of the oam-bind ingress efm interface interface-type interface-number egress
cfm md md-name ma ma-name and oam-bind ingress cfm md md-name ma ma-name egress efm
interface interface-type interface-number commands are displayed. In the records, the directions where
fault notification messages are transmitted are reverse.
----End

Prerequisites
The Configuration of association between EFM OAM and Ethernet CFM are complete.

Procedure
Step 1 In the OAM management view, run the display this command to check association between
EFM OAM and Ethernet CFM.
[Quidway-oam-mgr]display this
#
oam-mgr
oam-bind ingress efm interface GigabitEthernet1/0/1 egress cfm md md1 ma ma1
oam-bind ingress cfm md md1 ma ma1 egress efm interface GigabitEthernet1/0/1
#
----End
5.16 Configuring Association Between Ethernet CFM and

Ethernet CFM
This section describes how to configure association between Ethernet CFM and Ethernet CFM.

IEEE 802.1ag is designed for a group of services or certain network devices to detect faults on
the network. IEEE 802.1ag is used between CE devices, PE devices, or CE and PE devices. As
shown in Figure 5-13, Ethernet CFM runs between CE1 and PE1, and between CE2 and PE2;
Ethernet CFM runs between CE1 and CE2. After Ethernet CFM is associated with Ethernet
CFM, the Ethernet CFM module can detect faults on the link between CE1 and PE1 and notify
CE2.
Figure 5-13 Networking diagram for configuring association between Ethernet CFM and
Ethernet CFM
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
Ethernet CFM Ethernet CFM
CE1 CE2
Before configuring association between Ethernet CFM and Ethernet CFM, complete the
following task:

Data Preparation
To configure association between Ethernet CFM and Ethernet CFM, you need the following
data.
No. Data
1 Interface to be associated and number of the interface
2 Names of the MD and MA
5.16.2 Configuring Association Between Ethernet CFM and

Ethernet CFM
Context
Do as follows on the devices where association between Ethernet CFM and Ethernet CFM needs
to be configured.
Procedure
Step 1 Run:
system-view
Step 2 Run:
oam-mgr

oam-bind ingress cfm md md-name1 ma ma-name1 egress cfm md md-name2 ma ma-name2
Unidirectional fault transmission is enabled between Ethernet CFM modules at the two ends of
the link.

oam-bind cfm md md-name1 ma ma-name1 cfm md md-name2 ma ma-name2
Bidirectional fault transmission is enabled between Ethernet CFM modules at the two ends of
the link.
Steps 3 to 4 are optional and can be selected as required.
NOTE
After bidirectional transmission of fault messages is configured, the system displays two configuration
records of unidirectional fault message transmission, whose directions are mutually reverse.
----End


Prerequisites
The configurations of association between Ethernet CFM and Ethernet CFM are complete.
Procedure
Step 1 In the OAM management view, run the display this command to check association between
Ethernet CFM and Ethernet CFM.
#
oam-mgr
oam-bind ingress cfm md md1 ma ma1 egress cfm md md1 ma ma2
#
----End
5.17 Configuring Association Between Ethernet CFM and

SEP
This section describes how to configure association between Ethernet CFM and SEP.

Association between Ethernet CFM and SEP is configured on edge devices of the SEP segment.
When Ethernet CFM detects a fault on the upper-layer network, the edge device encapsulates a
fault message into a CFM protocol packet and sends it to the OAM management module. In
addition, the edge device triggers the physical status of the interface on the edge device bound
to Ethernet CFM to go Down.
When the interface on the edge device bound to Ethernet CFM becomes Down, the peer device
(on the SEP segment) of the edge device needs to send FLUSH-FDB packets to report the
topology change to other nodes on the SEP segment. After the nodes on the SEP segment receive
FLUSH-FDB packets, the blocking interface on the SEP segment needs to enter the forwarding
state and send FLUSH-FDB packets to trigger the updating of MAC address tables and ARP
tables of nodes on the SEP segment. In this manner, the lower-level network can detect faults
on the upper-level network and the reliability of service transmission is improved.
Before configuring association between Ethernet CFM and SEP, complete the following tasks:
l Configuring Basic SEP Functions
Data Preparation
To configure association between Ethernet CFM and SEP, you need the following data.

No. Data
1 Number of the interface where association between Ethernet CFM and SEP is
configured
2 Names of MDs and MAs
3 SEP segment
4 Number of the interface added to the SEP segment
5.17.2 Configuring Association Between Ethernet CFM and SEP

Context
Do as follows on the device where association between Ethernet CFM and SEP needs to be
configured.
Procedure
Step 1 Run:
system-view

Step 2 Run:
oam-mgr

Step 3 Run:
oam-bind ingress cfm md md-name ma ma-name egress sep segment segment-id interface
interface-type interface-number
Association between Ethernet CFM and SEP is configured.

The interface specified by interface interface-type interface-number must be added to the SEP
segment.
----End

Prerequisites
The configurations of association between Ethernet CFM and SEP are complete.
Procedure
Step 1 Run the display this command in the OAM management view to check association between
Ethernet CFM and SEP.
#
oam-mgr

oam-bind ingress cfm md md1 ma ma1 egress sep segment 1 interface

#
----End
5.18 Configuring Association Between Ethernet OAM and

BFD
By associating Ethernet OAM with BFD, you can implement the fault notification.

Before associating Ethernet OAM BFD, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the required data. This can help you complete
the configuration task quickly and accurately.
As shown in Figure 5-14, CEs access PEs in dual-homing mode. To implement the end-to-end
link detection, you can configure BFD between PEs. Ethernet OAM runs between CEs and PEs.
When detecting faults, BFD at the core side notifies Ethernet OAM of the faults through PEs
and the traffic is switched to the backup path between CEs.
Figure 5-14 Diagram of associating Ethernet OAM with BFD

PE1 PE2
802.1ag/802.3ah 802.1ag/802.3ah
BFD
CE1
CE2
PE3 PE4
Before associating Ethernet OAM with BFD, complete the following tasks:
l Configuring the BFD session
Data Preparation
To associate Ethernet OAM with BFD, you need the following data.

No. Data
1 Numbers of the interfaces to be associated
2 Name of an MD and an MA
4 Types of detect packets sent
6 BFD names
7 Parameters of BFD sessions
5.18.2 Configuring Ethernet OAM Functions

You can configure Ethernet OAM between a CE and a PE to detect connectivity faults in
between.
Context
Configure Ethernet OAM to run between CEs and PEs. For details, see "Configuring EFM
OAM" and "Configuring Ethernet CFM".
5.18.3 Associating Ethernet OAM with BFD

Ethernet OAM and BFD can send fault information to each other.
Context
Do as follows on the PEs:
Procedure
Step 1 Run:
system-view

Step 2 Run:
oam-mgr

l Run:
oam-bind ingress cfm md md-name ma ma-name egress bfd-session bfd-session-id
Ethernet CFM is configured to send fault messages to BFD.

l Run:
oam-bind ingress bfd-session bfd-session-id egress cfm md md-name ma ma-name
BFD is configured to send fault messages to Ethernet CFM.

l Run:
oam-bind cfm md md-name ma ma-name bfd-session bfd-session-id

The bidirectional transmission of fault messages between Ethernet CFM and BFD is
configured.
l Run:
oam-bind ingress efm interface interface-type interface-number egress bfd-
session bfd-session-id
EFM OAM is configured to send fault messages to BFD.

l Run:
oam-bind ingress bfd-session bfd-session-id egress efm interface interface-type
interface-number
BFD is configured to send fault messages to EFM OAM.

l Run:
oam-bind efm interface interface-type interface-number bfd-session bfd-session-
id
The bidirectional transmission of fault messages between EFM OAM and BFD is configured.
----End

By viewing whether traffic on CEs is switched to a backup path, you can check whether the
configurations are successful.
Prerequisites
After the preceding configuration, when BFD enabled between PE1 and PE2 detects faults, EFM
OAM and CFM notify CE1 of the faults and then traffic is switched to the bypass tunnel for
CE1.
5.19 Maintaining Ethernet OAM

This section describes how to maintain Ethernet OAM. Detailed operations include deleting
CCM statistics, monitoring Ethernet OAM.
5.19.1 Debugging EFM OAM

After debugging, you need to disable the debugging function in time.
Context
CAUTION
Debugging affects the performance of the system. So, after debugging, run the undo debugging
all command to disable it immediately.
When an EFM OAM fault occurs, run the following debugging command in the user view to
view the debugging information to locate and analyze the fault.

Procedure
Step 1 Run the debugging efm interface interface-type interface-number { all | error | event |
message | packet { all | receive | send } | process } command in the user view to enable the
debugging of the EFM OAM module on the specified interface.
----End

This section provides several configuration examples of Ethernet OAM.
5.20.1 Example for Configuring EFM OAM

As shown in Figure 5-15, a user network is connected to an ISP network through Switch A and
Switch B. Switch A functions as the CE device, and Switch B functions as the underlayer PE
(UPE) device. The networking requirements are as follows:
l Automatic connectivity detection can be performed between Switch A and Switch B. After
detecting connectivity faults, Switch A and Switch B generate alarms.
l Switch B monitors the errored frames, errored codes, and errored frame seconds on GE
2/0/1. When the number of errored frames, errored codes, or errored frame seconds exceeds
the threshold, Switch B generates an alarm.
Figure 5-15 Networking diagram for configuring EFM OAM
SwitchA SwitchB
User Internet
network
GE1/0/1 GE2/0/1
1. Enable EFM OAM globally on Switch A and Switch B.
2. Configure EFM OAM on GE 1/0/1 of Switch A to work in passive mode.
3. Enable EFM OAM on GE 2/0/1 on Switch B. Enable EFM OAM on GE 1/0/1 on Switch
A.
4. Configure GE 2/0/1 of Switch B to detect the errored frames, errored codes, and errored
frame seconds.

Data Preparation
l Period for detecting errored frames on GE2/0/1 of Switch B (5 seconds) and threshold of
number of errored frames (5)
l Period for detecting errored codes on GE2/0/1 of Switch B (5 seconds) and threshold of
number of errored codes (5)
l Period for detecting errored frame seconds on GE 2/0/1 of Switch B (120 seconds) and
threshold of number of errored frame seconds (5)
Procedure
Step 1 Enable EFM OAM globally.
# Enable EFM OAM globally on Switch A.

[SwitchA] efm enable
# Enable EFM OAM globally on Switch B.

[SwitchB] efm enable
Step 2 Configure EFM OAM on GE 1/0/1 of Switch A to work in passive mode.

[SwitchA-GigabitEthernet1/0/1] bpdu bridge enable
[SwitchA-GigabitEthernet1/0/1] efm mode passive
Step 3 Enable EFM OAM on GE 2/0/1 of Switch B and GE 1/0/1 of Switch A.
# Enable EFM OAM on GE 1/0/1 of Switch A.

[SwitchA-GigabitEthernet1/0/1] efm enable
# Enable EFM OAM of GE 2/0/1 on SwitchB.

[SwitchB-GigabitEthernet2/0/1] bpdu bridge enable
[SwitchB-GigabitEthernet2/0/1] efm enable
Step 4 Configure GE 2/0/1 of Switch B to detect the errored frames, errored codes, and errored frame
seconds.
# Configure GE 2/0/1 of Switch B to detect the errored frames.

[SwitchB-GigabitEthernet2/0/1] efm error-frame period 5
[SwitchB-GigabitEthernet2/0/1] efm error-frame threshold 5
[SwitchB-GigabitEthernet2/0/1] efm error-frame notification enable
# Configure GE 2/0/1 of Switch B to detect the errored codes.

[SwitchB-GigabitEthernet2/0/1] efm error-code period 5
[SwitchB-GigabitEthernet2/0/1] efm error-code threshold 5
[SwitchB-GigabitEthernet2/0/1] efm error-code notification enable
# Configure GE 2/0/1 of Switch B to detect the errored frames seconds.

[SwitchB-GigabitEthernet2/0/1] efm error-frame-second period 120

[SwitchB-GigabitEthernet2/0/1] efm error-frame-second threshold 5
[SwitchB-GigabitEthernet2/0/1] efm error-frame-second notification enable

# If EFM OAM is configured correctly on Switch A and Switch B, GE 2/0/1 and GE 1/0/1 start
the handshake after negotiation. Run the display efm session command on Switch A or Switch
B, and you can find that the EFM OAM protocol is in detect state.
[SwitchB] display efm session interface gigabitethernet 2/0/1
--------------------------------------------------------------------
# Run the display efm command on Switch B. If the function of detecting errored frames, errored
codes, and errored frame seconds on GE 2/0/1 is configured corrected, the following information
is displayed:
[SwitchB] display efm interface gigabitethernet 2/0/1
Item Value
-------------------------------------
Mode: active
OAMPDU MaxSize: 128
ErrCodeNotification: enable
ErrCodePeriod: 5
ErrCodeThreshold: 5
ErrFrameNotification: enable
ErrFramePeriod: 5
ErrFrameSecondNotification: enable
Hold Up Time: 0
ThresholdEvtTriggerErrDown: disable
Remote MAC: 0010-0010-0010
Remote MaxSize: 128
Remote Loopback IgnoreRequest: --
Remote State: --
----End
Configuration Files
#
sysname SwitchA
#
efm enable
#
efm mode passive
efm enable
bpdu bridge enable
#
return

#
sysname SwitchB

#
efm enable
#
efm enable
efm error-frame period 5
efm error-frame threshold 5
efm error-frame notification enable
efm error-frame-second period 120
efm error-frame-second threshold 5
efm error-frame-second notification enable
efm error-code period 5
efm error-code threshold 5
efm error-code notification enable
bpdu bridge enable
#
return
5.20.2 Example for Testing the Packet Loss Ratio on a Link

As shown in Figure 5-16, a user network is connected to an ISP network through Switch A and
Switch B. Switch A functions as the CE device, and Switch B functions as the UPE device. The
link between Switch A and Switch B is newly established. The ISP needs to test the packet loss
ratio on the link on Switch B before using the link.
Figure 5-16 Networking diagram for testing the packet loss ratio on the link
SwitchA SwitchB
User Internet
network
GE1/0/1 GE2/0/1
1. Enable EFM OAM on Switch A and Switch B. Configure EFM OAM on GE 1/0/1 of Switch
A to work in passive mode.
2. Enable EFM OAM remote loopback on Switch B.
3. Send test packets from Switch B to Switch A.
4. Check the returned test packets on Switch B.
Data Preparation

l Timeout interval for EFM OAM remote loopback

l Size, number, and sending rate of test packets
Procedure
Step 1 Configure basic functions of EFM OAM.
# Enable EFM OAM globally on Switch B.
# Enable EFM OAM globally on Switch A.

# Configure EFM OAM on GE 1/0/1 of Switch A to work in passive mode.

# Enable EFM OAM on GE 1/0/1 of Switch A.

# Enable EFM OAM on GE 2/0/1 of Switch B.

# Verify the configuration.

# If EFM OAM is configured correctly on Switch A and Switch B, GE 2/0/1 and GE 1/0/1 start
the handshake after negotiation. Run the display efm session command on Switch A or Switch
B, and you can find that the EFM OAM protocol is in detect state.
--------------------------------------------------------------------
Step 2 Enable EFM OAM remote loopback.

# Enable EFM OAM remote loopback on Switch B.
[SwitchB-GigabitEthernet2/0/1] efm loopback start

Run the display efm session command on Switch B. If the EFM OAM protocol on GE 2/0/1 is
in Loopback (control) state, that is, GE 2/0/1 initiates remote loopback, the configuration is
successful. The displayed information is as follows:
[SwitchB] display efm session interface gigabitethernet2/0/1
----------------------------------------------------------------------
GigabitEthernet2/0/1 Loopback(control) 20

Run the display efm session command on Switch A. If the EFM OAM protocol on GE 1/0/1 is
in Loopback (be controlled) state, that is, GE 1/0/1 responds to remote loopback, the
configuration is successful. The displayed information is as follows:
[SwitchA] display efm session interface gigabitethernet1/0/1
----------------------------------------------------------------------
GigabitEthernet1/0/1 Loopback(be controlled) --
Step 3 Send test packets from Switch B to Switch A.

[SwitchB] test-packet start interface gigabitethernet 2/0/1
Please wait.............
Info: The test is completed.
Step 4 Check the returned test packets on Switch B.

<Switch B> display test-packet result
TestResult Value
--------------------------------------------------------
PacketsSend : 5
PacketsReceive : 0
PacketsLost : 5
BytesSend : 320
BytesReceive : 0
BytesLost : 320
StartTime : 08-03-2009 20:41:14 UTC+03:00 DST
EndTime : 08-03-2009 20:41:21 UTC+03:00 DST
You can obtain the packet loss ratio on the link based on the preceding data.
Step 5 Disable EFM OAM remote loopback.

[SwitchB-GigabitEthernet2/0/1] efm loopback stop
NOTE
By default, the timeout interval for remote loopback is 20 minutes. After 20 minutes, remote loopback
stops. To disable remote loopback, you can perform the preceding step.
Run the display efm session command on Switch A or Switch B. If the EFM OAM protocol on
the interfaces is in Detect or Discovery state, the configuration is successful. The displayed
information on Switch B is as follows:
[SwitchB] display efm session interface gigabitethernet2/0/1
----------------------------------------------------------------------
GigabitEthernet2/0/1 Detect --
----End
Configuration Files
#
sysname SwitchA
#
efm enable
#
efm mode passive
efm enable
bpdu bridge enable

#
return

#
sysname SwitchB
#
efm enable
#
efm enable
bpdu bridge enable
#
return
5.20.3 Example for Configuring Basic Functions of Ethernet CFM
As shown in Figure 5-17, the Ethernet is managed by two ISPs. Switch A, Switch B, and Switch
D are managed by ISP 1; Switch C, Switch E, Switch F, Switch G, Switch H, and Switch I are
managed by ISP 2. Connectivity of links needs to be tested on the network.
Figure 5-17 Networking diagram for configuring basic functions of Ethernet CFM
VLAN2
GE1/0/1
SwitchA SwitchE
SwitchI GE1/0/0
GE1/0/0 GE1/0/1
SwitchB
VLAN2 GE1/0/2 MD2 SwitchF
GE1/0/1 GE1/0/1
SwitchD
GE1/0/0 GE1/0/2
GE1/0/0 SwitchC
MD1 SwitchG
SwitchH
GE1/0/2 GE1/0/1 GE1/0/0
VLAN2 VLAN3 VLAN3
MD1 MD2
MEP in MA1 MEP in MA3
MEP in MA2

1. Create VLANs and add interfaces to the VLANs.

2. Create MD 1 at level 6 on all the Switches.
3. Create MA 1 in MD 1 on all the Switches except Switch G. Associate MA 1 with VLAN
2.
4. Create MA 1 in MD 1 on all the Switches except Switch E and Switch I. Associate MA 2
with VLAN 3.
5. Create MD 2 at level 4 and create MA 3 in MD 2 on Switch A, Switch B, Switch C, and
Switch D. Associate MA 3 with VLAN 4.
6. Create MEPs and RMEPs in MA 1 of MD 1 on Switch I, Switch H, and Switch E.
7. Create MEPs and RMEPs in MA 2 of MD 1 on Switch H and Switch G.
8. Create MEPs and RMEPs in MA 3 of MD 2 on Switch A, Switch C, and Switch D.
9. Enable sending and receiving of CCMs.
Data Preparation
l Level of MD 1: 6
l Level of MD 2: 4
Procedure
Step 1 Create VLANs and add interfaces to the VLANs. The configuration procedure is not mentioned
here.
Step 2 Create MD 1.
# Create MD 1 on Switch A.
[SwitchA] cfm enable
[SwitchA] cfm md md1 level 6
# Create MD 1 on SwitchB to I.
The configurations of these Switches are similar to the configuration of Switch A, and are not
mentioned here.
Step 3 Create MA 1 in MD 1 on all the Switches except Switch G.
# Create MA 1 in MD 1 on Switch A.
[SwitchA-md-md1] ma ma1
[SwitchA-md-md1-ma-ma1] map vlan 2
[SwitchA-md-md1-ma-ma1] quit
# Create MA 1 in MD 1 on Switches B to I.
mentioned here.

Step 4 Create MA 2 in MD 1 on all the Switches except Switch E and Switch I.
[SwitchA-md-md1] quit
# Create MA 2 in MD 1 on Switches B to H.
mentioned here.
Step 5 Create MD 2 and create MA 3 in MD 2 on Switch A, Switch B, Switch C, and Switch D.
# Create MD 2 and create MA 3 in MD 2 on Switch A.

Create MD 2 and create MA 3 in MD 2 on Switch A, Switch B, Switch C, and Switch D.
mentioned here.
Step 6 Create MEPs and RMEPs in MA 1 of MD 1 on Switch I, Switch H, and Switch E.
# Create a MEP in MA 1 of MD 1 on Switch E.

[SwitchE] cfm md md1
[SwitchrE-md-md1] ma ma1
[SwitchE-md-md1-ma-ma1] mep mep-id 3 interface gigabitethernet 1/0/1 inward
# Create a MEP in MA 1 of MD 1 on Switch H.

[SwitchH] cfm md md1
[SwitchH-md-md1] ma ma1
[SwitchH-md-md1-ma-ma1] mep mep-id 2 interface gigabitethernet 1/0/2 inward
# Create a MEP in MA 1 of MD 1 on Switch I.

[SwitchI] cfm md md1
[SwitchI-md-md1] ma ma1
[SwitchI-md-md1-ma-ma1] mep mep-id 1 interface gigabitethernet 1/0/1 inward
# Create an RMEP in MA 1 of MD 1 on Switch E.

[SwitchE-md-md1-ma-ma1] remote-mep mep-id 1
# Create an RMEP in MA 1 of MD 1 on Switch H.

[SwitchH-md-md1-ma-ma1] remote-mep mep-id 1
# Create an RMEP in MA 1 of MD 1 on Switch I.

[SwitchI-md-md1-ma-ma1] remote-mep mep-id 2
[SwitchI-md-md1-ma-ma1] remote-mep mep-id 3
Step 7 Create MEPs and RMEPs in MD 1 of MA 2 on Switch H and Switch G.
# Create a MEP in MA 2 of MD 1 on Switch H.

[SwitchH] cfm md md1

[SwitchH-md-md1] ma ma2
[SwitchH-md-md1-ma-ma2] mep mep-id 1 interface gigabitethernet 1/0/1 inward
# Create a MEP in MA 2 of MD 1 on Switch G.

[SwitchG] cfm md md1
[SwitchG-md-md1] ma ma2
[SwitchG-md-md1-ma-ma2] mep mep-id 2 interface gigabitethernet 1/0/0 inward
# Create an RMEP in MA 2 of MD 1 on Switch H.

# Create an RMEP in MA 2 of MD 1 on Switch G.

[SwitchG-md-md1-ma-ma2] remote-mep mep-id 1
Step 8 Create MEPs and RMEPs in MA 3 of MD 2 on Switch A, Switch C, and Switch D.

# Create a MEP in MA 3 of MD 2 on Switch A.
[SwitchA] cfm md md2
[SwitchA-md-md2-ma-ma3] mep mep-id 1 interface gigabitethernet 1/0/0 inward
# Create a MEP in MA 3 of MD 2 on Switch C.

[SwitchC] cfm md md2
[SwitchC-md-md2] ma ma3
[SwitchC-md-md2-ma-ma3] mep mep-id 2 interface gigabitethernet 1/0/0 outward
# Create a MEP in MA 3 of MD 2 on Switch D.

[SwitchD] cfm md md2
[SwitchD-md-md2] ma ma3
[SwitchD-md-md2-ma-ma3] mep mep-id 3 interface gigabitethernet 1/0/0 inward
# Create an RMEP in MA 3 of MD 2 on Switch A.

[SwitchA-md-md2-ma-ma3] remote-mep mep-id 2
# Create an RMEP in MA 3 of MD 2 on Switch C.

[SwitchC-md-md2-ma-ma3] remote-mep mep-id 1
# Create an RMEP in MA 3 of MD 2 on Switch D.

[SwitchD-md-md2-ma-ma3] remote-mep mep-id 1
[SwitchD-md-md2-ma-ma3] remote-mep mep-id 2
Step 9 Enable sending and receiving of CCMs.

# Enable Switch A to send CCMs of all the MEPs.
[SwitchA-md-md2-ma-ma3] mep ccm-send enable
# Enable Switch A to receive CCMs sent from all the RMEPs.

[SwitchA-md-md2-ma-ma3] remote-mep ccm-receive enable
# Enable sending and receiving of CCMs on Switch C, Switch D, Switch E, Switch G, Switch
H and Switch I.
mentioned here.

Run the display cfm remote-mep command to view detailed information about the RMEP. You
can view the RMEP status and check whether the CFM configuration is successful.
# View detailed information about the RMEP on SwitchA.

[SwitchA] display cfm remote-mep
--------------------------------------------------
MD Name : md2
Level : 4
MA Name : ma3
RMEP ID : 2
Vlan ID : 4
VSI Name : --
L2VC ID : --
MAC : 0000-0121-0222
CFM Status : up
MD Name : md2
Level : 4
MA Name : ma3
RMEP ID : 3
Vlan ID : 4
VSI Name : --
L2VC ID : --
MAC : 0000-0121-0333
CFM Status : up
# View detailed information about the RMEP on SwitchH.

[SwitchA] display cfm remote-mep
--------------------------------------------------
MD Name : md1
Level : 6
MA Name : ma1
RMEP ID : 1
Vlan ID : 2
VSI Name : --
L2VC ID : --
MAC : 0000-0121-0555
CFM Status : up
MD Name : md1
Level : 6
MA Name : ma1
RMEP ID : 3
Vlan ID : 2
VSI Name : --
L2VC ID : --
MAC : 0000-0121-0666
CFM Status : up

MD Name : md1
Level : 6
MA Name : ma2
RMEP ID : 2
Vlan ID : 3
VSI Name : --
L2VC ID : --
MAC : 0000-0121-0888
CFM Status : up
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 2 to 4
#
cfm enable
#
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
ma ma2
map vlan 3
#
cfm md md2 level 4
ma ma3
map vlan 4
mep mep-id 1 interface gigabitethernet 1/0/0 inward
mep ccm-send mep-id 1 enable
remote-mep mep-id 2
remote-mep ccm-receive mep-id 2 enable
remote-mep mep-id 3
#
return

#
sysname SwitchB
#
vlan batch 2 to 4
#
cfm enable
#
#


#
cfm md md1 level 6
ma ma1
map vlan 2
ma ma2
map vlan 3
#
cfm md md2 level 4
ma ma3
map vlan 4
#
return
#
sysname SwitchC
#
vlan batch 2 to 4
#
cfm enable
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
ma ma2
map vlan 3
#
cfm md md2 level 4
ma ma3
map vlan 4
mep mep-id 2 interface gigabitethernet 1/0/0 outward
remote-mep mep-id 1
remote-mep mep-id 3
#
return
#
sysname SwitchD
#
vlan batch 2 to 4
#
cfm enable
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
ma ma2
map vlan 3

#
cfm md md2 level 4
ma ma3
map vlan 4
remote-mep mep-id 1
remote-mep mep-id 2
#
return
l Configuration file of Switch E

#
sysname SwitchE
#
vlan batch 2
#
cfm enable
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
remote-mep mep-id 1
remote-mep mep-id 2
#
return
l Configuration file of Switch F

#
sysname SwitchF
#
vlan batch 2 to 3
#
cfm enable
#
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
ma ma2
map vlan 3
#
return

l Configuration file of Switch G

#
sysname SwitchG
#
vlan batch 3
#
cfm enable
#
#
#
cfm md md1 level 6
ma ma2
map vlan 3
remote-mep mep-id 1
#
return
l Configuration file of Switch H

#
sysname SwitchH
#
vlan batch 2 to 3
#
cfm enable
#
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
remote-mep mep-id 1
remote-mep mep-id 3
ma ma2
map vlan 3
remote-mep mep-id 2
#
return
l Configuration file of Switch I

#
sysname SwitchI
#
vlan batch 2

#
cfm enable
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
remote-mep mep-id 2
remote-mep mep-id 3
#
return
5.20.4 Example for Configuring the Default MD for Ethernet CFM
As shown in Figure 5-18, Switch B and Switch C are managed by ISP 1, and Switch A, Switch
D, Switch E, and Switch F are managed by ISP 2. The CFM function can be enabled after the
default MD is configured on the device in a low-level MD.
Figure 5-18 Networking diagram for configuring the default MD for Ethernet CFM
VLAN3
GE1/0/2
SwitchC
SwitchB GE1/0/2
SwitchE
/1
/1
1 /0
GE
1 /0
VLAN2
GE
GE1/0/3 SwitchF
GE1/0/1 SwitchD
GE1/0/2 SwitchA GE1 GE1/0/1
/0 /3
VLAN3 VLAN2
MEP of MA1
MEP of MA2
MIP

2. Create MD 1 at level 6 on all the devices except for Switch B and Switch C.
Create MD 2 at level 4 on Switch B and Switch C.
3. Create the default MD at level 6 on Switch B and Switch C, associate the default MD with
VLAN 2 and VLAN 3, and set the MIP creation rule to default.
4. Create and configure MA 1 in MD 1 on all the devices except for Switch E. Associate MA
1 with VLAN 2.
Create and configure MA 2 in MD 1 on all the devices except for Switch F. Associate MA
2 with VLAN 3.
5. Create and configure MEPs and RMEPs on MA 1 in MD 1 of Switch A and Switch F.
Create and configure MEPs and RMEPs on MA 2 in MD 1 of Switch A and Switch E.
6. Enable the function of sending and receiving CCMs.
Data Preparation
l IDs of VLANs to which the sub-interfaces are to be added
l Level of MD 1: 6
l Level of MD 2: 4
l Level of the default MD: 6
Procedure
Step 1 Create VLANs and add interfaces to the VLANs. The configuration procedure is not mentioned
here.
Step 2 Create MD 1.
# Create MD 1 on Switch A.
# Create MD 1 on Switch D, Switch E, and Switch F.

The configurations on SwitchD, Switch E, and Switch F are similar to the configuration on
Switch A, and are not mentioned here.
Step 3 Create MD 2.
# Create MD 2 on Switch B.
[SwitchB] cfm enable
[SwitchB] cfm md md2 level 4
[SwitchB-md-md2] quit

# Create MD 2 on Switch C.
The configuration on Switch C is similar to the configuration on Switch B, and is not mentioned
here.
Step 4 Create the default MD and associate the default MD with VLAN 2 and VLAN 3 on Switch B
and Switch C.
# Create the default MD and associate the default MD to VLAN 2 and VLAN 3 on Switch B.
[SwitchB] cfm default md level 6
[SwitchB-default-md] vlan 2 to 3
[SwitchB-default-md] quit
# Create the default MD and associate the default MD to VLAN 2 and VLAN 3 on SwitchC.
here.
Step 5 Set the MIP creation rule in the default MD on Switch B and Switch C.
# Set the MIP creation rule in the default MD on Switch B.

[SwitchB] cfm default md
[SwitchB-default-md] mip create-type default
[SwitchB-default-md] quit
# Set the MIP creation rule in the default MD on Switch C.
here.
Step 6 Create and configure MA 1 in MD 1 on all the devices except for Switch B and Switch C.
# Create MA 1 in MD 1 on Switch D and Switch F.
The configurations on Switch D and Switch F are similar to the configuration on Switch A, and
Step 7 Create and configure MA 2 in MD 1 on all the devices except for Switch B and Switch C.
# Create MA 2 in MD 1 on Switch D and Switch E.
The configurations on Switch D and Switch E are similar to the configuration on Switch A, and
Step 8 Configure MEPs and RMEPs in MA 1 of MD 1 on Switch A and Switch F.
# Configure a MEP in MA 1 of MD 1 on Switch A.


# Create a MEP in MA 1 of MD 1 on SwitchF.

[SwitchF] cfm md md1
[SwitchF-md-md1] ma ma1
[SwitchF-md-md1-ma-ma1] mep mep-id 1 interface gigabitethernet 1/0/1 inward
# Configure an RMEP in MA 1 of MD 1 on Switch A.

[Switch A-md-md1-ma-ma1] remote-mep mep-id 1
# Configure an RMEP in MA 1 of MD 1 on Switch F.

[SwitchF-md-md1-ma-ma1] remote-mep mep-id 2
Step 9 Configure MEPs and RMEPs in MA 2 of MD 1 on Switch A and Switch E.

# Configure a MEP in MA 2 of MD 1 on Switch A.
# Configure a MEP in MA 2 of MD 1 on Switch E.

[SwitchE] cfm md md1
[SwitchE-md-md1] ma ma2
[SwitchE-md-md1-ma-ma2] mep mep-id 2 interface gigabitethernet 1/0/2 inward
# Configure an RMEP in MA 2 of MD 1 on Switch A.

# Configure an RMEP in MA 2 of MD 1 on Switch E.

Step 10 Enable the function of sending and receiving CCMs.

# Enable the function of sending CCMs in all MEPs on Switch A.
# Enable the function of receiving CCMs from all the RMEPs on Switch A.
# Enable the function of sending CCMs in all MEPs and the function of receiving CCMs from
all the RMEPs on Switch E and Switch F.
The configurations on Switch E and Switch F are similar to the configuration on Switch A, and
After the preceding configurations are complete and the network becomes stable, run the
following commands to verify the configuration. Take Switch A and Switch B for example.
l Run the display cfm default md command on Switch B, and you can view the following
information:
[SwitchB] display cfm default md
Level MIP-Create-type SenderID TLV-type VLAN-List
-------------------------------------------------------------------------------
---------
6 default SendIdDefer 2 to 3

According to the preceding information, on Switch B, the default MD at level 6 is configured

and associated with VLAN 2 and VLAN 3, and the MIP creation rule is default.
l Perform the 802.1ag MAC ping/trace operation on Switch A, and you can view that no
connectivity fault occurs between Switch A and Switch E and the 802.1ag MAC trace
operation is successful. The following information is displayed:
[SwitchA-md-md1-ma-ma1] trace mac-8021ag mep mep-id 1 md md1 ma ma1 mac
aa99-6600-5600
Tracing the route to aa99-6600-5600 over a maximum of 255 hops:
Hops Mac Ingress Ingress Action
Relay Action
Forwarded Egress Egress Action
Ismep
1 2155-2201-3302 gigabitethernet1/0/3 IngOK
RlyFDB
Forwarded gigabitethernet1/0/1 EgrOK No
RlyFDB
Forwarded gigabitethernet1/0/2 EgrOk No
RlyFDB
RlyFDB
5 aa99-6600-5600 gigabitethernet1/0/1 IngOK
RlyHit
Not Forwarded
Ismep
Info: Succeed in tracing the destination address aa99-6600-5600.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 2 to 3
#
cfm enable
#
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
remote-mep mep-id 1
ma ma2
map vlan 3


remote-mep mep-id 2
#
return
#
sysname SwitchB
#
vlan batch 2 to 3
#
cfm enable
#
#
#
cfm md md2 level 4
#
cfm default md level 6
mip create-type default
vlan 2 to 3
#
return
#
sysname SwitchC
#
vlan batch 2 to 3
#
cfm enable
#
#
#
cfm md md2 level 4
#
cfm default md level 6
mip create-type default
vlan 2 to 3
#
return
#
sysname SwitchD
#
vlan batch 2 to 3
#
cfm enable
#
#
#

#
cfm md md1 level 6
ma ma1
map vlan 2
ma ma2
map vlan 3
#
return
l Configuration file of Switch E

#
sysname SwitchE
#
vlan batch 3
#
cfm enable
#
#
#
cfm md md1 level 6
ma ma2
map vlan 3
remote-mep mep-id 1
#
return
l Configuration file of Switch F

#
sysname SwitchF
#
vlan batch 2
#
cfm enable
#
#
#
cfm md md1 level 6
ma ma1
map vlan 2
remote-mep mep-id 2
#
return
5.20.5 Example for Configuring Association Between an EFM OAM

Module and an Interface

As shown in Figure 5-19, EFM OAM is configured between Switch B and Switch C. When GE
2/0/0 on Switch B becomes Down, the EFM OAM module reports the fault to GE 1/0/0 on
Switch C through the association mechanism. Then GE 1/0/0 is triggered to go Down.
Figure 5-19 Networking diagram for configuring association between an EFM OAM module
and an interface
SwitchA SwitchB SwitchC
GE1/0/0 GE2/0/0
GE1/0/0 GE2/0/0
EFM OAM
Interface associated with
EFM OAM
1. Configure EFM OAM between Switch B and Switch C.
2. On Switch B, configure association between an EFM OAM module and GE 1/0/0.
Procedure
Step 1 Configure EFM OAM between Switch B and Switch C.
[SwitchB-GigabitEthernet2/0/0] efm mode passive
[SwitchC] efm enable
[SwitchC-GigabitEthernet2/0/0] bpdu bridge enable
[SwitchC-GigabitEthernet2/0/0] efm enable
Run the display efm session interface command on Switch B to check the EFM OAM status,
and you can find that EFM OAM is in detect state.
--------------------------------------------------------------------
GigabitEthernet2/0/0 detect
Step 2 Configure association between an EFM OAM module with an interface.

# Enable GE 1/0/0 on Switch B and the EFM OAM module between Switch B and Switch C to
report faults to each other.
[SwitchB] oam-mgr
[SwitchB-oam-mgr] oam-bind efm interface gigabitethernet 2/0/0 trigger if-down
interface gigabitethernet 1/0/0

After GE 2/0/0 on Switch B is shut down, the EFM OAM module reports the fault to GE 1/0/0.
Then GE 1/0/0 is triggered to go Down.
[SwitchB] display interface gigabitethernet 1/0/0
GigabitEthernet1/0/0 current state : TRIGGER DOWN
(3AH)
Line protocol current state : DOWN
Description:HUAWEI, Quidway Series, GigabitEthernet1/0/0 Interface
Switch Port,PVID : 1,The Maximum Frame Length is 9216
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-2000-0083
Last physical up time : -
Last physical down time : 2009-07-22 18:00:16 DST
Port Mode: COMMON FIBER
Speed : 1000, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE
Mdi : NORMAL
Last 300 seconds input rate 0 bits/sec, 0 packets/sec
Last 300 seconds output rate 0 bits/sec, 0 packets/sec
Input peak rate 0 bits/sec,Record time: -
Output peak rate 0 bits/sec,Record time: -
Input: 0 packets, 0 bytes

Unicast: 0, Multicast: 0
Broadcast: 0, Jumbo: 0
Discard: 0, Total Error: 0
CRC: 0, Giants: 0
Jabbers: 0, Throttles: 0
Runts: 0, DropEvents: 0
Alignments: 0, Symbols: 0
Ignoreds: 0, Frames: 0
Output: 0 packets, 0 bytes

Collisions: 0, ExcessiveCollisions: 0
Late Collisions: 0, Deferreds: 0
Buffers Purged: 0
Input bandwidth utilization threshold : 100.00%

Output bandwidth utilization threshold: 100.00%
Input bandwidth utilization : 0.00%
Output bandwidth utilization : 0.00%
----End
Configuration Files
#
sysname SwitchB
#
efm enable
#
#

efm mode passive

efm enable
bpdu bridge enable
#
oam-mgr
oam-bind ingress interface GigabitEthernet1/0/0 egress efm interface
GigabitEthernet2/0/0 trigger if-down
oam-bind ingress efm interface GigabitEthernet2/0/0 trigger if-down egress
#
return

#
sysname SwitchC
#
efm enable
#
efm enable
bpdu bridge enable
#
return
5.20.6 Example for Associating EFM OAM with BFD for IP

As shown in Figure 5-20, CE1 is connected to PE1 and PE2 and CE2 is connected to PE3 and
PE4 in dual-homing mode. The requirements are as follows:
l PWs are set up between PE1 and PE3, and between PE2 and PE4, using MPLS LSPs as
tunnels.
l When the path CE1 -> PE1 -> P -> PE3 -> CE2 fails, L2VPN traffic can be fast switched
to the backup path CE1 -> PE2 -> PE2 -> CE2.

Figure 5-20 Example for associating EFM OAM with BFD for IP
P
1 GE
2 /0 / 2 /0 /
GE 2
Loopback1 Loopback1
1.1.1.1/32 Loopback1 3.3.3.3/32
1 5.5.5.5/32 GE
2 /0 / 2 /0 /
GE LSP 1
PE1 PE3
Loopback1 Loopback1
GE1/0/0 2.2.2.2/32 4.4.4.4/32 GE1/0/0
GE2/0/0 GE2/0/0
PE2 PE4
LSP
GE1/0/0 GE1/0/0
GE1/0/0
GE1/0/1 GE1/0/0
GE1/0/1
CE1 CE2
GE1/0/2
S9700 Interface VLANIF interface IP address
PE1 GigabitEthernet1/0/0 VLANIF 10 10.1.1.2/24
GigabitEthernet2/0/1 VLANIF 20 100.1.13.1/24
Loopback1 - 1.1.1.1/32
Loopback1 - 2.2.2.2/32
Loopback1 - 3.3.3.3/32
Loopback1 - 4.4.4.4/32
P GigabitEthernet2/0/1 VLANIF 20 100.1.13.2/24
Loopback1 - 5.5.5.5/32
CE1 GigabitEthernet1/0/0 VLANIF 10 10.1.1.1/24
CE1 GigabitEthernet1/0/0 VLANIF 40 10.1.1.2/24

1. Set IP addresses of interfaces.
2. Configure OSPF on the backbone network.
3. Create MPLS LDP sessions between PE1 and PE3, and between PE2 and PE4.
4. Configure PWs on PEs by using PW templates.
5. Configure the Martini VLL on the interfaces connecting PEs and CEs.
6. Create BFD sessions for IP between PE1 and PE3, and between PE2 and PE4.
7. Configure EFM OAM on PEs and CEs.
8. Associate BFD for IP with Ethernet CFM on PEs.
Data Preparation
l Name of the remote peer of MPLS LDP
l VC IDs of the active PW and the standby PW
l Names of PW templates
l Names of BFD sessions for IP, and local and remote discriminators
Procedure
Step 1 Configure the VLANs that the interfaces belong to according to Figure 5-20.
The configuration details are not mentioned here.
Step 2 Assign IP addresses to VLANIF interfaces on the CEs.
# Configure CE1.
[CE1] interface vlanif 10
[CE1-Vlanif10] ip address 10.1.1.1 24
[CE1-Vlanif10] quit
[CE1-Vlanif50] quit
[CE1-Vlanif80] quit
# Configure CE2.
[CE2-Vlanif40] quit
[CE2-Vlanif70] quit

Step 3 On the MPLS backbone network, configure IP addresses for interfaces and an IGP so that PEs
and P on the backbone network can interwork.
# Configure PE1.
[Quidway] sysname PE1
[PE1] interface loopback1
[PE1-LoopBack1] ip address 1.1.1.1 32
[PE1-LoopBack1] quit
[PE1] interface vlanif 20
[PE1-Vlanif20] ip address 100.1.13.1 24
[PE1-Vlanif20] quit
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure the P.
[Quidway] sysname P
[P] interface loopback1
[P-LoopBack1] ip address 5.5.5.5 32
[P-LoopBack1] quit
[P] interface vlanif 20
[P-Vlanif20] ip address 100.1.13.2 24
[P-Vlanif20] quit
[P-Vlanif30] ip address 100.1.31.1 24
[P-Vlanif30] quit
[P] ospf 1
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 5.5.5.5 0.0.0.0
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
# Configure PE3.
[PE3-Vlanif30] quit
[PE3] ospf 1
[PE3-ospf-1] area 0
[PE3-ospf-1] quit
# Configure PE2.
[PE2-Vlanif60] quit
[PE2] ospf 1

[PE2-ospf-1] area 0
# Configure PE4.
[PE4-Vlanif60] quit
[PE4] ospf 1
[PE4-ospf-1] area 0
[PE2-ospf-1] quit
After the configuration, run the display ip routing-table command on the PEs, and you can
view that PE1 and PE2, and PE1 and PE3 have learned the routes on the Loopback1 interface
of each other.
Take the display on PE1 as an example:
[PE1] display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 11 Routes : 11
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0

3.3.3.3/32 OSPF 10 3 D 100.1.13.2 Vlanif20
5.5.5.5/32 OSPF 10 2 D 100.1.13.2 Vlanif20
100.1.13.0/24 Direct 0 0 D 100.1.13.1 Vlanif20
100.1.13.2/32 Direct 0 0 D 100.1.13.2 Vlanif20
100.1.31.0/24 OSPF 10 2 D 100.1.13.2 Vlanif20
Step 4 Configure basic MPLS functions on the MPLS backbone network.

# Enable MPLS, and set LSR-ID as the IP address of the Loopback1 interface. Enable MPLS
and MPLS LDP on interfaces on the backbone network.
# Configure PE1.
[PE1] mpls lsr-id 1.1.1.1
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1-Vlanif20] mpls
[PE1-Vlanif20] mpls ldp
[PE1-Vlanif20] quit
# Configure the P.
[P] mpls lsr-id 5.5.5.5
[P] mpls
[P-mpls] quit

[P] mpls ldp

[P-mpls-ldp] quit
[P-Vlanif20] mpls
[P-Vlanif20] mpls ldp
[P-Vlanif20] quit
[P-Vlanif30] mpls
[P-Vlanif30] mpls ldp
[P-Vlanif30] quit
# Configure PE3.
[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
[PE3-Vlanif30] mpls
[PE3-Vlanif30] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2-Vlanif60] mpls
[PE2-Vlanif60] quit
# Configure PE4.
[PE4] mpls
[PE4-mpls] quit
[PE4] mpls ldp
[PE4-mpls-ldp] quit
[PE4-Vlanif60] mpls
[PE4-Vlanif60] quit
After the configuration, run the display tunnel-info all command on PEs. You can view that
MPLS LSP tunnels are set up between PE1 and PE3, and between PE2 and PE4.
Take the display on PE1 and PE2 as an example.
[PE1] display tunnel-info all
* -> Allocated VC Token
Tunnel ID Type Destination Token
----------------------------------------------------------------------
0x10025 lsp 3.3.3.3 5
0x10026 lsp -- 6
0x10027 lsp 5.5.5.5 7
0x10028 lsp -- 8
[PE2] display tunnel-info all
* -> Allocated VC Token
Tunnel ID Type Destination Token
----------------------------------------------------------------------
0x10021 lsp 4.4.4.4 1
Step 5 Create remote LDP sessions between PEs.

# Create remote LDP sessions. Generally, addresses of loopback interfaces of the remote LDP
peers are configured as the IP addresses for remote LDP sessions.

NOTE
In this example, PE2 and PE4 are directly connected and you do not need to manually configure remote
LDP sessions between them.
# Configure PE1.
[PE1] mpls ldp remote-peer pe3
[PE1-mpls-ldp-remote-pe3] remote-ip 3.3.3.3
[PE1-mpls-ldp-remote-pe3] quit
# Configure PE3.
[PE3] mpls ldp remote-peer pe1
[PE3-mpls-ldp-remote-pe1] remote-ip 1.1.1.1
[PE3-mpls-ldp-remote-pe1] quit
After the configuration, run the display mpls ldp session command on PEs. You can see that
the LDP peer relationship is in Operational state. This indicates that the LDP sessions are set
up.
Take the display on PE1 as an example:
[PE1] display mpls ldp session
LDP Session(s) in Public Network

------------------------------------------------------------------------------
Peer-ID Status LAM SsnRole SsnAge KASent/Rcv
------------------------------------------------------------------------------
3.3.3.3:0 Operational DU Passive 000:00:56 225/227
5.5.5.5:0 Operational DU Passive 000:00:13 56/56
------------------------------------------------------------------------------
TOTAL: 2 session(s) Found.
LAM : Label Advertisement Mode SsnAge Unit : DDD:HH:MM
Step 6 Configure PWs on PEs by using PW templates.

# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] mpls l2vpn default martini
[PE1-l2vpn] quit
[PE1] pw-template 1to3
[PE1-pw-template-1to3] peer-address 3.3.3.3
[PE1-pw-template-1to3] control-word
[PE1-pw-template-1to3] quit
[PE1-Vlanif10] mpls l2vc pw-template 1to3 100
[PE1-Vlanif10] quit
# Configure PE3.
[PE3] mpls l2vpn
[PE3-l2vpn] quit
[PE3-Vlanif40] quit
# Configure PE2.
[PE2] mpls l2vpn

[PE2-l2vpn] quit
[PE2-Vlanif50] quit
# Configure PE4.
[PE4] mpls l2vpn
[PE4-l2vpn] quit
[PE4-Vlanif70] quit
After the configuration, run the display mpls l2vc command on PEs. You can view that PWs
are set up and are in Active state.
Take the display on PE1 as an example.

[PE1] display mpls l2vc
total LDP VC : 1 1 up 0 down
*client interface : Vlanif10
Administrator PW : no
session state : up
AC status : up
Label state : 0
Token state : 0
VC state : up
VC ID : 100
VC type : VLAN
destination : 3.3.3.3
local VC label : 21504 remote VC label : 21504
control word : enable
forwarding entry : existent
local group ID : 0
manual fault : not set
active state : active
link state : up
local VC MTU : 1500 remote VC MTU : 1500
tunnel policy name : --
traffic behavior name: --
PW template name : 1to3
primary or secondary : primary
create time : 1 days, 4 hours, 51 minutes, 22 seconds
up time : 0 days, 0 hours, 33 minutes, 13 seconds
last change time : 0 days, 0 hours, 33 minutes, 13 seconds
VC last up time : 2008/07/24 12:31:31
VC total up time: 0 days, 2 hours, 12 minutes, 51 seconds
CKey : 16
NKey : 15
AdminPw interface : LoopBack1
AdminPw link state : up
Run OSPF on CE1 and CE2 and advertise the route to 10.1.3.0/24 to CE2. To ensure that traffic
is transmitted through the path CE1 PE1 P PE3 CE2, increase the cost of OSPF on
VLANIF 50 of CE1 and VLANIF 70 of CE2. For example, change the cost to 10.
# Configure CE1.

[CE1] ospf 1
[CE1-ospf-1] area 0.0.0.0
[CE1-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[CE1-ospf-1-area-0.0.0.0] quit
[CE1-ospf-1] quit
[CE1-Vlanif50] ospf cost 10
[CE1-Vlanif50] quit
# Configure CE2.
[CE2] ospf 1
[CE2-ospf-1] quit
[CE2-Vlanif70] quit
Run the display ip routing-table command on CE1, and you can view that the outgoing interface
for the route from CE1 to 10.1.3.0/24 is VLANIF 40. That is, the traffic is transmitted through
the primary path.
[CE1] display ip routing-table
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Vlanif40

10.1.1.1/32 Direct 0 0 D 10.1.1.1 Vlanif40
10.1.2.0/24 Direct 0 0 D 10.1.2.2 Vlanif70
10.1.2.1/32 Direct 0 0 D 10.1.2.1 Vlanif70
10.1.3.0/24 OSPF 0 0 D 10.1.1.1 Vlanif40
10.1.3.1/32 OSPF 10 2 D 10.1.1.1 Vlanif40
CE2 can ping the address 10.1.3.1 on CE1.

[CE1] ping 10.1.3.1
PING 10.1.3.1: 56 data bytes, press CTRL_C to break
Reply from 10.1.3.1: bytes=56 Sequence=1 ttl=255 time=170 ms
--- 10.1.3.1 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 130/160/190 ms
Step 7 Configure BFD sessions between PEs.

NOTE
The local discriminators and remote discriminators of the two ends on a BFD session should be correctly
associated. That is, the local discriminator of the local system and the remote discriminator of the remote
system are the same, and the remote discriminator of the local system and the local discriminator of the
remote system are the same. The configuration cannot be changed.
# Configure PE1.
[PE1] bfd
[PE1-bfd] quit
[PE1] bfd 1to3 bind peer-ip 100.1.31.2
[PE1-bfd-session-1to3] discriminator local 1
[PE1-bfd-session-1to3] discriminator remote 3
[PE1-bfd-session-1to3] commit
[PE1-bfd-session-1to3] quit
# Configure PE3.
[PE3] bfd
[PE3-bfd] quit
# Configure PE2.
[PE2] bfd
[PE2-bfd] quit
# Configure PE4.
[PE4] bfd
[PE4-bfd] quit
After the configuration, BFD sessions are set up between PE1 and PE3, and between PE2 and
PE4. Run the display bfd session all command, and you can view that the status of the BFD
sessions is Up.
Take the display on PE1 as an example.
[PE1] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
1 3 100.1.31.2 Up S_IP_PEER -
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
Run the display bfd configuration all command. You can view information about the BFD
configuration, and you can view that the Commit field is True.
[PE1] display bfd configuration all
--------------------------------------------------------------------------------
CFG Name CFG Type LocalDiscr MIndex SessNum Commit AdminDown
--------------------------------------------------------------------------------
1to3 S_IP_PEER 13 4096 1 True False

--------------------------------------------------------------------------------
Total Commit/Uncommit CFG Number : 1/0
Step 8 Configure EFM OAM between PEs and CEs.
# Configure PE1.
[PE1] efm enable
[PE1] interface gigabitethernet 1/0/0
[PE1-GigabitEthernet1/0/0] bpdu bridge enable
[PE1-GigabitEthernet1/0/0] efm enable
[PE1-GigabitEthernet1/0/0] quit
# Configure PE2.
[PE2] efm enable
# Configure PE3.
[PE3] efm enable
# Configure PE4.
[PE4] efm enable
# Configure CE1.
[CE1] efm enable
[CE1-GigabitEthernet1/0/0] bpdu bridge enable
[CE1-GigabitEthernet1/0/0] efm mode passive
[CE1-GigabitEthernet1/0/0] efm enable
# Configure CE2.
[CE2] efm enable
After the configuration, run the display cfm remote-mep command on PEs and CEs to check
the CFM OAM status. You can view that the CFM OAM is Up. Take the display on CE1 as an
example.

[CE1] display cfm remote-mep

----------------------------------------------------------------------
Step 9 Associate EFM OAM with BFD.

# Configure PE1.
[PE1] oam-mgr
[PE1-oam-mgr] oam-bind efm interface GigabitEthernet 1/0/0 bfd-session 1
[PE1-oam-mgr] quit
# Configure PE3.
[PE3] oam-mgr
[PE3-oam-mgr] quit
# Configure PE2.
[PE2] oam-mgr
[PE2-oam-mgr] quit
# Configure PE4.
[PE4] oam-mgr
[PE4-oam-mgr] quit
After the configuration, run the display this command in the OAM management view on PEs
to check association. Take the display on PE1 as an example:
[PE1-oam-mgr] display this
#
oam-mgr
oam-bind ingress efm interface GigabitEthernet1/0/0 egress bfd-session 1
oam-bind ingress bfd-session 1 egress efm interface GigabitEthernet1/0/0
#
Run the display bfd session all verbose command on PEs to check the BFD session status, and
you can view that the bound application is ETHOAM. Take the display on PE1 as an example:
[PE1] display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 4096 (One Hop) State : Up Name : 1to3
--------------------------------------------------------------------------------
Local Discriminator : 1 Remote Discriminator : 3
Session Detect Mode : Asynchronous Mode Without Echo Function
BFD Bind Type : Peer IP Address
Bind Session Type : Static
Bind Peer IP Address : 100.1.31.2
NextHop Ip Address : 100.1.31.1
Bind Interface : -
FSM Board Id : 0 TOS-EXP : 7
Min Tx Interval (ms) : 1000 Min Rx Interval (ms) : 1000
Actual Tx Interval (ms): 13000 Actual Rx Interval (ms): 13000
Local Detect Multi : 3 Detect Interval (ms) : -
Echo Passive : Disable Acl Number : -
Destination Port : 3784 TTL : 255
Proc Interface Status : Disable Process PST : Disable
WTR Interval (ms) : -
Active Multi : 3
Last Local Diagnostic : Control Detection Time Expired
Bind Application : ETHOAM
Session TX TmrID : 17261 Session Detect TmrID : -
Session Init TmrID : - Session WTR TmrID : -

Session Echo Tx TmrID : -

PDT Index : FSM-0 | RCV-0 | IF-0 | TOKEN-0
Session Description : -
--------------------------------------------------------------------------------

l Check the status of the PW.
Run the display mpls l2vc interface command on PE1 or PE3. If the configuration is
successful, you can see that PW1 is Up. Take the display on PE1 as an example:
<PE1> display mpls l2vc interface vlanif 10
*client interface : Vlanif10 is up
session state : up
AC state : up
VC state : up
VC ID : 100
VC type : VLAN
local group ID : 0 remote group ID : 0
local AC OAM State : up
local PSN State : up
local forwarding state : forwarding
local status code : 0x0
remote AC OAM state : up

remote PSN state : up
remote forwarding state: forwarding
remote statuscode : 0x0
BFD for PW : enable

forwarding entry : exist
link state : up
Local VCCV : alert lsp-ping bfd
Remote VCCV : alert lsp-ping bfd
local control word : disable remote control word : disable
traffic behavior name : --
PW template name : --
VC tunnel/token info : 1 tunnels/tokens
NO.0 TNL type : lsp , TNL ID : 0x2002003
VC last up time : 2008/07/24 12:31:31
CKey :
16
NKey : 15
PW redundancy mode : independent
l Verify the active and standby switchover on CEs.

Shut down GE 2/0/1 on PE1 and set faults on the link between PEs.
Run the display bfd session all verbose command on PE1 or PE3, and you can find that the
BFD session of PW1 is Down. Take the display on PE1 as an example:
-------------------------------------------------------------------------------
-

Session MIndex : 4096 (One Hop) State : Down Name :

1to3
-------------------------------------------------------------------------------
-
Local Discriminator : 1 Remote Discriminator :
3
Session Detect Mode : Asynchronous Mode Without Echo
Function
Bind Session Type :
Static
Bind Interface : -
FSM Board Id : 0 TOS-EXP :
7
Min Tx Interval (ms) : 1000 Min Rx Interval (ms) :
1000
Actual Tx Interval (ms): 13000 Actual Rx Interval (ms):
13000
Local Detect Multi : 3 Detect Interval (ms) :
-
Echo Passive : Disable Acl Number :
-
Destination Port : 3784 TTL :
255
Proc Interface Status : Disable Process PST :
Disable
WTR Interval (ms) :
-
Active Multi :
3
Last Local Diagnostic : Control Detection Time
Expired
Bind Application :
ETHOAM
Session TX TmrID : 17261 Session Detect TmrID :
-
Session Init TmrID : - Session WTR TmrID :
-
Session Echo Tx TmrID :
-
PDT Index : FSM-0 | RCV-0 | IF-0 |
TOKEN-0
Session Description :
-
-------------------------------------------------------------------------------
-
Run the display mpls l2vc interface command on PE1 or PE3, and you can view that the
status of VC and BFD becomes Down. Take the display on PE1 as an example:
<PE1> display mpls l2vc interface vlanif 10
*client interface : Vlanif10 is up
session state : down
AC state : up
VC state : down
VC ID : 100
VC type : VLAN
local group ID : 0 remote group ID : 0
local AC OAM State : up
local PSN State : up
local forwarding state : forwarding
local status code : 0x0
remote AC OAM state : up

remote PSN state : up

remote forwarding state: forwarding

remote statuscode : 0x0
BFD for PW : enable

forwarding entry : exist
link state : down
Local VCCV : alert lsp-ping bfd
Remote VCCV : alert lsp-ping bfd
local control word : disable remote control word : disable
traffic behavior name : --
PW template name : --
BFD sessionIndex : 4097 BFD state : down
VC tunnel/token info : 1 tunnels/tokens
NO.0 TNL type : lsp , TNL ID : 0x2002003
VC last up time : 2008/07/24 12:31:31
CKey :
16
NKey : 15
PW redundancy mode : independent
Check the routing table on CE1. You can find that the outgoing interface of the route to 10.1.3.0
is VLANIF 70. That is, L2VPN traffic is switched to the standby path.
------------------------------------------------------------------------------
10.1.2.0/24 Direct 0 0 D 10.1.2.2 Vlanif70

10.1.2.1/32 Direct 0 0 D 10.1.2.1 Vlanif70
10.1.3.1/32 OSPF 10 11 D 10.1.2.1 Vlanif70
----End
Configuration Files
#
sysname CE1
#
vlan batch 10 50 80
#
efm enable
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif50
ip address 10.1.2.1 255.255.255.0

#
interface Vlanif80
ip address 10.1.3.1 255.255.255.0
#
efm mode passive
efm enable
bpdu bridge enable
#
efm mode passive
efm enable
bpdu bridge enable
#
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
#
return
#
sysname CE2
#
vlan batch 40 70
#
efm enable
#
interface Vlanif40
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif70
ip address 10.1.2.2 255.255.255.0
ospf cost 10
#
efm mode passive
efm enable
bpdu bridge enable
#
efm mode passive
efm enable
bpdu bridge enable
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
#
return
l Configuration file of PE1
#
sysname PE1
#

vlan batch 10 20
#
efm enable
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
#
mpls l2vpn
mpls l2vpn default martini
#
pw-template 1to3
peer-address 3.3.3.3
control-word
#
mpls ldp
#
mpls ldp remote-peer 3.3.3.3
remote-ip 3.3.3.3
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
mpls l2vc pw-template 1to3
#
interface Vlanif20
ip address 100.1.13.1 255.255.255.0
mpls
mpls ldp
#
port hybrid pvid vlan 10
efm enable
bpdu bridge enable
#
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 100.1.13.0 0.0.0.255
#
bfd 1to3 bind peer-ip 100.1.31.2
discriminator local 1
discriminator remote 3
commit
#
oam-mgr
oam-bind ingress bfd-session 1 egress interface GigabitEthernet1/0/0
#
return
l Configuration file of P
#
sysname P
#
vlan batch 20 30
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#

interface Vlanif20
ip address 100.1.13.2 255.255.255.0
mpls
mpls ldp
#
interface Vlanif30
ip address 100.1.31.1 255.255.255.0
mpls
mpls ldp
#
#
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 100.1.13.0 0.0.0.255
network 100.1.31.0 0.0.0.255
#
return
#
sysname PE3
#
vlan batch 30 40
#
efm enable
#
bfd
#
mpls lsr-id 3.3.3.3
mpls
#
mpls l2vpn
#
pw-template 3to1
control-word
#
mpls ldp
#
mpls ldp remote-peer 1.1.1.1
remote-ip 1.1.1.1
#
interface Vlanif30
ip address 100.1.31.2 255.255.255.0
mpls
mpls ldp
#
interface Vlanif40
ip address 10.1.1.1 255.255.255.0
#
efm enable
bpdu bridge enable
#


#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 100.1.31.0 0.0.0.255
#
commit
#
oam-mgr
oam-bind ingress bfd-session 3 egress interface GigabitEthernet1/0/0
#
return
#
sysname PE2
#
vlan batch 50 60
#
efm enable
#
bfd
#
mpls lsr-id 2.2.2.2
mpls
#
mpls l2vpn
#
pw-template 2to4
control-word
#
mpls ldp
#
interface Vlanif50
ip address 10.1.2.2 255.255.255.0
#
interface Vlanif60
ip address 100.1.24.1 255.255.255.0
mpls
mpls ldp
#
efm enable
bpdu bridge enable
#
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 100.1.24.0 0.0.0.255

#
commit
#
oam-mgr
#
return

#
sysname PE4
#
vlan batch 60 70
#
efm enable
#
bfd
#
mpls lsr-id 4.4.4.4
mpls
#
mpls l2vpn
#
pw-template 4to2
control-word
#
mpls ldp
#
interface Vlanif60
ip address 100.1.24.2 255.255.255.0
mpls
mpls ldp
#
interface Vlanif70
ip address 10.1.2.1 255.255.255.0
#
port hybrid pvid pvid vlan 70
efm enable
bpdu bridge enable
#
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 100.1.24.0 0.0.0.255
#
commit
#
oam-mgr

#
return
5.20.7 Example for Configuring Association Between EFM OAM

Modules
As shown in Figure 5-21, to implement the end-to-end link fault detection, EFM OAM is
configured between Switch A and Switch B and between Switch B and Switch C. When a fault
occurs on the link between Switch A and Switch B, EFM OAM between Switch A and Switch
B detects the fault and sends fault messages to Switch C through the association mechanism.
Then, alarms are generated on Switch C.
Figure 5-21 Networking diagram for configuring association between EFM OAM modules
GE1/0/0 GE2/0/0
GE1/0/0 GE2/0/0
EFM OAM EFM OAM
1. Enable EFM OAM globally on Switch A, Switch B, and Switch C.
2. Configure EFM OAM on GE 1/0/0 of Switch B and GE 2/0/0 of Switch C to work in passive
mode.
3. Enable EFM OAM on interfaces of the S9700s.
4. Configure association between EFM OAM modules on Switch B.
Procedure
Step 1 Enable EFM OAM globally.
<SwitchB> system-view
<SwitchC> system-view
Step 2 Configure the operation mode of interfaces.


[SwitchB-GigabitEthernet1/0/0] efm mode passive

[SwitchC-GigabitEthernet2/0/0] efm mode passive
Step 3 Enable EFM OAM on interfaces.

Run the display efm session all command to check the EFM OAM status, and you can find that
EFM OAM is in detect state. Take the display on Switch B as an example.
[SwitchB] display efm session all
----------------------------------------------------------------------
Step 4 Configure association between EFM OAM modules.

[SwitchB] oam-mgr
[SwitchB-oam-mgr] oam-bind efm interface gigabitethernet 1/0/0 efm interface
In the OAM management view, run the display this command to check association. You can
find that there are two unidirectional association configuration records, whose directions are
mutually reverse.
[SwitchB-oam-mgr] display this
#
oam-mgr
oam-bind ingress efm interface GigabitEthernet1/0/0 egress efm interface Gigabi
tEthernet2/0/0
oam-bind ingress efm interface GigabitEthernet2/0/0 egress efm interface Gigabi
tEthernet1/0/0
#

# On SwitchC, enable the function of sending debugging information to a terminal.
<SwitchC> terminal debugging
<SwitchC> terminal monitor

# Shut down GE 1/0/0 on SwitchA and simulate link faults.

# Fault messages between SwitchA and SwitchB are transmitted to SwitchC through the
association mechanism. Then alarms are generated on SwitchC.
<SwitchC>
Mar 9 2010 14:52:33 SwitchC %%01EFM/2/NONTHRESHOLD(l): OID 1.3.6.1.4.1.2011.5
.25.136.1.6.5 Non-threshold-crossing event occurred. (InterfaceName=GigabitEther
net1/0/0, EventLogIndex=0, EventLogTimestamp=148983996, EventLogOui=[01.80.c2 (h
ex)], EventLogType=258, EventLogLocation=2, EventLogRunningTotal=0 3)
----End
Configuration Files
#
sysname SwitchA
#
efm enable
#
efm enable
bpdu bridge enable
#
return

#
sysname SwitchB
#
efm enable
#
efm mode passive
efm enable
bpdu bridge enable
#
efm enable
bpdu bridge enable
#
oam-mgr
Gigabi
tEthernet2/0/0
Gigabi
tEthernet1/0/0
#
return

#
sysname SwitchC
#
efm enable
#
efm mode passive
efm enable
bpdu bridge enable
#
return

5.20.8 Example for Configuring Association Between an Ethernet

CFM Module and an Interface
As shown in Figure 5-22, CFM is used on a direct link and a multi-hop link. Ethernet CFM is
configured between SwitchA and SwitchB, and Ethernet CFM is associated with GE 1/0/1 of
SwitchA. When the CFM OAM module on SwitchA detects the connectivity fault on the link
between SwitchA and SwitchB, it shuts down GE 1/0/1. In this case, the peer device of
SwitchA detects the fault.
Figure 5-22 Networking diagram for associating an Ethernet CFM module with an interface
CFM OAM
GE1/0/1 GE1/0/0 GE2/0/1

SwitchC SwitchA SwitchB
Interface associated with CFM OAM
1. Configure Ethernet CFM on SwitchA and SwitchB.
2. Associate an Ethernet CFM module with GE 1/0/1 on SwitchA.
Procedure
Step 1 Create VLANs and add interfaces to the VLANs.
[SwitchA] vlan 10
[SwitchB] vlan 10
Step 2 Enable Ethernet CFM.

# Enable Ethernet CFM globally on SwitchA.
## Create the MD, MA, MEP, and RMEP on SwitchA.

[SwitchA]cfm md md1
[SwitchA-md-md1]ma ma1
[SwitchA-md-md1-ma-ma1] ccm-interval 1000
[SwitchA-md-md1-ma-ma1] mep mep-id 2 interface gigabitethernet 1/0/0 outward
# Enable Ethernet CFM globally on SwitchB.

## Create the MD, MA, MEP, and RMEP on SwitchB.

[SwitchB]cfm md md1
[SwitchB-md-md1]ma ma1
[SwitchB-md-md1-ma-ma1] map vlan 10
[SwitchB-md-md1-ma-ma1] ccm-interval 1000
[SwitchB-md-md1-ma-ma1] mep mep-id 1 interface gigabitethernet 2/0/1 outward
[SwitchB-md-md1-ma-ma1] remote-mep mep-id 2
[SwitchB-md-md1-ma-ma1] mep ccm-send enable
[SwitchB-md-md1-ma-ma1] remote-mep ccm-receive enable
[SwitchB-md-md1-ma-ma1] quit
Run the display cfm mep and display cfm remote-mep commands on SwitchA or SwitchB. If
information about the MEP and RMEP is displayed, it indicates that the configuration is
successful. The displayed information on SwitchB is as follows:
[SwitchB]display cfm mep md md1
The total number of MEPs is : 1
--------------------------------------------------
MD Name : md1
MD Name Format : md-name
Level : 0
MA Name : ma1
MEP ID : 1
Vlan ID : 10
VSI Name : --
L2VC ID : --
Interface Name : GigabitEthernet2/0/1
CCM Send : enabled
Direction : outward
MAC Address : 0018-2000-0083
[SwitchB] display cfm remote-mep md md1
--------------------------------------------------
MD Name : md1
Level : 0
MA Name : ma1
RMEP ID : 2
Vlan ID : 10
VSI Name : --
L2VC ID : --
MAC : --
CFM Status : up
Step 3 Associate an Ethernet CFM module with an interface.
Associate an Ethernet CFM module with an interface on SwitchA.

[SwitchA] oam-mgr
[SwitchA-oam-mgr] oam-bind cfm md md1 ma ma1 trigger if-down interface
GigabitEthernet 1/0/1

Shut down GE 1/0/0 on SwitchA.
After the interface of SwitchA is shut down, the OAM management module reports the fault to
GE 1/0/1. Then GE 1/0/1 is triggered to go Down.
[SwitchA] display interface gigabitethernet1/0/1
(1AG)
Last physical up time : 2009-08-06 01:45:45 UTC+03:00 DST
Last physical down time : 2009-08-03 00:56:27 UTC+03:00 DST
Current system time: 2009-08-06 01:49:45
Mdi : NORMAL
Input peak rate 12066605600 bits/sec,Record time: 2009-07-26 20:05:07
Output peak rate 12066653800 bits/sec,Record time: 2009-07-26 20:05:07

CRC: 0, Giants: 0

Buffers Purged: 0

----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10

#
cfm enable
#
#
#
cfm md md1
ma ma1
map vlan 10
ccm-interval 10000
mep mep-id 2 interface GigabitEthernet1/0/0 outward
remote-mep mep-id 1
#
oam-mgr
oam-bind ingress interface GigabitEthernet1/0/1 egress cfm md md1 ma ma1
#
return
#
sysname SwitchB
#
vlan batch 10
#
cfm enable
#
#
cfm md md1
ma ma1
map vlan 10
ccm-interval 10000
remote-mep mep-id 2
#
return
5.20.9 Example for Configuring Association Between an EFM OAM

Module and an Ethernet CFM Module
As shown in Figure 5-23, to implement end-to-end link fault detection, you need to enable EFM
OAM between Switch A and Switch B and between Switch C and Switch D. Enable Ethernet
CFM between Switch B and Switch C. When a fault occurs on the link between Switch A and
Switch B, Ethernet CFM is triggered to send trap message to Switch D. When a fault occurs on
the link between Switch C and Switch D, Ethernet CFM is triggered to send trap message to
Switch A.

Figure 5-23 Networking diagram for configuring association between an EFM OAM module
and an Ethernet CFM module
SwitchA SwitchB SwitchC SwitchD
EFM CFM EFM
VLAN10 VLAN10
GE2/0/0 GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0 GE1/0/0 GE1/0/0 GE2/0/0

2. Configure EFM OAM between Switch A and Switch B.
3. Configure Ethernet CFM between the Switch B and Switch C.
4. Configure EFM OAM between Switch C and Switch D.
5. Configure association between an EFM OAM module and an Ethernet CFM module on
Switch B and Switch C.
Procedure
Step 1 Create VLAN 10 and add interfaces to VLAN 10.
Step 2 Enable EFM OAM globally on Switch A and Switch B.
[Quidway] system-view
Step 3 Configure Ethernet CFM between the Switch B and Switch C.
[SwitchB] cfm md md1
[SwitchB-md-md1] ma ma1


[SwitchB-md-md1-ma-ma1] return
[SwitchC] cfm enable
[SwitchC-md-md1-ma-ma1] map vlan 10
[SwitchC-md-md1-ma-ma1] mep ccm-send enable
[SwitchC-md-md1-ma-ma1] remote-mep ccm-receive enable
[SwitchC-md-md1-ma-ma1] return
Step 4 Configure EFM OAM between Switch C and Switch D.

# Configure Switch D.
[SwitchD] efm enable
[SwitchD-GigabitEthernet1/0/0] bpdu bridge enable
[SwitchD-GigabitEthernet1/0/0] efm mode passive
[SwitchD-GigabitEthernet1/0/0] efm enable
Step 5 Configure association between an EFM OAM module and an Ethernet CFM module.
# Associate EFM OAM between Switch A and Switch B with Ethernet CFM between Switch
B and Switch C in both directions. That is, enable the EFM OAM and Ethernet CFM modules
to send trap messages to each other.
[SwitchB] oam-mgr
[SwitchB-oam-mgr] oam-bind cfm md md1 ma ma1 efm interface gigabitethernet 1/0/0
# Associate EFM OAM between Switch C and Switch D with Ethernet CFM between Switch
B and Switch C in both directions. That is, enable the EFM OAM and Ethernet CFM modules
to send trap messages to each other.
[SwitchC] oam-mgr
[SwitchC-oam-mgr] oam-bind cfm md md1 ma ma1 efm interface gigabitethernet 1/0/0

# On Switch D, enable the function of sending debugging information to a terminal.
<SwitchD> terminal debugging
<SwitchD> terminal monitor
# Shut down GE 1/0/0 on Switch A to simulate a link fault.

After the preceding configuration is complete, when EFM OAM between Switch A and Switch
B detects a fault, Ethernet CFM reports the fault to EFM OAM running between Switch C and
Switch D.

<SwitchD>
Nov 23 2007 18:31:27-05:00 SwitchD %%01EFM/2/NONTHRESHOLD(l)[0]:OID 1.3.6.1.4.
1.2011.5.25.136.1.6.5 Non-threshold-crossing event occurred. (InterfaceName=Giga
bitEthernet1/0/0, EventLogIndex=0, EventLogTimestamp=7357971, EventLogOui=[01.80
.c2 (hex)], EventLogType=258, EventLogLocation=1, EventLogRunningTotal=0 1)
Nov 23 2007 18:31:27-05:00 SwitchD %%01OAMMGR/4/CFM_TO_EFM(l)[1]:802.1AG notif
ied malfunction to 802.3AH. (Ma=ma1, Md=md1, InterfaceName=GigabitEthernet1/0/0,
FaultState=1)
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
efm enable
#
efm mode passive
efm enable
bpdu bridge enable
#
#
return

#
sysname SwitchB
#
vlan batch 10
#
efm enable
#
cfm enable
#
efm enable
bpdu bridge enable
#
#
cfm md md1
ma ma1
map vlan 10
mep ccm-send enable
remote-mep mep-id 2
#
oam-mgr
#
return


#
sysname SwitchC
#
vlan batch 10
#
efm enable
#
cfm enable
#
efm enable
bpdu bridge enable
#
#
cfm md md1
ma ma1
map vlan 10
mep ccm-send enable
remote-mep mep-id 1
#
oam-mgr
#
return

#
sysname SwitchD
#
vlan batch 10
#
efm enable
#
efm mode passive
efm enable
bpdu bridge enable
#
#
return
5.20.10 Example for Configuring Association Between Ethernet

CFM with Ethernet CFM
As shown in Figure 5-24, Ethernet CFM is configured between Switch A and Switch B, and
between Switch B and Switch C. When a fault occurs on the link between Switch A and Switch
B, Ethernet CFM is triggered to send fault messages to Switch C. Then, alarms are generated
on Switch C.

Figure 5-24 Networking diagram for configuring association between Ethernet CFM and
Ethernet CFM
GE1/0/0 GE2/0/0
GE1/0/0 GE2/0/0
CFM CFM
MEP in MA1
MEP in MA2

2. Configure Ethernet CFM between Switch A and Switch B, and between SwitchB and
Switch C.
3. Configure association between Ethernet CFM and Ethernet CFM on Switch B and Switch
C.
Procedure
Step 1 Create VLANs and add interfaces to the VLANs.
Step 2 Configure Ethernet CFM between Switch A and Switch B.
Step 3 Configure Ethernet CFM between Switch B and Switch C.


[SwitchC] cfm enable
[SwitchC-md-md1-ma-ma2] map vlan 20
[SwitchC-md-md1-ma-ma2] mep ccm-send enable
[SwitchC-md-md1-ma-ma2] remote-mep ccm-receive enable
[SwitchC-md-md1-ma-ma2] quit
[SwitchC-md-md1] quit
Run the display cfm remote-mep command on Switch B to check the CFM status, and you can
find that the CFM status is Up.
[SwitchB] display cfm remote-mep
--------------------------------------------------
MD Name : md1
Level : 0
MA Name : ma1
RMEP ID : 1
Vlan ID : 10
VSI Name : --
L2VC ID : --
MAC : --
CFM Status : up
MD Name : md2
Level : 0
MA Name : ma2
RMEP ID : 2
Vlan ID : 20
VSI Name : --
L2VC ID : --
MAC : --
CFM Status : up
Step 4 Configure association between Ethernet CFM and Ethernet CFM.

# Associate Ethernet CFM between Switch A and Switch B with Ethernet CFM between Switch
B and Switch C in both directions. That is, enable Ethernet CFM modules to send trap messages
to each other.
[SwitchB] oam-mgr
[SwitchB-oam-mgr] oam-bind cfm md md1 ma ma1 cfm md md1 ma ma2

Shut down GE 2/0/0 of Switch B. Run the display cfm remote-mep command on Switch A to
check the CFM status between Switch A and Switch B, and you can find that the CFM status is
Down.

[SwitchA]display cfm remote-mep

--------------------------------------------------
MD Name : md1
Level : 0
MA Name : ma1
RMEP ID : 2
Vlan ID : 10
VSI Name : --
L2VC ID : --
MAC : --
CFM Status : down
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
cfm enable
#
#
cfm md md1
ma ma1
map vlan 10
remote-mep mep-id 2
#
return

#
sysname SwitchB
#
vlan batch 10 20
#
cfm enable
#
#
#
cfm md md1
ma ma1
map vlan 10
remote-mep mep-id 1
ma ma2
map vlan 20


remote-mep mep-id 2
#
oam-mgr
#
return

#
sysname SwitchC
#
vlan batch 20
#
cfm enable
#
#
cfm md md1
ma ma2
map vlan 20
remote-mep mep-id 1
#
return
5.20.11 Example for Associating Ethernet CFM with RRPP

As shown in Figure 5-25, UPEA, UPEB, UPEC, and PE-AGG constitute an RRPP single ring.
VLANs 100 to 300 are configured on the CE; packets are transmitted on ring 1 of domain 1.
Ethernet CFM is configured between UPEA and PE-AGG, and Ethernet CFM is associated with
primary and secondary interfaces on the RRPP ring.

Figure 5-25 Networking diagram for associating Ethernet CFM and RRPP multi-instance
UPEB
GE/1/0/0 GE2/0/0
CE1 PE-AGG
VLAN 100-300 GE2/0/0 GE/1/0/0
Ring 1 Backbone
UPEA Master 1 network
GE/1/0/0 GE2/0/0
Domain 1 ring 1
GE2/0/0 GE/1/0/0
UPEC
For details on the protected VLAN in domain 1, and the instance that the protected VLAN
belongs to, see Table 5-2.
Table 5-2 Mapping between instances and protected VLANs
Ring Control VLAN Instance ID of Data VLAN ID Instance ID of

ID ID Control VLAN Data VLAN
Domain VLAN 5 and Instance 1 VLANs 100 to 300 Instance 1

1 VLAN 6
For details on the master node and primary and secondary interfaces on the master node of the
ring, see Table 5-3.
Table 5-3 Master node, and primary and secondary interfaces on the master node
Ring ID Master Node Primary Interface Secondary

Interface
1. Map instance 1 to VLANs 100 to 300.

2. Add UPEA, UPEB, UPEC, and PE-AGG to ring 1 in domain 1.

3. Configure protected VLAN and control VLAN for domain 1.

4. Configure PE-AGG as the master node and configure UPEA, UPEB, and UPE C as transit
nodes on ring 1 in domain 1.
5. Configure Ethernet CFM on PE-AGG and UPEA to detect faults on the two links between
PE-AGG and UPEA.
6. Configure association between Ethernet CFM and primary and secondary interfaces on the
RRPP ring on PE-AGG.
Data Preparation
l IDs of instances
Procedure
l Configure UPEA.
# Create data VLANs 100 to 300 on UPEA.
# Create instance 1, and map control VLANs 5 and 6 and data VLANs 100 to 200 in domain
1 to instance 1.
<UPEA> system-view

l Configure UPEB.
# Create data VLANs 100 to 300 on UPEB.
1 to instance 1.
<UPEB> system-view

l Configure UPEC.
# Create data VLANs 100 to 300 on UPEC.
1 to instance 1.
<UPEC> system-view

l Configure PE-AGG.
1 to instance 1.
<PE-AGG> system-view


After the preceding configuration, run the following command to view the mapping between
instances and VLANs. Take the display on UPEA as an example:
<UPEA> display stp region-configuration
Oper configuration
Format selector :0
Region name :001820000083
Revision level :0

0 1 to 4, 7 to 9, 12 to 99, 301 to 4094
1 5 to 6, 100 to 300
Step 2 Configure the interfaces to be added to the RRPP ring.

l Configure UPEA.
# On UPEA, disable STP on the interfaces to be added to the RRPP ring. Configure the RRPP
interfaces to allow packets of VLANs 100 to 300 to pass through.
<UPEA> system-view
l Configure UPEB.
# On UPEB, disable STP on the interfaces to be added to the RRPP ring. Configure the RRPP
<UPEB> system-view
l Configure UPEC.
# On UPEC, disable STP on the interfaces to be added to the RRPP ring. Configure the RRPP

<UPEC> system-view
l Configure PE-AGG.
# On PE-AGG, disable STP on the interfaces to be added to the RRPP ring. Configure the
Step 3 Create RRPP domains and configure protected VLANs and control VLANs.
l Configure UPEA.
# Configure the VLANs mapping instance 1 as protected VLANs in domain 1, and configure
<UPEA> system-view
l Configure UPEB.
<UPEB> system-view
l Configure UPEC.
<UPEC> system-view
l Configure PE-AGG.


l Configure UPEA.
# Configure UPEA as a transit node of ring 1 in domain 1 and specify primary and secondary
interfaces.
<UPEA> system-view
l Configure UPEB.
# Configure UPEB as a transit node of ring 1 in domain 1 and specify primary and secondary
interfaces.
<UPEB> system-view
l Configure UPEC.
# Configure UPEC as a transit node of ring 1 in domain 1 and specify primary and secondary
interfaces.
<UPEC> system-view
l Configure PE-AGG.
# Configure PE-AGG as the master node of ring 1 in domain 1, GE 1/0/0 as the primary
interface, and GE 2/0/0 as the secondary interface.
Step 5 Enable RRPP.

l Configure UPEA.
# Enable RRPP.
<UPEA> system-view
[UPEA] rrpp enable
l Configure UPEB.
# Enable RRPP.
<UPEB> system-view
[UPEB] rrpp enable
l Configure UPEC.
# Enable RRPP.

<UPEC> system-view
[UPEC] rrpp enable
l Configure PE-AGG.
# Enable RRPP.
perform the following operations to verify the configuration. Take the display on UPEA and
PE-AGG as examples.
l On UPEA, run the display rrpp brief or display rrpp verbose domain command. The result
is as follows:
# Check the brief information of RRPP on UPEA.
<UPEA> display rrpp brief

Domain Index : 1
----------------------------------------------------------------------------
RRPP is enabled on UPEA, VLAN 5 is the control VLAN and VLANs mapping instance 1
are the protected VLANs in domain 1, and UPE A is a transit node on ring 1; GE 1/0/0 is the
primary interface, and GE 2/0/0 is the secondary interface.
# Check detailed information about UPEA in domain 1.
<UPEA> display rrpp verbose domain 1
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Transit
Ring State : LinkUp
mapping instance 1 are the protected VLANs; UPEA is a transit node in domain 1 and is in
LinkUp state; RRPP is enabled on UPEA.
# Check the brief information of RRPP on PE-AGG.
<PE-AGG> display rrpp brief


Domain Index : 1
Enabled
---------------------------------------------------------------------------
The preceding information shows that RRPP is enabled on PE-AGG. In domain 1, VLAN 5
is the major control VLAN, VLANs mapping instance 1 are the protected VLANs, and PE-
AGG is the master node on ring 1; GE 1/0/0 is the primary interface, and GE 2/0/0 is the
secondary interface.
# Check detailed information about PE-AGG in domain 1.
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
mapping instance 1 are the protected VLANs. PE-AGG is the master node in domain 1 and
is in Complete state. GE 1/0/0 is the primary interface, and GE 2/0/0 is the secondary
interface.
Step 6 Configure Ethernet CFM.
# Configure UPEA.
[UPEA] cfm md md1
[UPEA-md-md1] ma ma1
[UPEA-md-md1-ma-ma1] map vlan 100
[UPEA-md-md1-ma-ma1] mep mep-id 1 interface GigabitEthernet2/0/0 outward
[UPEA-md-md1-ma-ma1] remote-mep mep-id 2
[UPEA-md-md1-ma-ma1] remote-mep ccm-receive mep-id 2 enable
[UPEA-md-md1-ma-ma1] mep ccm-send enable
[UPEA-md-md1-ma-ma1] quit
[UPEA-md-md1] ma ma2
[UPEA-md-md1-ma-ma2] map vlan 100
[UPEA-md-md1-ma-ma2] mep mep-id 3 interface GigabitEthernet1/0/0 outward
[UPEA-md-md1-ma-ma2] remote-mep mep-id 4
[UPEA-md-md1-ma-ma2] remote-mep ccm-receive mep-id 4 enable
[UPEA-md-md1-ma-ma2] mep ccm-send enable
[UPEA-md-md1-ma-ma2] quit
# Configure PE-AGG.
[PE-AGG] cfm md md1
[PE-AGG-md-md1] ma ma1
[PE-AGG-md-md1-ma-ma1] map vlan 100
[PE-AGG-md-md1-ma-ma1] mep mep-id 2 interface gigabitethernet1/0/0 outward
[PE-AGG-md-md1-ma-ma1] remote-mep mep-id 1
[PE-AGG-md-md1-ma-ma1] remote-mep ccm-receive mep-id 1 enable
[PE-AGG-md-md1-ma-ma1] mep ccm-send enable
[PE-AGG-md-md1-ma-ma1] quit
[PE-AGG-md-md1] ma ma2
[PE-AGG-md-md1-ma-ma2] map vlan 100
[PE-AGG-md-md1-ma-ma2] mep mep-id 4 interface gigabitethernet2/0/0 outward

[PE-AGG-md-md1-ma-ma2] remote-mep mep-id 3

[PE-AGG-md-md1-ma-ma2] remote-mep ccm-receive mep-id 3 enable
[PE-AGG-md-md1-ma-ma2] mep ccm-send enable
[PE-AGG-md-md1-ma-ma2] quit
On UPEA or PE-AGG, run the display cfm remote-mep command to check the status of
Ethernet CFM. You can find that Ethernet CFM is in Up state. Take the display on PE-AGG as
an example.
[PE-AGG] display cfm remote-mep
--------------------------------------------------
MD Name : md1
Level : 0
MA Name : ma1
RMEP ID : 1
Vlan ID : 100
VSI Name : --
L2VC ID : --
MAC : --
CFM Status : up
MD Name : md1
Level : 0
MA Name : ma2
RMEP ID : 3
Vlan ID : 100
VSI Name : --
L2VC ID : --
MAC : --
CFM Status : up
Step 7 Configure the association between Ethernet CFM and interfaces.

# Configure PE-AGG.
[PE-AGG] oam-mgr
[PE-AGG-oam-mgr] oam-bind cfm md md1 ma ma1 trigger if-down interface GigabitE
thernet 1/0/0
[PE-AGG-oam-mgr] oam-bind cfm md md1 ma ma2 trigger if-down interface GigabitE
thernet 2/0/0

Shut down GE 1/0/0 on UPEB and simulate fault on the link of GE 1/0/0 and run the display
cfm remote-mep command on PE-AGG to check the CFM status. The following information
is displayed:
[PE-AGG] display cfm remote-mep
--------------------------------------------------
MD Name : md1
Level : 0
MA Name : ma1
RMEP ID : 1
Vlan ID : 100
VSI Name : --
L2VC ID : --
MAC : --
CFM Status : down

MD Name : md1
Level : 0
MA Name : ma2
RMEP ID : 3
Vlan ID : 100
VSI Name : --
L2VC ID : --
MAC : --
CFM Status : up
Run the display this interface command on PE-AGG to check the status of GE 1/0/0, and you
can find that GE 1/0/0 is in TRIGGER DOWN (1AG) state.
[PE-AGG-GigabitEthernet1/0/0] display this interface
(1AG)
Last physical down time : 2009-07-22 18:00:16 DST
Mdi : NORMAL
Input peak rate 0 bits/sec,Record time: -
Output peak rate 0 bits/sec,Record time: -

CRC: 0, Giants: 0

Buffers Purged: 0

Run the display rrpp verbose domain 1 command on PE-AGG to check the status of the RRPP
ring and interface, and following information is displayed:
Domain Index : 1
RRPP Ring : 1

Ring Level : 0
Node Mode : Master
Ring State : Failed
Primary port : GigabitEthernet1/0/0 Port status: DOWN
The status of the RRPP ring becomes Failed and the secondary interface changes from
BLOCKED to UP.
Re-enable GE 1/0/0 of UPEB, and you can find that the CFM status on PE-AGG becomes UP.
Run the display rrpp verbose domain 1 command on PE-AGG to check the status of the RRPP
ring and interface, and you can find that the RRPP ring becomes Complete as follows:
Domain Index : 1
RRPP Ring : 1
Ring Level : 0
Node Mode : Master
----End
Configuration Files
l Configuration file of UPEA
#
sysname UPEA
#
#
rrpp enable
#
cfm enable
#
instance 1 vlan 5 6 100 to 300
#
rrpp domain 1
control-vlan 5
ring 1 enable
#
stp disable
#
stp disable
#
cfm md md1
ma ma1
map vlan 100


remote-mep mep-id 2
ma ma2
map vlan 100
remote-mep mep-id 4
#
oam-mgr
if-down
if-down
#
return
l Configuration file of UPEB
#
sysname UPEB
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
#
stp disable
#
stp disable
#
return
l Configuration file of UPEC
#
sysname UPEC
#
#
rrpp enable
#
#
rrpp domain 1
control-vlan 5

ring 1 enable
#
stp disable
#
stp disable
#
Return
#
sysname PE-AGG
#
#
rrpp enable
#
cfm enable
#
#
rrpp domain 1
control-vlan 5
ring 1 enable
#
stp disable
#
stp disable
#
cfm md md1
ma ma1
map vlan 100
remote-mep mep-id 1
ma ma2
map vlan 100
remote-mep mep-id 3
#
oam-mgr
if-down
if-down
#
return

5.20.12 Example for Associating Ethernet CFM with MSTP
As shown in Figure 5-26, each CE is connected to two PEs through sub-interfaces. Ethernet
CFM (802.1ag) is configured between GE 1/0/1 of CE1 and GE 1/0/1 of PE2 and between GE
1/0/2 of CE1 and GE 1/0/2 of PE1. MSTP is run on directly connected interfaces between CE1
and PE1 and between CE1 and PE2; PE1 is configured as the root switch; PE2 is configured as
the secondary root switch; MSTP blocks interfaces of the secondary root switch to prevent loops.
When Ethernet CFM detects faults on the link between CE1 and PE1, OAM Manager notifies
the MSTP module of the fault. Then, the interface notifies MSTP through association of OAM
Manager and interface. The secondary root switch becomes the root switch of a specified MSTI.
Protection of links connected to the VPLS network is implemented.
Figure 5-26 Networking diagram for associating Ethernet CFM with MSTP
PE1
GE1/0/1
GE1/0/2.1
GE1/0/2
C E1 VPLS network
GE1/0/1 PE3
GE1/0/1.1
GE1/0/2
PE2
NOTE
In this example, only the configuration of MSTP, CFM, and association is mentioned. The VPLS
configuration, however, is not mentioned.
1. Create VLANs.
2. Create sub-interfaces on PE1 and PE2 and add the sub-interfaces to a VLAN so that PE1
and PE2 can be connected to the VPLS network.
3. Configure PE1 as the CIST root.
4. Configure PE1, PE2, and CE1 to be in the same MST region named RG1 and create MSTI
1.
5. In RG1, PE1 functions as the CIST root and the root switch of MSTI 1, and PE2 functions
as the secondary root switch of MSTI 1.
6. Configure root protection on PE2.
7. Configure Ethernet CFM between PE1 and CE1, and between PE2 and CE1.
8. Configure association of Ethernet CFM and interfaces. After the root switch fails, the
secondary root switch immediately switches to the root switch of the specified MSTI.

Data Preparation
l MST region named RG1 that PE1, PE2, PE3, and CE1 belongs to
l Numbers of the GE interfaces, as shown in Figure 5-26
l VLAN IDs 1 to 19
Procedure
Step 1 Configure MSTP on PE1.
# Create VLANs 1-20.
<PE1> system-view
[PE1] vlan batch 1 to 19
# Create a sub-interface on PE1 and add the sub-interface to the VLAN.

[PE1] interface gigabitethernet1/0/2.1
[PE1-GigabitEthernet1/0/2.1] control-vid 100 dot1q-termination
[PE1-GigabitEthernet1/0/2.1] dot1q termination vid 20
[PE1-GigabitEthernet1/0/2.1] quit
# Configure the MST region on PE1.

[PE1] stp region-configuration
[PE1-mst-region] region-name RG1
[PE1-mst-region] instance 1 vlan 1 to 20
# Activate the configuration of the MST region.

[PE1-mst-region] active region-configuration
[PE1-mst-region] quit
# Configure PE1 as the root switch.

[PE1] stp instance 1 root primary
# Configure PE1 to use Huawei private algorithm to calculate the path cost.
[PE1] stp pathcost-standard legacy
# Add GE 1/0/2 to the VLANs.

[PE1] interface GigabitEthernet 1/0/2
[PE1-GigabitEthernet1/0/2] port link-type trunk
[PE1-GigabitEthernet1/0/2] port trunk allow-pass vlan 1 to 19
# Enable root protection on interface GE 1/0/2.

[PE1-GigabitEthernet1/0/2] stp root-protection
Step 2 Configure MSTP on PE2.

# Create VLANs 1-20.
<PE2> system-view
[PE2] vlan batch 1 to 19
# Create a sub-interface on PE2 and add the sub-interface to the VLAN.

[PE2] interface gigabitethernet1/0/1.1
[PE2-GigabitEthernet1/0/1.1] control-vid 100 dot1q-termination

[PE2-GigabitEthernet1/0/1.1] dot1q termination vid 20

[PE2-GigabitEthernet1/0/1.1] quit
# Configure the MST region on PE2.

[PE2] stp region-configuration
[PE2-mst-region] region-name RG1
[PE2-mst-region] instance 1 vlan 1 to 20

[PE2-mst-region] active region-configuration
[PE2-mst-region] quit
# Configure PE2 as the secondary root switch.

[PE2] stp instance 1 root secondary
# Configure PE2 to use Huawei private algorithm to calculate the path cost.
[PE2] stp pathcost-standard legacy

[PE2-GigabitEthernet1/0/1] port link-type trunk
[PE2-GigabitEthernet1/0/1] port trunk allow-pass vlan 1 to 19
# Enable root protection on GE 1/0/1.

[PE2-GigabitEthernet1/0/1] stp root-protection
Step 3 Configure MSTP on CE1.
# Configure the MST region on CE1.

[CE1-mst-region] region-name RG1
[CE1-mst-region] instance 1 vlan 1 to 20

# Configure CE1 to use Huawei private algorithm to calculate the path cost.
[CE1] stp pathcost-standard legacy
# Create VLANs 1 to 20.


[CE1] interface GigabitEthernet 1/0/1

[CE1] interface GigabitEthernet 1/0/2

After the configuration, run the display stp brief command on PEs and CE1 to check the status
and protection type of the interface, as follows:
[PE1] display stp brief
MSTID Port Role STP State Protection
0 GigabitEthernet1/0/2 DEST FORWARDING ROOT
1 GigabitEthernet1/0/2 DEST FORWARDING ROOT
0 GigabitEthernet1/0/1 DEST DISCARDING Root
1 GigabitEthernet1/0/1 DEST DISCARDING Root
Step 4 Configure Ethernet CFM.

# Configure CE1.
[CE1] cfm md md1
[CE1-md-md1] ma ma1
[CE1-md-md1-ma-ma1] map vlan 10
[CE1-md-md1-ma-ma1] mep mep-id 1 interface gigabitethernet1/0/2 outward
[CE1-md-md1-ma-ma1] remote-mep mep-id 2
[CE1-md-md1-ma-ma1] remote-mep ccm-receive mep-id 2 enable
[CE1-md-md1-ma-ma1] mep ccm-send enable
[CE1-md-md1-ma-ma1] quit
[CE1-md-md1] ma ma2
[CE1-md-md1-ma-ma2] map vlan 10
[CE1-md-md1-ma-ma2] mep mep-id 3 interface gigabitethernet1/0/1 outward
[CE1-md-md1-ma-ma2] remote-mep mep-id 4
[CE1-md-md1-ma-ma2] remote-mep ccm-receive mep-id 4 enable
[CE1-md-md1-ma-ma2] mep ccm-send enable
[CE1-md-md1-ma-ma2] quit
# Configure PE1.
[PE1] cfm md md1
[PE1-md-md1] ma ma1
[PE1-md-md1-ma-ma1] map vlan 10
[PE1-md-md1-ma-ma1] mep mep-id 2 interface gigabitethernet1/0/2 outward
[PE1-md-md1-ma-ma1] remote-mep mep-id 1
[PE1-md-md1-ma-ma1] remote-mep ccm-receive mep-id 1 enable
[PE1-md-md1-ma-ma1] mep ccm-send enable
[PE1-md-md1-ma-ma1] quit
# Configure PE2.
[PE2] cfm md md1
[PE2-md-md1] ma ma2
[PE2-md-md1-ma-ma2] map vlan 10
[PE2-md-md1-ma-ma2] mep mep-id 4 interface gigabitethernet1/0/1 outward
[PE2-md-md1-ma-ma2] remote-mep mep-id 3
[PE2-md-md1-ma-ma2] remote-mep ccm-receive mep-id 3 enable
[PE2-md-md1-ma-ma2] mep ccm-send enable
[PE2-md-md1-ma-ma2] quit
On CE1 or PE, run the display cfm remote-mep command to check the status of Ethernet CFM,
and you can find that ma1 is in Up state and ma2 is in Down. Take the display on CE1 as an
example.
[CE1] display cfm remote-mep
--------------------------------------------------
MD Name : md1
Level : 0
MA Name : ma1
RMEP ID : 2
Vlan ID : 10
VSI Name : --
MAC : --


CFM Status : up
MD Name : md1
Level : 0
MA Name : ma2
RMEP ID : 4
Vlan ID : 10
VSI Name : --
MAC : --
CFM Status : down
Step 5 Associate Ethernet CFM with interfaces.
# Configure PE1.
[PE1] oam-mgr
[PE1-oam-mgr] oam-bind cfm md md1 ma ma1 trigger if-down interface GigabitEthernet
1/0/2
# Configure PE2.
[PE2-oam-mgr] oam-bind cfm md md1 ma ma2 trigger if-down interface GigabitEthernet
1/0/1
Disable PE1 from sending CCMs and simulate link faults.

[PE1-md-md1-ma-ma1] undo mep ccm-send enable
Run the display interface command on PE1 to check the status of GE 1/0/2, and you can find
that GE 1/0/2 is in TRIGGER DOWN (1AG) state.
[PE1] display interface gigabitethernet 1/0/2
(1AG)
Switch Port, PVID : 10, TPID : 8100(Hex), The Maximum Frame Length is 9216
Last physical down time : 2009-03-13 19:57:53
Mdi : NORMAL
Input peak rate 0 bits/sec, Record time: -
Output peak rate 0 bits/sec, Record time: -

CRC: 0, Giants: 0
Jabbers: 0, Fragments: 0


Buffers Purged: 0

Run the display stp brief command on PE2 to check the status and protection type of the
interface. The displayed information is as follows:
# Run the display stp brief command on PE2.

0 GigabitEthernet1/0/1 DESI FORWARDING ROOT
1 GigabitEthernet1/0/1 DESI FORWARDING ROOT
GE 1/0/1 on PE2 is the specified interface.
----End
Configuration Files
#
sysname PE1
#
vlan batch 1 to 19
#
stp instance 1 root primary
#
cfm enable
#
region-name RG1
#
#
stp root-protection
#
#
cfm md md1
ma ma1
map vlan 10
remote-mep mep-id 1
#
oam-mgr
if-down
oam-bind ingress cfm md md1 ma ma1 trigger if-down egress interface GigabitEthe
rnet1/0/2

#
return
#
sysname PE2
#
vlan batch 1 to 19
#
stp instance 1 root secondary
#
cfm enable
#
region-name RG1
#
#
#
#
cfm md md1
ma ma2
map vlan 10
remote-mep mep-id 3
#
oam-mgr
if-down
oam-bind ingress cfm md md1 ma ma2 trigger if-down egress interface GigabitEthe
rnet1/0/1
#
return
#
sysname CE1
#
vlan batch 1 to 20
#
cfm enable
#
region-name RG1
#
#
#
#
cfm md md1
ma ma1
map vlan 10


remote-mep mep-id 2
ma ma2
map vlan 10
remote-mep mep-id 4
#
return

Configuration Guide - Reliability 6 ITU-T Recommendation Y.1731 Configuration
6 ITU-T Recommendation Y.1731

Configuration
About This Chapter
Y.1731 defines frame loss detection and frame delay measurement between MEPs, which is
similar to the fault detection defined in IEEE 802.1ag.
6.1 Introduction to ITU-T Recommendation Y.1731

Y.1731, as an Operations, Administration and Maintenance (OAM) protocol organized by the
ITU-T, is used to implement end-to-end Metropolitan Area Network (MAN) connectivity
detection, loopback detection, and link trace. It also provides the performance monitoring
functions, including frame loss measurement, frame delay measurement, frame jitter
measurement, and throughput measurement.
6.2 ITU-T Recommendation Y.1731 Features Supported by the S9700
The Y.1731 features supported by the S9700 include one-way frame delay measurement and
two-way frame delay Measurement.
6.3 Configuring the One-way Frame Delay Measurement in a VLAN
You can configure the one-way frame delay measurement in the VLAN bound to an MA and
estimate the quality of services based on the calculated one-way frame delay.
6.4 Configuring the Two-way Frame Delay Measurement in a VLAN
You can configure the two-way frame delay measurement in the VLAN bound to an MA and
estimate the quality of services based on the calculated two-way frame delay.
6.5 Configuring VLAN AIS
By configuring the AIS function in an MA, you can suppress the MEP in an MD of a higher
level from sending alarms to the NMS.
This section provides several configuration examples of Y.1731.

6.1 Introduction to ITU-T Recommendation Y.1731

Y.1731, as an Operations, Administration and Maintenance (OAM) protocol organized by the
ITU-T, is used to implement end-to-end Metropolitan Area Network (MAN) connectivity
detection, loopback detection, and link trace. It also provides the performance monitoring
functions, including frame loss measurement, frame delay measurement, frame jitter
measurement, and throughput measurement.
Y.1731 is an OAM protocol organized by the ITU-T. It covers not only the contents defined by
IEEE 802.1ag but also combinations of OAM messages, including the Remote Defect Indication
(RDI), Locked Signal (LCK), Test Signal, Automatic Protection Switching (APS), Maintenance
Communication Channel (MCC), Experimental OAM (EXP), and Vendor Specific (VSP) for
fault management and performance monitoring, such as frame loss measurement (LM) and delay
measurement ( DM).
As shown in Figure 6-1, ITU-T Recommendation Y.1731 is commonly deployed on MEPs to
implement end-to-end fast fault detection and performance monitoring.
Figure 6-1 Application of ITU-T Recommendation Y.1731
MEP1 MEP2
MA
802.1ag/Y.1731
When a user considers that the purchased Ethernet tunnel services are of low quality or when
an operator needs to conduct their regular service level agreement (SLA) monitoring, ITU-T
Recommendation Y.1731, as defining performance testing tools, is applicable. For example,
ITU-T Recommendation Y.1731 supports the sending and receiving of Continuity Check
Messages (CCMs) to calculate frame loss ratio and bidirectional frame delay and jitter.
6.2 ITU-T Recommendation Y.1731 Features Supported by

the S9700
The Y.1731 features supported by the S9700 include one-way frame delay measurement and
two-way frame delay Measurement.
One-way Frame Delay Measurement

One-way frame delay measurement is performed on end-to-end MEPs. A MEP receives a DM
frame and returns a Delay Measurement Reply (DMR) to carry out the one-way frame delay
measurement. As shown in Figure 6-2, the process of one-way frame delay measurement is as
follows:

1. A MEP periodically sends DM frames carrying TxTimeStampf.

2. After receiving a DM frame, the remote MEP calculates the one-way frame delay based
on the following formula:
Frame delay = RxTimef - TxTimeStampf
The frame delay variation, namely, frame jitter, can be calculated based on the frame delay.
Jitter: is used as a measure of the variability over time of the frame delay across a network, and
is the absolute difference value between two delays.
Figure 6-2 Networking diagram of the one-way frame delay measurement

1DM PDU
MEP1 MEP2
MA
Y.1731
Two-way Frame Delay Measurement

You can configure the two-way frame delay measurement to collect the statistics of the delay
in bidirectional service traffic transmission.
Figure 6-3 Networking diagram of the two-way frame delay measurement
DMM
DMR
MEP1 MEP2
MA
Y.1731
The two-way frame delay measurement is generally performed on end-to-end MEPs. A MEP
receives a DM frame and returns a DMR frame to carry out the two-way frame delay
measurement. After the two-way frame delay measurement is configured, a MEP periodically
sends DM frames with the TxTimeStampf value (timestamp at the time of sending the DM
frame). After receiving the DM frame, the remote MEP adds the RxTimeStampf value
(timestamp at the time of receiving the DM frame) to the DM frame, generates a DMR frame
with the TxTimeStampb value (timestamp at the time of sending the DMR frame), and sends
the message to the requesting MEP. Every field in the DM frame is copied to the DMR frame

except that the source and destination MAC addresses are swapped and the message type is
changed from DM to DMR. Upon receiving the DMR frame, the requesting MEP calculates the
two-way frame delay based on the following formula:
Two-way frame delay = (RxTimeb - TxTimeStampf) - (TxTimeStampb - RxTimeStampf)
The frame delay variation, namely, frame jitter, can be calculated based on the frame delay.
Jitter: is used as a measure of the variability over time of the frame delay across a network, and
is the absolute difference value between two delays.
6.3 Configuring the One-way Frame Delay Measurement in

a VLAN
You can configure the one-way frame delay measurement in the VLAN bound to an MA and
estimate the quality of services based on the calculated one-way frame delay.

Before configuring the one-way frame delay measurement, familiarize yourself with the
You can configure the one-way frame delay measurement to collect statistics about the delay in
bidirectional service traffic transmission.
The one-way frame delay measurement is commonly performed on point-to-point MEPs. After
a MEP receives a Delay Measurement (DM) message from the remote MEP, it calculates the
time delay experienced across the network by comparing the timestamp in the DM frame and
the local time. During the one-way frame delay measurement, ensure that clocks on MEPs are
synchronous.
NOTE
Before enabling the one-way delay measurement in the VLAN on the local device, you must configure the
DM frame reception function on the remote device.
Before configuring the one-way delay measurement in the VLAN, complete the following tasks:
l Configuring synchronize clock, For the configuration procedure, see NTP Configuration
l Configuring VLAN, For the configuration procedure, see VLAN Configuration
Data Preparation
To configure the one-way delay measurement in the VLAN, you need the following data:

No. Data
2 ID of the MEP, name of the interface on which the MEP resides, and type of the MEP
3 Name of the VLAN bound to the MA
4 (Optional) Alarm threshold of the one-way frame delay measurement
6.3.2 Binding an MA to a VLAN

Binding an MA to a VLAN is a prerequisite for configuring the one-way frame delay
measurement in the VLAN.
Context
Do as follows on the devices configured with MEPs:
Procedure
Step 1 Run:
system-view
Step 2 Run:
cfm md md-name
Step 3 Run:
ma ma-name
Step 4 Run:
map vlan vlan-id
The MA is bound to a VLAN.
----End
6.3.3 (Optional) Setting an Alarm Threshold for the One-way Frame

Delay Measurement
Context

Procedure
Step 1 Run:
system-view
Step 2 Run:
cfm md md-name
Step 3 Run:
ma ma-name
Step 4 Run:
delay-measure one-way threshold threshold-value
An alarm threshold is set for the two-way frame delay measurement.
----End
6.3.4 Configuring DM Frame Reception on a Remote MEP

The One-way frame delay measurement can work normally only when DM frame reception is
configured on a remote MEP.
Context
Do as follows on a remote MEP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
cfm md md-name
Step 3 Run:
ma ma-name
Step 4 Run:
delay-measure one-way receive mep mep-id
DM frame reception is configured on the remote MEP.
----End

6.3.5 Enabling the One-way Frame Delay Measurement in a VLAN

The one-way frame delay measurement in a VLAN can work normally only after you enable
the one-way frame delay measurement in the VLAN.
Context
To implement the one-way frame delay measurement, you need to specify the remote MEP ID
or the destination MAC address, the interval for sending DM frames, and the number of DM
frames sent each time.
To implement one-way frame delay measurement, you need to specify the RMEP ID or the
destination MAC address, the interval for sending DM frames, and the measurement period.
l If the local MEP has not learned the MAC address of the RMEP, you must specify the
destination MAC address for one-way frame delay measurement.
l If the local MEP has learned the MAC address of the RMEP, you can specify the RMEP
ID for one-way frame delay measurement.
One-way frame delay measurement is implemented between the transmitting and receiving
MEPs by exchanging DM frames. After one-way frame delay measurement is configured, a
MEP periodically sends DM frames with the TxTimeStampf (the timestamp at the transmission
time of the DM frame). After receiving a DM frame, the RMEP parses the value of the
TxTimeStampf and compares this value with the RxTimef (the time at the reception of the DM
frame) and then calculates the one-way frame delay as:
Frame delay = RxTimef - TxTimeStampf
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name

Step 4 Run:
delay-measure one-way send mep mep-id { mac mac-address | remote-mep mep-id }
interval { 1000 | 10000 } count count-value [ peer-ip peer-ip [ vc-id vc-id ] ]
The two-way frame delay measurement is configured.
----End

After the one-way frame delay measurement is configured in a VLAN, you can view the statistics
about the delay in bidirectional service traffic transmission in the VLAN.

Prerequisites
All the configurations of the one-way frame delay measurement in a VLAN are complete.
Procedure
l Run the display y1731 statistic-type oneway-delay md md-name ma ma-name [ count
count-value ] command to check the performance statistics collected through Y.1731.
----End
Example
After the configurations, run the display y1731 statistic-type command on the devices where
MEPs reside, and you can view the value of the average delay.
[SwitchB] display y1731 statistic-type oneway-delay md md1 ma ma1
Latest one-way delay statistics:
--------------------------------------------------------------------------------
Index Delay(usec) Delay variation(usec)
--------------------------------------------------------------------------------
1 -2001626137 -
2 -2001625996 141
3 -2001625852 144
4 -2001625704 148
5 -2001625565 139
6 -2001625559 6
7 -2001625407 152
8 -2001625004 403
9 -2001609680 15324
10 -2001624860 15180
--------------------------------------------------------------------------------
Average delay(usec) : -2001623976 Average delay variation(usec) : 3515
Maximum delay(usec) : -2001609680 Maximum delay variation(usec) : 15324
Minimum delay(usec) : -2001626137 Minimum delay variation(usec) :
6
6.4 Configuring the Two-way Frame Delay Measurement in

a VLAN
You can configure the two-way frame delay measurement in the VLAN bound to an MA and
estimate the quality of services based on the calculated two-way frame delay.

Before configuring the two-way frame delay measurement, familiarize yourself with the
You can configure the two-way frame delay measurement to collect statistics about the delay in
bidirectional service traffic transmission.
The two-way frame delay measurement is commonly performed on end-to-end MEPs. After a
remote MEP receives a DMM frame from a local MEP, the remote MEP adds the RxTimeStampf
value (timestamp at the time of receiving the DMM frame) to the DMM frame, generates a DMR
frame with the TxTimeStampb value, and sends the message to the local MEP. Every field in

the DMM frame is copied to the DMR frame except that the source and destination MAC
addresses are swapped and the message type is changed from DMM to DMR. Upon receiving
the DMR frame, the local MEP calculates the two-way frame delay based on the timestamps.
NOTE
Before enabling the two-way delay measurement in the VLAN on the local device, you must configure the
DMM frame reception function on the remote device.
Before configuring the two-way delay measurement in the VLAN, complete the following tasks:
l Configuring VLAN, For the configuration procedure, see VLAN Configuration
Data Preparation
To configure the two-way delay measurement in the VLAN, you need the following data:
No. Data
3 Name of the VLAN bound to the MA
4 (Optional) Alarm threshold of the two-way frame delay measurement

Binding an MA to a VLAN is a prerequisite for configuring the one-way frame delay
measurement in the VLAN.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name

Step 4 Run:
map vlan vlan-id
The MA is bound to a VLAN.
----End
6.4.3 (Optional) Setting an Alarm Threshold for the Two-way Frame

Delay Measurement
You can set an alarm threshold for the two-way frame delay measurement in each MA. When
the two-way delay exceeds the alarm threshold, an alarm is generated.
Context
Do as follows on the devices configured with MEPs on two ends of the link:
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name

Step 4 Run:
delay-measure two-way threshold threshold-value
An alarm threshold is set for the two-way frame delay measurement.
----End
6.4.4 Configuring Two-Way DMM Packet Receiving

Two-way frame delay measurement can work properly only when the devices at both ends are
enabled to receive DMM packets.
Context
The following operations must performed on both the local and remote MEP devices.
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name

Step 4 Run:
delay-measure two-way receive mep mep-id
Two way DMM packet receiving is enabled.
----End
6.4.5 Enabling the Two-way Frame Delay Measurement in a VLAN

The two-way frame delay measurement in a VLAN can work normally only after you enable
the two-way frame delay measurement in the VLAN.
Context
To implement the two-way frame delay measurement, you need to specify the remote MEP ID
or the destination MAC address, the interval for sending DMM frames, and the number of DMM
frames sent each time.
l If the local MEP has not learnt the MAC address of the remote MEP, you must specify the
destination MAC address for the two-way frame delay measurement.
l If the local MEP has learnt the MAC address of the remote MEP, you can specify the remote
MEP ID for the two-way frame delay measurement.
The two-way frame delay measurement is performed on end-to-end MEPs. A MEP receives a
DMM frame and returns a DMR frame to carry out the two-way frame delay measurement. After
the two-way frame delay measurement is configured, a MEP periodically sends DMM frames
with the TxTimeStampf value (timestamp at the time of sending the DMM frame). After
receiving the DMM frame, the remote MEP adds the RxTimeStampf value (timestamp at the
time of receiving the DMM frame) to the DMM frame, generates a DMR frame with the
TxTimeStampb value (timestamp at the time of sending the DMR frame), and sends the message
to the requesting MEP. Every field in the DMM frame is copied to the DMR frame except that
the source and destination MAC addresses are swapped and the message type is changed from
DMM to DMR. Upon receiving the DMR frame, the requesting MEP calculates the two-way
frame delay based on the following formula:
Two-way frame delay = (RxTimeb - TxTimeStampf) - (TxTimeStampb - RxTimeStampf)
Do as follows on the devices configured with MEPs on two ends of the link:
Procedure
Step 1 Run:
system-view

Step 2 Run:

cfm md md-name
Step 3 Run:
ma ma-name
Step 4 Run:
delay-measure two-way send mep mep-id { mac mac-address | remote-mep mep-id }
interval { 1000 | 10000 } count count-value [ peer-ip peer-ip [ vc-id vc-id ] ]
The two-way frame delay measurement is configured.
----End

After the two-way frame delay measurement is configured in a VLAN, you can view the statistics
about the delay in bidirectional service traffic transmission in the VLAN.
Prerequisites
All the configurations of the two-way frame delay measurement in a VLAN are complete.
Procedure
l Run the display y1731 statistic-type twoway-delay md md-name ma ma-name [ count
count-value ] command to check the performance statistics collected through Y.1731.
----End
Example
After the configurations, run the display y1731 statistic-type command on the devices where
MEPs reside, and you can view the value of the average delay.
<Quidway> display y1731 statistic-type twoway-delay md md1 ma ma1
Latest two-way delay statistics:
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 1093 -
2 1190 97
3 1154 36
4 1088 66
5 1156 68
--------------------------------------------------------------------------------
Average delay(usec) : 1136 Average delay variation(usec) : 66
Maximum delay(usec) : 1190 Maximum delay variation(usec) : 97
Minimum delay(usec) : 1088 Minimum delay variation(usec) :
36
6.5 Configuring VLAN AIS

By configuring the AIS function in an MA, you can suppress the MEP in an MD of a higher
level from sending alarms to the NMS.


Before configuring VLAN AIS, familiarize yourself with the applicable environment, complete
the pre-configuration tasks, and obtain the required data. This can help you complete the
As shown in Figure 6-4, MEPs configured on CE1 and CE2 are in MD1 of level 6; MEPs
configured on PE1 and PE2 are in MD2 of level 3. If the MEP in the MD of level 6 detects a
fault, the MEP sends an alarm to the NMS. After a certain period, if the MEP in the MD of level
3 also detects the fault, the MEP sends a same alarm to the NMS. In this case, you can configure
the AIS function on PE1 and PE2 to suppress the MEP in the MD of a higher level from sending
alarms to the NMS.
Figure 6-4 Networking diagram of configuring VLAN AIS
CE1
AIS packets PE1 PE2 AIS packets CE2
VLAN
VLAN/QinQ VLAN/QinQ
MD2 Level 3
MD1 Level 6
Before configuring VLAN AIS, complete the following tasks:
l Switching the version of Ethernet CFM to standard
l Enabling Ethernet CFM globally
l Creating an MD and an MA
l Creating an MEP
Data Preparation
To configure VLAN AIS, you need the following data.
No. Data
1 Names of an MD and an MA
3 VLAN ID bound to an MA

No. Data
4 (Optional) Interval for sending AIS packets
5 Level of an AIS packet to be sent
6 Range of VLANs to which AIS packets are to be sent

Binding an MA to a VLAN is a prerequisite for configuring VLAN AIS.
Context
Do as follows in the MDs in a VLAN:
Procedure
Step 1 Run:
system-view
Step 2 Run:
cfm md md-name
Step 3 Run:
ma ma-name
Step 4 Run:
map vlan vlan-id
The MA is bound to a specified VLAN.
----End
6.5.3 Configuring the AIS Function

By configuring the AIS function in an MD of a lower level, you can enable the MEP in the MD
of a lower level to send AIS packets.
Context
Do as follows in the MD of a lower level in a VLAN:
Procedure
Step 1 Run:
system-view


Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name

Step 4 Run:
ais enable
The AIS function is enabled in the current MA.

By default, the AIS function is disabled.
ais link-status interface interface-type interface-number
AIS is configured to monitor interfaces.

By default, AIS does not monitor interfaces.
ais interval interval-value
The interval for sending AIS packets is set.

By default, By default, the interval for sending AIS packets is one second.
NOTE
If the range of VLANs to which AIS packets are to be sent is set, setting the interval for sending AIS packets
to 60s is recommended.
Step 7 Run:
ais level level-value
The level of AIS packets to be sent is set.
----End
6.5.4 Configuring Alarm Suppression

By configuring alarm suppression in an MD of a higher level, you can suppress the MEP in the
MD of a higher level from sending the same alarm to the NMS.
Context
Do as follows in the MD of a higher level in a VLAN:
Procedure
Step 1 Run:
system-view

Step 2 Run:
cfm md md-name

Step 3 Run:
ma ma-name

Step 4 Run:
ais enable
The AIS function is enabled in the current MA.

By default, the AIS function is disabled.
Step 5 Run:
ais suppress-alarm
Alarm suppression is enabled in the current MA.

By default, alarm suppression of the MEP is disabled.
In case of MD nesting, if alarm suppression is enabled in the MD of a high level, the MEP in
this MD does not send alarms to the NMS after receiving an AIS packet.
----End

By checking the values of the Suppressing Alarms and Sending Ais Packet fields, you can
check whether VLAN AIS is configured successfully.
Prerequisites
Configuring VALN AIS is complete.
Procedure
l Run the display cfm ma command to check the detailed information about an MA.
----End
Example
Running the display cfm ma command in an MD of a lower level, you can find that the value
of the Sending Ais Packet field is Yes.
<Quidway> display cfm ma md md1 ma ma1
The total number of MAs is 1
MD Name : md1
MD Name Format :
Level : 3
SenderID TLV-type : Defer
MA Name : ma1
Interval : 1000
Priority : 4
Vlan ID : --

VSI Name : --
MEP Number : 1
RMEP Number : 2
Suppressing Alarms : No
Sending Ais Packet : Yes
Running the display cfm ma command in an MD of a higher level, you can find that the value
of the Suppressing Alarms field is Yes.
The total number of MAs is 1
MD Name : md2
MD Name Format :
Level : 6
SenderID TLV-type : Defer
MA Name : ma2
Interval : 10000
Priority : 4
Vlan ID : 7
VSI Name : --
MEP Number : 21
RMEP Number : 22
Suppressing Alarms : Yes
Sending Ais Packet : No

This section provides several configuration examples of Y.1731.
6.6.1 Example for Configuring the One-way Frame Delay

Measurement in a VLAN
When you need to estimate service qualities, you can configure the one-way frame delay
measurement on point-to-point MEPs to obtain the performance of the network.
As shown in Figure 6-5, the one-way frame delay measurement is deployed on Switch A. The
interval for sending DM frames is set to 10 seconds and the number of DM frames sent each
time is also set to 10.
Figure 6-5 Networking diagram of configuring the one-way frame delay measurement in a
VLAN
SwitchC SwitchD
GE2/0/0 GE2/0/0
GE1/0/0 GE1/0/0
GE1/0/0 GE1/0/0
SwitchA SwitchB

1. Configure VLANs on Switch A, Switch B, Switch C, and Switch D.
2. Configure MDs and MAs on Switch A and Switch B.
3. Configure outward-facing MEPs on Switch A and Switch B.
4. Set the alarm thresholds of the one-way frame delay measurement on Switch A.
5. Enable the one-way frame delay measurement for the VLANs on Switch A
Data Preparation
l VLAN ID
l Alarm threshold of the one-way frame delay measurement
l Names of the MD and MA
Procedure
Step 1 Configuring synchronize clock, For the configuration procedure, see NTP Configuration
Step 2 Configure VLANs.

[SwitchA] vlan 2
[SwitchB] vlan 2
[SwitchC] vlan 2


[SwitchD] vlan 2
Step 3 Configure basic Ethernet CFM functions.
Step 4 Configure outward-facing MEPs.
[SwitchA-md-md1-ma-ma1] mep ccm-send mep-id 1 enable
[SwitchA-md-md1-ma-ma1] remote-mep ccm-receive mep-id 2 enable
[SwitchB-md-md1-ma-ma1] mep ccm-send mep-id 2 enable
[SwitchB-md-md1-ma-ma1] remote-mep ccm-receive mep-id 1 enable
Step 5 Set the alarm threshold for the one-way frame delay measurement to 1000 on Switch A.
[SwitchA-md-md1-ma-ma1] delay-measure one-way threshold 1000

Step 6 Configure the one-way frame delay measurement in a VLAN.

[SwitchA-md-md1-ma-ma1] delay-measure one-way send mep 1 remote-mep 2 interval
10000 count 10
[SwitchB-md-md1-ma-ma1] delay-measure one-way receive mep 2

# After the configuration, run the display y1731 statistics-type oneway-delay md md1 ma
ma1 command, and you can view the statistics about the one-way frame delay.
[SwitchB] display y1731 statistic-type oneway-delay md md1 ma ma1
Latest one-way delay statistics:
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 -2001626137 -
2 -2001625996 141
3 -2001625852 144
4 -2001625704 148
5 -2001625565 139
6 -2001625559 6
7 -2001625407 152
8 -2001625004 403
9 -2001609680 15324
10 -2001624860 15180
--------------------------------------------------------------------------------
Average delay(usec) : -2001623976 Average delay variation(usec) : 3515
Maximum delay(usec) : -2001609680 Maximum delay variation(usec) : 15324
Minimum delay(usec) : -2001626137 Minimum delay variation(usec) : 6
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 2
#
cfm enable
#
interface gigabitethernet1/0/0
#
cfm md md1
ma ma1
map vlan 2
mep mep-id 1 interface gigabitethernet1/0/0 outward
remote-mep mep-id 2

delay-measure one-way threshold 1000

#
return

#
sysname SwitchB
#
vlan batch 2
#
cfm enable
#
interface gigabitethernet1/0/0 outward
#
cfm md md1
ma ma1
map vlan 2
mep mep-id 2 interface gigabitethernet1/0/0 outward
remote-mep mep-id 1
delay-measure one-way receive mep 2
#
return

#
sysname SwitchC
#
vlan batch 2
#
#
#
return

#
sysname SwitchD
#
vlan batch 2
#
#
#
return
6.6.2 Example for Configuring the Two-way Frame Delay

Measurement in a VLAN
When you need to estimate service qualities, you can configure the two-way frame delay
measurement on point-to-point MEPs to obtain the performance of the network.

As shown in Figure 6-6, the two-way frame delay measurement is deployed both on Switch A
and Switch B. The interval for sending DMM frames is set to 10 seconds and the number of
DMM frames sent each time is also set to 10.
Figure 6-6 Networking diagram of configuring the two-way frame delay measurement in a
VLAN
SwitchC SwitchD
GE2/0/0 GE2/0/0
GE1/0/0 GE1/0/0
GE1/0/0 GE1/0/0
SwitchA SwitchB
1. Configure VLANs on Switch A, Switch B, Switch C, and Switch D.
2. Configure MDs and MAs on Switch A and Switch B.
3. Configure outward-facing MEPs on Switch A and Switch B.
4. Set the alarm thresholds of the two-way frame delay measurement on Switch A and Switch
B.
5. Enable the two-way frame delay measurement for the VLANs on Switch A and Switch B.
Data Preparation
l VLAN ID
l Alarm threshold of the two-way frame delay measurement
l Names of the MD and MA
Procedure
Step 1 Configure VLANs.
[SwitchA] vlan 2

[SwitchB] vlan 2
[SwitchC] vlan 2
[SwitchD] vlan 2
Step 2 Configure basic Ethernet CFM functions.

Step 3 Configure outward-facing MEPs.



[SwitchA-md-md1-ma-ma1] mep ccm-send mep-id 1 enable
[SwitchB-md-md1-ma-ma1] mep ccm-send mep-id 2 enable
Step 4 Set the alarm threshold for the two-way frame delay measurement to 1000.
[SwitchA-md-md1-ma-ma1] delay-measure two-way threshold 1000
[SwitchB-md-md1-ma-ma1] delay-measure two-way threshold 1000
Step 5 Configure the two-way frame delay measurement in a VLAN.

[SwitchA-md-md1-ma-ma1] delay-measure two-way receive mep 1
[SwitchA-md-md1-ma-ma1] delay-measure two-way send mep 1 remote-mep 2 interval
10000 count 10
[SwitchB-md-md1-ma-ma1] delay-measure two-way receive mep 2
[SwitchB-md-md1-ma-ma1] delay-measure two-way send mep 2 remote-mep 1 interval
10000 count 10

# After the configuration, run the display y1731 statistics-type twoway-delay md md1 ma
ma1 command, and you can view the statistics about the two-way frame delay.
[Quidway] display y1731 statistic-type twoway-delay md md1 ma ma1
Latest two-way delay statistics:
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
1 0 -
2 0 0
3 0 0
4 0 0
5 0 0
6 0 0
7 0 0
8 0 0
9 0 0
10 0 0
--------------------------------------------------------------------------------
Average delay(usec) : 0 Average delay variation(usec) : 0
Maximum delay(usec) : 0 Maximum delay variation(usec) : 0
Minimum delay(usec) : 0 Minimum delay variation(usec) :
0
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 2
#
cfm enable
#
#
cfm md md1
ma ma1
map vlan 2
remote-mep mep-id 2
delay-measure two-way threshold 1000
delay-measure two-way receive mep 1
#
return

#
sysname SwitchB
#
vlan batch 2
#
cfm enable
#
interface GigabitEthernet1/0/0 outward
#
cfm md md1
ma ma1
map vlan 2
remote-mep mep-id 1
delay-measure two-way threshold 1000
delay-measure two-way receive mep 2
#
return


#
sysname SwitchC
#
vlan batch 2
#
interface GigabitEthernet1/0/0 port link-type trunk
#
#
return

#
sysname SwitchD
#
vlan batch 2
#
#
#
return

Configuration Guide - Reliability 7 BFD Configuration
7 BFD Configuration
About This Chapter
A BFD session rapidly detects a link fault on a network.
7.1 BFD Overview

BFD is a uniform detection mechanism for an entire network. It detects faults quickly and
monitors the forwarding and connectivity of links or IP routes of the network.
7.2 BFD Features Supported by the S9700
This section describes the BFD features supported by the S9700.
7.3 Configuring Single-hop BFD
A single-hop BFD session rapidly detects faults on direct links over a network.
7.4 Configuring the Multi-Hop BFD
By configuring a multi-hop BFD session, you can fast detect and monitor multi-hop links on a
network.
7.5 Configuring a BFD Session with Automatically Negotiated Discriminators
A static BFD session with automatically negotiated discriminators is configured to check the
interworking between a device and another device on which a BFD session has been dynamically
established. The static BFD session with automatically negotiated discriminators is applicable
to static routes.
7.6 Adjusting BFD Parameters
Adjusting BFD parameters allows a BFD session to check network links effectively and quickly.
7.7 Globally Configuring the Destination Port Number for the Multi-Hop BFD Control Packet
By configuring a global destination port number for multi-hop BFD control packets, you can
implement the interworking between the local device and a device running an earlier version,
and between a Huawei device and a non-Huawei device.
7.8 Configuring the Delay of a BFD Session to Go Up
In certain scenarios a BFD session is configured to go Up after a delay. Setting a delay for a
BFD session status change to Up can prevent traffic loss that occurs if an interface goes Up
before the routing protocol.
7.9 Configuring a BFD Session with the One-Arm Echo Function

By configuring a BFD session with the one-arm Echo function, you can fast detect and monitor
a direct link between a BFD-capable device and a BFD-incapable device.
7.10 Configuring the TTL Function Globally
Configuring the TTL globally helps you connect the current device and a device running an early
version.
7.11 Configuring the Interval for Trap Messages Are Sent
The interval at which trap messages are sent is set, helping a device to suppress BFD trap
messages.
7.12 Configuring Association Between a BFD Session and an Interface (Triggering the Physical
Status of the Interface Associated with the BFD Session to Become Down)
Association between a BFD session and an interface is applicable to the scenario where a CE is
directly connected to a PE. BFD is enabled on PEs and a BFD session is associated with an
interface. When the BFD session detects a link fault, the BFD module notifies the OAM
management module on the local PE of the fault. This triggers the physical status of the interface
to become Down.
7.13 Configuring Association Between BFD Sessions
After the association between BFD sessions is configured, the local BFD session can detect a
fault and then notify the OAM management module of the fault. The OAM management module
sends fault information to the associated BFD session. The associated BFD session then sends
BFD packets carrying the fault information to the OAM management module on the remote
device. In this manner, the fault is notified to the remote device.
7.14 Maintaining BFD
This section describes how to maintain BFD by deleting BFD statistics, and monitoring BFD
operations.
This section provides several configuration examples of BFD.

7.1 BFD Overview

BFD is a uniform detection mechanism for an entire network. It detects faults quickly and
monitors the forwarding and connectivity of links or IP routes of the network.
On a network, a link fault is detected in either of the following methods:
l Hardware detection signals, such as those provided by the Synchronous Digital Hierarchy
(SDH) alarm function, are used to detect a link fault rapidly.
l If the hardware detection method is unavailable, the Hello mechanism of a routing protocol
is used to detect faults.
The following problems exist in the preceding methods:

l Hardware is used by only part of mediums to detect faults.
l The routing protocol-specific Hello mechanism takes more than 1 second to detect a fault.
If data is forwarded at gigabit rates, a large amount of data is dropped.
l On a small-scale Layer 3 network, if no routing protocol is deployed, the routing protocol-
specific Hello mechanism does not detect faults. This means that a fault between
interconnected systems is difficult to locate.
BFD is developed to resolve these problems.
BFD provides the following functions:
l Detects faults rapidly along paths between neighboring forwarding engines, with light loads
and high speeds.
l Uses a single mechanism to monitor any kind of medium and protocol layer in real time.
Detection time and costs vary.
7.2 BFD Features Supported by the S9700

This section describes the BFD features supported by the S9700.
The S9700s send BFD control packets based on the negotiated period. If an S9700 does not
receive the packet of the peer within the detection time, the S9700 sets the BFD session in Down
state. The upper-layer application can take actions according to the status of the BFD session.
BFD Session Establishment Supported by the S9700

BFD uses the local discriminator and remote discriminator to differentiate multiple BFD sessions
between the same pair of systems. According to the difference in the modes of creating the local
discriminator and the remote discriminator, the S9700 supports the following BFD session types:
l Static BFD sessions with manually specified discriminators

l Static BFD sessions with automatically negotiated discriminators
l Dynamic BFD sessions triggered by a protocol
A dynamic BFD session triggered by a protocol is implemented as follows:

l The local discriminator is allocated automatically.
l The remote discriminator is learned by the local end.

NOTE
Currently, on the S9700, OSPF, BGP, IS-IS, MPLS, MPLS LDP, RSVP-TE, PWE3, and PIM can
dynamically trigger the establishment of BFD sessions.
When the two ends of a BFD session create discriminators in different modes:
l If the discriminators on the local end are specified manually, the discriminators on the
remote end must also be specified manually.
l If you configure a static BFD session with automatically negotiated discriminators on the
local end, you can configure a static BFD session with automatically negotiated
discriminators or configure a dynamic BFD session on the peer end.
l If a static BFD session with automatically negotiated discriminators and a dynamic BFD
session are configured at the local end, the following principles are applicable:
If the dynamic BFD session and static BFD session with automatically negotiated
discriminators share the same configurations (the source address, destination address,
outbound interface, and VPN index), the two BFD sessions coexist.
If the dynamic BFD session named DYN_local discriminator is configured earlier than
the static BFD session with automatically negotiated discriminators, the name of the
dynamic BFD session is changed to the name of the static BFD session.
The two BFD sessions use the smaller values of BFD parameters.
Single-Hop BFD
Single-hop BFD detects connectivity of the forwarding link between two directly connected
devices.
Between the two systems detected by the single-hop BFD session, only one BFD session can be
set up on a specified interface enabled with a specified data protocol. Therefore, each BFD
session is bound to an interface. On the S9700, BFD sessions are bound to Layer 2 interfaces.
The S9700 provides single-hop BFD for the link fault between IS-IS peer nodes. By detecting
the link fault between IS-IS peer nodes, the S9700 fast reports the fault to IS-IS, triggering IS-
IS fast convergence.
Multi-Hop BFD
Multi-hop BFD detects IP connectivity of paths between two non-directly-connected devices.
These paths may span multiple hops or overlap. Multi-hop BFD is often used to detect reachable
routes between two devices.
The S9700 provides multi-hop BFD for static routes. Generally, static routes do not have the
detection mechanism. When a network fails, the administrator needs to check the static routes
manually. You can use multi-hop BFD to check the status of static routes. The RM module
determines whether a static route is available according to the status of the BFD session.
Association Between the BFD Session Status and the Interface Status
When a transmission device exists on a directly connected link, BFD can detect a fault faster
than the detection mechanism of the link protocol on the interface. The link protocol status of
the trunk interface or the VLAN interface depends on the link protocol status of member
interfaces.
Therefore, to notify the BFD detection result to the application rapidly, each interface is added
with an attribute in the interface management module of the S9700, that is, the BFD status. The

BFD status indicates the status of the BFD session that is bound to the interface. The system
determines the interface status according to the link status, protocol status, and BFD status, and
then notifies the interface status to the application.
The association between the BFD session status and the interface status means that the BFD
session status in the IFNET module is modified when the BFD session status changes. This
function is valid for the single-hop BFD session that is bound to an outbound interface and uses
the default multicast address.
l After the BFD session is bound to an interface,
When the BFD session goes Down, the status of the interface that is bound to the BFD
session also goes Down. The application on the interface is notified of the interface
status change.
When the BFD session status goes Up, the status of the interface that is bound to the
BFD session also goes Up.
This function aims to fast report BFD detection results to the application.
BFD for Static Routes

Static routes do not have a detection mechanism. When the network fails, the administrator needs
to check the static routes manually.
Through BFD for static routes, the BFD session can be used to detect the status of IPv4 static
routes on a public network. The RM module determines whether the static route is available
according to the BFD session status.
NOTE
For details on how to configure BFD for static routes, see Configuring BFD for IPv4 Static Routes on a
Public Network in the S9700 Core Routing Switch Configuration Guide - IP Routing.
BFD for Routing Protocols

BFD uses the local discriminator and remote discriminator to differentiate multiple BFD sessions
between the same pair of systems. IS-IS supports dynamic and static BFD sessions; BGP and
OSPF support dynamic setup of BFD sessions.
The BFD session dynamically triggered by a routing protocol is implemented as follows:
l The local discriminator is allocated automatically.
l The remote discriminator is learned by the local end.
When the neighbor relationship of a routing protocol is set up successfully, the routing protocol
requests BFD to establish a BFD session through the RM module. The neighbor relationship of
the routing protocol then can be rapidly detected. The detection parameters of the BFD session
are negotiated by both ends through the routing protocol.
When a BFD session detects a fault, the BFD session becomes Down. BFD triggers route
convergence through the RM module.
When the neighbor is unreachable, the routing protocol requests BFD to delete the session
through the RM module.
BFD for FRR

l BFD for LDP FRR

The S9700 uses BFD to check the protected interfaces and to trigger the LDP FRR
switching.
l BFD for IP FRR and BFD for VPN FRR
On the S9700, IP FRR and VPN FRR are triggered after BFD reports detection faults to
the upper-layer application.
l BFD can provide reliability for MPLS-based applications, such as VPN FRR, TE FRR, and
VLL FRR, to protect services.
BFD for LSPs

BFD can detect faults of the data plane on LSPs.
When BFD detects data plane faults on the MPLS LSP, it has the following advantages:
l BFD works if only the IP route is reachable in the reverse direction.
l BFD detects faults fast.
l BFD supports fault detection for large-scale LSPs.
Currently, the S9700 supports BFD for the following LSPs:
l Static LSPs
For details on how to configure BFD for static LSPs, see the S9700 Core Routing Switch
Configuration Guide - MPLS.
l LDP LSPs
For details on how to configure BFD for LDP LSPs, see the S9700 Core Routing Switch
Configuration Guide - MPLS.
l MPLS TE tunnels
BFD can detect TE tunnels that use CR-Static and RAVP-TE as signaling protocols, and
detect the primary or standby LSP bound to the TE tunnel.
For details on how to configure BFD for MPLS TE tunnels, see the S9700 Core Routing
Switch Configuration Guide - MPLS.
BFD for PIM

The S9700 can dynamically create a BFD session between PIM neighbors to detect the status
of the link between them. When a fault occurs on the link, BFD notifies PIM of the fault.
NOTE
For details on how to configure BFD for PIM, see the S9700 Core Routing Switch Configuration Guide -
Multicast.
BFD for VRRP

BFD detects and monitors the connectivity of links or IP routes on a network and triggers the
fast VRRP switchover.
BFD for PW
BFD can quickly detect faults on the PW between the local and remote PEs to support FRR on
the VLL and reduce the impact of link faults on the services. The S9700 can set up a static BFD
session with manually configured discriminators or a dynamic BFD session to detect faults on
a PW.

The S9700 combines BFD and VCCV ping to detect the connectivity of the PW dynamically.
In this manner, the S9700 triggers fast switchover of the upper-layer services to protect them.
NOTE
For details on how to configure BFD for PWs, see the S9700 Core Routing Switch Configuration Guide
- VPN.
BFD for VSI PWs

On the network where VPLS convergence is performed, you can establish multiple service VSI
PWs and bind them to an mVSI PW. In this manner, if a BFD session is bound to the mVSI PW,
the S9700 can monitor the service VSI by only monitoring the status of the mVSI PW.
NOTE
For details on how to configure BFD for VSI PWs, see the S9700 Core Routing Switch Configuration
Guide - VPN.
Dynamically Changing Values of BFD Parameters

After a BFD session is set up, you can change the values of related parameters, such as the
expected interval for sending BFD packets, the minimum interval for receiving BFD packets,
and local detection multiplier, without affecting the status of the session.
7.3 Configuring Single-hop BFD

A single-hop BFD session rapidly detects faults on direct links over a network.

Before configuring a single-hop BFD session, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the required data.
To fast check directly connected links, configure single-hop BFD.
Before configuring single-hop BFD, complete the following tasks:
l Connecting each interface correctly

l Configuring IP addresses for Layer 3 interfaces
Data Preparation
To configure single-hop BFD, you need the following data.
No. Data
1 BFD configuration name

No. Data
2 Peer IP address, local interface type and number for the directly-connected link
detected by BFD, and default multicast address used by BFD if it checks the physical
layer status of the link
3 BFD session parameters: local and remote discriminators
7.3.2 Enabling BFD Globally

Context
Do as follows on S9700s at both ends of the link to be detected.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
BFD is enabled globally and the BFD view is displayed.

By default, BFD is disabled globally. Before configuring the BFD functions, you must enable
BFD globally; otherwise, the configuration fails.
----End
7.3.3 (Optional) Setting the Multicast IP Address of BFD

Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
The BFD view is displayed.

Step 3 Run:
default-ip-address ip-address
The multicast IP address of BFD is set.

To implement single-hop BFD on a Layer 2 forwarding link, BFD needs to use a multicast IP
address. By default, BFD uses the multicast IP address 224.0.0.184.
NOTE
l If this multicast IP address is used by other protocols on the network, you must change the multicast
IP address. The S9700s at both ends of the BFD session must use the same multicast IP address.
l If multiple BFD sessions exist on a path, for example, Layer 3 interfaces are connected through Layer
2 switching devices that support BFD, you must configure different default multicast IP addresses for
the devices where different BFD sessions are established. In this manner, BFD packets can be correctly
forwarded.
----End
7.3.4 Creating a BFD Session
Context
Procedure
Step 1 Run:
system-view

l bfd cfg-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ] [interface interface-
type interface-number ] [ source-ip source-ip ]
When creating a single-hop BFD session for the first time, you must bind the single-hop
BFD session to the peer IP address and the local address. In addition, the configuration
of the single-hop BFD session cannot be changed after being created.
When BFD configuration items are created, the system checks only the format of the IP
address rather than the correctness. A BFD session cannot be established if an incorrect
peer IP address or source IP address is bound.
When BFD and URPF are used together, URPF checks the source IP address of the
received BFD packets. In this case, you need to specify the correct source IP address of
BFD packets by setting the source-ip parameter when binding a BFD session to prevent
BFD packets from being discarded incorrectly.
l For a Layer 2 interface, run:
bfd cfg-name bind peer-ip default-ip { interface interface-type interface-number | vsi vsi-
name }[ source-ip source-ip ]
Step 3 Set the discriminators.

l Run:
discriminator local discr-value
The local discriminator is set.

l Run:
discriminator remote discr-value
The remote discriminator is set.

When you set the discriminators, ensure that the local discriminator at the local end is the same
as the remote discriminator at the peer end; otherwise, the BFD session fails to be set up. After
local and remote discriminators are set successfully, they cannot be modified.
NOTE
For the BFD sessions that use the default multicast IP address, the local and remote discriminators must
be different.
----End
Procedure
l Run the display bfd configuration { all | static } [ for-vsi-pw | for-ip | for-lsp | for-pw
| for-te ] [ verbose ] command to check the configuration of BFD.
l Run the display bfd interface [ interface-type interface-number ] command to check
information about the interface where BFD is enabled.
l Run the display bfd session { all | static } [ for-ip | for-lsp | for-pw | for-te | for-vsi-
pw ] [ verbose ] command to check information about a BFD session.
l Run the display bfd statistics session { all | static } [ for-ip | for-lsp | for-pw | for-te |
for-vsi-pw ] command to check the statistics on a BFD session.
----End
Example
Run the display bfd configuration command, and you can view the configuration of a BFD
session.
<Quidway> display bfd configuration static name bfd1 verbose
--------------------------------------------------------------------------------
BFD Session Configuration Name : bfd1
--------------------------------------------------------------------------------
BFD Bind Type : Interface(Vlanif511)
Bind Interface : Vlanif110
TOS-EXP : 7 Local Detect Multi : 3
WTR Interval (ms) : - Process PST : Disable
Proc Interface Status : Disable
Bind Application : No Application Bind
--------------------------------------------------------------------------------
Run the display bfd interface command, and you can view information about the BFD session
on a specified interface.
<Quidway> display bfd interface gigabitethernet 3/0/1
--------------------------------------------------------------------------------
Interface Name MIndex Sess-Count BFD-State
--------------------------------------------------------------------------------
GigabitEthernet3/0/1 1025 1 up
Run the display bfd session command, and you can view information about a BFD session.
<Quidway> display bfd session all
--------------------------------------------------------------------------------


--------------------------------------------------------------------------------
20 10 224.0.0.184 UP S_IP_IF GigabitEthernet3/0/1
--------------------------------------------------------------------------------
Run the display bfd statistics session command, and you can view the statistics on a BFD
session.
<Quidway> display bfd statistics session static for-ip
--------------------------------------------------------------------------------
Session MIndex : 4097 (One Hop) State : Init Name : 9to6
--------------------------------------------------------------------------------
Session Type : Static
Bind Type : IP
Local/Remote Discriminator : 20/10
Received Packets : 97
Send Packets : 314
Received Bad Packets : 169
Send Bad Packets : 0
Down Count : 32
ShortBreak Count : 0
Send Lsp Ping Count : 0
Dynamic Session Delete Count : 0
Create Time : 2007/10/14 16:48:13
Last Down Time : 2007/10/14 17:09:11
Total Time From Last DOWN : ---D:--H:--M:--S
Total Time From Create : 000D:00H:20M:59S
--------------------------------------------------------------------------------
Total Session Number : 1
7.4 Configuring the Multi-Hop BFD

By configuring a multi-hop BFD session, you can fast detect and monitor multi-hop links on a
network.

Before configuring a multi-hop BFD session, familiarize yourself with the applicable
environment and data preparation.
To rapidly detect the faults occur during IP switch forwarding, configure the multi-hop BFD.
Before configuring multi-hop BFD, complete the following tasks:
l Correctly connecting each interface and configuring IP addresses for them

l Configuring a routing protocol to ensure that the network layer is reachable
Data Preparation
To configure the multi-hop BFD, you need the following data.

No. Data
1 Remote IP address
3 BFD session parameters: local discriminator and remote discriminator

You can perform related BFD configurations only after enabling BFD globally.
Context
Perform the following procedure on the switch:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
----End
7.4.3 Creating a BFD Session
Context
If Unicast Reverse Path Forwarding (URPF) is enabled on a device on the transmission path of
BFD packets, this device checks the source IP address of the BFD packets. In this case, you can
specify the correct source IP address of BFD packets by setting the source-ip parameter when
creating a BFD session to prevent BFD packets from being discarded.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd cfg-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ] [ source-ip
source-ip ]
A BFD session is created.

l When creating a BFD session for the first time, you must bind the BFD session to the peer
IP address. In addition, the configuration of the BFD session cannot be changed after being
created.
l When the BFD configuration items are created, the system checks only the format of the IP
address rather than the correctness. A BFD session cannot be established if an incorrect peer
IP address or source IP address is bound.
l When BFD and URPF are used together, URPF checks the source IP address of the received
BFD packets. In this case, you need to specify the correct source IP address of BFD packets
by setting the source-ip parameter when creating a BFD session to prevent BFD packets
from being discarded incorrectly.
Step 3 Set the identifiers.
l Run:
The local discriminator is set.

l Run:
discriminator remote discr-value
The remote discriminator is set.

NOTE
When you set the discriminators, ensure that the local discriminator at the local end is the same as the
remote discriminator at the peer end; otherwise, the BFD session fails to be set up.
----End
Procedure
l Run the display bfd configuration { all | static } [ for-vsi-pw | for-ip | for-lsp | for-pw
| for-te ] [ verbose ] and display bfd configuration { static name cfg-name |
discriminator local-discr-value | dynamic | peer-ip peer-ip [ vpn-instance vpn-name ] |
static-auto } [ verbose ] commands to check the configuration of BFD.
l Run the display bfd session { all | static } [ for-ip | for-lsp | for-pw | for-te | for-vsi-
pw ] [ verbose ] and display bfd session { dynamic | discriminator discr-value | peer-
ip peer-ip [ vpn-instance vpn-name ] | static-auto } [ verbose ] commands to check
information about a BFD session.
l Run the display bfd statistics session { all | static } [ for-ip | for-lsp | for-pw | for-te |
for-vsi-pw ] and display bfd statistics session { dynamic | discriminator discr-value |
peer-ip peer-ip [ vpn-instance vpn-name ] | static-auto } commands to check the statistics
on a BFD session.
----End
Example
Run the display bfd configuration command, and you can view the configuration of a BFD
session.
<Quidway> display bfd configuration static name bfd1 verbose
--------------------------------------------------------------------------------
BFD Session Configuration Name : bfd1
--------------------------------------------------------------------------------

BFD Bind Type : Interface(GigabitEthernet3/0/1)

Bind Interface : GigabitEthernet3/0/1
WTR Interval (ms) : - Process PST : Disable
Local Demand Mode : Disable
--------------------------------------------------------------------------------
<Quidway> display bfd session discriminator 22 verbose
--------------------------------------------------------------------------------
Session MIndex : 4096 (One Hop) State : Up Name : bfd1
--------------------------------------------------------------------------------
Local Detect Multi : 3 Detect Interval (ms) : 3000
WTR Interval (ms) : - Local Demand Mode : Disable
Active Multi : 3
Last Local Diagnostic : No Diagnostic
Session TX TmrID : 16394 Session Detect TmrID : 16395
--------------------------------------------------------------------------------
Run the display bfd statistics session command, and you can view statistics a BFD session.
<Quidway> display bfd statistics session all
--------------------------------------------------------------------------------
Session MIndex : 4096 (One Hop) State : Up Name : bfd1
--------------------------------------------------------------------------------
Session Type : Static
Bind Type : IP
Local/Remote Discriminator : 22/11
Received Packets : 178
Send Packets : 177
Received Bad Packets : 0
Send Bad Packets : 0
Down Count : 0
ShortBreak Count : 0
Send Lsp Ping Count : 0
Dynamic Session Delete Count : 0
Create Time : 2007/10/14 22:26:53
Last Down Time : 0000/00/00 00:00:00
Total Time From Last DOWN : ---D:--H:--M:--S
Total Time From Create : 000D:00H:03M:03S
--------------------------------------------------------------------------------
Total Session Number : 1

7.5 Configuring a BFD Session with Automatically

Negotiated Discriminators
A static BFD session with automatically negotiated discriminators is configured to check the
interworking between a device and another device on which a BFD session has been dynamically
established. The static BFD session with automatically negotiated discriminators is applicable
to static routes.

Before configuring a static BFD session with automatically negotiated discriminators,
familiarize yourself with the applicable environment, complete the pre-configuration tasks, and
obtain data required for the configuration.
If a dynamic BFD session is used by a remote device, a static BFD session with automatically
negotiated discriminators must be created on a local device to interwork with the remote device
and support a static route tracking BFD.
Before configuring a BFD session with automatically negotiated discriminators, complete the
following tasks:
l Correctly connecting interfaces

l Correctly configuring an IP address for a Layer 3 interface
Data Preparation
No. Data
1 Name of a BFD session
2 IP addresses of local and remote ends of a link checked by BFD, and name and
number of the local interface

You can perform related BFD configurations only after enabling BFD globally.
Context
Perform the following procedure on the switch that uses a static BFD session with automatically
negotiated discriminators to detect link faults:

Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
----End
7.5.3 Configuring a Static BFD Session with Automatically

Negotiated Discriminators
Context
Do as follows on the Switch where the static BFD session with automatically negotiated
discriminators is used to detect the link.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd cfg-name bind peer-ip ip-address [ vpn-instance vpn-name ] [ interface
interface-type interface-number] source-ip ip-address auto
A BFD session with different parameters is created according to the detected link type.
When creating a BFD session, you must:
l When creating a single-hop BFD session for the first time, you must bind the single-hop BFD
session to the peer IP address and the local address. In addition, the configuration of the
single-hop BFD session cannot be changed after being created.
l Specify the source IP address.
l Specify the peer IP address instead of the multicast IP address.
----End
Context
The configurations of creating a static BFD session with automatically negotiated discriminators
are complete.

Procedure
Step 1 Run the display bfd session { all | static | dynamic | discriminator discr-value | peer-ip peer-
ip [ vpn-instance vpn-name ] } [ verbose ] command to check information about a BFD session.
----End
Example
# Display detailed information about all the BFD sessions.
<Quidway> display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 4098 (One Hop) State : Up Name : staticbfd
--------------------------------------------------------------------------------
Bind Session Type : Static_Auto
Bind Source IP Address : 10.10.10.116
Active Multi : 3
Bind Application : AUTO
PDT Index : FSM-0 | RCV-0 | IF-0 | TOKEN-0 | OAMF-0
--------------------------------------------------------------------------------
You can view that a BFD session with the type as Static_Auto is established. The local
discriminator and the remote discriminator of this BFD session are 8192 and 8192 respectively,
which are obtained through automatic negotiation.
7.6 Adjusting BFD Parameters

Adjusting BFD parameters allows a BFD session to check network links effectively and quickly.

Before adjusting BFD parameters, familiarize yourself with the applicable environment and
complete pre-configuration task for a BFD session, and obtain data required for configuring the
BFD session.
After a BFD session is set up, the sending interval, receiving interval, and local detection
multiplier are adjusted on the basis of network status and performance requirements.

The Wait to Recovery (WTR) time for a BFD session is set to prevent frequent master/slave
switchovers caused by BFD session flapping.
The description of a BFD session is added to describe a link monitored by a BFD session.
If none of the preceding parameters is set, the default configurations are used.
Before adjusting BFD parameters, you need to set up a BFD session.
Data Preparation
To adjust BFD parameters, you need the following data.
No Data
2 Local intervals at which BFD packets are sent and received
3 Local BFD detection multiplier
4 Priority of BFD packets
7.6.2 Adjusting the BFD Detection Time
Context
To reduce the usage of system resource, when detecting that the BFD session becomes Down,
the system sets the intervals for sending and receiving BFD packets at the local end to a random
value between 1000 and 3000 milliseconds. When the BFD session recovers, the intervals set
by the user are used.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd configuration-name
The BFD session view is displayed.
Step 3 Run:
min-tx-interval interval
The expected interval for sending BFD packets is set.

By default, if the Flexible Service Unit (FSU) is used, the interval for sending BFD control
packets is 10 ms; if the FSU is not used, the interval for sending BFD control packets is 1000
ms
NOTE
If the FSU is installed, the interval for sending packets can be set to 0 ms, 20 ms, 50 ms, 100 ms, or 1000
ms. If the FSU is not installed, the interval can only be set to 100 ms or 1000 ms.
Step 4 Run:
detect-multiplier multiplier
The local detection time multiplier is set.

By default, the local detection multiplier is 3.
Step 5 Run:
commit
The configuration takes effect.
----End
7.6.3 Adding the Description of a BFD Session

Descriptions of BFD sessions help you distinguish between different BFD sessions.
Context
NOTE
The description command takes effect only on statically configured BFD sessions not on BFD sessions
that are dynamically configured or BFD sessions that are created by using automatically negotiated
discriminators.
Perform the following procedure on the switch:
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd cfg-name

Step 3 Run:
description description
The description of a BFD session is added.

description is a string of 1 to 51 characters.
The default description of a BFD session is Null.
You can run the undo description command to delete the description of a BFD session.
----End

7.6.4 Configuring the BFD WTR

The Wait to Recovery (WTR) time for a BFD session is used to prevent frequent master/slave
switchovers triggered by BFD session flapping.
Context
The WTR time for a BFD session is used to prevent frequent master/slave switchovers caused
by BFD session flapping. If a BFD session changes from Down to Up, BFD reports the change
to an upper-layer application after the WTR time expires.
Do as follows on the switch:
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd cfg-name

Step 3 Run:
wtr wtr-value
The WTR is configured.

By default, the WTR is 0.
Step 4 Run:
commit
----End
7.6.5 Setting the Priority of BFD Packets

Context
You can change the priority of BFD packets to:
l Check whether packets of different priorities on the same link can be forwarded.
l Ensure that BFD packets with a higher priority are forwarded first.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd configuration-name

Step 3 Run:
tos-exp tos
The priority of BFD packets is set.

By default, the priority of BFD packets is 7, which is the highest priority. The value 0 is the
lowest priority.
Step 4 Run:
commit
----End
Procedure
Step 1 Run the display bfd configuration { all | static } [ for-vsi-pw | for-ip | for-lsp | for-pw | for-
te ] [ verbose ] and display bfd configuration { static name cfg-name | discriminator local-
discr-value | dynamic | peer-ip peer-ip [ vpn-instance vpn-name ] | static-auto } [ verbose ]
commands to check the configuration of BFD.
Step 2 Run the display bfd session { all | static } [ for-ip | for-lsp | for-pw | for-te | for-vsi-pw ]
[ verbose ] and display bfd session { dynamic | discriminator discr-value | peer-ip peer-ip
[ vpn-instance vpn-name ] | static-auto } [ verbose ] command to check information about a
BFD session.
----End
Example
# Run the display bfd configuration command, and you can view the configuration of BFD.
<Quidway> display bfd configuration static for-ip verbose
--------------------------------------------------------------------------------
BFD Session Configuration Name : multi
--------------------------------------------------------------------------------
WTR Interval (ms) : 1800000 Process PST : Disable
Local Demand Mode : Disable
--------------------------------------------------------------------------------
Total Commit/Uncommit CFG Number : 1/0

<Quidway> display bfd session all for-ip verbose

--------------------------------------------------------------------------------
Session MIndex : 4096 (Multi Hop) State : Up Name : multi
--------------------------------------------------------------------------------
Bind Interface : -
Active Multi : 3
--------------------------------------------------------------------------------
7.7 Globally Configuring the Destination Port Number for

the Multi-Hop BFD Control Packet
By configuring a global destination port number for multi-hop BFD control packets, you can
implement the interworking between the local device and a device running an earlier version,
and between a Huawei device and a non-Huawei device.

Before configuring a global destination port number for multi-hop BFD control packets,
familiarize yourself with the applicable environment, complete the pre-configuration tasks, and
obtain the required data. This can help you complete the configuration task quickly and
accurately.
The BFD control packet is encapsulated in the UDP packet for transmission, using the source
port in the range of 49152 to 65535 and destination port 3784 or 4784. According to the
RFC5883, the destination port 4784 is used for the multi-hop BFD control packet. On the
S9700 of the earlier version, however, destination port 3784 is used for the multi-hop BFD
control packet.
The destination port number of the multi-hop BFD control packet can be configured globally
according to the requirements:
l To interwork with the device running the version earlier than the S9700, the device running
the S9700 can be configured with destination port 3784 for the multi-hop BFD control
packet.

l To interwork with the non-Huawei device, the device running the S9700 can be configured
with destination port 4784 for the multi-hop BFD control packet.
Before globally configuring the destination port number for the multi-hop BFD control packet,
complete the following tasks:
l Installing the device and turning it on properly
l Connecting interfaces correctly
Data Preparation
To globally configure the destination port number for the multi-hop BFD control packet, you
need the following data.
No. Data
1 Name of the device
7.7.2 Globally Configuring the Destination Port Number

You can configure a global destination port number for multi-hop BFD control packets according
to the specified devices running a distinct version or the specified vendor's devices.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
BFD is enabled globally on the local node and the BFD view is displayed.
Step 3 Run:
multi-hop destination-port { 3784 | 4784 }
The destination port number is configured globally for the multi-hop BFD control packet.

NOTE
If destination port 3784 is used by the multi-hop BFD control packets on a switch, the switch can
successfully negotiate with the switch on which destination port 4784 is used by the multi-hop BFD control
packets. At the same time, on the switch that is configured with destination port 3784, destination port
3784 is automatically updated to destination port 4784. To change the destination port number, run the
shutdown command to terminate the BFD session on destination port, then, run the multi-hop destination-
port command on destination ports 4784 and 3784, and finally run the undo shutdown command to restore
the BFD session.
----End

By viewing the destination port number and TTL in multi-hop BFD control packets, you can
check whether the configurations are successful.
Prerequisites
All global configurations of the destination port number of the multi-hop BFD control packet
are completed.
Context
NOTE
You can view information about the BFD session and its statistics only after only after BFD session
parameters are configured and the BFD session is set up successfully.
Procedure
l Run the display bfd session { all | discriminator discr-value | dynamic | peer-ip peer-
ip [ vpn-instance vpn-instance-name ] | static } [ verbose ] command to view information
about the BFD session.
l Run the display bfd statistics command to view information about statistics of global BFD.
----End
Example
After the configuration, run the display bfd session all verbose command.According to the
preceding command output, you can view that destination port 3784 is used for the multi-hop
BFD control packet.
---------------------------------------------------------------------
Session MIndex : 16384 (Multi Hop) State : Up Name : test
---------------------------------------------------------------------
Min Tx Interval (ms) : 10 Min Rx Interval (ms) :10


Active Multi : 3
Session TX TmrID : - Session Detect TmrID : -
PDT Index : FSM-B030000 | RCV-0 | IF-B030000 | TOKEN-0
---------------------------------------------------------------------------
7.8 Configuring the Delay of a BFD Session to Go Up

In certain scenarios a BFD session is configured to go Up after a delay. Setting a delay for a
BFD session status change to Up can prevent traffic loss that occurs if an interface goes Up
before the routing protocol.

Before configuring a delay for a BFD session status change to Up, familiarize yourself with the
applicable environment, complete the pre-configuration tasks, and obtain the data required for
the configuration.
If BFD is Up on a network, the interface bound to BFD goes Up and traffic can be switched
back to the interface. If the interface goes Up before the status of the routing protocol changes,
no route is available for forwarding and switching back traffic. As a result, traffic is dropped.
The time when the routing protocol goes Up and the time when the interface goes Up must be
synchronous.
Before configuring the delay of BFD session status change to Up, ensure that the switch runs
properly.
Data Preparation
No. Data
1 Delay time
7.8.2 Configuring the Delay for BFD Session Status Change to Up

The delay for BFD session status change to Up is configured to prevent traffic loss in special
scenarios.

Context
Perform the following procedure on the switchs on which the setup of the BFD session needs
to be delayed:
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd

Step 3 Run:
delay-up seconds
The length of the delay before a BFD session goes Up is set.

By default, the delay time is 0 seconds.
----End

By viewing the delay of a BFD session to go Up, you can check whether the configurations are
successful.
Prerequisites
The configurations of the delay of a BFD session to go Up are complete.
Procedure
Step 1 Run the display bfd statistics [ slot slot-id ] command to check statistics about global BFD.
----End
Example
# After the configuration, restart the switch. After the restart, run the display bfd statistics
command.The System Session Delay Up Timer field in the command output. This field displays
the status of the current system delay Up time. OFF indicates that the system is in the normal
state; Xs indicates that after X seconds, the system recovers, and the BFD session goes Up.
<Quidway> display bfd statistics
Current Display Board Number : Main ; Current Product Register Type: S9700
IP Multihop Destination Port : 3784
Total Up/Down Session Number : 0/1
Current Session Number :
Static session : 0 Dynamic session : 0
E_Dynamic session : 0 STATIC_AUTO session : 1
LDP_LSP session : 0 STATIC_LSP session : 0
TE_TUNNEL session : 0 TE_LSP session : 0
PW session : 0 IP session : 1
VSI PW session : 0

--------------------------------------------------------------------------------
PAF/LCS Name Maxnum Minnum Create
--------------------------------------------------------------------------------
BFD_CFG_NUM 8192 1 1
BFD_IF_NUM 512 1 1
BFD_SESSION_NUM 8192 1 1
BFD_IO_SESSION_NUM 512 1 0
BFD_PER_TUNNEL_CFG_NUM 16 1 0
--------------------------------------------------------------------------------
IO Board Current Created Session Statistics Information :(slot/number)
--------------------------------------------------------------------------------
0/1 1/0 2/0 3/0
4/0 5/0 6/0 7/0
8/0 9/0 10/0 11/0
12/0 13/0 14/0 15/0
16/0
--------------------------------------------------------------------------------
Current Total Used Discriminator Num : 1
--------------------------------------------------------------------------------
IO Board Reserved Sessions Number Information :(slot/number)
--------------------------------------------------------------------------------
0/0 1/0 2/0 3/0
4/0 5/0 6/0 7/0
8/0 9/0 10/0 11/0
12/0 13/0 14/0 15/0
16/0
--------------------------------------------------------------------------------
BFD HA Information :
--------------------------------------------------------------------------------
Core Current HA Status : Normal
Shell Current HA Status : Normal
--------------------------------------------------------------------------------
BFD for LSP Information :
--------------------------------------------------------------------------------
Ability of auto creating BFD session on egress : Disable
Period of LSP Ping : 60
System Session Delay Up Timer : OFF
--------------------------------------------------------------------------------
7.9 Configuring a BFD Session with the One-Arm Echo

Function
By configuring a BFD session with the one-arm Echo function, you can fast detect and monitor
a direct link between a BFD-capable device and a BFD-incapable device.

Before configuring the BFD session with the one-arm Echo function, familiarize yourself with
the applicable environment, complete the pre-configuration tasks, and obtain the required data.
This can help you complete the configuration task quickly and accurately.
On two directly-connected devices, one device supports BFD and the other does not. To fast
detect a link fault, you can create a BFD session with the one-arm Echo function on the BFD-
capable device. After the BFD-capable device sends a BFD Echo packet to the BFD-incapable
device, the BFD-incapable device directly loops back the packet, thus achieving fast detection
on the link.

Before configuring the BFD session with the one-arm Echo function, complete the following
tasks:
l Correctly connecting interfaces

l Correctly assigning an IP address to every Layer 3 interface
Data Preparation
To configure the BFD session with the one-arm Echo function, you need the following data.
No. Data
1 Name of a BFD session
2 Minimum interval at which BFD packets are received
7.9.2 Enable BFD Globally

BFD-associated configurations can be performed only after BFD has been enabled globally.
Context
Do as follows on the BFD-supported device at one end of a link.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
BFD is globally enabled and the BFD view is displayed.
----End
7.9.3 Establishing a BFD Session

By establishing a BFD session on a BFD-capable device, you can rapidly detect a direct link
between the BFD-capable device and its BFD-incapable peer.
Context
Do as follows on a BFD-capable device at one end of a link:

Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd cfg-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ] interface
interface-type interface-number [ source-ip source-ip ] one-arm-echo
A BFD session with the one-arm Echo function is created.
NOTE
l A BFD session with the one-arm Echo function can detect only single-hop links.
l When configuring the one-arm Echo function on the S9700 switch, set the source-ip source-ip to the
IP address of an interface (not the outbound interface) on the switch. Ensure that the peer device can
ping this IP address.
Step 3 Run:
The discriminator is set for the BFD session that one-arm Echo function configured.
The one-arm Echo function can be configured only on the BFD-capable device at one end of a
link. A BFD session with this function must be configured with a local discriminator rather than
a remote discriminator.

min-echo-rx-interval interval
The minimum interval between receipt of BFD packets is set.
By default, the minimum interval between receipt of BFD packets is 10 milliseconds.
Step 5 Run:
commit
The configuration is committed.
NOTE
After configuring the local discriminator parameter and any other required parameters for a BFD session
with the one-arm Echo function, you must run the commit command to make the configuration take effect.
----End

By viewing the type and status of a BFD session with the one-arm Echo function, you can check
whether the configurations are correct.
Prerequisites
The configurations of the one-arm Echo function are complete.

Procedure
l Run the display bfd configuration { all | static [ name cfg-name ] | discriminator local-
discr-value | dynamic | peer-ip peer-ip [ vpn-instance vpn-instance-name ] } [ verbose ]
command to check the configuration of a BFD session.
l Run the display bfd interface [ interface-type interface-number ] command to check
information about an interface configured with BFD.
ip [ vpn-instance vpn-instance-name ] | static } [ verbose ] command to check information
about a BFD session.
l Run the display bfd statistics session { all | static | dynamic | discriminator discr-
value | peer-ip [ vpn-instance vpn-instance-name ] } command to check statistics about
BFD sessions.
----End
Example
After a BFD session with the one-arm Echo function has been successfully configured, run the
display bfd session all verbose command, and you can view detailed information about the
session.
--------------------------------------------------------------------------------
Session MIndex : 256 (One Hop) State : Up Name : atob
--------------------------------------------------------------------------------
Local Discriminator : 1 Remote Discriminator : -
Session Detect Mode : Asynchronous One-arm-echo Mode
BFD Bind Type : Interface(gigabitEthernet1/0/0)
Bind Interface : EigabitEthernet1/0/0
Echo Rx Interval (ms) : 100
Active Multi : 3
--------------------------------------------------------------------------------
The command output shows that a single-hop BFD session has been created and its status is Up.
7.10 Configuring the TTL Function Globally

Configuring the TTL globally helps you connect the current device and a device running an early
version.


Before configuring the TTL globally, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the required data. This helps you complete the
If devices running different versions interwork with each other, the TTL values and detection
modes on both ends of a BFD session are different, resulting in BFD packet loss. The TTL is
set globally to enable Huawei devices to interwork with Huawei devices running different
S9700 versions and non-Huawei devices.
Before configuring the TTL globally, complete the following tasks:
l Connecting interfaces correctly
l Configuring the IP address of each Layer 3 interface correctly
Data Preparation
To configure the TTL globally, you need the following data.
No. Data
1 Name and number of each interface
7.10.2 Configuring the TTL Globally

The TTLs help you distinguish between a single-hop BFD session and a multi-hop BFD session
when a device interworks with a device running an early version.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
BFD is enabled globally on the local device and the BFD view is displayed.
Step 3 Run:
peer-ip peer-ip mask-length ttl { single-hop | multi-hop } ttl-value
The TTL in BFD control packets is set.

NOTE
l By default, in a static BFD session, the TTL for single-hop BFD packets is 255, and the TTL for multi-
hop BFD packets is 254; in a dynamic BFD session, the TTL for single-hop BFD packets is 255 and
the TTL for multi-hop BFD packets is 253.
l If a TTL is set for packets in a multi-hop BFD session that is in the same segment as a single-hop BFD
session, the single BFD session must be configured with the same IP address, a longer mask than that
for the multi-hop BFD session, and a TTL.
----End

By viewing the global TTL in BFD control packets, you can check whether the configurations
are successful.
Prerequisites
The configurations of the global TTL are completed.
Procedure
ip [ vpn-instance vpn-instance-name ] | static } [ verbose ] command to view information
about the BFD session.
l Run the display bfd ttl command to view information about the globally configured TTL.
----End
Example
After the configurations are successful, run the display bfd ttl command, and you can view
information about the global TTL.
<Quidway> display bfd ttl
--------------------------------------------------------------------------
Peer IP Mask Type Value
---------------------------------------------------------------------------
1.1.1.0 24 Single-hop 255
---------------------------------------------------------------------------
7.11 Configuring the Interval for Trap Messages Are Sent

The interval at which trap messages are sent is set, helping a device to suppress BFD trap
messages.

Before configuring the interval at which trap messages are sent, familiarize yourself with the
applicable environment, complete the pre-configuration tasks, and obtain the data required for
the configuration. This will help you complete the configuration task quickly and accurately.
If BFD is enabled with the SNMP trap function, the NMS receives messages indicating that the
BFD session is Up or Down. If the BFD session flaps, the NMS will receive a large number of

trap messages. In this case, BFD trap messages need to be suppressed. Setting the interval at
which trap messages are sent prevents overflow of trap messages.
Before configuring the interval at which trap messages are sent, enable BFD globally.
Data Preparation
To configure the interval at which trap messages are sent, you need the following data.
No. Data
1 Interval at which trap messages are sent
7.11.2 Configuring the Interval at Which Trap Messages Are Sent

When BFD sessions flap, the NMS receives a great number of trap messages. The interval at
which trap messages are sent is set, helping a device suppress trap messages.
Context
Do as follows on the switch that needs to be configured with the interval at which trap messages
are sent:
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
BFD is enabled globally, and the global BFD view is displayed.

Step 3 Run:
snmp-agent bfd trap-interval interval
The interval at which trap messages are sent is set.

By default, the interval at which trap messages are sent is 120 seconds.
----End

By viewing the interval at which trap messages are sent, you can check whether the
configurations are successful.
Prerequisites
The configurations of the interval at which trap messages are sent are complete.

Procedure
l Run the display current-configuration configuration bfd command to view the
configuration of the BFD trap function.
----End
Example
Run the display current-configuration configuration bfd command, and you can view that
the interval at which trap messages are sent is 300 seconds.
<Quidway> display current-configuration configuration bfd
#
bfd
snmp-agent bfd trap-interval 300
#
return
7.12 Configuring Association Between a BFD Session and

an Interface (Triggering the Physical Status of the Interface
Associated with the BFD Session to Become Down)
Association between a BFD session and an interface is applicable to the scenario where a CE is
directly connected to a PE. BFD is enabled on PEs and a BFD session is associated with an
interface. When the BFD session detects a link fault, the BFD module notifies the OAM
management module on the local PE of the fault. This triggers the physical status of the interface
to become Down.

Before configuring the association between a BFD session and an interface, you must create a
BFD session in static mode.
You can configure the association between a BFD session and an interface to enable the BFD
session or the interface to send messages to each other in case of failure. As shown in Figure
7-1, CE1 is directly connected to PE1 and PE3, and CE2 is directly connected to PE2 and PE4.
BFD sessions are created between PE1 and PE2 and between PE3 and PE4. When a fault occurs
on a link between PEs, a CE needs to detect the fault to ensure reliable service transmission. In
this case, the associations between BFD sessions and interfaces can be configured. When the
BFD session between PE1 and PE2 detects a link fault, the BFD module on a PE notifies the
OAM management module of the fault. This triggers the physical status of GE 1/0/1 on a PE
directly connected to a CE to become Down. The CE can then detect the fault and switch traffic
to a backup path, which ensures reliable service transmission.

Figure 7-1 Networking diagram of the association between a BFD session and an interface
PE1 PE2
GE1/0/1 GE1/0/1
BFD
CE1 CE2
PE3 PE4
Primary Link
Backup Link
Assume that the bidirectional association between a BFD session and an interface is configured
on each PE. When GE 1/0/1 on PE1 connected to CE1 becomes Down, PE1 notifies the OAM
management module of the fault, and then the OAM management module forwards fault
information to the BFD session associated with GE 1/0/1. The fault information is sent to the
OAM management module on PE2 through BFD, which triggers the physical status of GE 1/0/1
to become Down. In this manner, CE2 can detect the fault and switch traffic to a backup path,
which ensures reliable service transmission.
NOTE
Currently, the association between a BFD session and an interface is inapplicable to links detected by the
BFD session for PWs.
The BFD session can be associated with the interface connecting a PE to a CE but not the interface
connecting two PEs (that is, the outbound interface of the BFD session).
Before configuring the association between a BFD session and an interface, complete the
following task:
l Creating a BFD session
Data Preparation
To configure the association between a BFD session and an interface, you need the following
data.
No. Data
1 ID of a BFD session, namely, local discriminator of a BFD session

No. Data
2 Type and number of each interface associated with a BFD session
7.12.2 Configuring Association Between a BFD Session and an

Interface
One BFD session is associated with only one interface. For example, when an interface is
associated with a BFD session, the interface cannot be associated with another BFD session. In
addition, when a BFD session is associated with an interface, the BFD session cannot be
associated with another interface.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
oam-mgr

Step 3 Run the following command as required:
l Run:
oam-bind ingress bfd-session bfd-session-id trigger if-down egress interface
interface-type interface-number
The unidirectional transmission of fault information from a BFD session to an interface is

configured.
When the BFD session detects a fault, the physical status of the interface associated with the
BFD session becomes Down.
l Run:
oam-bind ingress interface interface-type interface-number egress bfd-session
bfd-session-id trigger if-down
The unidirectional transmission of fault information from an interface to a BFD session is

configured.
When an interface goes Down, the OAM management module can send fault information to
the BFD session associated with the interface, and then the BFD session sends the fault
information to the remote device.
l Run:
oam-bind bfd-session bfd-session-id trigger if-down interface interface-type
interface-number
The bidirectional transmission of fault information between a BFD session and an interface
is configured.

NOTE
If oam-bind bfd-session bfd-session-id trigger if-down interface interface-type interface-number

command is performed, both the oam-bind ingress bfd-session bfd-session-id trigger if-down egress
interface interface-type interface-number command and the oam-bind ingress interface interface-
type interface-number egress bfd-session bfd-session-id trigger if-down command are displayed in
the configuration file, indicating fault notification in opposite directions.
----End

After the association between a BFD session and an interface is successfully configured, you
can view the association configuration in the OAM management view.
Prerequisites
All configurations of the association between a BFD session and an interface is complete.
Procedure
Step 1 Run the display this command in the OAM management view to check whether a BFD session
and an interface are successfully associated.
----End
Example
Run the display this command. You can view all associations between BFD sessions and
interfaces.
#
oam-mgr
oam-bind ingress interface GigabitEthernet0/0/1 egress bfd-session 1 trigger if-
down
oam-bind ingress bfd-session 1 trigger if-down egress interface
#
return
7.13 Configuring Association Between BFD Sessions

After the association between BFD sessions is configured, the local BFD session can detect a
fault and then notify the OAM management module of the fault. The OAM management module
sends fault information to the associated BFD session. The associated BFD session then sends
BFD packets carrying the fault information to the OAM management module on the remote
device. In this manner, the fault is notified to the remote device.

Before configuring the association between BFD sessions, you must create the two BFD sessions
in static mode.

As shown in Figure 7-2, BFD sessions are created between CE1 and PE1, between CE2 and
PE2, and between PE1 and PE2. When a fault occurs on a link between CE1 and PE1, CE2 needs
to detect the fault to ensure reliable service transmission. In this case, the association between
BFD sessions needs to be configured. When the BFD session between CE1 and PE1 detects a
fault, the BFD session on PE1 notifies the OAM management module of the fault. The OAM
management module notifies the associated BFD session on PE2. The BFD session sends the
fault information to the OAM management module on PE2. Then, the OAM management
module on PE2 notifies CE2 through BFD of the fault. CE2 can then detect the fault.
Figure 7-2 Networking diagram of the association between BFD sessions
CE1 PE1 PE2 CE2
BFD
Before configuring the association between BFD sessions, complete the following task:
l Creating BFD sessions
Data Preparation
To configure the association between BFD sessions, you need the following data.
No. Data
1 ID of each BFD session, namely, local discriminator of a BFD session
7.13.2 Configuring Association Between BFD sessions

Two BFD sessions can be associated with each other only. That is, after BFD session 1 is
associated with BFD session 2, neither of them can be associated with another BFD session.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
oam-mgr

Step 3 Run the following command as required:
l Run:
oam-bind ingress bfd-session bfd-session-id egress bfd-session bfd-sessionid
The unidirectional transmission of fault information from one BFD session to the other BFD
session is configured.
After the configuration, when detecting a fault, BFD session bfd-session-id1 can send fault
messages to BFD session bfd-session-id2.
l Run:
oam-bind bfd-session bfd-session-id bfd-session bfd-session-id
The bidirectional transmission of fault information between two BFD sessions is configured.
NOTE
If Step 4 is performed, two oam-bind ingress bfd-session bfd-session-id egress bfd-session bfd-
sessionid commands are displayed in the configuration file, indicating fault notification in opposite
directions.
----End

After the association between BFD sessions is successfully configured, you can view the
association configuration in the OAM management view.
Prerequisites
All configurations of the association between BFD sessions are complete.
Procedure
Step 1 Run the display this command in the OAM management view to check whether two BFD
sessions are successfully associated.
----End
Example
Run the display this command. You can view all associations between BFD sessions.
#
oam-mgr
oam-bind ingress bfd-session 1 egress bfd-session 2
#
return
7.14 Maintaining BFD

This section describes how to maintain BFD by deleting BFD statistics, and monitoring BFD
operations.

7.14.1 Clearing BFD Statistics

Deleting previous BFD statistics before collecting BFD statistics within a specified period of
time is recommended.
Context
CAUTION
BFD statistics cannot be restored after being deleted. Exercise caution when using the command.
Procedure
l Run the reset bfd statistics { all | discriminator discr-value } command in the user view
to delete BFD statistics.
----End
7.14.2 Debugging BFD

Debugging is used to troubleshoot BFD performance problems.
Context
CAUTION
Debugging affects system performance. After debugging is complete, run undo debugging
all command to disable debugging immediately.
If a BFD fault occurs, run the following debugging command in the user view to locate the fault.
Procedure
Step 1 Run the debugging bfd { all | defect-detect | error | event | fsm | ha | packet | process | product-
interface | session-management | timer } command in the user view to enable the debugging
of the BFD module.
----End

This section provides several configuration examples of BFD.
Context
For configuration examples of BFD for static LDP, see Example for Configuring Static BFD
for Static LSPs in the S9700 Core Routing Switch Configuration Guide - MPLS.

For configuration examples of BFD for LDP LSPs, see Example for Configuring Static BFD
for LDP LSPs and Example for Configuring Dynamic BFD for LDP LSPs in the S9700 Core
Routing Switch Configuration Guide - MPLS.
For configuration examples of BFD for MPLS TE tunnels, see Example for Configuring Static
BFD for CR-LSPs, Example for Configuring Static BFD for TE Tunnels, Example for
Configuring Dynamic BFD for CR-LSPs, and Example for Configuring Dynamic BFD for
RSVP in the S9700 Core Routing Switch Configuration Guide - MPLS.
7.15.1 Example for Configuring Single-Hop BFD on a Layer 2

Interface
Interfaces of the S9700 are Layer 2 interfaces. If you need to detect the connectivity of the Layer
2 forwarding link between two directly connected S9700s, configure single-hop BFD, and bind
the BFD session to a multicast IP address and local interface.
As shown in Figure 7-3, a BFD session is created to detect the connectivity of the Layer 2 link
between Switch A and Switch B.
Figure 7-3 Networking diagram of single-hop BFD (for Layer 2 forwarding link)
GE1/0/1 GE1/0/1
SwitchA SwitchB
1. Configure a BFD session on Switch A to detect the direct link from Switch A to Switch B.
2. Configure a BFD session on Switch B to detect the direct link from Switch B to Switch A.
Data Preparation
l Type and number of the interface bound to the BFD session
l Local and remote identifiers of the BFD session
Use the default values of the minimum sending interval, the minimum receiving interval, and
the local detection multiplier of BFD control packets.
Procedure
Step 1 Configure single-hop BFD on Switch A.
# Enable BFD on Switch A.

[SwitchA] bfd
[SwitchA-bfd] quit
# Create a BFD session on Switch A.

[SwitchA] bfd atob bind peer-ip default-ip interface gigabitethernet 1/0/1
[SwitchA-bfd-session-atob] discriminator local 1
[SwitchA-bfd-session-atob] discriminator remote 2
[SwitchA-bfd-session-atob] quit
Step 2 Configure single-hop BFD on Switch B.
# Enable BFD on Switch B.

[SwitchB] bfd
[SwitchB-bfd] quit
# Create a BFD session on Switch B.

[SwitchB] bfd btoa bind peer-ip default-ip interface gigabitethernet 1/0/1
[SwitchB-bfd-session-btoa] discriminator local 2
[SwitchB-bfd-session-btoa] discriminator remote 1
[SwitchB-bfd-session-btoa] quit
After the configuration, run the display bfd session command on Switch A and Switch B, and
you can find that a single-hop BFD session is set up and is in Up state.
Take Switch A for example. The display is as follows:

<SwitchA> display bfd session all verbose
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Active Multi : 3
Session TX TmrID : - Session Detect TmrID : -
--------------------------------------------------------------------------------
----End

Configuration Files
#
sysname SwitchA
#
bfd
#
bfd atob bind peer-ip default-ip interface GigabitEthernet1/0/1
#
return

#
sysname SwitchB
#
bfd
#
bfd btoa bind peer-ip default-ip interface GigabitEthernet1/0/1
#
return
7.15.2 Example for Configuring Single-Hop BFD on a VLANIF

Interface
The S9700s are connected through the VLANIF interface at Layer 3. To detect the connectivity
of the link between two directly connected S9700s, you can configure single-hop BFD to bind
the BFD session to the VLANIF interface and its IP address.
As shown in Figure 7-4, a BFD session is created to detect the connectivity of the link between
Switch A and Switch B.
Figure 7-4 Networking diagram for configuring single-hop BFD on a VLANIF interface
VLANIF 13 VLANIF 13
10.1.1.5/24 10.1.1.6/24
GE1/0/1 GE1/0/1
SwitchA SwitchB
1. Create VLAN 13 on Switch A and Switch B.

2. Configure GE 1/0/1 interfaces on Switch A and Switch B as hybrid interfaces.
3. Create VLANIF 13 on Switch A and Switch B and set their IP address.
4. Create a BFD session on Switch A to detect the link between Switch A and Switch B.

5. Create a BFD session on Switch B to detect the link between Switch B and Switch A.
Data Preparation
l Numbers of VLANIF interfaces bound to BFD sessions
l IP addresses of VLANIF interfaces
l Local and remote discriminators of BFD sessions
Default values of minimum intervals for sending BFD control packets, minimum intervals for
receiving BFD control packets, and local detection multipliers
Procedure
Step 1 On Switch A and Switch B, create VLAN 13, configure GE 1/0/1 interfaces as hybrid interfaces,
and add GE 1/0/1 interfaces to VLAN 13.
[SwitchA] vlan 13
[SwitchA-GigabitEthernet1/0/1] port hybrid pvid vlan 13
[SwitchA-GigabitEthernet1/0/1] port hybrid untagged vlan 13
[SwitchB] vlan 13
[SwitchB-GigabitEthernet1/0/1] port hybrid pvid vlan 13
[SwitchB-GigabitEthernet1/0/1] port hybrid untagged vlan 13
Step 2 Set IP addresses of VLANIF 13 interfaces so that Switch A can communicate with Switch B at
Layer 3.
[SwitchA] interface vlanif13
[SwitchA-Vlanif13] ip address 10.1.1.5 24
[SwitchA-Vlanif13] quit
[SwitchB] interface vlanif13
[SwitchB-Vlanif13] ip address 10.1.1.6 24
[SwitchB-Vlanif13] quit
After the configuration, run the display interface vlanif command on Switch A or Switch B.
You can view that the status of VLANIF 13 is Up.
[SwitchA] display interface vlanif 13
Vlanif13 current state : UP
Line protocol current state : UP
Last line protocol up time : 2007-10-19 11:46:42 UTC-08:00
Description:HUAWEI, Quidway Series, Vlanif13 Interface
Route Port,The Maximum Frame Length is 1500

Internet Address is 10.1.1.5/24

Input bandwidth utilization : --
Output bandwidth utilization : --
Step 3 Configure single-hop BFD on Switch A.

# Enable BFD on Switch A.
[SwitchA] bfd
[SwitchA-bfd] quit

[SwitchA] bfd atob bind peer-ip 10.1.1.6 interface vlanif 13
Step 4 Configure single-hop BFD on Switch B.

# Enable BFD on Switch B.
[SwitchB] bfd
[SwitchB-bfd] quit

[SwitchB] bfd btoa bind peer-ip 10.1.1.5 interface vlanif 13

After the configuration, run the display bfd session command on Switch A and Switch B. You
can view that the single-hop BFD session is set up and the status is Up.
Take the display on Switch A as an example.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Active Multi : 3
Session Init TmrID : 16898 Session WTR TmrID : -
--------------------------------------------------------------------------------

----End
Configuration Files
#
sysname SwitchA
#
vlan batch 13
#
bfd
#
interface Vlanif13
ip address 10.1.1.5 255.255.255.0
#
port hybrid untagged vlan 13
#
bfd atob bind peer-ip 10.1.1.6 interface Vlanif13
#
return

#
sysname SwitchB
#
vlan batch 13
#
bfd
#
interface Vlanif13
ip address 10.1.1.6 255.255.255.0
#
#
bfd atob bind peer-ip 10.1.1.5 interface Vlanif13
#
return
7.15.3 Example for Configuring Multi-Hop BFD

As shown in Figure 7-5, a BFD session is used to test the multi-hop path between Switch A and
Switch C.
Interfaces of the S9700 are Layer 2 interfaces. To configure multi-hop BFD, you need to add an
interface to a VLAN, create a VLANIF interface, and assign an IP address to the VLANIF
interface.

Figure 7-5 Networking diagram of multi-hop BFD
GE1/0/1 GE1/0/1 GE1/0/2 GE1/0/1
VLAN 10 VLAN 20
SwitchA
SwitchB SwitchC
1. Configure a BFD session on Switch A to detect the multi-hop path from Switch A to Switch
C.
2. Configure a BFD session on Switch C to detect the multi-hop path from Switch C to Switch
A.
Data Preparation
l Peer IP address bound to the BFD session

l Local and remote identifiers of the BFD session
l IP address of VLANIF 10 on Switch A: 10.1.1.1/16
l IP address of VLANIF 10 on Switch B: 10.1.1.2/16
l IP address of VLANIF 20 on Switch B: 10.2.1.1/16
l IP address of VLANIF 20 on Switch C: 10.2.1.2/16
the local detection multiplier of a BFD control packet.
Procedure
Step 1 Add interfaces to VLANs, create VLANIF interfaces, and assign an IP address to each VLANIF
interface.
# Create a VLAN on Switch A and add the interface to the VLAN.

[SwitchA] vlan batch 10
# Create a VLANIF interface and assign an IP address to the VLANIF interface.

[SwitchA] interface vlanif 10

The configurations of Switch B and Switch C are the same as the configuration of Switch A,
and are not mentioned here.
Step 2 Configure a reachable static route between Switch A and Switch C.
[SwitchA] ip route-static 10.2.0.0 16 10.1.1.2
The configuration of Switch C is the same as the configuration of Switch A, and is not mentioned
here.
Step 3 Configure multi-hop BFD on Switch A and Switch C.
# Create a BFD session with Switch C on Switch A.
[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] bfd atoc bind peer-ip 10.2.1.2
[SwitchA-bfd-session-atoc] discriminator local 10
[SwitchA-bfd-session-atoc] discriminator remote 20
[SwitchA-bfd-session-atoc] quit
# Create a BFD session with Switch A on Switch C.

[SwitchC] bfd
[SwitchC-bfd] quit
[SwitchC] bfd ctoa bind peer-ip 10.1.1.1
[SwitchC-bfd-session-ctoa] discriminator local 20
[SwitchC-bfd-session-ctoa] discriminator remote 10
[SwitchC-bfd-session-ctoa] quit

After the configuration is complete, run the display bfd session command on Switch A and
Switch C, and you can find that a BFD session is set up and is in Up state.
--------------------------------------------------------------------------------
Session MIndex : 4097 (One Hop) State : Up Name : atoc
--------------------------------------------------------------------------------
Active Multi : 3
Session Init TmrID : 16898 Session WTR TmrID : -
--------------------------------------------------------------------------------
----End

Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.0.0
#
#
bfd atoc bind peer-ip 10.2.1.2
commit
#
ip route-static 10.2.0.0 255.255.0.0 10.1.1.2
#
return

#
sysname SwitchB
#
vlan batch 10 20
#
interface Vlanif10
ip address 10.1.1.2 255.255.0.0
#
interface Vlanif20
ip address 10.2.1.1 255.255.0.0
#
#
#
return

#
sysname SwitchC
#
bfd
#
vlan batch 20
#
interface Vlanif20
ip address 10.2.1.2 255.255.0.0
#
#
bfd ctoa bind peer-ip 10.1.1.1
commit
#
ip route-static 10.1.0.0 255.255.0.0 10.2.1.1

#
return
7.15.4 Example for Associating the BFD Status with the Interface
Status
As shown in Figure 7-6, transmission devices exist on the link. After the BFD status is associated
with the interface status, the status change of the BFD session between GE 1/0/0 of Switch A
and GE 1/0/0 of Switch B affects the protocol status of the interfaces when the link between
transmission devices fails. Fast convergence of routes is triggered.
Figure 7-6 Networking diagram for associating the BFD session status with the interface status
VLAINF10 VLAINF10
10.1.1.1/24 10.1.1.2/24
GE1/0/0 GE1/0/0
SwitchA SwitchB
1. Create a BFD session on Switch A.

2. Create a BFD session on Switch B.
3. Associate the BFD status with the interface status on Switch A when the BFD session is
Up.
4. Associate the BFD status with the interface status on Switch B when the BFD session is
Up.
Data Preparation

l Local interface that sends and receives BFD control packets
l Local discriminator and remote discriminator of the BFD session
the local detection multiplier of a BFD control packet.
Procedure
Step 1 Set the IP addresses of the interfaces through which Switch A and Switch B are directly
connected.
# Assign an IP address to the interface of Switch A.

[SwitchA] vlan 10
# Assign an IP address to the interface of Switch B.

[SwitchB] vlan 10
[SwitchB] interface vlanif 10
Step 2 Configure single-hop BFD.

# On Switch A, enable BFD and create a BFD session with Switch B.
[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] bfd atob bind peer-ip default-ip interface gigabitethernet 1/0/0
# On Switch B, create a BFD session with Switch A.

[SwitchB] bfd
[SwitchB-bfd] quit
[SwitchB] bfd btoa bind peer-ip default-ip interface gigabitethernet 1/0/0
# Run the display bfd session all verbose command on Switch A and Switch B, and you can
find that a single-hop BFD session is set up and is in Up state. Take Switch A for example. The
display is as follows:
[SwitchA] display bfd session all verbose
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Bind Peer Ip Address : 224.0.0.184
Echo Passive : Disable Acl Number : --
Proc interface status : Enable Process PST : Disable
WTR Interval (ms) : --

Active Multi : 3
Session TX TmrID : -- Session Detect TmrID : --
Session Init TmrID : -- Session WTR TmrID : --
Session Description : --
--------------------------------------------------------------------------------
Step 3 Associate the BFD session status with the interface status.
# Associate the BFD status with the interface status on Switch A.

[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] bfd atob
[SwitchA-bfd-session-atob] process-interface-status
# Associate the BFD status with the interface status on Switch B.

[SwitchB] bfd
[SwitchB-bfd] quit
[SwitchB] bfd btoa
[SwitchB-bfd-session-btoa] process-interface-status
After the configuration is complete, run the display bfd session all verbose command on Switch
A and Switch B, and you can find that the Proc interface status displays field is Enable.

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Active Multi : 3
Bind Application : IFNET
--------------------------------------------------------------------------------
Run the shutdown command on GE 1/0/0 of Switch B so that the BFD session is Down.


[SwitchB-GigabitEthernet1/0/0] shutdown
Run the display bfd session all verbose and display interface gigabitethernet 1/0/0 commands
on Switch A, and you can find that the status of the BFD session is Down, and the status of GE
1/0/0 is Up (BFD status down).
--------------------------------------------------------------------------------
Session MIndex : 16384 (One Hop) State : Down Name : atob
--------------------------------------------------------------------------------
Active Multi : 3
Last Local Diagnostic : Neighbor Signaled Session Down
Bind Application : IFNET
--------------------------------------------------------------------------------

[SwitchA] display interface gigabitethernet 1/0/0
GigabitEthernet1/0/0 current state : UP
Line protocol current state : UP(BFD status down)
QoS max-bandwidth : 1000000 Kbps
Output queue : (Urgent queue : Size/Length/Discards) 0/50/0
Output queue : (Protocol queue : Size/Length/Discards) 0/1000/0
Output queue : (FIFO queue : Size/Length/Discards) 0/256/0

Last physical down time : 2007-10-18 12:02:27 UTC-08:00
Mdi : NORMAL
Input peak rate 27725312 bits/sec,Record time: 2007-10-18 12:15:22
Output peak rate 914311728 bits/sec,Record time: 2007-10-18 13:28:10
Unicast : 731, Multicast : 2537
Broadcast : 31215405, Jumbo : 0
CRC : 0, Giants : 0
Jabbers : 0, Throttles : 0
Runts : 0, DropEvents : 0
Alignments : 0, Symbols : 0
Ignoreds : 0, Frames : 0
Discard : 31215393, Total Error : 0

Unicast : 1453, Multicast : 2597

Broadcast : 8462845739, Jumbo : 0
Collisions : 0, Deferreds : 0
Late Collisions: 0, ExcessiveCollisions: 0
Buffers Purged : 0
Discard : 0, Total Error : 0
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
#
bfd atob bind peer-ip default-ip interface GigabitEthernet1/0/0
process-interface-status
#
return
#
sysname SwitchB
#
vlan batch 10
#
bfd
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
port hybrid untagged vlan10
#
bfd btoa bind peer-ip default-ip interface GigabitEthernet1/0/0
process-interface-status
#
return
7.15.5 Example for Configuring Association Between a BFD Session

and an Interface
As shown in Figure 7-7, BFD can be configured on CEs and PEs; BFD sessions are created
between PEs; CE1 is connected to PE1 and PE2 and CE2 is connected to PE3 and PE4 in dual-

homing mode. Normally, the traffic is forwarded through the primary path CE1 -> PE1 -> PE3
-> CE2. If the BFD session between the PEs detects a fault on the link, a fault notification
message is encapsulated into a BFD packet and then sent to the OAM management module.
After receiving the BFD packet, the OAM management module triggers the physical status of
the interface bound to the BFD session to go Down.
NOTE
The CEs must be directly connected to the PEs and no Layer 2 devices are deployed between CE and PE.
Figure 7-7 Networking diagram for configuring association between a BFD session and an
interface
GE 1/0/2
PE1 Vlanif20 PE3
20.1.1.1/24
GE 1/0/2
GE 1/0/1 Vlanif30
Vlanif10 GE 1/0/1
Vlanif20 30.1.1.1/24
10.1.1.2/24
20.1.1.2/24
GE 1/0/1 GE 1/0/1
GE 1/0/3 CE2 GE 1/0/3
Vlanif10 Vlanif30
Vlanif100 Vlanif110
10.1.1.1/24 30.1.1.2/24
100.1.1.1/24 110.1.1.1/24
CE1
GE 1/0/2 GE 1/0/2
Vlanif40 Vlanif60
40.1.1.1/24 GE 1/0/2 60.1.1.1/24
Vlanif50
GE 1/0/1 GE 1/0/2
50.1.1.1/24
Vlanif40 Vlanif60
40.1.1.2 GE 1/0/1 60.1.1.2/24
PE2 Vlanif50 PE4
50.1.1.2/24
1. Set IP addresses of interfaces according to Figure 7-7.

2. Advertise routes through OSPF and set the OSPF cost of VLANIF40 on CE1 and
VLANIF60 on CE2 to 10 so that traffic is transmitted through the primary path CE1 ->
PE1 -> PE3 -> CE2.
3. Create a BFD session on PE1 to detect the directly connected link between PE1 and PE2.
4. Create a BFD session on PE3 to detect the directly connected link between PE2 and PE1.
5. Associate the BFD session with GE 1/0/1 on PE1 and associate the BFD session with GE
1/0/2 on PE3.
Data Preparation
l VLANs allowed by interfaces

l Peer IP addresses to be detected by BFD sessions

l Local discriminators and remote discriminators of BFD sessions
Default values of the minimum interval for sending packets, the minimum interval for receiving
packets, and the local detection multiplier
Procedure
Step 1 Set IP addresses.
Configure VLANs allowed by interfaces and assign IP addresses to VLANIF interfaces. For
details, see Figure 7-7.
Step 2 Configure a routing protocol.
In this example, OSPF is used.
Run OSPF on CEs and PEs. To ensure that traffic is transmitted through the path CE1 -> PE1 -
> PE3 -> CE2, increase the OSPF cost of VLANIF 40 on CE1 and VLANIF 60 on CE2. For
example, change the cost to 10.
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0.0.0.0
[PE1-ospf-1] quit
The configurations of PE2, PE3, and PE4 are similar to the configuration of PE1, and are not
mentioned here.
# Configure CE1.
[CE1] ospf 1
[CE1-ospf-1] quit
[CE1-Vlanif40] quit
# Configure CE2.
[CE2] ospf 1
[CE2-ospf-1] quit
[CE2-Vlanif60] quit

Run the display ip routing-table command on CE1, and you can view that the outbound
interface for the route from CE1 to 110.1.1.0/24 is VLANIF 10. That is, traffic is transmitted
along the primary path.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Vlanif10

20.1.1.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
30.1.1.0/24 OSPF 10 3 D 110.1.1.2 Vlanif10
40.1.1.0/24 Direct 0 0 D 40.1.1.2 Vlanif40
50.1.1.0/24 OSPF 10 2 D 40.1.1.2 Vlanif40
60.1.1.0/24 OSPF 10 3 D 40.1.1.2 Vlanif40
110.1.1.0/24 OSPF 10 4 D 10.1.1.2 Vlanif10
Step 3 Create BFD sessions.
# Configure PE1.
[PE1] bfd
[PE1-bfd] quit
[PE1] bfd pe1tope3 bind peer-ip 20.1.1.2 interface Vlanif20
[PE1-bfd-session-pe1tope3] discriminator local 1
[PE1-bfd-session-pe1tope3] discriminator remote 2
[PE1-bfd-session-pe1tope3] commit
[PE1-bfd-session-pe1tope3] quit
# Configure PE3.
[PE3] bfd
[PE3-bfd] quit
[PE3] bfd pe3tope1 bind peer-ip 20.1.1.1 interface Vlanif20
Step 4 Associate BFD sessions with interfaces.
Associate the BFD session with GE 1/0/1.
# Configure PE1.
[PE1] oam-mgr
[PE1-oam-mgr] oam-bind bfd-session 1 trigger if-down interface gigabitethernet
1/0/1
[PE1-oam-mgr] quit
# Configure PE3.
[PE3] oam-mgr
[PE3-oam-mgr] oam-bind bfd-session 2 trigger if-down interface gigabitethernet
1/0/2
[PE3-oam-mgr] quit

Run the shutdown command on GE 1/0/1 of PE3 to simulate the link fault. After receiving the
fault notification message encapsulated into a BFD packet that is sent by the OAM management
module, CE1 can detect the link fault between PE1 and PE3.
Run the display bfd session all verbose command on PE1, and you can view that the BFD
session becomes Down and the value of Bind Application is ETHOAM.
--------------------------------------------------------------------------------
Session MIndex : 258 (Multi Hop) State : Down Name : pe1tope3
--------------------------------------------------------------------------------
Bind Interface :
Vlanif20
Active Multi : 3
--------------------------------------------------------------------------------
Run the display ip routing table command on CE1 to check the route from CE1 to CE2. The
next hop of 110.1.1.0/24 is 40.1.1.2. That is, the traffic is forwarded through the backup path.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Vlanif10

20.1.1.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
30.1.1.0/24 OSPF 10 3 D 110.1.1.2 Vlanif10
40.1.1.0/24 Direct 0 0 D 40.1.1.2 Vlanif40
50.1.1.0/24 OSPF 10 2 D 40.1.1.2 Vlanif40
60.1.1.0/24 OSPF 10 3 D 40.1.1.2 Vlanif40
110.1.1.0/24 OSPF 10 13 D 40.1.1.2 Vlanif40
----End

Configuration Files
#
sysname CE1
#
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.252
#
interface Vlanif40
ip address 40.1.1.1 255.255.255.252
ospf cost 10
#
interface Vlanif100
ip address 100.1.1.1 255.255.255.252
#
#
#
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
network 100.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
#
bfd
#
interface Vlanif30
ip address 30.1.1.2 255.255.255.252
#
interface Vlanif60
ip address 60.1.1.1 255.255.255.252
ospf cost 10
#
interface Vlanif110
ip address 110.1.1.1 255.255.255.252
#
#
#

#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255
network 60.1.1.0 0.0.0.255
network 110.1.1.0 0.0.0.255
#
return
#
sysname PE1
#
vlan batch 10 20
#
bfd
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.252
#
interface Vlanif20
ip address 20.1.1.1 255.255.255.252
#
#
#
bfd pe1tope3 bind peer-ip 20.1.1.2 interface Vlanif20
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
oam-mgr
oam-bind ingress interface GigabitEthernet1/0/1 egress bfd-session 1 trigger
if-down
#
return
#
sysname PE3
#
vlan batch 20 30
#
bfd
#
interface Vlanif20
ip address 20.1.1.2 255.255.255.252
#
interface Vlanif30
ip address 30.1.1.1 255.255.255.252
#
#
#


commit
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
oam-mgr
oam-bind ingress interface GigabitEthernet1/0/2 egress bfd-session 1 trigger
if-down
#
return
7.15.6 Example for Configuring Association Between the Status of

BFD Sessions
As shown in Figure 7-8, BFD runs between PEs and between PEs and CEs. CE1 is connected
to PE1 and PE2, and CE2 is connected to PE3 and PE4 in dual-homing mode. Normally, the
traffic is forwarded through the primary path CE1 -> PE1 -> PE3 -> CE2. When a fault occurs
on the link between PE1 and PE3, a fault notification message is transmitted to CE1 and CE2
through association between the status of BFD sessions on PE1 and PE3. Then, the traffic is
switched to the standby path CE1 -> PE2 -> PE4 -> CE2.
In this case, you can deploy association between the status of BFD sessions. When the BFD
session between the PEs detects a fault, a fault notification message is encapsulated into a BFD
packet and sent to the remote CE through the OAM management module. Then the CE detects
the fault and switches the traffic to the backup link.
Figure 7-8 Networking diagram for configuring association between the status of BFD sessions
GE 1/0/2
PE1 Vlanif20 PE3
20.1.1.1/24 GE 1/0/2
GE 1/0/1 Vlanif30
Vlanif10 GE 1/0/1
Vlanif20 30.1.1.1/24
10.1.1.2/24
20.1.1.2/24
GE 1/0/1 GE 1/0/1
CE1 Vlanif10 Vlanif30 CE2
10.1.1.1/24 30.1.1.2/24
GE 1/0/2 GE 1/0/2
Vlanif40 Vlanif60
40.1.1.1/24 GE 1/0/2 60.1.1.1/24
GE 1/0/1 Vlanif50 GE 1/0/2
Vlanif40 50.1.1.1/24 Vlanif60
40.1.1.2 GE 1/0/1 60.1.1.2/24
PE2 Vlanif50 PE4
50.1.1.2/24

1. Create BFD sessions between CE1 and PE1, between PE1 and PE3, and between PE3 and
CE2.
2. On PE1, configure bidirectional transmission of fault notification messages between CE1
and PE1 and between PE1 and PE3.
3. On PE3, configure bidirectional transmission of fault notification messages between PE1
and PE3 and between PE3 and CE2.
NOTE
In this example, PEs and CEs are Switches.
Data Preparation
l VLAN IDs of frames that are allowed on the interfaces
l Local discriminator and remote discriminator of the BFD session
Default values of the minimum interval for sending packets, the minimum interval for receiving
packets, and the local detection multiplier
Procedure
Step 1 Set IP addresses.
Configure the VLAN IDs of frames allowed by interfaces and assign IP addresses to VLANIF
interfaces. For details, see Figure 7-8.
Step 2 Configure the routing protocol.
In this example, OSPF is used.
Run OSPF on CE and PE devices. To ensure that traffic is transmitted through the path CE1 ->
PE1 -> PE3 -> CE2, increase the OSPF cost on VLANIF 40 of CE1 and VLANIF 60 of CE2.
For example, change the cost to 10.
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0.0.0.0
[PE1-ospf-1] quit
The configurations of PE2, PE3, and PE4 are similar to the configuration of PE1, and are not
mentioned here.

# Configure CE1.
[CE1] ospf 1
[CE1-ospf-1] quit
[CE1-Vlanif40] quit
# Configure CE2.
[CE2] ospf 1
[CE2-ospf-1] quit
[CE2-Vlanif60] quit
Run the display ip routing-table command on CE1, and you can view that the outgoing interface
for the route from CE1 to 110.1.1.0/24 is VLANIF 10. That is, the traffic is transmitted through
the primary path.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Vlanif10

20.1.1.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
30.1.1.0/24 OSPF 10 3 D 110.1.1.2 Vlanif10
40.1.1.0/24 Direct 0 0 D 40.1.1.2 Vlanif40
50.1.1.0/24 OSPF 10 2 D 40.1.1.2 Vlanif40
60.1.1.0/24 OSPF 10 3 D 40.1.1.2 Vlanif40
110.1.1.0/24 OSPF 10 4 D 10.1.1.2 Vlanif10
Step 3 Create BFD sessions.

# Configure CE1.
[CE1] bfd
[CE1-bfd] quit
[CE1] bfd ce1tope1 peer-ip 10.1.1.2 interface vlanif 10
[CE1-bfd-session-ce1tope1] discriminator local 10
[CE1-bfd-session-ce1tope1] discriminator remote 11
[CE1-bfd-session-ce1tope1] quit
# Configure PE1.
[PE1] bfd
[PE1-bfd] quit

[PE1] bfd pe1toce1 peer-ip 10.1.1.1 interface vlanif 10

[PE1-bfd-session-pe1toce1] discriminator local 11
[PE1-bfd-session-pe1toce1] discriminator remote 10
[PE1-bfd-session-pe1toce1] quit
[PE1] bfd pe1tope3 peer-ip 20.1.1.2 interface vlanif 20
# Configure PE3.
[PE3] bfd
[PE3-bfd] quit
[PE3] bfd pe3toce2 peer-ip 30.1.1.2 interface vlanif 30
[PE3-bfd-session-pe3toce2] discriminator local 32
[PE3-bfd-session-pe3toce2] discriminator remote 23
[PE3-bfd-session-pe3toce2] quit
[PE3] bfd pe3tope1 peer-ip 20.1.1.1 interface vlanif 20
# Configure CE2.
[CE2] bfd
[CE2-bfd] quit
[CE2] bfd ce2tope3 peer-ip 30.1.1.1 interface vlanif 10
[CE2-bfd-session-ce2tope3] discriminator local 23
[CE2-bfd-session-ce2tope3] discriminator remote 32
[CE2-bfd-session-ce2tope3] quit
After the configuration, run the display bfd session all command on PEs and CEs, and you can
view that the status of the BFD sessions is Up. Take the display on PE1 as an example.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
11 10 10.1.1.1 Up S_IP_IF Vlanif10
13 31 20.1.1.2 Up S_IP_IF Vlanif20
--------------------------------------------------------------------------------
Step 4 Associate the status between BFD sessions.

Associate the status between BFD sessions on PE1 and PE3.
# Configure PE1.
[PE1] oam-mgr
[PE1-oam-mgr] oam-bind bfd-session 11 bfd-session 13
[PE1-oam-mgr] quit
# Configure PE3.
[PE1] oam-mgr
[PE1-oam-mgr] oam-bind bfd-session 31 bfd-session 32
[PE1-oam-mgr] quit

# Run the shutdown command on GE 1/0/2 of PE1 to simulate the fault on the link.
Run the display bfd session peer-ip command on PE1 or PE3 to check the status of the BFD
session created with the peer. Take the display on PE1 as an example:
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
13 31 20.1.1.2 Down S_IP_IF Vlanif20
--------------------------------------------------------------------------------
Run the display bfd session all verbose command on CE1 or CE3, and you can view that the
status of the BFD session is Down. Take the display on CE1 as an example:
[CE1]display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 4096 (One Hop) State : Down Name : ce1tope1
--------------------------------------------------------------------------------
Local Detect Multi : 3 Detect Interval (ms) : -
PDT Index : FSM-0 | RCV-0 | IF-0 | TOKEN-0 | OAMF-1
--------------------------------------------------------------------------------
Run the display ip routing table command on CE1 to check the route from CE1 to CE2. The
next hop of 110.1.1.0/24 is 40.1.1.2. That is, the traffic is forwarded through the standby path.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Vlanif10

20.1.1.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
30.1.1.0/24 OSPF 10 3 D 110.1.1.2 Vlanif10
40.1.1.0/24 Direct 0 0 D 40.1.1.2 Vlanif40
50.1.1.0/24 OSPF 10 2 D 40.1.1.2 Vlanif40
60.1.1.0/24 OSPF 10 3 D 40.1.1.2 Vlanif40
110.1.1.0/24 OSPF 10 13 D 40.1.1.2 Vlanif40
----End

Configuration Files
#
sysname CE1
#
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.252
#
interface Vlanif40
ip address 40.1.1.1 255.255.255.252
ospf cost 10
#
interface Vlanif100
ip address 100.1.1.1 255.255.255.252
#
#
#
#
bfd ce1tope1 bind peer-ip 10.1.1.2 interface Vlanif10
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
network 100.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
#
bfd
#
interface Vlanif30
ip address 30.1.1.2 255.255.255.252
#
interface Vlanif60
ip address 60.1.1.1 255.255.255.252
ospf cost 10
#
interface Vlanif110
ip address 110.1.1.1 255.255.255.252
#
#

#
#
bfd ce2tope3 bind peer-ip 30.1.1.1 interface Vlanif30
#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255
network 60.1.1.0 0.0.0.255
network 110.1.1.0 0.0.0.255
#
return
#
sysname PE1
#
vlan batch 10 20
#
bfd
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.252
#
interface Vlanif20
ip address 20.1.1.1 255.255.255.252
#
#
#
bfd pe1toce1 bind peer-ip 10.1.1.1 interface Vlanif10
#
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
oam-mgr
#
return
#
sysname PE3
#
vlan batch 20 30
#
bfd
#
interface Vlanif20
ip address 20.1.1.2 255.255.255.252
#
interface Vlanif30

ip address 30.1.1.1 255.255.255.252

#
#
#
#
bfd pe3toce2 bind peer-ip 30.1.1.2 interface Vlanif30
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
oam-mgr
#
return
#
sysname PE2
#
vlan batch 40 50
#
bfd
#
interface Vlanif40
ip address 40.1.1.2 255.255.255.252
#
interface Vlanif50
ip address 50.1.1.1 255.255.255.252
#
#
#
ospf 1
area 0.0.0.0
network 40.1.1.0 0.0.0.255
network 50.1.1.0 0.0.0.255
#
return
#
sysname PE4
#
vlan batch 50 60
#
bfd
#
interface Vlanif50
ip address 50.1.1.2 255.255.255.252
#
interface Vlanif60

ip address 60.1.1.2 255.255.255.252

#
#
#
ospf 1
area 0.0.0.0
network 50.1.1.0 0.0.0.255
network 60.1.1.0 0.0.0.255
#
return

Configuration Guide - Reliability 8 VRRP and VRRP6 Configuration
8 VRRP and VRRP6 Configuration
About This Chapter
A VRRPor VRRP6 backup group allows a backup to take over network traffic from a master
if the master fails.
8.1 VRRP Overview

The Virtual Router Redundancy Protocol (VRRP) groups multiple routers into one virtual router,
and sets the default gateway address as the IP address of the virtual router.
8.2 VRRP Features Supported by the S9700
VRRP features include the VRRP backup group in master/backup mode, VRRP backup group
in load balancing mode, tracking of the interface status, fast VRRP switchover, ping of the virtual
IP address, VRRP security authentication, smooth VRRP switching, and Management Virtual
Router Redundancy Protocol (mVRRP).
8.3 Configuring the VRRP Backup Group
By configuring the VRRP backup group in master/backup mode or load balancing mode, you
can implement the communication between hosts inside a LAN and external networks.
8.4 Configuring VRRP to Track the Status of an Interface
By configuring a VRRP backup group to track the interface status, you can implement the backup
function when the interface fails.
8.5 Configuring a Fast VRRP Switchover
By tracking the BFD session status or the EFM OAM session status, NQA test instance status,
and route status, a VRRP backup group implements VRRP switchovers rapidly.
8.6 Configuring VRRP Security
On a network at security risks, you can protect devices against attacks by configuring an
authentication mode for VRRP packets.
8.7 Configuring VRRP Smooth Switching
By configuring smooth VRRP switching, you can address the problem of traffic loss due to the
AMB/SMB switchover.
8.8 Adjusting and Optimizing VRRP
By adjusting parameters of a VRRP backup group, you can optimize the functions of a VRRP
backup group.

8.9 Configuring mVRRP Backup Groups

An mVRRP backup group can be bound to other member backup groups and determine the
status of member backup groups according to the bindings. This is applicable to the scenario
where a device is dual-homed to master and slave devices on a MAN.
8.10 Configuring VRRP Version Upgrade
After being upgraded from version 2 to version 3, VRRP can support both IPv6 and IPv4
networks.
8.11 Maintaining VRRP
This section describes how to maintain VRRP. Detailed operations include deleting VRRP
statistics, and monitoring VRRP operating status.
This section provides several configuration examples of VRRP.

8.1 VRRP Overview

The Virtual Router Redundancy Protocol (VRRP) groups multiple routers into one virtual router,
and sets the default gateway address as the IP address of the virtual router.
All hosts on a network are configured with the same default route to an egress gateway. These
hosts send all packets whose destination addresses are not on the local network segment to the
default egress gateway, such as Switch A in Figure 8-1. The default egress gateway allows the
hosts and external networks to communicate. If the egress gateway is Down, all hosts using this
gateway fail to communicate with external networks.
Figure 8-1 LAN default gateway
Gateway:10.0.0.1
IP Address:10.0.0.2/24
10.0.0.1/24
Gateway:10.0.0.1
IP Address:10.0.0.3/24 Network
Gateway:10.0.0.1 SwitchA
IP Address:10.0.0.4/24
Ethernet
A common method to improve the system reliability is to deploy multiple egress gateways. In
addition, a mechanism for selecting one of routes to these gateways is required.
VRRP is a fault-tolerant protocol defined in RFC 3768. VRRP allows the hosts to select one of
routes to multiple egress gateways by separating logical devices from physical devices.
On a LAN (for example, an Ethernet) with multicast and broadcast capabilities, VRRP uses
logical gateways to provide high availability for transmission links, preventing a gateway failure
from interrupting services, without changing the configuration of routing protocols.
8.2 VRRP Features Supported by the S9700

VRRP features include the VRRP backup group in master/backup mode, VRRP backup group
in load balancing mode, tracking of the interface status, fast VRRP switchover, ping of the virtual
IP address, VRRP security authentication, smooth VRRP switching, and Management Virtual
Router Redundancy Protocol (mVRRP).
Master/Backup Mode
In VRRP, it is the basic mode for the backup of IP addresses. In the master/backup mode, a
VRRP backup group consists of a master switch and multiple backup switches. Different
switches have different priorities in this backup group. The switch with the highest priority serves
as the master switch.

l The master switch undertakes all the services in normal condition.

l The backup switches undertake the services only when the master switch fails.
Load Balancing Mode

In the load balancing mode, two or more backup groups are created. Multiple backup groups
undertake services at the same time.
In the load balancing mode, the VRRP backup groups have the following features:
l In the S9700, a switch can join several VRRP backup groups and has different priorities in
different backup groups. Multiple virtual switches carry out load balancing.
l Each backup group consists of a master switch and several backup switches.
l The master switch of each backup group can be different.
Tracking the Interface Status

In the S9700, the interfaces can be tracked. When the interface status changes, the priority of
the switch is automatically adjusted. The priorities of switches in the backup group change and
a new master switch is elected.
VRRP Fast Switchover

The S9700 supports bidirectional forwarding detection (BFD), which detects connectivity of
links and routes on the network. VRRP monitors the status of BFD sessions to perform fast
switchover between the master and backup switches. You can configure up to eight BFD
sessions. The switchover can be complete within 1 second. Working with the BFD sessions,
VRRP shortens the duration of the switchover.
Enable/Disable the Ping Function to the Virtual IP Address

To ping through virtual IP addresses that are used in the VRRP backup group, you can monitor
the operating status of the virtual switches but the VRRP backup group may suffer the ICMP
attack. In the S9700, you can run a command to enable the function to ping the virtual IP address.
VRRP Security Functions

For different security levels of networks, you can set different authentication modes and
authentication keys in the header of VRRP packets.
In a secure network, you can adopt the default configuration. That is, the switch does not
authenticate the VRRP packets to be sent and received. The switch considers all the received
packets as real and valid VRRP packets. In this case, no authentication key is required.
VRRP provides simple text authentication and MD5 authentication for networks that are
vulnerable to attacks. In simple text authentication mode, a string of 1 to 8 characters can be
configured as the authentication key. In MD5 authentication mode, a string of 1 to 8 characters
in plain text or a string of 24 characters in encrypted text can be configured as the authentication
key.
VRRP Smooth Switching

On the network configured with a VRRP backup group, during the AMB/SMB switchover of
the master device, the backup device directly becomes the master one because the master device

and the backup device cannot communicate in time. After the AMB/SMB switchover of the
original master device, if its priority is higher than the current master device, it automatically
becomes the master device. During the AMB/SMB switchover, the system is busy processing
packets. Thus, the gratuitous ARP packets sent by the master device are blocked or processed
abnormally, and the system must refresh the MAC entries of the downstream switch through
subsequent packets. As a result, user packets are dropped in this period of time.
VRRP smooth switching can solve such a problem. After the AMB/SMB switchover takes place
on the master device and the new AMB is started, if the priority of the current backup device is
higher than that of the current master device, the backup device becomes the master device
automatically. At this time, VRRP saves the currently configured interval and adjusts the interval
for sending a VRRP Advertisement packet to the configured interval. After receiving a VRRP
Advertisement packet, the backup device learns the new interval carried in the packet. This
ensures the stability of the VRRP backup group during or after the AMB/SMB switchover of
the master device and prevents packet loss.
After VRRP smooth switching is enabled, the learning function takes precedence over the
preemption function. That is, if the interval carried in the received packet is inconsistent with
the current interval and the priority carried in the received packet is lower than the current
priority, VRRP performs the learning and timer resetting functions first, and then the preemption
function.
VRRP smooth switching also depends on the system. If the system is quite busy since the AMB/
SMB switchover and cannot schedule the operation on the VRRP module, VRRP smooth
switching cannot take effect.
mVRRP
Many VRRP backup groups run between switchs for different services. If each VRRP backup
group needs to maintain its own state machine, a large number of VRRP packets are generated
between switchs. To simplify the process and reduce the bandwidth occupied by protocol
packets, you can configure a VRRP backup group to be an mVRRP backup group and bind it
to other backup group members. Then, the status of the backup group member is determined by
the status of the bound mVRRP backup group.
VRRP6
VRRP for IPv6, also called VRRP6, is a fault-tolerant protocol functioning as an extension to
the VRRP protocol. VRRP6 groups multiple switchs into one virtual router. When the next hop
of a host fails, VRRP6 can switch services to another switch through a certain mechanism. This
thus ensures coherence and reliability of communications.
The following table shows the comparison between VRRP6 and VRRP for IPv4 based on
functions.
Function VRRP6 VRRP for IPv4
Master/backup mode Supported Supported
Load balancing mode Supported Supported
Interface status tracking Supported Supported
Fast VRRP switchover Supported Supported

Function VRRP6 VRRP for IPv4
Pinging a virtual IP address Supported Supported
Security authentication of VRRP Not supported Supported

backup groups
Smooth VRRP switching Not supported Supported
mVRRP Supported Supported
8.3 Configuring the VRRP Backup Group

By configuring the VRRP backup group in master/backup mode or load balancing mode, you
can implement the communication between hosts inside a LAN and external networks.

Before configuring a VRRP backup group, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the required data. This can help you complete
the configuration task quickly and accurately.
The VRRP backup group works in master/backup mode or load balancing mode.
l The master/backup switchover is a basic function provided by VRRP. The master/backup

mode is as follows:
Only one backup group exist.
The switch with the highest priority in the backup group serves as the master switch
and undertakes the services.
Except for the master switch, other switchs in the backup group serve as the backup
switchs and work in the Backup state.
If the master switch fails, backup switchs select a new master switch based on their
priorities to provide routing service.
l In the load balancing mode, multiple backup groups are created to share the traffic of a
network. One switch can join different backup groups. The load balancing mode is as
follows:
Switch A serves as the master device in backup group 1 and the backup device in backup
group 2.
Switch B serves as the master device in backup group 2 and the backup device in backup
group 1.
Some hosts on the network use backup group 1 as their gateway and others use backup
group 2 as their gateway.
In this case, they can back up each other and share the traffic.
NOTE
The VLANIF interface support VRRP.

Before configuring the VRRP backup group, complete the following tasks:
l Configuring network layer attributes for the interface to connect the network
Data Preparation
To configure the VRRP backup group, you need the following data.
No. Data
1 Backup group ID
2 Virtual IP address of the backup group
3 Priorities of switchs in the VRRP backup group
8.3.2 Creating a Backup Group and Configuring a Virtual IP

Address
By creating a VRRP backup group, you can use the default gateway address on a LAN to be the
IP address of the VRRP backup group.
Context
Do as follows on each switch of a backup group:
Perform the following step as required to configure VRRP for IPv4 or VRRP for IPv6.
CAUTION
When both VRRP and DHCP relay are configured on the network, neither the DHCP snooping
function nor the arp learning dhcp-trigger command can be configured on the VRRP master
and backup devices.
Procedure
l For VRRP for IPv4(VRRP), run the following commands:
1. Run:
system-view

2. Run:

3. Run:
vrrp vrid virtual-router-id virtual-ip virtual-address

A backup group is created and its virtual IP address is specified.
NOTE
l On the S9700, VRRP functions can be configured only on VLANIF interfaces.

l The virtual IP address must be in the same network segment as the IP address of the
VLANIF interface.
l When configuring both a VRRP group and a VRRP6 group, set different virtual router IDs
for the two groups.
l Virtual IP addresses of backup groups must be different.
l Both ends of the same backup group must be configured with the same virtual router IDs.
When you assign the first virtual IP address to a VRRP backup group, the system
creates this backup group. Then, when you assign another virtual IP address to the
backup group, the system adds this address into the virtual IP address list of this backup
group.
For users who require equivalent VRRP reliability, a backup group can be configured
with multiple virtual IP addresses. Different addresses serve different user groups.
This is easy to manage and can prevent users' default gateway addresses from varying
with the VRRP configuration. A maximum number of 16 virtual IP addresses can be
configured for a backup group.
For a VRRP backup working in load balancing mode, you need to repeat the procedure
to configure multiple backup groups on an interface. At least two backup groups are
required on an interface. Backup groups are identified by VRIDs and their virtual IP
addresses cannot be identical.
NOTE
You can configure up to 255 VRRP groups on each interface of the S9700. To configure 255
VRRP groups on an interface, you need to set the CPCAR of VRRP packets to 256 kbps.
CAUTION
l When configuring VRRP and static ARP simultaneously on the S9700, do not use
the IP addresses in the static ARP entries as the virtual IP addresses of VRRP
groups. Otherwise, incorrect host routes are generated, which affects forwarding
between devices.
l The virtual MAC address of a VRRP backup group cannot be configured as a static
MAC address or blackhole MAC address.
l Do not create VRRP groups on the VLANIF interfaces corresponding to super
VLANs because the configuration degrades the system performance.
l For VRRP for IPv6(VRRP6), run the following commands:

1. Run:
system-view

2. Run:

3. Run:
vrrp6 vrid virtual-router-id virtual-ip virtual-ipv6-address [ link-
local ]
A VRRP6 backup group is configured and a virtual IPv6 address is assigned to the
VRRP6 backup group.
NOTE
l Virtual IPv6 addresses of VRRP6 backup groups must be different.

l Virtual router IDs on both ends of a VRRP6 backup group must be the same.
l Virtual router IDs on different interfaces can be the same.
l When configuring both a VRRP group and a VRRP6 group, set different virtual router IDs
for the two groups.
link-local indicates the virtual IPv6 address assigned to a VRRP6 backup group is a
link local address. The link local address is an IPv6 address with the prefix being FE80.
The link local address takes effect only on a local link because it is used by neighboring
nodes along the link to communicate with each other. An IPv6 switch never forwards
packets carrying link local addresses. To assign a virtual IPv6 address to a VRRP6
backup group, ensure that the first virtual IPv6 address is a link local address.
After the first virtual IPv6 address is assigned to a VRRP6 backup group, the system
creates the VRRP6 backup group. When another virtual IPv6 address is assigned to
the VRRP6 backup group, the system adds the virtual IPv6 address to the virtual IPv6
address list of the VRRP6 backup group.
In load balancing mode, you need to repeat this step to configure multiple VRRP6
backup groups. At least two VRRP6 backup groups need to be created and each
VRRP6 backup group is identified by a distinct VRID. In addition, virtual IPv6
addresses of VRRP6 backup groups must be different.
----End
8.3.3 Configuring Priorities for Interfaces Where a Backup Group

Is Created
Configuring priorities for interfaces on which a VRRP backup group is created allows the VRRP
status on an interface to become Master. The master device forwards network traffic.
Context
In master/backup mode, only one backup group is created. switchs have different priorities in
this backup group. The switch with the highest priority serves as the master and other switchs
are backups.
In load balancing mode, two backup groups or more are created. Every switch has different
priorities in different backup groups. Every switch plays a role based on its priority in a specific
backup group. Different priorities are set for every switch to allow that the masters of VRRP
backup groups are distributed on different switchs.
Do as follows on the interface of each switch in each backup group:
Perform the following step as required to configure VRRP for IPv4 (VRRPv4) or VRRP for
IPv6 (VRRPv6).

Procedure
l For VRRP for IPv4, run the following commands:
1. Run:
system-view

2. Run:
The VLANIF interface view is displayed.

3. Run:
vrrp vrid virtual-router-id priority priority-value
The priority of the switch in a VRRP backup group is configured.
By default, the priority is 100. Priority 0 is reserved for special purpose. Priority 255
is reserved for the IP address owner and this priority cannot be configured. A priority
ranges from 1 to 254.
1. Run:
system-view

2. Run:
The VLANIF interface view is displayed.

3. Run:
vrrp6 vrid virtual-router-id priority priority-value
The priority of the switch in a VRRPv6 backup group is configured.
By default, the priority is 100. Priority 0 is reserved for special use, and priority 255
is reserved for the IP address owner whose priority cannot be configured. The value
of a priority ranges from 1 to 254.
----End
8.3.4 (Optional) Configuring the Mode of Sending VRRP Packets

in Super-VLAN
You can configure the mode for sending VRRP advertisement packets for a super VLAN on
VLANIF interfaces as required.
Context
Perform the following steps on a VRRP switch that is configured with a super-VLAN:
Procedure
Step 1 Run:
system-view


Step 2 Run:
interface vlanif vlan-id
The VLAN interface view is displayed.

Step 3 Run:
vrrp advertise send-mode { sub-vlan-id | all }
The mode for sending VRRP advertising messages is configured.

By default, a super VLAN sends VRRP Advertisement packets only to the sub-VLAN with the
smallest VLAN ID among all the sub-VLANs in Up state.
----End

By viewing the status of a VRRP backup group, you can check whether the configurations are
successful.
Prerequisites
The configurations of the VRRP backup group function are complete.
Procedure
l Run the display vrrp [ interface interface-type interface-number [ virtual-router-id ] ]
[ brief ] command to check the status of VRRP backup group.
l Run the display vrrp6 [ interface interface-type interface-number [ vrid virtual-router-
id ] ] [ brief ] command to check the status and the configurations of the VRRP6 backup
group.
----End
Example
In the master/backup mode, after the configuration, you can run the display vrrp command to
view the status of a VRRP backup group.
<Quidway> display vrrp
Vlanif100 | Virtual Router 1
State : Master
Virtual IP : 10.1.1.111
PriorityRun : 120
PriorityConfig : 120
MasterPriority : 120
Preempt : YES Delay Time : 20s
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Config type : normal-vrrp
Config track link-bfd down-number : 0
In the load balancing mode, after the configuration, you can run the display vrrp command to
view the status of a switch in different backup groups.


State : Master
Virtual IP : 10.1.1.111
PriorityRun : 120
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
State : Backup
Virtual IP : 10.1.1.112
PriorityRun : 100
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0102
Check TTL : YES
After the configuration, run the display vrrp6 command on the switch, and you can view
information about the VRRP6 backup group.
<Quidway> display vrrp6
State : Master
Virtual IP : FE80::1:2
PriorityRun : 200
TimerRun : 100s
TimerConfig : 100s
Virtual Mac : 0000-5e00-0201
Uncheck hop limit : YES
Accept Mode : ON
Track If : GigabitEthernet3/0/4 priority reduced : 70
IF State : UP
8.4 Configuring VRRP to Track the Status of an Interface

By configuring a VRRP backup group to track the interface status, you can implement the backup
function when the interface fails.

Before configuring a VRRP backup group to track interface status, familiarize yourself with the
applicable environment and complete the pre-configuration task of configuring a VRRP backup
group.

VRRP tracking interface status provides the backup function when the interface where the VRRP
backup group resides is faulty or when another interface on the switch is faulty.
Interface status tracking works as follows:
1. When a tracked interface goes Down, the priority of the switch that houses the interface is
automatically reduced by a specific amount so that it is lower than prioties of other
switchs in the group.
2. A master/backup switchover within the VRRP backup group is completed. The switch with
the highest priority becomes the master switch.
Before configuring VRRP to track the status of an interface, complete the following tasks:
l Configuring network layer attributes for interfaces to connect the network
l Configuring a VRRP backup group
Data Preparation
To configure VRRP to track the status of an interface, you need the following data.
No. Data
1 Backup group ID
2 Interfaces to be tracked and the values by which the priority increases or decreases
8.4.2 Configuring VRRP to Track the Status of an Interface

By configuring a VRRP backup group to track interface status, you can implement the fast VRRP
master/backup switchover.
Context
The backup is performed when other interfaces on a switch are unavailable. This feature is
required in NAT applications.
Do as follows on the switch that has an interface to be tracked:
Procedure
1. Run:
system-view

2. Run:


3. Run:
vrrp vrid virtual-router-id track interface interface-type interface-
number [ increased value-increased | reduced value-reduced ]
A interface to be tracked is specified.

By default, when a tracked interface goes Down, the priorities of switches in the
tracking backup group decrease by 10.
increased value-increased: specifies the value by which a priority increases when
the tracked interface goes Down. The value ranges from 1 to 255. The maximum
value of the priority is 254 because 255 is reserved for only the IP address owner.
reduced value-reduced: specifies the value by which the priority decreases when
a tracked interface goes Down. The value ranges from 1 to 255. The lowest priority
that can be assigned is 1. When the priority is decreased to 1, a VRRP
Advertisement packet with priority 0 is sent.. The priority 0 is reserved for system
use. When a backup device receives a VRRP Advertisement packet with the
priority 0, it immediately switches to be the master device.
When a VRRP backup group tracks BFD sessions and interfaces concurrently, the
allowable maximum number of tracked BFD sessions and interfaces is eight.
When a BFD session or an interface tracked by the VRRP backup group goes
Down, the priority of the VRRP backup group may increase or reduce. If it is
configured that the priority always increases every time a BFD session or
interface goes Down, the priority of the VRRP backup group in the Backup
state can exceed that in the Master state when all the tracked BFD sessions or
interfaces go Down.
If it is configured that the priority does not always increase every time a BFD
session or interface goes Down, as long as one or some BFD sessions or
interfaces go Down, the priority of the VRRP backup group in the Backup state
can exceed that in the Master state, thus triggering VRRP fast switchover. Thus,
the increase of the priority caused by the down of other BFD sessions or
interfaces has no impact on VRRP fast switchover.
NOTE
You can configure up to eight tracked interfaces on a VRRP group. If an S9700 is the IP address
owner, interfaces of the S9700 cannot be tracked.
1. Run:
system-view

2. Run:

3. Run:
vrrp6 vrid virtual-router-id track interface interface-type interface-
number [ increased value-increased | reduced value-reduced ]
The status of the specified interface is tracked.

By default, when the tracked interface goes Down, the priority of the tracking
VRRP backup group decreases by 10.

increased value-increased specifies the value by which a priority increases when

a tracked interface goes Down. The value ranges from 1 to 255. The maximum
value that can be assigned is 254 and 255 is reserved for only the IP address owner.
reduced value-reduced specifies the value by which a priority decreases when a
tracked interface goes Down. The value ranges from 1 to 255. The lowest priority
is 1. When the priority is decreased to 1, a VRRP Advertisement packet with
priority 0 is sent.. The priority 0 is reserved in the system for special use. When
the backup device receives a VRRP Advertisement packet with the priority 0, it
immediately switches to be the master device.
A VRRP6 backup group is configured to monitor the interface status. When the
monitored interface is configured with an IPv4 address and the status of IPv4
changes, the VRRP6 backup group re-elects the Master; if the monitored interface
is configured with an IPv6 address, when the status of IPv6 changes, the VRRP6
backup group does not re-elect the Master.
----End

By viewing the status of an interface tracked by a VRRP backup group, you can check whether
the configurations are successful.
Prerequisites
The configurations of enabling VRRP to track the status of an interface are complete.
Procedure
[ brief ] command to check the VRRP status.
id ] ] [ brief ] command to check the status and the configurations of a VRRP6 backup
group.
----End
Example
Run the display vrrp command or the display vrrp6 command to view the Track IF field and
the IF State field. The Track IF field indicates the type and number of the tracked interface,
and the IF State field indicates the interface status, which is either Up or Down.
State : Master
Virtual IP : 10.1.1.111
PriorityRun : 130
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES

Track IF : GigabitEthernet2/0/1 priority reduced : 10

IF State : UP
State : Master
PriorityRun : 200
TimerRun : 100s
TimerConfig : 100s
Virtual Mac : 0000-5e00-0201
Accept Mode : ON
IF State : UP
8.5 Configuring a Fast VRRP Switchover

By tracking the BFD session status or the EFM OAM session status, NQA test instance status,
and route status, a VRRP backup group implements VRRP switchovers rapidly.

Before configuring a fast VRRP switchover (in common mode), familiarize yourself with the
applicable environment and complete the tasks of pre-configuring a VRRP backup group and a
BFD session or EFM OAM.
VRRP tracks BFD sessions or EFM OAM. The VRRP module is notified of any change in BFD
or EFM sessions and this triggers a fast VRRP switchover.
If a VRRP backup group tracks several BFD sessions, a change in the status of a BFD session
does not affect the status of other BFD sessions.
If one of normal BFD sessions tracked by a VRRP backup group changes in status, the master/
backup switchover is triggered by changing priorities of routers in the VRRP backup group.
After the tracked normal BFD session recovers, the priorities of routers in the VRRP backup
group are restored to their original values.
Before configuring a fast VRRP switchover, complete the following tasks:

l Configuring a VRRP backup group
Data Preparation
To configure a fast VRRP switchover, you need the following data.

No. Data
1 Backup group ID
8.5.2 Tracking the BFD Session Status

By tracking the status of a BFD session, a VRRP backup group can perform a fast VRRP
switchover if the BFD session status changes.
Context
Perform the following steps on the switch that needs to perform a fast VRRP switchover:
NOTE
l Before configuring a fast VRRP switchover, if VRRP tracks a peer BFD session, you must configure
a peer BFD session on both the master router and the backup router in a VRRP backup group. Otherwise,
VRRP flapping occurs.
l When configuring a VRRP backup group to track the status of a BFD session, note the following points:
l If the parameter session-name bfd-configure-name is specified, the VRRP backup group can track
the status of only static BFD sessions with automatically negotiated discriminators.
l If the parameter session-id is specified, the VRRP backup group can track the status of only static
BFD sessions.
Perform the following steps as required on a device enabled with VRRP for IPv4 or for VRRP
for IPv6.
Procedure
l For VRRP for IPv4:
1. Run:
system-view

2. Run:
interface interface-type interface-number[.subinterface-number ]
The view of the interface configured with a VRRP backup group is displayed.
3. Run:
vrrp vrid virtual-router-id track bfd-session { bfd-session-id | session-
name bfd-name } [ increased value-increased | reduced value-reduced ]
The normal BFD session is tracked.

increased value-increased: specifies the value by which the priority increases when
the tracked BFD session goes Down. The value ranges from 1 to 255. The maximum
value of the priority is 254.
reduced value-reduced: specifies the value by which the priority decreases when the
tracked BFD session goes Down. The value ranges from 1 to 255. The lowest priority
is 1. By default, when the tracked BFD sessions go Down, the value of the priority
decreases by 10.
When configuring the value by which the priority increases or decreases, especially
the default value, ensure that the priority of a backup switch in a backup group is

higher than that of a master switch whose priority is changed. In this manner, the
VRRP status can be switched fast.
When a VRRP backup group monitors both BFD sessions and interfaces, the
maximum number of BFD sessions and interfaces is 8. If increased value-
increased is specified, the value of the increased VRRP backup group priority can
exceed the priority of the master VRRP backup group when all the tracked BFD
sessions or interfaces go Down. Otherwise, if the VRRP backup group takes
precedence of the peer because its priority is increased when one or part of tracked
BFD sessions or interfaces go Down, the additional increasing of the priority is of no
significance when other BFD sessions or interfaces go Down.
NOTE
When configuring a VRRP backup group to track the status of a BFD session, note the following
points:
l If the parameter session-name bfd-configure-name is specified, the VRRP backup group
can track the status of only dynamic BFD sessions.
l If the parameter session-id is specified, the VRRP backup group can track the status of only
static BFD sessions.
1. Run:
system-view

2. Run:
The view of the interface configured with the VRRP backup group is displayed.
3. Run:
vrrp6 vrid virtual-router-id track bfd-session { session-id | session-
name bfd-configure-name } [ increased value-increased | reduced value-
reduced ]
The normal BFD session is tracked.

increased value-increased: specifies the value by which the priority increases when
the tracked BFD session goes Down. It is an integer ranging from 1 to 255. The
maximum value of the priority is 254 because 255 is reserved for only the IP address
owner.
reduced value-reduced: specifies the value by which the priority decreases when the
tracked BFD session goes Down. The value is an integer ranging from 1 to 254. The
minimum value of the priority is 0. The priority 0 is reserved in the system for special
use. When the backup device receives a VRRP Advertisement packet with the priority
0, it immediately switches to be the master device. By default, the value of the priority
decreases by 10.

NOTE
When configuring the value by which the priority increases or decreases, note that if the priority
of the Backup switch in a backup group is higher than that of the Master switch whose priority
is changed, the fast switchover is performed.
When configuring a VRRP6 backup group to track the status of a BFD session, note the
following points:
l If the parameter session-name bfd-configure-name is specified, the VRRP backup group
can track the status of only dynamic BFD sessions.
l If the parameter session-id is specified, the VRRP backup group can track the status of only
static BFD sessions.
----End
8.5.3 Associating a VRRP Backup Group with an NQA Test Instance

After being associated with a Network Quality Analysis (NQA) test instance, a VRRP backup
group can track the status of the NQA test instance. If the NQA test instance detects that the
monitored IP address becomes unreachable, it notifies the VRRP backup group of a status
change, triggering a rapid master/backup VRRP switchover.
Context
A VRRP-enabled S9700 can track a local forwarding interface connected to a network, but not
an interface along a network-side link connected to the local forwarding interface. If the interface
along the network-side link goes Down, the VRRP backup group cannot detect the fault but
continues to send packets along the link, causing user traffic loss.
To monitor the connectivity of the interface on the network-side link, an NQA ICMP test instance
can be configured on the NQA-supported S9700 and send test packets to the IP address.
The VRRP backup group can be associated with the NQA ICMP test instance. The NQA ICMP
test instance reports the link status to the VRRP backup group. This mechanism enables the
VRRP backup group to monitor the link connecting the master S9700 to the external network.
If the link fails, hosts on a LAN cannot access an external network through the master switch.
NQA detects this fault and notifies VRRP of the fault. The VRRP backup group lowers the
master switch's priority by a configured value. The backup switch with the highest priority will
become the new master switch and take over traffic. The process ensures that the communication
between the hosts and the external network is not interrupted. After the link recovers, NQA
detects the status change and instructs the VRRP backup group to restore the priority of the
previous master switch.
Figure 8-2 shows a network where a VRRP backup group tracks an NQA test instance. NQA
helps the VRRP backup group monitor the link between the master switch and a network.

Figure 8-2 Networking diagram for association between VRRP and an NQA test instance
Master SwitchC
SwitchA
20.1.1.1/24
Switch
NQA agent
Internet
SwitchB SwitchD
Backup
HostA
VRRP
Virtual IP Address:10.1.1.10
A VRRP backup group can track a maximum of eight NQA test instances.
CAUTION
l Before associating a VRRP backup group with an NQA test instance, ensure that the NQA
test instance is successfully created. For information about how to create an NQA test
instance, see "NQA Configuration" in the S9700 Core Routing Switch Configuration Guide
- Network Management.
l Only NQA ICMP test instances can be associated with a VRRP backup group.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the interface where the VRRP backup group is configured is displayed.
Step 3 Run:
vrrp vrid virtual-router-id track nqa admin-name test-name [ reduced value-
reduced ]
The VRRP backup group is configured to track the NQA test instance.
reduced value-reduced specifies the value by which the VRRP priority value reduces if the
tracked NQA test instance reports a detection failure. The value ranges from 1 to 255. The
smallest priority value is 0. The priority value 0 is reserved. If a VRRP Advertisement packet

carrying the priority value of 0 is received, the backup device immediately preempts the Master
state.
----End
8.5.4 Associating VRRP with a Route to Implement a Rapid Master/

Backup VRRP Switchover
A VRRP backup group can track an uplink route connected to a network. If the tracked route is
withdrawn or becomes inactive, the VRRP backup group is notified of the change and rapidly
performs a master/backup VRRP switchover.
Context
To improve device reliability, two user gateways working in master/backup mode are connected
to a network, and VRRP is enabled on these gateways to determine their master and backup
states. Although a VRRP backup group has been configured, if an uplink route to a network
becomes unreachable, access-side users still use the VRRP backup group to forwards user data
along the uplink route, causing user data loss.
Association between the VRRP backup group and route can prevent user data loss. The VRRP
backup group can be configured to track the uplink route to the network. If the route is withdrawn
or becomes inactive, the route management (RM) module notifies the VRRP backup group of
the change. After receiving the notification, the VRRP backup group changes its master device's
VRRP priority, and performs a master/backup switchover.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface interface-type interface-number [ .subinterface-number ]
The view of the interface where the VRRP backup group is configured is displayed.
Step 3 Run:
vrrp vrid virtual-router-id track ip route ip-address { mask-address | mask-
length } [ vpn-instance vpn-instance-name ] [ reduced value-reduced ]
The VRRP backup group is configured to track the route.
By default, if the tracked route is withdrawn or becomes inactive, the master device in the VRRP
backup group reduces its VRRP priority value by 10.
reduced value-reduced specifies the value by which the VRRP priority decreases if the tracked
route is withdrawn or becomes inactive. The value ranges from 1 to 255. The priority value 0 is
reserved. If a VRRP Advertisement packet carrying the priority value of 0 is received, the backup
device immediately preempts the Master state.
----End


Prerequisites
The configurations of VRRP fast switchover are complete.
Procedure
Step 1 Run the display vrrp [ interface interface-type interface-number [ virtual-router-id ] ]
command to view information about a specified VRRP group.
----End
Example
Run the display vrrp command, and you can find that the tracked BFD session is in Up state.
For example:
State : Master
Virtual IP : 11.1.1.10
PriorityRun : 90
PriorityConfig : 90
MasterPriority : 90
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-010a
Check TTL : YES
Track BFD : 1 Priority reduced : 10
BFD-session state : UP
8.6 Configuring VRRP Security

On a network at security risks, you can protect devices against attacks by configuring an
authentication mode for VRRP packets.

Before configuring VRRP security authentication, familiarize yourself with the applicable
environment and complete pre-configuration task of configuring a VRRP backup group.
A switch on a secure security considers all received and sent VRRP packets real and valid by
default. The router does not authenticate packets and there is no need to configure an
authentication key.
VRRP provides simple text authentication and MD5 authentication for routers on networks that
are vulnerable to attacks. In simple text authentication mode, a string of 1 to 8 characters can be
configured as an authentication key. In MD5 authentication mode, a string of 1 to 8 characters
in plain text or a string of 24 characters in encrypted text can be configured as the authentication
key.

The process of simple text authentication is as follows:

l Device that sends packets adds the authentication key into VRRP packets.
l Device that receives packets compares the received authentication key with the local
authentication key. If they are the same, VRRP packets are valid. Otherwise, the switch
discards the received VRRP packets and sends a Trap packet to the Network Management
System (NMS).
The process of MD5 authentication is as follows:
l The switch adds the authentication key to the VRRP packet.
l The receiver generates a summary based on the locally configured authentication key and
compares the summary of the received VRRP packet with the locally generated summary.
If they are the same, the receiver considers the received VRRP packet valid. If they are
different, the receiver considers the received VRRP packet illegal and discards it, and then
reports a trap message to the network management system.
Before configuring the VRRP security function, complete the following tasks:
l Configuring the VRRP backup group
Data Preparation
To configure the VRRP security function, you need the following data.
No. Data
1 Backup group ID
2 Virtual IP address of the backup group
3 Authentication key of the VRRP packet
8.6.2 Configuring the Authentication Mode of VRRP Packets

VRRP packets can be authenticated in simple text mode or MD5 mode.
Context
Perform the following steps on the switch that needs to be configured with an authentication
mode for VRRP packets:
Procedure
Step 1 Run:
system-view

Step 2 Run:


Step 3 Run:
A backup group is created and its virtual IP address is specified.

Step 4 (optional) Run:
The priority of the switch in the backup group is configured.

Step 5 Run:
vrrp vrid virtual-router-id authentication-mode { simple key | md5 md5-key }
The authentication mode for VRRP packets is configured.

The authentication key on the master device must be the same as the authentication key on a
backup device.
All devices in a VRRP backup group must be configured with the same authentication mode;
otherwise, the negotiation between the master and backup routers cannot succeed.
----End

By viewing the authentication mode and authentication key for VRRP packets, you can check
whether the configurations are successful.
Prerequisites
The configurations of the VRRP security function are complete.
Procedure
command to check the status of VRRP.
----End
Example
After the configuration is complete, run the display vrrp command to view the packet
authentication mode.
State : Master
Virtual IP : 10.1.1.111
PriorityRun : 120
TimerRun : 1s
TimerConfig : 1s
Auth Type : MD5 Auth key : >6M*PO438G/Q=^Q`MAF4<1!!
Virtual Mac : 0000-5e00-0101
Check TTL : YES


In the above command output, the Auth Type field displays MD5, and the Auth key field
displays >6M*PO438G/Q=^Q`MAF4<1!!. That is, VRRP backup group 1 is using MD5
authentication, and the authentication key is >6M*PO438G/Q=^Q`MAF4<1!!.
8.7 Configuring VRRP Smooth Switching

By configuring smooth VRRP switching, you can address the problem of traffic loss due to the
AMB/SMB switchover.

Before configuring VRRP smooth switching, familiarize yourself with the applicable
In the network where VRRP backup groups are configured, the backup switch switches to the
master switch because the original master switch and backup switch cannot communicate in
time when the original master switch performs the AMB/SMB switchover. After the AMB/SMB
switchover, the original master switch preempts to be the master switch again because its priority
is higher than the priority of the original backup switch.
Because the system is too busy during the switchover, the master router cannot send Hello
packets normally and the backup router cannot receive packets timely. In this case, the backup
router preempts to be the master router. Then, the link switchover is performed and this causes
packet loss.
Enabling VRRP smooth switching on a switch can optimize the VRRP performance and reduce
the impact on the user traffic.
None.
Data Preparation
To configure VRRP smooth switching, you need the following data.
No. Data
1 Interval for the master switch to send VRRP packets during VRRP smooth switching
8.7.2 Configuring VRRP Smooth Switching

After being enabled with smooth switching, a VRRP backup group performs the learning
function prior to the preemption function. This avoids switching the VRRP backup group status,
and thus traffic cannot be affected.

Context
Do as follows on the switch of a VRRP backup group:
Procedure
Step 1 Run:
vrrp timer-advertise learning enable
The function of learning the interval for receiving VRRP packets is enabled.
By default, this function is enabled.
Step 2 Run:
vrrp smooth-switching timer timer-value
VRRP smooth switching is enabled, and the interval carried in the VRRP packet during VRRP
smooth switching is configured.
By default, VRRP smooth switching is enabled, and the interval carried in the VRRP packet is
100 seconds.
Before running the command, you must enable the function of learning the interval for receiving
VRRP packets. When the learning function is disabled, VRRP smooth switching is also disabled.
NOTE
l If the interval set by the master switch for sending VRRP broadcast packets is much greater than the
interval set by the backup switch, the backup switch resets the "masterdown" time after the backup
switch is restarted and the interface recovers. The master switch may not send packets after the
"masterdown" time of the backup switch expires. In this case, the backup switch becomes the master
switch. As a result, two master switchs exist.
l During the AMB/SMB switchover, the master switch sends VRRP smooth switching packets at the
configured interval. If the time configured by the master switch for VRRP smooth switching, such as
1s, is shorter than the configured interval for sending VRRP broadcast packets, such as 10s, VRRP
packets are sent at the interval of 10s, and the interval carried in the VRRP packet is 1s. As a result,
the status of the backup switch continuously flaps.
----End

By viewing the status of a VRRP backup group, you can check whether the configurations are
successful.
Prerequisites
The configurations of the VRRP smooth switching function are complete.
Procedure
command to check the status of the VRRP backup group.
----End

Example
After configuring VRRP smooth switching, perform the AMB/SMB switchover on the device.
During the AMB/SMB switchover, the status of the VRRP backup group does not switch, and
thus the user traffic is not affected. After the AMB/SMB switchover, all VRRP configurations
of the new AMB are consistent with those of the original AMB.
State : Master
Virtual IP : 10.10.10.158
PriorityRun : 180
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
8.8 Adjusting and Optimizing VRRP

By adjusting parameters of a VRRP backup group, you can optimize the functions of a VRRP
backup group.

Before optimizing VRRP functions, familiarize yourself with the applicable environment and
complete pre-configuration tasks for configuring a VRRP backup group.
You can configure parameters for VRRP packets to optimize the backup group functions.
l By increasing the interval at which the VRRP backup group sends VRRP advertisement
packets, you can reduce the network load caused by negotiation packets.
l Configurations of intervals for sending VRRP packets affect the master router election
differently in VRRP for IPv4 and VRRP6 as follows:
In VRRP for IPv4, the members in a VRRP backup group are configured with the same
interval for sending VRRP packets, which prevents multiple backup routers from being
switched to master routers simultaneously in one VRRP backup group.
In VRRP6, only can one master router work in a VRRP6 backup group in spite of the
fact that members are configured with different intervals for sending VRRP packets.
l By configuring the preemption mode and preemption delay time of the switch in the backup
group, you can increase or reduce the speed of the master/backup switchover.
l By enabling the test on the reachability of the virtual IP address, you can ping the virtual
IP address to check the network connectivity.
l By prohibiting the system from checking number of hops in VRRP packets, you can
improve the compatibility of Huawei routers with different vendors' routers.

Before adjusting and optimizing VRRP, complete the following tasks:
l Configuring network layer attributes for interfaces to connect to the network

l Configuring the VRRP backup group
Data Preparation
To adjust and optimize VRRP, you need the following data.
No. Data
1 Interval for sending VRRP advertisement packets
2 Preemption delay of the switchs in the backup group
3 Timeout period for the master to send gratuitous ARP packets
8.8.2 Configuring the Interval for Sending VRRP Advertising

Messages
By increasing the interval for sending VRRP advertisement packets on a virtual switch, you can
reduce network load.
Context
The master switch sends VRRP advertisement packets to other backup switchs at preset intervals.
If the backup switchs do not receive VRRP advertising messages when a timer expires, the
backup switch with the highest priority automatically becomes the master switch.
Perform the following steps on the switch to adjust the interval for sending VRRP advertisement
packets:
Procedure
1. Run:
system-view

2. Run:

3. Run:
vrrp vrid virtual-router-id timer advertise advertise-interval
The interval for sending VRRP advertisement packets is configured.

The default interval for sending VRRP advertisement packets is 1 second. If multiple
backup groups exist, sending VRRP advertisement packets at very short intervals may
lead to frequent VRRP switchover. If this is the case, you can increase the interval.
NOTE
l If the advertise-interval parameters set for two VRRP devices are the same, the two devices
can work in master and slave mode.
l If the advertise-interval parameters set for two VRRP devices are different, both the two
devices are in master state.
l For VRRP6, run the following commands:
1. Run:
system-view

2. Run:

3. Run:
vrrp6 vrid virtual-router-id timer advertise interval
The interval for sending VRRP6 advertisement packets is configured for the master
router.
By default, the interval is 100 centiseconds, namely, 1 second.
The master device sends VRRP6 advertisement messages at the interval to the backup
devices in the group to notify that the master device works normally. If the backup
devices do not receive any VRRP6 advertisement message after the interval expires,
the backup device with the highest priority becomes the master device automatically.
----End
8.8.3 Configuring the Preemption Delay Time of Backup Group

Switch s
By setting a preemption delay time for switchs in a VRRP backup group, you can speed up or
slow down a master/backup switchover.
Context
Perform the following steps on the VRRP backup switch of which the latency of preemption
needs to be adjusted:
Procedure
1. Run:
system-view

2. Run:


3. Run:
vrrp vrid virtual-router-id preempt-mode timer delay delay-value
The preemption delay of switchs in the backup group is configured.
The preemption mode is enabled by default and the delay period is 0. This means that
preemption is immediate. If the priority of a backup switch becomes higher than that
of the current master switch, the backup immediately becomes a new master switch.
The original master switch becomes a backup switch. After a preemption delay time
is set, the backup switch is delayed to preempt the master switch status.
Run the vrrp vrid virtual-router-id preempt-mode disable command to configure

switchs in the backup group with the non-preemption mode. In the non-preemption
mode, if a switch in the backup group becomes the master switch and works normally,
other switchs do not become the master switch even if they are configured with higher
priorities later.
If the IP address owner recovers from a fault, it switches to be the master switch
immediately regardless any preemption delay that may have been set. The preemption
delay refers to a delay period for the backup switch to be switched to be the master
switch. The preemption delay is unavailable for the IP address owner. If a VRRP
backup group needs to be configured with a preemption delay, the master virtual
switch cannot be configured as the IP address owner.
Run the undo vrrp vrid virtual-router-id preempt-mode command to restore the
default preemption mode.
NOTE
On each switch to be configured with a delay mode in a VRRP backup group, it is recommended
to configure backup switchs with the immediate preemption mode (whose delay time is 0
seconds) and configure the master switch with the preemption mode (whose delay time is
specified). Configuring the delay time for the master switch can ensure that the original primary
link has enough time to restore and work stably, and then switch back. At the same time, the
backup link works normally. If the data is switched back to the original primary link, the
application is not affected.
l For VRRP6, run the following commands:
1. Run:
system-view

2. Run:

3. Run:
vrrp6 vrid virtual-router-id preempt-mode timer delay delay-value
The delay time of preemption is configured on the switch in the VRRP6 backup group.
The preemption mode is enabled by default and the preemption delay time is 0 seconds.
This means that preemption is immediately. If the priority of a backup router becomes
higher than that of the master router, the backup router immediately becomes a new
master router. The original master router becomes a backup router. After a preemption

delay time is set, a switchover between a backup router and the master router is delayed
for the amount of time specified by the value.
You can run the vrrp6 vrid preempt-mode disable command to adopt the non-
preemption mode on the switch of the VRRP6 backup group. In non-preemption mode,
after a certain switch becomes the master router in the backup group and works
normally, another switch cannot preempt the master router even if its priority is set to
a value higher than that of the master router.
When the IPv6 address owner recovers from a fault, the router immediately becomes
the master router despite the set delay time. The preemption delay refers to a period
during which a backup router waits for preempting the master router, whereas an IPv6
address owner is irrelevant to the preemption delay. In a VRRP6 backup group that
needs to be configured with the preemption delay, the master router cannot be
configured as the IPv6 address owner.
You can run the undo vrrp6 vrid preempt-mode command to restore the default
preemption mode.
NOTE
To configure the preemption mode for each switch in a VRRP6 backup group, you are
recommended to configure the immediate preemption mode on each backup router by setting
the delay time to 0 seconds, and configure the delayed preemption mode on the master router
by setting a delay time. This allows a transition period for the uplink status and the downlink
status to restore consistency on an unstable network, and thus prevents user devices from
learning the incorrect address of the master router due to dual master routers or frequent
preemption.
----End
8.8.4 Enabling the Reachability Test of the Virtual IP Address

By enabling the reachability test for a virtual IP address, you can use the ping function to detect
network reachability.
Context
On the S9700, you can ping the virtual IP address to check the following items:
l Availability of the master switch in a backup group

l Accessibility of external networks through the virtual IP address that serves as the default
gateway.
Do as follows on the switch that needs to be enabled with a reachable virtual IP address:
Procedure
Step 1 Run:
system-view
Step 2 Run:
vrrp virtual-ip ping enable
Testing reachability of a virtual address is enabled.

By default, the ping function is enabled. The master switch responds to ping packets to the virtual
IP address of this backup group.
Pinging a virtual address may cause ICMP attacks. Run the undo vrrp virtual-ip ping
enable command to disable the function of testing reachability of a virtual IP address.
----End
8.8.5 Disabling a Switch from Checking Number of Hops in VRRP

Packets
By prohibiting the check of TTLs in VRRP packets, you can improve compatibility between
devices from different vendors.
Context
The system detects number of hops in received VRRP packets, as defined in RFC 3768. The
packets with the number of hops not being 255 are discarded.
In certain networking environments where Huawei devices and non-Huawei devices work
together, checking the number of hops in VRRP packets may result in VRRP packets being
discarded mistakenly. To prevent this, you can disable the system from checking the number of
hops in VRRP packets.
Do as follows on the switch that is prohibited from checking the number of hops of VRRP
packets:
Perform the following step as required to configure VRRP for IPv4 or VRRP6.
Procedure
l For VRRP for IPv4,
1. Run:
system-view

2. Run:

3. Run:
vrrp un-check ttl
Checking TTLs in VRRP packets is disabled.

By default, TTLs in VRRP packets are detected. You can run the undo vrrp un-check
ttl command to enable the router to check TTLs in VRRP packets.
l For VRRP6,
1. Run:
system-view

2. Run:


3. Run:
vrrp6 un-check hop-limit
Checking the hop limit in VRRP6 packets is disabled.
By default, the hop limit in VRRP6 packets is checked. You can run the undo vrrp6
un-check hop-limit command to enable the switch to check the hop limit in VRRP6
packets.
----End
8.8.6 Configuring the Timeout Time of Sending Gratuitous ARP

Packets by the Master router
By adjusting the interval for sending gratuitous ARP packets on the master device, you can
reduce the number of VRRP packets on the network.
Context
Perform the following procedure on the switch to send gratuitous ARP packets:
Procedure
Step 1 Run:
system-view
Step 2 Run:
vrrp gratuitous-arp timeout time
A timeout period is configured for the master switch to send gratuitous ARP packets.
The master switch sends ARP packets with the virtual MAC address. By default, the master
router sends a gratuitous ARP packet every 120 seconds.
Run the undo vrrp gratuitous-arp timeout command in the system view to restore the default
timeout period for sending gratuitous ARP packets.
Run the vrrp gratuitous-arp timeout disable command in the system view to disable the master
switch from sending gratuitous ARP packets.
----End

By viewing adjustments made to VRRP backup group parameters, you can check whether the
configurations are correct.
Prerequisites
The configurations for adjusting and optimizing VRRP functions are complete.

Procedure
[ brief ] command to check the status of VRRP.
id ] ] [ brief ] command to check the status and configurations of the VRRP6 backup group.
----End
Example
Run the display vrrp command to view modified VRRP parameters. In this example, the
TimerRun field and the TimerConfig field display 20. The default interval of 1 second for
sending VRRP advertisement packets is modified to 20 seconds.
State : Master
Virtual IP : 100.1.1.111
PriorityRun : 120
TimerRun : 20s
TimerConfig : 20s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
GigabitEthernet1/0/0 | Virtual Router 1
State : Master
PriorityRun : 200
TimerRun : 200s
TimerConfig : 20s
Virtual Mac : 0000-5e00-0201
Accept Mode : ON
IF State : UP
8.9 Configuring mVRRP Backup Groups

An mVRRP backup group can be bound to other member backup groups and determine the
status of member backup groups according to the bindings. This is applicable to the scenario
where a device is dual-homed to master and slave devices on a MAN.

Before configuring an mVRRP backup group, familiarize yourself with the applicable

Figure 8-3 mVRRP determines the dual-homing of the master and slave switches
NPE1
mVRRP
UPE
NPE2
As shown in Figure 8-3, when the convergence layer of the Metro Ethernet (ME) dual NPEs
are deployed for high reliability. The master and standby switches are determined by mVRRP
between NPEs.
The mVRRP backup group is actually the ordinary VRRP backup group. The difference is that
the mVRRP backup group can be bound to other backup groups of different services. The status
of the backup group of related services depends on the binding relationship.
The mVRRP backup group can be bound to several backup group members. The mVRRP backup
group cannot be bound to other management backup groups.
According to different applications, the binding relationship of the mVRRP backup group is as
follows:
l The VRRP backup group is bound to the mVRRP backup group: UPEs are dual-homed to
NPEs. VRRP is run between NPEs. The master NPE and backup NPE are determined by
the configured priority of VRRP. Multiple VRRP backup groups run between NPEs with
different services.
If each VRRP backup group needs to maintain its own state machine, a huge number of
VRRP packets exist among NPEs. To simplify the process and decrease occupancy of
bandwidth, you can set one VRRP backup group as the mVRRP backup group. Other
backup group members are bound to the mVRRP backup group. The master and slave
switches are determined directly by the binding relationship.
l The service interfaces are bound to the mVRRP backup group. If the UPEs are dual-homed
to NPEs through two physical links. You can bind the member interfaces to the mVRRP
backup group to determine the master member interfaces and the slave interfaces.
Before configuring mVRRP, complete the following tasks:
l Configuring attributes of network layer of interfaces for connectivity

Data Preparation
To configure mVRRP, you need the following data.
No. Data
1 ID of the mVRRP and IDs of VRRP backup group members
2 Virtual IP address of the mVRRP and virtual IP addresses of VRRP backup group
members
3 Priority of the mVRRP
4 Number of the member interface
5 PW peer IP address
8.9.2 Configuring mVRRP Backup Group

Each VRRP backup group needs to maintain its own state machine by sending VRRP packets.
Configuring an mVRRP backup group can reduce bandwidth consumption of VRRP packets.
Context
Do as follows on each switch of an mVRRP backup group:
Procedure
1. Run:
system-view

2. Run:

3. Run:
A backup group is created and a virtual IP address is assigned to the backup group.
4. Run:
The priority of the VRRP backup group is configured.

5. Run:
admin-vrrp vrid virtual-router-id
This VRRP backup group is configured as an mVRRP backup group.


1. Run:
system-view

2. Run:

3. Run:
local ]
A VRRP6 backup group is created, and a virtual IPv6 address is assigned to the VRRP
backup group.
4. Run:
vrrp6 vrid virtual-router-id priority priority-value
The priority of the VRRP6 backup group is configured.

5. Run:
admin-vrrp6 vrid virtual-router-id
This VRRP6 backup group is configured as an mVRRP6 backup group.
----End
8.9.3 (Optional) Configuring Member VRRP Backup Groups and

Binding them to the mVRRP Backup Group
Through the bindings between member VRRP backup groups and the mVRRP backup group,
the state machines of member VRRP backup groups can be consistent with the state machine of
the mVRRP backup group.
Context
Do as follows on each switch on which the member VRRP backup groups need to be bound to
an mVRRP backup group.
Procedure
1. Run:
system-view

2. Run:
The interface view of a VRRP member is displayed.

3. Run:
A backup group is created with a virtual IP address.

The status of the member VRRP backup group is determined by the mVRRP backup
group. Therefore, the member VRRP backup group needs not a priority.
4. Run:
vrrp vrid virtual-router-id1 track admin-vrrp interface interface-type
interface-number [ .subinterface-number ] vrid virtual-router-id2
The member VRRP backup group is bound to the mVRRP backup group.
After the member VRRP backup group is bound to the mVRRP backup group, the
state machine of the member VRRP backup group becomes dependent. That is, the
member VRRP backup group deletes the protocol timer, and no longer sends or
receives packets, and implements its state machine by directly copying the status of
the mVRRP backup group. The backup member can be bound to only one mVRRP.
NOTE
Only a single member VRRP backup group can be configured on a single interface.
1. Run:
system-view

2. Run:
The interface view of a member VRRP6 backup group is displayed.

3. Run:
local ]
A member VRRP6 backup group is created, and a virtual IPv6 address is assigned to
the member VRRP6 backup group.
The status of the member VRRP6 backup group is determined by the mVRRP6 backup
group. Therefore, the member VRRP6 backup group does not need a priority.
4. Run:
vrrp6 vrid virtual-router-id1 track admin-vrrp6 interface interface-type
interface-number vrid virtual-router-id2
The member VRRP6 backup group is bound to the mVRRP6 backup group.
After the member VRRP6 backup group is bound to the mVRRP backup group, the
state machine of the member VRRP6 backup group becomes dependent. That is, the
member VRRP6 backup group deletes the protocol timer, and no longer sends or
receives packets, and implements its state machine by directly copying the status of
the mVRRP6 backup group. A member VRRP6 backup group can be bound to only
one mVRRP6 backup group.
NOTE
Only a single member VRRP6 backup group can be configured on a single interface.
----End

By viewing all bindings in an mVRRP backup group, you can check whether the configurations
are successful.

Prerequisites
The configurations of the mVRRP backup groups function are complete.
Procedure
l Run the display vrrp binding admin-vrrp [ interface interface-type1 interface-
number1 ] [ vrid virtual-router-id ] member-vrrp [ interface interface-type2 interface-
number2 ] [ vrid virtual-router-id ] command to check the binding between the mVRRP
backup group and the member VRRP backup groups.
l Run the display vrrp binding admin-vrrp [ interface interface-type1 interface-
number1 ] [ vrid virtual-router-id ] member-interface [ interface interface-type2
interface-number2 ] command to check the binding between the mVRRP backup group
and member VRRP backup groups.
l Run the display vrrp admin-vrrp command to check the status of all mVRRP backup
groups in the current configuration.
----End
Example
After the configuration, you can run the display vrrp binding admin-vrrp command to view
all binding information about the member VRRP backup group, interface member, and PW
member.
<Quidway> display vrrp binding admin-vrrp
Interface: Vlanif 100, admin-vrrp vrid: 6, state: Master
Member-vrrp number: 1
Interface: Vlanif 200, vrid: 8, state: Master
Member-interface number: 1
Interface: Vlanif 300, state: Up
8.10 Configuring VRRP Version Upgrade

After being upgraded from version 2 to version 3, VRRP can support both IPv6 and IPv4
networks.

Before configuring VRRP version upgrade, familiarize yourself with the applicable
Currently, VRRPv2 is adopted. VRRP for IPv4 supports both VRRPv2 packets and VRRPv3
packets, whereas VRRP for IPv6 supports only VRRPv3 packets. You can undertake this
configuration task to upgrade the VRRP version as required.
Before configuring VRRP version upgrade, complete the following tasks:

l Installing the device and powering it on properly

l Ensuring that VRRPv2 is running on the device
Data Preparation
To configure VRRP version upgrade, you need the following data.
No. Data
1 VRRP version number
8.10.2 Configuring VRRPv3

After VRRPv3 is configured, VRRP backup groups can receive both VRRPv2 and VRRPv3
Advertisement packets.
Context
Do as follows on each switch in a VRRP backup group.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vrrp version v3
The VRRP version of the current device is set to VRRPv3.

vrrp version-3 send-packet-mode { v2-only | v3-only | v2v3-both }
The mode for sending Advertisement packets in VRRPv3 is set.

The default VRRP version is v2. If the VRRP version is switched to v3, the default mode for
sending advertisement packets is v3-only.
----End

You can view VRRP version information to check whether the configuration is successful.
Prerequisites
The configurations of VRRP version upgrade are complete.
Procedure
l Run the display vrrp protocol-information command to view VRRP version information.
----End

Example
After the configuration, run the display vrrp protocol-information command, and you can
view that the VRRP protocol version is v3 and the mode for sending Advertisement packets is
send v3 only.
<Quidway> display vrrp protocol-information
VRRP protocol information is shown as below:
VRRP protocol version : v3
Send advertisement packet mode : send v3 only
8.11 Maintaining VRRP

This section describes how to maintain VRRP. Detailed operations include deleting VRRP
statistics, and monitoring VRRP operating status.
8.11.1 Debugging VRRP

After debugging, you need to disable the debugging function in time.
Context
CAUTION
Debugging affects the performance of the system. After debugging, run the undo debugging
When a VRRP fault occurs, run the following debugging commands in the user view to debug
VRRP and locate the fault.
Procedure
l Run the debugging vrrp packet command in the user view to enable the debugging of
VRRP packets.
l Run the debugging vrrp state command in the user view to enable the debugging of VRRP
status.
l Run the debugging vrrp timer command in the user view to enable the debugging of VRRP
timer.
----End

This section provides several configuration examples of VRRP.

8.12.1 Example for Configuring VRRP in Master/Backup Mode
As shown in Figure 8-4, Host A communicates with Host B through the default gateway.
The requirements are as follows:
l The VRRP group that consists of SwitchA and SwitchB functions as the default gateway
of Host A.
l SwitchA functions as the gateway. When SwitchA fails, SwitchB becomes the gateway.
l After SwitchA recovers, it preempts to be the master router within 20 seconds.
Figure 8-4 Networking of a VRRP group in master/backup mode
Backup group 1
Virtual IP Address:
10.1.1.111 SwitchA
Master
GE1/0/0
GE2/0/0
GE1/0/1
SwitchC
HostA GE1/0/0
10.1.1.100/24 HostB
GE1/0/2
GE1/0/0 20.1.1.100/24
GE2/0/0
Ethernet SwitchB
Backup
Device Interface VLANIF interface IP address
SwitchA GE1/0/0 VLANIF100 10.1.1.1/24
GE2/0/0 VLANIF200 192.168.1.1/24
SwitchB GE1/0/0 VLANIF100 10.1.1.2/24
GE2/0/0 VLANIF400 192.168.2.1/24
SwitchC GE1/0/0 VLANIF300 20.1.1.1/24
GE1/0/1 VLANIF200 192.168.1.2/24
GE1/0/2 VLANIF400 192.168.2.2/24

1. Configure VLANIF interfaces and assign IP addresses to the VLANIF interface.
2. Configure the OSPF protocol between SwitchA, SwitchB, and SwitchC to implement
interworking between them.
3. Create VRRP group 1 on VLANIF 100 of SwitchA. Set the highest priority for SwitchA
in the VRRP group to ensure that SwitchA functions as the master. Configure the
preemption mode on SwitchA.
4. Create VRRP group 1 on VLANIF 100 of SwitchB and use the default priority.
Data Preparation
l ID and virtual IP address of the VRRP group
l Priorities of SwitchA and SwitchB in the VRRP group
l Preemption mode
Procedure
Step 1 Configure VLANIF interfaces and assign IP addresses to the VLANIF interface.
# Create VLANs and add physical interfaces to VLANs.
[SwitchA] vlan batch 100 200
The configurations of SwitchB and SwitchC are similar to the configuration of SwitchA, and
# Configure an IP address for the VLANIF interface on SwitchA.
# Configure an IP address for the VLANIF interface on SwitchB.

# Configure an IP address for the VLANIF interface on SwitchC.

[SwitchC] interface vlanif 200
[SwitchC-Vlanif200] ip address 192.168.1.2 24
[SwitchC-Vlanif200] quit


Step 2 Configure the OSPF protocol between SwitchA, SwitchB, and SwitchC.
[SwitchA] ospf 1
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
[SwitchB] ospf 1
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] network 192.168.2.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
[SwitchC] ospf 1
[SwitchC-ospf-1] area 0
[SwitchC-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] quit
[SwitchC-ospf-1] quit
# Configure the default gateway address of Host A to 10.1.1.111 and the default gateway address
of Host B to 20.1.1.1.
Step 3 Configure a VRRP group.
# On SwitchA, assign an IP address to the VLANIF interface. Create VRRP group 1 and set the
priority of SwitchA in the VRRP group to 120 so that SwitchA functions as the master.
[SwitchA] interface Vlanif 100
[SwitchA-Vlanif100] vrrp vrid 1 virtual-ip 10.1.1.111
[SwitchA-Vlanif100] vrrp vrid 1 priority 120
[SwitchA-Vlanif100] vrrp vrid 1 preempt-mode timer delay 20
# On SwitchB, assign an IP address to the VLANIF interface. Create VRRP group 1 and retain
the default priority of SwitchB in the VRRP group so that SwitchB functions as the backup.
[SwitchB-Vlanif100] vrrp vrid 1 virtual-ip 10.1.1.111

l The VRRP group can function as the gateway.
After the preceding configuration, Host A can ping Host B. Run the display vrrp command on
SwitchA, and you can find that SwitchA is the master switch. Run the display vrrp command
on SwitchB, and you can find that SwitchB is the backup switch.
<SwitchA> display vrrp
state : Master

Virtual IP : 10.1.1.111
Master IP : 10.1.1.1
PriorityRun : 120
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
<SwitchB> display vrrp
state : Backup
Virtual IP : 10.1.1.111
PriorityRun : 100
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
Run the display ip routing-table command on SwitchA and SwitchB. You can find a direct
route to the virtual IP address in the routing table of SwitchA. In the routing table of SwitchB,
this direct route is an OSPF route. The displayed information on SwitchA and SwitchB is as
follows:
<SwitchA> display ip routing-table
Route Flags: R - relied, D - download to fib
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif100
20.1.1.0/24 OSPF 10 2 D 192.168.1.2 Vlanif200
192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif200
192.168.1.2/32 Direct 0 0 D 192.168.1.2 Vlanif200
192.168.2.0/24 OSPF 10 2 D 10.1.1.2 Vlanif100
<SwitchB> display ip routing-table
Route Flags: R - relied, D - download to fib
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Vlanif100
20.1.1.0/24 OSPF 10 2 D 192.168.2.2 Vlanif200
192.168.1.0/24 OSPF 10 2 D 10.1.1.1 Vlanif100
192.168.2.0/24 Direct 0 0 D 192.168.2.1 Vlanif200
192.168.2.2/32 Direct 0 0 D 192.168.2.2 Vlanif200
l When SwitchA fails, SwitchB becomes the master switch.
Run the shutdown command on VLANIF 100 of SwitchA to simulate a link fault.

Run the display vrrp command on SwitchB to view information about the VRRP status. You
can find that SwitchB is the master switch.
<SwitchB> display vrrp
state : Master
Virtual IP : 10.1.1.111
PriorityRun : 100
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
l When SwitchA recovers, it preempts to be the master.

Run the undo shutdown command on VLANIF 100 of SwitchA. Wait for 20 seconds after
VLANIF 100 recovers to the Up state, and then run the display vrrp command on SwitchA to
view the VRRP status. You can find that SwitchA is the master switch.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 200
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
vrrp vrid 1 virtual-ip 10.1.1.111
vrrp vrid 1 priority 120
vrrp vrid 1 preempt-mode timer delay 20
#
interface Vlanif200
ip address 192.168.1.1 255.255.255.0
#
#
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 100 400
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0


#
interface Vlanif400
ip address 192.168.2.1 255.255.255.0
#
#
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
l Configuration file of SwitchC

#
sysname SwitchC
#
#
interface Vlanif200
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif300
ip address 20.1.1.1 255.255.255.0
#
interface Vlanif400
ip address 192.168.2.2 255.255.255.0
#
#
#
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return
8.12.2 Example for Configuring VRRP in Load Balancing Mode
As shown in Figure 8-5,
l Switch A is the master device in VRRP group 1 and the backup device in VRRP group 2.
l Switch B is the master device in VRRP group 2 and the backup device in VRRP group 1.
l Host A on the internal network uses VRRP group 1 as the gateway, and Host C uses VRRP
group 2 as the gateway. The VRRP groups share data flows and back up each other.

Figure 8-5 Networking of VRRP in load balancing mode
Backup group 2
Virtual IP Address: SwitchA
10.1.1.112 group 1:Master
group 2:Backup
GE2/0/0
GE1/0/0
HostA
GE1/0/1
10.1.1.100/24
SwitchC GE1/0/0
GE1/0/2 HostB
20.1.1.100/24
HostC GE2/0/0
10.1.1.101/24 GE1/0/0
SwitchB
Ethernet group 2:Master
Backup group 1 group 1:Backup
Virtual IP Address:
10.1.1.111
SwitchA GE1/0/0 VLANIF100 10.1.1.1/24
GE2/0/0 VLANIF200 192.168.1.1/24
SwitchB GE1/0/0 VLANIF100 10.1.1.2/24
GE2/0/0 VLANIF400 192.168.2.1/24
SwitchC GE1/0/0 VLANIF300 20.1.1.1/24
GE1/0/1 VLANIF200 192.168.1.2/24
GE1/0/2 VLANIF400 192.168.2.2/24
1. Implement networking between Switch A, Switch B, and Switch C.
2. Create two VRRP groups on VLANIF 100 of Switch A. Configure Switch A as the master
device in VRRP group 1 and the backup device in VRRP group 2.
3. Create two VRRP groups on VLANIF 100 of Switch B. Configure Switch B as the master
device in VRRP group 2 and the backup device in VRRP group 1.

Data Preparation
l IDs and virtual IP addresses of the VRRP groups
l Priorities of Switch A and Switch B in the VRRP groups
For details, see OSPF Configuration.
Procedure
Step 1 Configure interworking between devices on the network.
# Configure the default gateway of Host A to the virtual IP address 10.1.1.111 of VRRP group
1, the default gateway of Host B to 20.1.1.1, and the default gateway of Host C to the virtual IP
address 10.1.1.112 of VRRP group 2.
# Configure OSPF between Switch A, Switch B, and Switch C.
Step 2 Configure VRRP groups.
# On Switch A, assign an IP address to VLANIF 100. Create VRRP group 1 and set the priority
of Switch A in VRRP group 1 to 120 so that Switch A functions as the master. Create VRRP
group 2 and retain the default priority (100) of Switch A in VRRP group 2 so that Switch A
functions as the backup device in VRRP group 2.
[SwitchA] interface Vlanif 100
# On Switch B, assign an IP address to VLANIF 100. Create VRRP group 1 and retain the default
priority (100) of Switch B in VRRP group 1 so that Switch B functions as the backup. # Create
VRRP group 2 on Switch B and set the priority of Switch B in VRRP group 2 to 120 so that
Switch B functions as the master in VRRP group 2.
[SwitchB] interface Vlanif 100
[SwitchB-Vlanif100] vrrp vrid 2 priority 120

After the preceding configuration, Host A and Host C can ping Host B successfully.
Tracert Host B from Host A and Host C. Packets from Host A to Host B pass through Switch
A and Switch C. Packets from Host C to Host B pass through Switch B and Switch C. That is,
load balancing is implemented between Switch A and Switch B.
<HostA> tracert 20.1.1.100
traceroute to 20.1.1.100(20.1.1.100), max hops: 30, packet length: 40, press
CTRL_C to break
1 10.1.1.1 120 ms 50 ms 60 ms
2 192.168.1.2 100 ms 60 ms 60 ms
3 20.1.1.100 130 ms 90 ms 90 ms

<HostC> tracert 20.1.1.100

traceroute to 20.1.1.100(20.1.1.100) 30 hops max,40 bytes packet
1 10.1.1.2 30 ms 60 ms 40 ms
2 192.168.2.2 90 ms 60 ms 60 ms
3 20.1.1.100 70 ms 60 ms 90 ms
Run the display vrrp command on Switch A, you can find that Switch A is the master in VRRP
group 1 and the backup in VRRP group 2.
[SwitchA] display vrrp
state : Master
Virtual IP : 10.1.1.111
PriorityRun : 120
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0101
Check TTL : YES
state : Backup
Virtual IP : 10.1.1.112
PriorityRun : 100
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0102
Check TTL : YES
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 200
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif200
ip address 192.168.1.1 255.255.255.0
#
#
#

ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 100 400
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
#
#
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return

#
sysname SwitchC
#
#
interface Vlanif200
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif300
ip address 20.1.1.1 255.255.255.0
#
interface Vlanif400
ip address 192.168.2.2 255.255.255.0
#
#
#
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255

#
return
8.12.3 Example for Configuring VRRP Fast Switchover
As shown in Figure 8-6, Switch A, Switch B, Switch C, Switch D and the Universal Medium
Gateway (UMG) form a simple next generation network (NGN).
The networking is as follows:
l The UMG connects to Switch A and Switch B through Switch C and Switch D.
l Switch A and Switch B run VRRP. Switch A functions as the master, and Switch B
functions as the backup.
When Switch A fails, or when the GE link between Switch A and Switch B fails, the active/
standby switchover should be completed within 1 second. That is, fast switchover is required
on the bearer network.
Figure 8-6 Networking of VRRP fast switchover
Backbone
Network
GE2/0/0 GE2/0/0
SwitchA SwitchB
GE1/0/0 GE1/0/0
Backup group 10
Virtual IP address: 10.1.1.3/24
SwitchC SwitchD
VLAN
UMG
Switch A GE1/0/0 VLANIF100 10.1.1.1/24
GE2/0/0 VLANIF200 192.168.0.1/24
Switch B GE1/0/0 VLANIF100 10.1.1.2/24
GE2/0/0 VLANIF200 192.168.0.2/24

1. Implement networking between the Switches.
2. Configure a BFD session on Switch A and Switch B to monitor Switch A and its downlink
Switch A - Switch C - Switch D - Switch B.
3. Enable VRRP to track the BFD session on Switch B. When the BFD session becomes
Down, the priority of Switch B increases by 40 and then the switchover is triggered.
NOTE
This example describes only the configurations on Switch A and Switch B.
Data Preparation
l Local and remote discriminators of the BFD session
l ID and virtual IP address of the VRRP group
l Priorities of the S9700s in the VRRP group
Procedure
Step 1 Configure interworking between the Switches.
Assign IP addresses to all interfaces. # Configure OSPF between Switch A, Switch B, and Switch
C.
For details, see 8.12.1 Example for Configuring VRRP in Master/Backup Mode.
Step 2 Create a BFD session.
[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] bfd atob bind peer-ip 10.1.1.2 interface vlanif 200
[SwitchA-bfd-session-atob] min-rx-interval 50
[SwitchA-bfd-session-atob] min-tx-interval 50
[SwitchA-bfd-session-atob] commit

[SwitchB] bfd
[SwitchB-bfd] quit
[SwitchB] bfd btoa bind peer-ip 10.1.1.1 interface vlanif 200
[SwitchB-bfd-session-btoa] min-rx-interval 50
[SwitchB-bfd-session-btoa] min-tx-interval 50
[SwitchB-bfd-session-btoa] commit

Run the display bfd session command on Switch A and Switch B, and you can see that the BFD
session is Up. Take Switch A for example. The display is as follows:
[SwitchA] display bfd session all
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 2 10.1.1.2 Up Static Vlanif200
--------------------------------------------------------------------------------
Step 3 Configure VRRP fast switchover.

# Create VRRP group 10 on Switch A and set the priority of Switch A in VRRP group 10 to 160
so that Switch A functions as the master in VRRP group 10.
# Create VRRP group 10 on Switch B and set the priority of Switch B in VRRP group 10 to 140
so that Switch B functions as the backup in VRRP group 10.
[SwitchB-Vlanif100] vrrp vrid 10 priority 140
# Configure VRRP to track the status of the BFD session on the backup device. If the BFD
session becomes Down, the priority of Switch B increases by 40.
[SwitchB-Vlanif100] vrrp vrid 10 track bfd-session 2 increased 40
Run the display vrrp command on Switch A or Switch B, and you can see that Switch A is the
master and Switch B is the backup. You can also view the tracked BFD session and its status on
Switch B.
state : Master
PriorityRun : 160
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0110
Check TTL : YES
[SwitchB] display vrrp
state : Backup
PriorityRun : 140
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0110
Check TTL : YES


Track BFD : 2 Priority increased : 40
BFD-Session State : UP

# Run the shutdown command on VLANIF 200 of Switch A to simulate a link fault.
[SwitchA-Vlanif200] shutdown
On Switch B, VRRP fast switchover is performed after BFD fails.

%May 10 15:48:30 2008 SwitchB BFD/5/BFD:Slot=1;IO(1) BFD Session(Discr:2) FSM
Change To Down(Detect)
%May 10 15:48:30 2008 SwitchB VRRP/5/BfdWarning:
Virtual Router 10 | BFD-SESSION 2 : BFD_STATE_UP --> BFD_STATE_DOWN
%May 10 15:48:30 2008 SwitchB VRRP/5/StateWarning:
Vlanif100 | Virtual Router 10 : BACKUP --> MASTER
Run the display vrrp command on Switch A, and you can see that the status of Switch A changes
to Initialize.
state : Initialize
PriorityRun : 160
MasterPriority : 0
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0110
Check TTL : YES
Run the display vrrp command on Switch B, and you can see that Switch B becomes the master,
and the status of the BFD session changes to Down.
[SwitchB] display vrrp
state : Master
PriorityRun : 180
TimerRun : 1s
TimerConfig : 1s
Auth Type : NONE
Virtual Mac : 0000-5e00-0110
Check TTL : YES
Track BFD : 2 Priority increased : 40
BFD-Session State : DOWN
----End
Configuration Files

#
sysname SwitchA
#
vlan batch 100 200
#
bfd
#
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif200
ip address 192.168.0.1 255.255.255.0
#
#
#
bfd atob bind peer-ip 10.1.1.2 interface Vlanif 200
min-tx-interval 50
min-rx-interval 50
commit
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 100 200
#
bfd
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
vrrp vrid 10 track bfd-session 2 increased 40
#
interface Vlanif200
ip address 192.168.0.2 255.255.255.0
#
#
#
bfd btoa bind peer-ip 10.1.1.1 interface Vlanif 200
min-tx-interval 50
min-rx-interval 50
commit
#

ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
return
8.12.4 Example for Configuring VRRP6 on an Interface

Switch A and Switch B elect a master device according to the configured priorities in a VRRP
group.
Once the master device is determined in the group, only the master device responds to IPv6
messages. If the master device goes down, the backup device becomes the master device and
the hosts in the private network can still communicate with external networks.
The configured virtual address can be same as the address of any physical interface of the Switch
A or Switch B.
Figure 8-7 Networking of VRRP6
Virtual IP Address:
2000::1
GE1/0/0
SwitchA
Vlanif100
Master
2000::2
HostA
GE1/0/0
Vlanif100 SwitchB
HostB 2000::3
Network
Backup
Ethernet
1. Configure IPv6 addresses for interfaces.
2. Configure virtual IPv6 addresses.
Data Preparation
l VRRP6 group ID
l Priorities of the Switches in the VRRP6 group
l IPv6 addresses to be configured for interfaces
l Virtual IPv6 addresses to be configured for interfaces in the VRRP6 group

Procedure
Step 1 Enable IPv6 forwarding.
[SwitchA] ipv6
[SwitchB] ipv6
Step 2 Configure IPv6 addresses for interfaces.

[SwitchA] vlan 100
[SwitchA-Gigabitethernet1/0/0] port hybrid pvid vlan 100
[SwitchA-Gigabitethernet1/0/0] port hybrid untagged vlan 100
[SwitchA-Gigabitethernet1/0/0] quit
[SwitchA-Vlanif100] ipv6 enable
[SwitchA-Vlanif100] ipv6 address fe80::2 link-local
[SwitchA-Vlanif100] ipv6 address 2000::2 64
[SwitchB] vlan 100
[SwitchB-Gigabitethernet1/0/0] port hybrid pvid vlan 100
[SwitchB-Gigabitethernet1/0/0] port hybrid untagged vlan 100
[SwitchB-Gigabitethernet1/0/0] quit
[SwitchB-Vlanif100] ipv6 enable
[SwitchB-Vlanif100] ipv6 address fe80::3 link-local
[SwitchB-Vlanif100] ipv6 address 2000::3 64
Step 3 Configure virtual IPv6 addresses on interfaces in the VRRP6 group.

[SwitchA-Vlanif100] vrrp6 vrid 24 virtual-ip fe80::1 link-local
[SwitchA-Vlanif100] vrrp6 vrid 24 virtual-ip 2000::1
[Switch-Vlanif100] quit
[SwitchB-Vlanif100] vrrp6 vrid 24 virtual-ip fe80::1 link-local
[SwitchB-Vlanif100] vrrp6 vrid 24 virtual-ip 2000::1
Step 4 Set the priority of SwitchB to a value lower than the priority of SwitchA.
[SwitchB-Vlanif100] vrrp6 vrid 24 priority 25

The following information shows that SwitchA is the master device, and SwitchB is the backup
device.
[SwitchA] display vrrp6 interface vlanif100
State : Master

Virtual IP : FE80::1
2000::1
Master IP : FE80::200:FF:FE00:24
PriorityRun : 100
MasterPriority : 0
Preempt : YES Delay Time : 0
TimerRun : 100
TimerConfig : 100
Virtual Mac : 0000-5e00-0201
Uncheck hop limit : NO
Accept Mode : ON
[SwitchB] display vrrp6 interface vlanif100
State : Backup
2000::1
PriorityRun : 25
MasterPriority : 0
TimerRun : 100
TimerConfig : 100
Virtual Mac : 0000-5e00-0201
Accept Mode : ON
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100
#
ipv6
#
interface vlanif 100
ipv6 enable
ipv6 address 2000::2/64
vrrp6 vrid 24 virtual-ip FE80::1 link-local
vrrp6 vrid 24 virtual-ip 2000::1
#
#
return

#
sysname SwitchB
#
vlan batch 100
#
ipv6
#
interface vlanif 100
ipv6 enable


vrrp6 vrid 24 priority 25
#
#
return
8.12.5 Example for Configuring VRRP6 in Load Balancing Mode
As shown in Figure 8-8,
l Switch A is the master device in VRRP group 1 and the backup device in VRRP group 2.
l Switch B is the master device in VRRP group 2 and the backup device in VRRP group 1.
l Host A on the LAN uses the virtual IPv6 address of VRRP group 1 as the gateway address,
and Host B uses the virtual IPv6 address of VRRP group 2 as the gateway address. The
two VRRP groups load balance traffic and back up each other.
Figure 8-8 Networking of VRRP in load balancing mode
Backup group 1
Virtual IP Address
2000::100 SwitchA
group 1:Master
group 2:Backup
GE2/0/0
GE1/0/0
GE1/0/1
HostA
2000::3/64 GE2/0/0
SwitchC
HostC
GE1/0/2 2003::1/64
HostB GE1/0/0 GE2/0/0

2000::4/64
SwitchB
Ethernet group 1:Backup
Backup group 2 group 2:Master
Virtual IP Address
2000::60
Switch A GE1/0/0 VLANIF100 2000::1/64
GE2/0/0 VLANIF200 2002::1/64
Switch B GE1/0/0 VLANIF100 2000::2/64

GE2/0/0 VLANIF400 2001::1/64
Switch C GE1/0/1 VLANIF200 2002::2/64
GE1/0/2 VLANIF400 2001::2/64
GE2/0/0 VLANIF300 2003::2/64
1. Create VRRP group 1 and VRRP group 2 on VLANIF 100 of Switch A. Ensure that Switch
A is the master device in VRRP group 1 and the backup device in VRRP group 2.
2. Create VRRP group 1 and VRRP group 2 on VLANIF 100 of Switch B. Ensure that Switch
B is the backup device in VRRP group 1 and the master device in VRRP group 1.
Data Preparation
l IPv6 addresses of the interfaces
l IDs and virtual IPv6 addresses of the VRRP groups
l Priorities of the switches in each VRRP group
Procedure
Step 1 Configure IP addresses for the interfaces. The configuration procedure is not mentioned here.
Step 2 Configure OSPFv3 on Switch A, Switch B, and Switch C so that they can communicate with
each other. The configuration procedure is not mentioned here.
Step 3 Configure the hosts.
Set the default gateway address of Host A to 2000::10, which is the virtual IPv6 address of VRRP
group 1. Set the default gateway address of Host B to 2000::60, which is the virtual IPv6 address
of VRRP group 2. Set the default gateway address of Host C to 2003::2.
Step 4 Configure VRRP6 groups.
# Create VRRP group 1 and VRRP group 2 on VLANIF 100 of Switch A. Set the priority of
Switch A in VRRP group 1 to 120 so that Switch A becomes the master device in VRRP group
1. Use the default priority of Switch A in VRRP group 2 so that Switch A becomes the backup
device in VRRP group 2.
[SwitchA] interface vlanif100
[SwitchA-Vlanif100] vrrp6 vrid 1 virtual-ip FE80::1 link-local
[SwitchA-Vlanif100] vrrp6 vrid 1 priority 120
[SwitchA-Vlanif100] vrrp6 vrid 2 virtual-ip FE80::2 link-local

# Create VRRP group 1 and VRRP group 2 on VLANIF 100 of Switch B. Use the priority of
Switch B in VRRP group 1 to 120 so that Switch B becomes the backup device in VRRP group
1. Set the priority of Switch B in VRRP group 2 to 120 so that Switch B becomes the master
[SwitchB-Vlanif100] vrrp6 vrid 1 virtual-ip FE80::1 link-local
[SwitchB-Vlanif100] vrrp6 vrid 2 virtual-ip FE80::2 link-local
[SwitchB-Vlanif100] vrrp6 vrid 2 priority 120

After the preceding configuration is complete, Host A and Host C can ping Host B successfully.
Run the display vrrp6 command on Switch A, and you can find that VRRP group 1 and VRRP
group 2 are created on Switch A. Switch A is the master device in VRRP group 1 and the backup
[SwitchA] display vrrp6
State : Master
2000::100
PriorityRun : 120
TimerRun : 100
TimerConfig : 100
Virtual Mac : 0000-5e00-0201
Accept Mode : ON
State : Backup
2000::60
Master IP : FE80::218:82FF:FED1:B6DF
PriorityRun : 100
TimerRun : 100
TimerConfig : 100
Virtual Mac : 0000-5e00-0102
Accept Mode : ON
Run the display vrrp6 command on Switch B, and you can find that VRRP group 1 and VRRP
group 2 are created on SwitchB. Switch B is the backup device in VRRP group 1 and the master
[SwitchB] display vrrp6
State : Backup
2000::100
PriorityRun : 100

TimerRun : 100
TimerConfig : 100
Virtual Mac : 0000-5e00-0201
Accept Mode : ON
State : Master
2000::60
Master IP : FE80::218:82FF:FED1:B6DF
PriorityRun : 120
TimerRun : 100
TimerConfig : 100
Virtual Mac : 0000-5e00-0102
Accept Mode : ON
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 200
#
ipv6
#
ospfv3 1
router-id 1.1.1.1
#
interface Vlanif100
ipv6 enable
ospfv3 1 area 0.0.0.0
#
interface Vlanif200
ipv6 enable
#
port hybrid pvid untagged 100
#
#
return

#
sysname SwitchB
#
vlan batch 100 400
#
ipv6
#
ospfv3 1
router-id 2.2.2.2
#
interface Vlanif100
ipv6 enable
#
interface Vlanif200
ipv6 enable
#
#
#
return
#
sysname SwitchC
#
#
ipv6
#
ospfv3 1
router-id 3.3.3.3
#
interface Vlanif200
ipv6 enable
ipv6 address 2002::2
#
interface Vlanif300
ipv6 enable
#
interface Vlanif400
ipv6 enable
#
#
#


#
return

Configuration Guide - Reliability 9 Collection of Configuration Examples of Association
9 Collection of Configuration Examples of

Association
The collection of configuration examples of association of BFD and an interface, BFD and other
protocols, Ethernet OAM and an interface, and Ethernet OAM and other protocols are listed.
This helps engineers find required information.
Context
The S9700 supports fault transmission between BFD, Ethernet CFM, EFM OAM, and an
interface.
The manual provides the following configuration examples of association:
l 5.20.5 Example for Configuring Association Between an EFM OAM Module and an
Interface
l 5.20.6 Example for Associating EFM OAM with BFD for IP
l 5.20.7 Example for Configuring Association Between EFM OAM Modules
l 5.20.8 Example for Configuring Association Between an Ethernet CFM Module and
an Interface
l 5.20.9 Example for Configuring Association Between an EFM OAM Module and an
Ethernet CFM Module
l 5.20.10 Example for Configuring Association Between Ethernet CFM with Ethernet
CFM
l 5.20.11 Example for Associating Ethernet CFM with RRPP
l 5.20.12 Example for Associating Ethernet CFM with MSTP
l 7.15.4 Example for Associating the BFD Status with the Interface Status
l 7.15.5 Example for Configuring Association Between a BFD Session and an Interface
l 7.15.6 Example for Configuring Association Between the Status of BFD Sessions

Configuration Guide - Reliability 10 MAC Swap Loopback Configuration
10 MAC Swap Loopback Configuration
About This Chapter
This chapter describes the working principle and configuration of MAC swap loopback.
10.1 MAC Swap Loopback Overview

The MAC swap loopback function modifies the header of a received Ethernet frame by swapping
the source and destination MAC addresses so that the Ethernet frame can be sent back to the
sender. This function checks Ethernet connectivity and network performance.
10.2 MAC Swap Loopback Features Supported by the S9700
The S9700 supports local MAC swap loopback test and remote MAC swap loopback test.
10.3 Configuring Local MAC Swap Loopback
By configuring local MAC swap loopback, you can test connectivity and performance of a switch
and the Ethernet network connected to the switch.
10.4 Configuring Remote MAC Swap Loopback
By configuring remote MAC swap loopback, you can test connectivity and performance of the
Ethernet network connected to a switch.
This section provides examples of MAC swap loopback configuration.

10.1 MAC Swap Loopback Overview

The MAC swap loopback function modifies the header of a received Ethernet frame by swapping
the source and destination MAC addresses so that the Ethernet frame can be sent back to the
sender. This function checks Ethernet connectivity and network performance.
The MAC swap loopback technique can work with a network performance tester to test the
connectivity, throughput, and QoS of an Ethernet network.
A MAC swap loopback test can be performed only for Ethernet frames with IP payload.
10.2 MAC Swap Loopback Features Supported by the S9700

The S9700 supports local MAC swap loopback test and remote MAC swap loopback test.
Local MAC Swap Loopback Test

A local MAC swap loopback test checks connectivity and performance of the network between
a tester and a tested switch, and performance of the tested switch. As shown in Figure 10-1,
Ethernet frames sent by a tester traverse an Ethernet network and reach the tested switch
(SwitchB). After the tested switch receives the Ethernet frames, it forwards them to the interface
where local MAC swap loopback is configured. The tested switch swaps source and destination
MAC addresses of all Ethernet frames that match the local MAC swap loopback configuration
and sends the Ethernet frames back to the tester through the specified outbound interface. The
tester then analyzes network performance based on Ethernet frames sent from the tested switch.
When a local MAC swap test is performed on an interface, services on the interface are
interrupted, but services on other interfaces are not affected. If a large number of test packets
are sent, test packets occupy bandwidth of other services on the interface that sends test packets
back to the tester.
Figure 10-1 Local MAC swap loopback test
Tester
SMAC DMAC DATA DMAC SMAC DATA
DMAC SMAC DATA

Ethernet
SwitchB Users
SwitchA
SMAC DMAC DATA
Remote MAC Swap Loopback Test

A remote MAC swap loopback test checks connectivity and performance of the network between
a tester and a tested switch but does not check performance of the tested switch. As shown in
Figure 10-2, Ethernet frames sent by a tester traverse an Ethernet network and reach the tested
switch (SwitchB). After the uplink interface of the tested switch receives the Ethernet frames,

the switch swaps source and destination MAC addresses of all Ethernet frames that match the
remote MAC swap loopback configuration and sends the Ethernet frames back to the tester
through this interface. The tester then analyzes network performance based on Ethernet frames
sent from the tested switch.
A remote MAC swap loopback test modifies only Ethernet frames matching the MAC swap
loopback configuration on an interface, and other Ethernet frames can still be forwarded on the
interface. However, if a large number of test packets are sent, test packets occupy bandwidth of
other services on the interface.
Figure 10-2 Remote MAC swap loopback test
Tester
SMAC DMAC DATA DMAC SMAC DATA
DMAC SMAC DATA

Ethernet
SwitchB
SwitchA Users
SMAC DMAC DATA
10.3 Configuring Local MAC Swap Loopback

By configuring local MAC swap loopback, you can test connectivity and performance of a switch
and the Ethernet network connected to the switch.

Before configuring local MAC swap loopback, familiarize yourself with the applicable
configuration. This can help you complete the configuration task quickly and accurately.
Before using an S9700 to provide services for users, perform a local MAC swap loopback test
on the S9700 to check whether the S9700 can provide services properly. This test checks
connectivity and QoS CAR of the network between an S9700 downlink interface and a remote
device. The local MAC swap loopback test can also check whether VLAN mapping and VLAN
stacking are configured successfully on the downlink interface.
a tester and a tested switch, and performance of the tested switch.
Before configuring local MAC swap loopback, complete the following tasks:
l Creating a VLAN and adding the interface where you want to perform the local MAC swap
loopback test to the VLAN

l Configuring QoS CAR if you want to test QoS CAR on the network
For the configuration procedure, see the S9700 Core Routing Switch Configuration Guide
- QoS.
Data Preparation
To configure local MAC swap loopback, you need the following data.
No. Data
1 Type and number of the interface where the local MAC swap loopback test needs to
be performed
2 Type and number of the outbound interface that sends loopback packets to the tester
3 ID of the VLAN that the interfaces belong to
4 (Optional) Inner VLAN ID
5 Loopback timeout period
10.3.2 Configuring Local MAC Swap Loopback

a tester and a tested switch, and performance of the tested switch.
Context
Before performing a local MAC swap loopback test, configure the source MAC address,
destination MAC address, and VLAN ID of test packets on the S9700. Only the packets with
the specified source MAC address, destination MAC address, and VLAN ID are looped back.
Procedure
Step 1 Run:
system-view
Step 2 Run:
MAC swap loopback tests cannot be performed on an Eth-Trunk interface or its member
interfaces.
Step 3 Run:
loopback local swap-mac source-mac source-mac-address dest-mac dest-mac-address
vlan vlan-id [ inner-vlan inner-vlan-id ] interface interface-type interface-
number [ timeout { time-value | none } ]
Local MAC swap loopback is configured.

NOTE
The SA and XSA boards support loopback of only single-tagged Ethernet frames.
CAUTION
When a local MAC swap test is performed on an interface, services on the interface are
interrupted, but services on other interfaces are not affected. If a large number of test packets
are sent, test packets occupy bandwidth of other services on the interface that sends test packets
back to the tester.
If single VLAN tag is configured on the S9700, the test packets cannot be double-tagged.
----End
10.3.3 Enabling the MAC Swap Loopback Function

This section describes how to enable the MAC swap loopback function.
Context
A loopback test deteriorates network performance. If a large number of test packets are sent,
bandwidth of other services is occupied. To ensure network performance, enable the MAC swap
loopback function when the loopback test begins and disable it immediately after the loopback
test is complete.
Procedure
Step 1 Run:
system-view

Step 2 Run:

interfaces.
Step 3 Run:
loopback swap-mac start
The MAC swap loopback function is enabled.

This is a one-time command and is not saved in the configuration file.
To ensure service provisioning on the interface, run the loopback swap-mac stop command to
disable the MAC swap loopback function immediately after the loopback test is complete.
----End
10.3.4 Disabling the MAC Swap Loopback Function

This section describes how to disable the MAC swap loopback function.

Context
bandwidth of other services is occupied. Therefore, disable the MAC swap loopback function
immediately after the loopback test is complete.
Procedure
Step 1 Run:
system-view

Step 2 Run:

interfaces.
Step 3 Run:
loopback swap-mac stop
The MAC swap loopback function is disabled.

A MAC swap loopback test stops when you disable the MAC swap loopback function or the
loopback test times out. To perform the loopback test again, run the loopback swap-mac
start command.
----End

After configuring the local MAC swap loopback function, use the following command to verify
the configuration.
Prerequisites
All configurations of local MAC swap loopback are complete.
Procedure
l Run the display loopback swap-mac information command to view the configuration of
local MAC swap loopback.
----End
Example
Run the display loopback swap-mac information command to check whether MAC swap
loopback is configured correctly. After test packets are sent, run this command to view the
statistics on received test packets and discarded packets.
<Quidway> display loopback swap-mac information
Loopback type : local

Loopback state : running

Loopback test time(s) : 60
Loopback interface : GigabitEthernet1/0/0
Loopback output interface : GigabitEthernet1/0/1
Loopback source MAC : 0001-0001-0001
Loopback destination MAC : 0002-0002-0002
Loopback vlan : 10
Loopback inner vlan : 0
Loopback packets : 0
Drop packets : 3
10.4 Configuring Remote MAC Swap Loopback

By configuring remote MAC swap loopback, you can test connectivity and performance of the
Ethernet network connected to a switch.

Before configuring remote MAC swap loopback, familiarize yourself with the applicable
configuration. This can help you complete the configuration task quickly and accurately.
Before using an S9700 to provide services for users, perform a remote MAC swap loopback test
to check whether the S9700 can provide services properly. This test checks connectivity and
performance of the network between an S9700 uplink interface and a remote device. The remote
MAC swap loopback test can also check whether VLAN mapping and VLAN stacking are
configured successfully on the uplink interface.
a tester and a tested switch but does not check performance of the tested switch.
Before configuring remote MAC swap loopback, complete the following task:
l Creating a VLAN and adding the interface where you want to perform the remote MAC
swap loopback test to the VLAN
l Configuring VLAN mapping or VLAN stacking as required.
Data Preparation
To configure remote MAC swap loopback, you need the following data.
No. Data
1 Type and number of the interface where the remote MAC swap loopback test needs
to be performed
2 ID of the VLAN that the interface belongs to
3 (Optional) Inner VLAN ID
4 Timeout time of the loopback test

10.4.2 Configuring Remote MAC Swap Loopback

a tester and a tested switch but does not check performance of the tested switch.
Context
Before performing a remote MAC swap loopback test, configure the source MAC address,
destination MAC address, and VLAN ID of test packets on the S9700. Only the packets with
the specified source MAC address, destination MAC address, and VLAN ID are looped back.
Procedure
Step 1 Run:
system-view

Step 2 Run:

interfaces.
Step 3 Run:
loopback remote swap-mac source-mac source-mac-address dest-mac dest-mac-address
vlan vlan-id [ inner-vlan inner-vlan-id ] [ timeout { time-value | none } ]
Remote MAC swap loopback is configured.
CAUTION
A remote MAC swap loopback test modifies only Ethernet frames matching the MAC swap
loopback configuration on an interface, and other Ethernet frames can still be forwarded on the
interface. However, if a large number of test packets are sent, test packets occupy bandwidth of
other services on the interface.
If single VLAN tag is configured on the S9700, the test packets cannot be double-tagged.
----End
10.4.3 Enabling the MAC Swap Loopback Function
Context
bandwidth of other services is occupied. To ensure network performance, enable the MAC swap
loopback function when the loopback test begins and disable it immediately after the loopback
test is complete.

Procedure
Step 1 Run:
system-view
Step 2 Run:
interfaces.
Step 3 Run:
loopback swap-mac start
The MAC swap loopback function is enabled.
To ensure service provisioning on the interface, run the loopback swap-mac stop command to
disable the MAC swap loopback function immediately after the loopback test is complete.
----End
10.4.4 Disabling the MAC Swap Loopback Function

This section describes how to disable the MAC swap loopback function.
Context
bandwidth of other services is occupied. Therefore, disable the MAC swap loopback function
immediately after the loopback test is complete.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interfaces.
Step 3 Run:
loopback swap-mac stop
The MAC swap loopback function is disabled.

A MAC swap loopback test stops when you disable the MAC swap loopback function or the
loopback test times out. To perform the loopback test again, run the loopback swap-mac
start command.
----End

After configuring the remote MAC swap loopback function, use the following command to
verify the configuration.
Prerequisites
All configurations of remote MAC swap loopback are complete.
Procedure
l Run the display loopback swap-mac information command to view the configuration of
remote MAC swap loopback.
----End
Example
Run the display loopback swap-mac information command to check whether remote MAC
swap loopback is configured correctly. After test packets are sent, run this command to check
the number of received loopback packets.
<Quidway> display loopback swap-mac information
Loopback type : remote
Loopback vlan : 10

This section provides examples of MAC swap loopback configuration.
10.5.1 Example for Configuring Local MAC Swap Loopback

As shown in Figure 10-3, SwitchB is an S9700. On SwitchB, GE1/0/1 is connected to an
Ethernet network, and GE1/0/2 is connected to users.
A local MAC swap loopback test needs to be performed on GE1/0/2. A tester sends Ethernet
frames to SwitchB. After the source and destination MAC addresses of the Ethernet frames are
swapped on GE1/0/2, the Ethernet frames are sent back to the tester through GE1/0/1. The tester
analyzes connectivity and performance of the Ethernet network and SwitchB based on the
received Ethernet frames.

Figure 10-3 Networking diagram of a local MAC swap loopback test
Tester
Ethernet GE1/0/1 GE1/0/2
Users
SwitchA SwitchB
1. Create a VLAN, configure GE1/0/1 as a trunk interface and GE1/0/2 as a hybrid interface,
and add the interfaces to the VLAN.
2. Configure local MAC swap loopback on SwitchB.
3. Enable the MAC swap loopback function on SwitchB.
Data Preparation
l VLAN ID: 100

l Source and destination MAC addresses of test Ethernet frames: 0018-2000-0085 and
0018-2000-0070
l Timeout period of the loopback test: 80s
Procedure
Step 1 Create VLAN 100, configure GE1/0/1 as trunk interface and GE1/0/2 as a hybrid interface, and
add the interfaces to VLAN 100.
[SwitchB] vlan batch 100
Step 2 Configure local MAC swap loopback on GE1/0/2 and specify GE1/0/1 as the outbound interface
of loopback Ethernet frames. Enable the MAC swap loopback function.
[SwitchB-GigabitEthernet1/0/2] loopback local swap-mac source-mac 0018-2000-0085
dest-mac 018-2000-0070 vlan 100 interface gigabitethernet 1/0/1 timeout 80
[SwitchB-GigabitEthernet1/0/2] loopback swap-mac start


After completing the configuration, run the display loopback swap-mac information
command to verify the configuration. If the configuration is correct, send Ethernet frames from
the tester to test network performance.
[SwitchB] display loopback swap-mac information
Loopback type : local
Loopback vlan : 100
Drop packets : 3
----End
Configuration Files
#
sysname SwitchB
#
vlan batch 100
#
#
loopback local swap-mac source-mac 0018-2000-0085 dest-mac 0018-2000-0070
vlan
100 interface GigabitEthernet1/0/1 timeout 80
#
return
10.5.2 Example for Configuring Remote MAC Swap Loopback

As shown in Figure 10-4, SwitchB is an S9700. GE1/0/1 of SwitchB is connected to an Ethernet
network.
A remote MAC swap loopback test needs to be performed on GE1/0/1. A tester sends Ethernet
frames to SwitchB. After the Ethernet frames are received on GE1/0/1, SwitchB swaps their
source and destination MAC addresses and sends them back to the tester from GE1/0/1. The
tester analyzes connectivity and performance of the Ethernet network based on the received
Ethernet frames.

Figure 10-4 Networking diagram of a remote MAC swap loopback test
Tester
Ethernet GE1/0/1
Users
SwitchA SwitchB
1. Create a VLAN, configure GE1/0/1 as a trunk interface, and add the interface to the VLAN.
2. Configure remote MAC swap loopback on SwitchB.
3. Enable the MAC swap loopback function on SwitchB.
Data Preparation
l VLAN ID: 100
l Source and destination MAC addresses of test Ethernet frames: 0018-2000-0085 and
0018-2000-0070
l Timeout period of the loopback test: 80s
Procedure
Step 1 Create VLAN 100, configure GE1/0/1 as a trunk interface, and add GE1/0/1 to VLAN 100.
[SwitchB] vlan batch 100
Step 2 Configure remote MAC swap loopback and enable the MAC swap loopback function on
GE1/0/1.
[SwitchB-GigabitEthernet1/0/1] loopback remote swap-mac source-mac 0018-2000-0085
dest-mac 018-2000-0070 vlan 100 timeout 80
[SwitchB-GigabitEthernet1/0/1] loopback swap-mac start

After completing the configuration, run the display loopback swap-mac information
command to verify the configuration. If the configuration is correct, send Ethernet frames from
the tester to test network performance.

[SwitchB] display loopback swap-mac information

Loopback type : remote
Loopback vlan : 100
----End
Configuration Files
#
sysname SwitchB
#
vlan batch 100
#
loopback remote swap-mac source-mac 0018-2000-0085 dest-mac 0018-2000-0070
vlan
100 timeout 80
#
return

S9700 Core Routing Switch 11 Hot Backup and Active/Standby Switchover
Configuration Guide - Reliability Configuration
11 Hot Backup and Active/Standby

Switchover Configuration
About This Chapter
This chapter describes the principle and configuration of hot backup and active/standby
switchover.
11.1 Introduction to Hot Backup and Active/Standby Switchover

This section describes the concepts of hot backup and active/standby switchover.
11.2 Hot Backup and Active/Standby Switchover Features Supported by the S9700
This section describes the hot backup and active/standby switchover features supported by the
S9700.
11.3 Configuring the Slave Main Control Board
This section describes how to configure the slave main control board.
11.4 Performing Active/Standby Switchover
This section describes how to perform active/standby switchover between the two main control
boards.
11.5 Maintaining Active/Standby Switchover
This section describes how to view the backup state of the master and slave main control boards
and debugging active/standby switchover.
This section provides a configuration example of active/standby switchover.

11.1 Introduction to Hot Backup and Active/Standby

Switchover
This section describes the concepts of hot backup and active/standby switchover.
To ensure uninterrupted service provisioning, network devices must have high reliability. High
reliability of the communications equipment means a low probability of service interruption
caused by the fault of the equipment itself.
In theory, to reduce the probability of service interruption to 0, you must have the software and
hardware designed without any flaw, which is impossible in reality.
Therefore, in addition to upgrading the quality of the software and hardware, you need to adopt
the backup mode to improve the reliability of the communications equipment.
For the critical node in a communications system, multiple units of the same function are
provided so that these units can take over the work of each other in the case of faults. This is
called backup mode. Among the multiple units, some are in active mode and are responsible for
the normal running of the node, whereas others are in standby mode. When the active units fail,
they are automatically replaced by the standby units immediately, which ensures normal
operation of the communications system.
Table 11-1 lists common backup modes.
Table 11-1 Common backup modes
Backup Mode Description
1:1 backup In 1:1 backup mode, two units are used. One is the active unit, and the
other is the standby unit. The standby unit backs up configurations of
the active unit and certain dynamic information. If the active unit fails,
the standby replaces the active unit immediately, which ensures normal
operations.
Load balancing In load balancing mode, multiple units share the load of the system. If
one of the units fails, the other units take over its service to ensure normal
operation.
1+1 backup In 1+1 backup mode, both the two units function at the same time. If one
of the units fails, services on this unit are switched to the other unit, and
the other unit is able to support the normal operation of the entire system.
1+1 backup can be considered as a special mode of load balancing.
11.2 Hot Backup and Active/Standby Switchover Features

Supported by the S9700
This section describes the hot backup and active/standby switchover features supported by the
S9700.

Backup Modes of the Hardware

Key hardware units of the S9700 such as the main control boards, Central Management Unit
(CMUs), power modules, and fans adopt the backup mode to ensure high reliability. Table
11-2 describes backup modes of the hardware.
Table 11-2 Backup modes of the hardware

Hardware Description
Main control The S9700 uses two main control boards. When the master main control
board board fails, the slave main control board substitutes for master main control
board to ensure normal operation.
CMU The S9700 uses two CMUs. When the master CMU fails, the slave CMU
substitutes for master CMU to ensure normal monitoring function of the
S9700.
Fan frame Multiple fans can be installed on the S9700. When a fan fails, other fans
adjust their rotation speed to ensure good heat dissipation on the S9700.
Power module Multiple power modules can be installed on the S9700. For more information
about Power module, refer to Configuration and Operation Modes of Power
Supplies.
High reliability of the main control boards is realized through hot backup and active/standby
switchover.
Hot Backup of the Main Control Boards

In backup mode, the slave main control board is the mirror of the master main control board.
When the S9700 is running normally, the master main control board synchronizes the
configuration and certain dynamic information to the slave main control board. In this manner,
when the slave main control board substitutes the master main control board, services on the
S9700 can be restored immediately.
Hot backup is implemented on the S9700 as follows:
If the master and slave main control boards use the same software version, the slave main control
board turns to hot backup state after startup.
When the slave main control board works in hot backup state, it does not process services or run
commands. The master main control board backs up configuration information and certain
dynamic information to the slave main control board in real time. When switchover is triggered,
the slave main control board can replace the master main control board immediately to prevent
service interruption.
When saving the configuration file, the S9700 synchronizes the configuration file of the master
main control board to the slave main control board so that the main control boards use the same
configuration file.

Conditions of Active/Standby Switchover

NOTE
Before performing an active/standby switchover, ensure that the two main control boards have the same
configuration. If their configurations are different, the active/standby switchover will fail. If one main
control board has an FSU installed but the other one has no FSU installed, the active/standby switchover
will also fail.
Active/standby switchover can be performed only when the slave main control board is in real-time backup
state.
In the following situations, the active/standby switchover is performed on the S9700:
l The master main control board is removed when the S9700 is running.
l The operator runs the switchover command.
l The master main control board fails.
In any of the preceding situations, active/standby switchover is triggered on the S9700. Services
can be switched to the slave main control board smoothly.
11.3 Configuring the Slave Main Control Board

This section describes how to configure the slave main control board.
After the S9700 starts, the main control board in the specified slot becomes the slave main control
board, and the other main control board automatically becomes the master main control board.
When two main control boards are installed, you can perform this configuration task after
upgrading the system software of the slave main control board. In this manner, you can make
the system software of the slave main control board take effect without affecting services on the
S9700.
None.
Data Preparation
To configure the slave main control board, you need the following data.
No. Data
1 Slot ID of the slave main control board

11.3.2 (Optional) Specifying the Slot ID of the Slave Main Control

Board
Procedure
Step 1 Run:
system-view
Step 2 Run:
slave default slot-id
The slot ID of the slave main control board is specified.
By default, the main control board with the smaller slot ID is the master one, and the one with
the larger slot ID is the slave one. The default master and slave main control boards of the
S9700 series are as follows:
l The master main control board of the is in slot 4, and the slave main control board is in slot
5.
8.
14.
----End
11.3.3 Resetting the Slave Main Control Board
Procedure
Step 1 Run:
system-view
Step 2 Run:
slave restart
The slave main control board is reset.
NOTE
The slave restart command may interrupt services on the device. Therefore, exercise caution when using this
command.
----End

Procedure
Step 1 Run the display slave default command to view the slot ID of the slave main control board used
after the next startup.
----End
Example
Run the display slave default command, and you can find that the slave main control board
used after the next startup is in slot 4.
<Quidway> display slave default
Info: Default slave slot is 4.
11.4 Performing Active/Standby Switchover

This section describes how to perform active/standby switchover between the two main control
boards.
When two main control boards are installed on the S9700, you can perform active/standby
switchover manually.
Before performing active/standby switchover, complete the following task:
l Ensuring that the slave main control board is in real-time backup mode
Data Preparation
None.
11.4.2 Enabling Active/Standby Switchover
Procedure
Step 1 Run:
system-view
Step 2 Run:
slave switchover enable
Active/standby switchover is enabled.
By default, the active/standby switchover is enabled.

You can perform the following task only when the active/standby switchover is enabled: 11.4.3
Performing Active/Standby Switchover
----End
11.4.3 Performing Active/Standby Switchover
Context
NOTE
Do not perform active/standby switchover in the following situations:

l The file system of the S9700 is in use. For example, you are creating, deleting, saving, or moving the files
or directories in the CF memory.
l The S9700 is loading or deleting information about the LPU because:
l The LPU is removed or inserted when the S9700 is running.
l You run the reset command to reset the LPU.
Active/standby switchover can be performed only when the slave main control board is in real-
time backup state. You can run the display switchover state command to view the hot backup
state of the slave main control board. If the slave main control board is in real-time backup state,
the following information is displayed:
Slave MPU: Receiving realtime and routine data.
During the switchover on the S9700, do not remove, install, or reset the master and slave main
control boards, LPUs, power modules, or fan frames. Otherwise, the S9700 restarts or fails.
Procedure
Step 1 Run:
system-view
Step 2 Run:
slave switchover
Active/standby switchover is performed.
NOTE
The slave switchover command may interrupt services on the device. Therefore, exercise caution when using
this command.
----End
Follow-up Procedure
After switchover, the master main control board is restarted and then enters the standby state;
the slave main control board enters the active state.

Procedure
Step 1 Run the display switchover state command to check the backup state of the active and standby
main control boards.
----End
Example
Run the display switchover state command, and you can view the backup state of the master
and slave main control boards.
<Quidway> display switchover state
Slot 4 HA FSM State(master): realtime or routine backup.
Slot 5 HA FSM State(slave): receiving realtime or routine data.
11.5 Maintaining Active/Standby Switchover

This section describes how to view the backup state of the master and slave main control boards
and debugging active/standby switchover.
11.5.1 Viewing the Status of the Master and Slave Main Control
Boards
Procedure
Step 1 Run the display device command to check the status of the master and slave main control board.
----End
Example
Run the display device command, and you can view the status of the master and slave main
control board.
<Quidway>display device
S9303's Device status:
Slot Sub Type Online Power Register Alarm Primary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 - G24CA Present PowerOn Registered Normal NA
2 - G24CA Present PowerOn Registered Normal NA
3 - G48SD Present PowerOn Registered Normal NA
4 - MCUA Present PowerOn Registered Normal Master
5 - MCUA Present PowerOn Registered Normal Slave
PWR1 - - Present PowerOn Registered Normal NA
11.5.2 Debugging Active/Standby Switchover

Context
CAUTION
Debugging affects the performance of the system. So, after debugging, run the undo debugging
When a fault occurs during hot backup or active/standby switchover, run the following
debugging command in the user view to locate the fault.
Procedure
Step 1 Run the debugging ha { all | message | resendipc | state } command to enable debugging of
hot backup and active/standby switchover.
----End

This section provides a configuration example of active/standby switchover.
11.6.1 Example for Configuring Hot Backup and Active/Standby

Switchover
During routine maintenance, for example, when you need to replace the main control board, you
can perform active/standby switchover on the S9700 to minimize the impact on services.
1. Run the slave switchover command to make the slave main control board active.
Data Preparation
l Slot IDs of the master and slave main control board In this example, the master main control
board is in slot 4, and the slave main control board is in slot 5.
Procedure
Step 1 Enable active/standby switchover.
[Quidway] slave switchover enable
Step 2 Perform active/standby switchover.

Run the slave switchover command when the slave main control board is in real-time backup
state. Then the slave main control board becomes active, and the master main control board is
restarted.
[Quidway] slave switchover
[Quidway] Warning: This operation will switch the slave board to the master board.
Continue?[Y/N]:
Step 3 Check the hot backup state of the master main control board.
[Quidway] display switchover state
Slot 4 HA FSM State(slave): receiving realtime and routine data.
As shown in the preceding output, the master main control board is in real-time backup state,
indicating that the active/standby switchover is successful. You can replace the main control
board if necessary.
----End
Configuration Files
None.


Configuration Guide - Reliability (V200R001C00 - 01) PDF

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

Configuration Guide - Reliability (V200R001C00 - 01) PDF

Uploaded by

Copyright:

Available Formats

S9700 Core Routing Switch

Configuration Guide - Reliability

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2012-03-15) Huawei Proprietary and Confidential i

About This Document

This document describes how to configure the reliability.

This document is intended for:

l Data configuration engineers

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

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

Indicates a potentially hazardous situation, which if not

NOTE Provides additional information to emphasize or supplement

Issue 01 (2012-03-15) Huawei Proprietary and Confidential ii

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

# A line starting with the # sign is comments.

Changes in Issue 01 (2012-03-15)

Issue 01 (2012-03-15) Huawei Proprietary and Confidential iii

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

2 Smart Link and Monitor Link Configuration........................................................................15

Issue 01 (2012-03-15) Huawei Proprietary and Confidential iv

3 ERPS (G.8032) Configuration....................................................................................................53

Issue 01 (2012-03-15) Huawei Proprietary and Confidential v

4.1 Overview of RRPP...........................................................................................................................................78

5 Ethernet OAM Configuration.................................................................................................211

Issue 01 (2012-03-15) Huawei Proprietary and Confidential vi

5.1 Introduction to Ethernet OAM.......................................................................................................................213

Issue 01 (2012-03-15) Huawei Proprietary and Confidential vii

5.9.6 Creating a MEP.....................................................................................................................................245

Issue 01 (2012-03-15) Huawei Proprietary and Confidential viii

5.18.3 Associating Ethernet OAM with BFD.................................................................................................275

6 ITU-T Recommendation Y.1731 Configuration...................................................................356

Issue 01 (2012-03-15) Huawei Proprietary and Confidential ix

Issue 01 (2012-03-15) Huawei Proprietary and Confidential x

7.10.1 Establishing the Configuration Task...................................................................................................412

8 VRRP and VRRP6 Configuration...........................................................................................451

Issue 01 (2012-03-15) Huawei Proprietary and Confidential xi

8.5.3 Associating a VRRP Backup Group with an NQA Test Instance.........................................................469

9 Collection of Configuration Examples of Association.......................................................516

Issue 01 (2012-03-15) Huawei Proprietary and Confidential xii

10.3.1 Establishing the Configuration Task...................................................................................................519

11 Hot Backup and Active/Standby Switchover Configuration..........................................531

Issue 01 (2012-03-15) Huawei Proprietary and Confidential xiii

About This Chapter

1.1 Introduction to DLDP

Issue 01 (2012-03-15) Huawei Proprietary and Confidential 1

1.1 Introduction to DLDP

Figure 1-1 Crossed connection of fibers

Figure 1-2 Disconnection of one fiber

Issue 01 (2012-03-15) Huawei Proprietary and Confidential 2

1.2 Configuring DLDP Functions

1.2.1 Establishing the Configuration Task

1 Type and number of each interface

2 (Optional)Name of the interface group

3 (Optional) Interval for sending Advertisement packets

4 (Optional) Value of the Delay Down timer