NE40E&80E V600R008C10 Configuration Guide - MPLS 01 PDF

HUAWEI NetEngine80E/40E Router
V600R008C10
Configuration Guide - MPLS
Issue 02
Date 2014-09-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2014. 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 a 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 02 (2014-09-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Configuration Guide - MPLS About This Document
About This Document
Purpose
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the MPLS feature supported by the NE80E/40E.
NOTICE
Note the following precautions:
l The encryption algorithms DES/3DES/SKIPJACK/RC2/RSA (RSA-1024 or lower)/MD2/
MD4/MD5 (in digital signature scenarios and password encryption)/SHA1 (in digital
signature scenarios) have a low security, which may bring security risks. If protocols allowed,
using more secure encryption algorithms, such as AES/RSA (RSA-2048 or higher)/SHA2/
HMAC-SHA2, is recommended.
l If the plain parameter is specified, the password will be saved in plaintext in the configuration
file, which has a high security risk. Therefore, specifying the cipher parameter is
recommended. To further improve device security, periodically change the password.
l Do not set both the start and end characters of a password to "%$%$." This causes the
password to be displayed directly in the configuration file.
Related Versions
The following table lists the product versions related to this document.
Product Name Version
HUAWEI NetEngine80E/40E V600R008C10

Router
Intended Audience
This document is intended for:
Issue 02 (2014-09-30) Huawei Proprietary and Confidential ii

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 an imminently hazardous situation which, if not

avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
Calls attention to important information, best practices and

tips.
NOTE is used to address information not related to personal
injury, equipment damage, and environment deterioration.
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.
Issue 02 (2014-09-30) Huawei Proprietary and Confidential iii

Convention Description
[ 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
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Changes in Issue 02 (2014-09-30)

This issue is the second official release.
Changes in Issue 01 (2014-06-30)

This issue is the first official release.
Issue 02 (2014-09-30) Huawei Proprietary and Confidential iv

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

1 Static LSPs Configuration............................................................................................................1
1.1 Introduction....................................................................................................................................................................2
1.1.1 Overview.....................................................................................................................................................................2
1.1.2 Static LSP Features Supported by the NE80E/40E.....................................................................................................2
1.2 Configuring Static LSPs.................................................................................................................................................2
1.2.1 Before You Start..........................................................................................................................................................2
1.2.2 Configuring the LSR ID..............................................................................................................................................3
1.2.3 Enabling MPLS...........................................................................................................................................................4
1.2.4 Configuring the Ingress for a Static LSP.....................................................................................................................5
1.2.5 Configuring the Transit Node for a Static LSP...........................................................................................................5
1.2.6 Configuring the Egress for a Static LSP......................................................................................................................6
1.2.7 Checking the Configurations.......................................................................................................................................6
1.3 Configuring Static BFD for Static LSP..........................................................................................................................7
1.3.1 Before You Start..........................................................................................................................................................7
1.3.2 Enabling Global BFD Capability................................................................................................................................8
1.3.3 Configuring BFD with Specific Parameters on Ingress..............................................................................................8
1.3.4 Configuring BFD with Specific Parameters on Egress.............................................................................................10
1.3.5 Checking the Configurations.....................................................................................................................................12
1.4 Maintaining Static LSPs...............................................................................................................................................12
1.4.1 Checking the LSP Connectivity and Reachability....................................................................................................12
1.4.2 Enabling the LSP Trap Function...............................................................................................................................13
1.5 Configuration Examples...............................................................................................................................................13
1.5.1 Example for Configuring Static LSPs.......................................................................................................................13
1.5.2 Example for Configuring Static BFD for Static LSP................................................................................................21
2 MPLS LDP Configuration..........................................................................................................29

2.1 MPLS LDP Overview..................................................................................................................................................32
2.1.1 Introduction to MPLS LDP.......................................................................................................................................32
2.1.2 MPLS LDP Features Supported by the NE80E/40E.................................................................................................33
2.2 Configuring a Local LDP Session................................................................................................................................35
2.2.1 Before You Start........................................................................................................................................................35
2.2.2 Configuring Global LDP...........................................................................................................................................36
Issue 02 (2014-09-30) Huawei Proprietary and Confidential v

2.2.3 (Optional) Configuring the Dynamic LDP Advertisement Capability......................................................................37

2.2.4 (Optional) Enabling LDP Loop Detection Negotiation.............................................................................................38
2.2.5 Configuring a Local LDP Session.............................................................................................................................39
2.2.6 (Optional) Configuring an LDP Transport Address..................................................................................................40
2.2.7 (Optional) Configuring Timers for a Local LDP Session.........................................................................................41
2.3 Configuring a Remote LDP Session.............................................................................................................................47
2.3.1 Before You Start........................................................................................................................................................47
2.3.2 Configuring Global LDP...........................................................................................................................................48
2.3.3 (Optional) Configuring the Dynamic LDP Advertisement Capability......................................................................49
2.3.4 (Optional) Enabling LDP Loop Detection Negotiation.............................................................................................50
2.3.5 Configuring a Remote LDP Session..........................................................................................................................51
2.3.6 (Optional) Disabling a Device from Distributing Labels to Remote Peers...............................................................52
2.3.7 (Optional) Configuring Timers for a Remote LDP Session......................................................................................53
2.4 Configuring LDP LSPs.................................................................................................................................................59
2.4.1 Before You Start........................................................................................................................................................60
2.4.2 Establishing LDP LSPs.............................................................................................................................................60
2.4.3 (Optional) Configuring PHP......................................................................................................................................61
2.4.4 (Optional) Configuring an LDP Label Advertisement Mode....................................................................................62
2.4.5 (Optional) Configuring LDP to Automatically Trigger the Request in DoD Mode..................................................63
2.4.6 Configuring an MPLS MTU on an Interface.............................................................................................................64
2.4.7 (Optional) Configuring LDP MTU Signaling...........................................................................................................65
2.4.8 (Optional) Configuring an LDP Split Horizon Policy...............................................................................................66
2.4.9 (Optional) Configuring the Inbound and Outbound LDP Policies............................................................................67
2.4.10 (Optional) Configuring a Policy for Triggering LDP LSP Establishment..............................................................69
2.4.11 (Optional) Configuring a Policy for Triggering Transit LSP Establishment..........................................................70
2.4.12 Checking the Configurations...................................................................................................................................71
2.5 Configuring LDP Extension for Inter-Area LSP..........................................................................................................72
2.5.1 Before You Start........................................................................................................................................................72
2.5.2 Configuring LDP Extension for Inter-Area LSPs.....................................................................................................73
2.6 Configuring the LDP Multi-Instance............................................................................................................................74
2.6.1 Before You Start........................................................................................................................................................74
2.6.2 Configuring the LDP Multi-Instance.........................................................................................................................75
2.7 Configuring a Node to Report LSP Fault Locations and Causes to the Ingress...........................................................76
2.8 Configuring an Automatic mLDP P2MP Tunnel.........................................................................................................78
2.8.1 Before You Start........................................................................................................................................................78
2.8.2 Enabling mLDP P2MP Globally...............................................................................................................................79
2.8.3 (Optional) Enabling the mLDP Make-Before-Break Capability...............................................................................79
Issue 02 (2014-09-30) Huawei Proprietary and Confidential vi

2.8.4 (Optional) Disabling mLDP P2MP on an Interface..................................................................................................80

2.9 Configuring LDP over TE............................................................................................................................................83
2.9.1 Before You Start........................................................................................................................................................83
2.9.2 Configuring Forwarding Adjacency..........................................................................................................................83
2.9.3 Establishing LDP Remote Peers on the Two Ends of the TE Tunnel.......................................................................84
2.9.4 Configuring a Method to Direct LDP Traffic to a TE Tunnel...................................................................................85
2.9.5 (Optional) Configuring the Policy for Triggering the Establishment of an LSP.......................................................86
2.10 Configuring Static BFD for LDP LSP........................................................................................................................86
2.10.1 Before You Start......................................................................................................................................................87
2.10.2 Enabling Global BFD Capability............................................................................................................................87
2.10.3 Configuring BFD Parameters on the Ingress...........................................................................................................88
2.10.4 Configuring BFD Parameters on the Egress............................................................................................................90
2.11 Configuring Dynamic BFD for LDP LSP..................................................................................................................92
2.11.1 Before You Start......................................................................................................................................................92
2.11.2 Enabling Global BFD Capability............................................................................................................................93
2.11.3 Enabling MPLS to Establish BFD Session Dynamically........................................................................................93
2.11.4 Configuring the Policy for Triggering Dynamic BFD for LDP LSP......................................................................94
2.11.5 (Optional) Adjusting BFD Parameters....................................................................................................................95
2.12 Configuring Dynamic BFD to Monitor an LDP Tunnel............................................................................................98
2.12.1 Before You Start......................................................................................................................................................98
2.12.2 Enabling an MPLS Device to Dynamically Establish a BFD Session....................................................................99
2.12.3 Configuring a Policy for Triggering Dynamic BFD for LDP Tunnel...................................................................100
2.12.4 (Optional) Adjusting BFD Parameters..................................................................................................................101
2.12.5 Checking the Configurations.................................................................................................................................102
2.13 Configuring Manual LDP FRR................................................................................................................................103
2.13.1 Before You Start....................................................................................................................................................103
2.13.2 Enabling Manual LDP FRR..................................................................................................................................104
2.13.3 (Optional) Allowing BFD to Modify the PST.......................................................................................................105
2.13.4 (Optional) Configuring LDP Graceful Deletion....................................................................................................105
2.14 Configuring LDP Auto FRR.....................................................................................................................................107
2.14.1 Before You Start....................................................................................................................................................107
2.14.2 Enabling LDP Auto FRR.......................................................................................................................................108
2.15 Configuring Synchronization Between LDP and IGP..............................................................................................110
2.15.1 Before You Start....................................................................................................................................................111
Issue 02 (2014-09-30) Huawei Proprietary and Confidential vii

2.15.2 Enabling Synchronization Between LDP and IGP................................................................................................112

2.15.3 (Optional) Blocking Synchronization Between LDP and IS-IS on an Interface...................................................113
2.15.4 (Optional) Setting the Hold-down Timer Value....................................................................................................114
2.15.5 (Optional) Setting the Hold-max-cost Timer Value..............................................................................................115
2.15.6 (Optional) Setting the Delay Timer Value............................................................................................................117
2.16 Configuring Synchronization Between LDP and Static Routes...............................................................................120
2.16.1 Before You Start....................................................................................................................................................120
2.16.2 Enabling Synchronization Between LDP and Static Routes.................................................................................121
2.16.3 (Optional) Setting a Hold-down Timer.................................................................................................................122
2.17 Configuring LDP Security Features.........................................................................................................................123
2.17.1 Before You Start....................................................................................................................................................124
2.17.2 Configuring LDP MD5 Authentication.................................................................................................................125
2.17.3 Configuring LDP Keychain Authentication..........................................................................................................126
2.17.4 Configuring the LDP GTSM.................................................................................................................................127
2.18 Configuring LDP GR................................................................................................................................................129
2.18.1 Before You Start....................................................................................................................................................129
2.18.2 Enabling LDP GR..................................................................................................................................................130
2.18.3 (Optional) Configuring GR Restarter Timer.........................................................................................................131
2.18.4 (Optional) Configuring GR Helper Timers...........................................................................................................131
2.19 Maintaining MPLS LDP...........................................................................................................................................133
2.19.1 Resetting LDP........................................................................................................................................................134
2.19.2 Checking the LSP Connectivity and Reachability................................................................................................134
2.19.3 Enabling the Trap Function on the LSP................................................................................................................135
2.19.4 Configuring a Policy for Triggering an LDP Session Status Alarm.....................................................................135
2.20 Configuration Examples...........................................................................................................................................136
2.20.1 Example for Configuring Local LDP Sessions.....................................................................................................136
2.20.2 Example for Configuring a Remote LDP Session.................................................................................................140
2.20.3 Example for Using LDP to Establish LSPs...........................................................................................................144
2.20.4 Example for Disabling Devices from Distributing LDP Labels to Remote Peers................................................148
2.20.5 Example for Configuring LDP over TE................................................................................................................159
2.20.6 Example for Configuring LDP Graceful Deletion.................................................................................................168
2.20.7 Example for Configuring an Inbound LDP Policy................................................................................................177
2.20.8 Example for Configuring an Outbound LDP Policy.............................................................................................181
2.20.9 Example for Configuring Transit LSPs Based on an IP Prefix List......................................................................186
2.20.10 Example for Configuring LDP to Automatically Send DoD Requests...............................................................192
2.20.11 Example for Configuring LDP Auto FRR...........................................................................................................199
Issue 02 (2014-09-30) Huawei Proprietary and Confidential viii

2.20.12 Example for Configuring LDP Authentication...................................................................................................208

2.20.13 Example for Configuring the LDP GTSM..........................................................................................................215
2.20.14 Example for Configuring LDP Extension for Inter-Area LSPs..........................................................................218
2.20.15 Example for Configuring Static BFD for LDP LSP............................................................................................224
2.20.16 Example for Configuring Dynamic BFD for LDP LSP......................................................................................231
2.20.17 Example for Configuring Dynamic BFD to Monitor an LDP Tunnel................................................................235
2.20.18 Example for Configuring Manual LDP FRR......................................................................................................241
2.20.19 Example for Configuring Synchronization Between LDP and IGP....................................................................247
2.20.20 Example for Configuring Synchronization Between LDP and Static Routes.....................................................253
2.20.21 Example for Configuring LDP GR......................................................................................................................259
2.20.22 Example for Configuring LDP over GRE...........................................................................................................264
3 MPLS TE Configuration...........................................................................................................270
3.1 Introduction................................................................................................................................................................273
3.1.1 MPLS TE Overview................................................................................................................................................273
3.1.2 MPLS TE Features Supported by the NE80E/40E..................................................................................................273
3.2 Configuring Static CR-LSP........................................................................................................................................278
3.2.1 Before You Start......................................................................................................................................................278
3.2.2 Enabling MPLS TE.................................................................................................................................................279
3.2.3 (Optional) Configuring Link Bandwidth.................................................................................................................280
3.2.4 Configuring the MPLS TE Tunnel Interface...........................................................................................................281
3.2.5 Configuring the Ingress of the Static CR-LSP........................................................................................................282
3.2.6 Configuring the Transit of the Static CR-LSP.........................................................................................................283
3.2.7 Configuring the Egress of the Static CR-LSP.........................................................................................................284
3.3 Configuring a Static Bidirectional Co-routed CR-LSP..............................................................................................285
3.3.1 Before You Start......................................................................................................................................................285
3.3.2 Enabling MPLS TE.................................................................................................................................................286
3.4 Configuring the Statistics Function for a Static Bidirectional Co-routed CR-LSP....................................................288
3.5 Configuring an RSVP-TE Tunnel..............................................................................................................................290
3.5.1 Before You Start......................................................................................................................................................290
3.5.2 Enabling MPLS TE and RSVP-TE.........................................................................................................................291
3.5.4 Configuring OSPF TE.............................................................................................................................................293
3.5.5 Configuring IS-IS TE..............................................................................................................................................294
3.5.6 (Optional) Configuring an MPLS TE Explicit Path................................................................................................295
3.5.7 Configuring an MPLS TE Tunnel Interface............................................................................................................297
3.5.8 (Optional) Configuring Tunnel Constraints............................................................................................................298
3.5.9 (Optional) Configuring an RSVP Resource Reservation Style...............................................................................299
3.5.10 Configuring CSPF.................................................................................................................................................300
Issue 02 (2014-09-30) Huawei Proprietary and Confidential ix

3.6 Configuring Dynamic Bandwidth Reservation..........................................................................................................303

3.6.1 Before You Start......................................................................................................................................................303
3.6.2 Setting the Proportion of the Maximum Reservable Bandwidth to the Physical Bandwidth of an Interface.........304
3.6.3 Setting the Proportion of the Bandwidth in Each BC Pool to the Maximum Reservable Bandwidth....................305
3.7 Configuring a Tunnel Protection Group.....................................................................................................................306
3.7.1 Before You Start......................................................................................................................................................307
3.7.2 Creating a Tunnel Protection Group........................................................................................................................308
3.7.3 (Optional) Configuring Dynamic BFD to Monitor CR-LSPs.................................................................................310
3.7.4 (Optional) Enabling MPLS OAM to Detect Bidirectional LSPs............................................................................311
3.7.5 (Optional) Configuring the Protection Switching Trigger Mechanism...................................................................312
3.8 Referencing the CR-LSP Attribute Template to Set Up a CR-LSP...........................................................................314
3.8.1 Before You Start......................................................................................................................................................314
3.8.2 Configuring a CR-LSP Attribute Template.............................................................................................................315
3.8.3 Setting Up a CR-LSP by Using a CR-LSP Attribute Template..............................................................................317
3.9 Configuring an Associated Bidirectional Dynamic LSP............................................................................................319
3.9.1 Before You Start......................................................................................................................................................319
3.9.2 Configuring an Associated Bidirectional Dynamic LSP.........................................................................................320
3.10 Adjusting RSVP Signaling Parameters....................................................................................................................322
3.10.1 Before You Start....................................................................................................................................................322
3.10.2 Configuring RSVP Hello Extension......................................................................................................................322
3.10.3 Configuring RSVP Timers....................................................................................................................................323
3.10.4 Configuring RSVP Refresh Mechanism................................................................................................................324
3.10.5 Enabling Reservation Confirmation Mechanism..................................................................................................325
3.10.6 Configuring the RSVP Message Format...............................................................................................................326
3.11 Configuring RSVP Authentication...........................................................................................................................328
3.11.1 Before You Start....................................................................................................................................................328
3.11.2 Configuring RSVP Key Authentication................................................................................................................329
3.11.3 (Optional) Configuring the RSVP Authentication Lifetime..................................................................................331
3.11.4 (Optional) Configuring the Handshake Function..................................................................................................332
3.11.5 (Optional) Configuring the Message Window Function.......................................................................................333
3.12 Adjusting the Path of CR-LSP..................................................................................................................................335
3.12.1 Before You Start....................................................................................................................................................335
3.12.2 Configuring Administrative Group and Affinity Property....................................................................................337
3.12.3 Configuring SRLG................................................................................................................................................338
3.12.4 Configuring CR-LSP Hop Limit...........................................................................................................................339
Issue 02 (2014-09-30) Huawei Proprietary and Confidential x

3.12.5 Configuring Metrics for Path Calculation.............................................................................................................340

3.12.6 Configuring Tie-Breaking of CSPF.......................................................................................................................341
3.12.7 Configuring Failed Link Timer.............................................................................................................................342
3.12.8 Configuring Loop Detection..................................................................................................................................343
3.12.9 Configuring Route Pinning....................................................................................................................................344
3.12.10 Configuring Isolated LSP Computation..............................................................................................................345
3.12.11 Checking the Configurations...............................................................................................................................346
3.13 Adjusting the Establishment of MPLS TE Tunnels.................................................................................................347
3.13.1 Before You Start....................................................................................................................................................347
3.13.2 Configuring the Tunnel Priority............................................................................................................................347
3.13.3 Configuring Re-optimization for CR-LSP............................................................................................................348
3.13.4 Associating CR-LSP Establishment with the Overload Setting............................................................................350
3.13.5 Configuring Tunnel Reestablishment Parameters.................................................................................................351
3.13.6 Configuring Route Record and Label Record.......................................................................................................352
3.13.7 Configuring the RSVP Signaling Delay-Trigger Function...................................................................................352
3.14 Importing Traffic to an MPLS TE Tunnel................................................................................................................353
3.14.1 Before You Start....................................................................................................................................................353
3.14.2 Configuring IGP Shortcut......................................................................................................................................354
3.14.3 Configuring Forwarding Adjacency......................................................................................................................356
3.14.4 Configuring Switching Delay and Deletion Delay................................................................................................357
3.15 Adjusting Flooding Threshold of Bandwidth Change..............................................................................................359
3.15.1 Before You Start....................................................................................................................................................359
3.15.2 Configuring Flooding Threshold...........................................................................................................................360
3.16 Configuring Automatic Adjustment of the Tunnel Bandwidth................................................................................361
3.16.1 Before You Start....................................................................................................................................................361
3.16.2 Configuring Auto Bandwidth Adjustment............................................................................................................362
3.17 Configuring the Limit Rate of MPLS TE Traffic.....................................................................................................364
3.17.1 Before You Start....................................................................................................................................................364
3.17.2 Configuring the Limit Rate of MPLS TE Traffic..................................................................................................365
3.18 Configuring DS-TE Tunnel......................................................................................................................................366
3.18.1 Before You Start....................................................................................................................................................366
3.18.2 Configuring DS-TE Mode.....................................................................................................................................367
3.18.3 Configuring DS-TE Bandwidth Constraints Model..............................................................................................369
3.18.4 (Optional) Configuring TE-Class Mapping Table.................................................................................................369
3.18.5 Configuring Link Bandwidth.................................................................................................................................371
3.18.6 Configuring the Tunnel Interface..........................................................................................................................372
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xi

3.18.7 Configuring the Static CR-LSP and the Bandwidth..............................................................................................374

3.18.8 Configuring the RSVP CR-LSP and Its Bandwidth..............................................................................................375
3.18.9 Configuring Mappings Between CTs and Flow Queues.......................................................................................377
3.18.10 (Optional) Configuring the Interface Class Queue..............................................................................................379
3.18.11 Checking the Configurations...............................................................................................................................380
3.19 Configuring TE Manual FRR...................................................................................................................................381
3.19.1 Before You Start....................................................................................................................................................381
3.19.2 Enabling TE FRR..................................................................................................................................................383
3.19.3 Configuring a Bypass Tunnel................................................................................................................................383
3.19.4 (Optional) Configuring a TE FRR Scanning Timer..............................................................................................385
3.19.5 (Optional) Changing the PSB and RSB Timeout Multiplier.................................................................................386
3.20 Configuring MPLS TE Auto FRR............................................................................................................................388
3.20.1 Before You Start....................................................................................................................................................388
3.20.2 Enabling TE Auto FRR.........................................................................................................................................389
3.20.3 Enabling TE FRR and Configuring Auto Bypass Tunnel Attributes....................................................................390
3.20.4 (Optional) Configuring the Scanning Timer for FRR...........................................................................................391
3.20.5 (Optional) Modifying PSB and RSB Timeout Multiplier.....................................................................................391
3.20.6 (Optional) Configuring Auto Bypass Tunnel Re-Optimization............................................................................392
3.21 Configuring CR-LSP Backup...................................................................................................................................394
3.21.1 Before You Start....................................................................................................................................................394
3.21.2 Configuring CR-LSP Backup................................................................................................................................397
3.21.3 (Optional) Configuring Forcible Switchover........................................................................................................398
3.21.4 (Optional) Locking a Backup CR-LSP Attribute Template..................................................................................399
3.21.5 (Optional) Configuring Dynamic Bandwidth for Hot-Standby CR-LSPs.............................................................400
3.21.6 (Optional) Configuring a Best-Effort Path............................................................................................................402
3.22 Configuring Synchronization of the Bypass Tunnel and the Backup CR-LSP........................................................404
3.22.1 Before You Start....................................................................................................................................................404
3.22.2 Enabling Synchronization of the Bypass Tunnel and the Backup CR-LSP..........................................................405
3.23 Configuring RSVP GR.............................................................................................................................................406
3.23.1 Before You Start....................................................................................................................................................406
3.23.2 Enabling the RSVP Hello Extension Function......................................................................................................407
3.23.3 Enabling Full GR of RSVP...................................................................................................................................408
3.23.4 (Optional) Enabling the RSVP GR Support Function...........................................................................................409
3.23.5 (Optional) Configuring Hello Sessions Between RSVP GR Nodes......................................................................409
3.23.6 (Optional) Modifying Basic Time.........................................................................................................................410
3.24 Configuring Static BFD for CR-LSP........................................................................................................................412
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xii

3.24.1 Before You Start....................................................................................................................................................412

3.24.2 Enabling BFD Globally.........................................................................................................................................413
3.24.3 Configuring BFD Parameters on the Ingress of the Tunnel..................................................................................413
3.24.4 Configuring BFD Parameters on the Egress of the Tunnel...................................................................................416
3.25 Configuring Static BFD for TE................................................................................................................................419
3.25.1 Before You Start....................................................................................................................................................419
3.25.3 Configuring BFD Parameters on the Ingress of the Tunnel..................................................................................420
3.25.4 Configuring BFD Parameters on the Egress of the Tunnel...................................................................................422
3.26 Configuring Dynamic BFD for CR-LSP..................................................................................................................426
3.26.1 Before You Start....................................................................................................................................................426
3.26.3 Enabling the Capability of Dynamically Creating BFD Sessions on the Ingress.................................................427
3.26.4 Enabling the Capability of Passively Creating BFD Sessions on the Egress........................................................429
3.27 Configuring Dynamic BFD for RSVP......................................................................................................................431
3.27.1 Before You Start....................................................................................................................................................431
3.27.3 Enabling BFD for RSVP.......................................................................................................................................433
3.28 Configuring an Automatic P2MP TE Tunnel...........................................................................................................436
3.28.1 Before You Start....................................................................................................................................................436
3.28.2 Enabling P2MP TE Globally.................................................................................................................................437
3.28.3 (Optional) Disabling P2MP TE on an Interface....................................................................................................438
3.28.4 (Optional) Configuring a Leaf List........................................................................................................................438
3.28.5 Configuring a P2MP Tunnel Template.................................................................................................................440
3.29 Maintaining MPLS TE.............................................................................................................................................444
3.29.1 Checking the Connectivity of the TE Tunnel........................................................................................................444
3.29.2 Checking a TE Tunnel by Using NQA..................................................................................................................444
3.29.3 Checking Information About Tunnel Faults..........................................................................................................445
3.29.4 Clearing the Operation Information......................................................................................................................445
3.29.5 Resetting the Tunnel Interface...............................................................................................................................446
3.29.6 Resetting the RSVP Process..................................................................................................................................446
3.29.7 Deleting or Resetting the Bypass Tunnel..............................................................................................................446
3.29.8 Enabling the LSP Trap Function...........................................................................................................................447
3.29.9 Configuring Alarm Thresholds for RSVP LSPs....................................................................................................447
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xiii

3.29.10 Configuring Alarm Thresholds for Total CR-LSPs............................................................................................448

3.30 Configuration Examples...........................................................................................................................................449
3.30.1 Example for Establishing a Static MPLS TE Tunnel............................................................................................449
3.30.2 Example for Configuring a Static Bidirectional Co-routed LSP...........................................................................455
3.30.3 Example for Configuring a 1:1 Tunnel Protection Group Over a Bidirectional LSP...........................................461
3.30.4 Example for Configuring an RSVP-TE Tunnel....................................................................................................469
3.30.5 Example for Configuring IGP Shortcut to Import Traffic to an MPLS TE Tunnel..............................................476
3.30.6 Example for Configuring Forwarding Adjacency to Import Traffic to an MPLS TE Tunnel..............................485
3.30.7 Example for Configuring a Tunnel Protection Group...........................................................................................497
3.30.8 Example for Configuring a Tunnel Protection Group Using Dynamic BFD to Detect Faults..............................507
3.30.9 Example for Configuring an Associated Bidirectional Dynamic LSP..................................................................518
3.30.10 Example for Setting Up a CR-LSP by Using the CR-LSP Attribute Template..................................................524
3.30.11 Example for Configuring RSVP Authentication.................................................................................................532
3.30.12 Example for Configuring Tunnel Properties.......................................................................................................537
3.30.13 Example for Configuring SRLG (TE Auto FRR)...............................................................................................550
3.30.14 Example for Configuring SRLG (Hot-standby)..................................................................................................559
3.30.15 Example for Configuring the Limit Rate for TE Tunnel Traffic.........................................................................564
3.30.16 Example for Configuring a DS-TE Tunnel in Non-IETF Mode (MAM)............................................................568
3.30.17 Example for Configuring a DS-TE Tunnel in IETF Mode (RDM).....................................................................583
3.30.18 Example for Switching the Non-IETF Mode to the IETF Mode........................................................................604
3.30.19 Example for Configuring MPLS TE FRR...........................................................................................................611
3.30.20 Example for Configuring MPLS TE Auto FRR..................................................................................................622
3.30.21 Example for Configuring RSVP Key Authentication (RSVP-TE FRR).............................................................629
3.30.22 Example for Configuring RSVP-TE Summary Refresh (RSVP-TE FRR).........................................................637
3.30.23 Example for Configuring Board Removal Protection.........................................................................................644
3.30.24 Example for Configuring CR-LSP Hot Standby.................................................................................................653
3.30.25 Example for Configuring Isolated LSP Computation.........................................................................................660
3.30.26 Example for Locking an Attribute Template for Hot-standby CR-LSPs............................................................669
3.30.27 Example for Configuring the Dynamic Bandwidth Function for a Hot-standby CR-LSP..................................678
3.30.28 Example for Configuring TE FRR and CR-LSP Hot Standby to Implement Combined Protection..................688
3.30.29 Example for Configuring Synchronization of the Bypass Tunnel and the Backup CR-LSP..............................696
3.30.30 Example for Configuring RSVP GR...................................................................................................................702
3.30.31 Example for Configuring Static BFD for CR-LSP..............................................................................................709
3.30.32 Example for Configuring Static BFD for TE......................................................................................................715
3.30.33 Example for Configuring Dynamic BFD for CR-LSP........................................................................................724
3.30.34 Example for Configuring Dynamic BFD for RSVP............................................................................................730
3.30.35 Example for Advertising MPLS LSR IDs to Multiple OSPF Areas...................................................................738
3.30.36 Example for Configuring an Inter-Area Tunnel..................................................................................................743
4 MPLS Common Configuration...............................................................................................753

4.1 Introduction................................................................................................................................................................755
4.1.1 Overview.................................................................................................................................................................755
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xiv

4.1.2 MPLS Common Features Supported by the NE80E/40E........................................................................................755

4.2 Configuring a Mode in Which MPLS Processes the EXP Field................................................................................756
4.3 Configuring the Mode in Which MPLS Handles the TTL.........................................................................................757
4.3.1 Before You Start......................................................................................................................................................757
4.3.2 Configuring a Mode for Processing TTLs in Packets Transmitted over an MPLS LDP LSP................................758
4.3.3 Configuring a Mode for Processing TTLs in Packets Transmitted over an MPLS TE LSP...................................759
4.3.4 Configuring the Mode in Which MPLS L3VPN Handles the TTL........................................................................760
4.3.5 Configuring the Path for ICMP Reply Messages....................................................................................................761
4.4 Configuring MPLS Load Balancing...........................................................................................................................762
4.4.1 Before You Start......................................................................................................................................................762
4.4.2 Configuring Layer 3 MPLS Forwarding in UCMP Mode......................................................................................763
4.4.3 Configuring Layer 3 MPLS Forwarding in the Label-based Load Balancing Mode..............................................763
4.4.4 Configuring an MPLS Load Balancing Mode.........................................................................................................764
4.5 Configuring Dynamic BFD to Monitor a BGP Tunnel..............................................................................................765
4.5.1 Before You Start......................................................................................................................................................765
4.5.2 Enabling an MPLS Device to Dynamically Establish a BGP BFD Session...........................................................766
4.5.3 Configuring a Policy for Dynamically Establishing a BGP BFD Session..............................................................767
4.5.4 (Optional) Adjusting BGP BFD Parameters...........................................................................................................768
4.6 Optimizing MPLS.......................................................................................................................................................770
4.6.1 Before You Start......................................................................................................................................................770
4.6.2 Configuring PHP.....................................................................................................................................................771
4.6.3 Configuring the MPLS MTU of the Interface.........................................................................................................771
4.7 Maintaining MPLS Common Configuration..............................................................................................................773
4.7.1 Checking the LSP Connectivity and Reachability..................................................................................................773
4.7.2 Configuring Alarm Thresholds for Dynamic Labels...............................................................................................773
4.7.3 Configuring Alarm Thresholds for BGP LSPs........................................................................................................774
4.7.4 Configuring Alarm Thresholds for BGP IPv6 LSPs...............................................................................................775
4.7.5 Configuring Alarm Thresholds for Total LSPs.......................................................................................................776
4.8 Configuration Examples.............................................................................................................................................777
4.8.1 Example for Configuring Load Balancing for MPLS Layer 3 Forwarding............................................................777
4.8.2 Example for Configuring PBR to LSP for Public Network Packets.......................................................................783
4.8.3 Example for Configuring Dynamic BFD to Monitor a BGP Tunnel......................................................................787
5 MPLS OAM Configuration.....................................................................................................796

5.1 Introduction to MPLS OAM.......................................................................................................................................798
5.1.1 MPLS OAM Overview............................................................................................................................................798
5.1.2 MPLS OAM Features Supported by the NE80E/40E.............................................................................................798
5.2 Configuring Basic MPLS OAM Functions of LSP....................................................................................................801
5.2.1 Before You Start......................................................................................................................................................801
5.2.2 Configuring MPLS OAM on the Ingress................................................................................................................802
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xv

5.2.3 Configuring MPLS OAM on the Egress.................................................................................................................804

5.3 Configuring MPLS OAM Protection Switching of LSP............................................................................................806
5.3.1 Before You Start......................................................................................................................................................806
5.3.2 Configuring a Tunnel Protection Group..................................................................................................................808
5.3.3 (Optional) Configuring the Protection Switching Trigger Mechanism...................................................................809
5.3.4 (Optional) Enabling MPLS OAM to Detect Bidirectional LSPs............................................................................810
5.4 Configuring MPLS OAM to Monitor a Static Bidirectional Co-routed LSP.............................................................812
5.4.1 Before You Start......................................................................................................................................................812
5.4.2 Configuring MPLS OAM Parameters.....................................................................................................................813
5.4.3 Enabling MPLS OAM.............................................................................................................................................814
5.5 Setting the Trap Threshold for Bandwidth Consumption in the Fast Packet Transmission Channel........................815
5.6 Configuring MPLS OAM to Monitor PW Connectivity............................................................................................817
5.7 Maintaining MPLS OAM...........................................................................................................................................821
5.7.1 Monitoring the Running of MPLS OAM................................................................................................................821
5.7.2 Monitoring the Running of Protection Group.........................................................................................................821
5.8.1 Example for Configuring MPLS OAM to Detect a Static LSP...............................................................................822
5.8.2 Example for Configuring MPLS OAM to Monitor a Static Bidirectional Co-routed LSP.....................................830
5.8.3 Example for Configuring MPLS OAM Protection Switching................................................................................836
6 Seamless MPLS Configuration...............................................................................................851

6.1 Introduction................................................................................................................................................................852
6.1.1 Overview.................................................................................................................................................................852
6.1.2 Seamless MPLS Networks Supported by the NE80E/40E......................................................................................852
6.2 Configuring Intra-AS Seamless MPLS......................................................................................................................854
6.2.1 Before You Start......................................................................................................................................................854
6.2.2 Configuring an AGG and a Core ABR as RRs.......................................................................................................856
6.2.3 Enabling BGP Peers to Exchange Labeled IPv4 Routes.........................................................................................856
6.2.4 Configuring a BGP LSP..........................................................................................................................................857
6.2.5 (Optional) Configuring the Protection Switching Function....................................................................................859
6.3 Configuring Inter-AS Seamless MPLS......................................................................................................................865
6.3.1 Before You Start......................................................................................................................................................865
6.3.2 Configure an AGG as an RR...................................................................................................................................866
6.3.5 (Optional) Configuring the Mode in Which a BGP Label Inherits the QoS Priority in an Outer Tunnel Label
..........................................................................................................................................................................................870
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xvi


6.4 Configuring Inter-AS Seamless MPLS+HVPN.........................................................................................................877
6.4.1 Before You Start......................................................................................................................................................877
6.4.2 Establishing an MP-EBGP Peer Relationship Between Each AGG and MASG....................................................879
6.4.5 (Optional) Configuring the Mode in Which a BGP Label Inherits the QoS Priority in an Outer Tunnel Label
..........................................................................................................................................................................................883
6.5 Maintaining Seamless MPLS.....................................................................................................................................890
6.5.1 Checking Network Connectivity and Reachability.................................................................................................890
6.6.1 Example for Configuring Intra-AS Seamless MPLS..............................................................................................890
6.6.2 Example for Configuring Inter-AS Seamless MPLS..............................................................................................898
6.6.3 Example for Configuring Inter-AS Seamless MPLS+HVPN.................................................................................907
6.6.4 Example for Configuring Seamless MPLS to Transmit L2VPN Services..............................................................918
A Glossary......................................................................................................................................937
B Acronyms and Abbreviations.................................................................................................943
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xvii

Configuration Guide - MPLS 1 Static LSPs Configuration
1 Static LSPs Configuration
About This Chapter
You can set up a static Label Switched Path (LSP) by manually assigning labels to Label
Switching Routers (LSRs). The static LSP applies stable, small-scale networks.
1.1 Introduction
Labels can be assigned manually to LSRs to establish static LSPs.
1.2 Configuring Static LSPs

A static LSP can be established only after each LSR is manually configured.
1.3 Configuring Static BFD for Static LSP

This section describes how to configure a static BFD session to monitor static LSPs. By
configuring static BFD for static LSPs, you can monitor the connectivity of static LSPs.
1.4 Maintaining Static LSPs

Static LSP maintenance involves deleting MPLS statistics, checking the connectivity or
reachability of an LSP, and configuring the trap function on an LDP LSP.
1.5 Configuration Examples

The following sections provide several examples of the static LSP configurations.
Issue 02 (2014-09-30) Huawei Proprietary and Confidential 1

1.1 Introduction
Labels can be assigned manually to LSRs to establish static LSPs.
1.1.1 Overview
The static LSP cannot be established using a label distribution protocol but can be established
by an administrator. Static LSPs can be used in stable, small-scaled networks with a simple
topology.
When configuring a static LSP, the administrator must manually allocate labels for each LSR
ensuring that the value of the outgoing label of the previous node is equal to the value of the
incoming label of the next node. LSRs on the static LSP cannot detect the changes in other LSRs
on the same LSP. Therefore, the static LSP is a local concept.
Static LSPs are set up without using label distribution protocols and do not need to exchange
control packets. Therefore, they consume a few resources and are transmitted on small-scale
networks with simple and stable topology. Static LSPs are not automatically adjusted when the
network topology changes. The administrator must adjust the static LSP according to the network
topology.
1.1.2 Static LSP Features Supported by the NE80E/40E

This section describes static LSPs features supported by the NE80E/40E. The features include
configuring static LSPs and static BFD for static LSP.
Static LSPs
Static LSPs must be configured manually by an administrator. LSRs on the static LSP cannot
detect the changes in other LSRs on the same LSP. Therefore, the static LSP is a local concept.
Static LSPs are not automatically adjusted when the network topology changes. The
administrator must adjust the static LSP according to the network topology.
Static BFD for Static LSPs

The NE80E/40E supports static bidirectional forwarding detection (BFD) for static LSPs. When
static BFD monitors static LSPs that are unidirectional, reverse links can be either IP links or
static LSPs.
1.2 Configuring Static LSPs

A static LSP can be established only after each LSR is manually configured.
1.2.1 Before You Start

Before configuring a static LSP, familiarize yourself with the usage scenario, complete the pre-
configuration tasks, and obtain the data required for the configuration.

Usage Scenario
A static LSP works properly only after all the LSRs along the LSP are configured.
Setting up static LSPs does not require the label distribution protocol or the exchange of any
control packets. Therefore, static LSPs consume few resources and can be used on small-scale
networks with a simple and stable topology. Static LSPs are not automatically adjusted when
the network topology changes. The administrator needs to adjust the static LSPs according to
the network topology.
Static LSPs and static CR-LSPs share the same label space (16 - 1023).
Static LSPs are used over MPLS L2VPNs.
For information about the MPLS L2VPN configuration, see the HUAWEI NetEngine80E/40E
Router Configuration Guide - VPN.
Pre-configuration Tasks
Before configuring static LSPs, configure a static unicast route or an IGP to connect LSRs at
the network layer.
Data Preparation
To configure static LSPs, you need the following data.
No. Data
1 Name of the static LSP
2 Destination address and mask
3 Value of an incoming or outgoing label on each LSR
4 Next hop address or outbound interface on the ingress
5 Inbound interface, next hop address, or outbound interface on a transit node
6 Inbound interface on the egress
1.2.2 Configuring the LSR ID

Before enabling MPLS, configure the LSR ID.
Context
When configuring an LSR ID, note the following issues:
l The LSR ID must be configured before other MPLS commands are run.
l The LSR ID does not have a default value and must be configured manually.
l Using the address of the loopback interface of the LSR as the LSR ID is recommended.

l To modify the configured LSR ID, run the undo mpls command in the system view to
delete all the MPLS configurations.
Perform the following steps on each LSR in an MPLS domain:
Procedure
Step 1 Run:
system-view
The system view is displayed.
Step 2 Run:
mpls lsr-id lsr-id
The LSR ID of the local node is configured.
lsr-id: A number in dotted decimal notation that identifies an LSR.
----End
1.2.3 Enabling MPLS

MPLS features can be configured only after MPLS is enabled.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
MPLS is enabled globally and the MPLS view is displayed.
Step 3 Run:
quit
Return to the system view.
Step 4 Run:
interface interface-type interface-number
The interface to participate in MPLS forwarding is specified.
Step 5 Run:
mpls
MPLS is enabled on the interface.
----End

1.2.4 Configuring the Ingress for a Static LSP

This section describes how to configure a static LSP on the ingress. Before you set up a static
LSP, configure the ingress manually.
Context
Perform the following steps on the LSR to be configured as the ingress:
Procedure
Step 1 Run:
system-view

Step 2 Run:
static-lsp ingress lsp-name destination ip-address { mask-length | mask }
{ nexthop next-hop-address | outgoing-interface interface-type interface-number }
* out-label out-label
The LSR is configured as the ingress on the specified LSP.

To modify the destination destination-address, nexthop next-hop-address, outgoing-
interface interface-type interface-number, or out-label out-label, run the static-lsp ingress
command to set a new value. There is no need to run the undo static-lsp ingress command
before changing a configured value.
NOTE
It is recommended to set up a static LSP by specifying a next hop. Ensure that the local routing table contains
the route entries, including the destination IP address and the next hop IP addresses of the LSP to be
established.
----End
1.2.5 Configuring the Transit Node for a Static LSP

This section describes how to configure a transit node manually for a static LSP.
Context
Perform the following steps on the LSR to be configured as a transit node:
Procedure
Step 1 Run:
system-view

Step 2 Run:
static-lsp transit lsp-name incoming-interface interface-type interface-number in-
label in-label { nexthop next-hop-address | outgoing-interface interface-type
interface-number } * out-label out-label
The LSR is configured as the transit node on the specified LSP.

To modify the incoming-interface interface-type interface-number, in-label in-label, next-hop-

address, outgoing-interface interface-type interface-number, or out-label out-label, run the
static-lsp transit command to set a new value. There is no need to run the undo static-lsp
transit command before changing a configured value.
NOTE
It is recommended to set up a static LSP by specifying a next hop address. In addition, ensure that the local
routing table contains the route entries, including the destination IP address and the next hop IP address of
the LSP to be established.
----End
1.2.6 Configuring the Egress for a Static LSP

This section describes how to configure a static LSP on the egress. Before you set up a static
LSP, configure the egress manually.
Context
Perform the following steps on the LSR to be configured as the egress:
Procedure
Step 1 Run:
system-view
Step 2 Run:
static-lsp egress lsp-name incoming-interface interface-type interface-number in-
label in-label [ lsrid ingress-lsr-id tunnel-id tunnel-id ]
The LSR is configured as the egress on the specified LSP.
To modify the incoming-interface interface-type interface-number or in-label in-label or

lsrid ingress-lsr-id tunnel-id tunnel-id, run the static-lsp egress command to set a new value.
There is no need to run the undo static-lsp egress command before changing a configured value.
----End
1.2.7 Checking the Configurations

After configuring a static LSP is set up, verify that the static LSP is Up, and the route status is
Ready.
Prerequisites
The static LSP function has been configured.
Procedure
l Run the display mpls static-lsp [ lsp-name ] [ { include | exclude } ip-address mask-
length ] [ verbose ] command to check the static LSP information.

l Run the display mpls route-state [ vpn-instance vpn-instance-name ] [ { exclude |

include } { idle | ready | settingup } * | destination-address mask-length ] [ verbose ]
command to check the LSP route on the ingress.
----End
Example
After completing the configurations run the preceding commands to display information about
the static LSP.
l Run the display mpls static-lsp command to view information about the static LSP
configuration. The command output includes the name of the static LSP, FEC, values of
the incoming and outgoing labels, and the inbound and outbound interfaces. In addition,
the status of the LSP is Up.
<HUAWEI> display mpls static-lsp
TOTAL : 1 STATIC LSP(S)
UP : 1 STATIC LSP(S)
DOWN : 0 STATIC LSP(S)
Name FEC I/O Label I/O If Status
lsp1 3.3.3.9/32 NULL/100 -/GE1/0/0 Up
1.3 Configuring Static BFD for Static LSP

This section describes how to configure a static BFD session to monitor static LSPs. By
configuring static BFD for static LSPs, you can monitor the connectivity of static LSPs.

Before configuring static BFD for static LSPs, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the data required for the configuration.
Usage Scenario
BFD is used to monitor the connectivity of static LSPs established manually.
NOTE
When static BFD is being used for a static LSP, you can create a static BFD session for non-host routes.
Static BFD for static LSPs can function properly even if the forward path is an LSP and the reverse path
is an IP link. The forward and reverse paths must be established over the same link. If they use different
links and a fault occurs, BFD cannot identify the faulty path.
Before configuring static BFD for static LSP, configure a static LSP.
NOTE
For static CR-LSPs bound to an MPLS TE tunnel, BFD is available after it is bound to the MPLS TE tunnel.
Data Preparations
Before configuring static BFD for static LSP, you need the following data.

No. Data
1 Name of a static LSP
2 BFD configuration name
3 Parameters of the reverse link:

l IP link: IP address of egress, outbound interface (optional), and source IP address
(optional)
l Dynamic LSP: IP address of egress, next hop address of the LSP, and egress
(optional)
l Static LSP: LSP name
l MPLS TE: ID of an MPLS TE tunnel
4 Local and remote discriminators of a BFD session
1.3.2 Enabling Global BFD Capability

You can enable BFD globally on both ends of a link to be monitored.
Context
Perform the following steps on each LSR at both ends of the link to be monitored:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
This node is enabled with the global BFD function. The global BFD view is displayed.
----End
1.3.3 Configuring BFD with Specific Parameters on Ingress

To monitor a static LSP using a static BFD session, configure BFD parameters on the ingress
of a static LSP.
Context
Perform the following steps on the ingress of a static LSP:
Procedure
Step 1 Run:

system-view
Step 2 Run:
bfd bfd-name bind static-lsp lsp-name
The BFD session is bound to the static LSP.
Step 3 Configure the discriminators.

l Run:
discriminator local discr-value
The local discriminator is set.

l Run:
discriminator remote discr-value
The remote discriminator is set.
Step 4 (Optional) Run:

min-tx-interval interval
The local minimum interval at which BFD packets are sent is set.
The default value is 10 milliseconds.

min-rx-interval interval
The local minimum interval at which BFD packets are received is set.

detect-multiplier multiplier
The local detection multiplier is set.
The default value is 3.

NOTE
l Effective local interval at which BFD packets are sent = MAX { Configured local interval at which
BFD packets are sent, Configured remote interval at which BFD packets are received }
l Effective local interval at which BFD packets are received = MAX { Configured remote interval at
which BFD packets are sent, Configured local interval at which BFD packets are received }
l Effective local detection interval = Effective local interval at which BFD packets are received x
Configured remote detection multiplier
For example, if:
l The interval at which BFD packets are sent is set to 200 ms, the local interval at which BFD packets
are received is set to 300 ms, and the detection multiplier is set to 4.
l The remote interval at which BFD packets are sent is set to 100 ms, the remote interval at which BFD
packets are received is set to 600 ms, and the remote detection multiplier is set to 5.
Then,
l Effective local interval at which BFD packets are sent = MAX {200 ms, 600 ms} = 600 ms; effective
local interval at which BFD packets are received = MAX {100 ms, 300 ms} = 300 ms; effective local
detection period = 300 ms x 5 = 1500 ms
l Effective remote interval at which BFD packets are sent = MAX { 100 ms, 300 ms } = 300 ms; effective
remote interval at which BFD packets are received = MAX { 200 ms, 600 ms } = 600 ms; effective
remote detection period = 600 ms x 4 = 2400 ms
Step 7 Run:
process-pst
If the BFD session status changes, the interface status table is modified.
If the BFD session status changes, the static LSP status in the interface status table is modified.
Step 8 Run:
commit
The configuration is committed.
The BFD session monitors the static LSP as follows:
l If the static LSP status goes Up, the BFD session is reestablished.
l If the static LSP status goes Down, the BFD session also goes Down.
----End
1.3.4 Configuring BFD with Specific Parameters on Egress

This section describes how to configure BFD parameters on the egress. Before using a static
BFD session to monitor a static LSP, configure BFD parameters on the egress of the static LSP.
Context
The egress can use an IP link, LSP, or TE tunnel as a reverse tunnel to notify the ingress of a
fault. To ensure that the forward and reverse paths travel through the same link, an LSP is
preferentially selected to notify the ingress of an LSP fault.
Perform the following steps on the egress of an LSP:

Procedure
Step 1 Run:
system-view
Step 2 Configure BFD sessions.

l For an IP link, run:
bfd bfd-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ]
[ interface interface-type interface-number ] [ source-ip source-ip ]
l For a dynamic LSP, run:

bfd bfd-name bind ldp-lsp peer-ip ip-address nexthop ip-address [ interface
interface-type interface-number ]
l For a static LSP, run:

l For an MPLS TE tunnel, run:

bfd bfd-name bind mpls-te interface tunnel interface-number [ te-lsp [ backup ] ]

l To set a local discriminator, run:
l To set a remote discriminator, run:





process-pst
The device is enabled to modify the PST if the BFD session status changes.
If an LSP or a TE tunnel is used as a reverse tunnel to notify the ingress of a fault, you can run
this command to allow the reverse tunnel to switch traffic if the BFD session goes Down. If a
single-hop IP link is used as a reverse tunnel, this command can be configured, because the
process-pst command can only be configured for BFD single-link detection.

Step 8 Run:
commit
----End

After configuring a static BFD session to monitor a static LSP, you can view the BFD
configuration, BFD session information, BFD statistics, and the status of the static LSP.
Prerequisites
The static BFD for static LSP function has been configured.
Procedure
l Run the display bfd configuration { all | static } [ for-lsp ] command to check the BFD
configuration.
l Run the display bfd session { all | static } [ for-lsp ] command to check BFD session
information.
l Run the display bfd statistics session { all | static } [ for-ip | for-lsp ] command to check
BFD statistics.
l Run the display mpls static-lsp [ lsp-name ] [ { include | exclude } ip-address mask-
length ] [ verbose ] command to check the static LSP information.
----End
1.4 Maintaining Static LSPs

Static LSP maintenance involves deleting MPLS statistics, checking the connectivity or
reachability of an LSP, and configuring the trap function on an LDP LSP.
1.4.1 Checking the LSP Connectivity and Reachability

You can monitor the connectivity or reachability of an LSP by running the ping or tracert
command.
Context
You can run the following commands in any view to perform MPLS ping and MPLS tracert.
Procedure
l Run the ping lsp [ -a source-ip | -c count | -exp exp-value | -h ttl-value | -m interval | -r
reply-mode | -s packet-size | -t time-out | -v ] * ip destination-address mask-length [ ip-
address ] [ nexthop nexthop-address | draft6 ] command to perform MPLS ping.
If draft6 is specified, the command complies with draft-ietf-mpls-lsp-ping-06. By default,

the command complies with RFC 4379.

l Run the tracert lsp [ -a source-ip | -exp exp-value | -h ttl-value | -r reply-mode | -t time-
out ] * ip destination-address mask-length [ ip-address ] [ nexthop nexthop-address |
draft6 ] command to perform MPLS tracert.

----End
1.4.2 Enabling the LSP Trap Function

By configuring the trap function on an LSP, you can notify the NMS of the changes in the LSP
status.
Context
Run the following commands in the system view to notify the Network Management System
(NMS) of LSP status changes.
Procedure
l Run the snmp-agent trap suppress feature-name lsp trap-name { mplsxcup |
mplsxcdown } trap-interval trap-interval [ max-trap-number max-trap-number ]
command in the system view to enable the trap function for the LSP and enable the
debugging of excessive mplsxcup or mplsxcdown information.
----End

The following sections provide several examples of the static LSP configurations.
1.5.1 Example for Configuring Static LSPs

This section provides an example for configuring static LSPs.
Networking Requirements
LSRs support MPLS and OSPF as an IGP running on the MPLS backbone network as shown
in Figure 1-1.
Bidirectional static LSPs are set up between LSRA and LSRD. The LSP between LSRA and
LSRD is along the path LSRA -> LSRB -> LSRD. The LSP between LSRD and LSRA is along
the path LSRD -> LSRC -> LSRA.

Figure 1-1 Networking diagram for static LSPs

Loopback1
2.2.2.9/32
P
/0 10 OS2
S 1/0 /30 .2. /0
PO 1.1.
2 1.1 /0
. /30 P
0 0 10 OS1
Loopback1 /0/ 0 1 LSRB Loopback1
1.1.1.9/32 OS1 .1/3 .2. /0/ 4.4.4.9/32
1.2 0
P 1.1 /30
.
10
P
LSRA 1 OS 0
0.3 2/0 2/0/ 30 LSRD
.1. /0 S 2/
1/3 LSRC PO 4.1.
0 POS .
10 /0 10
.3. 1/0/
1.2 0 S 2/0 /30
/30 PO 4.1.1
.
10
Loopback1
3.3.3.9/32
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure the IP address of each interface, use the loopback address as an LSR ID, and
enable OSPF to advertise routes of network segments to which the interfaces are connected
and LSR ID host routes.
2. Enable MPLS globally on each LSR.
3. Enable MPLS on the interfaces.
4. Specify the destination address, outbound interface or next hop address, and outgoing label
for the LSP on the ingress LSR.
5. Specify the inbound interface, incoming label (equal to the outgoing label used by the
previous hop), outgoing label, and outbound interface or next hop address of the LSP on
the transit node.
6. Specify the inbound interface and the incoming label (equal to the outgoing label used by
the previous hop) on the egress.
Data Preparation
To complete the configuration, you need the following data:
l IP addresses of the interfaces on each LSR as shown in Figure 1-1, OSPF process ID, and
area ID
l Name of the static LSP
l Outgoing labels of the interfaces

Procedure
Step 1 Assign an IP address to each interface.
According to Figure 1-1, configure the IP address and the mask of the interfaces, including the
loopback interface. For configuration details, see Configuration Files in this section.
Step 2 Use OSPF to advertise LSR ID host routes and routes of the network segments to which the
interfaces are connected.
# Configure LSRA.
[LSRA] ospf 1
[LSRA-ospf-1] area 0
[LSRA-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[LSRA-ospf-1-area-0.0.0.0] quit
[LSRA-ospf-1] quit
# Configure LSRB.
[LSRB] ospf 1
[LSRB-ospf-1] area 0
[LSRB-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[LSRB-ospf-1-area-0.0.0.0] quit
[LSRB-ospf-1] quit
# Configure LSRC.
[LSRC] ospf 1
[LSRC-ospf-1] area 0
[LSRC-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0
[LSRC-ospf-1-area-0.0.0.0] quit
[LSRC-ospf-1] quit
# Configure LSRD.
[LSRD] ospf 1
[LSRD-ospf-1] area 0
[LSRD-ospf-1-area-0.0.0.0] network 4.4.4.9 0.0.0.0
[LSRD-ospf-1-area-0.0.0.0] quit
[LSRD-ospf-1] quit
After completing the configuration, run the display ip routing-table command on the LSRs.
The LSRs already learn routes from each other.
The following example uses the command output on LSRA.
[LSRA] display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 14 Routes : 15
Destination/Mask Proto Pre Cost Flags NextHop Interface
1.1.1.9/32 Direct 0 0 D 127.0.0.1 LoopBack1
2.2.2.9/32 OSPF 10 2 D 10.1.1.2 Pos1/0/0
3.3.3.9/32 OSPF 10 2 D 10.3.1.2 Pos2/0/0
4.4.4.9/32 OSPF 10 3 D 10.1.1.2 Pos1/0/0
OSPF 10 3 D 10.3.1.2 Pos2/0/0

10.1.1.0/30 Direct 0 0 D 10.1.1.1 Pos1/0/0

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.2.1.0/30 OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.3.1.0/30 Direct 0 0 D 10.3.1.1 Pos2/0/0
10.3.1.1/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
10.3.1.2/32 Direct 0 0 D 10.3.1.2 Pos2/0/0
10.4.1.0/30 OSPF 10 2 D 10.3.1.2 Pos2/0/0
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
The routing table contains the next hop address or outbound interface in boldface of the static
LSP on 4.4.4.9/32 originating from LSRA and destined for LSRD. In this example, the next hop
IP address is 10.1.1.2/30.
The following example uses the command output on LSRD.

[LSRD] display ip routing-table
------------------------------------------------------------------------------
1.1.1.9/32 OSPF 10 3 D 10.2.1.1 Pos1/0/0
OSPF 10 3 D 10.4.1.1 Pos2/0/0
2.2.2.9/32 OSPF 10 2 D 10.2.1.1 Pos1/0/0
3.3.3.9/32 OSPF 10 2 D 10.4.1.1 Pos2/0/0
10.1.1.0/30 OSPF 10 2 D 10.2.1.1 Pos1/0/0
10.2.1.0/30 Direct 0 0 D 10.2.1.2 Pos1/0/0
10.2.1.1/32 Direct 0 0 D 10.2.1.1 Pos1/0/0
10.2.1.2/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.3.1.0/30 OSPF 10 2 D 10.4.1.1 Pos2/0/0
10.4.1.0/30 Direct 0 0 D 10.4.1.2 Pos2/0/0
10.4.1.1/32 Direct 0 0 D 10.4.1.1 Pos2/0/0
10.4.1.2/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
The routing table contains the next hop address or outbound interface in boldface of the static
LSP on 1.1.1.9/32 originating from LSRD and destined for LSRA. In this example, the next hop
IP address is 10.4.1.1/30.
Step 3 Configure the basic MPLS capability on each LSR.
# Configure LSRA.
[LSRA] mpls lsr-id 1.1.1.9
[LSRA] mpls
[LSRA-mpls] quit
# Configure LSRB.
[LSRB] mpls lsr-id 2.2.2.9
[LSRB] mpls
[LSRB-mpls] quit
# Configure LSRC.
[LSRC] mpls lsr-id 3.3.3.9
[LSRC] mpls
[LSRC-mpls] quit
# Configure LSRD.
[LSRD] mpls lsr-id 4.4.4.9

[LSRD] mpls
[LSRD-mpls] quit
Step 4 Configure the basic MPLS functions on each interface.

# Configure LSRA.
[LSRA] interface pos 1/0/0
[LSRA-Pos1/0/0] mpls
[LSRA-Pos1/0/0] quit
# Configure LSRB.
[LSRB] interface pos 1/0/0
[LSRB-Pos1/0/0] mpls
[LSRB-Pos1/0/0] quit
# Configure LSRC.
[LSRC] interface pos 1/0/0
[LSRC-Pos1/0/0] mpls
[LSRC-Pos1/0/0] quit
# Configure LSRD.
[LSRD] interface pos 1/0/0
[LSRD-Pos1/0/0] mpls
[LSRD-Pos1/0/0] quit
Step 5 Establish a static LSP originating from LSRA and destined for LSRD.
# Configure the ingress LSRA.
[LSRA] static-lsp ingress RAtoRD destination 4.4.4.9 32 nexthop 10.1.1.2 out-label
20
# Configure the transit LSRB.

[LSRB] static-lsp transit RAtoRD incoming-interface pos 1/0/0 in-label 20 nexthop
10.2.1.2 out-label 40
# Configure the egress LSRD.

[LSRD] static-lsp egress RAtoRD incoming-interface pos 1/0/0 in-label 40
After completing the configuration, run the display mpls static-lsp verbose or display mpls
lsp command on each LSR to view the LSP status.
[LSRA] display mpls static-lsp
RAtoRD 4.4.4.9/32 NULL/20 -/Pos1/0/0 Up

As the LSP is unidirectional, configure a static LSP originating from LSRD and destined for
LSRA.
Step 6 Establish the static LSP from LSRD to LSRA.
Using the same method, configure the static LSP originating from LSRD and destined for LSRA.
# Configure the ingress LSRD.

[LSRD] static-lsp ingress RDtoRA destination 1.1.1.9 32 nexthop 10.4.1.1 out-label
30
# Configure the transit LSRC.

[LSRC] static-lsp transit RDtoRA incoming-interface pos 2/0/0 in-label 30 nexthop
10.3.1.1 out-label 60
# Configure the egress LSRA.

[LSRA] static-lsp egress RDtoRA incoming-interface pos 2/0/0 in-label 60
Step 7 Verify the configuration.
# After completing the configuration, run the ping lsp ip 1.1.1.9 32 command on LSRD. The
LSP is reachable.
Run the display mpls static-lsp or display mpls static-lsp verbose command on the LSRs to
view the status and detailed information about the static LSP.
The following example uses the command output on LSRD.

[LSRD] display mpls static-lsp
RAtoRD -/- 40/NULL Pos1/0/0/- Up
RDtoRA 1.1.1.9/32 NULL/30 -/Pos2/0/0 Up
[LSRD] display mpls static-lsp verbose
No : 1
LSP-Name : RAtoRD
LSR-Type : Egress
FEC : -/-
In-Label : 40
Out-Label : NULL
In-Interface : Pos1/0/0
Out-Interface : -
NextHop : -
Static-Lsp Type: Normal
Lsp Status : Up
No : 2
LSP-Name : RDtoRA
LSR-Type : Ingress
FEC : 1.1.1.9/32
In-Label : NULL
Out-Label : 30
In-Interface : -
Out-Interface : Pos2/0/0
NextHop : 10.4.1.1
Static-Lsp Type: Normal
Lsp Status : Up
----End

Configuration Files
l LSRA configuration file
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.252
mpls
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.3.1.1 255.255.255.252
mpls
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.3.1.0 0.0.0.3
#
static-lsp ingress RAtoRD destination 4.4.4.9 32 nexthop 10.1.1.2 out-label 20
static-lsp egress RDtoRA incoming-interface Pos2/0/0 in-label 60
#
return
l LSRB configuration file

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.252
mpls
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.1 255.255.255.252
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
static-lsp transit RAtoRD incoming-interface Pos1/0/0 in-label 20 nexthop
10.2.1.2 out-label 40
#

return
l LSRC configuration file

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.3.1.2 255.255.255.252
mpls
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.4.1.1 255.255.255.252
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.3.1.0 0.0.0.3
network 10.4.1.0 0.0.0.3
#
static-lsp transit RDtoRA incoming-interface Pos2/0/0 in-label 30 nexthop
10.3.1.1 out-label 60
#
return
l LSRD configuration file

#
sysname LSRD
#
mpls lsr-id 4.4.4.9
mpls
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.2 255.255.255.252
mpls
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.4.1.2 255.255.255.252
mpls
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 10.2.1.0 0.0.0.3
network 10.4.1.0 0.0.0.3
#
static-lsp egress RAtoRD incoming-interface Pos1/0/0 in-label 40
static-lsp ingress RDtoRA destination 1.1.1.9 32 nexthop 10.4.1.1 out-label 30
#
return

1.5.2 Example for Configuring Static BFD for Static LSP

This section provides an example for setting up a static LSP and configuring a static BFD session
for monitoring the static LSP.
As shown in Figure 1-2:
l PE1, PE2, P1, and P2 are in the same MPLS domain.

l A static LSP is set up along the path PE1 -> P1 ->PE2.
Without MPLS operation, administration and maintenance (OAM), test the connectivity of the
static LSP. If the static LSP fails, PE1 can receive the advertisement within 50 ms.
Figure 1-2 Networking diagram for static BFD for static LSP
Loopback1
2.2.2.2/32
P
0
/0/ 24 10 OS1
1 .1. /0
S 2/ 5.2 /2
PO 1.1. /24
. P
Loopback1 0
/0/ 4 10 P1 10 OS1 Loopback1
1.1.1.1/32 OS1 .1/2 .1. /0/ 4.4.4.4/32
5.1 0
P 1.1 /24
.
10 Static LSP
P
PE1 10 OS 1
/0/ 24 PE2
.1. 1/0/ 1
S 1/
2.1 1
/24 PO 1.4.
.
P P2 10
10 OS1 /2
.1. /0/ S 1/0 /24
2.2 0
/24 PO 1.4.2
.
10
Loopback1
3.3.3.3/32
1. Configure OSPF for the MPLS domain and reachable IP routes to each LSR.
2. Configure a BFD session on PE1 to monitor the static LSP.
3. Configure a BFD session on PE2, which advertises a failure in static LSP to PE1 (the reverse
link of the LSP is an IP link).
Data Preparations

l IP addresses of the interfaces on each LSR

l OSPF process number
l BFD session parameters, such as configuration name and minimum detection intervals
between packet transmissions and receipts
Procedure
Step 1 Configure the IP address and the OSPF protocol for each interface.
Assign an IP address and a mask to each interface as shown in Figure 1-2, including loopback
interfaces.
Configure OSPF on all LSRs to advertise the host route of the loopback interface. For
configuration details, see Configuration Files in this section.
After the configuration is complete, each LSR can ping the other LSR ID. Run the display ip
routing-table command to view the route table on each LSR. The following example uses the
command output on PE1.
<PE1> display ip routing-table
------------------------------------------------------------------------------
1.1.1.1/32 Direct 0 0 127.0.0.1 LoopBack1
2.2.2.2/32 OSPF 10 2 10.1.1.2 Pos1/0/0
3.3.3.3/32 OSPF 10 2 10.1.2.2 Pos1/0/1
4.4.4.4/32 OSPF 10 3 10.1.1.2 Pos1/0/0
OSPF 10 3 10.1.2.2 Pos1/0/1
10.1.1.0/24 Direct 0 0 10.1.1.1 Pos1/0/0
10.1.1.1/32 Direct 0 0 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 10.1.2.1 Pos1/0/1
10.1.2.1/32 Direct 0 0 127.0.0.1 Pos1/0/1
10.1.2.2/32 Direct 0 0 10.1.2.2 Pos1/0/1
10.1.4.0/24 OSPF 10 2 10.1.2.2 Pos1/0/1
10.1.5.0/24 OSPF 10 2 10.1.1.2 Pos1/0/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoopBack0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoopBack0
Step 2 Enable MPLS and BFD functions on each LSR.
# Enable MPLS on PE1 globally and on each interface. The following example uses the
command output on PE1.
<PE1> system-view
[PE1] mpls lsr-id 1.1.1.1
[PE1] mpls
[PE1-mpls] quit
[PE1] interface pos 1/0/0
[PE1-Pos1/0/0] mpls
[PE1-Pos1/0/0] quit
[PE1-Pos1/0/1] mpls
[PE1-Pos1/0/1] quit
# Enable BFD on PE1 globally.

[PE1] bfd
[PE1-bfd] quit

Repeat preceding steps on PE2, P1, and P2.
Step 3 Create a static LSP with PE1 functioning as the ingress and PE2 functioning as the egress.
# Configure a static LSP on PE1 (ingress) named 1to4.

[PE1] static-lsp ingress 1to4 destination 4.4.4.4 32 nexthop 10.1.1.2 out-label 20
# Configure a static LSP on P1 (transit).

[P1] static-lsp transit 1to4 incoming-interface pos 1/0/0 in-label 20 nexthop
10.1.5.1 out-label 30
# Configure a static LSP on PE2 (egress).

[PE2] static-lsp egress 1to4 incoming-interface pos 1/0/0 in-label 30
After completing the configuration, run the ping lsp ip 4.4.4.4 32 command on PE1. The LSP
is reachable.
Step 4 Configure the BFD session to monitor the static LSP.
# Configure a BFD session on PE1 (ingress). Set the local discriminator to 1 and remote
discriminator to 2. Set the minimal intervals between packet transmissions and receipts to 10
seconds. Enable the BFD session to modify the interface status table.
[PE1] bfd 1to4 bind static-lsp 1to4
[PE1-bfd-lsp-session-1to4] discriminator local 1
[PE1-bfd-lsp-session-1to4] discriminator remote 2
[PE1-bfd-lsp-session-1to4] min-tx-interval 10
[PE1-bfd-lsp-session-1to4] min-rx-interval 10
[PE1-bfd-lsp-session-1to4] process-pst
[PE1-bfd-lsp-session-1to4] commit
[PE1-bfd-lsp-session-1to4] quit
# Configure the BFD session on PE2 (egress) that advertises a static LSP failure using the IP
route.
[PE2] bfd 4to1 bind peer-ip 1.1.1.1
[PE2-bfd-session-4to1] discriminator local 2
[PE2-bfd-session-4to1] discriminator remote 1
[PE2-bfd-session-4to1] min-tx-interval 10
[PE2-bfd-session-4to1] min-rx-interval 10
[PE2-bfd-session-4to1] commit
[PE2-bfd-session-4to1] quit
# Run the display bfd session all verbose command. The BFD session on PE1 is Up. The
following example uses the command output on PE1.
[PE1] display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 256 (One Hop)State : Up Name : 1to4
--------------------------------------------------------------------------------
Local Discriminator : 1 Remote Discriminator : 2
Session Detect Mode : Asynchronous Mode Without Echo Function
BFD Bind Type : STATIC_LSP
Bind Session Type : Static
Bind Peer Ip Address : 4.4.4.4
NextHop Ip Address : 10.1.1.2
Static LSP name : 1to4 LSP Token : 0x1002000
Bind Interface : --
FSM Board Id : 1 TOS-EXP : 7
Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10
Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10
Local Detect Multi : 3 Detect Interval (ms) : 30

Echo Passive : Disable Acl Number : -

Destination Port : 3784 TTL : 1
Proc Interface Status : Disable Process PST : Enable
WTR Interval (ms) : - Local Demand Mode : Disable
Active Multi : 3
Local Demand Mode : Disable
Last Local Diagnostic : Neighbor Signaled Session Down(Receive AdminDown)
Bind Application : LSPM | OAM_MANAGER
Session TX TmrID : -- Session Detect TmrID : --
Session Init TmrID : -- Session WTR TmrID : --
Session Echo Tx TmrID : -
PDT Index : FSM-B030000 | RCV-2 | IF-B030000 | TOKEN-0
Session Description : -
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
# Run the display bfd session all verbose command on PE2 to view the configuration.
--------------------------------------------------------------------------------
Session MIndex : 256 (Multi Hop) State : Up Name : 4to1
--------------------------------------------------------------------------------
BFD Bind Type : Peer Ip Address
Bind Interface : --
Proc Interface Status : Disable Process PST : Disable
Active Multi : 3
Last Local Diagnostic : Control Detection Time Expired
Bind Application : No Application Bind
PDT Index : FSM-0|RCV-0|IF-0|TOKEN-0
--------------------------------------------------------------------------------

# Shut down POS 1/0/2 of P1 to simulate a static LSP failure.
[P1] interface pos 1/0/2
[P1-Pos1/0/2] shutdown
# Run the display bfd session all verbose command on each PE to view the BFD status.
--------------------------------------------------------------------------------
Session MIndex : 256 (Multi Hop) State : Down Name : 4to1
--------------------------------------------------------------------------------
Bind Interface : -


Active Multi : 3
PDT Index : FSM-0|RCV-0|IF-0|TOKEN-0
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Session MIndex : 256 (One Hop) State : Down Name : 1to4
--------------------------------------------------------------------------------
BFD Bind Type : STATIC_LSP
Bind Interface : --
Static LSP name : 1to4 LSP Token : 0x1002000
WTR Interval (ms) : -
Proc interface status : Disable
Active Multi : 3
Bind Application : LSPM OAM_MANAGER
PDT Index : FSM-B030000 | RCV-2 | IF-B030000 | TOKEN-0
--------------------------------------------------------------------------------
----End
Configuration Files
l PE1 configuration file
#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
#
bfd
#
interface Pos1/0/0
link-protocol ppp
undo shutdown

ip address 10.1.1.1 255.255.255.0

mpls
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 10.1.2.1 255.255.255.0
mpls
#
interface NULL0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
ospf 100
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
#
static-lsp ingress 1to4 destination 4.4.4.4 32 nexthop 10.1.1.2 out-label 20
#
bfd 1to4 bind static-lsp 1to4
discriminator local 1
discriminator remote 2
min-tx-interval 10
min-rx-interval 10
process-pst
commit
#
Return

#
sysname PE2
#
mpls lsr-id 4.4.4.4
mpls
#
bfd
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.5.1 255.255.255.0
mpls
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 10.1.4.1 255.255.255.0
mpls
#
interface NULL0
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bfd 4to1 bind peer-ip 1.1.1.1
min-tx-interval 10
min-rx-interval 10
commit
#
ospf 100
area 0.0.0.0

network 4.4.4.4 0.0.0.0

network 10.1.4.0 0.0.0.255
network 10.1.5.0 0.0.0.255
#
static-lsp egress 1to4 incoming-interface Pos1/0/0 in-label 30
#
user-interface con 0
user-interface vty 0 4
#
Return
l P1 configuration file
#
sysname P1
#
mpls lsr-id 2.2.2.2
mpls
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
#
interface Pos1/0/2
link-protocol ppp
undo shutdown
ip address 10.1.5.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 100
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.5.0 0.0.0.255
#
static-lsp transit 1to4 incoming-interface Pos1/0/0 in-label 20 nexthop
10.1.5.1 out-label 30
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.3
mpls
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.2.2 255.255.255.0
mpls
#
interface Pos1/0/2
link-protocol ppp
undo shutdown
ip address 10.1.4.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 100

area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.4.0 0.0.0.255
#
return

Configuration Guide - MPLS 2 MPLS LDP Configuration
2 MPLS LDP Configuration
About This Chapter
Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) defines the messages
used during label distribution and the processing of the messages used to negotiate parameters
between label switching routers (LSRs) and allocate labels to set up a label switched path (LSP).
2.1 MPLS LDP Overview

Multiprotocol Label Switching Label Distribution Protocol (MPLS LDP) is a label distribution
protocol that is widely used for transmitting virtual private network (VPN) services. MPLS LDP
networking and configurations are simple. MPLS LDP supports route-driven establishment of
a large number of label switched paths (LSPs).
2.2 Configuring a Local LDP Session

A local LDP session must be established between each pair of directly connected LSRs on an
LSP before the LSP is established.
2.3 Configuring a Remote LDP Session

ikA remote LDP session needs to be configured if both L2VPN and LDP over TE are configured.
2.4 Configuring LDP LSPs

LDP can distribute labels to establish LSPs in an MPLS domain.
2.5 Configuring LDP Extension for Inter-Area LSP

Configuring LDP extension for inter-area LSP enables LDP to search for routes based on the
longest match rule to establish inter-area LDP LSPs.
2.6 Configuring the LDP Multi-Instance

You need to configure the LDP multi-instance when deploying the BGP/MPLS IP VPN.
2.7 Configuring a Node to Report LSP Fault Locations and Causes to the Ingress
Nodes on an LDP LSP can be enabled to report the locations and causes of LSP faults to the
ingress. After receiving fault notifications, the ingress notifies the NMS of fault information so
that the NMS is able to associates the root trap with the other traps. Administrators can rectify
the fault only using the root trap information, which improves fault-handling efficiency.
2.8 Configuring an Automatic mLDP P2MP Tunnel

An automatic mLDP P2MP tunnel must be configured before it can be automatically established
to transmit multicast services when the multicast services arrive in an IP/MPLS backbone
network.
2.9 Configuring LDP over TE

This section describes how to configure LDP over TE.
2.10 Configuring Static BFD for LDP LSP

This section describes how to configure a static BFD session to monitor an LDP LSP, and
therefore you can monitor LSP connectivity.
2.11 Configuring Dynamic BFD for LDP LSP

This section describes how to configure a dynamic BFD session to monitor an LDP LSP. There
is no need to configure BFD parameters. This helps speed up link fault detection and reduce
configuration workload.
2.12 Configuring Dynamic BFD to Monitor an LDP Tunnel

Dynamic BFD can be configured to establish a dynamic BFD session to monitor both primary
and backup LDP LSPs in an LDP tunnel. If BFD detects a fault, BFD instructs a specific LDP
upper-layer application to perform a protection switchover.
2.13 Configuring Manual LDP FRR

This section describes how to configure Manual LDP FRR. Manual LDP FRR can quickly switch
traffic to a backup LSP if an LDP link fails, which ensures uninterrupted traffic transmission.
2.14 Configuring LDP Auto FRR

LDP Auto FRR can be configured to rapidly trigger a service switchover if a fault occurs,
improving network reliability.
2.15 Configuring Synchronization Between LDP and IGP

This section describes how to configure LDP and IGP synchronization. LDP and IGP
synchronization can delay a route switchback by suppressing the setup of an IGP neighbor
relationship until an LDP session is established.
2.16 Configuring Synchronization Between LDP and Static Routes

By configuring synchronization between LDP and static routes, you can switch traffic from a
faulty primary link to the backup link by suppressing the activation of static routes. You can
also delay traffic switchback to synchronize LDP and static routes.
2.17 Configuring LDP Security Features

LDP security features such as MD5 authentication, keychain authentication, and the GTSM can
be configured to meet high network security requirements. By default, no authentication is
configured for LDP. Configuring security authentication is recommended to ensure system
security.
2.18 Configuring LDP GR

This section describes how to configure LDP GR. LDP GR implements the uninterrupted
forwarding during a master/slave switchover or the protocol restart, which minimizes the
protocol flapping on the control plane.
2.19 Maintaining MPLS LDP

This section describes how to maintain MPLS LDP. The operations of MPLS LDP maintenance
include resetting LDP, monitoring the connectivity and reachability of an LSP, configuring alarm
thresholds for LDP LSPs, and configuring the trap function on an LDP LSP.

The following sections provide several examples for configuring MPLS LDP.

2.1 MPLS LDP Overview

Multiprotocol Label Switching Label Distribution Protocol (MPLS LDP) is a label distribution
protocol that is widely used for transmitting virtual private network (VPN) services. MPLS LDP
a large number of label switched paths (LSPs).
2.1.1 Introduction to MPLS LDP

MPLS LDP, a label distribution protocol, is widely used for transmitting VPN services. Its
a large number of LSPs.
The IP-based Internet prevailed in the middle 1990s. However, IP technology is inefficient at
forwarding packets because software must search for routes through the longest match algorithm.
As a result, the forwarding capability of IP technology becomes a bottleneck of network
development. The Asynchronous Transfer Mode (ATM) technology has been created from the
evolution of network technologies. It uses labels (particularly, cells) of fixed length and
maintains a label table that is much smaller than a routing table. Therefore, compared to IP
technology, ATM technology is much more efficient at forwarding packets. ATM technology,
however, is a complex protocol with a high cost of deployment, which hinders its widespread
popularity and growth.
Traditional IP technology, however, is simple and costs little to deploy. People are eager to use
technology that combines the best that IP and ATM technologies have to offer. This has sparked
the emergence of Multiprotocol Label Switching (MPLS) technology.
Initially, MPLS was created to increase forwarding rates. With the development of the
application-specific integrated circuit (ASIC) technology Application specific integrated circuit
(ASIC) technology has now been developed, and the routing rate is no longer a bottleneck to
network development. As a result, MPLS no longer has the high-speed forwarding advantage.
MPLS is widely used in virtual private network (VPN), traffic engineering (TE), and quality of
service (QoS) because of its support for multi-layer labels, the connection-oriented forwarding
plane, and the connectionless control plane.
LDP is an MPLS control protocol. Similar to most routing protocols, LDP sends multicast Hello
messages to automatically discover LDP peers and establish peer relationships, or sends unicast
Hello messages to establish target peer relationships. LDP uses negotiated parameters to
establish LDP sessions over TCP connections between peers. LDP sessions send Label Mapping
messages, distribute labels related to routes, and establish LSPs. Data packets travel along the
LSPs over MPLS networks.
In real world situations, LDP is run on the provider (P) devices to forward LDP messages and
on provider edge (PE) devices to support services such as LDP over TE on backbone networks.

Figure 2-1 LDP networking
Service provider's
VPN 2
VPN 1 backbone Site
Site P P P PE
CE CE
PE
VPN 1
Site
VPN 2
PE
Site P P P
CE
CE
2.1.2 MPLS LDP Features Supported by the NE80E/40E

The NE80E/40E supports MPLS LDP features, including basic LDP functions, extended LDP
functions, reliability, and security.
Basic LDP Functions

l LDP Sessions
LDP sessions are established to exchange labels between label switching routers (LSRs).
LDP sessions are classified into the following types:
– Local LDP session: established only between adjacent LSRs.
– Remote LDP session: established primarily between indirectly connected LSRs and also
between adjacent LSRs.
l LDP LSPs
LDP can dynamically establish LSPs. LDP LSPs are recommended on networks where
there is no need to strictly control LSP paths or configured MPLS TE.
Extended LDP Functions

l Inter-area LDP extension
The inter-area LDP extension supports the longest match rule for looking up routes and
establishing LDP LSPs across Interior Gateway Protocol (IGP) areas.
l LDP multi-instance
The LDP multi-instance primarily applies to carrier's carrier MPLS Layer 3 VPNs
(L3VPNs). For more information about carrier's carrier networking, see the HUAWEI
NetEngine80E/40E Router Feature Description - VPN.
l LSP fault notification to the ingress
If an LDP LSP fails, a node detects the fault and notifies the ingress of the fault location
and cause. The ingress then sends the root trap to the network management system (NMS).
The NMS associates the root trap with the other traps, which helps administrators improve
fault handling efficiency.
l LDP LSP load balancing

Equal-cost LDP LSPs for the same FEC can be established on the ingress or a transit node
to balance traffic. You can adjust the maximum number of equal-cost LDP LSPs that can
be established to improve link usage efficiency or save LDP LSP resources.
l mLDP
The multipoint extensions for Label Distribution Protocol (mLDP) transmits multicast
services over IP/MPLS backbone networks, which simplifies network deployment and
improves the efficiency of bandwidth usage.
In some applications, such as IPTV, a fixed multicast source and multiple receivers are
configured. To transmit such applications, the mLDP point-to-multipoint (P2MP)
technique can be used. mLDP P2MP extends the MPLS LDP protocol to establish P2MP
paths. A tree-shaped mLDP P2MP LSP consists of sub-LSPs originating from the root node
(ingress) and destined for leaf nodes. The root node directs multicast traffic to the P2MP
LSP and sends packets to a branch node for replication. The branch node replicates the
packets and forwards the packets to leaf nodes connected to the branch node.
l LDP over TE
MPLS TE supports strong traffic engineering capabilities and provides various QoS
guarantees. Due to live network limitations, such as application types and costs, deploying
MPLS TE on the entire network is difficult. Therefore, LDP over TE can be used to deploy
MPLS TE on a core area and LDP on non-core areas.
Reliability
The NE80E/40E supports the following reliability features for LDP LSPs:
l BFD
Bidirectional forwarding detection (BFD) detects faults in LDP LSPs. BFD packets are in
a fixed format and easily traverse firewalls, with low hardware requirements. BFD has the
following advantages:
– Rapid detection
– Detection for faults in a large number of LSPs
l LDP FRR
Traditional IP fast reroute (FRR) cannot protect MPLS traffic. The NE80E/40E supports
LDP FRR and provides interface-level protection solutions.
When there is no fault, a primary LSP is forwarding traffic. If the outbound interface of the
primary LSP goes Down, a backup LSP takes over traffic, ensuring uninterrupted traffic
transmission during network convergence.
The NE80E/40E supports LDP Auto FRR and LDP manual FRR.
l LDP-IGP synchronization
On an MPLS network with both the primary and backup LSPs, if the primary LSP fails,
traffic switches from the primary LSP to the backup LSP. This process causes traffic
interruption hundreds of milliseconds. After the primary LSP recovers, traffic switches
back to the primary LSP. This process causes traffic interruption approximately 5 seconds.
LDP-IGP synchronization can be configured, minimizing traffic interruption during a
traffic switchback to milliseconds.
l LDP and static route synchronization
On an MPLS network with both the primary and backup LSPs, LSRs use static routes to
establish LSPs. If the primary LSP fails, traffic switches from the primary LSP to the backup

LSP. This process causes traffic interruption hundreds of milliseconds. After the primary
LSP recovers, traffic switches back to the primary LSP. This process causes traffic
interruption several seconds.
LDP and static route synchronization can be configured, minimizing traffic interruption
during a traffic switchback to milliseconds.
LDP and static route synchronization sets static routes to the inactive state to delay the
traffic switchback. This allows the static route and the primary LSP to become available
simultaneously.
l LDP GR
Graceful restart (GR) is a key technique for high availability (HA). GR is used to protect
traffic during active main board (AMB)/standby main board (SMB) switchovers and
upgrade. LDP GR prevents the system from resetting an interface board when an AMB/
SMB switchover is performed. This helps retain LDP LSP information on the data plane,
ensures uninterrupted LSP forwarding, and minimizes adverse impact on MPLS packet
forwarding.
l LDP NSR
Non-stop routing (NSR) ensures uninterrupted traffic transmission and proper connections
on the control plane if a software or hardware fault occurs. This prevents the control plane
on a neighbor device from detecting the fault and being affected.
LDP Security Features

LDP security features include message digest algorithm 5 (MD5) authentication, keychain
authentication, and the Generalized TTL Security Mechanism (GTSM).
l LDP MD5: A typical MD5 application is to calculate a message digest to prevent message
spoofing. The MD5 message digest is a unique result calculated using an irreversible
character string conversion. If a message is modified during transmission, a different digest
is generated. After the message arrives at the receiving end, the receiving end can detect
the modification after comparing the received digest with a pre-computed digest.
l LDP keychain: Keychain, an enhanced encryption algorithm similar to MD5, calculates a
message digest for an LDP message to prevent the message from being modified.
l LDP GTSM: The GTSM checks TTL values to defend against attacks. The GTSM can be
configured to check whether or not the TTL value in the IP header is within a specified
range, protecting the nodes against attacks and improving system security.
2.2 Configuring a Local LDP Session

A local LDP session must be established between each pair of directly connected LSRs on an
LSP before the LSP is established.

Before configuring a local LDP session, familiarize yourself with the usage scenario, complete
the pre-configuration tasks, and obtain the data required for the configuration.

Usage Scenario
A local LDP session must be created between each pair of directly connected LSRs before an
LSP is established. LDP distributes and swaps label along an LSP.
When LDP LSPs carry L2VPN and L3VPN services, you can specify an LSR ID for each local
LDP session on the current LSR to isolate VPN services.
Before configuring a local LDP session, configure static routes or an IGP to implement reachable
routes between LSRs.
Data Preparation
To configure a local LDP session, you need the following data.
Item Data
1 LSR ID of each LSR
2 Type and number of the interface on which the local LDP session is to be set up
3 (Optional) LSR ID of the local LDP session
3 (Optional) LDP transport addresses
4 (Optional) Values of the following LDP timers:

l Link Hello hold timer
l Link Hello send timer
l Keepalive send timer
l Keepalive hold timer
l Exponential backoff timer
2.2.2 Configuring Global LDP

Global LDP must be enabled on each LSR before LDP services are configured in an MPLS
domain.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls lsr-id lsr-id
An LSR ID is set for the local LSR.

Note the following when configuring an LSR ID:

l LSR IDs must be set before other MPLS commands are run.
l No default LSR ID is provided and the LSR ID needs to be configured.
l Using the IP address of a loopback interface as the LSR ID is recommended for an LSR.
l Before a configured LSR ID is changed, the undo mpls command must be run in the system
view to delete all MPLS configurations.
NOTICE
After the undo mpls command is run, all MPLS configurations including LDP sessions and
LSPs will be deleted and services will be interrupted. Correctly plan and set all LSR IDs for
LSRs on an MPLS network to prevent this problem.
Step 3 Run:
mpls
By default, no node is enabled with MPLS globally.
Step 4 Run:
quit
Step 5 Run:
mpls ldp
LDP is enabled globally and the MPLS-LDP view is displayed.
By default, no node is enabled with LDP globally.

lsr-id lsr-id
An LSR ID is set for an LDP instance.
The default LSR ID of an LDP instance is the LSR ID of the LSR where the LDP instance is
configured. Using the default value is recommended.
----End
2.2.3 (Optional) Configuring the Dynamic LDP Advertisement

Capability
On LSRs enabled with global LDP, the dynamic LDP advertisement capability allows extended
LDP functions to be dynamically enabled or disabled when the LDP session is working properly,
ensuring stable LSP operation.
Context
On an LSR disabled from the dynamic LDP negotiation capability, if an extended LDP function
is enabled after an LDP session has been created, the LDP session will be interrupted and the

extended LDP function will be negotiated, affecting LSP stability. The dynamic LDP
advertisement capability allows an extended LDP function to be enabled or disabled dynamically
during proper operation of an LDP session, ensuring LSP stability.
NOTE
Enabling this function immediately after LDP is enabled globally is recommended. The dynamic LDP
advertisement capability does not affect existing LDP functions.
Before the dynamic LDP advertisement capability is enabled, MPLS and LDP must be enabled globally.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
The MPLS-LDP view is displayed.
Step 3 Run:
capability-announcement
The dynamic LDP advertisement capability is enabled.
By default, the dynamic LDP advertisement capability is not enabled.
NOTE
Enabling dynamic LDP advertisement after an LDP session is established will result in reestablishment of
the LDP session.
----End
2.2.4 (Optional) Enabling LDP Loop Detection Negotiation

If the NE80E/40E is connected to a device enabled with LDP loop detection, the NE80E/40E
must obtain the capability of negotiating LDP loop detection before being able to set up an LDP
session with the peer device.
Context
The NE80E/40E does not support LDP loop detection. To establish an LDP session with a device
enabled with LDP loop detection, the NE80E/40E needs to be enabled with the capability of
negotiating LDP loop detection.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp

Step 3 Run:
loop-detect
LDP loop detection negotiation is enabled. This allows the NE80E/40E to negotiate LDP
parameters during the initialization phase and establish an LDP session with a peer device that
is enabled with LDP loop detection.
NOTE
After the loop-detect command is run, the NE80E/40E obtains the capability of negotiating LDP loop
detection but still does not support LDP loop detection.

path-vectors integer
The maximum value of a path vector is specified.
A path vector is carried in a Mapping message to record the addresses of nodes that an LDP LSP
has passed. By setting the maximum hops that a path vector can record, you can adjust the
sensitivity of LDP loop detection. If the maximum hops of a path vector is n, the egress LSP
triggered by local routes detects a loop after n + 1 hops, and the egress LSP triggered by non-
local routes detects a loop after n hops.
----End
2.2.5 Configuring a Local LDP Session

Local LDP sessions allow LSRs to establish LSPs and swap labels.
Context
A local LDP session is created over a TCP connection. After a TCP connection is established,
LSRs negotiate LDP session parameters with each other. If LSRs on both ends of an LDP session
agree on negotiated parameters, a local LDP session can be established.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of an interface on which an LDP session is to be established is displayed.
Step 3 Run:
mpls
MPLS is enabled on the interface.
Step 4 Run:
mpls ldp
LDP is enabled on the interface.

By default, no interface is enabled with LDP.
NOTE
Disabling LDP on an interface causes the interface to terminate all LDP sessions on it and delete all LSPs
established using the LDP sessions.
----End
2.2.6 (Optional) Configuring an LDP Transport Address

An LDP session is established over a TCP connection. To set up an LDP session, two LSRs need
to confirm the LDP transport address of each other and then set up a TCP connection.
Context
LDP transport addresses are used to set up a TCP connection and need to be configured on both
nodes of a local LDP session. The default transport address is the loopback interface address
used as an LSR ID.
NOTE
l If LDP sessions are to be established over multiple links connecting two LSRs, LDP-enabled interfaces
of either LSR must use the default transport address or the same transport address. If multiple transport
addresses are configured on an LSR, only one transport address can be used to establish only one LDP
session.
l A change in an LDP transport address will terminate an LDP session. Exercise caution when running
the mpls ldp transport-address command.
Using the default LDP transport address is recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of the interface on which the LDP session is set up is displayed.
Step 3 Run:
mpls ldp transport-address { interface-type interface-number | interface }
An LDP transport address is specified. Either of the following settings can be used:
l interface-type interface-number: specifies the type and number of an interface. These

parameters allow LDP to use the primary IP address of a specified interface as a transport
address.
l interface: allows LDP to use the IP address of the current interface as a transport address.
The default transport address for a node on a public network is the local LSR ID of the current
LDP session, and the default transport address for a node on a private network is the primary IP
address of an interface on the node.
----End

2.2.7 (Optional) Configuring Timers for a Local LDP Session

A local LDP session uses the following timers: link Hello send timer, link Hello hold timer,
KeepAlive send timer, KeepAlive hold timer, and Exponential backoff timer.
Context
A local LDP session uses the following timers.
Table 2-1 Timers for a local LDP session
LDP Timers Description Suggestion
Link Hello send Used to send Hello messages On an unstable network, decrease the
timer periodically to notify a peer LSR value of a link Hello send timer,
of the local LSR's presence and speeding up network fault detection.
establish a Hello adjacency.
Similar to a remote LDP session,
a local LDP session uses a link
Hello send timer.
Link Hello hold Used to exchange Hello On a network with unstable links or a
timer messages periodically between large number of packets, increase the
two LDP peers to maintain the value of the link Hello hold timer,
Hello adjacency. If no Hello preventing a local LDP session from
message is received after the link being torn down and set up frequently.
Hello hold timer expires, the
Hello adjacency is torn down.
Similar to a remote LDP session,
a local LDP session uses a link
Hello hold timer.
KeepAlive send Used to send KeepAlive On an unstable network, set a smaller

timer messages periodically, value for a KeepAlive send timer,
maintaining the local LDP speeding up network fault detection.
session.
KeepAlive hold Used to send LDP PDUs over an On a network with unstable links,
timer LDP session, maintaining the increase the value of the KeepAlive
local LDP session. If no LDP hold timer, preventing the local LDP
PDU is received after the session from flapping.
KeepAlive hold timer expires,
the TCP connection is closed and
the local LDP session is
terminated.

LDP Timers Description Suggestion
Exponential Started by an LSR that plays an l When a device is upgraded, prolong

backoff timer active role after an LDP the period for the active role to retry
Initialization message sent by setting up a session. In this case, you
the LSR to another LSR that can set larger initial and maximum
plays a passive role fails to be values for the Exponential backoff
processed or parameters carried timer.
in the message are rejected. The l When a device that bears services
LSP that plays the active role tends to alternate between Up and
periodically resends an LDP Down, shorten the period for the
Initialization message to initiate active role to retry setting up a
an LDP session before the session. In this case, you can set
Exponential backoff timer smaller initial and maximum values
expires. for the Exponential backoff timer.
Using default values of these timers are recommended.
Procedure
l Perform the following steps to configure a link Hello send timer:
1. Run:
system-view

2. Run:

3. Run:
mpls ldp timer hello-send interval
A link Hello send timer is configured.

The default value of a link Hello send timer is one third of the value of a link Hello
hold timer.
Effective value of a link Hello send timer = Min { Configured value of the link Hello
send timer, one third of the value of the link Hello hold timer }
l Perform the following procedure to configure a link Hello hold timer:
1. Run:
system-view

2. Run:

3. Run:
mpls ldp timer hello-hold interval

A link Hello hold timer is configured.
The default value of a link Hello hold timer is 15, in seconds.
A smaller value between two configured link Hello hold timers on both ends of the
LDP session takes effect.
l Configure a KeepAlive send timer.
1. Run:
system-view

2. Run:

3. Run:
mpls ldp timer keepalive-send interval
A KeepAlive send timer is configured.
The default value of a KeepAlive send timer is one third of the value of the KeepAlive
hold timer.
Effective value of a KeepAlive send timer = Min { Configured value of the KeepAlive
send timer, one third of the value of the KeepAlive hold timer }
If more than one LDP-enabled links connect two LSRs, the values of KeepAlive send
timers for all links must be the same. Otherwise, LDP sessions become unstable.
NOTICE
Changing the value of a KeepAlive send timer may lead to reestablishment of related
LDP sessions.
l Configure a KeepAlive hold timer.

1. Run:
system-view

2. Run:

3. Run:
mpls ldp timer keepalive-hold interval
A KeepAlive hold timer is configured.
The default value of a KeepAlive hold timer is 45, in seconds.
A smaller value between two configured KeepAlive hold timers on both ends of the
LDP session takes effect.

If more than one LDP-enabled links connect two LSRs, the values of KeepAlive hold
timers for all links must be the same. Otherwise, LDP sessions may fail to be set up.
NOTICE
Changing the value of a KeepAlive hold timer may lead to reestablishment of related
LDP sessions.
l Configure an Exponential backoff timer.

1. Run:
system-view

2. Run:
mpls
The MPLS view is displayed.

3. Run:
quit

4. Run:
mpls ldp

5. Run:
backoff timer init max
An Exponential backoff timer is configured. Note the following settings:
– init: specifies the initial value of an Exponential backoff timer. The value is an
integer ranging from 5 to 2147483, in seconds. The default value is 15.
– max: specifies the maximum value of an Exponential backoff timer. The value is
an integer ranging from 5 to 2147483, in seconds. The default value is 120.
NOTE
Setting the initial value equal to or greater than 15 and the maximum value equal to or greater
than 120 is recommended.
The backoff timer command helps the active role adjust the interval between attempts
to establish an LDP session.
– The initial and maximum values can be increased to allow a longer interval between
attempts to establish an LDP session during device upgrade.
– The initial and maximum values can be decreased to allow a shorter interval
between attempts to establish an LDP session if intermittent service interruptions
occur.
----End


After a local LDP session has been configured, you can view information about interfaces
enabled with MPLS and LDP, the LDP session status, LDP peers, and remote LDP peers.
Prerequisites
A local LDP session has been configured.
Procedure
l Run the display mpls interface [ interface-type interface-number ] [ verbose ] command
to check information about MPLS-enabled interfaces.
l Run the display mpls ldp [ all ] [ verbose ] command to check LDP information.
l Run either of the following commands to check information about LDP-enabled interfaces:
– display mpls ldp interface [ interface-type interface-number | verbose ]
– display mpls ldp interface [ all ] [ verbose ]
l Run either of the following commands to check the LDP session status:
– display mpls ldp session [ verbose | peer-id ]
– display mpls ldp session [ all ] [ verbose ]
l Run either of the following commands to check information about LDP peers:
– display mpls ldp peer [ verbose | peer-id ]
– display mpls ldp peer [ all ] [ verbose ]
----End
Example
Run the display mpls interface command to view information about all MPLS-enabled
interfaces.
<HUAWEI> display mpls interface
Interface Status TE Attr LSP Count CRLSP Count Effective MTU
Pos1/0/0 Up Dis 0 0 1500
Run the display mpls ldp command to view global LDP information, including timers.
<HUAWEI> display mpls ldp
LDP Global Information
--------------------------------------------------------------------------
Protocol Version : V1 Neighbor Liveness : 600 Sec
Graceful Restart : Off FT Reconnect Timer : 300 Sec
MTU Signaling : On Recovery Timer : 300 Sec
Capability-Announcement : On Longest-match : On
mLDP P2MP Capability : Off mLDP MBB Capability : Off
mLDP MP2MP Capability : Off
LDP Instance Information
--------------------------------------------------------------------------
Instance ID : 0 VPN-Instance :
Instance Status : Active LSR ID : 4.4.4.4
Loop Detection : Off Path Vector Limit : 32
Label Distribution Mode : Ordered
Label Retention Mode : Liberal(DU)/Conservative(DOD)
Instance Deleting State : No Instance Reseting State : No
Graceful-Delete : Off Graceful-Delete Timer : 5 Sec

--------------------------------------------------------------------------
Run the display mpls ldp interface [ verbose ] command to view LDP-enabled interface
information, including transport addresses and timers.
<HUAWEI> display mpls ldp interface
LDP Interface Information in Public Network

Codes:LAM(Label Advertisement Mode), IFName(Interface name)
A '*' before an interface means the entity is being deleted.
------------------------------------------------------------------------------
IFName Status LAM TransportAddress HelloSent/Rcv
------------------------------------------------------------------------------
Pos1/0/0 Active DU 172.17.1.1 2495/2514
GE2/0/0 Active DU 172.17.1.1 1106/1094
------------------------------------------------------------------------------
<HUAWEI> display mpls ldp interface verbose

------------------------------------------------------------------------------
Interface Name : Pos1/0/0
LDP ID : 1.1.1.1:0 Transport Address : 1.1.1.1
Entity Status : Active Effective MTU : 1500
Configured Hello Hold Timer : 15 Sec

Negotiated Hello Hold Timer : 15 Sec
Configured Hello Send Timer : 2 Sec
Configured Keepalive Hold Timer : 45 Sec
Configured Keepalive Send Timer : 3 Sec
Configured Delay Timer : 0 Sec
Label Advertisement Mode : Downstream Unsolicited
Hello Message Sent/Rcvd : 29913/29878 (Message Count)
Entity Deletion Status : No
mLDP P2MP Capability : Enable
mLDP MP2MP Capability : Disable
------------------------------------------------------------------------------
Run the display mpls ldp session [ verbose ] command. The command output shows that the
LDP session status is Operational.
<HUAWEI> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
------------------------------------------------------------------------------
PeerID Status LAM SsnRole SsnAge KASent/Rcv
------------------------------------------------------------------------------
2.2.2.2:0 Operational DU Passive 0000:01:36 387/386
------------------------------------------------------------------------------
TOTAL: 2 session(s) Found.
<HUAWEI> display mpls ldp session verbose

------------------------------------------------------------------------------
Peer LDP ID : 2.2.2.2:0 Local LDP ID : 1.1.1.1:0
TCP Connection : 1.1.1.1 <- 2.2.2.2
Session State : Operational Session Role : Passive
Session FT Flag : Off MD5 Flag : Off
Reconnect Timer : --- Recovery Timer : ---
Keychain Name : kc1
Negotiated Keepalive Hold Timer : 45 Sec

Keepalive Message Sent/Rcvd : 438/438 (Message Count)
Label Resource Status(Peer/Local) : Available/Available

Session Age : 0000:01:49 (DDDD:HH:MM)

Session Deletion Status : No
Capability:
Capability-Announcement : On
mLDP P2MP Capability : Off
mLDP MBB Capability : Off
Outbound&Inbound Policies Applied :

outbound peer 2.2.2.2 fec none
outbound peer all split-horizon
inbound peer 2.2.2.2 fec none
Addresses received from peer: (Count: 3)

10.1.1.2 2.2.2.2 10.1.2.1
------------------------------------------------------------------------------
Run the display mpls ldp peer command to view LDP peer information.
<HUAWEI> display mpls ldp peer
LDP Peer Information in Public network
A '*' before a peer means the peer is being deleted.
------------------------------------------------------------------------------
PeerID TransportAddress DiscoverySource
------------------------------------------------------------------------------
2.2.2.2:0 2.2.2.2 Remote Peer : rtb
Serial0/0/0
3.3.3.3:0 3.3.3.3 Remote Peer : rtc
------------------------------------------------------------------------------
TOTAL: 2 Peer(s) Found.
2.3 Configuring a Remote LDP Session

ikA remote LDP session needs to be configured if both L2VPN and LDP over TE are configured.

Before configuring a remote LDP session, familiarize yourself with the usage scenario, complete
Usage Scenario
A remote LDP session supports the following applications:
l Allocating inner labels for L2VPN
If a Martini VLL or VPLS connection is to be established between two LSRs, the remote
LDP session must be established between the LSRs to allocate inner labels.
l Configuring LDP over TE
If the core area on an MPLS network supports TE and the edge devices run LDP, two LSRs
at the edge establish the remote LDP session. LDP over TE allows a TE tunnel to function
as a hop on an LDP LSP.
When LDP LSPs carry L2VPN and L3VPN services, you can configure an LSR ID for each
remote LDP session on the LSR to isolate VPN services.

Before configuring a remote LDP session, configure static routes or an IGP to implement
reachable routes between LSRs.
Data Preparation
To configure a remote LDP session, you need the following data.
No. Data
1 LSR ID of every LSR
2 (Optional) LSR ID of the remote LDP session
2 (Optional) Values of the following LDP timers:

l Target Hello hold timer
l Target Hello send timer
l Keepalive send timer
l Keepalive hold timer
l Exponential backoff timer
2.3.2 Configuring Global LDP

Global LDP must be enabled on each LSR before LDP services are configured in an MPLS
domain.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls lsr-id lsr-id
An LSR ID is set for the local LSR.
Note the following when configuring an LSR ID:

l LSR IDs must be set before other MPLS commands are run.
l No default LSR ID is provided and the LSR ID needs to be configured.
l Using the IP address of a loopback interface as the LSR ID is recommended for an LSR.
l Before a configured LSR ID is changed, the undo mpls command must be run in the system
view to delete all MPLS configurations.

NOTICE
After the undo mpls command is run, all MPLS configurations including LDP sessions and
LSPs will be deleted and services will be interrupted. Correctly plan and set all LSR IDs for
LSRs on an MPLS network to prevent this problem.
Step 3 Run:
mpls

By default, no node is enabled with MPLS globally.
Step 4 Run:
quit

Step 5 Run:
mpls ldp
LDP is enabled globally and the MPLS-LDP view is displayed.

By default, no node is enabled with LDP globally.
lsr-id lsr-id
An LSR ID is set for an LDP instance.

The default LSR ID of an LDP instance is the LSR ID of the LSR where the LDP instance is
configured. Using the default value is recommended.
----End
2.3.3 (Optional) Configuring the Dynamic LDP Advertisement

Capability
On LSRs enabled with global LDP, the dynamic LDP advertisement capability allows extended
LDP functions to be dynamically enabled or disabled when the LDP session is working properly,
ensuring stable LSP operation.
Context
On an LSR disabled from the dynamic LDP negotiation capability, if an extended LDP function
is enabled after an LDP session has been created, the LDP session will be interrupted and the
extended LDP function will be negotiated, affecting LSP stability. The dynamic LDP
advertisement capability allows an extended LDP function to be enabled or disabled dynamically
during proper operation of an LDP session, ensuring LSP stability.
NOTE
Enabling this function immediately after LDP is enabled globally is recommended. The dynamic LDP
advertisement capability does not affect existing LDP functions.
Before the dynamic LDP advertisement capability is enabled, MPLS and LDP must be enabled globally.

Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
capability-announcement
The dynamic LDP advertisement capability is enabled.
By default, the dynamic LDP advertisement capability is not enabled.
NOTE
Enabling dynamic LDP advertisement after an LDP session is established will result in reestablishment of
the LDP session.
----End
2.3.4 (Optional) Enabling LDP Loop Detection Negotiation

If the NE80E/40E is connected to a device enabled with LDP loop detection, the NE80E/40E
must obtain the capability of negotiating LDP loop detection before being able to set up an LDP
session with the peer device.
Context
The NE80E/40E does not support LDP loop detection. To establish an LDP session with a device
enabled with LDP loop detection, the NE80E/40E needs to be enabled with the capability of
negotiating LDP loop detection.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
loop-detect
LDP loop detection negotiation is enabled. This allows the NE80E/40E to negotiate LDP
parameters during the initialization phase and establish an LDP session with a peer device that
is enabled with LDP loop detection.

NOTE
After the loop-detect command is run, the NE80E/40E obtains the capability of negotiating LDP loop
detection but still does not support LDP loop detection.

path-vectors integer
The maximum value of a path vector is specified.
A path vector is carried in a Mapping message to record the addresses of nodes that an LDP LSP
has passed. By setting the maximum hops that a path vector can record, you can adjust the
sensitivity of LDP loop detection. If the maximum hops of a path vector is n, the egress LSP
triggered by local routes detects a loop after n + 1 hops, and the egress LSP triggered by non-
local routes detects a loop after n hops.
----End
2.3.5 Configuring a Remote LDP Session

MPLS and MPLS LDP must be enabled globally before a remote LDP session is configured.
Context
A remote LDP session can be established between two indirectly connected LSRs or two directly
connected LSRs.
A local LDP session and a remote LDP session can be established simultaneously between two
LSRs.
When a local LDP session and a remote LDP session are established between two LSRs, the
configurations that both the local and remote LDP sessions support must be the same.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp remote-peer remote-peer-name
A remote MPLS LDP peer is created, and the peer MPLS-LDP view is displayed.
Step 3 Run:
remote-ip ip-address [ pwe3 ]
The IP address of the remote MPLS LDP peer is specified.
PEs on both ends of an MPLS L2VPN that runs LDP signaling can establish a remote LDP
session. The MPLS L2VPN can be a Martini VLL, PWE3, or Martini VPLS network. The remote
LDP session is expected to transmit Label Mapping messages carrying VC labels, not LDP
labels. By default, the PE distributes LDP labels to its peer. To disable the PE from distributing
LDP labels to its peer, configure pwe3 in the remote-ip command to disable the PE from
distributing LDP labels to a specified remote LDP peer.

NOTE
l The IP address must be the local LSR ID of the current LDP session on the remote LDP peer.
l Modifying or deleting a configured IP address of a remote peer also deletes the remote LDP session.
l If a remote peer IP address is specified using the remote-ip ip-address command, ip-address cannot
be used as a local interface IP address. If it is used as a local interface IP address, the remote LDP
session is interrupted.
----End
2.3.6 (Optional) Disabling a Device from Distributing Labels to

Remote Peers
You can disable a device from distributing LDP labels to remote peers when a remote LDP
session between the device and its remote LDP peer is established to transmit Label Mapping
messages carrying VC labels within an MPLS L2VPN. This helps prevent LDP label wastes and
minimize memory usage.
Context
PEs on both ends of an MPLS L2VPN that runs LDP signaling can establish a remote LDP
session. The MPLS L2VPN can be a Martini VLL, PWE3, or Martini VPLS network. The remote
LDP session is expected to transmit Label Mapping messages carrying VC labels, not LDP
labels. By default, the PE distributes LDP labels to its peer. To disable the PE from distributing
LDP labels to its peer, perform either of the following operations, which helps prevent LDP
label wastes and minimize memory usage.
l In the LDP view, disable the PE from distributing labels to all remote peers.
l In the view of a specified remote peer, disable the PE from distributing labels to the specified
remote peer.
Procedure
l Disable a device from distributing LDP labels to all remote peers.
1. Run:
system-view

2. Run:
mpls ldp

3. Run:
remote-peer pwe3
The device is disabled from distributing LDP labels to all remote peers.
l Disable a device from distributing labels to a specified remote peer.
1. Run:
system-view

2. Run:

The remote MPLS LDP peer view is displayed.

3. Run:
remote-ip ip-address pwe3
A device is disabled from distributing LDP labels to the specified remote peer.
----End
2.3.7 (Optional) Configuring Timers for a Remote LDP Session

A remote LDP session uses the following timers: target Hello send timer, target Hello hold timer,
Keepalive send timer, Keepalive hold timer, and Exponential backoff timer.
Context
Table 2-2 lists timers that a remote LDP session uses.
Table 2-2 Timers that a remote LDP session uses
Timer Description Usage
Target Hello Sends Hello messages On an unstable network, decrease the

send timer periodically to notify a peer LSR value of a target Hello send timer,
of the local LSR's presence and speeding up network fault detection.
establish a Hello adjacency. The
Hello send timer of LDP remote
session is called Target Hello
send timer.
Target Hello Exchanges Hello messages On a network with unstable links or a

hold timer periodically between two LDP large number of packets, increase the
peers to maintain a Hello value of a target Hello hold timer,
adjacency. If no Hello message is preventing frequent disconnection and
received after the target Hello setup of a remote LDP session.
hold timer expires, the Hello
adjacency is torn down. The
Hello hold timer of LDP remote
session is called Target Hello
hold timer.
Keepalive send Sends Keepalive messages On an unstable network, set a smaller

timer periodically, maintaining the value for a Keepalive send timer,
remote LDP session. speeding up network fault detection.

Timer Description Usage
Keepalive hold Sends LDP PDUs over an LDP On a network with unstable links,
timer session to maintain the remote increase the value of a Keepalive hold
LDP session. If no LDP PDU is timer, preventing a remote LDP
received after the Keepalive hold session from flapping.
timer expires, the TCP
connection is closed and the
remote LDP session is
terminated.
Exponential Started by an LSR that plays an l The initial and maximum values
backoff timer active role after the LSR fails to can be increased to allow a longer
process an LDP Initialization interval between attempts to
message or is notified that establish an LDP session during
another LSR playing a passive device upgrade.
role rejects parameters carried in l The initial and maximum values
the received LDP Initialization can be reduced to allow a shorter
message. The LSR playing the interval between attempts to
active role periodically resends establish an LDP session if
an LDP Initialization message to intermittent service interruptions
initiate an LDP session before occur.
the Exponential backoff timer
expires.
Using default values of these timers are recommended.
Procedure
l Configure a target Hello send timer.
1. Run:
system-view

2. Run:
The remote MPLS-LDP peer view is displayed.

3. Run:
mpls ldp timer hello-send interval
The target Hello send timer is configured.

The default value of the target Hello send timer is one third of the value of a target
Hello hold timer that takes effect.
Effective value of a target Hello send timer = Min {Configured value of the target
Hello send timer, One third of the value of the target Hello hold timer}
l Configure a target Hello hold timer.
1. Run:
system-view


2. Run:

3. Run:
mpls ldp timer hello-hold interval
The target Hello hold timer is configured.
The default value of the target Hello hold timer is 45, in seconds.
The value of the target Hello hold timer configured using the mpls ldp timer hello-
hold command may not be equal to the value of the timer that takes effect. The smaller
value between the timers configured at both ends of a remote LDP session takes effect.
l Configure a Keepalive send timer for a remote LDP session.
1. Run:
system-view

2. Run:

3. Run:
mpls ldp timer keepalive-send interval
A Keepalive send timer is configured.
The default value of the Keepalive send timer is one third of the value of the effective
Keepalive hold timer.
Effective value of a Keepalive send timer = Min {Configured value of the Keepalive
send timer, One third of the effective value of the Keepalive hold timer}
If more than one LDP-enabled links connect to two LSRs, the values of Keepalive
send timers for all links must be the same. Different settings cause the LDP sessions
to be unstable.
NOTICE
Changing the value of a Keepalive send timer causes the reestablishment of related
LDP sessions.
l Configure a Keepalive hold timer for a remote LDP session.

1. Run:
system-view

2. Run:


3. Run:
mpls ldp timer keepalive-hold interval
The Keepalive hold timer is configured.
The default value of the Keepalive hold timer is 45, in seconds.
The value of the Keepalive hold timer configured on the LSR may not be equal to the
value of the timer that takes effect. The smaller value between the timers configured
at both ends of a remote LDP session takes effect.
If there is more than one LDP link between two LSRs, the values of the Keepalive
hold timers configured for the links must be the same. Different settings cause the
LDP sessions to be unstable.
NOTICE
Changing the value of a Keepalive hold timer causes the reestablishment of related
LDP sessions.
l Configure an Exponential backoff timer.

1. Run:
system-view

2. Run:
mpls

3. Run:
quit

4. Run:
mpls ldp

5. Run:
backoff timer init max
The Exponential backoff timer is configured. The following parameters can be

configured:
– init: specifies the initial value of the Exponential backoff timer. The value is an
integer ranging from 5 to 2147483, in seconds. The default value is 15.
– max: specifies the maximum value of the Exponential backoff timer. The value is
an integer ranging from 5 to 2147483, in seconds. The default value is 120.
NOTE
Setting the initial value of the Exponential backoff timer to be greater than or equal to 15s and
the maximum value to be greater than or equal to 120s is recommended.

The backoff timer command can be used to change the interval between attempts to
set up a session. Its usage is as follows:
– When a device is being upgraded, increase the initial and maximum values to set
a large interval between attempts to set up a session.
– When a device that is transmitting services is prone to intermittent interruptions,
reduce the initial and maximum values to set a small interval between attempts to
set up a session.
----End

After configuring a remote LDP session successfully, you can view information about MPLS-
and LDP-enabled interfaces, LDP configurations, LDP session status, LDP peers, and remote
LDP peers.
Prerequisites
The remote LDP session has been configured.
Procedure
l Run the display mpls ldp [ all ] [ verbose ] command to check LDP configurations.
l Run either of the following commands to check the LDP session status:
– display mpls ldp session [ verbose | peer-id ]
– display mpls ldp session [ all ] [ verbose ]
l Run either of the following commands to check information about LDP peers:
– display mpls ldp peer [ verbose | peer-id ]
– display mpls ldp peer [ all ] [ verbose ]
l Run the display mpls ldp remote-peer [ remote-peer-name ] command to check
information about remote LDP peers.
----End
Example
Run the display mpls ldp command to view global LDP information, including timers.
--------------------------------------------------------------------------
Capability-Announcement : On Longest-match : On
--------------------------------------------------------------------------


--------------------------------------------------------------------------
Run the display mpls ldp interface [ verbose ] command to view LDP-enabled interface
information, including transport addresses and timers.
<HUAWEI> display mpls ldp interface

Codes:LAM(Label Advertisement Mode), IFName(Interface name)
A '*' before an interface means the entity is being deleted.
------------------------------------------------------------------------------
IFName Status LAM TransportAddress HelloSent/Rcv
------------------------------------------------------------------------------
Pos1/0/0 Active DU 172.17.1.1 2495/2514
GE2/0/0 Active DU 172.17.1.1 1106/1094
------------------------------------------------------------------------------
<HUAWEI> display mpls ldp interface verbose

------------------------------------------------------------------------------
Interface Name : Pos1/0/0
LDP ID : 1.1.1.1:0 Transport Address : 1.1.1.1
Entity Status : Active Effective MTU : 1500

Configured Hello Send Timer : 2 Sec
Hello Message Sent/Rcvd : 29913/29878 (Message Count)
Entity Deletion Status : No
mLDP P2MP Capability : Enable
mLDP MP2MP Capability : Disable
------------------------------------------------------------------------------
Run the display mpls ldp session [ verbose ] command. The command output shows that the
LDP session status is Operational.
<HUAWEI> display mpls ldp session
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------

------------------------------------------------------------------------------
TCP Connection : 1.1.1.1 <- 2.2.2.2
Keychain Name : kc1



Capability:


10.1.1.2 2.2.2.2 10.1.2.1
------------------------------------------------------------------------------
Run the display mpls ldp peer command to view LDP peer information.
<HUAWEI> display mpls ldp peer
------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.2:0 2.2.2.2 Remote Peer : rtb
Serial0/0/0
3.3.3.3:0 3.3.3.3 Remote Peer : rtc
------------------------------------------------------------------------------
Run the display mpls ldp remote-peer command to view remote LDP peer information.
<HUAWEI> display mpls ldp remote-peer
LDP Remote Entity Information

------------------------------------------------------------------------------
Remote Peer Name : lsrc
Remote Peer IP : 3.3.3.9 LDP ID : 1.1.1.9:0
Transport Address : 1.1.1.9 Entity Status : Active

Configured Keepalive Send Timer : ---
Configured Hello Send Timer : ---
Hello Packet sent/received : 61/59
Remote Peer Deletion Status : No
Auto-config : ---
------------------------------------------------------------------------------
2.4 Configuring LDP LSPs

LDP can distribute labels to establish LSPs in an MPLS domain.


Before configuring LDP LSPs, familiarize yourself with the usage scenario, complete the pre-
Usage Scenario
LDP is used to distribute labels on an MPLS network and establish LSPs automatically in the
situation where paths for the LSPs do not need to be specified and traffic engineering (TE) does
not need to be deployed on the MPLS network.
The number of LSPs that an LSR supports depends on the capacity and performance of the LSR.
A large number of LSPs probably lead to unstable LSR operation.
LSPs can be established based on eligible routes and a policy for triggering LSP establishment.
The LSP establishment policy filters out unqualified routes and allows LDP to use eligible routes
to establish LSPs and control the number of LSPs.
Policies for triggering the LSP establishment are used based on the following types of LSPs:
l Ingress or egress LSPs can be established based on the following policies:

– All static routes and IGP routes trigger LSP establishment.
– Labeled public network BGP routes to destination addresses with 32-bit masks trigger
LSP establishment. For the configuration procedure, see the chapter "BGP/MPLS IP
VPN Configuration" in the HUAWEI NetEngine80E/40E Router Configuration Guide
- VPN.
– Host routes trigger LSP establishment.
– Routes matching an IP prefix list triggers LSP establishment.
– No route triggers LSP establishment.
l Transit LSPs can be established based on an IP prefix list. The IP prefix list is used to filter
out unqualified routes and allow LDP to use only eligible routes to establish LSPs.
Before configuring LDP LSPs, configure a local LDP session.
Data Preparation
To configure LDP LSPs, you need the following data.
No. Data
1 LSR ID of each LSR
2.4.2 Establishing LDP LSPs

An LDP LSP is automatically established after an LDP session is established.

Prerequisites
The task described in 2.2 Configuring a Local LDP Session is complete.
Context
An MPLS LDP session is configured between each pair of adjacent LSRs along an LSP to be
established. After MPLS LDP sessions are established, LDP LSPs are automatically established.
2.4.3 (Optional) Configuring PHP

Penultimate hop popping (PHP) can be configured on the egress to allocate a label to an LSR at
the penultimate hop, helping relieve the burden on the egress.
Context
No label needs to be swapped on the egress of an LSP. PHP can be configured on the egress to
allow the LSR at the penultimate hop to pop out the label from an MPLS packet and send the
packet to the egress. After receiving the packet, the egress directly forwards the unlabeled IP
packet or the single-labeled packet. PHP helps reduce the burden on the egress.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
label advertise { explicit-null | implicit-null | non-null }
The label allocated to the LSR at the penultimate hop is configured. One of the following
parameters can be configured in this command:
l implicit-null: is the default value and means that PHP is supported. If this parameter is
configured, the egress allocates an implicit null label with the value of 3 to the LSR at the
penultimate hop.
l explicit-null: means that PHP is not supported. If this parameter is configured, the egress
allocates an explicit null label with the value of 0 to the LSR at the penultimate hop. The
explicit-null parameter can be configured when MPLS QoS attributes are used.
l non-null: means that PHP is not supported. If this parameter is configured, the egress
allocates a common label with a value greater than or equal to 16 to the LSR at the penultimate
hop.
Exercise caution when using the explicit-null or non-null parameter. The setting leads to a great
deal of resource consumption on the egress.

NOTE
PHP takes effect on LSPs that will be established after PHP is configured.
----End
2.4.4 (Optional) Configuring an LDP Label Advertisement Mode

An LDP label advertisement mode can be configured to control LSP establishment.
Context
A downstream LSR sends a Label Mapping message to an upstream LSR in downstream
unsolicited mode (DU) by default. This allows multiple LSPs including backup LSPs to be
established. If a network fault occurs, services rapidly switch to a backup LSP, improving
network reliability. Establishing a large number of LSPs burdens an LSR such as a digital
subscriber link access multiplexer (DSLAM) that is a low-performance access device deployed
on an MPLS network. On a large-scale network, a DSLAM can be configured to send Label
Mapping messages to only upstream LSRs only after receiving requests for labels. This
minimizes the number of unwanted MPLS forwarding entries forwarded by the DSLAM.
Procedure
l Configuring an LDP Label Advertisement Mode of local LDP session.
1. Run:
system-view

2. Run:
The interface view is displayed.

3. Run:
mpls ldp advertisement { dod | du }
A label advertisement mode is configured.
NOTE
l A pair of LDP peers must have the same label advertisement mode. Inconsistency in label
advertisement modes causes the two LDP peers to fail to establish LDP LSPs between them
over multiple links.
l Modifying a configured label advertisement mode leads to the reestablishment of an LDP
session, resulting in service interruptions.
l Configuring an LDP Label Advertisement Mode of remote LDP session.
1. Run:
system-view

2. Run:
The remote MPLS LDP peer is created and the remote MPLS LDP peer view is
displayed.

3. Run:
mpls ldp advertisement { dod | du }
A label advertisement mode is configured.
NOTE
When the local and remote LDP sessions coexist, they must have the same label advertisement
mode.
----End
2.4.5 (Optional) Configuring LDP to Automatically Trigger the

Request in DoD Mode
A remote LDP session must be configured before LDP is configured to automatically send
requests in Downstream-on-Demand (DoD) mode
Context
On a large-scale network with a great number of remote LDP peers deployed, DSLAMs that are
low-end devices on the edge of the network cannot ensure network stability or prevent wasting
resources. Run the remote-ip auto-dod-request command or the remote-peer auto-dod-
request command to configure the function of triggering a request to a downstream node for a
Label Mapping message associated with all remote LDP peers or a remote LDP peer with a
specified LSR ID in DoD mode, which can save system resources.
To disable an LSR from automatically sending a request to a downstream node for a Label
Mapping message associated with a specified LSR ID in DoD mode, you can run the remote-
ip auto-dod-request block command.
NOTE
l A remote LDP session must be configured before the remote-peer auto-dod-request or remote-ip
auto-dod-request command is run.
l Run the longest-match command to configure LDP extension for inter-area LSPs before running the
remote-peer auto-dod-request or remote-ip auto-dod-request command.
l The mpls ldp advertisement dod command must be run to create an LDP session with a downstream
node in DoD mode before you run the remote-peer auto-dod-request or remote-ip auto-dod-
request command.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 You can perform either of the following procedures to enable a device to automatically send
DoD requests for Label Mapping messages to a specified or all downstream remote LDP peers.

l To enable the device to automatically send DoD requests for Label Mapping messages to all
downstream remote LDP peers, run:
remote-peer auto-dod-request
l You can perform the following procedures to enable the device to automatically send DoD
requests for Label Mapping messages to a specified downstream remote LDP peer.
1. Run:
quit

2. Run:
The remote MPLS LDP peer is created, and the remote MPLS LDP peer view is
displayed.
3. Run:
remote-ip ip-address
The IP address of the remote MPLS LDP peer is configured.
NOTE
l This IP address must be the LSR ID that the remote LDP peer uses to establish the existing
remote LDP session.
l Modifying or deleting the configured address of a remote peer also deletes the remote LDP
session.
4. Run:
remote-ip auto-dod-request
The device is enabled to automatically send DoD requests for Label Mapping messages
to a specified downstream remote LDP peer.
NOTE
To disable the function of the remote-peer auto-dod-request command, run the remote-ip auto-
dod-request block command.
----End
2.4.6 Configuring an MPLS MTU on an Interface

An MPLS MTU can be configured on an interface to determine the maximum size of MPLS
packets that can be forwarded each time.
Context
MTU is short for maximum transmission unit. An MTU value determines the maximum number
of bytes each time a sender can send. If the size of packets exceeds the MTU supported by a
transit node or a receiver, the transit node or receiver fragments the packets or even discards
them, aggravating the network transmission load. MTU values must be correctly negotiated
between LSRs to allow packets to successfully reach the receiver.
LDP MTU = Min { All MTUs advertised by downstream devices, Local outbound interface
MTU }
A downstream LSR uses the preceding formula to calculate an MTU value, adds it to the MTU
TLV in a Label Mapping message, and sends the Label Mapping message upstream.
If an MTU value changes (such as when the local outbound interface or its configuration is
changed), an LSR recalculates an MTU value and sends a Label Mapping message carrying the

new MTU value upstream. The comparison process repeats to update MTU information along
an LSP.
The relationships between the MPLS MTU and the interface MTU are as follows:
l If an interface MTU but not an MPLS MTU is configured on an interface, the interface
MTU is used.
l If both an MPLS MTU and an interface MTU are configured on an interface, the smaller
value between the MPLS MTU and the interface MTU is used.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of an MPLS-enabled interface is displayed.

Step 3 Run:
mpls mtu mtu
An MPLS MTU is configured on the interface.
NOTE
The configured MPLS MTU takes effect immediately and there is no need to restart the interface.
----End
2.4.7 (Optional) Configuring LDP MTU Signaling

LDP MTU signaling can be configured to control which MTU TLV to be sent.
Context
An MPLS LDP-enabled LSR by default sends a Huawei proprietary MTU TLV different from
the MTU TLV defined in RFC 3988.
l Using the default MTU setting is recommended.
l Before a Huawei device is interconnected to a non-Huawei device, run the mtu-
signalling apply-tlv command on the Huawei device. This command allows the Huawei
device to send the MTU TLV in compliance with RFC 3988 to the non-Huawei device. If
this command is not run, a configured LDP MTU may fail to take effect.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls ldp

Step 3 Run:
mtu-signalling [ apply-tlv ]
The function to send an MTU TLV is enabled.
The system sends a Huawei proprietary MTU TLV by default.
NOTE
Enabling or disabling the function to send an MTU TLV leads the reestablishment of existing LDP sessions.
----End
2.4.8 (Optional) Configuring an LDP Split Horizon Policy

An LDP split horizon policy can be configured to prevent an LSR from distributing labels to a
specified downstream LDP peer.
Context
An LSR sends Label Mapping messages to both upstream and downstream LDP peers by default,
speeding up LDP LSP convergence. DSLAMs functioning as access devices on an MPLS
network have low performance. All LDP peers (DSLAMs) by default exchange labels with each
other to establish a large number of LSPs. As a result, the DSLAMs are heavily burdened. An
LDP split horizon policy can be configured to reduce the number of unwanted LSPs and
efficiently use memory.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
outbound peer { peer-id | all } split-horizon
A split horizon policy is configured to distribute labels to only upstream LDP peers.
By default, split horizon is not enabled and an LSR distributes labels to both upstream and
downstream LDP peers.
In the outbound peer command, configure either of the following parameters to prevent an LSR
from distributing labels to specified downstream peers:
l peer-id: prevents the LSR from distributing labels to a specified downstream peer.
l all: prevents the LSR from distributing labels to all downstream peers.

NOTE
The all parameter takes preference over the peer-id parameter. For example, the outbound peer all split-
horizon and then outbound peer 2.2.2.2 split-horizon commands are run, the outbound peer all split-
horizon command can be saved in the configuration file and take effect, not the outbound peer 2.2.2.2
split-horizon command.
----End
2.4.9 (Optional) Configuring the Inbound and Outbound LDP

Policies
An inbound LDP policy and an outbound LDP policy can be configured to prevent the
establishment of unwanted LSPs, efficiently using memory.
Context
An LSR is usually able to receive Label Mapping messages from all LDP peers or send Label
Mapping messages to both upstream and downstream LDP peers, speeding up LDP LSP
convergence. This leads to a great number of unwanted LSPs to be established, wasting
resources. An inbound LDP policy can be configured to reduce the number of Label Mapping
messages to be received; an outbound LDP policy can be configured to reduce the number of
Label Mapping messages to be sent. The inbound and outbound LDP policies help reduce the
number of unwanted LSPs to be established and efficiently use memory.
Procedure
l Configure an inbound LDP policy.
1. Run:
system-view

2. Run:
mpls ldp

3. Run:
inbound peer { peer-id | peer-group peer-group-name | all } fec { none |
host | ip-prefix prefix-name }
An inbound policy for allowing the local LSR to receive label mapping messages from
a specified LDP peer for a specified IGP route is configured.
To apply a policy associated with a single FEC range to an LDP peer group or all LDP
peers from which the local LSR receive Label Mapping messages, configure either
the peer-group peer-group-name or all parameter in the command.

NOTE
If multiple inbound policies are configured for a specified LDP peer, the first configured one
takes effect. For example, the following two inbound policies are configured:
inbound peer 2.2.2.2 fec host
inbound peer peer-group group1 fec none
As group1 also contains an LDP peer with peer-id of 2.2.2.2, the following inbound policy
takes effect:
If two inbound policies are configured in sequence and the peer parameters in the two
commands are the same, the second command overwrites the first one. For example, the
following two inbound policies are configured:
The second configuration overwrites the first one. This means that the following inbound policy
takes effect on the LDP peer with peer-id of 2.2.2.2:
MPLS and MPLS LDP must be enabled globally before an inbound policy is configured.
To delete all inbound policies simultaneously, run the undo inbound peer all command.
l Configure an outbound LDP policy.
1. Run:
system-view

2. Run:
mpls ldp

3. Perform either of the following steps to apply the outbound policy that allows Label
Mapping messages for specified routes to be sent to a specified LDP peer:
– To configure an outbound policy that allows Label Mapping messages for specified
IGP routes to be sent to a specified LDP peer, run:
outbound peer { peer-id | peer-group peer-group-name | all } fec
{ none | host | ip-prefix prefix-name }
– To configure an outbound policy that allows Label Mapping messages for specified
labeled BGP routes to be sent to a specified LDP peer, run:
outbound peer { peer-id | peer-group peer-group-name | all } bgp-label-
route { none | ip-prefix prefix-name }
To apply a policy associated with a single FEC range to an LDP peer group or all LDP
peers to which the local LSR sends Label Mapping messages, configure either the
peer-group peer-group-name or all parameter in the command.

NOTE
If multiple outbound policies are configured for a specified LDP peer, the first configured one
takes effect. For example, the following two outbound policies are configured:
outbound peer 2.2.2.2 fec host
outbound peer peer-group group1 fec none
As group1 also contains an LDP peer with peer-id of 2.2.2.2, the following outbound policy
takes effect:
If two outbound policies are configured in sequence and the peer parameters in the two
commands are the same, the second command overwrites the first one. For example, the
following two outbound policies are configured:
The second configuration overwrites the first one. This means that the following outbound
policy takes effect on the LDP peer with peer-id of 2.2.2.2:
MPLS and MPLS LDP must be enabled globally before an outbound policy is configured.
To delete all outbound policies simultaneously, run the undo outbound peer all command.
----End
2.4.10 (Optional) Configuring a Policy for Triggering LDP LSP

Establishment
A policy can be configured to allow LDP to establish LSPs based on eligible routes.
Context
After MPLS LDP is enabled, LSPs are automatically established. If no policy is configured, an
increasing number of LSPs are established, wasting resources.
A policy can be configured to allow LDP to use eligible routes to establish ingress and egress
LSPs on a public network. The policy allows only specified routes to trigger LDP LSP
establishment, controlling the number of LSPs and minimizing resource wastes.
NOTE
Do not use the lsp-trigger all command. If this command is run, all IGP routes can be used by LDP to
establish LSPs. This causes a large number of unwanted LSPs to be established, wasting system resources.
Before using the lsp-trigger all command, configure a policy for filtering out routes that LDP will not use
to establish LSPs. This reduces the number of LSPs to be established and saves system resources.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls

Step 3 Perform either of the following steps to configure a policy for triggering LDP LSP establishment:
l To allow static routes and IGP routes to trigger LDP LSP establishment, run:
lsp-trigger { all | host | ip-prefix ip-prefix-name | none }
l To allow labeled public network BGP routes to trigger LDP LSP establishment, run:
lsp-trigger bgp-label-route [ ip-prefix ip-prefix-name ]
One of the following parameters can be configured for a trigger policy:
l host: is the default policy and allows LDP to use 32-bit host-address route ( except 32-bit
host-address of interfaces ) to establish LSPs.
l all: allows LDP to use all static and IGP routes, but not public network BGP routes, to
establish LSPs.
l ip-prefix: allows LDP to use the routes that match an IP address prefix list to establish LSPs.
l none: does not allow LDP to use any routes to establish LSPs.
l bgp-label-route: allows LDP to use labeled public network BGP routes to establish LSPs.
NOTE
LSPs can be established using exactly matching routes on LSRs. For example, an exactly matching host
route to an IP address with a 32-bit mask of a loopback interface can be used to trigger LSP establishment.
A policy for triggering LSP establishment cannot be modified during the LDP graceful restart (GR) process.
Step 4 Run:
proxy-egress disable
A policy for disabling a device from establishing proxy egress LSPs is configured.
If the current policy allows a device to establish LSPs for all static and IGP routes or use an IP
address prefix list to establish LSPs, the policy also triggers proxy egress LSP establishment.
However, the proxy egress LSPs may be unavailable, which wastes system resources. To prevent
this problem, run the proxy-egress disable command to disable a device from establishing such
proxy egress LSPs.
NOTE
During the LDP GR, the proxy-egress disable command cannot be run.
----End
2.4.11 (Optional) Configuring a Policy for Triggering Transit LSP

Establishment
A policy for triggering transit LSP establishment can be configured to allow LDP to use a
specified route to establish a transit LSP.
Context
After MPLS LDP is enabled, LDP LSPs will be automatically established, leading to a large
number of transit LSPs and resulting in resource wastes. A policy for triggering transit LSP
establishment can be configured to allow LDP to only send Label Mapping messages upstream
for routes that match specified conditions to establish a transit LSP. This reduces the number of
unwanted LSPs and efficiently uses network resources.

Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls ldp

Step 3 Run:
propagate mapping for ip-prefix ip-prefix-name
A policy for triggering transit LSP establishment is configured.

LDP uses all routes without filtering them to establish transit LSPs by default.
NOTE
The policy for triggering transit LSP establishment cannot be modified during the LDP GR process.
----End

After configuring LDP LSPs, you can view information about LDP configurations, LDP LSPs,
and LSPs.
Prerequisites
The LDP LSPs have been established.
Procedure
l Run the display mpls ldp [ all ] [ verbose ] command to check LDP configurations.
l Run the display mpls ldp lsp [ all ] command to check LDP information.
l Run the display mpls lsp [ verbose ] command to check LSP information.
----End
Example
If the configurations succeed, you can run the preceding commands to obtain the following
results:
Run the display mpls ldp command to view LDP information.

--------------------------------------------------------------------------
Capability-Announcement : Off Longest-match : Off


--------------------------------------------------------------------------
--------------------------------------------------------------------------
Run the display mpls ldp lsp command to view LDP LSP information.
<HUAWEI> display mpls ldp lsp
LDP LSP Information

-------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop OutInterface
-------------------------------------------------------------------------------
3.3.3.9/32 NULL/1025 - 10.1.1.2 Pos1/0/0
_-------------------------------------------------------------------------------
TOTAL: 1 Normal LSP(s) Found.
TOTAL: 0 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
A '*' before a UpstreamPeer means the session is stale
A '*' before a DS means the session is stale
A '*' before a NextHop means the LSP is FRR LSP
Run the display mpls lsp command to view LSP information.

<HUAWEI> display mpls lsp
----------------------------------------------------------------------
LSP Information: LDP LSP
----------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
1.1.1.1/32 NULL/3 -/Pos1/0/0
2.5 Configuring LDP Extension for Inter-Area LSP

Configuring LDP extension for inter-area LSP enables LDP to search for routes based on the
longest match rule to establish inter-area LDP LSPs.

Before configuring LDP extension for inter-area LSP, familiarize yourself with the usage
scenario, complete the pre-configuration tasks, and obtain the data required for the configuration.
Usage Scenario
On a large-scale network, multiple IGP areas usually need to be configured for flexible network
deployment and fast route convergence. When advertising routes between IGP areas, to prevent
a large number of routes from consuming too many resources, an area border router (ABR) needs
to aggregate the routes in the area and then advertise the aggregated routes to the neighboring
IGP areas. However, by default, when establishing LSPs, LDP searches the routing table for the
route that exactly matches the forwarding equivalence class (FEC) carried in the received Label
Mapping message. For aggregated routes, only liberal LDP LSPs, not inter-area LDP LSPs, can
be set up.

In this case, you can run the longest-match command to configure LDP to search for routes
based on the longest match rule to establish inter-area LDP LSPs.
Before configuring LDP extension for inter-area LSP, complete the following tasks:
l Assign IP addresses to interfaces to make neighboring nodes on the network layer
reachable.
l Configure an IGP to advertise the network segments connecting to interfaces on each node
and to advertise the routes of hosts with LSR IDs.
l Configure the policy for aggregating routes.
l Configure MPLS and MPLS LDP.
Data Preparation
To configure LDP extension for inter-area LSP, you need the following data.
No. Data
1 IS-IS area ID of each node and level of each node and interface
2.5.2 Configuring LDP Extension for Inter-Area LSPs

LDP extension for inter-area LSPs can be configured on the ingress and transit nodes.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls ldp

Step 3 Run:
longest-match
LDP is configured to search for routes based on the longest match rule to establish LSPs.
NOTE
The longest-match command cannot be run during LDP GR.
----End

After configuring LDP extension for inter-area LSPs, you can view information about the
establishment of inter-Area LSPs.

Prerequisites
The LDP extension for inter-area LSP has been configured.
Procedure
l Run the display mpls lsp command to check the setup of inter-area LSPs after LDP is
configured to search for routes based on the longest match rule to establish LSPs.
----End
Example
Configure LDP to search for routes based on the longest match rule to establish LSPs. 1.3.0.1/32
and 1.3.0.2/32 are routes to another IGP area. Run the display mpls lsp command. The command
output shows that an inter-area LSP has been established.
[HUAWEI] display mpls lsp
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.2.0.1/32 NULL/3 -/GE1/0/0
1.2.0.1/32 1024/3 -/GE1/0/0
1.3.0.1/32 NULL/1025 -/GE1/0/0
1.3.0.1/32 1025/1025 -/GE1/0/0
1.3.0.2/32 NULL/1026 -/GE1/0/0
1.3.0.2/32 1026/1026 -/GE1/0/0
2.6 Configuring the LDP Multi-Instance

You need to configure the LDP multi-instance when deploying the BGP/MPLS IP VPN.

Before configuring the LDP multi-instance, familiarize yourself with the usage scenario,
Usage Scenario
The LDP multi-instance is used on the BGP/MPLS VPN. To configure the LDP multi-instance,
bind LDP to a created IP VPN instance.
Before configuring an LDP multi-instance, complete the following tasks:
l Enable MPLS.
l Enable MPLS LDP.
l Configure the IP VPN instance.
Data Preparation
To configure an LDP multi-instance, you need the following data.

No. Data
1 LSR ID of each node
2 Name of an interface that forwards MPLS packets
3 Name of a VPN instance to be enabled with LDP
4 LSR ID of an LDP instance
2.6.2 Configuring the LDP Multi-Instance

This section describes how to configure the LDP multi-instance. Before you configure the LDP
multi-instance, enable LDP for the specified VPN instance on each node.
Context
To configure the transport address for an LDP instance, you must use the IP address of the
interfaces that are bound to the same VPN instance.
NOTE
In LDP multiple instances, you can use the interface address to establish a session.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp vpn-instance vpn-instance-name
LDP for the specified VPN instance is enabled, and the MPLS LDP VPN instance view is
displayed.
Note the following:
l Configurations in the MPLS LDP VPN instance view only take effect on LDP-enabled
interfaces that are bound to the same VPN instance.
l Configurations in the MPLS LDP view do not take effect on LDP-enabled interfaces that are
bound to the VPN instance.

lsr-id lsr-id
An LSR ID is configured for the LDP VPN instance.
By default, the LDP LSR ID is MPLS LSR ID.

NOTE
In most applications, use the default LDP LSR ID. In some networking schemes that VPN instances are
used, for example, BGP or MPLS VPN, configure an LSR ID separately for the LDP multi-instance to
ensure normal establishment of a TCP connection, if the address space of the VPN overlaps that of the
public network.
----End

After the LDP multi-instance is configured, you can view information about LDP of the specified
VPN instance.
Prerequisites
The LDP multi-instance function has been configured.
Procedure
l Run the display mpls ldp vpn-instance vpn-instance-name command to check information
about LDP of a specified VPN instance.
----End
Example
After completing the configuration, run the display mpls ldp vpn-instance command to view
information about LDP of a specified VPN instance.
<HUAWEI> display mpls ldp vpn-instance vpn1
--------------------------------------------------------------------
Capability-Announcement : On Longest-match : Off
mLDP P2MP Capability : On mLDP MBB Capability : On
--------------------------------------------------------------------
Instance ID : 1 VPN-Instance : vpn1
Label Distribution Mode : Ordered Label Retention Mode : Liberal
2.7 Configuring a Node to Report LSP Fault Locations and

Causes to the Ingress
Nodes on an LDP LSP can be enabled to report the locations and causes of LSP faults to the
ingress. After receiving fault notifications, the ingress notifies the NMS of fault information so
that the NMS is able to associates the root trap with the other traps. Administrators can rectify
the fault only using the root trap information, which improves fault-handling efficiency.

Context
If an LDP LSP is torn down due to a fault, the ingress cannot locate the fault or find the cause.
For example, L2VPN traffic travels through an LDP LSP. If a link fault occurs, the LDP LSP
is torn down, which causes an L2VPN traffic interruption. In addition, the NMS receives several
traps, including the root trap and its associated traps. For example, the LDP LSP failure trap is
the root trap, and the L2VPN failure alarm is an associated trap. The NMS cannot distinguish
between the root trap and its associated traps. Administrators process all traps, which reduces
fault-handling efficiency.
To address this problem, nodes can be configured to report the locations and causes of LSP faults
to the ingress. The ingress then reports fault information to the NMS so that the NMS is able to
associate the root trap with the other traps. Administrators are then able to rectify the fault only
using the root trap information, which improves fault-handling efficiency.
The label withdraw delay function can be configured so that the ingress can obtain the location
and cause of an LSP failure. If a route change causes an LDP LSP failure, the upstream node of
the faulty node may detect the route change and send a Label Withdraw message to instruct the
ingress to tear down the LSP before receiving an LSP Down Reason message from the faulty
node. When the LSP Down Reason message arrives at the upstream node, this node discards the
message because the LSP has been torn down. As a result, the ingress cannot obtain fault
information carried in the LSP Down Reason message. The label withdraw delay function can
be enabled to address this problem.
Perform the following steps on each node of an LDP LSP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
send-message lsp-down-reason
The node is enabled to report the locations and causes of LSP failures to the ingress.
Step 4 Run:
label-withdraw-delay
The label withdraw delay function is enabled.

label-withdraw-delay timer time
The delay time for a Label Withdraw message to be sent is set.
The default delay time is 5 seconds, which is recommended.

NOTE
The label withdraw delay function prevents downstream LSP flapping from spreading to upstream nodes.
For example, an LSP on a local node flaps because an LDP session between the node and its downstream
peer flaps, a route flaps, or an LDP policy is modified. The local node repeatedly sends Label Withdraw
and Label Mapping messages in sequence to upstream nodes. This causes the upstream nodes to repeatedly
tear down and reestablish LSPs. As a result, the entire LDP LSP flaps. The label withdraw delay function
prevents the entire LDP LSP from flapping.
----End
Checking the Configurations

After completing the preceding configuration, run the display this command in the MPLS-LDP
view. The command output shows that the node has been enabled to report LSP fault locations
and causes to the ingress, and the label withdraw delay function has been enabled.
<HUAWEI> system-view
[HUAWEI] mpls ldp
[HUAWEI-mpls-ldp] display this
#
mpls ldp
label-withdraw-delay
send-message lsp-down-reason
#
#
return
2.8 Configuring an Automatic mLDP P2MP Tunnel

An automatic mLDP P2MP tunnel must be configured before it can be automatically established
to transmit multicast services when the multicast services arrive in an IP/MPLS backbone
network.

Before configuring an automatic mLDP P2MP tunnel, familiarize yourself with the usage
Usage Scenario
There is an increasing diversity of multicast services, such as IPTV, massively multiplayer online
role-playing games (MMORPGs), and multimedia conferences. These services are transmitted
over service bearer networks that must meet the following requirements:
l Forward multicast traffic even during traffic congestion.
l Rapidly detect network faults and switch traffic to standby links.
The multicast virtual private LAN service (VPLS) solution meets these requirements. In some
applications, such as IPTV, a fixed multicast source and multiple receivers are configured. To
transmit such applications, when multicast VPLS traffic arrives, the IP/MPLS network enables
nodes to automatically establish an mLDP P2MP tunnel and direct multicast traffic to the tunnel.
This solution eliminates the need to deploy Protocol Independent Multicast (PIM) or hierarchical
virtual private LAN service (HVPLS) and prevents duplicate packets from wasting LSP
bandwidth.

NOTE
After the configuration is complete, an mLDP P2MP tunnel can be established automatically when
multicast VPLS is being deployed.
Before configuring an automatic mLDP P2MP tunnel, configure a local LDP session.
2.8.2 Enabling mLDP P2MP Globally

mLDP P2MP must be enabled globally on nodes along an automatic mLDP P2MP tunnel to be
established.
Context
mLDP P2MP must be globally enabled on LDP peers to establish mLDP P2MP sessions.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
mldp p2mp
mLDP P2MP is enabled globally.
After this step is performed, mLDP P2MP is enabled automatically on all MPLS LDP-enabled
interfaces on the node.
----End
2.8.3 (Optional) Enabling the mLDP Make-Before-Break Capability

On an mLDP network, the make-before-break (MBB) capability can be enabled on each node,
which helps minimize packet loss.
Context
If the optimal route destined for a root node on a non-root node changes on an mLDP network,
the non-root node re-selects an upstream node and by default tears down the existing MP2MP
LSP. As a result, traffic is dropped before a new MP2MP LSP is established. To minimize traffic
loss, enable the mLDP MBB capability on each node on the mLDP MP2MP network. If the
optimal route destined for the root node changes, the non-root node establishes a new MP2MP
LSP before tearing down the original MP2MP LSP, which minimizes traffic loss.

Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
mldp make-before-break
The mLDP MBB capability is enabled globally.

mldp make-before-break timer { wait-ack wait-ack-time | switch-delay switch-delay-
time }
The time for a local node to wait to receive an MBB ACK Notification message is set. The delay
time for performing an MBB switchover is also set.
If a local route destined for a root node changes, the local node attempts to send an MBB Mapping
message to another upstream node to establish an MBB LSP. After the upstream node replies
with an MBB ACK Notification message, the local node can successfully establish the MBB
LSP. If the local node does not receive an MBB ACK Notification message after a specified
period of time elapses, traffic is switched to the MBB LSP immediately. The default time for
waiting for an MBB ACK Notification message is 10s. The default time is recommended. The
waiting time can be configured using the wait-ack-time parameter in the mldp make-before-
break timer command.
Although the MBB LSP is established on the control plane, a local node has to wait a period of
time before the new upstream node generates and delivers a forwarding entry. In this situation,
if traffic is switched to this MBB LSP, traffic is dropped because there is no available forwarding
entry. Therefore, to prevent packet loss, the local node has to delay switching traffic to the MBB
LSP. The default delay time is 100 ms. The default time is recommended. The delay time can
be configured using the switch-delay-time parameter in the mldp make-before-break timer
command.
----End
2.8.4 (Optional) Disabling mLDP P2MP on an Interface

To flexible control the path of a P2MP LSP, you can disable mLDP P2MP on a specified
interface.
Context
Disabling mLDP P2MP on an interface helps you plan a network. For example, if links balance
traffic on a network, to enable P2MP traffic to travel along a specific link, disable mLDP P2MP
on interfaces connected to other links.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mpls mldp p2mp disable
mLDP P2MP is disabled on the interface.

By default, the mLDP P2MP capability on a specific interface of a node is the same as that
configured globally on the node.
Disabling mLDP P2MP on an interface causes P2MP LSPs to fail to be established, while does
not affect existing P2P LDP sessions.
----End

After configuring an automatic mLDP P2MP tunnel, you can check mLDP P2MP LSP
information, forwarding information, and mLDP P2MP LSP connectivity on the root node
(ingress).
Prerequisites
The automatic mLDP P2MP tunnel has been configured so that the establishment of an mLDP
P2MP LSP can be triggered when multicast VPLS is deployed.
Procedure
l Run the ping multicast-lsp mldp p2mp root-ip root-ip-address { lsp-id lsp-id | opaque-
value opaque-value } command on the ingress to check mLDP P2MP LSP connectivity.
l Run the display mpls mldp lsp p2mp [ root-ip root-ip-address { lsp-id lsp-id | opaque-
value opaque-value } ] command to check mLDP P2MP LSP information on a local node.
l Run the display mpls multicast-lsp protocol mldp p2mp [ root-ip root-ip-address { lsp-
id lsp-id | opaque-value opaque-value } ] [ lsr-role { bud | ingress | transit | egress } ]
command to check mLDP P2MP LSP forwarding information.
----End
Example
# Run the ping multicast-lsp mldp p2mp command on the root node to check mLDP P2MP
LSP connectivity.
<HUAWEI> ping multicast-lsp mldp p2mp root-ip 1.1.1.1 lsp-id 100
LSP PING FEC: root-ip 1.1.1.1 : 100 data bytes, press CTRL_C to break
Reply from 3.3.3.3: bytes=100 Sequence=1 time=80 ms


round-trip min/avg/max = 60/106/190 ms
Run the following commands to view LDP siganling and forwarding plane information about
mLDP P2MP LSPs on a transit node.
# Run the display mpls mldp lsp p2mp command to view information about all mLDP P2MP
LSPs on the transit node.
<HUAWEI> display mpls mldp lsp p2mp
A '*' before a Peer means the session is stale
-------------------------------------------------------------------------------
LSP Information: mLDP P2MP LSP
-------------------------------------------------------------------------------
Root IP : 1.1.1.1 Instance : --
Opaque decoded : LSP-ID 100
Opaque value : 01 0004 00000064
Lsr Type : Transit
Trigger Type : --
Upstream Count : 1 Downstream Count : 2
Upstream:
In Label Peer MBB State
1029 1.1.1.1 --
Downstream:
Out Label Peer MBB State Next Hop Out Interface
1029 3.3.3.3 -- 10.1.3.2 GigabitEthernet1/0/2
1030 4.4.4.4 -- 10.1.2.2 GigabitEthernet1/0/1
-------------------------------------------------------------------------------
# Run the display mpls multicast-lsp protocol mldp p2mp command to view forwarding
information about all mLDP P2MP LSPs on the transit node.
<HUAWEI> display mpls multicast-lsp protocol mldp p2mp
------------------------------------------------------------------------------
LSP Information: mLDP P2MP-LSP
------------------------------------------------------------------------------
Root IP : 1.1.1.1 Instance : --
Opaque decoded : LSP-ID 100
Opaque value : 01 0004 00000064
Lsr Type : Transit
Forward ID : 0x80000000
Insegment Count : 1 Outsegment Count : 2
Insegment:
In Label State Age
1029 Active 0d12h48m51s
Outsegment:
Out Label MTU Token Age Next Hop Out Interface
1029 1500 0x80080a 0d12h48m51s 10.1.3.2 GigabitEthernet1/0/2
1030 1500 0x800810 0d12h43m49s 10.1.2.2 GigabitEthernet1/0/1
------------------------------------------------------------------------------

2.9 Configuring LDP over TE

This section describes how to configure LDP over TE.

Before configuring LDP over TE, familiarize yourself with the usage scenario, complete the
pre-configuration tasks, and obtain the data required for the configuration.
Usage Scenario
MPLS TE supports strong traffic engineering capabilities and provides various QoS guarantees.
Due to live network limitations, such as application types and costs, deploying MPLS TE on the
entire network is difficult. Therefore, LDP over TE can be used to deploy MPLS TE on a core
area and LDP on non-core areas.
Before configuring LDP over TE, complete the following tasks:
l Configure IGP to implement the reachability between LSRs.

l Configure basic MPLS functions of all nodes and interfaces.
l Enable MPLS LDP on the interface in the non-TE domain.
l Configure RSVP-TE Tunnel on the TE node.
Data Preparation
To configure LDP over TE, you need the following data.
No. Data
1 IP address and loopback address of the interface on each LSR
2 Metrics and link overhead
2.9.2 Configuring Forwarding Adjacency

This section describes how to configure the forwarding adjacency to advertise a route of an LSP
to neighbor nodes so that the neighbor nodes can use this LSP.
Context
The routing protocol performs bidirectional detection on a link. When using the forwarding
adjacency to advertise LSP links to other nodes, configure another tunnel for transferring data
packets in the reverse direction. Then, enable the forwarding adjacency on these two tunnels.

NOTE
By default, the forwarding adjacency is disabled.

If the forwarding adjacency is used, the IGP shortcut cannot be used at the same time.
Perform the following steps on the ingress of a CR-LSP tunnel:
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface tunnel interface-number
The tunnel interface view is displayed.

Step 3 Run:
mpls te igp advertise [ hold-time interval ]
The forwarding adjacency is enabled.

Step 4 Run:
mpls te igp metric { absolute | relative } value
The IGP metric value for the tunnel is configured.
NOTE
The IGP metric value must be set properly to ensure that the LSP is advertised and used correctly. For
example, the metric of a TE tunnel must be less than that of IGP routes to ensure that the TE tunnel is used
as a route link.
Step 5 Run:
mpls te commit
The current tunnel configuration is committed.

Step 6 You can select either of the following modes to enable the forwarding adjacency.
l For IS-IS, run:
isis enable [ process-id ]
IS-IS is enabled on the tunnel interface.

l For OSPF, run the following commands in sequence.
1. Run the quit command to return to the system view.
2. Run the ospf [ process-id ] command to enter the OSPF view.
3. Run the enable traffic-adjustment advertise command to enable the forwarding
adjacency.
----End
2.9.3 Establishing LDP Remote Peers on the Two Ends of the TE

Tunnel
To configure LDP over TE, create remote LDP peers on both ends of a TE tunnel.

Context
Perform the following steps on the ingress and egress of a TE tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the MPLS LDP remote peer is displayed.
Step 3 Run:
remote-ip ip-address
The IP address of the remote peer is specified.
----End
2.9.4 Configuring a Method to Direct LDP Traffic to a TE Tunnel

A specific method can be configured to direct LDP traffic to a TE tunnel so that an LDP LSP
can span the TE tunnel.
Context
After two devices on both ends of a TE tunnel establish an LDP peer relationship, LDP traffic
cannot be automatically directed to the TE tunnel. To direct LDP traffic to the TE tunnel, use
either of the following methods:
l IGP shortcut: The TE tunnel is considered as a logical link used to locally calculate an IGP
route. In this situation, the tunnel interface is used as an outbound interface in an IGP route.
With the IGP shortcut method, a device does not advertise the TE tunnel route to peers,
and the peers cannot use the TE tunnel to transmit traffic.
l Forwarding adjacency: The TE tunnel is considered as a logical link used to globally
calculate an IGP route. In this situation, the tunnel interface is used as an outbound interface
in an IGP route. With the forwarding adjacency method, a device advertises the TE tunnel
route to peers, and the peers can use the TE tunnel to transmit traffic.
Select either of the following configuration tasks:
Procedure
l Configure the IGP shortcut.
l Configure the forwarding adjacency.
----End

2.9.5 (Optional) Configuring the Policy for Triggering the

Establishment of an LSP
A policy is configured to trigger the establishment of an LSP on the ingress and egress of a TE
tunnel.
Context
Perform the following steps on the ingress and egress of a TE tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
lsp-trigger { all | host | ip-prefix ip-prefix-name | none }
The policy for triggering the establishment of LSPs is configured.
----End

After the configuration of LDP over TE, you can view that an LDP LSP over TE is set up.
Procedure
Step 1 Run the display mpls ldp lsp [ all | [ vpn-instance vpn-instance-name ] destination-address
mask-length ] command to check information about the tunnel interface on the ingress of an
LDP LSP.
----End
Example
After the configurations are successful, run the display mpls ldp lsp command. LDP LSP over
TE is added.
2.10 Configuring Static BFD for LDP LSP

This section describes how to configure a static BFD session to monitor an LDP LSP, and
therefore you can monitor LSP connectivity.


Before configuring a static BFD session to monitor an LDP LSP, familiarize yourself with the
usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
Usage Scenario
When a static BFD session monitors an LDP LSP, note that:
l BFD can be bound only on the ingress of the LDP LSP.
l One LSP can only be bound to one BFD session.
l BFD only monitors the LDP LSP that is established using a host route.
NOTE
BFD for LSP can function properly even if the reverse path of a forward LSP is an IP link. The forward
and reverse paths must be established over the same link. If they are established using different links, and
a fault occurs, BFD cannot identify the faulty path. Before you deploy BFD, ensure that the forward and
reverse paths are established over the same link so that BFD can correctly identify the faulty path.
Before configuring static BFD for LDP LSP, complete the following tasks:
l Configure the network layer parameters to make the network accessible.
l Enable MPLS LDPs on all nodes and establish an LDP session.
l Configure an LDP LSP.
Data Preparations
Before configuring static BFD for LDP LSP, you need the following data.
No. Data
1 BFD configuration name
2 LDP LSP parameters:

l Next hop address of an LSP
l (Optional) Type and number of each outbound interface
3 Local and remote discriminators of a BFD session

This section describes how to enable BFD globally. You only need to enable BFD on both ends
of a link to be monitored.
Context
Perform the following steps on each LSR on both ends of a link that to be monitored:

Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
The global BFD function is enabled on this node. The BFD global view is displayed.
----End
2.10.3 Configuring BFD Parameters on the Ingress

This section describes how to configure BFD parameters on the ingress. BFD parameters must
be configured on the ingress before you configure a static BFD session to monitor an LDP LSP.
Context
Perform the following steps on the ingress of an LSP:
Procedure
Step 1 Run:
system-view

Step 2 Run:
The BFD session is bound to a dynamic LSP.

When the IP address of the egress on the LSP to be monitored is borrowed, an interface must
be specified.
NOTE
When configuring static BFD for LDP LSP on a network deployed with LDP over TE, configure
interface interface-type interface-number to specify the tunnel interface.

l To set the local discriminator, run:
l To set the remote discriminator, run:

NOTE
The local and remote discriminators on both ends of a BFD session must accord with each other. Otherwise,
the session cannot be established. In addition, once configured, the local and remote discriminators cannot
be modified.




NOTE
l Effective local interval at which BFD packets are sent = MAX { Configured local interval at which
BFD packets are sent, Configured remote interval at which BFD packets are received }
l Effective local interval at which BFD packets are received = MAX { Configured remote interval at
which BFD packets are sent, Configured local interval at which BFD packets are received }
l Effective local detection interval = Effective local interval at which BFD packets are received x
Configured remote detection multiplier
For example, if:
l The local interval at which BFD packets are sent is set to 200 ms, the local interval at which BFD
packets are received is set to 300 ms, and the local detection multiplier is set to 4.
l The remote interval at which BFD packets are sent is set to 100 ms, the remote interval at which BFD
packets are received is set to 600 ms, and the remote detection multiplier is set to 5.
Then,
l Effective local interval at which BFD packets are sent = MAX { 200 ms, 600 ms } = 600 ms; effective
local interval at which BFD packets are received = MAX { 100 ms, 300 ms } = 300 ms; effective local
detection period = 300 ms x 5 = 1500 ms
l Effective remote interval at which BFD packets are sent = MAX { 100 ms, 300 ms } = 300 ms; effective
remote interval at which BFD packets are received = MAX { 200 ms, 600 ms } = 600 ms; effective
remote detection period = 600 ms x 4 = 2400 ms
Step 7 Run:
process-pst
The BFD session status changes can be advertised to a specific upper-layer application.
Step 8 Run:
commit
----End
Follow-up Procedure
After the BFD session is established and its status is Up, the BFD starts to detect failures in an
LDP LSP.
If the LDP LSP is torn down, the BFD status also goes Down.

2.10.4 Configuring BFD Parameters on the Egress

This section describes who to configure BFD parameters on the egress before you configure a
static BFD session to monitor an LDP LSP.
Context
The egress can use an IP link, LSP, or TE tunnel as a reverse tunnel to inform the ingress of a
fault. To ensure that the forward and reverse paths are over the same link, an LSP is preferentially
selected to notify the ingress of an LSP fault.
Perform the following steps on the egress of the LSP:
Procedure
Step 1 Run:
system-view
Step 2 Configure BFD sessions.

bfd bfd-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ]
[ interface interface-type interface-number ] [ source-ip source-ip ]
l For a dynamic LSP, run:



l To set the local discriminator, run:
l To set the remove discriminator, run:

NOTE
The local discriminator on a local device must be the same as the remote discriminator on the other device
on the remote end of a BFD session. Otherwise, the session cannot be established correctly. In addition,
the local and remote discriminators cannot be modified after being configured.





process-pst
If an LSP is used as a reverse tunnel to notify the ingress of a fault, you can run this command
to allow the reverse tunnel to switch traffic if the BFD session goes Down. If a single-hop IP
link is used as a reverse tunnel, this command can be configured because the process-pst
command can only be configured for BFD single-link detection.
Step 8 Run:
commit
----End

After configuring a static BFD session to monitor an LDP LSP, you can view the BFD
configuration, the specified BFD session, and BFD statistics.
Prerequisites
The static BFD for LDP LSP function has been configured.
Procedure
l Run the display bfd configuration { all | static } [ for-lsp ] command to check the BFD
configuration.
l Run the display bfd session { all | static } [ for-lsp ] command to check BFD session
information.
l Run the display bfd statistics session { all | static } [ for-ip | for-lsp ] command to check
BFD statistics.
----End
Example
Run the display bfd session all verbose command on the ingress. Up is displayed in the
State field, and LDP_LSP is displayed in the BFD Bind Type field.
<HUAWEI> display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 256 State : Up Name : 1to4
--------------------------------------------------------------------------------
BFD Bind Type : LDP_LSP

Bind Peer IP Address : 4.4.4.9

Bind Interface : Pos1/0/0

Active Multi : 3
Bind Application : LSPM | L2VPN | OAM_MANAGER
Session TX TmrID : 94 Session Detect TmrID : 95
Session Init TmrID : - Session WTR TmrID : -
PDT Index : FSM-0 | RCV-0 | IF-0 | TOKEN-0
--------------------------------------------------------------------------------
2.11 Configuring Dynamic BFD for LDP LSP

This section describes how to configure a dynamic BFD session to monitor an LDP LSP. There
is no need to configure BFD parameters. This helps speed up link fault detection and reduce
configuration workload.

Before configuring a dynamic BFD session to monitor an LDP LSP, familiarize yourself with
the usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
Usage Scenario
With dynamic BFD for LDP LSP, failure detection speeds up and configuration workload
decreases. In addition, LDP FRR is well supported for the LSP to provide better services.
NOTE
Dynamic BFD only monitors the LDP LSP established using a host route.
BFD for LSP can function properly even if the reverse path of a forward LSP is an IP link. The forward
and reverse paths must be established over the same link. If they are established using different links, and
a fault occurs, BFD cannot identify the faulty path.
Before configuring dynamic BFD for LDP LSP, complete the following tasks:
l Configure basic MPLS functions.

l Configure MPLS LDP.
l (Optional) Create the FEC list and adjust BFD parameters.

Data Preparations
To configure dynamic BFD for LDP LSP, you need the following data.
No. Data
1 LSR ID of each node
2 BFD session trigger mode
3 (Optional) FEC list name
4 (Optional) BFD parameters

This section describes how to enable BFD globally. You only need to enable BFD on both ends
of a link to be monitored.
Context
Perform the following steps on the ingress and egress:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
BFD is enabled globally.
----End
2.11.3 Enabling MPLS to Establish BFD Session Dynamically

This section describes how to enable MPLS to dynamically establish a BFD session. After you
enable BFD on the ingress and egress, enable MPLS to establish a BFD session dynamically.
Procedure
l Perform the following steps on the ingress:
1. Run:
system-view

2. Run:
mpls


3. Run:
mpls bfd enable
An LDP LSP is enabled with the capability of dynamically creating a BFD session.
A BFD session is not created after this command is run.

l Perform the following steps on the egress:
1. Run:
system-view

2. Run:
bfd
The BFD view is displayed.

3. Run:
mpls-passive
The device is enabled to passively establish a BFD session.
A BFD session is not created after this command is run. The BFD session is established
only after the egress receives an LSP ping request packet containing the BFD TLV
sent by the ingress.
----End
2.11.4 Configuring the Policy for Triggering Dynamic BFD for LDP
LSP
There are two trigger policies to establish a dynamic BFD session for LDP LSP: host and FEC
list policies.
Context
A policy can be enforced to establish a session of dynamic BFD for LDP LSP in either of the
following modes:
l Host policy: All host addresses are used to establish a BFD session. Specify nexthop and
outgoing-interface parameters to define the LSPs that can establish a BFD session.
l FEC list policy: Only some host addresses are used to establish a BFD session. Use the
fec-list command to specify host addresses that trigger BFD session creation.
Perform the following steps on the ingress of an LSP to be monitored:
Procedure
Step 1 Run:
system-view
Step 2 (Optional) If you need the FEC list, perform the following operations:

1. Run:
fec-list list-name
A FEC list is created, and the FEC list view is displayed.

2. Run:
fec-node ip-address [ nexthop ip-address | outgoing-interface interface-type
interface-number ] *
A FEC node is added to the FEC list.

3. Run:
quit
Step 3 Run:
mpls
Step 4 Run:
mpls bfd-trigger [ host [ nexthop next-hop-address | outgoing-interface interface-
type interface-number ] * | fec-list list-name ]
The policy for establishing a dynamic BFD session for LDP LSP is configured.
After the command is run, the device starts to establish a BFD session.
----End
2.11.5 (Optional) Adjusting BFD Parameters

This section describes how to adjust BFD parameters. The BFD detection parameters include
the BFD detection intervals and detection multiplier.
Context
Perform the following steps on the ingress:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Step 3 Run:
mpls ping interval interval
The interval at which LSP ping packets are sent is set.
Step 4 Run:
quit

Exit the BFD view.
Step 5 Run:
mpls
Step 6 Run:
mpls bfd { min-tx-interval interval | min-rx-interval interval | detect-multiplier
multiplier }*
BFD time parameters are set.
By default, the minimum interval at which BFD packets are sent and the minimum interval at
which BFD packets are received are 1000 ms, and the detection multiplier is 3 on the ingress.
BFD detection intervals are calculated as follows:
l Effective local interval at which BFD packets are sent = MAX { Configured local interval
at which BFD packets are sent, Configured remote interval at which BFD packets are
received }
l Effective local interval at which BFD packets are received = MAX { Configured remote
interval at which BFD packets are sent, Configured local interval at which BFD packets are
received }
l Effective local detection interval = Effective local interval at which BFD packets are received
x Configured remote detection multiplier
The minimum interval at which BFD packets are sent and the minimum interval at which BFD
packets are received are 100 ms, and the detection multiplier is 3 on the egress, which are fixed
values.
Therefore, you can adjust the minimum interval at which BFD packets are sent, the minimum
interval at which BFD packets are received, and the detection multiplier only on the ingress to
update BFD detection time on the ingress and egress.
----End

After configuring a dynamic BFD session to monitor an LDP LSP, you can view the BFD
configurations and information about BFD sessions on the ingress and egress.
Prerequisites
The dynamic BFD for LDP LSP function has been configured.
Procedure
l Run the display bfd configuration all [ verbose ] command to check the BFD
configuration on the ingress.
l Run the display bfd configuration passive-dynamic [ peer-ip peer-ip remote-
discriminator discriminator ] [ verbose ] command to check the BFD configuration on
the egress.
l Run the display bfd session all [ verbose ] command to check information about the BFD
session on the ingress.

l Run the display bfd session passive-dynamic [ peer-ip peer-ip remote-discriminator

discriminator ] [ slot slot-id ] [ verbose ] command to check information about the BFD
established passively on the egress.
l Run the display mpls bfd session [ statistics | [ protocol { ldp | cr-static | rsvp-te } ] |
[ outgoing-interface interface-type interface-number ] | [ nexthop ip-address ] | [ fec fec-
address ] | verbose | monitor ] command to check information about BFD session on the
ingress.
----End
Example
Run the display bfd session all command to view the state of BFD session that is established
dynamically. The status of the BFD session is Up, and the type of the link that is bound to the
session is LDP_LSP.
--------------------------------------------------------------------------------
Session MIndex : 256 State : Up Name : dyn_8192
--------------------------------------------------------------------------------
Bind Session Type : Dynamic
Bind Interface : GE1/0/0
LSP Token : 0x3002001
Proc interface status : Disable
WTR Interval (ms) : -- Process PST : Enable
Active Multi : 3
Last Local Diagnostic : No Diagnostic
Bind Application : VRRP | LSPM | LSPM | L2VPN | OAM_MANAGER
Session Description : --
--------------------------------------------------------------------------------
Run the display bfd session passive-dynamic verbose command on the egress to view the status
of the BFD session that is established passively. The BFD Bind Type field value is peer IP
address. The BFD packets sent by this egress are transported over IP routes. BFD parameters
cannot be adjusted on the egress. By default, the min-tx-interval and min-tx-interval values
are 10. The interval at which BFD packets are sent and the interval at which BFD packets are
received are negotiated by both ends of the BFD session before the intervals take effect.
<HUAWEI> display bfd session passive-dynamic verbose
--------------------------------------------------------------------------------
Session MIndex : 256 (Multi Hop) State : Up Name : dyn_8192
--------------------------------------------------------------------------------
Bind Session Type : Entire_Dynamic


Bind Interface : --
WTR Interval (ms) : -- Local Demand Mode : Disable
Active Multi : 3
Bind Application
--------------------------------------------------------------------------------
2.12 Configuring Dynamic BFD to Monitor an LDP Tunnel

Dynamic BFD can be configured to establish a dynamic BFD session to monitor both primary
and backup LDP LSPs in an LDP tunnel. If BFD detects a fault, BFD instructs a specific LDP
upper-layer application to perform a protection switchover.

Before configuring dynamic BFD to monitor an LDP tunnel, familiarize yourself with the usage
Usage Scenario
When LDP LSPs transmit application traffic, for example, VPN, to improve network reliability,
LDP FRR and an LDP upper-layer protection mechanism, such as VPN FRR or VPN equal-cost
multipath (ECMP), are used. BFD for LDP LSP only detects primary LSP faults and switches
traffic to an FRR LSP. If the primary and FRR LSP fail simultaneously, the BFD mechanism
does not take effect. In this situation, LDP can instruct its upper-layer application to perform a
protection switchover only after LDP detects the FRR LSP failure. As a result, a great number
of packets are dropped.
To minimize packet loss, dynamic BFD can be configured to establish dynamic BFD sessions
to monitor both the primary and FRR LSPs. If both primary and FRR LSPs fail, BFD rapidly
detects the failures and instructs a specific LDP upper-layer application to perform a protection
switchover.
Before configuring dynamic BFD to monitor an LDP tunnel, complete the following tasks:


Data Preparation
To configure dynamic BFD to monitor LDP tunnels, you need the following data.
No. Data
1 Policy for dynamically establishing a BFD session
2 (Optional) FEC list name
3 (Optional) BFD parameters
2.12.2 Enabling an MPLS Device to Dynamically Establish a BFD

Session
A dynamic BFD session that monitors both the primary and FRR LSPs can be established only
after an MPLS device is enabled to dynamically establish the BFD session.
Procedure
l Perform the following steps on the ingress:
1. Run:
system-view

2. Run:
bfd
BFD is globally enabled.

3. Run:
quit

4. Run:
mpls

5. Run:
mpls bfd enable
The capability of dynamically establishing a BFD session is configured on the ingress.
The mpls bfd enable command does not create a BFD session.
l Perform the following steps on the egress:
1. Run:
system-view

2. Run:
bfd

BFD is globally enabled, and the BFD view is displayed.

3. Run:
mpls-passive
The capability of passively creating a BFD session is configured on the egress.
The mpls-passive command does not create a BFD session. The egress has to receive
an LSP ping request carrying a BFD TLV before creating a BFD session with the
ingress.
----End
2.12.3 Configuring a Policy for Triggering Dynamic BFD for LDP

Tunnel
Either the host address-based policy or FEC list-based policy can be used to dynamically
establish BFD sessions to monitor LDP tunnels.
Context
Either of the following trigger policies can be used to establish BFD sessions to monitor LDP
tunnels:
l Host address-based policy: used when all host addresses are available to trigger the creation
of BFD sessions.
l FEC list-based policy: used when only some host addresses are available to establish BFD
sessions. The FEC list contains specified host addresses.
Perform the following steps on the ingress on which an LDP tunnel to be monitored is
established:
Procedure
Step 1 Run:
system-view
Step 2 (Optional) If a FEC list is used to establish a dynamic BFD session, perform the following steps:
1. Run:
fec-list list-name
A FEC list is created, and the FEC list view is displayed.

2. Run:
fec-node ip-address
A FEC node is added to the FEC list.
Do not specify an outbound interface name or next hop address for the FEC node to be
added to the FEC list.
3. Run:
quit


Step 3 Run:
mpls

Step 4 Run:
mpls bfd-trigger-tunnel [ host | fec-list list-name ]
A policy is configured to dynamically establish a BFD session to monitor an LDP tunnel.

If no parameter is specified, the host address-based policy is used by default.
After a policy is configured, the device starts to dynamically establish a BFD session.
----End

This section describes how to adjust BFD parameters. The BFD detection parameters include
the BFD detection intervals and detection multiplier.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd

Step 3 Run:

Step 4 Run:
quit
Exit the BFD view.

Step 5 Run:
mpls

Step 6 Run:
mpls bfd { min-tx-interval interval | min-rx-interval interval | detect-multiplier
multiplier }*

BFD detection intervals are calculated as follows:
l Effective local interval at which BFD packets are sent = MAX { Configured local interval
at which BFD packets are sent, Configured remote interval at which BFD packets are
received }
l Effective local interval at which BFD packets are received = MAX { Configured remote
interval at which BFD packets are sent, Configured local interval at which BFD packets are
received }
l Effective local detection interval = Effective local interval at which BFD packets are received
x Configured remote detection multiplier
The minimum interval at which BFD packets are sent and the minimum interval at which BFD
packets are received are 100 ms, and the detection multiplier is 3 on the egress, which are fixed
values.
update BFD detection time on the ingress and egress.
----End

After configuring dynamic BFD to monitor an LDP tunnel, you can view BFD session
information on the ingress on which an LDP tunnel is established.
Prerequisites
The dynamic BFD for LDP tunnel function has been configured.
Procedure
l Run the display bfd session all [ verbose ] command to check information about all BFD
sessions on the ingress.
l Run the display mpls bfd session [ verbose ] command to check information about all
BFD sessions that monitor MPLS tunnels on the ingress.
----End
Example
Run the display bfd session all verbose command on the ingress. The command output shows
that a BFD session is in the Up state and has been bound to a tunnel with the type of
LDP_TUNNEL.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
BFD Bind Type : LDP_TUNNEL


Bind Interface : GigabitEthernet1/0/0
Active Multi : 3 DSCP : -
Bind Application : LSPM | LDP | L2VPN | OAM_MANAGER
Session TX TmrID : - Session Detect TmrID : -
--------------------------------------------------------------------------------
Run the display mpls bfd session command on the ingress to view information about a BFD
session that monitors an LDP tunnel.
<HUAWEI> display mpls bfd session
-------------------------------------------------------------------------------
BFD Information: LDP Tunnel
-------------------------------------------------------------------------------
FEC DISC OUT-IF NEXTHOP TUNNEL STATE
4.4.4.4 8195 GE1/0/0 10.1.1.2 - Up
2.13 Configuring Manual LDP FRR

This section describes how to configure Manual LDP FRR. Manual LDP FRR can quickly switch
traffic to a backup LSP if an LDP link fails, which ensures uninterrupted traffic transmission.

Before configuring Manual LDP FRR, familiarize yourself with the usage scenario, complete
Usage Scenario
LDP FRR provides MPLS with a fast reroute function to implement the local port-level backup,
which reduces data loss.
Before configuring manual LDP FRR, complete the following tasks:
l Configure MPLS.
For detailed information about one-hop BFD, see "BFD Configuration" in the HUAWEI
NetEngine80E/40E Router Configuration Guide - Reliability.

Data Preparation
To configure LDP FRR, you need the following data.
No. Data
1 Type and number of the interface protected by a bypass LSP
2 Next hop address in a bypass LSP
3 Name of the IP prefix list that can trigger the establishment of bypass LSPs
4 Priority of a bypass LSP
5 (Optional) Configuration name of the one-hop BFD session
2.13.2 Enabling Manual LDP FRR

This section describes how to enable Manual LDP FRR on the ingress and transit nodes.
Context
Perform the following steps on the ingress or transit node:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls ldp frr nexthop nexthop-address [ ip-prefix ip-prefix-name ] [ priority
priority ]
LDP FRR is enabled on the interface.
On the same interface, you can configure a maximum of 10 LDP FRR entries with different
precedences. Based on different precedences, only a single bypass LSP is generated. The smaller
the value is, the higher the precedence is. By default, the precedence value is 50.

NOTE
l LDP FRR cannot be enabled or disabled during the LDP GR process.

l If LDP FRR and IP FRR are deployed concurrently, IP FRR is used preferentially.
l When the undo mpls ldp command is run to disable the LDP function in the system view, or the undo
mpls ldp command is run to disable the LDP function in the interface view, the LDP FRR configuration
in the interface view is not automatically deleted. Only the LDP FRR function is invalid.
l In LDP FRR configuration, the bypass LSP must be in liberal state, and the route state of the bypass
LSP must be "Inactive Avd."
----End
2.13.3 (Optional) Allowing BFD to Modify the PST

This section describes how to enable BFD to modify the PST. A BFD session can modify the
PST only in the BFD for Manual LDP FRR scenario
Context
The procedure is only used to configure LDP FRR based on BFD.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd bfd-name
The created BFD session view is displayed.
Step 3 Run:
process-pst
BFD is allowed to modify the PST.
Step 4 Run:
commit
By default, BFD does not modify the PST.
----End
2.13.4 (Optional) Configuring LDP Graceful Deletion

LDP graceful deletion can be configured to speed up traffic switching using LDP FRR.

Context
LDP graceful deletion can be configured in the LDP-IGP synchronization or LDP FRR scenario
to speed up traffic switching and ensure uninterrupted traffic during traffic switching, improving
reliability of the entire network.
If the primary link goes Down and the LDP session on the primary link goes Down accordingly,
LDP immediately instructs the upstream device to withdraw labels and triggers LDP Auto FRR,
and the LSP convergence on the secondary link requires LDP to allocate labels to the upstream
device again, prolonging the convergence time and traffic switching using FRR. As a result,
packet loss occurs.
If LDP graceful deletion is configured and the LDP session goes Down, LDP delays deleting
the LDP session and keeps the relevant labels and LSP. The LSP on the secondary link does not
require LDP to allocate labels to the upstream device again, shortening traffic switching using
LDP FRR and reducing packet loss.
Perform the following operations on the LSR configured with LDP FRR.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
The MPLS LDP view is displayed.
Step 3 Run:
graceful-delete
LDP graceful deletion is enabled.

graceful-delete timer time
The value of the graceful deletion timer is set.
After the LDP session goes Down, forwarding entries on the LSR remain unchanged for the
time specified by the graceful deletion timer.
By default, the value of the graceful deletion timer is 5 seconds.
NOTE
If the value of the graceful deletion timer is too large, the invalid LSP will be kept for a long time, consuming
system resources.
----End

After the configuration of Manual LDP FRR, you can view information about Manual LDP FRR
LSPs and BFD-enabled interfaces.

Prerequisites
The LDP FRR function has been configured.
Procedure
l Run the display mpls lsp command to check information about LSPs enabled with LDP
FRR.
l Run the display bfd interface [ interface-type interface-number ] command to check
information about the BFD interface.
----End
Example
Run the display mpls lsp command, you can see LDP FRR is enabled on the related LDP LSP.
----------------------------------------------------------------------
----------------------------------------------------------------------
3.3.3.9/32 NULL/3 -/GigabitEthernet2/0/0
**LDP FRR** /1025 /GigabitEthernet1/0/0
3.3.3.9/32 1025/3 -/GigabitEthernet2/0/0
**LDP FRR** /1025 /GigabitEthernet1/0/0
2.2.2.9/32 NULL/3 -/GigabitEthernet1/0/0
2.2.2.9/32 1024/3 -/GigabitEthernet1/0/0
2.14 Configuring LDP Auto FRR

LDP Auto FRR can be configured to rapidly trigger a service switchover if a fault occurs,
improving network reliability.

Before configuring LDP Auto FRR, familiarize yourself with the usage scenario, complete the
Usage Scenario
On an MPLS network with a backup link, if a link fault occurs, IGP routes converge and routes
related to the backup link become available. After IGP route convergence is complete, an LDP
LSP over the backup link becomes available. During this process, traffic is interrupted. To
prevent traffic interruption, LDP FRR can be configured.
LDP FRR uses the liberal label retention mode, obtains a liberal label, applies for a forwarding
entry associated with the label, and forwards the forwarding entry to the forwarding plane as a
backup forwarding entry used by the primary LSP. On the network enabled with LDP FRR, if
an interface failure (detected by the interface itself or by an associated BFD session) or a primary
LSP failure (detected by an associated BFD session)occurs, LDP FRR is notified of the failure
and rapidly forwards traffic to a backup LSP, protecting traffic on the primary LSP. The traffic
switchover is performed within 50 milliseconds, minimizing the traffic interruption time.
LDP FRR is classified into the following types:

l LDP manual FRR: A backup LSP is configured manually by specifying an outbound

interface or a next hop. The configuration is complex and flexible. LDP manual FRR applies
to simple networks.
l LDP Auto FRR: A backup LSP is automatically created based on a specified policy. The
configuration is simple and prevents loops. LDP Auto FRR applies to complex and large
networks.
Before configuring LDP Auto FRR, complete the following tasks:
l Assign an IP address to each interface to ensure IP connectivity.

l Configure an IGP to advertise a route to each network segment of each interface and to
advertise the host route to each LSR ID.
l Configure IGP Auto FRR.
Data Preparation
To configure LDP Auto FRR, you need the following data.
No. Data
1 Type and number of an interface on which a backup LSP will be established
2 Policy for triggering LDP to establish backup LSP
2.14.2 Enabling LDP Auto FRR

LDP Auto FRR is enabled on the ingress or a transit node.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
auto-frr lsp-trigger { all | host | ip-prefix ip-prefix-name | none }
A policy for triggering LDP LSP establishment is configured.
By default, LDP uses backup routes to addresses with 32-bit masks to set up backup LSPs.

NOTE
LDP Auto FRR depends on IGP Auto FRR. After the frr (IS-IS) or frr (OSPF)ommand is used to enable
IGP Auto FRR, LDP Auto FRR will be automatically enabled. The auto-frr lsp-trigger command is used
to configure or change a policy for triggering LDP LSP establishment.
If both the auto-frr lsp-trigger command and the lsp-trigger command are run, the established backup
LSPs satisfy both the policy for triggering LDP LSP establishment and the policy for triggering backup
LDP LSP establishment.
During the LDP GR process, changing a policy for triggering the backup LDP LSP establishment is not
allowed.
----End

LDP graceful deletion can be configured to speed up traffic switching using LDP FRR.
Context
If the primary link goes Down and the LDP session on the primary link goes Down accordingly,
LDP immediately instructs the upstream device to withdraw labels and triggers LDP Auto FRR,
and the LSP convergence on the secondary link requires LDP to allocate labels to the upstream
device again, prolonging the convergence time and traffic switching using FRR. As a result,
packet loss occurs.
If LDP graceful deletion is configured and the LDP session goes Down, LDP delays deleting
the LDP session and keeps the relevant labels and LSP. The LSP on the secondary link does not
require LDP to allocate labels to the upstream device again, shortening traffic switching using
LDP FRR and reducing packet loss.
Perform the following operations on the LSR configured with LDP FRR.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls ldp

Step 3 Run:
graceful-delete


After the LDP session goes Down, forwarding entries on the LSR remain unchanged for the
time specified by the graceful deletion timer.
NOTE
system resources.
----End

After configuring LDP Auto FRR, you can view information about the LDP Auto FRR LSP.
Prerequisites
LDP Auto FRR has been configured.
Procedure
l Run the display mpls lsp command to check information about LSPs after LDP Auto FRR
is enabled.
----End
Example
After configuring LDP Auto FRR, run the display mpls lsp command to view information about
a backup LSP with the destination address of 2.2.2.9/32. The command output is as follows:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.9/32 NULL/3 -/Pos1/0/0
**LDP FRR** /1025 /Pos1/0/1
2.2.2.9/32 1024/3 -/Pos1/0/0
**LDP FRR** /1025 /Pos1/0/1
3.3.3.9/32 NULL/3 -/Pos1/0/1
**LDP FRR** /1025 /Pos1/0/0
3.3.3.9/32 1025/3 -/Pos1/0/1
**LDP FRR** /1025 /Pos1/0/0
4.4.4.9/32 NULL/1026 -/Pos1/0/1
**LDP FRR** /1026 /Pos1/0/0
4.4.4.9/32 1026/1026 -/Pos1/0/1
**LDP FRR** /1026 /Pos1/0/0
10.1.3.0/24 1027/3 -/Pos1/0/1
10.1.4.0/24 1028/3 -/Pos1/0/1
**LDP FRR** /1027 /Pos1/0/0
2.15 Configuring Synchronization Between LDP and IGP

This section describes how to configure LDP and IGP synchronization. LDP and IGP
synchronization can delay a route switchback by suppressing the setup of an IGP neighbor
relationship until an LDP session is established.


Before configuring LDP and IGP synchronization, familiarize yourself with the usage scenario,
Usage Scenario
In the networking where primary and backup LSPs are used, synchronization between LDP and
IGP is used to prevent traffic loss if the primary LSP fails. The situations are as follows:
l If the primary LSP fails, IGP and LSP traffic is switched to a backup LSP. When the primary
LSP recovers, IGP converges more rapidly than the creation of the LDP session. IGP traffic
is switched back to the primary LSP before the LDP session is set up, which causes LSP
traffic loss.
l When the primary LSP is working properly, whereas the LDP sessions between the nodes
along the primary LSP fail, the LSP traffic is switched to the backup LSP. The IGP traffic
is still transmitted along the primary LSP. As a result, LSP traffic is lost.
LDP-IGP synchronization delays IGP route advertisement so that the LDP session and IGP route
can converge simultaneously.
LDP-IGP synchronization is configured on the LDP peer nodes (for example, LSR3 in Figure
2-2) on the active link and the cross node (for example, LSR2 in Figure 2-2) of the active and
standby links. Figure 2-2 shows the LDP-IGP synchronization networking.
Figure 2-2 LDP-IGP synchronization networking

LSR3
LSR1 LSR2 LSR5 LSR6
Active link
Standby link
LSR4
Before configuring synchronization between LDP and IGP, complete the following tasks:
l Configure MPLS functions.

l Configure MPLS LDP functions globally and on all interfaces.
Data Preparation
To configure synchronization between LDP and IGP, you need the following data.

No. Data
1 Type and number of the interface on which the backup LSP is set up
2 Type and number of the interface on which the timer is configured
3 (Optional) Timer value
2.15.2 Enabling Synchronization Between LDP and IGP

This section describes how to enable synchronization between LDP and IGP on the interfaces
of both ends of the link between the crossing node of active and standby links and the LDP
neighboring node.
Context
LDP-IGP synchronization can be enabled in either of the following modes:
l Enable LDP-IGP synchronization on a specific interface.

This configuration mode allows LDP-IGP synchronization to take effect only on a specific
interface, and therefore applies when only a few interfaces on a node must have LDP-IGP
synchronization enabled.
l Enable LDP-IGP synchronization in a specific IGP process.
This configuration mode allows LDP-IGP synchronization to take effect on all interfaces
in the specified IGP process, and therefore applies when many interfaces on a node must
have LDP-IGP synchronization enabled.
NOTE
LDP-IGP synchronization can be enabled in IS-IS processes, not OSPF processes.

If the synchronization status between LDP and IS-IS is different on an interface and in an IS-IS process,
the synchronization status on the interface takes effect.
Procedure
l If OSPF is used as an IGP, perform the following steps on an interface:
1. Run:
system-view

2. Run:

3. Run:
ospf ldp-sync
Synchronization between LDP and OSPF is enabled on the specified interface.

l If IS-IS is used as an IGP, perform the following steps:
Enable synchronization between LDP and IS-IS on an interface.

1. Run:
system-view

2. Run:

3. Run:
isis enable process-id
IS-IS is enabled.
4. Run:
isis ldp-sync
Synchronization between LDP and IS-IS is enabled on the specified interface.

Enable synchronization between LDP and IS-IS in an IS-IS process.
1. Run:
system-view

2. Run:
isis [ process-id ]
The IS-IS process view is displayed.

3. Run:
ldp-sync enable [ mpls-binding-only ]
Synchronization between LDP and IS-IS is enabled on all interfaces in the specified
IS-IS process.
If you want to enable synchronization between LDP and IS-IS on MPLS LDP-enabled
interfaces, please specify the parameter mpls-binding-only.
----End
2.15.3 (Optional) Blocking Synchronization Between LDP and IS-

IS on an Interface
This section describes how to block synchronization between LDP and IS-IS on an interface.
Context
The ldp-sync enable command run in an IS-IS process enables synchronization between LDP
and IS-IS on all local IS-IS interfaces. On an IS-IS interface transmits importance services, LDP
and IS-IS synchronization may affect service transmission. If the link is working properly and
an LDP session over the link fails, IS-IS sends link state PDUs (LSPs) to advertise the maximum
cost of the link. As a result, IS-IS does not select the route for the link, which affects important
service transmission.
To prevent the preceding problem, block LDP and IS-IS synchronization on an IS-IS interface
that transmits important services.

Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of an IS-IS-enabled interface is displayed.
Step 3 Run:
isis ldp-sync block
Synchronization between LDP and IS-IS on an interface is blocked.
----End
2.15.4 (Optional) Setting the Hold-down Timer Value

This section describes how to set the hold-down timer. The timer is an interval during which an
interface waits for the setup of an LDP session without setting up an OSPF neighbor relationship.
Context
On a device that has LDP-IGP synchronization enabled, if the active physical link recovers, an
IGP enters the Hold-down state, and a Hold-down timer starts. Before the Hold-down timer
expires, the IGP delays establishing an IGP neighbor relationship until an LDP session is
established over the active link so that the LDP session over and IGP route for the active link
can become available simultaneously.
NOTE
A Hold-down timer can be set on either an OSPF or IS-IS interface and can only be set in an IS-IS process,
not an OSPF process.
If different Hold-down values on an interface and in an IS-IS process are set, the setting on the interface
takes effect.
Procedure
1. Run:
system-view

2. Run:

3. Run:
ospf timer ldp-sync hold-down value
The Hold-down timer is set, which enables an OSPF interface to delay establishing
an OSPF neighbor relationship until an LDP session is established.

The default Hold-down time is 10s.

Set the Hold-down timer on a specified IS-IS interface.
1. Run:
system-view

2. Run:

3. Run:
isis timer ldp-sync hold-down value
The Hold-down timer is set, which enables an IS-IS interface to delay establishing an
IS-IS neighbor relationship until an LDP session is established.

Set the Hold-down timer on all IS-IS interfaces in a specified IS-IS process.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer ldp-sync hold-down value
The Hold-down timer is set, which enables all IS-IS interfaces within an IS-IS process
to delay establishing IS-IS neighbor relationships until LDP sessions are established.
----End
2.15.5 (Optional) Setting the Hold-max-cost Timer Value

This section describes how to set the hold-max-cost timer. The timer is an interval for advertising
the maximum cost using LSAs generated locally.
Context
If an LDP session over the active link fails but an IGP route for the active link is reachable, a
node that has LDP-IGP synchronization enabled uses a Hold-max-cost timer to enable an IGP
to advertise LSAs or LSPs carrying the maximum route cost, which delays IGP route
convergence until an LDP session is established. Therefore, an IGP route for a standby link and
an LDP session over the standby link can become available simultaneously.

NOTE
A Hold-max-cost timer can be set on either an OSPF or IS-IS interface and can only be set in an IS-IS
process, not an OSPF process.
If different Hold-max-cost values on an interface and in an IS-IS process are set, the setting on the interface
takes effect.
Procedure
1. Run:
system-view

2. Run:

3. Run:
ospf timer ldp-sync hold-max-cost { value | infinite }
The Hold-max-cost timer is set, which enables OSPF to keep advertising LSAs
carrying the maximum route cost.
The default Hold-max-cost time is 10s.
Either of the following parameters can be configured in this command:

– infinite: indicates that an OSPF interface keeps advertising LSAs carrying the
maximum cost value until an LDP session is established. This parameter ensures
that the OSPF route selects the same path over which an LDP LSP is established
when an OSPF network carries only LDP services.
– value: specifies the period of time during which an OSPF interface keeps
advertising LSAs carrying the maximum cost value. This parameter helps prevent
an LDP session disconnection from affecting OSPF routing or non-LDP services
when an OSPF network carries multiple types of services, including LDP services.
If the ospf timer ldp-sync hold-max-cost command is run more than once, the latest
configuration overrides the previous one.
Set the Hold-max-cost timer on a specified IS-IS interface.
1. Run:
system-view

2. Run:

3. Run:
isis timer ldp-sync hold-max-cost { value | infinite }
The Hold-max-cost timer is set, which enables IS-IS to keep advertising LSPs carrying
the maximum route cost.

Either of the following parameters can be configured in this command:

– infinite: indicates that an IS-IS interface keeps advertising LSPs carrying the
maximum cost value until an LDP session is established. This parameter ensures
that the IS-IS route selects the same path over which an LDP LSP is established
when an IS-IS network carries only LDP services.
– value: specifies the period of time during which an IS-IS interface keeps
advertising LSPs carrying the maximum cost value. This parameter helps prevent
an LDP session disconnection from affecting IS-IS routing or non-LDP services
when an IS-IS network carries various services, including LDP services.
If the isis timer ldp-sync hold-max-cost command is run more than once, the latest
configuration overrides the previous one.
Set the Hold-max-cost timer on all IS-IS interfaces in a specified IS-IS process.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer ldp-sync hold-max-cost { infinite | interval }
The Hold-max-cost timer is set, which enables IS-IS to keep advertising LSPs carrying
the maximum route cost on all interfaces within an IS-IS process.
If different Hold-max-cost values on an interface and in an IS-IS process are set, the
setting on the interface takes effect.
----End
2.15.6 (Optional) Setting the Delay Timer Value

This section describes how to set the delay timer. The timer is a period for waiting for the setup
of an LSP.
Context
Perform the following steps on the interfaces of both ends of the link between the crossing node
of active and standby links and the LDP neighboring node on the active link:
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
mpls ldp timer igp-sync-delay value
The period of waiting for the LSP setup after the establishment of an LDP session is set.
By default, the value of the delay timer is 10 seconds.
----End

LDP graceful deletion can be configured to speed up traffic switching using LDP-IGP
synchronization, improving network reliability.
Context
If the physical and protocol status of the primary link is proper but the LDP session on the primary
link goes Down, LDP-IGP synchronization enables LDP to inform the IGP of the primary link
fault, and the IGP configures the maximum cost value for the primary link. After that, LDP
immediately instructs the upstream device to withdraw labels and allocates labels to the upstream
device because a new LSP is set up on the secondary link, prolonging the LSP convergence time.
As a result, packet loss occurs.
After the LDP session on the faulty link goes Down, LDP does not immediately instruct the
upstream device to withdraw labels but keeps the labels and LSP and allows traffic to be
transmitted on the primary link until the LSP convergence is complete on the secondary link.
This ensures uninterrupted traffic and speeds up the LDP-IGP synchronization.
Perform the following operations on the LSR configured with LDP-IGP synchronization.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
graceful-delete


After the LDP session goes Down, LDP does not instruct the upstream device to withdraw labels
until the graceful deletion timer expires.
NOTE
system resources.
----End

After the configuration of LDP and IGP synchronization, you can view the synchronization and
route management information on interfaces enabled with LDP and IGP synchronization.
Prerequisites
The synchronization between LDP and IGP function has been configured.
Procedure
l Run the display ospf ldp-sync interface { all | interface-type interface-number } command
to check information about synchronization between LDP and OSPF on a specified
interface or all interfaces.
l Run the display isis [ process-id | vpn-instance vpn-instance-name ] ldp-sync interface
command to check information about synchronization between LDP and IS-IS on a
specified interface or all interfaces.
l Run the display rm interface [ interface-type interface-number | vpn-instance vpn-
instance-name ] command to check information about the route management module.
----End
Example
Run the display ospf ldp-sync interface-type interface-number command, and you can find that
the interface status becomes Sync-Achieved.
<HUAWEI> display ospf ldp-sync interface gigabitethernet 1/0/0
Interface gigabitethernet1/0/0
HoldDown Timer: 9 HoldMaxCost Timer: 50
LDP State: Up OSPF Sync State: Sync-Achieved
Run the display isis ldp-sync interface command, and you can find that the interface status
becomes Sync-Achieved.
<HUAWEI> display isis ldp-sync interface
Ldp Sync interface information for ISIS(1)
------------------------------------------
Interface HoldDownTimer HoldMaxCostTimer LDP State Sync State
GigabitEthernet1/0/0 10 10 Down Sync-Achieved

2.16 Configuring Synchronization Between LDP and Static

Routes
By configuring synchronization between LDP and static routes, you can switch traffic from a
faulty primary link to the backup link by suppressing the activation of static routes. You can
also delay traffic switchback to synchronize LDP and static routes.

Before configuring synchronization between LDP and static routes, familiarize yourself with
the usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
Usage Scenario
Synchronization between LDP and static routes is applicable to an MPLS network with primary
and backup LSPs. On this type of MPLS network, LSRs establish LSPs based on static routes.
When the LDP session of the primary link becomes faulty (the fault is not caused by a link
failure) or the primary link recovers, synchronization between LDP and static routes minimizes
traffic loss during traffic switchover and switchback. As shown in Figure 2-3, there is a static
route between LSRA and LSRD, and an LSP is established between the two devices based on
the static route. Normally, the link LSRA→LSRB→LSRD is preferred.
l In a switchover scenario, when the LDP session of the primary link becomes faulty (the
fault is not caused by a link failure), traffic transmitted through the static route is not
switched to the backup link. As a result, MPLS traffic on the primary link is interrupted.
Normally, after an LDP session is established, MPLS traffic is forwarded along the primary
link LSRA→LSRB→LSRD. If the LDP session between LSRA and LSRB is disconnected,
the LSP is immediately switched to the backup link LSRA→LSRC→LSRD. Because the
link between LSRA and LSRB works properly, traffic transmitted through the static route
is not switched to the backup link. As a result, LDP is not synchronous with the static route,
and MPLS traffic is interrupted.
After synchronization between LDP and static routes is enabled, when the LDP session
goes Down, traffic is automatically switched to the backup link, ensuring non-stop traffic
forwarding.
l In a switchback scenario, when the primary link recovers, traffic transmitted through a
static route is first switched back to the primary link because the static route converges
faster than LDP. However, the backup LSP becomes unavailable, and the primary LSP has
not been established. As a result, MPLS traffic is interrupted.
When the link between LSRA and LSRB becomes faulty, traffic is immediately switched
to the backup link LSRA→LSRC→LSRD. After the link between LSRA and LSRB
recovers, traffic transmitted through the static route is immediately switched to the primary
link LSRA→LSRB→LSRD. However, the backup LSP becomes unavailable, and the
primary LSP has not recovered. Therefore, traffic is interrupted.
After synchronization between LDP and static routes is enabled, when the primary LSP is
established, traffic is switched back to the primary link, ensuring non-stop traffic
forwarding.

Figure 2-3 Networking diagram for configuring synchronization between LDP and static routes
LSRB
LSRE LSRA LSRD
LSRC
Primary link
Bypass link
Before configuring synchronization between LDP and static routes, complete the following
tasks:
l Enable MPLS.
l Configure MPLS LDP in the system view and interface view.
l Establish LDP sessions between devices.
Data Preparation
To configure synchronization between LDP and static routes, you need the following data.
No. Data
1 Type and number of the outbound interface of a static route
2 Time during which a static route waits for an LDP session to be established, that is,
time of the Hold-down timer (optional)
2.16.2 Enabling Synchronization Between LDP and Static Routes

On an MPLS network with primary and backup LSPs, LSRs establish LSPs based on static
routes. By enabling synchronization between LDP and static routes on both ends of the two
links, you can avoid MPLS traffic interruption.

Context
With synchronization between LDP and static routes, you can switch traffic from the faulty
primary link to the backup link by suppressing the activation of static routes and delay traffic
switchback to the primary link, ensuring that LDP is synchronous with static routes.
NOTE
Only the static route with a specified outbound interface can be configured with synchronization between
LDP and static routes.
Perform the following steps on devices on both ends of the primary and backup links:
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip route-static ip-address { mask | mask-length } interface-type interface-number
[ nexthop-address ] [ preference preference | tag tag ] * ldp-sync [ description
text ]
Synchronization between LDP and static routes is configured.
By default, synchronization between LDP and static routes is not enabled.
----End
2.16.3 (Optional) Setting a Hold-down Timer

When the primary link recovers, a static route does not become active immediately. Instead, the
static route becomes active only when an LDP session is established before the Hold-down timer
expires. Then traffic is switched back to the primary link.
Context
After a Hold-down timer is set on an interface, the static route enabled with synchronization
between LDP and static routes becomes inactive temporarily and waits for an LDP session to
be established before the Hold-down timer expires. This implements synchronization between
LDP and static routes. If the Hold-down timer expires, the static route becomes active regardless
of whether the LDP session has been established.
NOTE
Setting a Hold-down timer on loopback interfaces or null interfaces is not allowed.
Procedure
Step 1 Run:
system-view
Step 2 Run:

The outbound interface view of the primary link of the static route is displayed.
Step 3 Run:
static-route timer ldp-sync hold-down { timer | infinite }
A Hold-down timer is set.

By default, a Hold-down timer is set to 10 seconds.
l If the Hold-down timer is set to 0 seconds, it indicates that synchronization between LDP
and static routes is disabled on an interface.
l If the Hold-down timer is set to infinite, it indicates that the timer never expires. In this case,
the static route becomes active and MPLS traffic is switched only after an LDP session is
established.
----End

After synchronization between LDP and static routes is configured, you can check the status of
all the interfaces configured with synchronization between LDP and static routes.
Prerequisites
Synchronization between LDP and static routes has been configured.
Procedure
l Run the display static-route ldp-sync [ interface interface-type interface-number ]
command to check the status of the interface configured with synchronization between LDP
and static routes.
If the parameter interface interface-type interface-number is specified, only the status of
a specified interface is displayed.
----End
Example
Run the display static-route ldp-sync command after configuring synchronization between
LDP and static routes. If the following is displayed, it means that the configuration succeeds.
<HUAWEI> display static-route ldp-sync
Total number of routes enable LDP-sync: 1
--------------------------------------------------------
interface GigabitEthernet1/0/0
Enable ldp-sync static routes number: 1
Static-route ldp-sync holddown timer: 10s
Sync State: Normal
Dest = 1.1.1.1, Mask = 32, NextHop = 2.2.2.2
---------------------------------------------------------
2.17 Configuring LDP Security Features

LDP security features such as MD5 authentication, keychain authentication, and the GTSM can
be configured to meet high network security requirements. By default, no authentication is

configured for LDP. Configuring security authentication is recommended to ensure system

security.

Before configuring LDP security features, familiarize yourself with the usage scenario, complete
Usage Scenario
The following LDP security features can be configured to meet network security requirements:
l LDP MD5 authentication
A typical MD5 application is to calculate a message digest to prevent message spoofing.
The MD5 message digest is a unique result calculated using an irreversible character string
conversion. If a message is modified during transmission, a different digest is generated.
After the message arrives at the receiving end, the receiving end can detect the modification
after comparing the received digest with a pre-computed digest.
The password of MD5 authentication can be recorded in either plaintext or cipher text.
During MD5 authentication configuration, two peers of an LDP session can be configured
with different record modes for password and must be configured with a single password.
l LDP keychain authentication
Keychain, an enhanced encryption algorithm similar to MD5, calculates a message digest
for an LDP message to prevent the message from being modified.
During keychain authentication, a group of passwords are defined in the format of a
password string, and each password is assigned a specified encryption and decryption
algorithm such as MD5 or secure hash algorithm-1 (SHA-1) and configured with a validity
period. When sending or receiving a packet, the system selects a valid password. Within
the validity period of the password, the system uses the encryption algorithm matching the
password to encrypt the packet before sending it out, or uses the decryption algorithm
matching the password to decrypt the packet before accepting it. In addition, the system
automatically uses a new password after the previous password expires, minimizing
password decryption risks.
Before configuring LDP keychain authentication, configure keychain authentication
globally. If LDP keychain authentication is configured before global keychain
authentication is configured, the LDP session will be disconnected.
l LDP GTSM
The GTSM checks TTL values to defend against attacks. An attacker simulates unicast
LDP messages and sends them to nodes. After receiving these messages, an interface board
on a node finds that the messages are destined for itself and directly sends them to the LDP
module on the control plane without verifying them. As a result, the node is busy in
processing these forged messages on the control plane, leading to high CPU usage.
To address this problem, the GTSM can be configured to check whether or not the TTL
value in the IP header is within a specified range, protecting the nodes against attacks and
improving system security.
Before configuring LDP security features, enable MPLS and MPLS LDP.

Data Preparation
To configure LDP security features, you need the following data.
No. Data
1 Transport address of each LDP peer
2 (Optional) MD5 authentication password

(Optional) Global keychain name
(Optional) Maximum number of hops permitted by the GTSM
2.17.2 Configuring LDP MD5 Authentication

LDP authentication can be configured to improve the security of the connection of an LDP
session. LDP authentication is configured on LSRs at both ends of an LDP session.
Context
MD5 authentication can be configured for a TCP connection over which an LDP session is
established, improving security. Note that the peers of an LDP session can be configured with
different authentication modes, but must be configured with a single password.
LDP MD5 authentication generates a unique digest for an information segment to prevent LDP
packets from being modified. LDP MD5 authentication is stricter than common checksum
verification for TCP connections.
You can configure either LDP MD5 authentication or LDP keychain authentication based on
their separate characteristics:
l The MD5 algorithm is easy to configure and generates a single password which can be
changed only manually. MD5 authentication applies to the network requiring short-period
encryption.
l Keychain authentication involves a set of passwords and uses a new password when the
previous one expires. Keychain authentication is complex to configure and applies to a
network requiring high security.
NOTE
Keychain authentication and MD5 authentication cannot be both configured on a single LDP peer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp

Step 3 Run:
md5-password { plain | cipher } peer-lsr-id password
MD5 authentication is configured and a password is set.
The password can be set in either plaintext or cipher text. A plaintext password is a pre-
configured character string that is directly recorded in a configuration file. A cipher text password
is a character string that is encrypted using a specified algorithm and recorded in a configuration
file.
By default, LDP MD5 authentication is not performed between LDP peers.
NOTICE
l When configuring an authentication password, select the ciphertext mode because the
password is saved in configuration files in plaintext if you select plaintext mode, which has
a high risk. To ensure device security, change the password periodically.
l Configuring LDP keychain authentication leads to reestablishment of an LDP session and
deletes the LSP associated with the LDP session.
----End
2.17.3 Configuring LDP Keychain Authentication

LDP keychain authentication can be configured to improve the security of a connection used by
an LDP session. LDP authentication is configured on LSRs at both ends of an LDP session.
Context
To help improve LDP session security, keychain authentication can be configured for a TCP
connection over which an LDP session has been established.
During keychain authentication, a group of passwords are defined in the format of a password
string, and each password is assigned a specified encryption and decryption algorithm such as
MD5 or secure hash algorithm-1 (SHA-1) and configured with a validity period. When sending
or receiving a packet, the system selects a valid password. Within the validity period of the
password, the system uses the encryption algorithm matching the password to encrypt the packet
before sending it out, or uses the decryption algorithm matching the password to decrypt the
packet before accepting it. In addition, the system automatically uses a new password after the
previous password expires, minimizing password decryption risks.
You can configure either LDP MD5 authentication or LDP keychain authentication based on
their separate characteristics:
l The MD5 algorithm is easy to configure and generates a single password which can be
changed only manually. MD5 authentication applies to the network requiring short-period
encryption.
l Keychain authentication involves a set of passwords and uses a new password when the
previous one expires. Keychain authentication is complex to configure and applies to a
network requiring high security.

NOTE
Keychain authentication and MD5 authentication cannot be both configured on a single LDP peer.
Before configuring LDP keychain authentication, configure keychain globally. For the detailed
configuration procedure, see the HUAWEI NetEngine80E/40E Router Configuration Guide -
Security.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
authentication key-chain peer peer-id name keychain-name
LDP keychain is enabled and a keychain name is specified.
By default, LDP keychain authentication is not performed between LDP peers.
NOTICE
Configuring LDP keychain authentication leads to reestablishment of an LDP session and deletes
the LSP associated with the LDP session.
----End
2.17.4 Configuring the LDP GTSM

The LDP GTSM can be configured on LSRs at both ends of an LDP session.
Context
The GTSM checks TTL values to verify packets and defend devices against attacks. LDP peers
are configured with the GTSM and a valid TTL range to check TTLs in LDP packets exchanged
between them. If the TTL in an LDP packet is out of the valid range, this LDP message is
considered invalid and discarded. The GTSM defends against CPU-based attacks initiated using
a large number of forged packets and protects upper-layer protocols.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls ldp

Step 3 Run:
gtsm peer ip-address valid-ttl-hops hops
The LDP GTSM is configured.

hops is the maximum number of valid hops permitted by the GTSM. If a TTL value carried in
a received packet is in a specified range of [255 - hops + 1, 255], the packet is accepted; if the
TTL value is out of the range, the packet is discarded.
----End

After configuring the LDP security features, you can view the configurations of LDP MD5
authentication, LDP keychain authentication, and the LDP GTSM.
Prerequisites
LDP security features have been configured.
Procedure
l Run the display mpls ldp session verbose command to check the configurations of LDP
MD5 authentication and LDP keychain authentication.
l Run the display gtsm statistics { slot-id | all } command to check GTSM statistics.
----End
Example
Run the display mpls ldp session verbose command to view the LDP MD5 authentication status
and the globally referenced keychain authentication name.

------------------------------------------------------------------------------
TCP Connection : 1.1.1.1 <- 2.2.2.2
Keychain Name : kc1

Capability:



10.1.1.2 2.2.2.2 10.1.2.1
------------------------------------------------------------------------------
Run the display gtsm statistics to view GTSM statistics on interface boards, including the
number of LDP, BGP, BGPv6, and OSPF packets that are received, accepted, and dropped.
<HUAWEI> display gtsm statistics all
GTSM Statistics Table
----------------------------------------------------------------
SlotId Protocol Total Counters Drop Counters Pass Counters
----------------------------------------------------------------
6 BGP 0 0 0
6 BGPv6 0 0 0
6 OSPF 0 0 0
6 LDP 11 0 11
0 OSPFv3 0 0 0
0 RIP 0 0 0
----------------------------------------------------------------
2.18 Configuring LDP GR

This section describes how to configure LDP GR. LDP GR implements the uninterrupted
forwarding during a master/slave switchover or the protocol restart, which minimizes the
protocol flapping on the control plane.

Before configuring LDP GR, familiarize yourself with the usage scenario, complete the pre-
Usage Scenario
You can enable LDP GR to maintain proper forwarding and resume the LDP session and
establish LSPs after a switchover or system update is performed.
NOTE
In practical applications, system-level GR is usually configured in the hardware environment with dual
main control boards. System-level GR allows the system to forward services if the main control board fails.
Before configuring LDP GR, complete the following tasks:
l Configure the IGP GR function.

l Configure the local MPLS LDP session.
Data Preparation
To configure LDP GR, you need the following data.

No. Data
1 MPLS LSR ID of the local node
2 (Optional) Value of the Reconnect timer of the LDP session
3 (Optional) Value of the LDP Neighbor-liveness timer
4 (Optional) Value of the LDP Recovery timer
2.18.2 Enabling LDP GR

This section describes how to configure LDP GR on both the GR Restarter and its neighbor
nodes.
Context
Perform the following steps on the LDP GR Restarter and its neighbor nodes:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls lsr-id lsr-id
The local LSR ID is configured.
Step 3 Run:
mpls
The MPLS function is enabled on the local node, and the MPLS view is displayed.
Step 4 Run:
quit
Step 5 Run:
mpls ldp
The LDP function is enabled on the local node, and the LDP view is displayed.
Step 6 Run:
graceful-restart
The GR function is enabled.
By default, the LDP GR function is disabled.

NOTE
l When the LDP GR is enabled or disabled, the LDP session is renewed.

l During the LDP GR process, the undo mpls ldp and reset mpls ldp commands are not permitted.
l During the LDP GR process, the modification of the LSP trigger policy using the lsp-trigger,
propagate mapping or lsp-trigger bgp-label-route command is invalid.
l During the LDP GR process, you are not permitted to run the mpls ldp frr nexthop command to enable
LDP FRR. Alternatively, run the undo mpls ldp frr nexthop command to disable LDP FRR.
----End
2.18.3 (Optional) Configuring GR Restarter Timer

You can set the value of a GR Restarter timer, that is, the Neighbor-liveness timer.
Context
Perform the following steps on the GR restarter:
NOTE
Modifying the values of LDP GR timers may lead to reestablishment of LDP sessions.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
graceful-restart timer neighbor-liveness time
The value of the Neighbor-liveness timer is set.
The value is 600 seconds.
----End
2.18.4 (Optional) Configuring GR Helper Timers

This section describes how to configure GR Helper timers. The GR Helper timers include the
Reconnect timer for an LDP session and the LSP Recovery timer.
Context
Perform the following steps on the GR Helper:
NOTE
If any timer value related to LDP GR is modified, the LDP session is reestablished.

Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls ldp

Step 3 Run:
graceful-restart timer reconnect time
The Reconnect timer for the LDP session is set.

By default, the Reconnect timer is set to 300 seconds.
Step 4 Run:
graceful-restart timer recovery time
The LSP Recovery timer is set.

By default, the LSP Recovery timer is set to 300 seconds.
Step 5 Run:
graceful-restart timer neighbor-liveness time
The Neighbor-liveness timer is set.

By default, the Neighbor-liveness timer is 600 seconds.
----End

After the configuration of LDP GR, you can view GR information about all protocols related to
MPLS, LDP information, and LDP session information.
Prerequisites
The LDP GR function has been configured.
Procedure
l Run the display mpls graceful-restart command to check information about GR of all
protocols related to MPLS.
l Run the display mpls ldp [ all ] [ verbose ] command to check LDP information.
l Run the display mpls ldp session [ all ] [ verbose ] command to check LDP session
information.
----End
Example
l Run the display mpls ldp command. The state of Graceful Restart is On, which means
that LDP GR has been enabled.


------------------------------------------------------------------------------
Graceful Restart : On FT Reconnect Timer : 300 Sec
------------------------------------------------------------------------------
------------------------------------------------------------------------------
l Run the display mpls ldp command or the display mpls ldp session verbose command
to view the values of the LDP session Reconnect timer, Neighbor-liveness timer, and LSP
Recovery timer.
------------------------------------------------------------------------------
TCP Connection : 10.0.35.7 -> 10.0.35.2
Session State : Operational Session Role : Active
Session FT Flag : On MD5 Flag : Off
Reconnect Timer : 300 Sec Recovery Timer : 300 Sec
Keychain Name : ---

Capability:
Outbound&Inbound Policies applied : NULL

10.0.35.2
------------------------------------------------------------------------------
2.19 Maintaining MPLS LDP

This section describes how to maintain MPLS LDP. The operations of MPLS LDP maintenance
include resetting LDP, monitoring the connectivity and reachability of an LSP, configuring alarm
thresholds for LDP LSPs, and configuring the trap function on an LDP LSP.

2.19.1 Resetting LDP

This section describes how to reset LDP.
Context
NOTICE
Resetting LDP may temporarily affect the reestablishment of the LSP. Exercise caution when
resetting LDP.
Resetting LDP is prohibited during the LDP GR.
After you confirm to reset LDP, run the following commands in the user view.
Procedure
l Run the reset mpls ldp command to reset the configurations of the global LDP instance.
l Run the reset mpls ldp vpn-instance vpn-instance-name command to reset LDP
configurations in a specified LDP instance.
l Run the reset mpls ldp all command to reset configurations in all LDP instances.
l Run the reset mpls ldp peer peer-id command to reset a specified peer.
l Run the reset mpls ldp vpn-instance vpn-instance-name peer peer-id command to reset
the peer in a specified VPN instance.
----End

command.
Context
Procedure



----End
2.19.3 Enabling the Trap Function on the LSP

This section describes how to configure the LSP trap function. The trap function on an LSP can
notify the network management system (NMS) of LSP status changes.
Context
Run the following commands in the system view to notify the NMS of LSP status changes.
By default, the trap function is disabled during the setup of an LDP LSP.
Procedure
command in the system view to enable the trap function for the LDP LSP and enable the
----End
2.19.4 Configuring a Policy for Triggering an LDP Session Status

Alarm
A policy for only allowing a public instance's LDP session status change to trigger an alarm. If
the status of an LDP session in a public network instance changes, an alarm is generated.
Context
In an LDP multi-instance scenario, a session status change by default triggers either an
mplsLdpSessionDown or mplsLdpSessionUp alarm for an LDP session in either a public
network instance or VPN instance. To allow a status change in an LDP session only in a public
network instance to trigger an alarm, configure a policy for triggering an LDP session status
alarm.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls ldp
Step 3 Run:
session-state-trap public-only

A policy for only allowing a public instance's LDP session status change to trigger an alarm is
configured.
----End

The following sections provide several examples for configuring MPLS LDP.
2.20.1 Example for Configuring Local LDP Sessions

This section describes how to configure local LDP sessions, including how to enable MPLS and
LDP on nodes and interfaces.
As shown in Figure 2-4, LSRA, LSRB, and LSRC are core routers on an MPLS network. A PE
transmits data traffic to the MPLS network. Before establishing an LSP to forward data traffic
within the MPLS network, configure local LDP sessions between LSRA and LSRB, and LSRB
and LSRC.
Addresses of interfaces are planned for LSRA, LSRB, and LSRC shown in Figure 2-5.
Figure 2-4 Networking diagram for a local LDP session (I)
Service provider's
backbone VPN 2
VPN 1
Site LSRA LSRB LSRC Site
CE CE
PE
PE
VPN 1
VPN 2 PE Site
Site P P P
CE
CE
Figure 2-5 Networking diagram for a local LDP session (II)

Loopback1 Loopback1 Loopback1
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS1/0/0 POS1/0/0 POS2/0/0 POS1/0/0
10.1.1.1/30 10.1.1.2/30 10.2.1.1/30 10.2.1.2/30
LSRA LSRB LSRC

1. Enable global MPLS and LDP on each LSR.
2. Enable MPLS on interfaces of each LSR.
3. Enable LDP on directly connected interfaces where local LDP sessions are to be
established.
Data Preparation
l IP address of every interface on every LSR as shown in Figure 2-5, OSPF process ID, and
OSPF area ID
l LSR ID of every LSR
Procedure
Step 1 Assign an IP address to every interface.
Configure IP addresses for interfaces on every LSR as shown in Figure 2-5, specify loopback
addresses as LSR IDs, and configure OSPF to advertise routes of network segments to which
the interfaces are connected and routes to the loopback addresses. For configuration details, see
Configuration files in this section.
Step 2 Enable global MPLS and LDP on every LSR.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
[LSRA-mpls-ldp] quit
# Configure LSRB.
<LSRB> system-view
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
[LSRB-mpls-ldp] quit
# Configure LSRC.
<LSRC> system-view
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
[LSRC-mpls-ldp] quit
Step 3 Enable MPLS on interfaces of every LSR.

# Configure LSRA.


# Configure LSRB.
# Configure LSRC.
Step 4 Enable LDP on interfaces where local LDP sessions are to be established.
# Configure LSRA.
[LSRA-Pos1/0/0] mpls ldp
# Configure LSRB.
[LSRB-Pos1/0/0] mpls ldp
# Configure LSRC.
[LSRC-Pos1/0/0] mpls ldp

After completing the preceding configurations, run the display mpls ldp session command on
every LSR. The status of each local LDP session between LSRA and LSRB, and LSRB and
LSRC is Operational.
<LSRA> display mpls ldp session
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
----End
Configuration Files

#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp

#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.2 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.2.1.0 0.0.0.3
#
return
2.20.2 Example for Configuring a Remote LDP Session

This example describes how to configure a remote LDP session. The configuration procedure
includes operations of enabling MPLS on each LSR and interfaces.
LSRA and LSRC are edge routers on a backbone network shown in Figure 2-6. An LDP LSP
can be configured across the backbone network to provide services for VPN sites. To establish
the LDP LSP, LSRA and LSRC must establish a remote LDP session between them.
Addresses of interfaces are planned for LSRA, LSRB, and LSRC shown in Figure 2-7.
Figure 2-6 Remote LDP session networking I
Service provider's
backbone
VPN 1 VPN 2
P
Site (LSRB) Site
CE CE
PE
PE (LSRC)
(LSRA)
VPN 1
VPN 2 Site
Site P PE
CE
CE

Figure 2-7 Remote LDP session networking II

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS1/0/0 POS1/0/0 POS2/0/0 POS1/0/0
10.1.1.1/30 10.1.1.2/30 10.2.1.1/30 10.2.1.2/30
LSRA LSRB LSRC
1. Enable MPLS and LDP globally on each LSR.
2. Specify a remote LDP peer and its IP address on two LSRs at both ends of a remote LDP
session.
Data Preparation
l IP addresses of the interfaces on each LSR, as listed in "Data Preparation" of Figure 2-7,
OSPF process IDs, and OSPF area IDs
l LSR ID of each LSR
l Name and IP address of each remote LDP peer of a remote LDP session
Procedure
Step 1 Assign an IP address to each interface and configure OSPF.
Assign an IP address and its mask to every physical interface; configure a loopback interface
address as an LSR ID on every LSR shown in Figure 2-7; configure OSPF to advertise the route
of the network segment of each interface and a host rout to each LSR ID. For configuration
details, see Configuration Files in this section.
Step 2 Enable MPLS and LDP globally on each LSR.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRB.
<LSRB> system-view
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp

# Configure LSRC.
<LSRC> system-view
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
Step 3 Specify a remote LDP peer and its IP address on two LSRs at both ends of a remote LDP session.
# Configure LSRA.
[LSRA] mpls ldp remote-peer LSRC
[LSRA-mpls-ldp-remote-lsrc] remote-ip 3.3.3.9
[LSRA-mpls-ldp-remote-lsrc] quit
# Configure LSRC.
[LSRC] mpls ldp remote-peer LSRA
[LSRC-mpls-ldp-remote-lsra] remote-ip 1.1.1.9
[LSRC-mpls-ldp-remote-lsra] quit
# After completing the preceding configurations, run the display mpls ldp session command
on each LSR. The command output shows that the remote LDP session between LSRA and
LSRC is in the Operational state.

[LSRA] display mpls ldp session
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
# Run the display mpls ldp remote-peer command on each LSR to view remote LDP peer
information.

[LSRA] display mpls ldp remote-peer

------------------------------------------------------------------------------
Remote Peer Name : LSRC

Auto-config : ---

------------------------------------------------------------------------------
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
mpls ldp remote-peer LSRC
remote-ip 3.3.3.9
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.252
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.1 255.255.255.252
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
return

#

sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
mpls ldp remote-peer LSRA
remote-ip 1.1.1.9
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.2 255.255.255.252
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.2.1.0 0.0.0.3
#
return
2.20.3 Example for Using LDP to Establish LSPs

This example describes how to use LDP to establish LSPs. The configuration procedure includes
operations of configuring a local LDP session and configuring a policy for triggering LDP LSP
establishment on each LSR.
LSRA, LSRB, and LSRC are core devices on an MPLS network shown in Figure 2-8. Adjacent
LSRs establish local LDP sessions between each other to establish LDP LSPs and swap labels
so that MPLS services can be transmitted. On the network shown in Figure 2-9, LDP is used to
establish an LSP between LSRA and LSRC.
Figure 2-8 LDP LSP networking I
Service provider's
backbone VPN 2
VPN 1
Site LSRA LSRB LSRC Site
CE CE
PE
PE
VPN 1
VPN 2 PE Site
Site P P P
CE
CE

Figure 2-9 LDP LSP networking II

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS1/0/0 POS1/0/0 POS2/0/0 POS1/0/0
10.1.1.1/30 10.1.1.2/30 10.2.1.1/30 10.2.1.2/30
LSRA LSRB LSRC
1. Configure a local LDP session.
2. (Optional) Modify a policy for triggering LDP LSP establishment on each LSR.
Data Preparation
l IP addresses of the interfaces on each LSR, as listed in "Data Preparation" of Figure 2-9,
OSPF process IDs, and OSPF area IDs
l (Optional) Policy for triggering LDP LSP establishment on each LSR
Procedure
Step 1 Configure LDP LSPs.
After completing the procedure described in 2.20.1 Example for Configuring Local LDP
Sessions on each LSR, LSPs use all hosts routes to establish LDP LSPs based on the default
policy for triggering LDP LSP establishment.
Run the display mpls ldp lsp command on each LSR. The command output shows that LDP
LSPs are established using all host routes.
[LSRA] display mpls ldp lsp
LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal DS/2.2.2.9
2.2.2.9/32 NULL/3 - 10.1.1.2 Pos1/0/0
2.2.2.9/32 1024/3 2.2.2.9 10.1.1.2 Pos1/0/0
3.3.3.9/32 NULL/1025 - 10.1.1.2 Pos1/0/0
3.3.3.9/32 1025/1025 2.2.2.9 10.1.1.2 Pos1/0/0
-------------------------------------------------------------------------------


NOTE
Usually, the default policy is used. Host routes are used to trigger LDP LSP establishment. In addition to
the default policy, a policy for triggering LDP LSP establishment can be configured manually. Perform
the following steps to configure a policy on each LSR.
Step 2 (Optional) Modify a policy for triggering LDP LSP establishment.
Modify the default policy and allow LDP to use all routes including all static and IGP routes in
the routing table to establish LDP LSPs on each LSR.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] lsp-trigger all
[LSRA-mpls] quit
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] lsp-trigger all
[LSRB-mpls] quit
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] lsp-trigger all
[LSRC-mpls] quit
After completing the preceding configurations, run the display mpls ldp lsp command to view
the established LDP LSPs.

LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal DS/2.2.2.9
2.2.2.9/32 NULL/3 - 10.1.1.2 Pos1/0/0
2.2.2.9/32 1024/3 2.2.2.9 10.1.1.2 Pos1/0/0
3.3.3.9/32 NULL/1025 - 10.1.1.2 Pos1/0/0
3.3.3.9/32 1025/1025 2.2.2.9 10.1.1.2 Pos1/0/0
10.1.1.0/30 3/NULL 2.2.2.9 10.1.1.1 Pos1/0/0
*10.1.1.0/30 Liberal DS/2.2.2.9
10.2.1.0/30 NULL/3 - 10.1.1.2 Pos1/0/0
10.2.1.0/30 1026/3 2.2.2.9 10.1.1.2 Pos1/0/0
-------------------------------------------------------------------------------
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
lsp-trigger all
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
lsp-trigger all
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
return

#
sysname LSRC

#
mpls lsr-id 3.3.3.9
mpls
lsp-trigger all
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.2 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.2.1.0 0.0.0.3
#
return
2.20.4 Example for Disabling Devices from Distributing LDP

Labels to Remote Peers
This section provides an example for disabling devices from distributing LDP labels to remote
peers.
On the network shown in Figure 2-10, PE1, PE2, and PE3 are connected to each other through
a P device on the MPLS backbone network, and IS-IS is enabled on all devices. LDP sessions
are established between PE1 and PE2 and between PE1 and PE3 to transmit VPN Label Mapping
messages to establish LSPs. Dynamic PWs are established between PE1 and PE2 and between
PE1 and PE3 over the LSPs.
The remote LDP sessions are expected to transmit Label Mapping messages carrying VC labels,
not LDP labels. PE1, PE2, and PE3 can be disabled from distributing LDP labels to remote peers,
which helps prevent LDP label wastes and minimize memory usage.
NOTE
In this example, routes to PEs' loopback interfaces are used as private routes. For configuration details, see
PWE3 Configuration.

Figure 2-10 Networking diagram for disabling devices from distributing LDP labels to remote
peers
Loopback 0
5.5.5.5/32
PE2
Loopback 0
.1 3
.2 1
.1 0/
PO 24
.1 0/
4
1.1.1.1/32
.1 1/
.1 1/
/2
/
20 OS
20 S
P
POS1/0/1
10.1.1.2/24 Loopback 0
POS1/0/1 2.2.2.2/32
10.1.1.1/24 P P
PE1 P 30 OS
30 OS .1 1/
.1 1/ .1 0 /
.1 0/ .2 0
.1 0 /2
/2 4
4
PE3
Loopback 0
4.4.4.4/32
1. Enable an IGP on the backbone network to allow devices on the backbone network to
communicate with each other.
2. Enable basic MPLS capabilities over the backbone network and set up LSPs.
3. Establish a remote MPLS LDP peer relationship between PEs on both ends of each PW.
4. Disable PEs on both ends of each PW from distributing LDP labels to remote peers.
5. Create MPLS L2VCs on PEs.
Data Preparation
l L2VC IDs on both ends of each PW (must be the same)

l Interface IP addresses and loopback addresses on each PE and the P
l MPLS LSR ID (equal to the loopback0 address) on each PE and the P
l IP addresses of PE's remote peers
Procedure

Assign an IP address to each interface, including loopback interfaces, according to Figure

2-10, and configure IS-IS to advertise routes to network segments to which interfaces are
connected and routes to host addresses that are the same as LSR IDs. For configuration details,
see Configuration Files in this section.
Step 2 Enable MPLS and MPLS LDP globally and on each interface.
# Configure PE1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1-Pos1/0/1] mpls
[PE1-Pos1/0/1] mpls ldp
[PE1-Pos1/0/1] quit
# Configure the P device.

<P> system-view
[P] mpls lsr-id 2.2.2.2
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
[P] interface pos 1/0/0
[P-Pos1/0/0] mpls
[P-Pos1/0/0] mpls ldp
[P-Pos1/0/0] quit
[P-Pos1/0/1] mpls
[P-Pos1/0/1] quit
[P-Pos1/0/3] mpls
[P-Pos1/0/3] quit
# Configure PE2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2-Pos1/0/1] mpls
[PE2-Pos1/0/1] quit
# Configure PE3.
<PE3> system-view
[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
[PE3-Pos1/0/0] mpls
[PE3-Pos1/0/0] quit

each device. The command output shows that the Status field is Operational. An LSP has been
established over an LDP session between each pair of directly connected devices on the public
network.
The following example uses the command output on PE1.

<PE1> display mpls ldp session
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Run the display mpls ldp lsp command to view information about LSPs and label advertisement.

<PE1> display mpls ldp lsp
LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/1025 DS/2.2.2.2
2.2.2.2/32 NULL/3 - 10.1.1.2 Pos1/0/1
2.2.2.2/32 1024/3 2.2.2.2 10.1.1.2 Pos1/0/1
4.4.4.4/32 NULL/1024 - 10.1.1.2 Pos1/0/1
4.4.4.4/32 1025/1024 2.2.2.2 10.1.1.2 Pos1/0/1
5.5.5.5/32 NULL/1026 - 10.1.1.2 Pos1/0/1
5.5.5.5/32 1026/1026 2.2.2.2 10.1.1.2 Pos1/0/1
-------------------------------------------------------------------------------
Step 3 Establish a remote MPLS LDP peer relationship between PEs on both ends of each PW.
# Configure PE1.
<PE1> system-view
[PE1] mpls ldp
[PE1-mpls-ldp] mpls ldp remote-peer PE2
[PE1-mpls-ldp-remote-pe2] remote-ip 5.5.5.5
[PE1-mpls-ldp-remote-pe2] mpls ldp remote-peer PE3
[PE1-mpls-ldp-remote-pe3] quit
# Configure PE2.
<PE2> system-view
[PE2] mpls ldp
# Configure PE3.

<PE3> system-view
[PE3] mpls ldp
each device. The command output shows that the Status field is Operational. Remote LDP
sessions between PEs have been established. The following example uses the command output
on PE1.
<PE1> display mpls ldp session
[PE1]display mpls ldp session

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Run the display mpls ldp lsp command. The command output shows that each PE has assigned
liberal labels to its remote peers. LDP labels that are not used on the MPLS PWE3 L2VPN are
wasted.
LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
1.1.1.1/32 3/NULL 5.5.5.5 127.0.0.1 InLoop0
1.1.1.1/32 3/NULL 4.4.4.4 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/1025 DS/2.2.2.2
*1.1.1.1/32 Liberal/1024 DS/5.5.5.5
*1.1.1.1/32 Liberal/1025 DS/4.4.4.4
2.2.2.2/32 NULL/3 - 10.1.1.2 Pos1/0/1
2.2.2.2/32 1024/3 2.2.2.2 10.1.1.2 Pos1/0/1
2.2.2.2/32 1024/3 5.5.5.5 10.1.1.2 Pos1/0/1
2.2.2.2/32 1024/3 4.4.4.4 10.1.1.2 Pos1/0/1
*2.2.2.2/32 Liberal/1025 DS/5.5.5.5
*2.2.2.2/32 Liberal/1024 DS/4.4.4.4
4.4.4.4/32 NULL/1024 - 10.1.1.2 Pos1/0/1
4.4.4.4/32 1025/1024 2.2.2.2 10.1.1.2 Pos1/0/1
4.4.4.4/32 1025/1024 5.5.5.5 10.1.1.2 Pos1/0/1
4.4.4.4/32 1025/1024 4.4.4.4 10.1.1.2 Pos1/0/1
*4.4.4.4/32 Liberal/1026 DS/5.5.5.5
*4.4.4.4/32 Liberal/3 DS/4.4.4.4
5.5.5.5/32 NULL/1026 - 10.1.1.2 Pos1/0/1
5.5.5.5/32 1026/1026 2.2.2.2 10.1.1.2 Pos1/0/1
5.5.5.5/32 1026/1026 5.5.5.5 10.1.1.2 Pos1/0/1
5.5.5.5/32 1026/1026 4.4.4.4 10.1.1.2 Pos1/0/1
*5.5.5.5/32 Liberal/3 DS/5.5.5.5
*5.5.5.5/32 Liberal/1026 DS/4.4.4.4
-------------------------------------------------------------------------------


Step 4 Disable PEs on both ends of each PW from distributing LDP labels to remote peers.
# Configure PE1.
<PE1> system-view
[PE1-mpls-ldp-remote-pe2] remote-ip 5.5.5.5 pwe3
[PE1-mpls-ldp-remote-pe2] mpls ldp remote-peer PE3
# Configure PE2.
<PE2> system-view
[PE2] mpls ldp remote-peer PE1
# Configure PE3.
<PE3> system-view
[PE3] mpls ldp remote-peer PE1
After completing the preceding configurations, run the display mpls ldp lsp command on each
PE to view information about LSPs that are established after a PWE3 policy is configured. LDP
labels for remote LDP sessions are not assigned to a directly connected PE.

LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/1025 DS/2.2.2.2
2.2.2.2/32 NULL/3 - 10.1.1.2 Pos1/0/1
2.2.2.2/32 1024/3 2.2.2.2 10.1.1.2 Pos1/0/1
4.4.4.4/32 NULL/1024 - 10.1.1.2 Pos1/0/1
4.4.4.4/32 1025/1024 2.2.2.2 10.1.1.2 Pos1/0/1
5.5.5.5/32 NULL/1026 - 10.1.1.2 Pos1/0/1
5.5.5.5/32 1026/1026 2.2.2.2 10.1.1.2 Pos1/0/1
-------------------------------------------------------------------------------
Run the display mpls ldp lsp command. The command output shows that LDP labels have been
withdrawn and LSPs established using the labels have been torn down. LSPs are established
only over local LDP sessions.
Step 5 Create a loopback interface on each PE to simulate VPN routes and create MPLS L2VCs using
the configured PW template.
# Configure PE1.

<PE1> system-view
[PE1] mpls l2vpn
[PE1-l2vpn] quit
[PE1] pw-template 1to3
[PE1-pw-template-1to3] peer-address 4.4.4.4
[PE1-pw-template-1to3] control-word
[PE1-pw-template-1to3] quit
[PE1] interface LoopBack 1
[PE1-LoopBack1] mpls l2vc pw-template 1to2 100 control-word
[PE1-LoopBack1] ip address 10.3.1.1 30
[PE1-LoopBack1] quit
# Configure PE3.
<PE3> system-view
[PE3] mpls l2vpn
[PE3-l2vpn] quit
# Configure PE2.
<PE2> system-view
[PE2] mpls l2vpn
[PE2-l2vpn] quit
After completing the preceding configurations, run the display mpls l2vc command on PE1.
The command output shows that that VCs are Up.
[PE1] display mpls l2vc
total LDP VC : 2 2 up 0 down
*client interface : LoopBack1

Administrator PW : no
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : IP-interworking
destination : 4.4.4.4

local VC label : 1027 remote VC label : 1027

control word : enable
forwarding entry : exist
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 : --
PW template name : 1to3
primary or secondary : primary
load balance type : flow
Access-port : false
create time : 0 days, 1 hours, 10 minutes, 45 seconds
up time : 0 days, 0 hours, 47 minutes, 26 seconds
last change time : 0 days, 0 hours, 47 minutes, 26 seconds
VC last up time : 2011/06/21 12:26:29
VC total up time : 0 days, 0 hours, 47 minutes, 26 seconds
CKey : 2
NKey : 1
AdminPw interface : --
AdminPw link state : --
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : --
Domain Name : --
*client interface : LoopBack2

session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 200
VC type : IP-interworking
destination : 5.5.5.5
local VC label : 1028 remote VC label : 1028
control word : enable
forwarding entry : exist
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 : --
PW template name : 1to2
primary or secondary : primary
load balance type : flow
Access-port : false
create time : 0 days, 0 hours, 0 minutes, 39 seconds
up time : 0 days, 0 hours, 0 minutes, 19 seconds
last change time : 0 days, 0 hours, 0 minutes, 19 seconds
VC last up time : 2011/06/21 13:13:37
VC total up time : 0 days, 0 hours, 0 minutes, 19 seconds
CKey : 4
NKey : 3
AdminPw interface : --
AdminPw link state : --
Diffserv Mode : uniform
Service Class : --
Color : --
This command output shows that the VCs can be established properly after a local PE is disabled
from distributing labels to its remote peer PE.

Run the ping vc ip-interworking 100 control-word remote 10.5.1.1 100 command on PE1.
The command output shows that PE1 and PE3 can communicate with each other using the VCs.
[PE1] ping vc ip-interworking 100 control-word remote 10.5.1.1 100

--- FEC: FEC 128 PSEUDOWIRE (NEW). Type = ip-interworking, ID = 100 ping
statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
#
mpls l2vpn
#
pw-template 1to2
peer-address 4.4.4.4
control-word
#
pw-template 1to3
control-word
#
mpls ldp
#
#
mpls ldp remote-peer pe2
remote-ip 4.4.4.4 pwe3
#
#
isis 1
is-level level-2
network-entity 86.4501.0010.0100.0001.00
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
interface LoopBack1
ip address 10.3.1.1 255.255.255.252

mpls l2vc pw-template 1to2 100 control-word

#
interface LoopBack2
ip address 11.2.1.1 255.255.255.252
#
return
l P configuration file
#
sysname P
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
isis 1
is-level level-2
network-entity 86.4501.0030.0300.0003.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 30.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos1/0/3
link-protocol ppp
undo shutdown
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 5.5.5.5
mpls
#
mpls l2vpn
#
pw-template 2to1
control-word
#
mpls ldp
#


#
isis 1
is-level level-2
network-entity 86.4501.0050.0500.0005.00
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
interface LoopBack2
ip address 11.1.1.1 255.255.255.252
#
return

#
sysname PE3
#
mpls lsr-id 4.4.4.4
mpls
#
mpls l2vpn
#
pw-template 3to1
control-word
#
mpls ldp
#
#
#
isis 1
is-level level-2
network-entity 86.4501.0040.0400.0004.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
interface LoopBack1
ip address 10.5.1.1 255.255.255.252
#
return

2.20.5 Example for Configuring LDP over TE

This section provides an example for configuring LDP over TE.
On the network shown in Figure 2-11, LDP is run between LSRA and LSRB, and between
LSRD and LSRE. LDP does not run between LSRB, LSRC and LSRD. RSVP tunnels from
LSRB to LSRD and from LSRD to LSRB are established. It is required that traffic between
LSRA and LSRE pass transmitted over tunnels.
LDP is not run between LSRB, LSRC, and LSRD.
Figure 2-11 Networking diagram for LDP over TE configuration

2.2.2.2/32 3.3.3.3/32 4.4.4.4/32
POS2/0/0 POS2/0/0
LSRB 20.1.1.1/24 30.1.1.1/24 LSRD
POS1/0/0 POS1/0/0
POS1/0/0 POS2/0/0
20.1.1.2/24 LSRC 30.1.1.2/24
10.1.1.2/24 40.1.1.2/24
POS1/0/0 POS1/0/0
10.1.1.1/24 40.1.1.1/24
Loopback1 Loopback1
1.1.1.1/32 5.5.5.5/32
LSRA LSRE
1. Configure IP addresses for interfaces on each LSR, configure loopback address as the LSR
IDs, and enable IGP.
2. Enable OSPF TE or IS-IS TE in the area supporting TE and create an MPLS TE tunnel.
3. Enable MPLS LDP in the area that does not support TE and configure LDP remote peer
on the border of TE.
4. Configure forwarding adjacency on the border of TE.
Data Preparation
To complete the configuration, you need the following data.
l IS-IS area ID and IS-IS level of each LSR

l Policy for triggering the establishment of the LSP (in this example the policy is all)
l Names and IP addresses of remote peers on LSRB and LSRD
l Bandwidth attributes for outbound interfaces of links along the tunnel

l Tunnel interface names, IP addresses, destination addresses, tunnel IDs, tunnel signaling
protocols (default RSVP-TE), tunnel bandwidths, TE metric values, and link cost values
of LSRB and LSRD
Procedure
Configure the IP address and mask for each interface as shown in Figure 2-11, including the
loopback interface. For configuration details, see Configuration Files in this section.
Step 2 Configure IGP.
Configure IS-IS on all LSRs to advertise LSR ID.
# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] network-entity 86.1111.1111.1111.00
[LSRA-isis-1] is-level level-2
[LSRA-isis-1] cost-style wide
[LSRA-isis-1] quit
[LSRA] interface loopback 1
[LSRA-LoopBack1] isis enable 1
[LSRA-LoopBack1] quit
[LSRA-Pos1/0/0] isis enable 1
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] network-entity 86.2222.2222.2222.00
[LSRB-isis-1] is-level level-2
[LSRB-isis-1] cost-style wide
[LSRB-isis-1] traffic-eng level-2
[LSRB-isis-1] quit
[LSRB] interface loopback 1
[LSRB-LoopBack1] isis enable 1
[LSRB-LoopBack1] quit
[LSRB-Pos1/0/0] isis enable 1
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] network-entity 86.3333.3333.3333.00
[LSRC-isis-1] is-level level-2
[LSRC-isis-1] cost-style wide
[LSRC-isis-1] traffic-eng level-2
[LSRC-isis-1] quit
[LSRC] interface loopback 1
[LSRC-LoopBack1] isis enable 1
[LSRC-LoopBack1] quit
[LSRC-Pos1/0/0] isis enable 1

# Configure LSRD.
[LSRD] isis 1
[LSRD-isis-1] network-entity 86.4444.4444.4444.00
[LSRD-isis-1] is-level level-2
[LSRD-isis-1] cost-style wide
[LSRD-isis-1] traffic-eng level-2
[LSRD-isis-1] quit
[LSRD] interface loopback 1
[LSRD-LoopBack1] isis enable 1
[LSRD-LoopBack1] quit
[LSRD-Pos1/0/0] isis enable 1
# Configure LSRE.
[LSRE] isis 1
[LSRE-isis-1] network-entity 86.5555.5555.5555.00
[LSRE-isis-1] is-level level-2
[LSRE-isis-1] cost-style wide
[LSRE-isis-1] quit
[LSRE] interface loopback 1
[LSRE-LoopBack1] isis enable 1
[LSRE-LoopBack1] quit
[LSRE] interface pos 1/0/0
[LSRE-Pos1/0/0] isis enable 1
[LSRE-Pos1/0/0] quit
After completing the configuration, run the display ip routing-table command on each LSR.
LSRs can learn routes from each other.
------------------------------------------------------------------------------
2.2.2.2/32 ISIS 15 10 D 10.1.1.2 Pos1/0/0
3.3.3.3/32 ISIS 15 20 D 10.1.1.2 Pos1/0/0
4.4.4.4/32 ISIS 15 30 D 10.1.1.2 Pos1/0/0
5.5.5.5/32 ISIS 15 40 D 10.1.1.2 Pos1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
20.1.1.0/24 ISIS 15 20 D 10.1.1.2 Pos1/0/0
30.1.1.0/24 ISIS 15 30 D 10.1.1.2 Pos1/0/0
40.1.1.0/24 ISIS 15 40 D 10.1.1.2 Pos1/0/0
Step 3 Configure basic MPLS functions on all LSRs, enable LDP on LSRA, LSRB, LSRD, and LSRE,
and enable RSVP on LSRB, LSRC, and LSRD.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp


# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] mpls te
[LSRB-mpls] mpls rsvp-te
[LSRB-mpls] mpls te cspf
[LSRB-mpls] quit
[LSRB] mpls ldp
[LSRB-Pos2/0/0] mpls te
[LSRB-Pos2/0/0] mpls rsvp-te
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] mpls te
[LSRC-mpls] mpls rsvp-te
[LSRC-mpls] quit
[LSRC-Pos1/0/0] mpls te
[LSRC-Pos1/0/0] mpls rsvp-te
# Configure LSRD.
[LSRD] mpls
[LSRD-mpls] mpls te
[LSRD-mpls] mpls rsvp-te
[LSRD-mpls] mpls te cspf
[LSRD-mpls] quit
[LSRD] mpls ldp
[LSRD-mpls-ldp] quit
[LSRD-Pos1/0/0] mpls te
[LSRD-Pos1/0/0] mpls rsvp-te
[LSRD-Pos2/0/0] mpls ldp
# Configure LSRE.
[LSRE] mpls lsr-id 5.5.5.5
[LSRE] mpls
[LSRE-mpls] quit

[LSRE] mpls ldp

[LSRE-mpls-ldp] quit
[LSRE-Pos1/0/0] mpls
[LSRE-Pos1/0/0] mpls ldp
After the configuration, the LDP session is established successfully between LSRA and LSRB,
and between LSRD and LSRE.
Run the display mpls ldp session command on LSRA, LSRB, LSRD, and LSRE. You can ss
whether LDP sessions are established.
Run the display mpls ldp peer command. You can see whether LDP peers have been set up.
Run the display mpls lsp command. RSVP LSP is not set up.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
[LSRA] display mpls ldp peer
------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.2:0 2.2.2.2 Pos1/0/0
------------------------------------------------------------------------------
[LSRA] display mpls lsp
----------------------------------------------------------------------
----------------------------------------------------------------------
2.2.2.2/32 NULL/3 -/Pos1/0/0
2.2.2.2/32 1024/3 -/Pos1/0/0
4.4.4.4/32 NULL/1026 -/Pos1/0/0
4.4.4.4/32 1027/1026 -/Pos1/0/0
3.3.3.3/32 NULL/1028 -/Pos1/0/0
3.3.3.3/32 1029/1028 -/Pos1/0/0
5.5.5.5/32 NULL/1029 -/Pos1/0/0
5.5.5.5/32 1030/1029 -/Pos1/0/0
Step 4 Configure the LDP remote session between LSRB and LSRD.
# Configure LSRB.
[LSRB] mpls ldp remote-peer LSRD
[LSRB-mpls-ldp-remote-LSRD] remote-ip 4.4.4.4
[LSRB-mpls-ldp-remote-LSRD] quit
# Configure LSRD.
[LSRB] mpls ldp remote-peer LSRB
[LSRB-mpls-ldp-remote-LSRB] remote-ip 2.2.2.2
[LSRB-mpls-ldp-remote-LSRB] quit

After completing the configuration, run the display mpls ldp remote-peer command on LSRB
or LSRD. The remote session is set up successfully between LSRB and LSRD.
The following example uses the command output on LSRB.

[LSRB] display mpls ldp remote-peer LSRD

------------------------------------------------------------------------------
Remote Peer Name : lsrd

------------------------------------------------------------------------------
Step 5 Configure the bandwidth attributes for the outbound interfaces of links along the TE tunnel.
# Configure LSRB.
[LSRB-Pos2/0/0] mpls te bandwidth max-reservable-bandwidth 20000
[LSRB-Pos2/0/0] mpls te bandwidth bc0 20000
# Configure LSRC.
[LSRC-Pos1/0/0] mpls te bandwidth max-reservable-bandwidth 20000
[LSRC-Pos1/0/0] mpls te bandwidth bc0 20000
# Configure LSRD.
[LSRD-Pos1/0/0] mpls te bandwidth max-reservable-bandwidth 20000
[LSRD-Pos1/0/0] mpls te bandwidth bc0 20000
Step 6 Configure a tunnel from LSRB to LSRD.
# On LSRB, enable forwarding adjacency on the tunnel interface and adjust the metric value of
forwarding adjacency to direct traffic of LSRD or LSRE to pass through the tunnel.
[LSRB] interface tunnel 1/0/0
[LSRB-Tunnel1/0/0] ip address unnumbered interface loopback 1
[LSRB-Tunnel1/0/0] tunnel-protocol mpls te
[LSRB-Tunnel1/0/0] destination 4.4.4.4
[LSRB-Tunnel1/0/0] mpls te tunnel-id 100
[LSRB-Tunnel1/0/0] mpls te bandwidth ct0 10000
[LSRB-Tunnel1/0/0] mpls te igp advertise
[LSRB-Tunnel1/0/0] mpls te igp metric absolute 1
[LSRB-Tunnel1/0/0] mpls te commit
[LSRB-Tunnel1/0/0] isis enable 1

Step 7 Configure a tunnel from LSRD to LSRB.
# On LSRD, enable forwarding adjacency on the tunnel interface and adjust the metric value of
forwarding adjacency to direct traffic of LSRA or LSRB to pass through the tunnel.
[LSRD] interface tunnel 1/0/0
[LSRD-Tunnel1/0/0] ip address unnumbered interface loopback 1
[LSRD-Tunnel1/0/0] tunnel-protocol mpls te
[LSRD-Tunnel1/0/0] destination 2.2.2.2
[LSRD-Tunnel1/0/0] mpls te tunnel-id 100
[LSRD-Tunnel1/0/0] mpls te bandwidth ct0 10000
[LSRD-Tunnel1/0/0] mpls te igp advertise
[LSRD-Tunnel1/0/0] mpls te igp metric absolute 1
[LSRD-Tunnel1/0/0] mpls te commit
[LSRD-Tunnel1/0/0] isis enable 1
# Run the display interface tunnel command. The tunnel has been set up.
[LSRB] display interface tunnel
Tunnel1/0/0 current state : UP
Line protocol current state : UP
Last up time: 2007-10-29, 16:35:10
Description : Tunnel1/0/0Interface
...
# Run the display mpls lsp command on LSRB, LSRC, and LSRD. The RSVP LSP has been
set up between them.
The following example uses the command output on LSRB.

[LSRB] display mpls lsp
-------------------------------------------------------------------------
LSP Information: RSVP LSP
-------------------------------------------------------------------------
4.4.4.4/32 NULL/1024 -/Pos2/0/0
-------------------------------------------------------------------------
-------------------------------------------------------------------------
3.3.3.3/32 1024/NULL -/-
1.1.1.1/32 NULL/3 -/Pos1/0/0
1.1.1.1/32 1028/3 -/Pos1/0/0
4.4.4.4/32 NULL/3 -/Tun1/0/0
4.4.4.4/32 1025/3 -/Tun1/0/0
5.5.5.5/32 NULL/1029 -/Tun1/0/0
5.5.5.5/32 1026/1029 -/Tun1/0/0
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
isis 1
is-level level-2

cost-style wide
network-entity 86.1111.1111.1111.00
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls ldp
#
mpls ldp remote-peer LSRd
remote-ip 4.4.4.4
#
isis 1
is-level level-2
cost-style wide
network-entity 86.2222.2222.2222.00
traffic-eng level-2
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 20000
mpls te bandwidth bc0 20000
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
interface Tunnel1/0/0
ip address unnumbered interface LoopBack1
tunnel-protocol mpls te
destination 4.4.4.4
mpls te tunnel-id 100
mpls te bandwidth ct0 10000
mpls te igp advertise
mpls te igp metric absolute 1
mpls te commit

isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 86.3333.3333.3333.00
traffic-eng level-2
#
interface Pos1/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 30.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls ldp
#
mpls ldp remote-peer LSRd
remote-ip 2.2.2.2
#
isis 1
is-level level-2
cost-style wide
network-entity 86.4444.4444.4444.00
traffic-eng level-2
#
interface Pos1/0/0

link-protocol ppp
ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 40.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
destination 2.2.2.2
mpls te commit
isis enable 1
#
return
l LSRE configuration file

#
sysname LSRE
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
isis 1
is-level level-2
cost-style wide
network-entity 86.5555.5555.5555.00
#
interface Pos1/0/0
link-protocol ppp
ip address 40.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
2.20.6 Example for Configuring LDP Graceful Deletion

This section provides an example for configuring LDP graceful deletion, including enabling
MPLS and MPLS LDP on devices and interfaces, and configuring parameters on the intersecting
device of the primary and secondary links and its directly connected device on the primary link.

As shown in Figure 2-12, two links are configured between PE1 and PE4. The link of PE1->P1-
>P2->P4 is the primary link; the link of PE1->P1->P3->P4 is the secondary link.
If the link between P1 and P2 becomes faulty, either of the following problems occurs:
l If the primary link physically goes Down, the LDP session and routes on the primary link
go Down accordingly. LDP immediately instructs the upstream device to withdraw labels
and triggers LDP Auto FRR, and the LSP on the secondary link will allocate labels to the
upstream device again, prolonging the convergence time. As a result, FRR switching is not
performed in time, causing packet loss.
l If the physical and protocol status of the primary link is proper but the LDP session on the
primary link goes Down, LDP-IGP synchronization enables LDP to inform the IGP of the
primary link fault, and the IGP configures the maximum cost value for the primary link.
After that, LDP immediately instructs the upstream device to withdraw labels and allocates
labels to the upstream device because a new LSP is set up on the secondary link, prolonging
the LSP convergence time. As a result, packet loss occurs.
LDP graceful deletion can resolve the preceding problems. If LDP graceful deletion is
configured, after the LDP session goes Down, the local device does not immediately instruct
the upstream device to withdraw labels but allows the upstream device to keep the labels,
speeding up the convergence of LDP Auto FRR and LDP-IGP synchronization and the primary/
secondary link switchover.
LDP Auto FRR, LDP-IGP synchronization, and LDP graceful deletion are configured on
interfaces of the intersecting device P1 and its directly connected device P2.
Figure 2-12 Configuring LDP graceful deletion
Loopback1
2.2.2.9/32
/1 G
10 E1/
E 1 /0 2 /3 0 .2. 0/3
Loopback1 Loopback1 G .1 . 1.1
.1 /30 Loopback1
5.5.5.9/32 1.1.1.9/32 /0/1 010 P2 G
10 E1/ 4.4.4.9/32
E 1 1 /3 .2. 0/1
GE1/0/1 G .1. 1.2
.1 /30
10.5.1.2/30 10
GE1/0/3
PE1 10.5.1.1/30 P1 G P4
10 E1 / 0/2 30
.3 . /0 / 1 /
1.1 2 G E .1 .2
/3 0 .4
G P3 10
10 E1/ /4
.3. 0/2
1.2 E 1/ 0 1/ 30
/30 G . 1.
.4
10
Loopback1 Primary link
3.3.3.9/32
Bypass link

1. Configure IP addresses for interfaces, and configure IS-IS to advertise routes to the network
segments where the interfaces reside and to advertise the routes to devices with LSR IDs.
2. Enable MPLS and MPLS LDP globally and on each interface.
3. Enable IS-IS Auto FRR on P1.
4. Configure the LDP LSP trigger policy for the backup LSP on P1.
5. Enable LDP Auto FRR, LDP-IGP synchronization, and LDP graceful deletion on interfaces
of the intersecting device P1 and its directly connected device P2.
6. Enable LDP graceful deletion on the intersecting device P1 and its directly connected device
P2.
Data Preparation
l IP addresses of the interfaces on each device, as listed in Figure 2-12, IS-IS process IDs,
and the area where each device resides
l Values of the hold-down timer and the delay timer
l LSP trigger policy for the backup LSP
Procedure
Step 1 Assign IP addresses to interfaces. Configure dynamic routes to make the devices reachable.
Configure IP addresses and masks for interfaces including loopback interfaces as shown in
Figure 2-12, and configure IS-IS to advertise routes to network segments to which the IP
addresses of interfaces belong and routes to hosts with LSR IDs. For configuration details, see
Configuration Files in this section.
The link of PE1->P1->P2->P4 is the primary link; the link of PE1->P1->P3->P4 is the secondary
link. The cost of GE 1/0/2 on P1 is 60.
Step 2 Enable MPLS and MPLS LDP globally and on each interface.
# Configure P1.
<P1> system-view
[P1] mpls lsr-id 1.1.1.9
[P1] mpls
[P1-mpls] quit
[P1] mpls ldp
[P1-mpls-ldp] quit
[P1] interface GigabitEthernet 1/0/1
[P1-GigabitEthernet 1/0/1] mpls
[P1-GigabitEthernet 1/0/1] mpls ldp
[P1-GigabitEthernet 1/0/1] quit

# Configure P2.
<P2> system-view
[P2] mpls
[P2-mpls] quit
[P2] mpls ldp
[P2-mpls-ldp] quit
# Configure P3.
<P3> system-view
[P3] mpls
[P3-mpls] quit
[P3] mpls ldp
[P3-mpls-ldp] quit
# Configure P4.
<P4> system-view
[P4] mpls
[P4-mpls] quit
[P4] mpls ldp
[P4-mpls-ldp] quit
# Configure PE1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] interface GigabitEthernet 1/0/1
[PE1-GigabitEthernet 1/0/1] mpls
[PE1-GigabitEthernet 1/0/1] mpls ldp
[PE1-GigabitEthernet 1/0/1] quit
After the preceding configuration is complete, LDP sessions are set up between directly
connected devices. Run the display mpls ldp session command on each device to view that the

value of the Status field is Operational. The following example uses the command output on
P1.
<P1> display mpls ldp session
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 3 Enable IS-IS Auto FRR on P1. View the routing information and the setup of the LSPs.
# Configure P1.
[P1] isis 1
[P1-isis-1] frr
[P1-isis-1-frr] loop-free-alternate
[P1-isis-1-frr] quit
[P1-isis-1] quit
# Display information about the routes between P1 and P4.

[P1] display ip routing-table 4.4.4.9 verbose

------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination: 4.4.4.9/32
Protocol: ISIS-L1 Process ID: 1
Preference: 15 Cost: 20
NextHop: 10.1.1.2 Neighbour: 0.0.0.0
State: Active Adv Age: 00h05m02s
Tag: 0 Priority: medium
Label: NULL QoSInfo: 0x0
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: GigabitEthernet1/0/1
TunnelID: 0x80001a Flags: D
BkNextHop: 10.3.1.2 BkInterface: GigabitEthernet1/0/2
BkLabel: NULL SecTunnelID: 0x800020
BkPETunnelID: 0x0 BkPESecTunnelID: 0x0
BkIndirectID: 0x0
The command output shows that IS-IS Auto FRR enables IS-IS to generate a backup route.
# Run the display mpls lsp command on P1 to view the setup of the LSPs.
[P1] display mpls lsp
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL -/-
2.2.2.9/32 NULL/3 -/GE1/0/1
2.2.2.9/32 1024/3 -/GE1/0/1
3.3.3.9/32 NULL/1025 -/GE1/0/1
**LDP FRR** /3 /GE1/0/2
3.3.3.9/32 1025/1025 -/GE1/0/1
**LDP FRR** /3 /GE1/0/2

4.4.4.9/32 NULL/1026 -/GE1/0/1

**LDP FRR** /1026 /GE1/0/2
4.4.4.9/32 1026/1026 -/GE1/0/1
**LDP FRR** /1026 /GE1/0/2
5.5.5.9/32 NULL/3 -/GE1/0/3
5.5.5.9/32 1027/3 -/GE1/0/3
The preceding command output shows that the setup of a backup LSP is triggered by LDP for
the routes with 32-bit addresses by default.
Step 4 Enable LDP Auto FRR and LDP-IGP synchronization and configure parameters on interfaces
of the intersecting device P1 and its directly connected device P2.
# Configure P1.
<P1> system-view
[P1-GigabitEthernet 1/0/1] isis ldp-sync
[P1-GigabitEthernet 1/0/1] isis timer ldp-sync hold-down 8
[P1-GigabitEthernet 1/0/1] isis timer ldp-sync hold-max-cost infinite
[P1-GigabitEthernet 1/0/1] mpls ldp timer igp-sync-delay 6
# Configure P2.
<P2> system-view
[P2-GigabitEthernet 1/0/1] isis ldp-sync
[P2-GigabitEthernet 1/0/1] isis timer ldp-sync hold-down 8
[P2-GigabitEthernet 1/0/1] isis timer ldp-sync hold-max-cost infinite
[P2-GigabitEthernet 1/0/1] mpls ldp timer igp-sync-delay 6
Step 5 Enable LDP graceful deletion on the intersecting device P1 and its directly connected P2.
# Configure P1.
<P1> system-view
[P1] mpls ldp
[P1-mpls-ldp] graceful-delete
[P1] quit
# Configure P2.
<P2> system-view
[P2] mpls ldp
[P2-mpls-ldp] graceful-delete
[P2] quit

After completing the preceding configuration, run the display mpls ldp command on P1. The
status of Graceful-Delete is On.
<P1> display mpls ldp

------------------------------------------------------------------------------
------------------------------------------------------------------------------


Label Distribution Mode : Ordered Label Retention Mode : Liberal
Graceful-Delete : On Graceful-Delete Timer : 5 Sec
------------------------------------------------------------------------------
----End
Configuration Files
#
sysname P1
mpls lsr-id 1.1.1.9

mpls
#
mpls ldp
auto-frr lsp-trigger host
graceful-delete
#
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
frr
loop-free-alternate level-1
#
undo shutdown
ip address 10.1.1.1 255.255.255.252
isis enable 1
isis ldp-sync
isis timer ldp-sync hold-down 8
isis timer ldp-sync hold-max-cost infinite
mpls
mpls ldp
mpls ldp timer igp-sync-delay 6
#
undo shutdown
ip address 10.3.1.1 255.255.255.252
isis enable 1
isis cost 60
mpls
mpls ldp
#
undo shutdown
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return
#
sysname P2

#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.252
isis enable 1
isis ldp-sync
isis timer ldp-sync hold-down 8
isis timer ldp-sync hold-max-cost infinite
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname P3
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
#
isis 1
is-level level-2
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1

#
return
#
sysname P4
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
#
isis 1
is-level level-2
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
#
sysname PE1
#
mpls lsr-id 5.5.5.9
mpls
#
mpls ldp
#
#
isis 1
is-level level-2
network-entity 10.0000.0000.0005.00
#
undo shutdown
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
isis enable 1
#
return

2.20.7 Example for Configuring an Inbound LDP Policy

This example describes how to configure an inbound LDP policy. The configuration procedure
includes operations of enabling MPLS and MPLS LDP globally.
MPLS LDP services are transmitted on the network shown in Figure 2-13. LSRD is a DSLAM
that is a low-performance access device. LSRD by default receives Label Mapping messages
from all peers and uses the routing information in these messages to establish a large number of
LSPs. As a result, memory on LSRD is overused and LSRD is overburdened. An inbound LDP
policy can be configured to allow LSRD to receive only Label Mapping messages for routes to
LSRC. Only an LSP originating from LSRD and destined for LSRC can be established,
efficiently using resources.
Figure 2-13 Inbound LDP policy

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS1/0/0 POS1/0/0 POS1/0/1 POS1/0/0
10.1.1.1/24 10.1.1.2/24 10.1.2.1/24 10.1.2.2/24
LSRB
LSRA LSRC
POS1/0/2
10.1.3.2/24
Loopback1
4.4.4.9/32
POS1/0/0
10.1.3.1/24
LSRD
1. Assign an IP address and a loopback address to each interface.

2. Configure OSPF to advertise the route to each network segment of each interface and to
3. Enable MPLS and MPLS LDP on each LSR and its interfaces.
4. Configure an inbound LDP policy.
Data Preparation

l IP address of every interface on every LSR shown in Figure 2-13, OSPF process IDs, and
OSPF area IDs
Procedure
Step 1 Assign an IP address to each interface and configure an IGP.
address as an LSR ID on every LSR shown in Figure 2-13; configure OSPF to advertise the
route of the network segment of each interface and a host rout to each LSR ID. For configuration
Step 2 Enable MPLS and MPLS LDP on each LSR and its interfaces.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRB.
<LSRB> system-view
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
# Configure LSRC.
<LSRC> system-view
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
# Configure LSRD.

<LSRD> system-view
[LSRD] mpls
[LSRD-mpls] quit
[LSRD] mpls ldp
# After completing the preceding configurations, run the display mpls lsp command on LSRD
to view information about the established LSPs.
[LSRD] display mpls lsp
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9/32 NULL/1024 -/Pos1/0/0
1.1.1.9/32 1024/1024 -/Pos1/0/0
2.2.2.9/32 NULL/3 -/Pos1/0/0
2.2.2.9/32 1025/3 -/Pos1/0/0
3.3.3.9/32 NULL/1025 -/Pos1/0/0
3.3.3.9/32 1026/1025 -/Pos1/0/0
The command output shows that LSPs to LSRA, LSRB, and LSRC have been established on
LSRD.
Step 3 Configure an inbound LDP policy.
# Configure an IP prefix list on LSRD to permit the routes only to LSRC to pass the inbound
LDP policy.
[LSRD] ip ip-prefix prefix1 permit 3.3.3.9 32
# Configure an inbound policy on LSRD to allow LSRD to receive Label Mapping messages
for the routes only to LSRC.
[LSRD] mpls ldp
[LSRD-mpls-ldp] inbound peer 2.2.2.9 fec ip-prefix prefix1

After completing the preceding configurations, run the display mpls lsp command on LSRD.
The command output shows that only an LSP to LSRC has been established.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
3.3.3.9/32 NULL/1025 -/Pos1/0/0
3.3.3.9/32 1026/1025 -/Pos1/0/0
----End
Configuration Files

sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
interface Pos1/0/0
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
interface Pos1/0/0
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos1/0/1
ip address 10.1.2.1 255.255.255.0
mpls
mpls ldp
#
interface Pos1/0/2
ip address 10.1.3.2 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 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 LSRC

#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
interface Pos1/0/0
ip address 10.1.2.2 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.1.2.0 0.0.0.255
#
return
#
sysname LSRD
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
inbound peer 2.2.2.9 fec ip-prefix prefix1
#
interface Pos1/0/0
ip address 10.1.3.1 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 10.1.3.0 0.0.0.255
#
ip ip-prefix prefix1 index 10 permit 3.3.3.9 32
#
return
2.20.8 Example for Configuring an Outbound LDP Policy

This example describes how to configure an outbound LDP policy. The configuration procedure
includes operations of enabling MPLS and MPLS LDP globally.
MPLS LDP services are transmitted on the network shown in Figure 2-14. LSRD is a DSLAM
that is a low-performance access device. LSRD by default receives Label Mapping messages
from all peers and uses the routing information in these messages to establish a large number of
LSPs. As a result, memory on LSRD is overused and LSRD is overburdened. An outbound LDP

policy can be configured on LSRB to send LSRD Label Mapping messages for routes only to
LSRC so that only LSPs to LSRC are established, saving resources.
Figure 2-14 Outbound LDP policy networking

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS1/0/0 POS1/0/0 POS1/0/1 POS1/0/0
10.1.1.1/24 10.1.1.2/24 10.1.2.1/24 10.1.2.2/24
LSRB
LSRA LSRC
POS1/0/2
10.1.3.2/24
Loopback1
4.4.4.9/32
POS1/0/0
10.1.3.1/24
LSRD
1. Assign an IP address and a loopback address to each interface.

2. Configure OSPF to advertise the route to each network segment of each interface and to
3. Enable MPLS and MPLS LDP on each LSR and its interfaces.
4. Configure an outbound LDP policy.
Data Preparation
OSPF area IDs
Procedure
Step 1 Assign an IP address to each interface and configure an IGP.

Step 2 Enable MPLS and MPLS LDP on each LSR and its interfaces.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRB.
<LSRB> system-view
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
# Configure LSRC.
<LSRC> system-view
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
# Configure LSRD.
<LSRD> system-view
[LSRD] mpls
[LSRD-mpls] quit
[LSRD] mpls ldp
# After completing the preceding configurations, run the display mpls lsp command on LSRD
to view information about the established LSPs.
-------------------------------------------------------------------------------


-------------------------------------------------------------------------------
1.1.1.9/32 NULL/1024 -/Pos1/0/0
1.1.1.9/32 1024/1024 -/Pos1/0/0
2.2.2.9/32 NULL/3 -/Pos1/0/0
2.2.2.9/32 1025/3 -/Pos1/0/0
3.3.3.9/32 NULL/1025 -/Pos1/0/0
3.3.3.9/32 1026/1025 -/Pos1/0/0
The command output shows that LSPs to LSRA, LSRB, and LSRC have been established on
LSRD.
Step 3 Configure an outbound LDP policy.
# Configure an IP prefix list on LSRB to permit the routes to LSRC to pass the outbound LDP
policy.
[LSRB] ip ip-prefix prefix1 permit 3.3.3.9 32
# Configure an outbound policy on LSRB to send LSRD Label Mapping messages for the routes
only to LSRC.
[LSRB] mpls ldp
[LSRB-mpls-ldp] outbound peer 4.4.4.9 fec ip-prefix prefix1

After completing the preceding configurations, run the display mpls lsp command on LSRD.
The command output shows that only an LSP to LSRC has been established.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
3.3.3.9/32 NULL/1025 -/Pos1/0/0
3.3.3.9/32 1026/1025 -/Pos1/0/0
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
interface Pos1/0/0
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#

ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
outbound peer 4.4.4.9 fec ip-prefix prefix1
#
interface Pos1/0/0
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos1/0/1
ip address 10.1.2.1 255.255.255.0
mpls
mpls ldp
#
interface Pos1/0/2
ip address 10.1.3.2 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 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
#
ip ip-prefix prefix1 index 10 permit 3.3.3.9 32
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
interface Pos1/0/0
ip address 10.1.2.2 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack1

ip address 3.3.3.9 255.255.255.255

#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.1.2.0 0.0.0.255
#
return
#
sysname LSRD
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
interface Pos1/0/0
ip address 10.1.3.1 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 10.1.3.0 0.0.0.255
#
return
2.20.9 Example for Configuring Transit LSPs Based on an IP Prefix

List
This example describes how to configure transit LSPs. The configuration procedure includes
operations of configuring local LDP sessions and configuring an IP prefix list on each transit
LSR to filter routes.
After MPLS LDP is enabled, LDP LSPs will be automatically established, leading to a large
number of transit LSPs and resulting in resource wastes. On the network shown in Figure
2-15, a policy for triggering transit LSP establishment can be configured on LSB so that a FEC
for a route to 4.4.4.4/32 can only be used to establish a transit LSP. This efficiently reduces the
number of unwanted LSPs and saves network resources.

Figure 2-15 Transit LSP networking

Loopback1 Loopback1
2.2.2.2/32 3.3.3.3/32
POS2/0/0
192.168.2.2/24
LSRB LSRC
POS1/0/0
POS1/0/0 192.168.2.1/24 POS2/0/0
192.168.1.2/24 192.168.3.1/24
POS1/0/0 POS1/0/0
192.168.1.1/24 192.168.3.2/24
LSRA LSRD
Loopback1 Loopback1
1.1.1.1/32 4.4.4.4/32
1. Configure the IP address and loopback address as an LSR ID of each interface, and
configure OSPF to advertise the route to each network segment of each interface and to
2. Configure an IP prefix list on transit LSRB to filter routes used to establish transit LSPs.
3. Enable MPLS and MPLS LDP globally on each LSR.
4. Enable MPLS and MPLS LDP on each interface.
Data Preparation
OSPF area IDs
l Policy for triggering transit LDP LSP establishment
l IP prefix list name and route that transit LSRB can use to establish a transit LSP
Procedure
Step 1 Assign an IP address to each interface and configure OSPF to advertise the route to each network
segment of each interface and to advertise the host route to each LSR ID.

Step 2 Configure an IP prefix list on transit LSRB.

# Configure an IP prefix list on transit LSRB to allow LDP to use a route to LSRD (4.4.4.4/32)
to establish a transit LSP.
[LSRB]ip ip-prefix FilterOnTransit permit 4.4.4.4 32
Step 3 Configure MPLS and MPLS LDP on each LSR and its interfaces.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] lsp-trigger all
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] lsp-trigger all
[LSRB-mpls] quit
[LSRB] mpls ldp
[LSRB-mpls-ldp] propagate mapping for ip-prefix FilterOnTransit
Repeat this step for LSRC and LSRD. For configuration details, see Configuration Files in this
section.
Run the display mpls ldp lsp command to view established LSPs.
# View LDP LSP information on LSRA.
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
2.2.2.2/32 NULL/3 - 192.168.1.2 Pos1/0/0
2.2.2.2/32 1024/3 2.2.2.2 192.168.1.2 Pos1/0/0
4.4.4.4/32 NULL/1026 - 192.168.1.2 Pos1/0/0
4.4.4.4/32 1026/1026 2.2.2.2 192.168.1.2 Pos1/0/0
192.168.1.0/24 3/NULL 2.2.2.2 192.168.1.1 Pos1/0/0
*192.168.1.0/24 Liberal
192.168.2.0/24 NULL/3 - 192.168.1.2 Pos1/0/0
192.168.2.0/24 1027/3 2.2.2.2 192.168.1.2 Pos1/0/0
-------------------------------------------------------------------------------


A '*' before a UpstreamPeer means the session is in GR state
# View LDP LSP information on LSRB.

[LSRB] display mpls ldp lsp
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 NULL/3 - 192.168.1.1 Pos1/0/0
2.2.2.2/32 3/NULL 1.1.1.1 127.0.0.1 InLoop0
2.2.2.2/32 3/NULL 3.3.3.3 127.0.0.1 InLoop0
*2.2.2.2/32 Liberal
*2.2.2.2/32 Liberal
3.3.3.3/32 NULL/3 - 192.168.2.1 Pos2/0/0
4.4.4.4/32 NULL/1026 - 192.168.2.1 Pos2/0/0
4.4.4.4/32 1026/1026 1.1.1.1 192.168.2.1 Pos2/0/0
4.4.4.4/32 1026/1026 3.3.3.3 192.168.2.1 Pos2/0/0
*4.4.4.4/32 Liberal
192.168.1.0/24 3/NULL 1.1.1.1 192.168.1.2 Pos1/0/0
192.168.1.0/24 3/NULL 3.3.3.3 192.168.1.2 Pos1/0/0
*192.168.1.0/24 Liberal
*192.168.1.0/24 Liberal
192.168.2.0/24 3/NULL 1.1.1.1 192.168.2.2 Pos2/0/0
192.168.2.0/24 3/NULL 3.3.3.3 192.168.2.2 Pos2/0/0
*192.168.2.0/24 Liberal
*192.168.2.0/24 Liberal
192.168.3.0/24 NULL/3 - 192.168.2.1 Pos2/0/0
-------------------------------------------------------------------------------
# View LDP LSP information on LSRC.

[LSRC] display mpls ldp lsp
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.2/32 NULL/3 - 192.168.2.2 Pos1/0/0
2.2.2.2/32 1025/3 2.2.2.2 192.168.2.2 Pos1/0/0
2.2.2.2/32 1025/3 4.4.4.4 192.168.2.2 Pos1/0/0
*2.2.2.2/32 Liberal
3.3.3.3/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
3.3.3.3/32 3/NULL 4.4.4.4 127.0.0.1 InLoop0
*3.3.3.3/32 Liberal
4.4.4.4/32 NULL/3 - 192.168.3.2 Pos2/0/0
4.4.4.4/32 1026/3 2.2.2.2 192.168.3.2 Pos2/0/0
4.4.4.4/32 1026/3 4.4.4.4 192.168.3.2 Pos2/0/0
*4.4.4.4/32 Liberal
192.168.1.0/24 NULL/3 - 192.168.2.2 Pos1/0/0
192.168.1.0/24 1027/3 2.2.2.2 192.168.2.2 Pos1/0/0
192.168.1.0/24 1027/3 4.4.4.4 192.168.2.2 Pos1/0/0
*192.168.1.0/24 Liberal
192.168.2.0/24 3/NULL 2.2.2.2 192.168.2.1 Pos1/0/0
192.168.2.0/24 3/NULL 4.4.4.4 192.168.2.1 Pos1/0/0
*192.168.2.0/24 Liberal

*192.168.2.0/24 Liberal
192.168.3.0/24 3/NULL 2.2.2.2 192.168.3.1 Pos2/0/0
192.168.3.0/24 3/NULL 4.4.4.4 192.168.3.1 Pos2/0/0
*192.168.3.0/24 Liberal
-------------------------------------------------------------------------------
# View LDP LSP information on LSRD.

[LSRD] display mpls ldp lsp
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.2/32 NULL/1025 - 192.168.3.1 Pos1/0/0
2.2.2.2/32 1025/1025 3.3.3.3 192.168.3.1 Pos1/0/0
3.3.3.3/32 NULL/3 - 192.168.3.1 Pos1/0/0
3.3.3.3/32 1026/3 3.3.3.3 192.168.3.1 Pos1/0/0
4.4.4.4/32 3/NULL 3.3.3.3 127.0.0.1 InLoop0
*4.4.4.4/32 Liberal
192.168.1.0/24 NULL/1027 - 192.168.3.1 Pos1/0/0
192.168.1.0/24 1027/1027 3.3.3.3 192.168.3.1 Pos1/0/0
192.168.2.0/24 NULL/3 - 192.168.3.1 Pos1/0/0
192.168.2.0/24 1028/3 3.3.3.3 192.168.3.1 Pos1/0/0
192.168.3.0/24 3/NULL 3.3.3.3 192.168.3.2 Pos1/0/0
*192.168.3.0/24 Liberal
-------------------------------------------------------------------------------
The command output shows that a single transit LDP LSP destined for 4.4.4.4/32 has been
established with the transit node of LSRB.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
lsp-trigger all
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls ldp
#

interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
lsp-trigger all
#
mpls ldp
propagate mapping for ip-prefix FilterOnTransit
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
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 2.2.2.2 0.0.0.0
#
ip ip-prefix FilterOnTransit index 10 permit 4.4.4.4 32
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
lsp-trigger all
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp

undo shutdown
ip address 192.168.3.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 3.3.3.3 0.0.0.0
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
lsp-trigger all
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.3.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 192.168.3.0 0.0.0.255
network 4.4.4.4 0.0.0.0
#
Return
2.20.10 Example for Configuring LDP to Automatically Send DoD

Requests
This example describes how to configure LDP to automatically send downstream on demand
(DoD) requests for labels. The configuration procedure includes operations of enabling MPLS
and MPLS LDP globally and configuring the DoD mode.
Pseudo wire emulation edge-to-edge (PWE3) refers to a technology that carries Layer 2 services
on a packet switched network (PSN). PWE3 sets up a pseudo wire (PW) over a public network
tunnel. To establish the public network tunnel, a remote LDP session must be created between
LSRA and LSRD shown in Figure 2-16. LSRA uses the remote LDP session to automatically
send DoD requests to LSRD for a Label Mapping message containing a route to the loopback
address (LSR ID) of LSRD. This reduces unneeded IP and MPLS entries and efficiently uses
network resources.

Figure 2-16 Networking for configuring LDP to automatically send DoD requests
Loopback0 Loopback0 Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32 4.4.4.4/32
POS1/0/0 POS1/0/1 POS1/0/1
10.1.1.1/24 10.1.2.1/24 10.1.3.1/24
POS1/0/0 POS1/0/0 POS1/0/0
10.1.1.2/24 10.1.2.2/24 10.1.3.2/24
LSRA LSRB LSRC LSRD
1. Assign an IP address and its mask to every interface and configure a loopback interface
address as an LSR ID on every node.
2. Configure basic IS-IS functions on backbone nodes and static routes to edge nodes and
their adjacent nodes.
3. Enable MPLS and MPLS LDP on each node and its interfaces.
4. Configure the DoD label advertisement mode.
5. Configure the inter-area LDP extension.
6. Configure a remote LDP session and enable LDP to automatically send requests for labels
advertised in DoD mode.
Data Preparation
l IP address of every interface on every node shown in Figure 2-16

l IS-IS level of each node
Procedure
Step 1 Assign an IP address and its mask to every interface and configure a loopback interface address
as an LSR ID on every node.
Assign an IP address and its mask to every physical interface and configure a loopback interface
address as an LSR ID on every node shown in Figure 2-16. For configuration details, see
Step 2 Configure basic IS-IS functions on backbone nodes and static routes to edge nodes and their
adjacent nodes.
# Configure basic IS-IS functions on LSRB.

<LSRB> system-view
[LSRB] isis 1
[LSRB-isis-1] quit

# Configure basic IS-IS functions on LSRC and import static routes.

<LSRC> system-view
[LSRC] isis 1
[LSRC-isis-1] import-route static
[LSRC-isis-1] quit
# Configure a default route with a next-hop address of 10.1.1.2 on LSRA.

<LSRA> system-view
[LSRA] ip route-static 0.0.0.0 0.0.0.0 10.1.1.2
# Configure LSRB with a static route to LSRA.

<LSRB> system-view
[LSRB] ip route-static 1.1.1.1 255.255.255.255 10.1.1.1
# Configure LSRC with a static route to LSRD.

<LSRC> system-view
[LSRC] ip route-static 4.4.4.4 255.255.255.255 10.1.3.2
# Configure a default route with a next-hop address of 10.1.3.1 on LSRD.

<LSRD> system-view
<LSRD> ip route-static 0.0.0.0 0.0.0.0 10.1.3.1
# Run the display ip routing-table command on LSRA to view route information. The
configured default route exists in the routing table of LSRA.
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 RD 10.1.1.2 Pos1/0/0

10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
# Run the display ip routing-table command on LSRB to view route information. The
configured static route to LSRA exists in the routing table of LSRB.
[LSRB] display ip routing-table
------------------------------------------------------------------------------

1.1.1.1/32 Static 60 0 RD 10.1.1.1 Pos1/0/0

3.3.3.3/32 ISIS-L1 15 10 D 10.1.2.2 Pos1/0/1
4.4.4.4/32 ISIS-L1 15 74 D 10.1.2.2 Pos1/0/1
10.1.1.0/24 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos1/0/1
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/1
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos1/0/1
Step 3 Enable MPLS and MPLS LDP on each node and its interfaces.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
Repeat this step for LSRB, LSRC, and LSRD. For configuration details, see Configuration
Files in this section.
Step 4 Configure the DoD mode.
# Configure LSRA.
[LSRA-Pos1/0/0] mpls ldp advertisement dod
# Configure LSRB.
[LSRB-Pos1/0/0] mpls ldp advertisement dod
# Configure LSRC.
[LSRC-Pos1/0/1] mpls ldp advertisement dod
# Configure LSRD.
[LSRD-Pos1/0/0] mpls ldp advertisement dod
Step 5 Configure the inter-area LDP extension to enable the longest match rule.
# Run the longest-match command on LSRA to enable LDP to use the longest match rule to
search for routes related to an LSP to be established.
[LSRA] mpls ldp
[LSRA-mpls-ldp] longest-match

# Run the longest-match command on LSRD to enable LDP to use the longest match rule to
search for routes related to an LSP to be established.
[LSRD] mpls ldp
[LSRD-mpls-ldp] longest-match
Step 6 Configure a remote LDP session and enable LDP to automatically send DoD requests.
# Configure LSRA.
[LSRA] mpls ldp remote-peer lsrd
[LSRA-mpls-ldp-remote-lsrd] remote-ip 4.4.4.4
[LSRA-mpls-ldp-remote-lsrd] remote-ip auto-dod-request
[LSRA-mpls-ldp-remote-lsrd] quit
# Configure LSRD.
[LSRD] mpls ldp remote-peer lsra
[LSRD-mpls-ldp-remote-lsra] remote-ip 1.1.1.1
[LSRD-mpls-ldp-remote-lsra] remote-ip auto-dod-request
[LSRD-mpls-ldp-remote-lsra] quit
# After completing the preceding configurations, run the display ip routing-table 4.4.4.4
command to view the route to LSRD (4.4.4.4) on LSRA.
[LSRA] display ip routing-table 4.4.4.4
------------------------------------------------------------------------------
Summary Count : 1
0.0.0.0/0 Static 60 0 RD 10.1.1.2 Pos1/0/0
The command output shows that there is only a default route to 4.4.4.4 in the routing table.
# Run the display mpls ldp lsp command on LSRA to view information about the established
LSP.
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
4.4.4.4/32 NULL/1026 - 10.1.1.2 Pos1/0/0
-------------------------------------------------------------------------------
The command output shows that an LSP destined for LSRD (4.4.4.4) has been established on
LSRA. LSRA has requested for a Label mapping message containing the route to 4.4.4.4 and
obtained the route, and the LSP has been successfully established.
# Run the display tunnel-info all command on LSRA to view information about the established
LSP.

[LSRA] display tunnel-info all

* -> Allocated VC Token
Tunnel ID Type Destination Token
----------------------------------------------------------------------
0x1000 lsp 4.4.4.4 0
The command output shows that the LSP originated from LSRA and destined for LSRD has
been established.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
longest-match
#
#
mpls ldp remote-peer lsrd
remote-ip 4.4.4.4
undo remote-ip pwe3
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
mpls ldp advertisement dod
#
interface NULL0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ip route-static 0.0.0.0 0.0.0.0 10.1.1.2
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#

interface Pos1/0/1
link-protocol ppp
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
ip route-static 1.1.1.1 255.255.255.255 10.1.1.1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
#
isis 1
network-entity 10.0000.0000.0002.00
import-route static
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos1/0/1
link-protocol ppp
ip address 10.1.3.1 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
ip route-static 4.4.4.4 255.255.255.255 10.1.3.2
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
longest-match
#
#
mpls ldp remote-peer lsra

remote-ip 1.1.1.1
undo remote-ip pwe3
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.3.2 255.255.255.0
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
ip route-static 0.0.0.0 0.0.0.0 10.1.3.1
#
return
2.20.11 Example for Configuring LDP Auto FRR

This example describes how to configure LDP Auto FRR. The configuration procedure includes
operations of enabling MPLS and MPLS LDP globally.
Network services such as VoIP, online video services, and online games are transmitted based
on VPN technologies, requiring high continuity. VPN services usually travel through LDP LSPs.
Data loss due to link faults adversely affects these services.
To improve service reliability, LDP Auto FRR can be configured. Compared with manual LDP
FRR, LDP Auto FRR does not require to specify a next-hop address. When LDP Auto FRR is
configured, a backup LSP is automatically created based on IGP routes. LDP Auto FRR
simplifies the configuration process and avoids loops that may occur in manual LDP FRR. It
applies to complex and large networks.
On the network shown in Figure 2-17, a primary LSP between LSRA and LSRC and a backup
LSP over a path LSRA -> LSRB -> LSRC are established. To allow traffic to rapidly switch to
the backup LSP if the primary LSP fails, LSRA can be configured with LDP Auto FRR,
minimizing traffic loss.

Figure 2-17 LDP Auto FRR networking

Loopback0
2.2.2.9/32
P
10 O S
.2 0
.1 1/
.1 0/
4
.3 0/
/2
.1 1/
.1 1
10 O S
LSRB /2
4
P backup LSP
PO .1.3
.1 0
10
.1 0/
4
S1 .2/
/2
.1 1/
10 O S
/ 0 24
/2
P
primary LSP POS1/0/0 LSRD

LSRA LSRC 10.1.4.1/24
POS1/0/1 POS1/0/1 POS1/0/0
10.1.2.1/24 10.1.2.2/24 10.1.4.2/24
1.1.1.9/32 3.3.3.9/32 4.4.4.9/32
1. Assign an IP address and its mask to every interface and configure a loopback interface
address as an LSR ID on every node.
2. Configure IS-IS to advertise the route to each network segment of each interface and to
3. Enable MPLS and MPLS LDP on each node and its interfaces.
4. Enable IS-IS Auto FRR on the ingress to protect traffic.
5. Configure a policy for triggering LDP LSP establishment based on all routes.
6. Configure a policy for triggering backup LDP LSP establishment on LSRA.
Data Preparation
l IP address of every interface on every node shown in Figure 2-17, IS-IS process ID, and
IS-IS area ID
l Policy for triggering backup LDP LSP establishment
Procedure
Step 1 Assign an IP address to every interface.
Assign an IP address and its mask to every physical interface and configure a loopback interface
address as an LSR ID on every node shown in Figure 2-17. For configuration details, see

Step 2 Configure IS-IS to advertise the route to each network segment of each interface and to advertise
the host route to each LSR ID.
# Configure LSRA.
<LSRA> system-view
[LSRA] isis 1
[LSRA-isis-1] quit
[LSRA] interface loopBack 0
# Configure LSRB.
<LSRB> system-view
[LSRB] isis 1
[LSRB-isis-1] quit
[LSRB] interface loopBack 0
# Configure LSRC.
<LSRC> system-view
[LSRC] isis 1
[LSRC-isis-1] quit
[LSRC] interface loopBack 0
# Configure LSRD.
<LSRD> system-view
[LSRD] isis 1
[LSRD-isis-1] quit
[LSRD] interface loopBack 0

Step 3 Configure MPLS and MPLS LDP on every node and its interfaces to forward MPLS traffic, and
verify LSP information.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
# Configure LSRD.
[LSRD] mpls
[LSRD-mpls] quit
[LSRD] mpls ldp

# After completing the preceding configurations, run the display mpls lsp command on LSRA
to view information about the established LSP.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.9/32 NULL/3 -/Pos1/0/0
2.2.2.9/32 1024/3 -/Pos1/0/0
3.3.3.9/32 NULL/3 -/Pos1/0/1
3.3.3.9/32 1025/3 -/Pos1/0/1
4.4.4.9/32 NULL/1026 -/Pos1/0/1
4.4.4.9/32 1026/1026 -/Pos1/0/1
The command output shows that the host route to an address with a 32-bit mask is used to
establish the LDP LSP. This means that the default policy for triggering LSP establishment is
used.
Step 4 Enable IS-IS Auto FRR on LSRA, and verify routing information and backup LSP information.
# Enable IS-IS Auto FRR on LSRA.
[LSRA] isis
[LSRA-isis-1] frr
[LSRA-isis-1-frr] loop-free-alternate
[LSRA-isis-1-frr] quit
[LSRA-isis-1] quit
# View routing information of direct links between LSRA and LSRC and between LSRC and
LSRD. The command output shows that a backup IS-IS route has been generated after IS-IS
Auto FRR was enabled.
[LSRA] display ip routing-table 10.1.4.0 verbose

------------------------------------------------------------------------------
Summary Count : 1
Destination: 10.1.4.0/24
Protocol: ISIS Process ID: 1
Preference: 15 Cost: 20
NextHop: 10.1.2.2 Neighbour: 0.0.0.0
State: Active Adv Age: 00h05m38s
Tag: 0 Priority: low
Label: NULL QoSInfo: 0x0
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: Pos1/0/1
TunnelID: 0x0 Flags: D
BkNextHop: 10.1.1.2 BkInterface: Pos1/0/0
BkLabel: NULL SecTunnelID: 0x0
BkPETunnelID: 0x0 BkPESecTunnelID: 0x0
BkIndirectID: 0x0
# Run the display mpls lsp command on LSRA to view LSP information.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.9/32 NULL/3 -/Pos1/0/0
**LDP FRR** /1025 /Pos1/0/1

2.2.2.9/32 1024/3 -/Pos1/0/0

**LDP FRR** /1025 /Pos1/0/1
3.3.3.9/32 NULL/3 -/Pos1/0/1
**LDP FRR** /1025 /Pos1/0/0
3.3.3.9/32 1025/3 -/Pos1/0/1
**LDP FRR** /1025 /Pos1/0/0
4.4.4.9/32 NULL/1026 -/Pos1/0/1
**LDP FRR** /1026 /Pos1/0/0
4.4.4.9/32 1026/1026 -/Pos1/0/1
**LDP FRR** /1026 /Pos1/0/0
The command output shows that the backup route to an address with a 32-bit mask is used to
establish the backup LSP. This means that the default policy for triggering backup LSP
establishment is used.
Step 5 Configure a policy to allow all routes to be used to trigger LDP LSP establishment, and view
LSP information.
# Run the lsp-trigger command on LSRC to allow all routes to be used to trigger LDP LSP
establishment and view LSP information.
[LSRC] mpls
[LSRC-mpls] lsp-trigger all
[LSRC-mpls] quit
# Run the display mpls lsp command on LSRA to view LSP information.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.9/32 NULL/3 -/Pos1/0/0
**LDP FRR** /1025 /Pos1/0/1
2.2.2.9/32 1024/3 -/Pos1/0/0
**LDP FRR** /1025 /Pos1/0/1
3.3.3.9/32 NULL/3 -/Pos1/0/1
**LDP FRR** /1025 /Pos1/0/0
3.3.3.9/32 1025/3 -/Pos1/0/1
**LDP FRR** /1025 /Pos1/0/0
4.4.4.9/32 NULL/1026 -/Pos1/0/1
**LDP FRR** /1026 /Pos1/0/0
4.4.4.9/32 1026/1026 -/Pos1/0/1
**LDP FRR** /1026 /Pos1/0/0
10.1.3.0/24 1027/3 -/Pos1/0/1
10.1.4.0/24 1028/3 -/Pos1/0/1
The command output shows that routes to addresses with 24-bit masks are used to set up LSPs.
Step 6 Configure a policy for triggering backup LSP establishment based all routes.
# Run the auto-frr lsp-trigger command on LSRA to allow LDP to use all backup routes to
establish backup LSPs.
[LSRA] mpls ldp
[LSRA-mpls-ldp] auto-frr lsp-trigger all

# After completing the preceding configurations, run the display mpls lsp command on LSRA
to view LSP information. The command output shows that a backup CR-LSP over a path LSRA
-> LSRB -> LSRC has been established for the primary CR-LSP over a path LSRA -> LSRC -
> LSRD.

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.9/32 NULL/3 -/Pos1/0/0
**LDP FRR** /1025 /Pos1/0/1
2.2.2.9/32 1024/3 -/Pos1/0/0
**LDP FRR** /1025 /Pos1/0/1
3.3.3.9/32 NULL/3 -/Pos1/0/1
**LDP FRR** /1025 /Pos1/0/0
3.3.3.9/32 1025/3 -/Pos1/0/1
**LDP FRR** /1025 /Pos1/0/0
4.4.4.9/32 NULL/1026 -/Pos1/0/1
**LDP FRR** /1026 /Pos1/0/0
4.4.4.9/32 1026/1026 -/Pos1/0/1
**LDP FRR** /1026 /Pos1/0/0
10.1.3.0/24 1027/3 -/Pos1/0/1
10.1.4.0/24 1028/3 -/Pos1/0/1
**LDP FRR** /1027 /Pos1/0/0
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
auto-frr lsp-trigger all
#
aaa
authentication-scheme default
#
authorization-scheme default
#
accounting-scheme default
#
domain default
#
#
isis 1
frr
network-entity 10.0000.0000.0001.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls

mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
oam-mgr
#
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
aaa
#
#
#
domain default
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
oam-mgr
#
#
return


#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
lsp-trigger all
#
mpls ldp
#
aaa
#
#
#
domain default
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.4.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos1/0/2
link-protocol ppp
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
oam-mgr
#
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.9
mpls

#
mpls ldp
#
aaa
#
#
#
domain default
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.4.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
oam-mgr
#
#
return
2.20.12 Example for Configuring LDP Authentication

This section provides an example for configuring LDP authentication. LDP message digest
algorithm 5 (MD5) and keychain authentication modes can be configured.
To improve LDP session security, you can configure LDP MD5 or keychain authentication for
LDP peers on both ends of an LDP session. You can choose either of the security authentication
modes based on their characteristics:
l MD5 authentication configuration is simple. MD5 keys must be manually updated at

intervals. MD5 authentication applies to networks that are encrypted within a short term.
l Keychain authentication involves a set of passwords and automatically updates a password
at intervals. Keychain authentication is complex to configure and applies to a network
requiring high security.
On the network shown in Figure 2-18, LDP sessions between PE1 and the P and between PE2
and the P are established. LDP LSPs are to be established over the LDP sessions. As the user
network connected to PE1 transmits important services, the LDP session between PE1 and the
P has high security requirements. The user network connected to PE2 transmits regular services.
Therefore, services transmitted over the LDP session between PE2 and the P can be encrypted

within a short term. To meet specific security requirements, you can configure the following
authentication modes:
l LDP keychain authentication for the LDP session between PE1 and the P
l LDP MD5 authentication for the LDP session between PE2 and the P
Figure 2-18 Networking diagram for LDP authentication

Loopback0
1.1.1.1/32
CE
GE1/0/0
10.1.1.1/24
Loopback0
PE1 3.3.3.3/32
GE1/0/0
10.1.1.2/24 P
GE1/0/1
Loopback0 10.1.2.2/24
2.2.2.2/32
GE1/0/0
10.1.2.1/24 IP/MPLS
backbone
PE2
CE
1. Configure basic IS-IS functions so that nodes are reachable at the network layer.
2. Configure local LDP sessions between PE1 and the P and between PE2 and the P.
3. Configure LDP keychain authentication for the LDP session between PE1 and the P.
4. Configure LDP MD5 authentication for the LDP session between PE2 and the P.
Data Preparation
l IS-IS process ID (1), area ID (10.0001), system ID converted using the loopback address
of each node, IS-IS level (Level-2)
l LSR ID, the same as the loopback address of each node, as shown in Figure 2-18
l Keychain name (kforldp) on PE1 and the P, TCP type value (180), TCP authentication
algorithm (SHA-1), algorithm ID (4), the tolerance time (15 minutes) for waiting to receive
authentication packets, and periodic validation parameters:
– Key 1: algorithm (SHA-1), password (huaweiwork), validity period (Monday to
Thursday)
– Key 2: algorithm (SHA-1), password (testpass), validity period (Friday to Sunday)

l MD5 authentication password (md5forLDP) for the LDP session between PE2 and the P
Procedure
Assign an IP address to each interface shown in Figure 2-18 and create a loopback interface on
each node. For configuration details, see Configuration Files in this section.
Step 2 Configure basic IS-IS functions and enable IS-IS on interfaces, including loopback interfaces,
on each node.
# Configure PE1.
<PE1> system-view
[PE1] is-is 1
[PE1-is-is-1] network-entity 10.0001.0010.0100.1001.00
[PE1-is-is-1] is-level level-2
[PE1-is-is-1] quit
[PE1] interface LoopBack0
[PE1-LoopBack0] isis enable 1
[PE1] interface GigabitEthernet1/0/0
[PE1-GigabitEthernet1/0/0] isis enable 1
[PE1-GigabitEthernet1/0/0] quit
Repeat the preceding step on PE2 and the P. For configuration details, see Configuration
Step 3 Configure local LDP sessions.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls ldp
[PE1-mpls-ldp] quit
[PE1-GigabitEthernet1/0/0] mpls
[PE1-GigabitEthernet1/0/0] mpls ldp
# Configure PE2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] mpls ldp
[PE2-mpls-ldp] quit
# Configure the P.
<P> system-view
[P] mpls
[P-mpls] mpls ldp
[P-mpls-ldp] quit
[P] interface GigabitEthernet1/0/0
[P-GigabitEthernet1/0/0] mpls
[P-GigabitEthernet1/0/0] mpls ldp
[P-GigabitEthernet1/0/0] quit

[P] interface GigabitEthernet1/0/1

[P-GigabitEthernet1/0/1] mpls ldp
Step 4 Configure keychain authentication over a TCP connection.

# Configure PE1.
[PE1] keychain kforldp mode periodic weekly
[PE1-keychain-kforldp] tcp-kind 180
[PE1-keychain-kforldp] tcp-algorithm-id sha-1 4
[PE1-keychain-kforldp] receive-tolerance 15
[PE1-keychain-kforldp] key-id 1
[PE1-keychain-kforldp-keyid-1] algorithm sha-1
[PE1-keychain-kforldp-keyid-1] key-string plain huaweiwork
[PE1-keychain-kforldp-keyid-1] send-time day mon to thu
[PE1-keychain-kforldp-keyid-1] receive-time day mon to thu
[PE1-keychain-kforldp-keyid-1] quit
[PE1-keychain-kforldp] key-id 2
[PE1-keychain-kforldp-keyid-2] algorithm sha-1
[PE1-keychain-kforldp-keyid-2] key-string plain testpass
[PE1-keychain-kforldp-keyid-2] send-time day fri to sun
[PE1-keychain-kforldp-keyid-2] receive-time day fri to sun
[PE1-keychain-kforldp-keyid-2] quit
[PE1-keychain-kforldp] quit
# Configure the P.
[P] keychain kforldp mode absolute
[P-keychain-kforldp] tcp-kind 180
[P-keychain-kforldp] tcp-algorithm-id sha-1 4
[P-keychain-kforldp] receive-tolerance 15
[P-keychain-kforldp] key-id 1
[P-keychain-kforldp-keyid-1] algorithm sha-1
[P-keychain-kforldp-keyid-1] key-string plain huaweiwork
[P-keychain-kforldp-keyid-1] send-time day mon to thu
[P-keychain-kforldp-keyid-1] receive-time day mon to thu
[P-keychain-kforldp-keyid-1] quit
[P-keychain-kforldp] key-id 2
[P-keychain-kforldp-keyid-2] algorithm sha-1
[P-keychain-kforldp-keyid-2] key-string plain testpass
[P-keychain-kforldp-keyid-2] send-time day fri to sun
[P-keychain-kforldp-keyid-2] receive-time day fri to sun
[P-keychain-kforldp-keyid-2] quit
[P-keychain-kforldp] quit
Step 5 Configure LDP keychain authentication.

# Configure PE1.
[PE1] mpls ldp
[PE1-mpls-ldp] authentication key-chain peer 3.3.3.3 name kforldp
[PE1-mpls-ldp] quit
# Configure the P.
[P] mpls ldp
[P-mpls-ldp] authentication key-chain peer 1.1.1.1 name kforldp
[P-mpls-ldp] quit
Step 6 Configure LDP MD5 authentication.

# Configure PE2.
[PE2] mpls ldp
[PE2-mpls-ldp] md5-password plain 3.3.3.3 md5forLDP
[PE2-mpls-ldp] quit

# Configure the P.
[P] mpls ldp
[P-mpls-ldp] md5-password plain 2.2.2.2 md5forLDP
[P-mpls-ldp] quit

# Run the display mpls ldp session verbose command on the P. The command output contains
the following information:
l The Session State value of each LDP session is Optional, indicating that the LDP session
is established successfully.
l The Keychain Name value is kforldp, indicating that keychain authentication is configured
successfully.
l The MD5 Flag value is On, indicating that MD5 authentication is configured successfully.
[P] display mpls ldp session verbose
------------------------------------------------------------------------------
TCP Connection : 3.3.3.3 -> 1.1.1.1
Keychain Name : kforldp

Capability:
mLDP P2MP Capability : On
mLDP MBB Capability : On

1.1.1.1 10.1.1.1
------------------------------------------------------------------------------
TCP Connection : 3.3.3.3 -> 2.2.2.2
Session FT Flag : Off MD5 Flag : On
Keychain Name : ---

Capability:
mLDP P2MP Capability : On
mLDP MBB Capability : On


2.2.2.2 10.1.2.1
------------------------------------------------------------------------------
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
authentication key-chain peer 3.3.3.3 name kforldp
#
#
keychain kforldp mode periodic weekly
receive-tolerance 15
tcp-kind 180
key-id 1
algorithm sha-1
key-string plain huaweiwork
send-time day mon to thu
receive-time day mon to thu
key-id 2
algorithm sha-1
key-string plain testpass
send-time day fri to sun
receive-time day fri to sun
#
isis 1
is-level level-2
network-entity 10.0001.0010.0100.1001.00
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
md5-password plain 3.3.3.3 md5forLDP
#
isis 1
is-level level-2
network-entity 10.0001.0020.0200.2002.00

#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname P
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
authentication key-chain peer 1.1.1.1 name kforldp
md5-password plain 2.2.2.2 md5forLDP
#
#
keychain kforldp mode periodic weekly
receive-tolerance 15
tcp-kind 180
key-id 1
algorithm sha-1
key-string plain huaweiwork
send-time day mon to thu
receive-time day mon to thu
key-id 2
algorithm sha-1
key-string plain testpass
send-time day fri to sun
receive-time day fri to sun
#
isis 1
is-level level-2
network-entity 10.0001.0030.0300.3003.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

2.20.13 Example for Configuring the LDP GTSM

This example describes how to configure the LDP GTSM. The configuration procedure includes
operations of enabling MPLS and MPLS LDP on each node and its interfaces, and configuring
LDP GTSM parameters on LSRs at both ends of an LDP session.
On the network shown in Figure 2-19, LSRs run MPLS and MPLS LDP. An attacker can send
simulated unicast LDP packets to LSRB, causing LSRB to be busy processing packets and
resulting in high CPU usage. To defend against the attack, LSRB can be configured with the
GTSM to accept packets carrying the TTL values within a specified range, improving system
security.
Figure 2-19 LDP GTSM networking

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0
10.1.1.1/30 10.1.1.2/30 10.2.1.1/30 10.2.1.2/30
LSRA LSRB LSRC
1. Configure basic MPLS and MPLS TE functions.

2. Configure the GTSM on LSRs at both ends of an LDP session.
Data Preparation
l LSR ID of each LDP peer

l Maximum number of hops permitted by the GTSM
Procedure
Step 1 Assign an IP address and its mask to every interface. For configuration details, see
Step 2 Configure OSPF to advertise the route of each network segment of each interface and to advertise
each host route to each LSR ID. For configuration details, see Configuration Files in this
section.
Step 3 Configure MPLS and MPLS LDP on LSRs and their interfaces. For configuration details, see

each LSR to view information about an LDP session. The following example uses the command
output on LSRA.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Configure the LDP GTSM.
# On LSRA, set the valid TTL value to a range of 253 to 255 for LDP packets sent from LSRB
to LSRA.
<LSRA> system-view
[LSRA] mpls ldp
[LSRA-mpls-ldp] gtsm peer 2.2.2.9 valid-ttl-hops 3
# On LSRB, set the valid TTL value to a range of 252 to 255 for LDP packets sent from LSRA
to LSRB; set the valid TTL value to a range of 251 to 255 for LDP packets sent from LSRC to
LSRB.
<LSRB> system-view
[LSRB] mpls ldp
[LSRB-mpls-ldp] gtsm peer 1.1.1.9 valid-ttl-hops 4
[LSRB-mpls-ldp] gtsm peer 3.3.3.9 valid-ttl-hops 5
# On LSRC, set the valid TTL value to a range of 250 to 255 for LDP packets sent from LSRB
to LSRC.
<LSRC> system-view
[LSRC] mpls ldp
[LSRC-mpls-ldp] gtsm peer 2.2.2.9 valid-ttl-hops 6
Use a PC to simulate LSRA and send LDP packets with TTL values that are beyond the range
of 252 to 255 to LSRB. After receiving the LDP packets and detecting that the TTL values in
the received packets are not in the configured range, LSRB discards the packets. GTSM statistics
on LSRB show that the number of dropped packets increases.
----End
Configuration Files
l Configuration file of LSRA
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
gtsm peer 2.2.2.9 valid-ttl-hops 3
#
interface GE1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.252

mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return
l Configuration file of LSRB

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
interface GE1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface GE2/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
return
l Configuration file of LSRC

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
interface GE1/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.2 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1

ip address 3.3.3.9 255.255.255.255

#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.2.1.0 0.0.0.3
#
return
2.20.14 Example for Configuring LDP Extension for Inter-Area LSPs

This section provides an example for configuring LDP extension for inter-area LSPs. The
procedure involves enabling global MPLS and MPLS LDP and configuring a policy for
aggregating routes.
On the network shown in Figure 2-20, there are two IGP areas, Area 10 and Area 20. Inter-area
LSPs need to be established from LSRA to LSRB and from LSRA to LSRC. An inter-area LSP
needs to be configured on LSRA so that LSRA can search for routes based on the longest match
rule to establish LSPs.
Figure 2-20 Networking diagram for configuring LDP Extension for Inter-Area LSP
Loopback0
1.3.0.1/32
0/1
Loopback0 Loopback0 S1/ /24 0 LSRB
O 1 /0/ 24
1.1.0.1/32 1.2.0.1/32 P .1.1. 1
S 2/
POS1/0/0 20 PO 1.1.
. IS-IS
10.1.1.1/24 PO 20
20 S1 Area10
POS1/0/0 .1. /0/
2.1 2
LSRA 10.1.1.2/24 LSRD /24 Loopback0
1.3.0.2/32
IS-IS PO
Area20 20 S1
.1. /0/
2.2 0
/24
LSRC

1. Assign IP addresses to interfaces on each node and configure the loopback addresses that
are used as LSR IDs.
2. Enable IS-IS.
3. Configure the policy for aggregating routes.
4. Enable global and interface-based MPLS and MPLS LDP on each node.
5. Configure LDP extension for inter-area LSPs.
Data Preparation
l IP address of each interface, as shown in Figure 2-20

l IS-IS area ID of each node and level of each node and interface
Procedure
Step 1 Assign IP addresses to interfaces on each node and configure the loopback addresses that are
used as LSR IDs.
Assign an IP address and a mask to each interface, including a loopback interface, according to
Figure 2-20. For configuration details, see Configuration Files in this section.
Step 2 Enable IS-IS.
# Configure LSRA.
<LSRA> system-view
[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRD.
<LSRD> system-view
[LSRD] isis 1
[LSRD-isis-1] quit
[LSRD-Pos1/0/0] isis circuit-level level-2

# Configure LSRB.
<LSRB> system-view
[LSRB] isis 1
[LSRB-isis-1] quit
# Configure LSRC.
<LSRC> system-view
[LSRC] isis 1
[LSRC-isis-1] quit
# On LSRA, run the display ip routing-table command to view routing information.

------------------------------------------------------------------------------

1.2.0.1/32 ISIS-L1 15 10 D 10.1.1.2 Pos1/0/0
1.3.0.1/32 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
1.3.0.2/32 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos10/0/0
20.1.1.0/24 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
20.1.2.0/24 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
Step 3 Configure the policy for aggregating routes.

# On LSRD, run the summary command to obtain the aggregated LSRB and LSRC host route.
[LSRD] isis 1
[LSRD-isis-1] summary 1.3.0.0 255.255.255.0 avoid-feedback
# On LSRA, run the display ip routing-table command to view routing information.

------------------------------------------------------------------------------

1.2.0.1/32 ISIS-L1 15 10 D 10.1.1.2 Pos1/0/0

1.3.0.0/24 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
20.1.1.0/24 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
20.1.2.0/24 ISIS-L1 15 20 D 10.1.1.2 Pos1/0/0
The command output shows that the host routes to LSRB and LSRC have been aggregated.
Step 4 Configure global and interface-based MPLS and MPLS LDP on each node so that the network
can forward MPLS traffic, and view the setup of the LSP.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRD.
[LSRD] mpls
[LSRD-mpls] quit
[LSRD] mpls ldp
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp

# After completing the configuration, run the display mpls lsp command on LSRA to view the
established LSP.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.2.0.1/32 NULL/3 -/Pos1/0/0
1.2.0.1/32 1024/3 -/Pos1/0/0
The preceding command output shows that by default, LDP does not establish the inter-area
LSPs from LSRA to LSRB and from LSRA to LSRC.
Step 5 Configure LDP extension for inter-area LSPs.
# Run the longest-match command on LSRA to configure LDP to search for a route based on
the longest match rule to establish an inter-area LDP LSP.
[LSRA] mpls ldp
[LSRA-mpls-ldp] longest-match
# After completing the preceding configuration, run the display mpls lsp command on LSRA
to view the established LSP.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.2.0.1/32 NULL/3 -/Pos1/0/0
1.2.0.1/32 1024/3 -/Pos1/0/0
1.3.0.1/32 NULL/1025 -/Pos1/0/0
1.3.0.1/32 1025/1025 -/Pos1/0/0
1.3.0.2/32 NULL/1026 -/Pos1/0/0
1.3.0.2/32 1026/1026 -/Pos1/0/0
The preceding command output shows that LDP establishes the inter-area LSPs from LSRA to
LSRB and from LSRA to LSRC.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.0.1
mpls
#
mpls ldp
longest-match
#
isis 1

is-level level-2
network-entity 20.0010.0100.0001.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 1.1.0.1 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 1.2.0.1
mpls
#
mpls ldp
#
isis 1
network-entity 10.0010.0200.0001.00
import-route isis level-1 into level-2 filter-policy ip-prefix permit-host
summary 1.3.0.0 255.255.255.0 avoid-feedback
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
isis circuit-level level-2
mpls
mpls ldp
#
interface Pos1/0/1
link-protocol ppp
undo shutdown
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface Pos1/0/2
link-protocol ppp
undo shutdown
ip address 20.1.2.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 1.2.0.1 255.255.255.255
isis enable 1
#
ip ip-prefix permit-host index 10 permit 0.0.0.0 32

#
return

#
sysname LSRB
#
mpls lsr-id 1.3.0.1
mpls
#
mpls ldp
#
isis 1
is-level level-1
network-entity 10.0010.0300.0001.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface NULL0
#
interface LoopBack0
ip address 1.3.0.1 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 1.3.0.2
mpls
#
mpls ldp
#
isis 1
is-level level-1
network-entity 10.0010.0300.0002.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 20.1.2.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 1.3.0.2 255.255.255.255
isis enable 1
#
return
2.20.15 Example for Configuring Static BFD for LDP LSP

This section provides an example for configuring a static BFD session to monitor an LDP LSP.
The procedure consists of enabling MPLS and MPLS LDP on each device and interface and
enabling BFD on both ends of a link to be monitored.

As shown in Figure 2-21, an LDP LSP is set up along the path of PE1 → P1→ PE2, and the
path of PE2 → P2 → PE1 works as an IP link. Static BFD sessions are required to monitor the
connectivity of the LDP LSP.
Figure 2-21 Networking diagram for static BFD for LDP LSP
Loopback1
2.2.2.9/32
P
0
/0/ 24 10 OS1
1 .1. /0
S 2/ 5.2 /1
PO 1.1. /24
. P
Loopback1 0
/0/ 4 10 P1 10 OS1 Loopback1
1.1.1.9/32 OS1 .1/2 .1. /0/ 4.4.4.9/32
5.1 0
P 1.1 /24
.
10 LDP LSP
P
PE1 10 OS 1
/0/ 24 PE2
.1. 1/0/ 1
S 1/
2.1 1
/24 PO 1.4.
.
P P2 10
10 OS1 /1
.1. /0/ S 1/0 /24
2.2 0
/24 PO 1.4.2
.
10
Loopback1
3.3.3.9/32
1. Configure OSPF for the MPLS domain and reachable IP routes to each LSR.
2. Set up an LDP LSP along the path of PE1 → P1 → PE2.
3. Configure PE1 with a BFD session that is bound to the LDP LSP.
4. Configure PE2 with a BFD session that is bound to the IP link to notify PE1 of the LDP
LSP faults.
Data Preparations
l IP address of each interface

l OSPF process number
l BFD configuration name, local discriminator, and remote discriminator

Procedure
Step 1 Configure the IP address and the OSPF protocol for each interface.
Assign the IP address and mask to each interface as shown in Figure 2-21, including loopback
interfaces.
Configure OSPF on all LSRs to advertise the host route of the loopback interface. For
After the configuration is complete, each LSR can ping each other using the LSR ID. Run the
display ip routing-table command to view the routing table on each LSR. The following
example uses the command output on PE1.
<PE1> display ip routing-table
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 2 D 10.1.1.2 Pos1/0/0
3.3.3.9/32 OSPF 10 2 D 10.1.2.2 Pos1/0/1
4.4.4.9/32 OSPF 10 3 D 10.1.2.2 Pos1/0/1
OSPF 10 3 D 10.1.1.2 Pos1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos1/0/1
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/1
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos1/0/1
10.1.4.0/24 OSPF 10 2 D 10.1.2.2 Pos1/0/1
10.1.5.0/24 OSPF 10 2 D 10.1.1.2 Pos1/0/0
Step 2 Set up an LDP LSP along the path PE1 → P1 → PE2.
# Configure PE1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls] quit
[PE1]interface pos 1/0/0
[PE1-Pos1/0/0] mpls
[PE1-Pos1/0/0] quit
# Configure P1.
<P1> system-view
[P1] mpls
[P1-mpls] quit
[P1] mpls ldp
[P1-mpls] quit
[P1]interface pos 1/0/0
[P1-Pos1/0/0] mpls
[P1-Pos1/0/0] mpls ldp
[P1-Pos1/0/0] quit

[P1]interface pos 1/0/1

[P1-Pos1/0/1] mpls
[P1-Pos1/0/1] quit
# Configure PE2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls] quit
[PE2]interface pos 1/0/0
[PE2-Pos1/0/0] mpls
[PE2-Pos1/0/0] quit
# Run the display mpls ldp lsp command. An LDP LSP destined for 4.4.4.9/32 is set up on PE1.
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal DS/2.2.2.9
2.2.2.9/32 NULL/3 - 10.1.1.2 Pos1/0/0
2.2.2.9/32 1024/3 2.2.2.9 10.1.1.2 Pos1/0/00
4.4.4.9/32 NULL/1025 - 10.1.1.2 Pos1/0/0
4.4.4.9/32 1025/1025 2.2.2.9 10.1.1.2 Pos1/0/0
-------------------------------------------------------------------------------
Step 3 Enable global BFD functions on LSRs at both ends of the monitored link.
# Configure PE1.
<PE1> system-view
[PE1] bfd
[PE1-bfd] quit
# Configure PE2.
<PE2> system-view
[PE2] bfd
[PE2-bfd] quit
Step 4 On the ingress, set up a BFD session that is bound to the LDP LSP.
# Configure PE1.
<PE1> system-view
[PE1] bfd 1to4 bind ldp-lsp peer-ip 4.4.4.9 nexthop 10.1.1.2 interface pos 1/0/0
[PE1-bfd-lsp-session-1to4] discriminator local 1
[PE1-bfd-lsp-session-1to4] discriminator remote 2
[PE1-bfd-lsp-session-1to4] process-pst
[PE1-bfd-lsp-session-1to4] commit

[PE1-bfd-lsp-session-1to4] quit
Step 5 On the egress, create a BFD session that is bound to the IP link to notify the ingress of LDP LSP
faults.
# Configure PE2.
<PE2> system-view
[PE2] bfd 4to1 bind peer-ip 1.1.1.9
[PE2-bfd-session-4ot1] discriminator local 2
[PE2-bfd-session-4ot1] discriminator remote 1
[PE2-bfd-session-4ot1] commit
[PE2-bfd-session-4ot1] quit

# After completing the configuration, run the display bfd session all verbose command on the
ingress PE1. Up is displayed in the State field, and LDP_LSP is displayed in the BFD Bind
Type field.
<PE1> display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 256 State : Up Name : 1to4
--------------------------------------------------------------------------------

Active Multi : 3
--------------------------------------------------------------------------------
# After completing the preceding configuration, run the display bfd session all verbose
command on the egress PE2. Up is displayed in the (MultiHop) State field, and Peer IP
Address is displayed in the BFD Bind Type field.
<PE2> display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 256 (Multi Hop) State : Up Name : 4to1
--------------------------------------------------------------------------------
BFD Bind Type : Peer IP Address
Bind Interface : -


Active Multi : 3
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos1/0/1
undo shutdown
link-protocol ppp
ip address 10.1.2.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
#
bfd 1to4 bind ldp-lsp peer-ip 4.4.4.9 nexthop 10.1.1.2 interface Pos1/0/0
process-pst
commit
#
return

#
sysname PE2
#

bfd
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.5.1 255.255.255.0
mpls
mpls ldp
#
interface Pos1/0/1
undo shutdown
link-protocol ppp
ip address 10.1.4.1 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bfd 4to1 bind peer-ip 1.1.1.9
commit
#
ospf 1
area 0.0.0.0
network 10.1.5.0 0.0.0.255
network 10.1.4.0 0.0.0.255
network 4.4.4.9 0.0.0.0
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos1/0/1
undo shutdown
link-protocol ppp
ip address 10.1.5.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.5.0 0.0.0.255

#
return
#
sysname P2
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.2.2 255.255.255.0
#
interface Pos1/0/1
undo shutdown
link-protocol ppp
ip address 10.1.4.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.1.4.0 0.0.0.255
network 10.1.2.0 0.0.0.255
#
return
2.20.16 Example for Configuring Dynamic BFD for LDP LSP

This section provides an example for configuring a dynamic BFD session to monitor an LDP
LSP. The procedure consists of enabling MPLS and MPLS LDP on each device and interface
and enabling BFD on the ingress and egress to be monitored.
As shown in Figure 2-22, LSRA, LSRB, and LSRC locate in one MPLS domain. An LDP LSP
is established between LSRA and LSRC that requires dynamic BFD for LDP LSP. The time to
detect a failure is within 50 ms.
Figure 2-22 Networking diagram for dynamic BFD for LDP LSP
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS1/0/0 POS2/0/0
192.168.1.1/24 192.168.2.1/24
POS1/0/0 POS1/0/0
LSRA 192.168.1.2/24 LSRB 192.168.2.2/24 LSRC
1. Enable basic MPLS function on each LSR and establish the LDP LSP links.
2. Configuration basic BFD functions.

3. Adjust BFD parameters.
Data Preparations
Before configuring, you need the following data:
l LSR IDs and IP addresses of the interfaces on each LSR

l BFD parameters
Procedure
Step 1 Assign the IP address and mask to each interface. For configuration details, see Configuration
Step 2 Configure OSPF. For configuration details, see Configuration Files in this section.
Step 3 Configure basic MPLS functions.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# The configuration on LSRB and LSRC is the same as that on LSRA. The configuration details
are not provided here.
After completing the configuration, run the display mpls ldp lsp command on LSRA. An LDP
LSP is set up between LSRA and LSRC.

<LSRA> display mpls ldp lsp
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal DS/2.2.2.9
2.2.2.9/32 NULL/3 - 192.168.1.2 Pos1/0/0
2.2.2.9/32 1024/3 2.2.2.9 192.168.1.2 Pos1/0/0
3.3.3.9/32 NULL/1025 - 192.168.1.2 Pos1/0/0
3.3.3.9/32 1025/1025 2.2.2.9 192.168.1.2 Pos1/0/0
-------------------------------------------------------------------------------
Step 4 Configure dynamic BFD for LDP LSP from LSRA to LSRC.

# Configure a FEC list on LSRA to ensure that BFD for LDP LSP only from LSRA to LSRC is
triggered.
[LSRA] fec-list tortc
[LSRA-fec-list-tortc] fec-node 3.3.3.9
# Enable BFD on LSRA. Specify the FEC list that triggers a BFD session dynamically. Adjust
BFD parameters.
[LSRA] bfd
[LSRA-bfd] quit
[LSRA] mpls
[LSRA-mpls] mpls bfd-trigger fec-list tortc
[LSRA-mpls] mpls bfd enable
[LSRA-mpls] mpls bfd min-tx-interval 600 min-rx-interval 600 detect-multiplier 4
# Configure on LSRC with passively enabled BFD to monitor the LSP.

[LSRC] bfd
[LSRC-bfd] mpls-passive
# Run the display bfd session all verbose command to view the status of the BFD session that
is created dynamically. The following example uses the command output on LSRA.
<LSRA> display bfd session all verbose
-----------------------------------------------------------
-----------------------------------------------------------
Local Discriminator: 8192 Remote Discriminator : 8193
Echo Passive : Disable Acl Number : --
Proc interface status : Disable Process PST : Enable
WTR Interval (ms) : --
Active Multi : 3
Session Echo Tx TmrID : --
-----------------------------------------------------------
# Display the status of the BFD session created dynamically on LSRC. The field of BFD bind
type is Peer IP Address. This indicates that the BFD packets sent by LSRC are transported over
IP routes.
<LSRC> display bfd session passive-dynamic verbose
-----------------------------------------------------------
Session MIndex : 257 (Multi Hop) State : Up Name : dyn_8193
-----------------------------------------------------------


Bind Session Type : Entire_Dynamic
Bind Interface : --
Echo Passive : Disable Acl Number : --
Proc interface status : Disable Process PST : Disable
WTR Interval (ms) : -- Local Demand Mode : Disable
Active Multi : 4
Bind Application
Session Echo Tx TmrID : --
-----------------------------------------------------------
----End
Configuration Files
#
sysname LSRA
#
bfd
#
mpls lsr-id 1.1.1.9
mpls
mpls bfd enable
mpls bfd-trigger fec-list tortc
mpls bfd min-tx-interval 600 min-rx-interval 600 detect-multiplier 4
#
fec-list tortc
fec-node 3.3.3.9
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 100
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9

mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 100
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return

#
sysname LSRC
#
bfd
mpls-passive
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 100
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
2.20.17 Example for Configuring Dynamic BFD to Monitor an LDP

Tunnel
This section provides an example for configuring dynamic BFD to monitor an LDP tunnel. The
configuration involves configuring LDP FRR and configuring dynamic BFD for LDP tunnel.

When LDP LSPs transmit application traffic, for example, VPN, to improve network reliability,
LDP FRR and an LDP upper-layer protection mechanism, such as VPN FRR or VPN equal-cost
multipath (ECMP), are used. BFD for LDP LSP only detects primary LSP faults and switches
traffic to an FRR LSP. If the primary and FRR LSP fail simultaneously, the BFD mechanism
does not take effect. In this situation, LDP can instruct its upper-layer application to perform a
protection switchover only after LDP detects the FRR LSP failure. As a result, a great number
of packets are dropped.
To minimize packet loss, dynamic BFD can be configured to dynamically establish BFD sessions
to monitor both the primary and FRR LSPs in an LDP tunnel. If both primary and FRR LSPs
fail, BFD rapidly detects the failures and instructs a specific LDP upper-layer application to
perform a protection switchover.
On the network shown in Figure 2-23, an LDP LSP originates from LSRA and is destined for
LSRD. LDP Auto FRR is configured to protect LSP traffic. LSRA establishes the primary LSP
over the path LSRA -> LSRC -> LSRD and the FRR LSP over the path LSRA -> LSRB ->
LSRC -> LSRD. Dynamic BFD for LDP tunnel can be configured to dynamically create a BFD
session to monitor both the primary and FRR LSPs.
Figure 2-23 Dynamic BFD for LDP tunnel networking

Loopback0
3.3.3.3/32
10 GE
.1 1/0
.2 /1
.7 /0
4
.1 1/0
/2
.2
.2
/2
10 GE
LSRB 4
FRR LSP
G 1.7
.2 /1
10
E1 . 1
4
.1 1/0
/2
.
/ 0 / 24
.1
10 GE
/1
Primary LSP GE1/0/2 LSRD

LSRA LSRC 10.1.3.1/24
GE1/0/0 GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24 10.1.3.2/24
1.1.1.1/32 2.2.2.2/32 4.4.4.4/32
1. Establish an LDP LSP between LSRA and LSRD.

2. Configure LDP Auto FRR on the ingress LSRA.
3. Configure a dynamic BFD session to monitor an LDP tunnel.
Data Preparation

l IP address of each interface on each node: values shown in Figure 2-23.

l LSR ID of each node: loopback addresses shown in Figure 2-23
l IS-IS process number (1), IS-IS level (level-2), and network entity name of each node:
– LSRA: 01.0000.0000.0003.00
– LSRC: 01.0000.0000.0004.00
– LSRB: 01.0000.0000.0005.00
– LSRD: 01.0000.0000.0006.00
l Name of a FEC list used to establish the BFD session: list1
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic IS-IS functions. For configuration details, see Configuration Files in this
section.
Step 3 Configure LDP LSPs.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
[LSRA] interface GigabitEthernet 1/0/0
[LSRA-GigabitEthernet1/0/0] mpls
[LSRA-GigabitEthernet1/0/0] mpls ldp
[LSRA-GigabitEthernet1/0/0] quit
[LSRA] interface GigabitEthernet 1/0/1
[LSRA-GigabitEthernet1/0/1] mpls ldp
# Repeat this step for LSRB, LSRC, and LSRD. For configuration details, see Configuration
Step 4 Configure LDP Auto FRR.
# Enable IS-IS Auto FRR on LSRA.

[LSRA] isis 1
[LSRA-isis-1] frr
[LSRA-isis-1-frr] loop-free-alternate level-2
[LSRA-isis-1-frr] quit
[LSRA-isis-1] quit
After IS-IS Auto FRR is enabled, LDP Auto FRR automatically takes effect. Then, run the
display mpls lsp command on LSRA to view information about the primary and FRR LSPs in
the LDP tunnel.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL -/-

2.2.2.2/32 NULL/3 -/GE1/0/0

**LDP FRR** /1025 /GE1/0/1
2.2.2.2/32 900001/3 -/GE1/0/0
**LDP FRR** /1025 /GE1/0/1
3.3.3.3/32 NULL/3 -/GE1/0/1
**LDP FRR** /900003 /GE1/0/0
3.3.3.3/32 900002/3 -/GE1/0/1
**LDP FRR** /900003 /GE1/0/0
4.4.4.4/32 NULL/900004 -/GE1/0/0
**LDP FRR** /1026 /GE1/0/1
4.4.4.4/32 900003/900004 -/GE1/0/0
**LDP FRR** /1026 /GE1/0/1
Step 5 Enable BFD globally.

# Configure LSRA.
[LSRA] bfd
[LSRA-bfd] quit
# Configure LSRD.
[LSRD] bfd
[LSRD-bfd] quit
Step 6 Enable the ingress LSRA and egress LSRD to dynamically establish a BFD session.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls bfd enable
[LSRA-mpls] quit
# Configure LSRD.
[LSRD] bfd
[LSRD-bfd] mpls-passive
[LSRD-bfd] quit
Step 7 Configure a policy for triggering dynamic BFD for LDP tunnel.
# On LSRA, create a FEC list and add a node with IP address 4.4.4.4 to the list so that the FEC
list is used to establish a BFD session only to monitor the LDP tunnel between LSRA and LSRD.
[LSRA] fec-list list1
[LSRA-fec-list-list1] fec-node 4.4.4.4
[LSRA-fec-list-list1] quit
# Specify the FEC list on LSRA so that LSRA uses it to establish a BFD session.
[LSRA] mpls
[LSRA-mpls] mpls bfd-trigger-tunnel fec-list list1
[LSRA-mpls] quit

# Run the display bfd session all verbose command on LSRA. The command output shows
that a dynamic BFD session is Up and has been bound to a tunnel with the type of
LDP_TUNNEL.
[LSRA] display bfd session all verbose
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
BFD Bind Type : LDP_TUNNEL


Bind Interface : GigabitEthernet1/0/0
Active Multi : 3 DSCP : -
Bind Application : LSPM | LDP | L2VPN | OAM_MANAGER
Session TX TmrID : - Session Detect TmrID : -
--------------------------------------------------------------------------------
# Run the display mpls bfd session command on LSRA to view information about the BFD
session that monitors an LDP tunnel.
[LSRA] display mpls bfd session
-------------------------------------------------------------------------------
BFD Information: LDP Tunnel
-------------------------------------------------------------------------------
4.4.4.4 8195 GE1/0/0 10.1.1.2 - Up
----End
Configuration Files
#
sysname LSRA
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
mpls bfd enable
mpls bfd-trigger-tunnel fec-list list1
#
fec-list list1
fec-node 4.4.4.4
#
mpls ldp
#
isis 1
is-level level-2
network-entity 01.0000.0000.0003.00
frr
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls

mpls ldp
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return

#
sysname LSRB
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
isis 1
is-level level-2
network-entity 01.0000.0000.0005.00
#
undo shutdown
ip address 10.1.7.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
isis 1
graceful-restart
is-level level-2
network-entity 01.0000.0000.0004.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls

mpls ldp
#
undo shutdown
ip address 10.1.7.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
bfd
mpls-passive
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
isis 1
is-level level-2
network-entity 01.0000.0000.0006.00
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return
2.20.18 Example for Configuring Manual LDP FRR

This section provides an example for configuring Manual LDP FRR. The procedure consists of
enabling MPLS and MPLS LDP on each device and interface and specifying the outbound
interface and the next hop of the specified backup LSP.
As shown in Figure 2-24, two LSPs are required from LSRA to LSRC. One is the primary LSP
along the path LSRA -> LSRC, and another is the bypass LSP along the path LSRA -> LSRB
-> LSRC. Manual LDP FRR is required on LSRA for local interface backup to reduce data loss.
Here, only LSRA must support Manual LDP FRR.

NOTE
In networking of Manual LDP FRR, the bypass LSP must be in liberal state. On an LSR that is enabled
with FRR, run the display ip routing-table ip-address verbose command. The command output shows
that the route state of the bypass LSP is "Inactive Adv."
Figure 2-24 Networking diagram for Manual LDP FRR

Loopback1
2.2.2.9/32
/0
S 1/0 /30 LSRB
2
PO 1.1.
.
10
10.2.1.1/30 10.2.1.2/30
Loopback1 /0
POS2/0/0 POS2/0/0
1.1.1.9/32 S 1/0 /30
1
PO 1.1.
.
10
LSRA P
10 OS2
.3. /0
1.1 /0
/30 PO
10 S1
.3. /0/ LSRC
1.2 0
/30 Primary LSP
Loopback1
3.3.3.9/32 Bypass LSP
1. Configure the IP address of the interfaces, set the loopback address as the LSR ID, and use
OSPF to advertise the network segments that the interfaces are connected to and the LSR
ID host route.
2. Enable MPLS and MPLS LDP globally on the LSRs.
3. Enable MPLS and MPLS LDP on the interfaces.
4. Specify the next hop address that is used by Manual LDP FRR to generate the backup LSP
on the protected interface.
Data Preparation
l IP address of the interfaces, OSPF process ID, and area ID

l Policy for triggering the establishment of LSPs
l Next hop address of the backup LSP

Procedure
Step 1 Configure the IP address for each interface.
Configure the IP address and mask for each interface, including each Loopback interface as
shown in Figure 2-24. For configuration details, see Configuration Files in this section.
Step 2 Configure OSPF to advertise the LSR ID host route and network segments to which the interfaces
are connected.
# Configure LSRA.
<LSRA> system-view
[LSRA] ospf 1
[LSRA-ospf-1] quit
# Configure LSRB.
<LSRB> system-view
[LSRB] ospf 1
[LSRB-ospf-1] quit
# Configure LSRC.
<LSRC> system-view
[LSRC] ospf 1
[LSRC-ospf-1] quit
LSRs learn the routes from each other.
<LSRA> display ip routing-table
------------------------------------------------------------------------------
2.2.2.9/32 OSPF 10 2 D 10.1.1.2 Pos1/0/0
3.3.3.9/32 OSPF 10 2 D 10.3.1.2 Pos2/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.2.1.0/30 OSPF 10 2 D 10.3.1.2 Pos2/0/0
OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.3.1.0/30 Direct 0 0 D 10.3.1.1 Pos2/0/0
10.3.1.2/32 Direct 0 0 D 10.3.1.2 Pos2/0/0

Step 3 Configure the MPLS and MPLS LDP functions on the nodes globally and on the interfaces to
forward the MPLS traffic over the network.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
After the configuration, LDP sessions are established between neighboring LSRs. Run the
display mpls ldp session command on each LSR. Status is displayed as Operational.

------------------------------------------------------------------------------
------------------------------------------------------------------------------

------------------------------------------------------------------------------
Step 4 Enable Manual LDP FRR on the POS 2/0/0 on LSRA and specify the next hop address for
generating the backup LSP.
# Configure LSRA.
[LSRA-Pos2/0/0] mpls ldp frr nexthop 10.1.1.2
Run the display mpls lsp command on LSRA. Manual LDP FRR is enabled on the LSP of
LSRC.
<LSRA> display mpls lsp
----------------------------------------------------------------------
----------------------------------------------------------------------
3.3.3.9/32 NULL/3 -/Pos2/0/0
**LDP FRR** /1025 /Pos1/0/0
3.3.3.9/32 1025/3 -/Pos2/0/0
**LDP FRR** /1025 /Pos1/0/0
2.2.2.9/32 NULL/3 -/Pos1/0/0
2.2.2.9/32 1024/3 -/Pos1/0/0
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.3.1.1 255.255.255.252
mpls
mpls ldp
mpls ldp frr nexthop 10.1.1.2
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.3.1.0 0.0.0.3

#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.3.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.2 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.3.1.0 0.0.0.3

network 10.2.1.0 0.0.0.3

#
Return
2.20.19 Example for Configuring Synchronization Between LDP

and IGP
This section provides an example for configuring LDP and IGP synchronization. The procedure
consists of enabling MPLS and MPLS LDP on each device and each interface and configuring
the interfaces of both ends of the link between the crossing node of active and standby links and
the LDP neighboring node.
As shown in Figure 2-25, two links are established between PE1 and PE2. The link PE1 -> P1
-> P2 -> PE2 is an active link, and the link PE1 -> P1 -> P3 -> PE2 is a standby link.
Configure synchronization between LDP and IGP on the P1 and P2 interfaces. P1 is the crossing
node of active and standby links and P2 is the LDP neighbor node of the active link. After the
active link recovers from the fault, configuring synchronization can shorten the time that it takes
to switch traffic from the standby link to the active link to within milliseconds.
Figure 2-25 Networking diagram for synchronization between LDP and IGP
Loopback1
2.2.2.9/32
0 P
1/0/ 30 10 OS2
S 2/ .2. /0/
Loopback1 PO 1.1. 1.1 0
/30 P Loopback1
0 .
1.1.1.9/32 1/0/ 010 P2
10 OS1 4.4.4.9/32
S 1/3 .2. /0/
PO 1.1. 1.2 0
. /30
10
PE1 P1 P /0 PE2
10 OS2 2/ 0 30
.3. /0 S .2/
1.1 /0 PO .4.1
/30 P P3 10
10 OS1 0
/0/ 30
.3. /0 2
S .1/
1.2 /0
/30 PO .4.1
10
Loopback1 Primary link
3.3.3.9/32
Bypass link

1. Establish LDP sessions between neighboring nodes and between P1 and PE2.
2. Configure LDP and IGP synchronization on the P1 and P2 interfaces. P1 is the crossing
node of active and standby links and P2 is the LDP neighboring node of the active link.
3. Configure the values of the hold-down, hold-max-cost, and delay timers on the P1 and P2
interfaces.
Data Preparation
l IP addresses of the interfaces, OSPF process number, and the area

l Values of the hold-down, hold-max-cost, and delay timers
Procedure
Step 1 Assign IP addresses for the node interfaces and the address of the loopback interface as the LSR
ID, and advertise routes using OSPF. For configuration details, see Configuration Files in this
section.
The link PE1 -> P1 -> P2 -> PE2 is an active link, and the link PE1 -> P1 -> P3 -> PE2 is a
standby link. The cost value of POS 2/0/0 on P1 is 1000.
After completing the configuration, run the display ip routing-table command on each node.
They have learned routes from each other. The outbound interface of the P1 route is POS 1/0/0.
The following example uses the command output on P1.

<P1> display ip routing-table
------------------------------------------------------------------------------
2.2.2.9/32 OSPF 10 2 D 10.1.1.2 Pos1/0/0
3.3.3.9/32 OSPF 10 4 D 10.1.1.2 Pos1/0/0
4.4.4.9/32 OSPF 10 3 D 10.1.1.2 Pos1/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.2.1.0/30 OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.3.1.0/30 Direct 0 0 D 10.3.1.1 Pos2/0/0
10.3.1.1/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
10.3.1.2/32 Direct 0 0 D 10.3.1.2 Pos2/0/0
10.4.1.0/30 OSPF 10 3 D 10.1.1.2 Pos1/0/0
Step 2 Enable MPLS and MPLS LDP globally and on all interfaces on the nodes.
# Configure P1.
<P1> system-view
[P1] mpls
[P1-mpls] quit
[P1] mpls ldp
[P1-mpls-ldp] quit
[P1-Pos1/0/0] mpls


[P1-Pos1/0/0] quit
[P1-Pos2/0/0] mpls
[P1-Pos2/0/0] quit
# Configure P2.
<P2> system-view
[P2] mpls
[P2-mpls] quit
[P2] mpls ldp
[P2-mpls-ldp] quit
[P2-Pos1/0/0] mpls
[P2-Pos1/0/0] quit
[P2-Pos2/0/0] mpls
[P2-Pos2/0/0] quit
# Configure P3.
<P3> system-view
[P3] mpls
[P3-mpls] quit
[P3] mpls ldp
[P3-mpls-ldp] quit
[P3-Pos1/0/0] mpls
[P3-Pos1/0/0] quit
[P3-Pos2/0/0] mpls
[P3-Pos2/0/0] quit
# Configure PE2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2-Pos1/0/0] mpls
[PE2-Pos1/0/0] quit
[PE2-Pos2/0/0] mpls
[PE2-Pos2/0/0] quit
After the configuration is complete, LDP sessions are set up between adjacent nodes. Run the
display mpls ldp session command on each node. The Status is Operational.

<P1> display mpls ldp session

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 3 Enable synchronization between LDP and IGP on the P1 and P2 interfaces.
# Configure P1.
<P1> system-view
[P1-Pos1/0/0] ospf ldp-sync
[P1-Pos1/0/0] quit
# Configure P2.
<P2> system-view
[P2-Pos1/0/0] ospf ldp-sync
[P2-Pos1/0/0] quit
Step 4 Set a value for the hold-down timer on the P1 and P2 interfaces.
# Configure P1.
<P1> system-view
[P1-Pos1/0/0] ospf timer ldp-sync hold-down 8
[P1-Pos1/0/0] quit
# Configure P2.
<P2> system-view
[P2-Pos1/0/0] ospf timer ldp-sync hold-down 8
[P2-Pos1/0/0] quit
Step 5 Set a value for the hold-max-cost timer on the P1 and P2 interfaces.
# Configure P1.
<P1> system-view
[P1-Pos1/0/0] ospf timer ldp-sync hold-max-cost 9
[P1-Pos1/0/0] quit
# Configure P2.
<P2> system-view
[P2-Pos1/0/0] ospf timer ldp-sync hold-max-cost 9
[P2-Pos1/0/0] quit
Step 6 Set a value for the delay timer on the P1 and P2 interfaces.
# Configure P1.
<P1> system-view
[P1-Pos1/0/0] mpls ldp timer igp-sync-delay 6
[P1-Pos1/0/0] quit
# Configure P2.
<P2> system-view


[P2-Pos1/0/0] mpls ldp timer igp-sync-delay 6
[P2-Pos1/0/0] quit

After completing the preceding configuration, run the display ospf ldp-sync interface command
on P1. The interface status is Sync-Achieved.
<P1> display ospf ldp-sync interface Pos 1/0/0
Interface Pos1/0/0
HoldDown Timer: 8 HoldMaxCost Timer: 9
LDP State: Up OSPF Sync State: Sync-Achieved
----End
Configuration Files
#
sysname P1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.252
ospf ldp-sync
ospf timer ldp-sync hold-down 8
ospf timer ldp-sync hold-max-cost 9
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.3.1.1 255.255.255.252
ospf cost 1000
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.3.1.0 0.0.0.3
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.9
mpls
#

mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.252
ospf ldp-sync
ospf timer ldp-sync hold-down 8
ospf timer ldp-sync hold-max-cost 9
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
return
#
sysname P3
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.3.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.4.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.3.1.0 0.0.0.3
network 10.4.1.0 0.0.0.3
#
return

#

sysname PE2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.4.1.2 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 10.2.1.0 0.0.0.3
network 10.4.1.0 0.0.0.3
#
return
2.20.20 Example for Configuring Synchronization Between LDP

and Static Routes
This section provides an example for configuring synchronization between LDP and static
routes. This synchronization function helps minimize MPLS traffic loss during traffic switchover
and switchback on an MPLS network where the primary link, backup link, and LSPs use static
routes.
On an MPLS network with primary and backup LSPs, LSRs establish LSPs based on static
routes. When the LDP session of the primary link becomes faulty (the fault is not caused by a
link failure) or the primary link recovers, LDP and static routes are unsynchronized, causing
MPLS traffic to be interrupted temporarily.
As shown in Figure 2-26, there are two static routes from LSRA to LSRD, which pass through
LSRB and LSRC respectively. LDP sessions are established based on the static routes. Link A
is the primary link, and Link B is the backup link. It is required that synchronization between
LDP and static routes be configured to ensure non-stop MPLS traffic forwarding when the LDP
session on Link A is disconnected or Link A recovers.

Figure 2-26 Networking diagram for configuring synchronization between LDP and static
routes
Loopback0
LSRB
PO
S2 Loopback0
Loopback0 /0 /0 /0/0
S1/0 S1/0
PO PO PO
LinkA S1
/0/
0
PO LinkB
S2/
0/0 /0 0/0 LSRD
LSRA
PO S2/0 OS2/
S1/ PO P
0/0
LSRC
Loopback0
Device Name Interface Name IP Address and Mask Device Name Interface Name IP Address and Mask
LSRA POS 1/0/0 10.1.1.1/30 LSRC POS 1/0/0 20.1.1.2/30
POS 2/0/0 20.1.1.1/30 POS 2/0/0 40.1.1.2/30
Loopback0 1.1.1.1/32 Loopback0 3.3.3.3/32
LSRB POS 1/0/0 10.1.1.2/30 LSRD POS 1/0/0 30.1.1.2/30
POS 2/0/0 30.1.1.1/30 POS 2/0/0 40.1.1.2/30
1. Configure static routes between LSRs to ensure network connectivity.

2. Enable MPLS and MPLS LDP in the system view and interface view.
3. Configure synchronization between LDP and static routes and verify the configuration.
Data Preparation
l IP addresses of all interfaces

l MPLS LSR IDs of LSRs
l Value of the Hold-down timer
Procedure

# Configure IP addresses for interfaces according to Figure 2-26. For configuration details, see
Step 2 Configure static routes on devices to ensure network connectivity.
# On LSRA, configure two static routes with different priorities to LSRD, and on LSRD,
configure two static routes with different priorities to LSRA.
# Configure LSRA.
[LSRA] ip route-static 2.2.2.2 32 pos1/0/0
[LSRA] ip route-static 4.4.4.4 32 pos1/0/0 preference 40
[LSRA] ip route-static 4.4.4.4 32 pos2/0/0 preference 60
# Configure LSRB.
[LSRB] ip route-static 1.1.1.1 32 pos1/0/0
[LSRB] ip route-static 4.4.4.4 32 pos2/0/0
# Configure LSRC.
[LSRC] ip route-static 1.1.1.1 32 pos1/0/0
[LSRC] ip route-static 4.4.4.4 32 pos2/0/0
# Configure LSRD.
[LSRD] ip route-static 2.2.2.2 32 pos1/0/0
[LSRD] ip route-static 1.1.1.1 32 pos1/0/0 preference 40
[LSRD] ip route-static 1.1.1.1 32 pos2/0/0 preference 60
# After completing the preceding configurations, run the display ip routing-table protocol
static command on each LSR. The command output shows the configured static routes. The
following example uses the command output on LSRA.
[LSRA] display ip routing-table protocol static
------------------------------------------------------------------------------
Public routing table : Static
Destinations : 5 Routes : 6 Configured Routes : 6
Static routing table status : <Active>

2.2.2.2/32 Static 60 0 D 10.1.1.1 Pos1/0/0

3.3.3.3/32 Static 60 0 D 20.1.1.1 Pos2/0/0
4.4.4.4/32 Static 40 0 D 10.1.1.1 Pos1/0/0
30.1.1.0/30 Static 60 0 D 10.1.1.1 Pos1/0/0
40.1.1.0/30 Static 60 0 D 20.1.1.1 Pos2/0/0
Static routing table status : <Inactive>

4.4.4.4/32 Static 60 0 20.1.1.1 Pos2/0/0
Step 3 Enable MPLS LDP and establish LDP LSPs on LSRs.

# Configure LSRA.


[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
[LSRA] interface pos1/0/0
The configurations for LSRB, LSRC, and LSRD are similar to the configuration for LSRA, and
are not described here. For configuration details, see Configuration Files in this section.
# Run the display mpls ldp session command on each LSR. The command output shows that
the status of LDP sessions is Operational. This indicates that LDP sessions have been
established. The following example uses the command output on LSRA.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Configure synchronization between LDP and static routes on LSRA and LSRD.
# Configure LSRA.
[LSRA] ip route-static 4.4.4.4 32 pos1/0/0 preference 40 ldp-sync
[LSRA-Pos1/0/0] static-route timer ldp-sync hold-down 20
# Configure LSRD.
[LSRD] ip route-static 1.1.1.1 32 pos1/0/0 preference 40 ldp-sync
[LSRD] interface pos1/0/0
[LSRD-Pos1/0/0] static-route timer ldp-sync hold-down 20
# On LSRA, check the status of the outbound interface of the static route configured with
synchronization between LDP and static routes.
[LSRA] display static-route ldp-sync
Total number of routes enable Ldp-Sync: 1
-----------------------------------------------------
Interface Pos1/0/0
Enable ldp-sync static routes number: 1
Static-route ldp-sync holddown timer: 20s
Sync state: Normal
Dest = 4.4.4.4, Mask = 32, NextHop = 10.1.1.1.
-----------------------------------------------------

The preceding display shows that the status of synchronization between LDP and static routes
is Normal. This indicates that synchronization between LDP and static routes has been
configured.
l If the LDP session of the primary link (Link A) is disconnected, traffic is immediately
switched to the backup link (Link B) to synchronize LDP and static routes. This ensures non-
stop traffic forwarding.
l After the primary link recovers, the static route with the next-hop address 10.1.1.1 is not
preferred immediately. Instead, the static route becomes active only after the LDP session
of the primary link has been established and the Hold-down timer expires (the timeout period
of the timer is 20 seconds). This synchronizes static routes and LDP, ensuring non-stop MPLS
traffic forwarding.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
static-route timer ldp-sync hold-down 20
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface loopback0
ip address 1.1.1.1 255.255.255.255
#
ip route-static 2.2.2.2 255.255.255.255 Pos1/0/0
ip route-static 4.4.4.4 255.255.255.255 Pos1/0/0 preference 40 ldp-sync
ip route-static 4.4.4.4 255.255.255.255 Pos2/0/0 preference 60
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.252

mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 30.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface loopback0
ip address 2.2.2.2 255.255.255.255
#
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 40.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface loopback0
ip address 3.3.3.3 255.255.255.255
#
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 30.1.1.2 255.255.255.252
static-route timer ldp-sync hold-down 20
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 40.1.1.2 255.255.255.252
mpls
mpls ldp
#

interface loopback0
ip address 4.4.4.4 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 Pos1/0/0 preference 40 ldp-sync
ip route-static 1.1.1.1 255.255.255.255 Pos2/0/0 preference 60
#
return
2.20.21 Example for Configuring LDP GR

This section provides an example for configuring LDP GR. The procedure consists of enabling
MPLS and MPLS LDP on each device and each interface and enabling LDP GR on both GR
Restarter and its neighbor.
As shown in Figure 2-27, LSRA, LSRB, and LSRC are LSRs with dual main control boards.
The three LSRs belong to the same OSPF area and are interconnected using OSPF. All of them
support the GR mechanism.
After establishing the LDP sessions between them, LSRA, LSRB, and LSRC start to establish
the LDP GR sessions. When the main control board of LSRB fails and is switched, the LDP GR
mechanism is used in synchronization with neighbor LSRs.
Figure 2-27 Networking diagram for LDP GR

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS1/0/0 POS1/0/0 POS2/0/0 POS1/0/0
10.1.1.1/30 10.1.1.2/30 10.2.1.1/30 10.2.1.2/30
LSRA LSRB LSRC
1. Configure IP address of each interface on the LSRs and the Loopback address used as the
LSR ID, and configure OSPF to advertise the network segments that the interfaces are
connected to and the LSR ID host route.
2. Configure the OSPF GR function on each LSR.
3. Enable MPLS and MPLS LDP on each LSR globally.
4. Enable MPLS and MPLS LDP on each interface.
5. Configure parameters during LDP session negotiation on LSRB.
6. Enable the GR function of MPLS LDP on each LSR.
7. Configure the GR session of MPLS LDP and neighboring parameters on LSRB.

Data Preparation
l IP address of each interface, OSPF process ID, and OSPF area ID

l OSPF GR interval
l Time of the LDP Reconnect timer (300 seconds by default)
l Time of the LDP Neighbor-liveness timer (600 seconds by default)
l Time of the LDP Recovery timer (300 seconds by default)
Procedure
Step 1 Assign the IP address to each interface. The configuration details are not provided here.
Step 2 Configure OSPF to advertise the network segments to which the interfaces are connected and
the LSR ID host route. For configuration details, see Configuration Files in this section.
Step 3 Configure the OSPF GR function.
# Configure LSRA.
<LSRA> system-view
[LSRA] ospf 1
[LSRA-ospf-1] opaque-capability enable
[LSRA-ospf-1] graceful-restart
[LSRA-ospf-1] quit
# Configure LSRB.
<LSRB> system-view
[LSRB] ospf 1
[LSRB-ospf-1] opaque-capability enable
[LSRB-ospf-1] graceful-restart
[LSRB-ospf-1] quit
# Configure LSRC.
<LSRC> system-view
[LSRC] ospf 1
[LSRC-ospf-1] opaque-capability enable
[LSRC-ospf-1] graceful-restart
[LSRC-ospf-1] quit
Step 4 Configure the MPLS and MPLS LDP functions on each node globally.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
# Configure LSRC.


[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
Step 5 Configure the MPLS and MPLS LDP functions on each interface.
# Configure LSRA.
# Configure LSRB.
# Configure LSRC.
After the preceding configuration is complete, the local LDP sessions are established between
LSRA and LSRB, and between LSRB and LSRC.
Run the display mpls ldp session command on each LSR to view the established LDP session.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 6 Configure the LDP GR function.
# Configure LSRA.
[LSRA] mpls ldp
[LSRA-mpls-ldp] graceful-restart
Warning: All the related sessions will be deleted if the operation is performed
!Continue? (y/n)y
# Configure LSRB.
[LSRB] mpls ldp
[LSRB-mpls-ldp] graceful-restart
!Continue? (y/n)y

# Configure LSRC.
[LSRC] mpls ldp
[LSRC-mpls-ldp] graceful-restart
!Continue? (y/n)y
Step 7 Configure the parameters of LDP GR on the GR Restarter.
# Configure LSRB.
[LSRB] mpls ldp
[LSRB-mpls-ldp] graceful-restart timer reconnect 300
!Continue? (y/n)y
[LSRB-mpls-ldp] graceful-restart timer neighbor-liveness 600
!Continue? (y/n)y
[LSRB-mpls-ldp] graceful-restart timer recovery 300
!Continue? (y/n)y
# After completing the configuration, run the display mpls ldp session verbose command on
the LSR. On is displayed in the Session FT Flag field.

[LSRA]display mpls ldp session verbose
------------------------------------------------------------------------------
TCP Connection : 1.1.1.9 <- 2.2.2.9
Session FT Flag : On MD5 Flag : Off
Reconnect Timer : 300 Sec Recovery Timer : 300 Sec
Keychain Name : ---

Capability:
Capability-Announcement : Off

10.1.1.2 10.2.1.1 2.2.2.9
------------------------------------------------------------------------------
Alternatively, run the display mpls ldp peer verbose command on the LSR. On is displayed
in the Peer FT Flag field.


[LSRA] display mpls ldp peer verbose
------------------------------------------------------------------------------
Peer LDP ID : 2.2.2.9:0
Peer Max PDU Length : 4096 Peer Transport Address : 2.2.2.9
Peer Loop Detection : Off Peer Path Vector Limit : ----
Peer FT Flag : On Peer Keepalive Timer : 45 Sec
Recovery Timer : 300 Sec Reconnect Timer : 300 Sec
Peer Type : Local
Peer Label Advertisement Mode : Downstream Unsolicited

Peer Discovery Source : Pos1/0/0
Peer Deletion Status : No
Capability-Announcement : Off
Peer mLDP P2MP Capability : On
Peer mLDP MP2MP Capability : Off
Peer mLDP MBB Capability : On
------------------------------------------------------------------------------
----End
Configuration Files
l LSA configuration file
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
graceful-restart
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
opaque-capability enable
graceful-restart
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
graceful-restart
#
interface Pos1/0/0
link-protocol ppp

undo shutdown
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
graceful-restart
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
graceful-restart
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.2.1.2 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
graceful-restart
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.2.1.0 0.0.0.3
#
Return
2.20.22 Example for Configuring LDP over GRE
As shown in Figure 2-28, LSRA, LSRB, and LSRC belong to a VPN backbone network and
run IS-IS. LSRA and LSRC run GRE, implementing interconnection between PC1 and PC2.
For L2VPN service transmission, an LDP LSP needs to be set up between LSRA and LSRC
over the GRE tunnel. This is called LDP over GRE.

Figure 2-28 Networking diagram for configuring LDP over GRE

Loopback0
2.2.2.9/32
POS1/0/0 POS2/0/0
20.1.1.2/24 30.1.1.1/24
LSRB
Loopback1 Loopback1
11.11.11.1132 33.33.33.33/32
POS1/0/0 POS1/0/0
Loopback0 20.1.1.1/24 30.1.1.2/24 Loopback0
1.1.1.9/32 Tunnel 3.3.3.9/32
Tunnel1/0/1 Tunnel1/0/1 LSRC
LSRA
40.1.1.1/24 40.1.1.2/24
PC1 PC2
1. Assign IP addresses to interfaces on each node, configure the loopback addresses, and
configure an IGP to advertise routes.
2. Configure basic MPLS functions.
3. Configure a tunnel interface on LSRA and LSRC and specify the source address and
destination address of the tunnel.
4. Enable MPLS LDP on tunnel interfaces.
NOTE
In configuration, the address of loopback 0 is used as an LSR ID for each LSR. That is, LDP uses loopback
0 to establish a session. GRE tunnel interfaces need to be configured with IP addresses. The addresses of
loopback 1 on the LSRs on both ends of a GRE tunnel are used as a source address and a destination address
respectively. The source address, destination address, and addresses of physical interfaces of a GRE tunnel
are advertised by using an IGP. The addresses of loopback 0 interfaces and tunnel interface addresses are
advertised by using another IGP or static routes (the outbound interfaces of the static routes must be tunnel
interfaces).
Data Preparation
l Source address and destination address of a GRE tunnel, and IP addresses of tunnel
interfaces

Procedure
Assign an IP address to each interface according to Figure 2-28, including addresses of loopback
0 and loopback 1 on LSRA and LSRC. For configuration details, see Configuration Files in
this section.
Step 2 Configure the IS-IS protocol to advertise routes.
# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] quit
Step 3 Configure the basic MPLS functions and MPLS LDP functions on LSRA and LSRC.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRC.
<LSRC> system-view
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
Step 4 Configure a tunnel interface on LSRA and LSRC.
# Configure LSRA.
[LSRA] interface loopback1
[LSRA-LoopBack1] target-board 1

[LSRA-LoopBack1] binding tunnel gre

[LSRA] interface tunnel 1/0/1
[LSRA-Tunnel1/0/1] tunnel-protocol gre
[LSRA-Tunnel1/0/1] ip address 40.1.1.1 255.255.255.0
[LSRA-Tunnel1/0/1] source loopback1
[LSRA-Tunnel1/0/1] destination 33.33.33.33
[LSRA-Tunnel1/0/1] quit
# Configure LSRC.
[LSRC] interface loopback1
[LSRC-LoopBack1] target-board 1
[LSRC-LoopBack1] binding tunnel gre
[LSRC] interface tunnel 1/0/1
[LSRC-Tunnel1/0/1] tunnel-protocol gre
[LSRC-Tunnel1/0/1] ip address 40.1.1.2 255.255.255.0
[LSRC-Tunnel1/0/1] source loopback1
[LSRC-Tunnel1/0/1] destination 11.11.11.11
[LSRC-Tunnel1/0/1] quit
Step 5 Configure the OSPF protocol to advertise routes.
# Configure LSRA.
[LSRA] ospf 1
[LSRA-ospf-1] quit
# Configure LSRC.
[LSRC] ospf 1
[LSRC-ospf-1] quit
Step 6 Configure the MPLS LDP capability on each tunnel interface.
# Configure LSRA.
[LSRA-Tunnel1/0/1] mpls
[LSRA-Tunnel1/0/1] mpls ldp
# Configure LSRC.
[LSRC-Tunnel1/0/1] mpls
[LSRC-Tunnel1/0/1] mpls ldp
# After completing the configuration, run the display mpls lsp command on LSRA. You can
view that the LDP LSP with the outbound interface being Tunnel 1/0/1 is set up between LSRA
and LSRC.
[LSRA] display mpls lsp include 3.3.3.9 32

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
3.3.3.9/32 NULL/3 -/Tun1/0/1
3.3.3.9/32 1028/3 -/Tun1/0/1
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0001.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
target-board 1
binding tunnel gre
isis enable 1
#
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source LoopBack1
destination 33.33.33.33
mpls
mpls ldp
#
ospf 1
area 0.0.0.0
network 40.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return

#
sysname LSRB
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
#
interface Pos1/0/0

link-protocol ppp
undo shutdown
ip address 20.1.1.2 255.255.255.0
isis enable 1
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 30.1.1.1 255.255.255.0
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
#
interface LoopBack1
ip address 33.33.33.33 255.255.255.255
target-board 1
binding tunnel gre
isis enable 1
#
ip address 40.1.1.2 255.255.255.0
tunnel-protocol gre
source LoopBack1
destination 11.11.11.11
mpls
mpls ldp
#
ospf 1
area 0.0.0.0
network 40.1.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return

Configuration Guide - MPLS 3 MPLS TE Configuration
3 MPLS TE Configuration
About This Chapter
MPLS TE tunnels transmit MPLS L2VPN (VLL and VPLS) services and MPLS L3VPN
services, provide high security, and guarantee reliable QoS for VPN services.
3.1 Introduction
Integrating the Multiprotocol Label Switching (MPLS) technology with the traffic engineering
(TE) technology, MPLS TE addresses the problem of congestions caused by load imbalance.
3.2 Configuring Static CR-LSP

This section describes how to configure a static CR-LSP. The configuration of a static CR-LSP
is simple and label allocation is performed manually, not by using a signaling protocol to
exchange control packets, which consumes a few resources.
3.3 Configuring a Static Bidirectional Co-routed CR-LSP

A static bidirectional co-routed label switched path (LSP) is composed of two static constraint-
based routed (CR) LSPs in opposite directions. Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) supports MPLS forwarding in both directions along such an LSP.
3.4 Configuring the Statistics Function for a Static Bidirectional Co-routed CR-LSP
The statistics function for a static bidirectional co-routed CR-LSP enables a device to collect
statistics about traffic on nodes of a static bidirectional co-routed CR-LSP. the statistics helps
locate faulty nodes.
3.5 Configuring an RSVP-TE Tunnel

A Resource Reservation Protocol Traffic Engineering (RSVP-TE) tunnel is a type of
Multiprotocol Label Switching (MPLS) TE tunnel. Configuring an RSVP-TE tunnel is a
prerequisite for configuring advanced MPLS TE features and applications.
3.6 Configuring Dynamic Bandwidth Reservation

This section describes how to configure dynamic bandwidth reservation on an MPLS TE
interface. This configuration enables the MPLS TE interface dynamically reserve bandwidth for
an MPLS TE tunnel to account for the fact that physical bandwidth is variable.
3.7 Configuring a Tunnel Protection Group

A configured protection tunnel can be bound to a working tunnel to form a tunnel protection
group. If the working tunnel fails, traffic switches to the protection tunnel. The tunnel protection
group helps improve tunnel reliability.
3.8 Referencing the CR-LSP Attribute Template to Set Up a CR-LSP

By configuring a CR-LSP attribute template to set up CR-LSPs, you can simply the
configurations and make the configurations of CR-LSPs more flexible.
3.9 Configuring an Associated Bidirectional Dynamic LSP

The associated bidirectional dynamic LSP can transmit bidirectional traffic, addressing the
problem of network congestions and protecting bidirectional traffic against interruption by
switching traffic to the backup tunnel in the case of a tunnel failure.
3.10 Adjusting RSVP Signaling Parameters

This section describes how to adjust RSVP signaling parameters. RSVP-TE provides various
parameters, which meet the requirements for reliability, network resources, and advanced MPLS
features.
3.11 Configuring RSVP Authentication

This section describes how to configure RSVP authentication. RSVP authentication prevents
unauthorized nodes from setting up RSVP neighbor relationships with the local node and
prevents spoofing of forged packets. By default, RSVP authentication is not configured.
Configuring RSVP authentication is recommended to ensure system security.
3.12 Adjusting the Path of CR-LSP

This section describes how to adjust the path of a CR-LSP. You can configure and adjust the
method of calculating CR-LSPs.
3.13 Adjusting the Establishment of MPLS TE Tunnels

This section describes how to adjust the establishment of an MPLS TE tunnel. You can configure
multiple attributes of the MPLS TE tunnel to adjust parameters during the establishment of the
MPLS TE tunnel.
3.14 Importing Traffic to an MPLS TE Tunnel

This section describes how to importing traffic to an MPLS TE tunnel. An MPLS TE tunnel
does not automatically import traffic. A method must be used to import traffic to the MPLS TE
tunnel before traffic can travel along an MPLS TE tunnel.
3.15 Adjusting Flooding Threshold of Bandwidth Change

By adjusting the flooding threshold of the bandwidth change, you can suppress the frequency
of TEDB update and flooding, which minimizes network resource consumption.
3.16 Configuring Automatic Adjustment of the Tunnel Bandwidth

By being enabled with the automatic bandwidth adjustment, the system can adjust the bandwidth
of a tunnel automatically according to the actual traffic volume.
3.17 Configuring the Limit Rate of MPLS TE Traffic

This section describes how to configure the limit rate of MPLS TE traffic to limit TE tunnel
traffic within the bandwidth range that is actually configured.
3.18 Configuring DS-TE Tunnel

By integrating traditional TE tunnels with DiffServ models, DS-TE can provide QoS according
to specific service types.
3.19 Configuring TE Manual FRR

TE manual FRR is a local protection mechanism used on MPLS TE networks. TE manual FRR
switches traffic on a primary MPLS TE tunnel to a manually configured bypass tunnel if a link
or node on the primary tunnel fails.
3.20 Configuring MPLS TE Auto FRR

This section describes how to configure MPLS TE Auto FRR. MPLS TE Auto FRR is a local
protection technique and is used to protect a CR-LSP against link faults and node faults. MPLS
TE Auto FRR does not need to be configured manually.
3.21 Configuring CR-LSP Backup

CR-LSP backup is configured to provide end-to-end protection for traffic on CR-LSPs.
3.22 Configuring Synchronization of the Bypass Tunnel and the Backup CR-LSP
This section describes that after the primary CR-LSP is faulty, the system starts the TE FRR
bypass tunnel and tries to restore the primary CR-LSP the same time it sets up a backup CR-
LSP.
3.23 Configuring RSVP GR

This section describes how to configure RSVP-TE GR so that devices along an RSVP-TE tunnel
can retain RSVP sessions during a master/slave switchover.
3.24 Configuring Static BFD for CR-LSP

This section describes how to configure a static BFD session to detect link faults in static CR-
LSPs or RSVP CR-LSPs.
3.25 Configuring Static BFD for TE

This section describes how to configure a static BFD session to detect faults in a TE tunnel.
3.26 Configuring Dynamic BFD for CR-LSP

This section describes how to configure a dynamic BFD session to detect link faults in a static
CR-LSP or an RSVP CR-LSP.
3.27 Configuring Dynamic BFD for RSVP

This section describes how to configure a dynamic BFD session to detect faults in links between
RSVP neighbors.
3.28 Configuring an Automatic P2MP TE Tunnel

An automatic P2MP TE tunnel must be configured before it can be automatically established to
transmit multicast services when the multicast services arrive in an IP/MPLS backbone network.
3.29 Maintaining MPLS TE

This section describes how to clear operation information about MPLS TE, and reset the
automatic bandwidth adjustment.

The following sections provide several examples for configuring MPLS TE.Each configuration
example consists of the networking requirements, configuration precautions, configuration
roadmap, configuration procedures, and configuration files.

3.1 Introduction
Integrating the Multiprotocol Label Switching (MPLS) technology with the traffic engineering
(TE) technology, MPLS TE addresses the problem of congestions caused by load imbalance.
3.1.1 MPLS TE Overview

MPLS TE reserves resources for tunnels to be set up and allows traffic to be load-balanced
among nodes without passing through congested nodes.
TE
Network resource insufficiency and load imbalance result in congestions on a network, which
affects the performance of a backbone network. TE prevents network congestions and optimizes
the network resources.
TE dynamically monitors traffic and load on network elements and adjusts parameters relevant
to traffic control, routing, and resource constraints in real time. This optimizes the utilization of
network resources and prevents imbalance-triggered congestions.
MPLS TE
As a combination of MPLS and TE, MPLS TE load-balances traffic on a network by setting up
an LSP over a specified path to reserve resources for traffic that will not pass through congested
nodes.
An LSP with a higher priority preempts bandwidth resources of LSPs with lower priorities to
provide sufficient bandwidth for services on the LSP with a higher priority in the case of
bandwidth insufficiency.
If a link fault or a node fault occurs, MPLS TE uses path backup and fast reroute (FRR) to ensure
uninterrupted traffic.
Administrators use MPLS TE to create LSPs to eliminate network congestions and use special
offline utility to analyze traffic if the number of LSPs increases to a certain extent.
3.1.2 MPLS TE Features Supported by the NE80E/40E

The NE80E/40E supports various MPLS Traffic Engineering (TE) features, such as static MPLS
TE tunnels, static bidirectional constraint-based routed label switched paths (CR-LSPs),
Resource Reservation Protocol Traffic Engineering (RSVP-TE) tunnels, DiffServ-aware Traffic
Engineering (DS-TE), P2MP TE and MPLS TE reliability.
NOTE
This section describes MPLS TE features that the NE80E/40E supports. For more information about MPLS
TE features, see the chapter "MPLS TE" in the HUAWEI NetEngine80E/40E Router Feature Description
- MPLS.

Static MPLS TE Tunnels

Static MPLS TE tunnels are established using labels that are allocated manually but not by a
signaling protocol to send control packets. Using static MPLS TE tunnels is recommended for
a stable network with low-performance devices.
Static MPLS TE tunnels have the highest priorities, which means that their bandwidth cannot
be preempted. Static MPLS TE tunnels will not preempt bandwidth of other types of LSPs.
Static Bidirectional CR-LSPs

Static bidirectional CR-LSPs are used on MPLS Transport Profile (MPLS-TP) networks,
improving maintainability. Static bidirectional CR-LSPs are established using labels that are
allocated manually but not allocated by a signaling protocol to send control packets. They apply
to simple, stable, and small-scale networks and consume a few resources. Statically allocating
labels disables the static bidirectional CR-LSPs from adapting to changeable networks. If the
network topology changes, an administrator has to change the paths for the static bidirectional
CR-LSPs.
Traffic Statistics for a Static Bidirectional Co-routed CR-LSP

No mechanisms can locate the faulty node that discards traffic on a static bidirectional co-routed
CR-LSP that takes effect. To help locate the faulty node, the statistics function for a static
bidirectional co-routed CR-LSP can be configured. With the CR-LSP traffic statistics function,
the CR-LSP manager checks the difference between the rate at which the upstream node sends
packets and the rate at which the downstream node receives packets. The CR-LSP manager can
then locate the node on which traffic is dropped on the CR-LSP based on the difference.
RSVP-TE Tunnels
RSVP-TE signaling is used to set up RSVP-TE tunnels or adapt RSVP-TE tunnels to changing
network conditions.
The NE80E/40E supports the following RSVP-TE features:
l Collecting and advertising TE link information

RSVP-TE uses an extended Interior Gateway Protocol (IGP) to collect and advertise TE
link information and set up a traffic engineering database (TEDB). The extended IGP can
be either Open Shortest Path First (OSPF) TE or Intermediate System-to-Intermediate
System (IS-IS) TE. An extended IGP floods link information at a specified interval. Link
information flooding also occurs when a link goes Up or Down, link attributes change, or
the reservable bandwidth on a link changes to a certain extent. The flooding threshold can
be set as needed.
l Path calculation
On the NE80E/40E, the path of a TE tunnel is calculated using Constrained Shortest Path
First (CSPF). If multiple reachable paths share the same weight, one path is selected based
on the configured tie-breaking policy.
In addition to the reservable bandwidth and administrative group attribute for links on a
tunnel, the following attributes can be set for the tunnel:
– Tunnel bandwidth

– Affinity property
– Explicit path
– Maximum hop limit
– Shared risk link group (SRLG)
l Establishing an RSVP-TE tunnel
NE80E/40Es can be configured to record information about routes and labels during the
establishment of an RSVP-TE tunnel. If resources are insufficient, the NE80E/40Es
preempt bandwidth of other RSVP-TE tunnels with lower setup and holding priorities for
an RSVP-TE tunnel to be established.
If the NE80E/40E fails to establish an RSVP-TE tunnel, it attempts to reestablish the RSVP-
TE tunnel periodically.
l Signaling mechanism
The NE80E/40E reserves resources using RSVP-TE in either fixed filter (FF) or shared-
explicit (SE) style. The NE80E/40E supports RSVP extensions, such as confirmation and
retransmission of RSVP messages, summary refresh (Srefresh), and the Hello mechanism.
The RSVP extensions help the NE80E/40E relieve network loads and improve network
reliability. In addition, the NE80E/40E supports RSVP authentication, improving network
security.
l Traffic forwarding
Virtual Private Network (VPN) traffic can be directed to TE tunnels using configured
policy-based routing. Non-VPN traffic can be directed to TE tunnels using the configured
static routes, policy-based routing, IGP shortcut, or forwarding adjacency.
l Optimizing and adjusting tunnels
Established TE tunnels can be adjusted and optimized using the following features:
– Tunnel reoptimization: If the NE80E/40E calculates a better path for a CR-LSP, it
establishes a CR-LSP over the new path. After the new CR-LSP has been established,
the NE80E/40E switches traffic to the new CR-LSP. Tunnel reoptimization is performed
in either automatic or manual mode. Automatic tunnel reoptimization means that the
NE80E/40E periodically resends a request for calculating a better path for a CR-LSP.
Manual tunnel reoptimization means that path calculation for a CR-LSP is manually
triggered.
– Automatic bandwidth adjustment: When the service volume changes, the bandwidth
for the CR-LSP that carries services is automatically adjusted.
DS-TE
MPLS TE tunnels apply to one of the following VPN scenarios:
l Each TE tunnel transmits various types of non-VPN services such as video, voice, and data.
l A single TE tunnel transmits various types of services in a VPN.
l A single TE tunnel transmits various types of services in multiple VPNs.
l A single TE tunnel transmits various types of VPN and non-VPN services.
Traditional MPLS TE tunnels (non-standard DS-TE tunnels) cannot transmit services based on
service types in compliance with the quality of service (QoS). For example, when a TE tunnel
carries both voice and video flows, video flows may have more duplicate frames than voice

flows. Therefore, video flows require higher drop precedence than the voice flows. The same
drop precedence, however, is used for voice and video flows on MPLS TE tunnels.
DiffServ-aware Traffic Engineering (DS-TE) maps various service types of traffic (such as
voice, video, and data traffic) to LSPs. This allows traffic to travel through a path that meets
traffic engineering constraints for the specific service type. DS-TE improves network resource
usage.
DS-TE implemented on the NE80E/40E supports the Non-IETF mode and the IETF mode. The
two modes have the following specifications:
l The Non-IETF (non-standard) mode supports two CTs (CT0 and CT1), eight priorities
(0-7), and two bandwidth constraint models (Russian Dolls Model [RDM] and Maximum
Allocation Model [MAM]).
The CT refers to the class type of a specific service flow. The priority refers to the LSP
preemption priority.
l The IETF (standard) mode supports eight CTs (CT0 to CT7), eight priorities (0-7), and
three bandwidth constraint models (RDM, MAM, and extended MAM).
DS-TE supports TE Fast Reroute (FRR), hot standby, protection group switchover, and CT-
based traffic statistics collection.
Reliability
CR-LSP backup provides an end-to-end protection mechanism. CR-LSP backup is usually used
together with another rapid detection or protection mechanism to implement rapid traffic
switchovers and prevent traffic loss. The following feature combinations are supported:
l CR-LSP backup and TE FRR

TE FRR is a local protection mechanism. It protects traffic on a specified link or node along
a CR-LSP and allows rapid traffic switchovers if a fault occurs. CR-LSP backup allows
end-to-end path protection and protects traffic on an entire CR-LSP. CR-LSP backup is
classified into hot standby and ordinary backup, each of which can be used together with
TE FRR:
– CR-LSP hot standby and TE FRR: FRR can rapidly detect a link fault and switch traffic
to a bypass tunnel. After signaling carries information about a link fault to the ingress,
the ingress switches traffic to a backup CR-LSP.
– CR-LSP ordinary backup and TE FRR: FRR can rapidly detect a link fault and switch
traffic to a bypass tunnel. If the primary and bypass TE FRR tunnels both fail, traffic is
switched to a backup CR-LSP.
l CR-LSP backup and BFD
TE FRR detects faults in a specific direct link or node, whereas bidirectional fault detection
(BFD) rapidly detects faults in an entire CR-LSP. BFD is applicable only to hot-standby
CR-LSPs, not other types of CR-LSPs. If a BFD session detects a tunnel fault, it rapidly
switches traffic to a hot-standby CR-LSP or switches traffic back to a primary CR-LSP.
The NE80E/40E supports the following reliability features for TE tunnels:

l TE FRR
TE FRR is a local protection mechanism. It is used on networks requiring high reliability.
If a link or node fails, FRR rapidly switches traffic to a bypass tunnel, minimizing the
impact on traffic. TE FRR is performed in manual or automatic mode.

NOTE
FRR requires reserved bandwidth for a bypass tunnel to be established before a fault occurs. If
available bandwidth is insufficient, FRR protects only important nodes or links.
l CR-LSP backup
Backup CR-LSPs are established on networks requiring high reliability to provide end-to-
end protection, ensuring network reliability. If a primary CR-LSP fails, traffic rapidly
switches to a backup CR-LSP, ensuring uninterrupted traffic transmission.
Hot standby and ordinary backup are supported. If both primary and backup CR-LSPs fail,
best-effort paths can be established, improving reliability. Backup CR-LSPs and best-effort
paths are established in different ways:
– Hot-standby backup: The NE80E/40E establishes a primary CR-LSP and a backup CR-
LSP using separate paths simultaneously.
– Ordinary backup: The NE80E/40E establishes a backup CR-LSP over an explicit path
only if a primary CR-LSP fails.
– Best-effort path: The NE80E/40E establishes a best-effort path over available paths if
the primary and backup CR-LSP both fail.
l BFD
BFD can detect CR-LSP faults in milliseconds. BFD can be used if no hardware detection
mechanism is available and rapid detection is required, which helps speed up fault
detection.
BFD configured on the NE80E/40E can monitor hot-standby CR-LSPs and tunnel
protection groups.
l RSVP GR
RSVP graceful restart (GR) is a state recovery mechanism for RSVP-TE. If the control
plane fails or a manual master/slave switchover is performed, RSVP GR ensures
uninterrupted data transmission on the forwarding plane and restores the proper status for
RSVP-TE LSPs. FRR can be performed during the GR process.
l Tunnel protection group
A tunnel protection group provides an end-to-end protection mechanism for MPLS TE
tunnels. Its applications are not limited to RSVP-TE networking. In a tunnel protection
group, a tunnel protects one or more tunnels.
NOTE
For more information about how to configure a tunnel protection group, see the chapter "MPLS
OAM" in HUAWEI NetEngine80E/40E Router Configuration Guide - MPLS.
l NSR
Non-stop routing (NSR) ensures uninterrupted traffic transmission and proper connections
on the control plane if a software or hardware fault occurs. This prevents the control plane
on a neighbor device from detecting the fault or being affected.
P2MP TE
Point-to-multipoint (P2MP) TE provides a solution to multicast transmission on IP/MPLS
networks. P2MP TE has combined advantages of high IP multicast transmission efficiency and
MPLS TE E2E quality of service (QoS) guarantee. P2MP TE establishes a tree-shaped tunnel
that originates from a root and terminates at leaf nodes and directs multicast traffic to the P2MP
TE tunnel. P2MP TE helps simplify multicast service deployment on IP/MPLS networks because

service configurations, such as multicast protocols or L2VPN parameters, are not performed.
P2MP TE is integrated with advantages of TE, QoS, and reliability on MPLS networks.
3.2 Configuring Static CR-LSP

This section describes how to configure a static CR-LSP. The configuration of a static CR-LSP
is simple and label allocation is performed manually, not by using a signaling protocol to
exchange control packets, which consumes a few resources.

Before configuring a static CR-LSP, familiarize yourself with the usage scenario, complete the
pre-configuration tasks, and data required for the configuration.
Usage Scenario
The configuration of a static CR-LSP is a simple process. Labels are manually allocated, and no
signaling protocol or exchange of control packets are needed. The setup of a static CR-LSP
consumes a few resources. In addition, neither IGP TE nor CSPF needs to be configured for the
static CR-LSP.
The static CR-LSP cannot dynamically adapt to a changing network. Therefore, its application
is very limited.
NOTE
After a static CR-LSP is bound to a tunnel interface, the static CR-LSP takes effect without an IP route
configured.
Before configuring a static CR-LSP, complete the following tasks:
l Configure an LSR ID on each LSR.

l Enable basic MPLS functions on each LSR globally and on each interface.
Data Preparation
To configure a static CR-LSP, you need the following data.
No. Data
1 Nodes through which the static CR-LSP passes
2 Values for outgoing labels on LSRs along the static CR-LSP
3 Number, tunnel ID, and destination address of the tunnel interface
4 Destination address of the static CR-LSP
5 Next hop address or outbound interface on the ingress
6 Inbound interface, next hop address, or outbound interface on each transit

No. Data
7 Incoming interface on the egress
8 Bandwidth of the ingress and transit nodes
NOTE
l The value of the outgoing label on each node is the value of the incoming label of its next node.
l The destination address of a static CR-LSP is the destination address of the TE tunnel interface.
3.2.2 Enabling MPLS TE

This section describes how to enable MPLS TE. Before you set up a static CR-LSP, enable
MPLS TE.
Context
Perform the following steps on each node along a static CR-LSP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te
MPLS TE is enabled on the node globally.
Before you enable MPLS TE on each interface, enable MPLS TE globally in the MPLS view.
Step 4 Run:
quit
Step 5 Run:
Step 6 Run:
mpls
The MPLS is enabled on the interface.
Step 7 Run:

mpls te
The MPLS TE is enabled on the interface.
NOTE
When the MPLS TE is disabled in the interface view, all CR-LSPs on the current interface go Down.
When the MPLS TE is disabled in the MPLS view, the MPLS TE on each interface is disabled, and all
CR-LSPs are torn down.
----End
3.2.3 (Optional) Configuring Link Bandwidth

This section describes how to configure link bandwidth. By configuring the link bandwidth, you
can constrain the bandwidth of a CR-LSP.
Context
NOTE
To constrain the bandwidth of CR-LSPs, the procedure is mandatory. In addition, the mpls te lsp-tp
outbound command must be run on the corresponding tunnel interface.
By default, the maximum reservable bandwidth on the link is 0 bit/s. If the maximum reservable bandwidth
is not configured, when the bandwidth of the CR-LSP is constrained, the bandwidth of the CR-LSP is more
than the maximum reservable bandwidth. Therefore, the CR-LSP cannot be set up.
Perform the following steps on each node along the CR-LSP:
Procedure
Step 1 Run:
system-view

Step 2 Run:
The MPLS-TE-enabled interface view is displayed.

Step 3 Run:
mpls te bandwidth max-reservable-bandwidth bw-value
The maximum available bandwidth of the link is configured.

Step 4 Run:
mpls te bandwidth { bc0 bc0-bw-value | bc1 bc1-bw-value }*
The BC bandwidth of the link is configured.
NOTE
l The maximum reservable bandwidth of a link cannot be higher than the actual bandwidth of the link.
A maximum of 80% of the actual bandwidth of the link is recommended for the maximum reservable
bandwidth of the link.
l Neither the BC0 bandwidth nor the BC1 bandwidth can be higher than the maximum reservable
----End

3.2.4 Configuring the MPLS TE Tunnel Interface

This section describes how to configure the MPLS TE tunnel interface. You must create a tunnel
interface before setting up an MPLS TE tunnel.
Context
Perform the following steps on the ingress of a static CR-LSP:
Procedure
Step 1 Run:
system-view

Step 2 Run:
The tunnel interface is created, and the tunnel interface view is displayed.
Step 3 To configure the IP address of the tunnel interface, select one of the following commands.
l To specify the IP address of the tunnel interface, run:
ip address ip-address { mask | mask-length } [ sub ]
The secondary IP address of the tunnel interface can be configured only after the primary IP
address is configured.
l To borrow an IP address from another interface, run:
ip address unnumbered interface interface-type interface-number
An MPLS TE tunnel can be established even if the tunnel interface is assigned no IP address.
But the tunnel interface must obtain an IP address before forwarding traffic. An MPLS TE tunnel
is unidirectional; therefore, its peer address is irrelevant to traffic forwarding. A tunnel interface
does not need to be assigned an IP address but uses the ingress LSR ID as its IP address.
NOTE
Because the type of packet forwarded by the MPLS TE tunnel is MPLS, the commands, such as ip urpf
commands, related to IP packet forwarding configured on this interface are invalid.
Step 4 Run:
MPLS TE is configured to be the tunnel protocol.

Step 5 Run:
destination ip-address
The destination address of the tunnel is configured, which is usually the LSR ID of the egress
node.
Different types of tunnels need different destination addresses. When the tunnel protocol is
changed to MPLS TE from other different protocols, the configured destination is deleted
automatically and needs to be reconfigured.
Step 6 Run:
mpls te tunnel-id tunnel-id

The tunnel ID is configured.
Step 7 Run:
mpls te signal-protocol cr-static
The signal protocol of the tunnel is configured to be static CR-LSP.
Step 8 Run:
mpls te commit
NOTE
If MPLS TE parameters on a tunnel interface are modified, run the mpls te commit command to make the
configuration take effect.
----End
3.2.5 Configuring the Ingress of the Static CR-LSP

This section describes how to configure the ingress of a static CR-LSP. Before you set up a static
CR-LSP, specify the ingress of the CR-LSP.
Context
Perform the following steps on the ingress of a static CR-LSP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
static-cr-lsp ingress { tunnel-interface tunnel interface-number | tunnel-name }
destination destination-address { nexthop next-hop-address | outgoing-interface
interface-type interface-number } * out-label out-label [ bandwidth [ ct0 | ct1 |
ct2 | ct3 | ct4 | ct5 | ct6 | ct7 ] bandwidth | pir pir-value | cbs cbs-value |
pbs pbs-value | mtu mtu-value ] * [ description description-text ]
The ingress of a static CR-LSP is configured.
The configuration notes are as follows:
l The tunnel interface-number and tunnel-name specify the MPLS TE tunnel that uses the
specified static CR-LSP.
l The next-hop IP address and outbound interface name are determined by an ingress-to-egress
route. For detailed configurations of the next-hop IP address and outbound interface, see
"Configuring a Static Route" in HUAWEI NetEngine80E/40E Router Configuration Guide
- IP Routing.
l The default class type is ct0, and the default bandwidth is 0 kbit/s. The bandwidth used by
a tunnel cannot exceed the maximum link reservable bandwidth.
l pir pir-value specifies the peak information rate (PIR) for reservable bandwidth for the static
CR-LSP. The specified PIR must be greater than or equal to the specified bandwidth.

l cbs cbs-value specifies the committed burst size (CBS) of the static CR-LSP. pbs pbs-
value specifies the peak burst size (PBS) of the static CR-LSP.
l mtu mtu-value specifies the maximum transmission unite (MTU) for the static CR-LSP. By
default, the outbound interface's MTU is used as the MTU of a static CR-LSP.
NOTE
The specified MTU value only takes effect on a local node. If MTU values on nodes on an MPLS
protection ring are different, the smallest value takes effect.
l description description-text specifies the description of the static CR-LSP, which facilitates
management.
l All parameters, except tunnel-interface and tunnel-name, can be dynamically updated.
----End
3.2.6 Configuring the Transit of the Static CR-LSP

This section describes how to configure the transit nodes of a static CR-LSP. Before you set up
a static CR-LSP, specify the transit nodes of the CR-LSP. This procedure is optional because
the CR-LSP may have no transit node.
Context
If the static CR-LSP only has the ingress and egress, configuring a transit node is not needed. If
the static CR-LSP has one or more transit nodes, perform the following steps on each transit
node:
Procedure
Step 1 Run:
system-view

Step 2 Run:
static-cr-lsp transit lsp-name incoming-interface interface-type interface-number
in-label in-label { nexthop next-hop-address | outgoing-interface interface-type
interface-number } * out-label out-label [ bandwidth [ ct0 | ct1 | ct2 | ct3 | ct4
| ct5 | ct6 | ct7 ] bandwidth | pir pir-value | cbs cbs-value | pbs pbs-value |
mtu mtu-value ] * [ description text ]
A transit node of a static CR-LSP is configured.

l On the transit and egress nodes, the lsp-name parameter must be unique locally.
l The default class type is ct0, and the default bandwidth is 0 kbit/s. The bandwidth used by
a tunnel cannot exceed the maximum link reservable bandwidth.
l pir pir-value specifies the peak information rate (PIR) for reservable bandwidth for a static
CR-LSP. The specified PIR must be greater than or equal to the specified bandwidth.
l cbs cbs-value specifies the committed burst size (CBS) of the static CR-LSP. pbs pbs-
value specifies the peak burst size (PBS) of the static CR-LSP.
l mtu mtu-value specifies the maximum transmission unite (MTU) for the static CR-LSP. By
default, the outbound interface's MTU is used as the MTU of a static CR-LSP.

NOTE
The specified MTU value only takes effect on a local node. If MTU values on nodes on an MPLS
protection ring are different, the smallest value takes effect.
l description text specifies the description of the static CR-LSP, which facilitates
management.
l All parameters, except lsp-name, can be dynamically updated.
----End
3.2.7 Configuring the Egress of the Static CR-LSP

This section describes how to configure the egress of a static CR-LSP. Before you set up a static
CR-LSP, specify the egress of the CR-LSP.
Context
Perform the following steps on the egress of a static CR-LSP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
static-cr-lsp egress lsp-name incoming-interface interface-type interface-number
in-label in-label [ lsrid ingress-lsr-id tunnel-id tunnel-id ] [ description
description-text ]
The egress of a static CR-LSP is configured.
l description description-text specifies the description of the static CR-LSP, which facilitates
management.
l ingress-lsr-id specifies the LSR ID of the ingress on the static CR-LSP. tunnel-id specifies
the tunnel ID of an MPLS TE tunnel that uses the static CR-LSP.
NOTE
Before you use MPLS OAM to monitor the Trail Termination Source Identifier (TTSI) of a static CR-
LSP, configure lsrid ingress-lsr-id and tunnel-id tunnel-id in the static-lsp egress command. The LSR
ID and tunnel ID uniquely specify a static CR-LSP. If either LSR ID or tunnel ID is different from the
effective value on the ingress, MPLS OAM considers that a TTSI error occurs and prompts a user with
a configuration error message.
l All parameters, except lsp-name, can be dynamically updated.
----End

After the configuration of a static CR-LSP, you can view the static CR-LSP status.

Prerequisites
The static CR-LSP has been configured.
Procedure
l Run the display mpls static-cr-lsp [ lsp-name ] [ { include | exclude } ip-address mask-
length ] [ verbose ] command to check information about the static CR-LSP.
l Run the display mpls te tunnel [ destination ip-address ] [ lsp-id ingress-lsr-id session-
id local-lsp-id | lsr-role { all | egress | ingress | remote | transit } ] [ name tunnel-name ]
[ { incoming-interface | interface | outgoing-interface } interface-type interface-
number ] [ te-class0 | te-class1 | te-class2 | te-class3 | te-class4 | te-class5 | te-class6 | te-
class7 ] [ verbose ] command to check information about the tunnel.
l Run the display mpls te tunnel statistics or display mpls lsp statistics command to check
the tunnel statistics.
l Run the display mpls te tunnel-interface [ tunnel interface-number ] command to check
information about the tunnel interface on the ingress.
----End
Example
If the configurations are successful, run the preceding commands to view the following
information:
l Information about the static CR-LSP name, the incoming and outgoing labels, and the
incoming and outgoing interfaces. The status of CR-LSP is Up.
l Statistics about the tunnel status on the LSR.
l Detailed information about the tunnel interface, including the tunnel name, state
description, and attributes. The tunnel attributes include the LSP ID, ingress, egress, and
signaling protocol.
3.3 Configuring a Static Bidirectional Co-routed CR-LSP

A static bidirectional co-routed label switched path (LSP) is composed of two static constraint-
based routed (CR) LSPs in opposite directions. Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) supports MPLS forwarding in both directions along such an LSP.

Before configuring a static bidirectional co-routed LSP, familiarize yourself with the usage
Usage Scenario
A static bidirectional co-routed LSP is applicable to MPLS Transport Profile (TP) networks,
improving network maintainability.
A static CR-LSP is easy to configure: labels are manually allocated, and no signaling protocol
is used to exchange control packets. The setup of a static CR-LSP consumes only a few resources,

and you do not need to configure IGP TE or CSPF for the static CR-LSP. However, static CR-
LSP application is quite limited. A static CR-LSP cannot dynamically adapt to network changes,
and it uses the same label range (16 to 1023) as a common static LSP.
Before configuring a static bidirectional co-routed LSP, complete the following tasks:
l Configure unicast static routes or an IGP to implement the reachability between LSRs.
l Configure an LSR ID for each LSR.
l Enable MPLS globally and on interfaces on all LSRs.
Data Preparation
To configure a static bidirectional co-routed LSP, you need the following data.
No. Data
1 Physical link supporting MPLS TE forwarding
2 Maximum reservable bandwidth and BC bandwidth for each link
3 Tunnel interface IP address and tunnel ID
4 Next-hop address or outbound interface on the ingress
5 Inbound interface and next-hop address or outbound interface on each transit node
6 Inbound interface on the egress
NOTE
l The value of the outgoing label on each node is the value of the incoming label on its next hop.
l The destination address of a static bidirectional co-routed LSP is the destination address specified
on the tunnel interface.
3.3.2 Enabling MPLS TE

This section describes how to enable MPLS TE. Before you set up a static CR-LSP, enable
MPLS TE.
Context
Perform the following steps on each node along a static CR-LSP:
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls
Step 3 Run:
mpls te
MPLS TE is enabled on the node globally.
Before you enable MPLS TE on each interface, enable MPLS TE globally in the MPLS view.
Step 4 Run:
quit
Step 5 Run:
Step 6 Run:
mpls
The MPLS is enabled on the interface.
Step 7 Run:
mpls te
The MPLS TE is enabled on the interface.
NOTE
When the MPLS TE is disabled in the interface view, all CR-LSPs on the current interface go Down.
When the MPLS TE is disabled in the MPLS view, the MPLS TE on each interface is disabled, and all
CR-LSPs are torn down.
----End

Context
NOTE

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

Step 4 Run:
NOTE
----End
3.4 Configuring the Statistics Function for a Static

Bidirectional Co-routed CR-LSP
The statistics function for a static bidirectional co-routed CR-LSP enables a device to collect
statistics about traffic on nodes of a static bidirectional co-routed CR-LSP. the statistics helps
locate faulty nodes.
Usage Scenario
No mechanisms can locate the faulty node that discards traffic on a static bidirectional co-routed
CR-LSP that takes effect. To help locate the faulty node, the statistics function for a static
bidirectional co-routed CR-LSP can be configured. With the CR-LSP traffic statistics function,
the CR-LSP manager checks the difference between the rate at which the upstream node sends
packets and the rate at which the downstream node receives packets. The CR-LSP manager can
then locate the node on which traffic is dropped on the CR-LSP based on the difference.
l If the difference is slight, no traffic is dropped.
l If the difference is significant, traffic is dropped.
Before configuring the statistics function for a static bidirectional co-routed CR-LSP, configure
a static bidirectional co-routed CR-LSP.

Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls traffic-statistics
The MPLS traffic statistics view is displayed.
Step 3 Run:
bidirectional static-cr-lsp name
Statistics about packets transmitted on a static bidirectional co-routed CR-LSP are collected.
With the CR-LSP traffic statistics function, the device records packet statistics on the static
bidirectional co-routed CR-LSP. The statistics include the number of sent and received bytes
and packets. To delete existing statistics, run the reset mpls traffic-statistics command. To re-
collect statistics, run the display mpls traffic-statistics command. These two commands can
be run simultaneously to collect statistics about the sent and received traffic on CR-LSPs within
a specified period. The statistics help locate nodes that discard packets.

interval
The sampling interval is set.
The default sampling interval is 300 seconds.
l If CR-LSP performance is good, increase the sampling interval, which helps reduce system
resource consumption during the sampling process.
l If CR-LSP performance deteriorates, decrease the sampling interval, which helps effectively
locate the node that discards traffic.
Setting the same sampling interval on all nodes along a CR-LSP is recommended, which helps
obtain comparable statistics on upstream and downstream nodes on the CR-LSP.
----End

After configuring the statistics function for a static bidirectional co-routed CR-LSP, you can run
the following command to check the configurations.
l Run the display mpls traffic-statistics [ protocol static-cr name lsp-name ] command to
check CR-LSP traffic statistics.
Run the display mpls traffic-statistics protocol static-cr name lsp1 command to view statistics
about traffic transmitted on a static bidirectional co-routed CR-LSP named lsp1.
<HUAWEI> display mpls traffic-statistics protocol static-cr name lsp1
-------------------------------------------------------------------------------
Traffic Statistics Information: BISTATIC CR-LSP
-------------------------------------------------------------------------------
lsp1 traffic-statistics:
Forward:
Last 300 seconds input rate 16 bytes/sec, 0 packets/sec

Realtime 30 seconds input rate 16 bytes/sec, 0 packets/sec

Last 300 seconds output rate 17 bytes/sec, 0 packets/sec
Realtime 30 seconds output rate 17 bytes/sec, 0 packets/sec
Input: 310031 bytes, 6802 Packets
Ouput: 352027 bytes, 6843 Packets
Backward:
Last 300 seconds input rate 16 bytes/sec, 0 packets/sec
Realtime 30 seconds input rate 16 bytes/sec, 0 packets/sec
Last 300 seconds output rate 17 bytes/sec, 0 packets/sec
Realtime 30 seconds output rate 17 bytes/sec, 0 packets/sec
Input: 310031 bytes, 6802 Packets
Ouput: 352027 bytes, 6843 Packets
3.5 Configuring an RSVP-TE Tunnel

A Resource Reservation Protocol Traffic Engineering (RSVP-TE) tunnel is a type of
Multiprotocol Label Switching (MPLS) TE tunnel. Configuring an RSVP-TE tunnel is a
prerequisite for configuring advanced MPLS TE features and applications.

Before configuring an RSVP-TE tunnel, familiarize yourself with the usage scenario, complete
Applicable Environment
RSVP-TE is a dynamic signaling protocol that provides the same resource reservation function
as the RSVP protocol. Unlike RSVP, RSVP-TE supports extended functions for label
distribution and management, explicit paths, and dynamic TE tunnel attribute adjustment.
RSVP-TE also supports advanced features such as TE fast reroute (FRR) and constraint-based
routed label switched path (CR-LSP) backup, which can rapidly trigger a traffic switchover if a
fault occurs. Using RSVP-TE tunnels is recommended for transmitting MPLS TE services.
Before configuring an RSVP-TE tunnel, complete the following tasks:
l Configure an IGP to implement reachable routes between nodes.

l Configure an LSR ID for each node.
l Enable MPLS globally on each node.
l Enable MPLS on each interface of each node.
Data Preparation
To configure an RSVP-TE tunnel, you need the following data.
No. Data
1 LSR ID of each node on an RSVP-TE tunnel
2 (Optional) IP address and name of each interface connected to each physical MPLS
TE link

No. Data
3 Maximum available bandwidth and maximum reservable bandwidth
4 Open Shortest Path First (OSPF) area ID or Intermediate System-to-Intermediate

System (IS-IS) level
5 Tunnel ID
6 Tunnel destination address
7 Tunnel constraints such as explicit path and bandwidth
8 (Optional) RSVP resource reservation style (shared explicit [SE] style by default)
3.5.2 Enabling MPLS TE and RSVP-TE

MPLS TE and RSVP-TE must be enabled on each node and its interfaces before an RSVP-TE
tunnel is established.
Context
MPLS TE and RSVP-TE must be enabled on each node and its interfaces. After this, an RSVP-
TE tunnel can be established and settings such as link bandwidth attributes and Constraint
Shortest Path First (CSPF) parameters can be configured.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls te
MPLS TE is enabled globally.

Step 4 Run:
mpls rsvp-te
RSVP-TE is enabled on the node.

Step 5 Run:
quit

Step 6 Run:

The MPLS TE interface view is displayed.
Step 7 Run:
mpls te
MPLS TE is enabled on the interface.
Step 8 Run:
mpls rsvp-te
RSVP-TE is enabled on the interface.
NOTE
l If MPLS TE is disabled in the MPLS view, MPLS TE will also be disabled on interfaces and all the
CR-LSPs configured on the interfaces will go Down.
l If MPLS TE is disabled in the interface view, all the CR-LSPs configured on the interface will go
Down.
l If RSVP-TE is disabled in the MPLS view, RSVP-TE will also be disabled on interfaces on the node.
----End

Context
NOTE
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:

NOTE
----End
3.5.4 Configuring OSPF TE

OSPF TE sends Opaque Type 10 link state advertisements (LSAs) to form TEDBs, and TEDB
information is used by CSPF to calculate paths.
Context
Nodes on an MPLS network use OSPF TE to exchange TE link attributes such as bandwidth
and colors to generate TEDBs. TEDB information is used by CSPF to calculate paths for RSVP-
TE tunnels. OSPF TE extends OSPF functions and supports Opaque Type 10 LSAs to carry TE
link attributes.
OSPF areas do not support TE by default. The OSPF Opaque capability must be enabled to
support OSPF TE, and a node can generate Opaque Type 10 LSAs only if at least one OSPF
neighbor is in the Full state.
NOTE
If OSPF TE is disabled, no Opaque Type 10 LSA is generated or exchanged by nodes to generate TEDBs.
On an OSPF TE-incapable network, CR-LSPs are established using OSPF routes but not CSPF calculation
results.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
The OSPF view is displayed.
Step 3 Run:
The OSPF Opaque capability is enabled.

advertise mpls-lsr-id
The node is enabled to advertise an MPLS LSR ID to multiple OSPF areas.

NOTE
This step is performed only on an area border router (ABR) connected to multiple OSPF areas.
Step 5 Run:
area area-id
The OSPF area view is displayed.
Step 6 Run:
mpls-te enable [ standard-complying ]
MPLS TE is enabled in the OSPF area.
----End
3.5.5 Configuring IS-IS TE

IS-IS TE sends extended type-length-values (TLVs) to form a TEDB and TEDB information is
used by CSPF to calculate paths.
Context
IS-IS TE is an IS-IS extension used on an MPLS TE network. IS-IS TE defines a new TLV in
Link State Packets (LSPs) and IS-IS TE-enabled nodes send these LSPs to flood and synchronize
TE link information. IS-IS TE extracts TE link information from LSPs and then transmits the
TE link information to the CSPF module for calculating tunnel paths.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
The IS-IS view is displayed.
Step 3 Run:
cost-style { compatible [ relax-spf-limit ] | wide | wide-compatible }
The IS-IS wide metric function is enabled.
IS-IS TE uses sub-TLVs of the IS reachability TLV (type 22) to carry TE link information. The
IS-IS wide metric must be configured to support the IS reachability TLV. The IS-IS wide metric
supports the wide, compatible, and wide-compatible metric types. By default, IS-IS sends and
receives LSPs with narrow metric values.
Step 4 Run:
traffic-eng [ level-1 | level-2 | level-1-2 ]
IS-IS TE is enabled.
By default, TE is not enabled for IS-IS processes.

If no IS-IS level is specified, the node is a Level-1-2 device that can generate two TEDBs for
communicating with Level-1 and Level-2 devices.

te-set-subtlv { bw-constraint value | lo-multiplier value | unreserve-bw-sub-pool
value }*
The type and value of a sub-TLV carrying DS-TE parameters are specified.
By default, the value of the Unreserve-BW-Sub-Pool sub-TLV is 251; the value of the BW-
constraint sub-TLV is 252; the value of the Local Overbooking Multiplier (LOM) sub-TLV is
253.
----End
3.5.6 (Optional) Configuring an MPLS TE Explicit Path

An explicit path can be configured on the ingress so that a CR-LSP is established over the explicit
path, efficiently using network resources.
Context
An explicit path refers to a vector path on which a series of nodes are arranged in configuration
sequence. The IP address of an interface on the egress is usually used as the destination address
of the explicit path. Links or nodes can be specified for an explicit path so that a CR-LSP can
be established over the specified path, facilitating resource allocation and efficiently controlling
CR-LSP establishment.
Two adjacent nodes are connected in either of the following modes on an explicit path:
l Strict: A hop is directly connected to its next hop.

l Loose: Other nodes may exist between a hop and its next hop.
The strict and loose modes are used either separately or together.
NOTE
TE tunnels are classified as intra-area tunnels and inter-area tunnels. In this situation, areas indicate OSPF and
IS-IS areas, but not an autonomous system (AS) running the Border Gateway Protocol (BGP). OSPF areas are
divided based on different area IDs while IS-IS areas are divided based on different levels.
l Intra-area tunnel: is a TE tunnel in a single OSPF or IS-IS area. An intra-area tunnel can be established over
a strict or loose explicit path.
l Inter-area tunnel: is a TE tunnel traversing multiple OSPF or IS-IS areas. An explicit path must be used to
establish an inter-area TE tunnel and an ABR or an Autonomous System Boundary Router (ASBR) must
be included in the explicit path.
The explicit path in use can be updated.
Procedure
Step 1 Run:
system-view
Step 2 Run:
explicit-path path-name

An explicit path is created and the explicit path view is displayed.
Step 3 Perform the following steps as needed:

l Run:
next hop ip-address [ exclude | include [ [ loose | strict ] | [ incoming |
outgoing ] ] * ]
A next-hop IP address is specified for the explicit path.

Either of the following parameters can be configured:
– incoming: sets the ip-address to the IP address of an inbound interface of a next-hop
node.
– outgoing: sets the ip-address to the IP address of an outbound interface of a next-hop
node.
Repeat this command for each node you want to add.
l Run:
add hop ip-address1 [ exclude | include [ [ loose | strict ] | [ incoming |
outgoing ] ] * ] { after | before } ip-address2
A node is added to the explicit path.

– incoming: sets the ip-address1 to the IP address of an inbound interface of a new node.
– outgoing: sets the ip-address1 to the IP address of an outbound interface of a new node.
Repeat this command for each node you want to add.
l Run:
modify hop ip-address1 ip-address2 [ exclude | include [ [ loose | strict ] |
[ incoming | outgoing ] ] * ]
The address of a node is changed to allow another specified node to be used by the explicit
path.
– incoming: sets the ip-address2 to the IP address of an inbound interface of the modified
node.
– outgoing: sets the ip-address2 to the IP address of an outbound interface of the modified
node.
l Run:
delete hop ip-address
A node is deleted from the explicit path.

l Run:
list hop [ ip-address ]
Information about nodes on the explicit path is displayed.

NOTE
By default, the include strict parameters are configured, meaning that a hop and its next hop must be directly
connected. An explicit path can be configured to pass through a specified node or not to pass through a specified
node.
include means that a CR-LSP must pass through a specified node; exclude means that a CR-LSP cannot pass
through a specified node.
----End

3.5.7 Configuring an MPLS TE Tunnel Interface

A tunnel interface must be created on the ingress so that a tunnel can be established and forward
data packets.
Context
A tunnel interface supports the following functions:
l Establishes a tunnel. Tunnel constraints, bandwidth attributes, and advanced attributes such
as TE FRR and tunnel re-optimization can be configured on the tunnel interface to establish
the tunnel.
l Manages a tunnel. Tunnel attributes can be modified on the tunnel interface to manage the
tunnel.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface tunneltunnel-number
A tunnel interface is created and the tunnel interface view is displayed.
NOTICE
Setting the value of tunnel-number to the slot ID of the main control board is recommended.
The slot ID of the main control board is usually 0. If the tunnel interface is configured on an
interface board, the tunnel interface and the established tunnel will be deleted if the interface
board resets.
NOTE
If the shutdown command is run on the tunnel interface, all tunnels established on the tunnel interface will
be deleted.
Step 3 Run either of the following commands to assign an IP address to the tunnel interface:
l To configure an IP address for the tunnel interface, run:
The primary IP address must be configured before the secondary IP address is configured.
l To configure the tunnel interface to borrow an IP address of another interface, run:
An MPLS TE tunnel can be established even if the tunnel interface is assigned no IP address.
But the tunnel interface must obtain an IP address before forwarding traffic. An MPLS TE tunnel
is unidirectional; therefore, its peer address is irrelevant to traffic forwarding. A tunnel interface
does not need to be assigned an IP address but uses the ingress LSR ID as its IP address.

NOTE
Because MPLS TE tunnels forward MPLS packets, not IP packets, IP forwarding-related commands run
on the tunnel interface are invalid.
Step 4 Run:
MPLS TE is configured as a tunnel protocol.

Step 5 Run:
A tunnel destination address is configured, which is usually the LSR ID of the egress.
Various types of tunnels require specific destination addresses. If a tunnel protocol is changed
from another protocol to MPLS TE, a configured destination address is deleted automatically
and a new destination address needs to be configured.
Step 6 Run:
A tunnel ID is set.
Step 7 Run:
mpls te signal-protocol rsvp-te
RSVP-TE is used as a signaling protocol.

mpls te signalled tunnel-name
The tunnel name is specified.

mpls te cspf disable
Do not perform the constraint shortest path first (CSPF) calculation when a TE tunnel is being
set up.
NOTE
The command is applicable to the inter-AS VPN-OptionC scenario. In other scenarios, do not run the
command.
Step 10 Run:
mpls te commit
NOTE
The mpls te commit command must be run to make configurations take effect each time MPLS TE
parameters are changed on a tunnel interface.
----End
3.5.8 (Optional) Configuring Tunnel Constraints

Constraints such as bandwidth and explicit path attributes can be configured on the ingress to
accurately and flexibly establish an RSVP-TE tunnel.

Context
CSPF uses constraints to calculate paths for tunnels. Constraints can be configured to help CSPF
correctly calculate paths for RSVP-TE tunnels.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface tunnel tunnel-number
Step 3 Run:
mpls te bandwidth [ ct0 ct0-bw-value | ct1 ct1-bw-value ] [ flow-queue flow-
queue ]
The bandwidth is configured for the tunnel.
The bandwidth used by the tunnel cannot be greater than the maximum reservable link
bandwidth.
The default bandwidth class type (CT) is CT0.
Ignore this step if only an explicit path is required.
Step 4 Run:
mpls te path explicit-path path-name
An explicit path is configured for the tunnel.
Ignore this step if only the bandwidth needs to be specified.
Step 5 Run:
mpls te commit
----End
3.5.9 (Optional) Configuring an RSVP Resource Reservation Style

If multiple CR-LSPs pass through the same node, the ingress nodes can be configured with an
RSVP resource reservation style to allow the CR-LSPs to share reserved resources or use
separate reserved resources on the overlapping node.
Context
A reservation style is used by an RSVP node to reserve resources after receiving resource
reservation requests from upstream nodes. The HUAWEI NetEngine80E/40E supports the
following reservation styles:

l Fixed filter (FF): reserves resources for each ingress node. The sum of reserved resources
on a node is equal to the sum of reserved resources for all ingress nodes.
l SE: explicitly reserves resources for one or more specified ingress nodes. The ingress nodes
share reserved resources.
The SE style is used for tunnels established using the make-before-break mechanism, whereas
the FF style is seldom used.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls te resv-style { ff | se }
A resource reservation style is configured.
NOTE
The default resource reservation style is SE.
Step 4 Run:
mpls te commit
----End
3.5.10 Configuring CSPF

To calculate a tunnel path meeting specified constraints, CSPF should be configured on the
ingress.
Context
CSPF extends the shortest path first (SPF) algorithm and is able to calculate the shortest path
meeting MPLS TE requirements. CSPF calculates paths using the following information:
l Link state information sent by IGP-TE and saved in TEDBs
l Network resource attributes, such as the maximum available bandwidth, maximum
reservable bandwidth, and affinity property, sent by IGP-TE and saved in TEDBs
l Configured constraints such as explicit paths

NOTE
l An RSVP-TE tunnel can be established on a CSPF-disabled ingress. However, to allow a path to meet
tunnel constraints, you are advised to enable CSPF on the ingress before establishing the RSVP-TE
tunnel.
l Enabling CSPF on all transit nodes is recommended.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te cspf
CSPF is enabled on a node.
CSPF is disabled by default.

mpls te cspf preferred-igp { isis [ process-id [ level-1 | level-2 ] ] | ospf
[ process-id [ area { area-id-1 | area-id-2 } ] ] }
A preferred IGP is specified.
The default value is OSPF.
----End

After configuring the RSVP-TE tunnel, you can view statistics about the RSVP-TE tunnel and
the tunnel status.
Prerequisites
The RSVP-TE tunnel has been configured.
Procedure
l Run the display mpls te link-administration bandwidth-allocation [ interface interface-
type interface-number ] command to check information about the allocated link bandwidth.
l Run the display ospf [ process-id ] mpls-te [ area area-id ] [ self-originated ] command
to check information about OSPF TE.
l Run one of the following commands to check IS-IS TE information:
– display isis traffic-eng advertisements
– display isis traffic-eng link
– display isis traffic-eng network

– display isis traffic-eng statistics

– display isis traffic-eng sub-tlvs
l Run the display explicit-path [ [ ] path-name ] [ | verbose ] command to check configured
explicit paths.
l Run the display mpls te cspf destination ip-address [ affinity properties [ mask mask-
value ] | bandwidth { ct0 ct0-bandwidth | ct1 ct1-bandwidth | ct2 ct2-bandwidth | ct3 ct3-
bandwidth | ct4 ct4-bandwidth | ct5 ct5-bandwidth | ct6 ct6-bandwidth | ct7 ct7-
bandwidth }* | explicit-path path-name | hop-limit hop-limit-number | metric-type
{ igp | te } | priority setup-priority | srlg-strict exclude-path-name | tie-breaking
{ random | most-fill | least-fill } ]* [ hot-standby [ explicit-path path-name | overlap-
path | affinity properties [ mask mask-value ] | hop-limit hop-limit-number | srlg
{ preferred | strict } ] * ] command to check information about a path that is calculated
using CSPF based on specified conditions.
l Run the display mpls te cspf tedb { all | area { area-id | area-id-ip } | interface ip-
address | network-lsa | node [ router-id ] | srlg srlg-number | overload-node } command
to check information about TEDBs that can meet specified conditions and be used by CSPF
to calculate paths.
l Run the display mpls rsvp-te command to check RSVP information.
l Run the display mpls rsvp-te established [ interface interface-type interface-number
peer-ip-address ] command to check information about the established RSVP-TE CR-
LSPs.
l Run the display mpls rsvp-te peer [ interface interface-type interface-number ] command
to check RSVP neighbor parameters.
l Run the display mpls rsvp-te reservation [ interface interface-type interface-number
peer-ip-address ] command to check information about RSVP resource reservation.
l Run the display mpls rsvp-te request [ interface interface-type interface-number peer-
ip-address ] command to check information about RSVP resource reservation requests sent
by RSVP senders.
l Run the display mpls rsvp-te sender [ interface interface-type interface-number peer-ip-
address ] command to check information about RSVP senders.
l Run the display mpls rsvp-te statistics { global | interface [ interface-type interface-
number ] } command to check RSVP-TE statistics.
l Run the display mpls te link-administration admission-control [ interface interface-
type interface-number | stale-interface interface-index ] command to check the tunnels set
up on the local node.
id local-lsp-id ] [ lsr-role { all | egress | ingress | remote | transit } ] [ name tunnel-
name ] [ { incoming-interface | interface | outgoing-interface } interface-type interface-
number ] command to check tunnel information.
l Run the display mpls te tunnel statistics or display mpls lsp statistics command to check
tunnel statistics.
l Run the display mpls te tunnel-interface [ tunnel tunnel-number ] command to check
information about a tunnel interface on the ingress.
----End

Example
If the configuration is successful, run the preceding commands to obtain the following
information:
l Link information such as physical bandwidth and available bandwidth

l OSPF Opaque Type 10 LSA information on each node
l IS-IS TE information on each node
l Values of MPLS RSVP-TE timers, RSVP-TE-enabled interface status and bandwidth,
RSVP neighbor parameters, sender information, and statistics
l Tunnel names, incoming labels, outgoing labels, inbound interfaces, and outbound
interfaces
l Tunnel statistics on each node
l Detailed information about the tunnel interface on the ingress, including the tunnel name,
tunnel status, and attributes (such as LSP ID, ingress LSR ID, and egress LSR ID)
3.6 Configuring Dynamic Bandwidth Reservation

This section describes how to configure dynamic bandwidth reservation on an MPLS TE
interface. This configuration enables the MPLS TE interface dynamically reserve bandwidth for
an MPLS TE tunnel to account for the fact that physical bandwidth is variable.

Before configuring dynamic bandwidth reservation on an MPLS TE interface, familiarize
yourself with the usage scenario, complete the pre-configuration task, and obtain the data
required for the configuration.
Usage Scenario
An MPLS TE tunnel can only be established on interfaces with sufficient bandwidth reserved
for the tunnel. Since the physical bandwidth requirements are not static, the amount of bandwidth
that can be reserved for an MPLS TE interface must be flexible, the statically reserved bandwidth
may exceed the maximum bandwidth that can be reserved on that interface. In this case, the
interface cannot reserve sufficient bandwidth for MPLS TE links.
For example, a trunk interface has 1 Gbit/s physical bandwidth. Its maximum reservable
bandwidth is set to 800 Mbit/s and its reserved bandwidth in the BC0 pool is set to 600 Mbit/s.
If a trunk member interface fails, the trunk interface has its physical bandwidth reduced to 500
Mbit/s. As a result, the statically specified maximum reservable bandwidth and bandwidth in
the BC0 pool fail.
To enable the interface to dynamically reserve bandwidth within the reservable bandwidth range,
set the following parameters:
l Proportion of the maximum reservable bandwidth to the physical bandwidth of the interface
l Proportion of the bandwidth in a BC pool to the maximum reservable bandwidth
The two parameters help the interface dynamically reserve bandwidth for an MPLS TE tunnel.

Pre-configuration Task
Before configuring dynamic bandwidth reservation, enable MPLS TE on the interface.
Data Preparation
To configure dynamic bandwidth reservation, you need the following data.
No. Data
1 Proportion (in percentage) of the maximum reservable bandwidth to the physical

bandwidth of the specified interface
2 Proportion (in percentage) of the bandwidth in each BC pool to the maximum

reservable bandwidth of the specified interface
3.6.2 Setting the Proportion of the Maximum Reservable

Bandwidth to the Physical Bandwidth of an Interface
This section describes how to set the proportion of the maximum reservable bandwidth to the
physical bandwidth of an interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of an MPLS TE-enabled interface is displayed.
Step 3 Run:
mpls te bandwidth max-reservable-bandwidth dynamic bw-value-percentage
The proportion of the maximum reservable bandwidth to the physical bandwidth is set.
The bw-value-percentage parameter ranges from 1 to 100.
NOTE
l When both the mpls te bandwidth max-reservable-bandwidth dynamic command and the mpls te
bandwidth max-reservable-bandwidth command are run in a random order on an interface, the last
executed command takes effect.
l After the mpls te bandwidth max-reservable-bandwidth dynamic command is run on an interface,
only the mpls te bandwidth dynamic command can be used to set the proportion of the bandwidth in
a BC pool to the maximum reservable bandwidth.
----End

3.6.3 Setting the Proportion of the Bandwidth in Each BC Pool to

the Maximum Reservable Bandwidth
This section describes how to set the proportion of the bandwidth in each BC pool to the
maximum reservable bandwidth on an MPLS TE interface.
Context
The maximum reservable bandwidth must be specified before you perform this procedure. The
maximum reservable bandwidth can be either dynamic or static. Using the dynamic maximum
reservable bandwidth is recommended on MPLS TE interfaces.
Perform the following steps on each MPLS TE interface:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of an MPLS TE-enabled interface is displayed.
Step 3 Run:
mpls te bandwidth dynamic { bc0 bc0-bw-percentage | bc1 bc1-bw-percentage | bc2 bc2-
bw-percentage | bc3 bc3-bw-percentage | bc4 bc4-bw-percentage | bc5 bc5-bw-
percentage | bc6 bc6-bw-percentage | bc7 bc7-bw-percentage } *
The proportion of the bandwidth in each BC pool to the maximum reservable bandwidth is set.
The percent parameters, such as bc0-bw-percentage, range from 1 to 100.
NOTE
l When both the mpls te bandwidth dynamic command and the mpls te bandwidth command are run
in a random order on an interface, the last executed command takes effect.
l The DS-TE non-IETF mode supports BC0 and BC1; the DS-TE IETF mode supports BC0 through
BC7.
l If the non-IETF mode is switched to the IETF mode, the dynamic bandwidth in BC0 and BC1 pools
remains. If the IETF mode is switched to the non-IETF mode, the dynamic bandwidth in BC0 and BC1
pools also remains, and the dynamic bandwidth in all other BC pools are cleared.
----End

After configuring dynamic bandwidth reservation, view bandwidth information on MPLS TE
interfaces and check the configurations.
Prerequisites
Dynamic bandwidth reservation has been configured.

Procedure
l Run the display mpls te link-administration bandwidth-allocation [ interface interface-
type interface-number ] command to check bandwidth information on a specified or all
MPLS TE interfaces.
----End
Example
For example, on MPLS TE-enabled GE 1/0/0, the maximum reservable bandwidth is 80% of
the physical bandwidth, the bandwidth in the BC0 pool is 60% of the maximum reservable
bandwidth, and the bandwidth in the BC1 pool is 40% of the maximum reservable bandwidth.
Run the display mpls te link-administration bandwidth-allocation interface

GigabitEthernet 1/0/0 command to view bandwidth information on GE 1/0/0. The command
output shows that GE 1/0/0 has successfully reserved bandwidth in BC0 and BC1 pools.
<HUAWEI> display mpls te link-administration bandwidth-allocation interface
GigabitEthernet 1/0/0
Link ID: GigabitEthernet1/0/0
Bandwidth Constraint Model : Russian Dolls Model (RDM)
Physical Link Bandwidth(Kbits/sec) : 1000000
Maximum Link Reservable Bandwidth(Kbits/sec): 800000
Reservable Bandwidth BC0(Kbits/sec) : 480000
Downstream Bandwidth (Kbits/sec) : 0
IPUpdown Link Status : UP
PhysicalUpdown Link Status : UP
GracefulUpdown Link Status : DOWN
----------------------------------------------------------------------
TE-CLASS CT PRIORITY BW RESERVED BW AVAILABLE DOWNSTREAM
(Kbit/sec) (Kbit/sec) RSVPLSPNODE COUNT
----------------------------------------------------------------------
0 0 0 0 480000 0
1 0 1 0 480000 0
2 0 2 0 480000 0
3 0 3 0 480000 0
4 0 4 0 480000 0
5 0 5 0 480000 0
6 0 6 0 480000 0
7 0 7 0 480000 0
8 1 0 0 320000 0
9 1 1 0 320000 0
10 1 2 0 320000 0
11 1 3 0 320000 0
12 1 4 0 320000 0
13 1 5 0 320000 0
14 1 6 0 320000 0
15 1 7 0 320000 0
----------------------------------------------------------------------
3.7 Configuring a Tunnel Protection Group

group. If the working tunnel fails, traffic switches to the protection tunnel. The tunnel protection
group helps improve tunnel reliability.


Before configuring a tunnel protection group, familiarize yourself with the usage scenario,
Usage Scenario
A tunnel protection group protects E2E MPLS TE tunnels. If a working tunnel in a protection
group fails, traffic switches to a protection tunnel, minimizing traffic interruptions.
A protected tunnel is called a working tunnel. A tunnel that protects the working tunnel is called
a protection tunnel. The working and protection tunnels form a tunnel protection group. A tunnel
protection group works in either 1:1 or N:1 mode. The 1:1 mode enables a protection tunnel to
protect only a single working tunnel. The N:1 mode enables a protection tunnel to protect a
maximum of 16 working tunnels.
l Working and protection tunnels

Tunnel-specific attributes in a tunnel protection group are independent from each other.
For example, a protection tunnel with the bandwidth 50 Mbit/s can protect a working tunnel
with the bandwidth 100 Mbit/s.
TE FRR can be enabled to protect the working tunnel.
A protection tunnel cannot be protected by other tunnels or be enabled with TE FRR.
l Protection switching mechanism
The NE80E/40E performs protection switching based on the following rules.
Table 3-1 Switching rules
Switching Order of Description

Request Priority
Clear Highest Clears all switching requests initiated manually,

including forcible and manual switching. A signal
failure does not trigger traffic switching.
Lockout of ↑ Prevents traffic from switching to a protection

protection tunnel even though a working tunnel fails.
Forcible switch ↑ Forcibly switches traffic from a working tunnel to

a protection tunnel, irrespective of whether the
protection tunnel functions properly (unless a
higher priority switch request takes effect).
Signal failure ↑ Automatically triggers protection switching.
Manual switching ↑ Switches traffic from a working tunnel to a

protection tunnel only when the protection tunnel
functions properly or switches traffic from the
protection tunnel to the working tunnel only when
the working tunnel functions properly.

Switching Order of Description

Request Priority
Wait to restore ↑ Switches traffic from a protection tunnel to a

working tunnel after the working tunnel recovers
after the wait-to-restore (WTR) timer elapses.
No request Lowest There is no switching request.
Before configuring a tunnel protection group, create a working tunnel and a protection tunnel.
NOTE
A tunnel protection group uses a configured protection tunnel to protect a working tunnel, improving tunnel
reliability. Configuring working and protection tunnels over separate links is recommended.
Data Preparation
To configure a tunnel protection group, you need the following data.
No. Data
1 Interface number of a working tunnel in a protection group
2 Tunnel ID of the protection tunnel in the tunnel protection group
3 Parameters for the tunnel protection group, such as the hold-off time, switchback
mode, and WTR time
3.7.2 Creating a Tunnel Protection Group

group. If the working tunnel fails, traffic switches to the protection tunnel, improving tunnel
reliability.
Context
A tunnel protection group can be configured on the ingress to protect a working tunnel. The
switchback delay time and a switchback mode can also be configured. The switchback modes
are classified into revertive and non-revertive modes. The revertive mode is used by default. A
tunnel protection group working in revertive mode supports the switchback delay time.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
mpls te protection tunnel tunnel-id [ holdoff holdoff-time ] [ mode { non-
revertive | revertive [ wtr wtr-time ] } ]
The working tunnel is added to the protection group.
The following parameters can be configured in this step:
l tunnel-id specifies the tunnel ID of a protection tunnel.

l The holdoff time specifies the time between the declaration of signal failure and the
initialization of protection switching. The holdoff time ranges from 0 to 10. The default hold-
off time is 0 milliseconds. holdoff-time specifies a multiplier of 100 milliseconds.
NOTE
Holdoff-time = 100 milliseconds x holdoff-time

l Non-revertive mode means that traffic does not switch back to a working tunnel even though
a working tunnel recovers.
l Revertive mode means that traffic can switch back to a working tunnel after the working
tunnel recovers.
By default, the protection group works in revertive mode.
l Wait to restore (WTR) time is the time elapses before traffic switching is performed. The
WTR time ranges from 0 to 30 minutes. The default WTR time is 12 minutes. The wtr-
time parameter specifies a multiplier of 30 seconds.
NOTE
WTR time = 30 seconds x wtr-time
NOTE
If the number of working tunnels in the same protection group is N, perform Step 2 and Step 3 on each
interface with a specific interface-number.
NOTICE
If traffic has been switched to a protection tunnel, you can run the undo mpls te protection
tunnel command to delete the protection tunnel from the protection group after the board on
which the protection tunnel's outbound interface resides fails or is removed. After this command
is run, services will be restored after the working channel recovers. If you do not run this
command, services will not be switched back to the working channel even after the working
channel recovers.
Step 4 Run:
mpls te commit
The current configuration of the tunnel protection group is committed.
----End

Follow-up Procedure
You can also perform the preceding steps to modify a protection tunnel group.
3.7.3 (Optional) Configuring Dynamic BFD to Monitor CR-LSPs

A dynamic BFD session can be configured to monitor CR-LSPs in an MPLS TE tunnel protection
group. If the dynamic BFD session detects a fault in a CR-LSP bound to a working tunnel, the
session notifies the MPLS module of the fault and instructs the MPLS module to rapidly switch
traffic to a CR-LSP in a protection tunnel.
Context
An MPLS TE tunnel uses RSVP messages to detect and advertise faults at a low speed. To speed
up fault detection, dynamic BFD can be configured for the working tunnel in a tunnel protection
group.
NOTE
MPLS OAM and BFD cannot be configured for the same CR-LSP in a tunnel protection group.
Procedure
l Perform the following steps on the ingress of a working tunnel:
1. Run:
system-view

2. Run:
bfd
BFD is globally enabled.

3. Run:
quit

4. Run:
The view of the working tunnel interface is displayed.

5. Run:
mpls te bfd enable
The ingress is configured to automatically create a BFD session for the tunnel.
This command run in the tunnel interface view takes effect only on the specific tunnel
interface.
NOTE
To enable the ingress to automatically create BFD sessions for many tunnels, run the mpls te
bfd enable command in the MPLS view to globally enable BFD for TE. To disable the ingress
from automatically creating a BFD session on a specific tunnel interface, run the mpls te bfd
block command in the specific tunnel interface view.
6. (Optional) Run:

mpls te bfd { min-tx-interval tx-interval | min-rx-interval tx-interval |

detect-multiplier multiplier }*

7. Run:
mpls te commit

l Perform the following steps on the egress of a working tunnel:
1. Run:
system-view

2. Run:
bfd
BFD is globally enabled and the BFD view is displayed.

3. Run:
mpls-passive
The egress is enabled to create a BFD session passively.
The egress has to receive an LSP ping request carrying a BFD TLV before creating a
BFD session.
----End
3.7.4 (Optional) Enabling MPLS OAM to Detect Bidirectional LSPs

When the working and the protection tunnels have backward LSPs, you can enable MPLS OAM.
MPLS OAM to detect bidirectional LSPs.
Context
Before Enabling MPLS OAM to Detect Bidirectional LSPs, complete the following task:
l Configure backward LSPs for the working and protection tunnels. The working LSP and
protection LSP, and their reverse LSPs compose bidirectional LSPs.
l Configuring Basic MPLS OAM Functions of LSP
NOTE
The backward LSP must be a static LSP or static CR-LSP. The working LSP and protection LSP can be a
static LSP, static CR-LSP, or RSVP LSP.
It is recommended that the LSP and the backward LSP of a bidirectional LSP be both static LSPs or both
static CR-LSPs; the protection LSP and the backward LSP are all static LSPs or all static CR-LSPs.
On the ingress, the inbound interface of the backward LSP and the outbound interface of the working LSP
or the protection LSP must be the same.
Procedure
l Enable MPLS OAM to detect the bidirectional LSP of the working tunnel.
Perform the following steps on the ingress of the working tunnel:

1. Run:
system-view

2. Run:
The tunnel interface view of the working tunnel is displayed.

3. Run:
mpls te reverse-lsp lsp-name lsp-name
The backward LSP of the working tunnel is specified.

4. Run:
mpls te commit
The current configuration of the working tunnel is committed.

l Enable MPLS OAM to detect the bidirectional LSP of the protection tunnel.
Perform the following steps on the ingress of the protection tunnel:
1. Run:
system-view

2. Run:
The tunnel interface view of the protection tunnel is displayed.

3. Run:
The backward LSP of the protection tunnel is specified.

4. Run:
mpls te commit
The current configuration of the protection tunnel is committed.
----End
3.7.5 (Optional) Configuring the Protection Switching Trigger

Mechanism
After configuring a tunnel protection group, you can configure a trigger mechanism of protection
switching to force traffic to switch to the primary LSP or the backup LSP. Alternatively, you
can perform switchover manually.
Context
Pay attention to the Switching rules before configuring the protection switching trigger
mechanism.
Perform the following steps on the ingress of the tunnel protection group as required:

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Select one of the following protection switching trigger methods as required:
l To switch traffic to the protection tunnel, run:
mpls te protect-switch manual
l To cancel the configuration of the protection switching trigger mechanism, run:

mpls te protect-switch clear
Step 4 Run:
mpls te commit
The current configuration is committed.
----End

After configuring a tunnel protection group, run display commands to view information about
the tunnel protection group and the binding between the working and protection tunnels.
Prerequisites
A tunnel protection group has been configured.
Procedure
Step 1 Run the display mpls te protection tunnel { all | tunnel-id | interface tunnel interface-
number } [ verbose ] command to check information about a tunnel protection group.
Step 2 Run the display mpls te protection binding protect-tunnel { tunnel-id | interface tunnel
interface-number } command to check the binding between the working and protection tunnels.
----End
Example
If the configurations succeed, you can run a display command to view the configuration of a
tunnel protection group.
# Run the display mpls te protection tunnel all command on the ingress to view information
about the tunnel protection group.
<HUAWEI> display mpls te protection tunnel all
------------------------------------------------------------------------
No. Work-tunnel status /id Protect-tunnel status /id Switch-Result
------------------------------------------------------------------------
1 non-defect /100 non-defect /101 work-tunnel

# Run the display mpls te protection binding protect-tunnel tunnel-id command. The
command output shows that a protection tunnel has been bound to a working tunnel.
<HUAWEI> display mpls te protection binding protect-tunnel 101
------------------------------------------------------------------------
Binding information of( tunnel id: 101 )
------------------------------------------------------------------------
Protect-tunnel id :101
Protect-tunnel name :Tunnel1/0/11
Maximum number of bound work-tunnels :8
Currently bound work-tunnels :Total( 1 )
:Tunnel1/0/10
3.8 Referencing the CR-LSP Attribute Template to Set Up a

CR-LSP
By configuring a CR-LSP attribute template to set up CR-LSPs, you can simply the
configurations and make the configurations of CR-LSPs more flexible.

Before using a CR-LSP attribute template to set up a CR-LSP, familiarize yourself with the
configuration.
Usage Scenario
You can create a CR-LSP by using the following methods:
l Creating a CR-LSP without using a CR-LSP attribute template

l Creating a CR-LSP by using a CR-LSP attribute template
It is recommended to use a CR-LSP attribute template to set up a CR-LSP because this
method has the following advantages:
– A CR-LSP attribute template can greatly simplify the configurations of CR-LSPs.
– A maximum of three CR-LSP attribute templates can be created for a hot-standby CR-
LSP or an ordinary backup CR-LSP; you can set up a hot-standby CR-LSP or an ordinary
backup CR-LSP with different path options. (Among the three attribute templates, the
template with the smallest sequence number is firstly used. If the setup fails, the template
with a greater sequence number is used.)
– If configurations of a CR-LSP attribute template are modified, configurations of the
CR-LSPs established by using the CR-LSP attribute template are automatically updated,
which makes the configurations of CR-LSPs more flexible.
NOTE
The preceding two methods can be used together. If the TE attribute configured in the tunnel interface view
and the TE attribute configured through a CR-LSP attribute template coexist, the former takes precedence
over the latter.
Before using a CR-LSP attribute template to set up a CR-LSP, complete the following tasks:

l Configure an IGP on the P and PE on the MPLS backbone network to implement IP

connectivity.
l Enable MPLS, MPLS TE, and RSVP TE on the MPLS backbone network.
Data Preparation
To use a CR-LSP attribute template to set up a CR-LSP, you need the following data.
No. Data
1 Names of the primary CR-LSP attribute template, hot-standby CR-LSP attribute

template, or ordinary backup CR-LSP attribute template
2 (Optional) Bandwidth of the CR-LSP attribute template
3 (Optional) Name of the explicit path referenced by the CR-LSP attribute

template
4 (Optional) Affinity value and affinity mask of the CR-LSP attribute template
5 (Optional) Setup priority and hold priority of the CR-LSP attribute template
6 (Optional) Hop limit of the CR-LSP attribute template
7 Tunnel interface which will use the attribute template
8 Sequence of using the hot-standby CR-LSP attribute template and ordinary

backup CR-LSP attribute template
3.8.2 Configuring a CR-LSP Attribute Template

You need to configure a CR-LSP attribute template before using the CR-LSP attribute template
to set up a CR-LSP.
Context
Perform the following steps on the ingress of the CR-LSP:
Steps 3 to 10 are optional.
Procedure
Step 1 Run:
system-view
Step 2 Run:
lsp-attribute lsp-attribute-name
A CR-LSP attribute template is created and the LSP attribute view is displayed.

NOTE
A CR-LSP attribute template can be deleted only when it is not used by any tunnel interface.

bandwidth { ct0 bandwidth | ct1 bandwidth | ct2 bandwidth | ct3 bandwidth | ct4
bandwidth | ct5 bandwidth | ct6 bandwidth | ct7 bandwidth }*
The bandwidth is set for the CR-LSP attribute template. The optional bandwidth type varies with
DS-TE modes. In non-DS-TE mode, only CT0 and CT1 are supported. In DS-TE mode, if no
TE-Class mapping table is configured, only CT0, CT1, CT2, and CT3 are supported; if a TE-
Class mapping table is configured, the CT types configured in the TE-Class mapping table are
used.

An explicit path is configured for the CR-LSP attribute template.

affinity property affinity-value [ mask mask-value ]
The affinity attribute is set for the CR-LSP attribute template.
By default, both the affinity value and the affinity mask are 0x0.

priority setup_priority_value [ hold_priority_value ]
The setup priority and hold priority are set for the CR-LSP attribute template.
By default, both the setup priority and the hold priority are 7.

hop-limit hop-limit
The hop limit is set for the CR-LSP attribute template.
By default, the hop limit is 32.

fast-reroute [ bandwidth ]
FRR is enabled for the CR-LSP attribute template.
By default, FRR is disabled.
NOTE
Before enabling or disabling FRR for the CR-LSP attribute template, note the following:
l After FRR is enabled, the route recording function is automatically enabled for the CR-LSP.
l After FRR is disabled, attributes of the bypass tunnel are automatically deleted.

record-route [ label ]
The route recording function is enabled for the CR-LSP attribute template.
By default, the route recording function is disabled.

NOTE
The undo mpls te record-route command can take effect only when FRR is disabled.

bypass-attributes { bandwidth bandwidth | priority setup_priority_value
[ hold_priority_value ] }
The bypass tunnel attributes are configured for the CR-LSP attribute template.
By default, the bypass tunnel attributes are not configured.
NOTE
This command can take effect only when the following conditions are met:
l The CR-LSP attribute template has been enabled with FRR allowing bandwidth protection.
l The bandwidth for the bypass tunnel is lower than or equal to the bandwidth for the CR-LSP attribute
template.
l The setup priority and hold priority of the bypass tunnel are smaller than the setup priority and hold
priority of the CR-LSP attribute template.
Step 11 Run:
commit
Configurations of the CR-LSP attribute template are committed.
NOTE
When the CR-LSP attribute template is used to set up a CR-LSP:

l The CR-LSP is removed and a new CR-LSP is created if the Break-Before-Make attribute (the priority
attribute) of the CR-LSP attribute template is modified.
l The CR-LSP is removed after an eligible CR-LSP is created and traffic switches to the new CR-LSP
if the Make-Before-Break attribute of the CR-LSP attribute template is modified.
----End
3.8.3 Setting Up a CR-LSP by Using a CR-LSP Attribute Template

You can use a CR-LSP attribute template to set up the primary CR-LSP, hot-standby CR-LSP,
and ordinary backup CR-LSP.
Context
Perform the following steps on the ingress of the CR-LSP:
Procedure
Step 1 Run:
system-view
The system view is display.
Step 2 Run:

To configure the TE tunnel interface, refer to the section Configuring MPLS TE Tunnel
Interfaces.
Step 3 Run:
mpls te primary-lsp-constraint { dynamic | lsp-attribute lsp-attribute-name }
The primary CR-LSP is set up through the specified CR-LSP attribute template.
If dynamic is used, it indicates that when a CR-LSP attribute template is used to set up a primary
CR-LSP, all attributes in the template use the default values.

mpls te hotstandby-lsp-constraint number { dynamic | lsp-attribute lsp-attribute-
name }
The hot-standby CR-LSP is set up by using the specified CR-LSP attribute template.
A maximum of three CR-LSP attribute templates can be used to set up a hot-standby CR-LSP.
The hot-standby CR-LSP must be consistent with the primary CR-LSP in the attributes of the
setup priority, hold priority, and bandwidth type. To set up a hot-standby CR-LSP, you should
keep on attempting to use CR-LSP attribute templates one by one in ascending order of the
number of the attribute templates until the hot-standby CR-LSP is set up.
If dynamic is used, it indicates that the hot-standby CR-LSP is assigned the same bandwidth
and priority as the primary CR-LSP, but specified with a different path from the primary CR-
LSP.

mpls te backup hotstandby-lsp-constraint wtr interval
The Wait to Restore (WTR) time is set for the traffic to switch back from the hot-standby CR-
LSP to the primary CR-LSP.
By default, the WTR time for the traffic to switch back from the hot-standby CR-LSP to the
primary CR-LSP is 10 seconds.
NOTE
The hot-standby CR-LSP specified in the mpls te backup hotstandby-lsp-constraint wtr command must
be an existing one established by running the mpls te hotstandby-lsp-constraint command.

mpls te ordinary-lsp-constraint number { dynamic | lsp-attribute lsp-attribute-
name }
The ordinary backup CR-LSP is set up by using the specified CR-LSP attribute template.
A maximum of three CR-LSP attribute templates can be used to set up an ordinary backup CR-
LSP. The ordinary backup CR-LSP must be consistent with the primary CR-LSP in the attributes
of the setup priority, hold priority, and bandwidth type. To set up an ordinary backup CR-LSP,
you should keep on attempting to use CR-LSP attribute templates one by one in ascending order
of the number of the attribute template until the ordinary backup CR-LSP is set up.
If dynamic is used, it indicates that the ordinary backup CR-LSP is assigned the same bandwidth
and priority as the primary CR-LSP.
Step 7 Run:
mpls te commit

The configurations of the CR-LSP are committed.
----End

After referencing a CR-LSP attribute template to set up CR-LSPs, you can view information
about the established MPLS TE CR-LSPs.
Prerequisites
The CR-LSP has been established using the CR-LSP attribute template .
Procedure
Step 1 Run the display explicit-path [ [ name ] path-name ] [ tunnel-interface | lsp-attribute |
verbose ] command to view information about the explicit path configured for the CR-LSP
attribute template.
Step 2 Run the display mpls te tunnel-interface lsp-constraint [ tunnel interface-number ] command
to view information about the CR-LSP attribute template on the TE tunnel interface.
Step 3 Run the display mpls te tunnel-interface [ auto-bypass-tunnel [ tunnel-name ] | tunnel

interface-number ] command to view information about the MPLS TE tunnel using the CR-LSP
attribute template.
----End
Example
If the configurations succeed, you can view the following information:
l List of CR-LSP attribute templates that use the specified explicit path
l Information about the CR-LSP attribute templates on the specified TE tunnel interface
l Information about the CR-LSPs that are set up through the specified CR-LSP attribute
template
3.9 Configuring an Associated Bidirectional Dynamic LSP

The associated bidirectional dynamic LSP can transmit bidirectional traffic, addressing the
problem of network congestions and protecting bidirectional traffic against interruption by
switching traffic to the backup tunnel in the case of a tunnel failure.

Before configuring an associated bidirectional dynamic LSP, familiarize yourself with the usage
Usage Scenario
Associated bidirectional dynamic LSPs are configured to address the following problems:

l An RSVP TE tunnel is unidirectional (a forward tunnel), which means that service flows
can be sent only from the ingress to the egress of the tunnel. To send service flows from
the egress to the ingress of the tunnel, use IP forwarding. This, however, may lead to traffic
congestion.
l If another RSVP TE tunnel (a reverse tunnel) is configured to send service flows from the
egress to the ingress, when the forward tunnel or the reverse tunnel becomes faulty and
traffic switching is performed, the corresponding reverse or forward tunnel is not informed
of the fault, and traffic switching is not performed, leading to a service interruption.
Deploy two RSVP TE tunnels on two devices functioning as the source and destination of each
other. Bind two unidirectional dynamic LSPs of the two tunnels to an associated bidirectional
dynamic LSP. The associated bidirectional dynamic LSP can transmit bidirectional traffic,
addressing the problem of network congestions and protecting bidirectional traffic against
interruption by switching traffic to the backup tunnel in case of a tunnel failure.
Prerequisites
Before configuring an associated bidirectional dynamic LSP, create two MPLS TE tunnels over
the same path but in opposite directions.
Data Preparation
To configure an associated bidirectional dynamic LSP, you need the following data.
No. Data
1 Tunnel ID of a reverse RSVP LSP
2 LSR ID of the ingress on the reverse RSVP LSP
3.9.2 Configuring an Associated Bidirectional Dynamic LSP

After the primary and backup tunnels are established, you can bind the unidirectional LSP of
each tunnel into an associated bidirectional dynamic LSP on both primary and backup tunnels
for dual-end protection switching.
Context
To configure an associated bidirectional dynamic LSP, both the forward and backward tunnels
must be RSVP-TE tunnels.
In the tunnel interface view, configure the RSVP LSP with the local ingress as the egress to be
the reverse LSP. The configuration is performed on both the forward and backward tunnels.
Procedure
Step 1 Run:
system-view

Step 2 Run:
A tunnel interface is created and the tunnel interface view is displayed.
Step 3 Run:
mpls te reverse-lsp protocol rsvp-te ingress-lsr-id ingress-lsr-id tunnel-id
tunnel-id
A reverse LSP is configured for the tunnel.
Step 4 Run:
mpls te commit
----End

After an associated bidirectional dynamic LSP is configured, you can view the configuration
information.
Prerequisites
An associated bidirectional dynamic LSP has been configured.
Procedure
l Run the display mpls te reverse-lsp command to check information about the reverse LSP.
----End
Example
Run the display mpls te reverse-lsp command to view information about the reverse LSP.
[HUAWEI] display mpls te reverse-lsp verbose
----------------------------------------------------------------------
LSP Information: STATIC LSP
-------------------------------------------------------------------------------
Obverse Tunnel : Tunnel0/0/2
Reverse LSP Name : lsp1
Reverse LSP State : Down
Incoming Label : 30
Incoming Interface : Eth0/0/1
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Obverse Tunnel : Tunnel0/0/1
Reverse LSP IngressLsrID : 3.3.3.3
Reverse LSP SessionID : 1
Signalled Tunnel Name : -
Reverse LSP State : Down

3.10 Adjusting RSVP Signaling Parameters

This section describes how to adjust RSVP signaling parameters. RSVP-TE provides various
parameters, which meet the requirements for reliability, network resources, and advanced MPLS
features.

Before adjusting RSVP signaling parameters, familiarize yourself with the usage scenario,
Usage Scenario
RSVP-TE supports diversified signaling parameters, which helps improve network reliability
and network resource efficiency and offers some MPLS TE advanced features.
Before performing the configuration tasks described in this section, you must know in detail the
purpose of each task and the influences they have on networks.
Before optimizing the RSVP-TE tunnel, configure an RSVP-TE tunnel.
Data Preparation
To optimize the RSVP TE tunnel, you need the following data.
No. Data
1 Refresh interval of RSVP messages
2 PSB, RSB, and BSB timeout multiplier of RSVP
3 Retransmission timer and increment of RSVP
4 Transmission interval and allowable maximum numbers of lost Hello messages
3.10.2 Configuring RSVP Hello Extension

This section describes how to configure the RSVP Hello extension. The RSVP Hello extension
mechanism can monitor the reachability of RSVP neighbors.
Context
Perform the following steps on each node along a TE tunnel:
Procedure
Step 1 Run:

system-view
Step 2 Run:
mpls
Step 3 Run:
mpls rsvp-te hello
The RSVP Hello extension is enabled on this node.
By default, the RSVP Hello extension is disabled.
Step 4 Run:
mpls rsvp-te hello-lost times
The maximum number of dropped Hello messages is set.
When the RSVP Hello extension is enabled, by default, a maximum of three consecutive Hello
ACK messages cannot be received. If more than three Hello ACK messages are dropped, the
link is considered faulty, and the TE tunnel is torn down.
Step 5 Run:
mpls rsvp-te timer hello interval
The interval at which Hello messages are refreshed is set.
When the RSVP Hello extension is enabled, by default, the refresh interval of Hello message is
3 seconds.
If the refresh interval is modified, the modification takes effect after the existing timer expires.
Step 6 Run:
quit
Step 7 Run:
The interface view of the RSVP-TE-enabled interface is displayed.
Step 8 Run:
mpls rsvp-te hello
The RSVP Hello extension mechanism is enabled on the interface.
The RSVP Hello extension mechanism is used to monitor the reachability of RSVP neighboring
nodes. For more information, see RFC 3209.
----End
3.10.3 Configuring RSVP Timers

This section describes how to configure RSVP timers. The RSVP status timer defines the interval
at which Path and Resv messages are refreshed.

Context
Perform the following steps on each node along a TE tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls rsvp-te timer refresh interval
The interval at which Path and Resv messages are refreshed is set.
By default, the refresh interval is 30 seconds.
If the refresh interval is modified, the modification takes effect after the existing timer expires.
Do not set a long refresh interval or modify the refresh interval frequently.
Step 4 Run:
mpls rsvp-te keep-multiplier number
The timeout multiplier of the PSB and RSB is configured.
By default, the timeout multiplier of the PSB and RSB is 3.
----End
3.10.4 Configuring RSVP Refresh Mechanism

This section describes who to configure the RSVP Refresh mechanism. Enabling Srefresh on
the interface that connects two neighboring devices can reduce the cost and improve system
performance. After Srefresh is enabled on an interface, the retransmission of Srefresh messages
is automatically enabled on the interface.
Context
Enabling Srefresh in the interface or MPLS view on two nodes that are the neighbors of each
other can reduce the cost and improve network performance. Enabled in the interface view,
Srefresh takes effect only on the interface; enabled in the MPLS view, Srefresh takes effect on
the entire device. After Srefresh is enabled, the retransmission of Srefresh messages is
automatically enabled on the interface or the device.
For example, a node initializes the retransmission interval as Rf seconds. If a node receives no
ACK message within Rf seconds, the node retransmits the RSVP message after (1 + Delta) x
Rf seconds. The value of Delta depends on the link rate. The node retransmits the message until
it receives an ACK message or the times of retransmission reach the threshold (retransmission
increment value).

Procedure
Step 1 Run:
system-view
Step 2 Run either of the following commands to enter a specific view:

l To enter the interface view of the MPLS TE tunnel, run:
The Srefresh mechanism that is configured in the interface view takes effect only on the
current interface.
l To enter the MPLS view, run:
mpls
The Srefresh mechanism that is configured in the MPLS view takes effect globally. The
Srefresh mechanism in MPLS view applies to the TE FRR networking. Srefresh is enabled
globally on the Point of Local Repair (PLR) and Merge Point (MP) over an FRR bypass
tunnel. This allows efficient use of network resources and improves Srefresh reliability.
Step 3 Run:
mpls rsvp-te srefresh
Srefresh is enabled.
By default, Srefresh is disabled on the interface.

mpls rsvp-te timer retransmission { increment-value increment | retransmit-value
interval } *
The retransmission parameters are set.
By default, increment is 1, and interval is s00 milliseconds.
----End
3.10.5 Enabling Reservation Confirmation Mechanism

This section describes how to enable the reservation confirmation mechanism. Receiving a
ResvConf message does not mean that the resource reservation is successful, but only means
that resources are reserved on the farthest upstream node at which this Resv message arrives.
These resources may be preempted by other applications later.
Context
Perform the following steps on the egress of a TE tunnel:
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls
Step 3 Run:
mpls rsvp-te resvconfirm
The reservation confirmation mechanism is enabled.
The reservation confirmation is initiated by the node that receives a Path message. An object
that requires confirming the reservation is carried in the Resv message sent by the node that
receives the Path message.
----End
3.10.6 Configuring the RSVP Message Format

If the formats of Resource Reservation Protocol (RSVP) messages are different between a
Huawei device and a non-Huawei device, you can modify the format of RSVP messages to be
sent by the Huawei device, enabling the Huawei device to interwork with the non-Huawei device.
In addition, if you want an ingress to learn the RSVP-Traffic Engineering (RSVP-TE) tunnel
Down causes of transit and egress nodes, you can configure the transit and egress nodes to add
the down-reason object in an RSVP message to be sent, facilitating fault locating.
Context
If an RSVP-TE tunnel is constructed by Huawei and non-Huawei devices and the format of
RSVP messages sent by a Huawei device is different than that of a non-Huawei device in the
same RSVP-TE tunnel, you can configure the format of RSVP messages to be sent by the Huawei
device, so that the Huawei device can interwork with the non-Huawei device.
You can also configure the Huawei device to add the down-reason object in an RSVP message
to be sent. This object records RSVP-TE tunnel Down causes of transit and egress nodes, so that
the ingress can learn the tunnel Down causes, facilitating fault locating.
Procedure
l Configure the formats of objects in an RSVP message.
Perform the following steps on all Huawei devices along an RSVP-TE tunnel:
1. Run:
system-view

2. Run:
mpls

3. Run:
mpls rsvp-te send-message { suggest-label | extend-class-type value-
length-type | session-attribute without-affinity | down-reason }
The formats of objects are specified for RSVP messages to be sent.

The configuration guidelines of this command are as follows:
– If a non-Huawei device requires the suggest-label object in a Path message sent

by a Huawei device, specify suggest-label.
– If a non-Huawei device uses the value-length-type (VLT) encoding format of the
extended-class-type object but a Huawei device uses the type-length-value (TLV)
encoding format of the extended-class-type object, specify extend-class-type
value-length-type.
– If a non-Huawei device does not support the session-attribute object sent by a
Huawei device and the session-attribute object sent by the Huawei device has an
affinity attribute, specify session-attribute without-affinity.
– If you want an ingress to learn RSVP-TE tunnel Down causes of the transit and
egress nodes, run the mpls rsvp-te send-message down-reason command.
l Configure the format of the record route object (RRO) in a Resv message if a non-Huawei
device does not support the RRO object in a Resv message sent by a Huawei device.
Perform the following steps on all Huawei devices along an RSVP-TE tunnel:
1. Run:
system-view

2. Run:
mpls

3. Run the following command as needed:
– On a transit node, run the mpls rsvp-te resv-rro transit { { incoming | incoming-
with-label } | { routerid | routerid-with-label } | { outgoing | outgoing-with-
label } } * command.
– On an egress, run the mpls rsvp-te resv-rro egress { { incoming | incoming-with-
label } | { routerid | routerid-with-label } } * command.
----End

After adjusting RSVP signaling parameters, you can view the refresh parameters, the status of
RSVP reservation confirmation and RSVP Hello extension, and the RSVP status timer
configuration.
Procedure
l Run the display mpls rsvp-te command to check information about RSVP-TE.
l Run the display mpls rsvp-te psb-content [ ingress-lsr-id tunnel-id lsp-id ] command to
check information about RSVP-TE PSB.
l Run the display mpls rsvp-te rsb-content [ ingress-lsr-id tunnel-id lsp-id ] command to
check information about RSVP-TE RSB.

number ] } command to check RSVP-TE statistics.
----End
Example
If the configurations are successful, run the preceding commands and view the following
information:
l Refresh parameters of the interface

l Confirmation of the resource reservation, the Hello extension status, and the configurations
of RSVP-TE status timers.
3.11 Configuring RSVP Authentication

This section describes how to configure RSVP authentication. RSVP authentication prevents
unauthorized nodes from setting up RSVP neighbor relationships with the local node and
prevents spoofing of forged packets. By default, RSVP authentication is not configured.
Configuring RSVP authentication is recommended to ensure system security.

Before configuring RSVP authentication, familiarize yourself with the usage scenario, complete
Usage Scenario
RSVP key authentication prevents an unauthorized node from setting up RSVP neighbor
relationships with the local node or generating forged packets to attack the local node.
RSVP key authentication prevents the following unauthorized means of setting up RSVP
neighbor relationships, protecting the local node from attacks (for example, malicious
reservation of high bandwidth):
l An unauthorized node attempts to set up a neighbor relationship with the local node.
l A remote node generates and sends forged RSVP messages to set up a neighbor relationship
with the local node.
RSVP key authentication alone cannot prevent replay attacks or RSVP message mis-sequence
during network congestion. RSVP message mis-sequence causes authentication termination
between RSVP neighbors. The handshake and message window functions, together with RSVP
key authentication, can prevent the preceding problems.
The RSVP authentication lifetime can be configured to prevent unceasing RSVP authentication.
When no CR-LSP exists between RSVP neighbors, the neighbor relationship is kept Up until
the RSVP authentication lifetime elapses.
Before configuring RSVP authentication, configure an RSVP-TE tunnel.

Data Preparation
To configure RSVP authentication, you need the following data.
No. Data
1 RSVP authentication key
2 (Optional) RSVP Authentication Lifetime
3 (Optional) Local password used in handshake authentication
4 (Optional) RSVP message window size (1 by default)
3.11.2 Configuring RSVP Key Authentication

This section describes how to configure RSVP key authentication. RSVP key authentication is
performed on interfaces of two RSVP neighbors. The keys configured on the interfaces of the
RSVP neighbors must be the same. A key inconsistency causes RSVP authentication to fail and
the RSVP packets to be discarded.
Context
RSVP authentication uses authentication objects carried in RSVP messages to authenticate the
RSVP messages, which prevents malicious attacks initiated by the modified or forged RSVP
messages and improves network reliability and security.
RSVP key authentication is configured in either of the following views:
l In the interface view, RSVP key authentication is performed between directly connected
nodes.
l In the MPLS RSVP-TE neighbor view, RSVP key authentication is performed between
neighboring nodes, which is recommended.
HMAC-MD5 or keychain authentication is enabled by configuring one of the following optional
parameters:
l cipher: configures HMAC-MD5 authentication with keys displayed in ciphertext.
l plain: configures HMAC-MD5 authentication with keys displayed in plaintext.
l keychain: configures keychain authentication by using a globally configured keychain.
NOTE
RSVP keychain authentication only supports the HMAC-MD5 algorithm.
Procedure
l Configure RSVP key authentication in the interface view.
Perform the following steps on each interface between two directly connected nodes:
NOTE
The configuration must be complete on two neighboring nodes within a period of time three times
as long as the refresh interval at which a Path Refresh message is sent. If the configuration is not
complete on either of the two neighboring nodes after three intervals elapse, the session goes Down.

1. Run:
system-view

2. Run:
The view of the MPLS TE link interface is displayed.

3. Run:
mpls rsvp-te authentication { { { cipher | plain } auth-key } | keychain
keychain-name }
The authentication key is configured.
RSVP key authentication configured in the interface view takes effect only on the
current interface and has the lowest preference.
NOTICE
When configuring an authentication password, select the ciphertext mode because the
password is saved in configuration files in plaintext if you select plaintext mode, which
has a high risk. To ensure device security, change the password periodically.
l Configure RSVP key authentication in the MPLS RSVP-TE neighbor view.
Perform the following steps on each neighboring node:
NOTE
The configuration must be complete on two neighboring nodes within a period of time three times
as long as the refresh interval at which a Path Refresh message is sent. If the configuration is not
complete on either of the two neighboring nodes after three intervals elapse, the session goes Down.
1. Run:
system-view

2. Run:
mpls rsvp-te peer ip-address
The MPLS RSVP-TE neighbor view is displayed.
– When ip-address is specified as an interface address but not the LSR ID of the
RSVP neighbor, key authentication is based on this neighbor's interface address.
RSVP key authentication takes effect only on the specified interface of the
neighbor, which provides high security. RSVP key authentication has the highest
preference.
– When ip-address is specified as an address equal to the LSR ID of the RSVP
neighbor, key authentication is based on the neighbor's LSR ID. RSVP key
authentication takes effect on all interfaces of the neighbor. RSVP key
authentication has the higher preference than that configured in the interface view,
but has the lower preference than that configured based on the neighbor interface
address.

3. Run:
mpls rsvp-te authentication { { { cipher | plain } auth-key } | keychain
keychain-name }
The authentication key is configured.

l (Optional) Set an interval at which a Challenge message is retransmitted and the maximum
number of times that a Challenge message can be retransmitted.
If Authentication messages exchanged between two RSVP nodes are out of order, a node
sends a Challenge message to its peer to request connection restoration. If the node receives
no reply to the Challenge message, the node retransmits the Challenge message at a
specified interval. If no reply is received after the maximum number of retransmission times
is reached, the neighbor relationship is not restored. If a reply is received before the
maximum number of retransmission times is reached, the neighbor relationship is restored,
and the number of retransmission times is cleared for the Challenge message.
If the interval at which a Challenge message is retransmitted or the maximum number of
times that a Challenge message can be retransmitted does not meet your RSVP
authentication success ratio requirement, perform the following steps:
1. Run:
system-view

2. Run:
mpls

3. Run:
mpls rsvp-te retrans-timer challenge retransmission-interval
The interval at which a Challenge message is retransmitted is specified.

The default interval is 1000 ms.
4. Run:
mpls rsvp-te challenge-lost max-miss-times
The maximum number of times that a Challenge message can be retransmitted is

specified.
----End
3.11.3 (Optional) Configuring the RSVP Authentication Lifetime

This section describes how to configure the RSVP authentication lifetime. A device retains an
RSVP neighbor relationship for a specified period of time even though no CR-LSP exists
between the RSVP neighbors.
Context
RSVP neighbors to remain the neighbor relationship when no CR-LSP exists between them until
the RSVP authentication lifetime elapses. Configuring the RSVP authentication time does not
affect the existing CR-LSPs.

Perform the following steps on each node along the tunnel:
Procedure
Step 1 Run:
system-view

l To enter the interface view of an MPLS TE tunnel, run:
The RSVP authentication lifetime that is configured in the interface view takes effect only
on the current interface.
l To enter the MPLS RSVP-TE neighbor view, run:
This command takes effect based on the specified IP address:

– If ip-address is set to a value equal to an interface address but not the LSR ID of the RSVP
neighbor, the RSVP authentication lifetime takes effect only on the interface.
– If ip-address is set to a value equal to the LSR ID, the RSVP authentication lifetime takes
effect on the entire device.
Step 3 Run:
mpls rsvp-te authentication lifetime lifetime
The RSVP authentication lifetime is set.
The lifetime value is in the format of HH:MM:SS. The value ranges from 00:00:01 to 23:59:59.
By default, the time is 00:30:00, that is, 30 minutes.
----End
3.11.4 (Optional) Configuring the Handshake Function

This section describes how to configure the handshake function. RSVP key authentication is the
prerequisite for configuring the RSVP handshake function.
Context
Perform the following steps on each node along a tunnel:
Procedure
Step 1 Run:
system-view


The handshake function that is configured in the interface view takes effect only on the
current interface.

– If ip-address is set to a value equal to an interface address but not the LSR ID of the RSVP
neighbor, the handshake function is configured based on the neighbor interface address.
The handshake function takes effect only on the interface.
– If ip-address is set to a value equal to the LSR ID of the neighbor, the handshake function
is configured based on the neighbor LSR ID. The handshake function takes effect on the
entire device.
Step 3 Run:
mpls rsvp-te authentication handshake
The handshake function is configured.
The handshake function helps a device to establish an RSVP neighbor relationship with its
neighbor. If a device receives RSVP messages from a neighbor, with which the device has not
established an RSVP authentication relationship, the device will send Challenge messages
carrying local identifier to this neighbor. After receiving the Challenge messages, the neighbor
returns Response messages carrying the identifier the same as that in the Challenge messages.
After receiving the Response messages, the local end checks identifier carried in the Response
messages. If identifier in the Response messages is the same as the local one, the device
determines to establish an RSVP authentication relationship with its neighbor.
NOTE
If you run the mpls rsvp-te authentication lifetime command after configuring the handshake function,
note that the RSVP authentication lifetime must be greater than the interval at which RSVP refresh messages
are sent.
If the RSVP authentication lifetime is less than the interval at which RSVP refresh messages are sent, the
RSVP authentication relationship may be deleted because no RSVP refresh message is received within the
RSVP authentication lifetime. In such a case, after the next RSVP refresh message is received, the
handshake operation is triggered. Repeated handshake operations may cause RSVP tunnels unable to be
set up or cause RSVP tunnels to be deleted.
----End
3.11.5 (Optional) Configuring the Message Window Function

This section describes how to configure the message window function to prevent mis-sequence
of RSVP messages.
Context
The default window size is 1, which means that a device saves only the largest sequence number
of the RSVP message from neighbors.
When window-size is greater than 1, a device accepts several valid sequence numbers.
Perform the following steps on each node along a tunnel:

Procedure
Step 1 Run:
system-view

The message window function that is configured in the interface view takes effect only on
the current interface.

– If ip-address is set to a value equal to an interface address but not the LSR ID of an RSVP
neighbor, the message window function is configured based on the neighbor interface
address. The handshake function takes effect only on the interface.
– If ip-address is set to a value equal to the LSR ID of the RSVP neighbor, the message
window function is configured based on the neighbor LSR ID. The message window
function takes effect on the entire device.
Step 3 Run:
mpls rsvp-te authentication window-size window-size
The message window function is configured.
window-size is the number of valid sequence numbers carried in RSVP messages that a device
can save.
Configuring RSVP Key Authentication must be configured before the message window
function is configured.
NOTE
If RSVP is enabled on an Eth-Trunk interface or an IP-Trunk interface, only one neighbor relationship is
established on the trunk link between RSVP neighbors. Therefore, any member interface of the trunk
interface receives RSVP messages in a random order, which results in RSVP message mis-sequence. The
RSVP message window size can be configured to prevent RSVP message mis-sequence.
The window size greater than 32 is recommended. If the window size is set too small, the RSVP packets
are discarded because the sequence number is out of the range of the window size, which causes an RSVP
neighbor relationship to be terminated.
----End

After the configuration of RSVP authentication, you can view information about RSVP-TE of
a physical outgoing interface.
Prerequisites
The configurations of RSVP authentication are complete.

Procedure
Step 1 Run the display mpls rsvp-te peer [ interface interface-type interface-number ] command to
view information about the RSVP neighbor on an RSVP-TE-enabled interface.
----End
Example
If the configuration is successful, the command output shows that the number of RSBs is not
zero.
3.12 Adjusting the Path of CR-LSP

This section describes how to adjust the path of a CR-LSP. You can configure and adjust the
method of calculating CR-LSPs.

Before adjusting the path calculation method of CR-LSPs, familiarize yourself with the usage
Usage Scenario
CSPF uses the TEDB and constraints to calculate appropriate paths, and a singling protocol
establishes CR-LSPs over the paths. MPLS TE provides many methods to affect CSPF
computation to adjust the CR-LSP path:
l Tie-breaking
CSPF calculates only the shortest path to reach the tunnel destination. During path
computation, if there are several paths with the same metric, the device selects one of them.
Tie-breaking methods for selecting the path are as follows:
– Most-fill: selects a link with the largest ratio of the used bandwidth to the maximum
reservable bandwidth. This method ensures that bandwidth resources are used
effectively.
– Least-fill: selects the link with the smallest ratio of the used bandwidth to the maximum
reservable bandwidth. This method ensures that links use bandwidth resources evenly.
– Random: selects the link randomly. This method can distribute LSPs evenly over links
regardless of the bandwidth.
NOTE
Tie-breaking selects the link based on bandwidth ratio. If the ratios are the same, such as no reservable
bandwidth or the equal bandwidth is used, the link that is found firstly is selected, even if least-fill
or most-fill is configured.
l Route pinning
A successfully established CR-LSP does not vary with the route change.
l Administrative group and affinity property
The affinity property of the MPLS TE tunnel determines the links used by the tunnel. The
affinity cooperates with link administrative group to determine which links the tunnel uses.

l SRLG
A shared risk link group (SRLG) is a set of links which are likely to fail concurrently due
to sharing a physical resource. Links in the group have a shared risk. If one of the links
fails, other links in the group may fail too.
In MPLS TE, SRLG is a feature that enhances path reliability for a hot-standby tunnel or
TE FRR tunnel. Two or more links may run the same risk when they share common physical
resources. For example, sub-interfaces share the risk with their main interface. A sub-
interface definitely goes down if its main interface goes down. If the backup or bypass
tunnel goes through a link which shares the same risk with the primary tunnel, the possibility
of backup tunnel going down along with the primary tunnel is high.
l Hop limit
Hop limit is a rule for path selection for setting up a CR-LSP. It limits the number of hops
that a CR-LSP allows.
l Re-optimization
Dynamically optimizing a CR-LSP is to periodically recompute routes for the CR-LSP. If
the route in recomputation is better than the route in use, then a new CR-LSP is established
based on the recomputed route. Meanwhile, services are switched from the old CR-LSP to
the new CR-LSP, and the old one is deleted.
l Isolated LSP computation
To improve the LSP reliability on a network that has the CR-LSP hot standby feature, you
can configure the isolated LSP computation feature so that the device uses both the disjoint
algorithm and the CSPF algorithm to compute isolated primary and hot-standby LSPs.
The configuration tasks described in this section are some special configurations for CSPF in
MPLS TE. Before performing these configuration tasks, understand their influences on the
system.
Before adjusting the selection of the CR-LSP, configure an RSVP-TE tunnel.
Data Preparation
To adjust the selection of the CR-LSP, you need the following data.
No. Data
1 Tie-breaking policy for the nodes and tunnel
2 Administrative group of links and affinity property of tunnels
3 Re-optimization interval of CR-LSPs
4 SRLG number and SRLG path calculation mode (preferred or strict)
5 Value of the failed link timer

3.12.2 Configuring Administrative Group and Affinity Property

This section describes how to configure the administrative group and affinity. The administrative
group affects only LSPs to be set up, and the affinity affects established LSPs by recalculating
the paths.
Context
Perform the following steps on the ingress of a CR-LSP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The interface view of the MPLS-TE-enabled interface is displayed.
Step 3 Run:
mpls te link administrative group value
The administrative group of the MPLS TE link is configured.
Step 4 Run:
quit
Step 5 Run:
The tunnel interface view of the MPLS TE tunnel is displayed.
Step 6 Run:
mpls te affinity property properties [ mask mask-value ] [ best-effort |
secondary ]
The affinity for the tunnel is configured.
By default, the values of administrative group, affinity, and mask are all 0x0.
Step 7 Run:
mpls te commit
----End
Follow-up Procedure
The modification of administrative group takes effect only on LSPs that are established after
modification.

After the modified affinity is committed, the established LSP in this tunnel may be affected, and
the system recalculates the path for the TE tunnel.
3.12.3 Configuring SRLG

In the networking scenario where the hot standby CR-LSP is set up or TE FRR is enabled,
configure the SRLG attribute on the outgoing tunnel interface of the ingress and the other
member links of the SRLG to which the outgoing interface belongs.
Context
Configuring Shared Risk Link Group (SRLG) includes:
l Configuring SRLG for the link

l Configuring SRLG path calculation mode for the tunnel
l Deleting the member interfaces of all SRLGs
Procedure
l Configuring SRLG for the link
Perform the following steps on the links which are in the same SRLG.
1. Run:
system-view

2. Run:

3. Run:
mpls te srlg srlg-number
The interface is configured as an SRLG member.
On a network with hot standby or TE FRR, the SRLG attribute can be configured for
the tunnel outbound interface of the ingress and other members of the SRLG to which
the outbound interface belongs. A link joins an SRLG after the SRLG attribute is
configured on an outbound interface of the link.
l Configuring SRLG path calculation mode for the tunnel
Perform the following steps on the ingress node of the hot-standby tunnel or the TE FRR
tunnel.
1. Run:
system-view

2. Run:
mpls

3. Run:

mpls te srlg path-calculation [ preferred | strict ]
The SRLG path calculation mode is configured.
NOTE
l If you specify the strict keyword, the CSPF always considers the SRLG as a constraint
when calculating the path for the bypass CR-LSP or the backup CR-LSP.
l If you specify the preferred keyword, CSPF tries to calculate the path which avoids the
links in the same SRLG as protected interfaces; if the calculation fails, CSPF does not
consider the SRLG as a constraint anymore.
l Delete the member interfaces of all SRLGs.
Perform the following steps to delete the member interfaces of all SRLGs from an MPLS
TE node:
1. Run:
system-view

2. Run:
mpls

3. Run:
undo mpls te srlg all-config
The member interfaces of all SRLGs are deleted from the MPLS TE node.
NOTE
The undo mpls te srlg all-config does not delete an SRLG-based path calculation mode
configured in the mpls te srlg path-calculation command in the MPLS view.
----End
3.12.4 Configuring CR-LSP Hop Limit

This section describes how to configure the CR-LSP hop limit. Similar to the administrative
group and the affinity, the hop limit is a condition for CR-LSP path selection and is used to
specify the number of hops along a CR-LSP to be set up.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
mpls te hop-limit hop-limit-value [ best-effort | secondary ]
The number of hops along the CR-LSP is set. The hop-limit-value is an integer ranging from 1
to 32.
NOTE
If the mpls te hop-limit command is not configured, the maximum number of hops supported by a CR-LSP is
64.
Step 4 Run:
mpls te commit
----End
3.12.5 Configuring Metrics for Path Calculation

This section describes who to configure the metric for path calculation. You can configure the
metric type that is used to set up a tunnel.
Procedure
l Specify the metric type used by a tunnel.
Perform the following steps on the ingress along a CR-LSP:
1. Run:
system-view

2. Run:

3. Run:
mpls te path metric-type { igp | te }
The metric type for path computation is configured.

4. Run:
mpls te commit
The current configuration of the tunnel is committed.

5. Run:
quit

6. (Optional) Run:
mpls

7. (Optional) Run:
mpls te path metric-type { igp | te }
The path metric type used by the tunnel during route selection is specified.

If the mpls te path metric-type command is not run in the tunnel interface view, the
metric type in the MPLS view is used; otherwise, the metric type in the tunnel interface
view is used.
By default, path metric type used by the tunnel during route selection is TE.
l (Optional) Configure the TE metric value of the path.
If the metric type of a specified tunnel is TE, you can modify the TE metric value of the
path on the outbound interface of the ingress and the transit node.
1. Run:
system-view

2. Run:
The view of the MPLS-TE-enabled interface is displayed.

3. Run:
mpls te metric value
The TE metric value of the path is set.

By default, the path uses the IGP metric value as the TE metric value.
NOTE
If OSPF is used as an IGP and the current device is a stub router, the mpls te metric command
does not take effect.
----End
3.12.6 Configuring Tie-Breaking of CSPF

This section describes how to configure CSPF tie breaking to select a path from multiple paths
with the same weight value.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls te tie-breaking { least-fill | most-fill | random }
A CR-LSP tie-breaking policy for the LSR is configured.

Tie-breaking policies can be classified as:
l least-fill: selects the route with the smallest ratio of the occupied available bandwidth to the
maximum reservable bandwidth.
l most-fill: selects the route with the largest ratio of the occupied available bandwidth to the
maximum reservable bandwidth.
l random: selects a route randomly.
The default tie-breaking policy is random.
NOTE
The maximum reservable bandwidth is the bandwidth configured using the mpls te bandwidth max-
reservable-bandwidth command.
Step 4 Run:
quit
Step 5 Run:
Step 6 Run:
mpls te tie-breaking { least-fill | most-fill | random }
The CR-LSP tie-breaking policy for current tunnel is configured.
The parameters have the same functions as those used in step 3.
Step 7 Run:
mpls te commit
NOTE
The tunnel preferentially takes the tie-breaking policy configured in its tunnel interface view. If the tie-
breaking policy is not configured in the tunnel interface view, the configuration in the MPLS view is used.
----End
3.12.7 Configuring Failed Link Timer

This section describes how to configure a failed link timer, which helps prevent a failed link
from repeatedly participating in CSPF calculation.
Context
CSPF uses a locally maintained traffic-engineering database (TEDB) to calculate the shortest
path to the destination address. A signaling protocol applies for and reserves resources for the
path. If a link on a network fails, and the routing protocol fails to instruct CSPF to update the
TEDB, the path calculated by CSPF contain the faulty link.
As a result, the control packets, such as RSVP Path messages, of a signaling protocol are
discarded on the faulty link. Then, the signaling protocol returns an error message to the upstream

node. Receiving the link error message on the upstream node triggers CSPF to recalculate a path.
The path recalculated by CSPF and returned to the signaling protocol still contains the faulty
link because the TEDB is not updated. The control packets of the signaling protocol are still
discarded, and the signaling protocol returns an error message to instruct CSPF to recalculate a
path. The procedure repeats until the TEDB is updated.
To prevent the preceding situation, when the signaling protocol returns an error message to notify
CSPF of a link failure, CSPF sets the status of the faulty link to INACTIVE and enables a failed
link timer. Then, CSPF does not use the faulty link in path calculation until CSPF receives a
TEDB update event notification or the failed link timer expires.
Before the failed link timer expires, if a TEDB update event is received, CSPF deletes the failed
link timer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te cspf timer failed-link interval
The failed link timer is configured.
By default, the failed link timer is 10 seconds.
The failed link timer is a local configuration. If the failed link timers of nodes are set to different
values, a failed link that is in ACTIVE state on one node may be in INACTIVE state on other
nodes.
----End
3.12.8 Configuring Loop Detection

This section describes how to configure loop detection to prevent loops.
Context
In the loop detection mechanism, a maximum number of 32 hops are allowed on an LSP. If
information about the local LSR is recorded in the path information table, or the number of hops
on the path exceeds 32, a loop occurs, and the LSP fails to be set up.
Procedure
Step 1 Run:

system-view
Step 2 Run:
Step 3 Run:
mpls te loop-detection
Loop detection for tunnel creation is enabled.
By default, loop detection is disabled.
Step 4 Run:
mpls te commit
----End
3.12.9 Configuring Route Pinning

This section describes how to configure route pinning to establish a CR-LSP over the path that
is originally selected, not another eligible path.
Context
By default, route pinning is disabled.
NOTE
If route pinning is enabled, MPLS TE re-optimization cannot be used at the same time.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls te record-route [ label ]
Route record and label record are enabled.
Step 4 Run:
mpls te route-pinning
Route pinning is enabled.

Step 5 Run:
mpls te commit
----End
3.12.10 Configuring Isolated LSP Computation

To improve the label switched path (LSP) reliability on a network that has the constraint-based
routed label switched path (CR-LSP) hot standby feature, you can configure the isolated LSP
computation feature, so that the device uses both the disjoint algorithm and the constrained
shortest path first (CSPF) algorithm to compute isolated primary and hot-standby LSPs.
Context
Most IP radio access networks (IP RANs) that use Multiprotocol Label Switching (MPLS) TE
have high reliability requirements for LSPs. The CSPF algorithm does not meet this reliability
requirement because CSPF is a metric-based path computing algorithm that may compute two
intersecting LSPs.
Specifying explicit paths can meet this reliability requirement; this method, however, does not
adapt to topology changes. Each time a node is added to or deleted from the IP RAN, operators
must configure new explicit paths, which is time-consuming and laborious.
To resolve these problems, you can configure isolated LSP computation. After this feature is
enabled, the disjoint and CSPF algorithms work together to compute primary and hot-standby
LSPs at the same time and cut off crossover paths of the two LSPs. Then, the device gets the
isolated primary and hot-standby LSPs.
NOTE
l Isolated LSP computation is a best-effort technique. If the disjoint and CSPF algorithms cannot get
isolated primary and hot-standby LSPs or two isolated LSPs do not exist, the device uses the primary
and hot-standby LSPs computed by CSPF.
l The disjoint algorithm cannot work together with the following features: explicit path, affinity property,
hop limit, CR-LSP attribute template, and automatic bandwidth adjustment. Therefore, before you
configure the disjoint algorithm, check that all those features are disabled. Otherwise, the device does
not allow you to configure the disjoint algorithm. After you configure the disjoint algorithm, the device
does not allow you to configure any of those features.
l After you enable the disjoint algorithm, the Shared Risk Link Group (SRLG), if configured, becomes
ineffective.
l Isolated LSP computation requires the collaboration of the CR-LSP hot standby feature and requires
the hot-standby LSP to have the same reserved bandwidth as the primary LSP.
Perform the following steps on the ingress of the RSVP-TE tunnel:
Procedure
Step 1 Run:
system-view

Step 2 Run:

The TE tunnel interface view is displayed.
Step 3 Run:
mpls te cspf disjoint
The disjoint algorithm is enabled.
Step 4 Run:
mpls te commit
----End

After the adjustment of CR-LSP path selection, you can view the status of the CSPF tie-breaking
function, status of the route pinning function, interval at which a CR-LSP is optimized, and
affinity and its mask. You can also check the computed primary and hot-standby LSPs after the
disjoint algorithm is enabled.
Prerequisites
All configurations of adjusting the patch for a CR-LSP are complete.
Procedure
Step 1 Run the display mpls te tunnel verbose command to check information about the MPLS TE
tunnel.
Step 2 Run the display mpls te cspf destination ip-address computation-mode disjoint command to
check the computed primary and hot-standby LSPs after the disjoint algorithm is enabled.
----End
Example
If the configuration is successful, run display mpls te tunnel verbose command to view the
affinity values.
Run the display mpls te cspf destination ip-address computation-mode disjoint command to
view the computed primary and hot-standby LSPs after the disjoint algorithm is enabled.
[HUAWEI] display mpls te cspf destination 6.6.6.6 computation-mode disjoint
Main path for the given constraints is:
1.1.1.1 Include LSR-ID
2.1.0.1 Include
2.1.0.2 Include
4.2.0.2 Include
4.2.0.4 Include
4.6.0.4 Include
4.6.0.6 Include
The total metrics of the calculated path is : 3
Hot-standby path for the given constraints is:


1.3.0.1 Include
1.3.0.3 Include
3.5.0.3 Include
3.5.0.5 Include
5.6.0.5 Include
5.6.0.6 Include
Complete disjoint path computed and the total metrics of the calculated path is
: 16
3.13 Adjusting the Establishment of MPLS TE Tunnels

This section describes how to adjust the establishment of an MPLS TE tunnel. You can configure
multiple attributes of the MPLS TE tunnel to adjust parameters during the establishment of the
MPLS TE tunnel.

Before adjusting the establishment of an MPLS TE tunnel, familiarize yourself with the usage
Usage Scenario
During the establishment of an MPLS TE tunnel, specific configurations are required in the
practical application. This section describes the special configuration.
Note that tasks introduced in this section are of special MPLS TE configurations. Before
performing these configuration tasks, you must know their influences on the system.
Before adjusting the establishment of the MPLS TE tunnel, configure an RSVP-TE tunnel.
Data Preparation
To adjust the establishment of the MPLS TE tunnel, you need the following data.
No. Data
1 Number of attempts to reestablish a tunnel and the reestablishment interval
2 Setup priority and holding priority of tunnels
3.13.2 Configuring the Tunnel Priority

This section describes how to configure a tunnel priority. In the process of establishing a CR-
LSP, if no path with the required bandwidth exists, you can perform bandwidth preemption based
on the setup and holding priorities.

Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls te priority setup-priority [ hold-priority ]
The priority for the tunnel is configured.
Both the setup priority and the holding priority range from 0 to 7. The smaller the value is, the
higher the priority is.
By default, both the setup and holding priorities are 7. If only the setup priority value is set, the
holding priority value is the same as the setup priority value.
NOTE
The setup priority must not be higher than the holding priority. Therefore, the value of the setup priority
must not be less than that of the holding priority.
Step 4 Run:
mpls te commit
----End
3.13.3 Configuring Re-optimization for CR-LSP

This section describes how to configure the tunnel re-optimization function for a CR-LSP. This
function enables a device to periodically recompute routes for a CR-LSP. If the recomputed
routes are better than the routes in use, a new CR-LSP is then established over the recomputed
routes. In addition, services are switched to the new CR-LSP, and the previous CR-LSP is torn
down.
Context
NOTE
l If re-optimization is enabled, the route pinning cannot be used at the same time.
l CR-LSP re-optimization cannot be configured when the resource reservation style is fixed filter (FF).

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls te reoptimization [ frequency interval ]
Periodic re-optimization is enabled.
By default, re-optimization is disabled. The default periodic re-optimization interval is 3600

seconds.
Step 4 Run:
mpls te commit
Step 5 Run:
return
Back to the user view.

mpls te reoptimization
Manual re-optimization is enabled.
After you configure automatic re-optimization in the tunnel interface view, return to the user
view and run the mpls te reoptimization command to attempt to immediately use better path
to reestablish the tunnels on which automatic re-optimization is enabled. After you perform
manual re-optimization, the timer of the automatic re-optimization is reset and starts to count
again.

mpls te reoptimization [ tunnel tunnel-interface ]
After you configure the automatic re-optimization in the tunnel interface view, return to the user
view and run the mpls te reoptimization command to attempt to immediately use better path
to reestablish all tunnels or the specified tunnel on which automatic re-optimization is enabled.
After you perform manual re-optimization, the timer of the automatic re-optimization is reset
and starts to count again.
----End

3.13.4 Associating CR-LSP Establishment with the Overload

Setting
CR-LSP establishment can be associated with the overload setting. This association ensures that
CR-LSPs are established over paths excluding overloaded nodes.
Context
A node becomes overloaded in the following situations:
l When the node is transmitting a large number of services and its system resources are
exhausted, the node marks itself overloaded.
l When the node is transmitting a large number of services and its CPU is overburdened, an
administrator can run the set-overload command to mark the node overloaded.
If there are overloaded nodes on an MPLS TE network, associate CR-LSP establishment with
the IS-IS overload setting to ensure that CR-LSPs are established over paths excluding
overloaded nodes. This configuration prevents overloaded nodes from being further burdened
and improves CR-LSP reliability.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te path-selection overload
CR-LSP establishment is associated with the IS-IS overload setting. This association allows
CSPF to calculate paths excluding overloaded IS-IS nodes.
NOTE
Before the association is configured, the mpls te cspf command must be run to enable CSPF and the mpls
te record-route command must be run to enable the route and label record.
Traffic travels through an existing CR-LSP before a new CR-LSP is established. After the new CR-LSP
is established, traffic switches to the new CR-LSP and the original CR-LSP is deleted. This traffic
switchover is performed based on the make-before-break mechanism. Traffic is not dropped during the
switchover.
The mpls te path-selection overload command has the following influences on the CR-LSP
establishment:
l CSPF recalculates paths excluding overloaded nodes for established CR-LSPs.
l CSPF calculates paths excluding overloaded nodes for new CR-LSPs.

NOTE
This command does not take effect on bypass tunnels.

If the ingress or egress is marked overloaded, the mpls te path-selection overload command does not take
effect. The established CR-LSPs associated with the ingress or egress will not be reestablished and new
CR-LSPs associated with the ingress or egress will also not be established.
----End
3.13.5 Configuring Tunnel Reestablishment Parameters

This section describes how to configure tunnel reestablishment parameters to enable a device to
periodically recompute the route for a CR-LSP. If the route in recomputation is better than the
route in use, a new CR-LSP is then established over the recomputed route. In addition, services
are switched to the new CR-LSP, and the previous CR-LSP is torn down.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls te retry times
The maximum number of attempts to reestablish a tunnel is specified.
By default, the maximum number of attempts is 5.
Step 4 Run:
mpls te timer retry interval
The interval for reestablishing a tunnel is specified.
By default, the interval at which a tunnel is reestablished is 30 seconds.
Step 5 Run:
mpls te commit
If the establishment of a tunnel fails, the system attempts to reestablish the tunnel at the set
interval, and the maximum number of attempts is the set reestablishment times.
----End

3.13.6 Configuring Route Record and Label Record

This section describes how to configure the route record and label record. The route record and
label record functions enable nodes to record routes and labels during the establishment of an
RSVP-TE tunnel.
Context
By default, routes and labels are not recorded.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mpls te record-route [ label ]
The route and label are recorded for an MPLS TE tunnel to be established.
Step 4 Run:
mpls te commit
----End
3.13.7 Configuring the RSVP Signaling Delay-Trigger Function

In the case that a fault occurs on an MPLS network, a great number of RSVP CR-LSPs need to
be reestablished. This causes consumption of a large number of system resources. By configuring
the delay for triggering the RSVP signaling, you can reduce the consumption of system resources
when establishing an RSVP CR-LSP.
Context
Perform the following steps on each node on which multiple CR-LSPs need to be reestablished:
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls te signaling-delay-trigger enable
The RSVP signaling delay-trigger function is enabled.
By default, the RSVP signaling delay-trigger function is not enabled.
----End

After adjusting the establishment of an MPLS TE tunnel, you can view the TE tunnel attributes.
Prerequisites
All configurations of adjusting the establishment of an MPLS TE tunnel are complete.
Procedure
Step 1 Run the display mpls te tunnel-interface [ tunnel interface-number ] command to view
information about the tunnel interface.
----End
Example
If the configurations are successful, run the preceding commands to view the following
information:
l The route record and label record of the tunnel are enabled.
l The times and interval of tunnel reestablishment attempts are displayed.
l The tunnel setup priority and holding priority are displayed.
3.14 Importing Traffic to an MPLS TE Tunnel

This section describes how to importing traffic to an MPLS TE tunnel. An MPLS TE tunnel
does not automatically import traffic. A method must be used to import traffic to the MPLS TE
tunnel before traffic can travel along an MPLS TE tunnel.

Before importing traffic to an MPLS TE tunnel, familiarize yourself with the usage scenario,
Usage Scenario
An MPLS TE tunnel does not automatically import traffic. To enable traffic to travel along an
MPLS TE tunnel, use one of the following methods to import the traffic to the MPLS TE tunnel:

l Use static routes. This is the simplest method for importing the traffic to an MPLS TE
tunnel. You only need to configure a static route with a TE tunnel interface as the outbound
interface.
l Use TE policy-based routing (PBR). MPLS TE PBR, the same as IP unicast PBR, is
implemented based on a set of matching rules and behaviors. The rules and behaviors are
defined using an apply clause, in which a specific tunnel interface is used as the outbound
interface. If packets do not match PBR rules, they are forwarded using IP. If packets match
PBR rules, they are forwarded over specific TE tunnels.
For details on how to configure IP unicast PBR, see Class-Based QoS Configuration in the
NE80E/40E Configuration Guide - QoS.
l Use the auto route mechanism. A TE tunnel is used as a logical link for IGP route
calculation. A tunnel interface is used as an outbound interface of a route. The auto route
mechanism can be implemented in either of the following modes:
– IGP shortcut: A device uses a TE tunnel for local route calculation and does not advertise
the TE tunnel to its peers as a route. Therefore, the peers of this device cannot use the
TE tunnel for route calculation.
– Forwarding adjacency: A device uses a TE tunnel for local route calculation and
advertises the TE tunnel to its peers as a route. Therefore, the peers of this device can
use the TE tunnel for route calculation.
To prevent packet loss during MPLS TE tunnel reestablishment, configure the tunnel switching
and deletion delays on the ingress of an MPLS TE tunnel.
Before you import traffic to an MPLS TE tunnel, configure a Resource Reservation Protocol
(RSVP)-TE tunnel (For details on how to configure an RSVP TE tunnel, see Configuring an
RSVP-TE Tunnel).
Data Preparation
To import traffic to an MPLS TE tunnel, you need the following data.
No. Data
1 Number of an MPLS TE tunnel interface
3 IGP metric of an MPLS TE tunnel
4 MPLS TE tunnel switching and deletion delays
3.14.2 Configuring IGP Shortcut

This section describes how to configure the IGP shortcut, which helps prevent a route to an LSP
from being advertised to neighbor nodes so that the neighbor nodes cannot use this LSP.

Context
NOTE
The IGP shortcut and the forwarding adjacency cannot be used together.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The interface view of the MPLS TE tunnel is displayed.
Step 3 Run:
mpls te igp shortcut [ isis | ospf ]
The IGP shortcut is configured.
NOTE
By default, the IGP shortcut is not configured.

If the IGP type is not specified when the IGP shortcut is configured, both IS-IS and OSPF are supported
by default.
Step 4 Run:
By default, the metric value used by the TE tunnel is the same as that of the IGP.
You can specify a metric value used by the TE tunnel when path is calculated in the IGP shortcut
feature.
l If the absolute metric is used, the metric used by the TE tunnel is equal to the configured
metric value.
l If the relative metric is used, the metric used by the TE tunnel is equal to the sum of the
metric value of the corresponding IGP path and relative metric value.
Step 5 Run:
mpls te commit
The current TE tunnel configuration is committed.
Step 6 You can select either of the following modes to configure the IGP shortcut.
l For IS-IS, run:



3. Run the enable traffic-adjustment command to configure OSPF IGP shortcut.
----End
3.14.3 Configuring Forwarding Adjacency

This section describes how to configure the forwarding adjacency to advertise a route of an LSP
to neighbor nodes so that the neighbor nodes can use this LSP.
Context
The routing protocol performs bidirectional detection on a link. When using the forwarding
adjacency to advertise LSP links to other nodes, configure another tunnel for transferring data
packets in the reverse direction. Then, enable the forwarding adjacency on these two tunnels.
NOTE
By default, the forwarding adjacency is disabled.

If the forwarding adjacency is used, the IGP shortcut cannot be used at the same time.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls te igp advertise [ hold-time interval ]
The forwarding adjacency is enabled.
Step 4 Run:
NOTE
The IGP metric value must be set properly to ensure that the LSP is advertised and used correctly. For
example, the metric of a TE tunnel must be less than that of IGP routes to ensure that the TE tunnel is used
as a route link.
Step 5 Run:
mpls te commit
Step 6 You can select either of the following modes to enable the forwarding adjacency.

l For IS-IS, run:


3. Run the enable traffic-adjustment advertise command to enable the forwarding
adjacency.
----End
3.14.4 Configuring Switching Delay and Deletion Delay

This section describes how to configure the switching delay and deletion delay, which ensures
that an original CR-LSP can be deleted only after a new CR-LSP is set up. Theses settings help
prevent traffic interruptions.
Context
MPLS TE uses a make-before-break mechanism. When attributes of an MPLS TE tunnel, such
as bandwidth and path, change, a new CR-LSP with new attributes must be established. The
new CR-LSP is also called Modified LSP. To prevent data loss during traffic switching, the new
CR-LSP must be established before the original CR-LSP is torn down. With the make-before-
break mechanism, the system does not need to calculate the bandwidth to be reserved for the
new CR-LSP. The new CR-LSP shares the bandwidth with the original CR-LSP.
In practical applications, if the upstream nodes are not as busy as the downstream nodes, the
original CR-LSP may be torn down in advance, which causes temporary traffic interruptions.
To prevent this problem, configure the switch delay and deletion delay on the ingress of the
tunnel.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls te switch-delay switch-time delete-delay delete-time
The switching delay and deletion delay are configured.

By default, the switching delay is 5 seconds, and the deletion delay is 7 seconds.
----End


After you import traffic to a Multiprotocol Label Switching (MPLS) traffic engineering (TE)
tunnel, check traffic forwarding information.
Prerequisites
Traffic has been imported to an MPLS TE tunnel.
Procedure
Step 1 Run the display current-configuration command to check the configuration for importing
traffic to an MPLS TE tunnel.
Step 2 Run the display ip routing-table command to check the routes with an MPLS TE tunnel
interface as the outbound interface.
----End
Example
Run the display current-configuration command to view the configuration for importing traffic
to an MPLS TE tunnel. The command output contains the following information:
l IGP metric of the MPLS TE tunnel

l MPLS TE tunnel switching and deletion delays
Run the display ip routing-table command to view the routes with an MPLS TE tunnel interface
as the outbound interface.
<HUAWEI> display ip routing-table
------------------------------------------------------------------------------

2.2.2.2/32 ISIS-L2 15 10 D 10.1.1.2
GigabitEthernet1/0/0
3.3.3.3/32 ISIS-L2 15 15 D 10.1.2.2
4.4.4.4/32 ISIS-L2 15 10 D 1.1.1.1 Tunnel1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Ethernet1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1
10.1.2.1/32 Direct 0 0 D 127.0.0.1
10.1.3.0/24 ISIS-L2 15 20 D 10.1.1.2
ISIS-L2 15 20 D 1.1.1.1
10.1.4.0/24 ISIS-L2 15 20 D 1.1.1.1

3.15 Adjusting Flooding Threshold of Bandwidth Change

By adjusting the flooding threshold of the bandwidth change, you can suppress the frequency
of TEDB update and flooding, which minimizes network resource consumption.

Before adjusting the flooding threshold of the bandwidth change, familiarize yourself with the
configuration.
Usage Scenario
To form a uniform TE database in an IGP domain, OSPF-TE and ISIS-TE need to be enabled
to update and flood information about the traffic engineering database (TEDB) when the
remaining bandwidth changes on the MPLS interface.
When a number of tunnels that need reservable bandwidth are set up on a node, the system
frequently updates and floods information about the TEDB. For example, suppose that the
bandwidth of a certain link is 100 Mbit/s. When 100 TE tunnels whose bandwidth is 1 Mbit/s
are set up, the flooding is performed for 100 times.
The system provides the following mechanism to suppress the frequency of TEDB update and
flooding.
l When the ratio of the reserved bandwidth for an MPLS TE tunnel on a link to the remaining
bandwidth of the link in the TEDB is equal to or greater than the set threshold (that is, flood
threshold of the bandwidth), OSPF TE and IS-IS TE flood the link information to all the
nodes within the domain and update the TEDB.
l When the ratio of the released bandwidth of the MPLS TE tunnel on a link to the remaining
bandwidth of the link in the TEDB is equal to or greater than the set threshold, OSPF TE
and IS-IS TE flood the link information to all the nodes within the domain and update the
TEDB.
By default, the flood threshold is 10%. Its value can be modified through command lines.
Before adjusting the flood threshold of the bandwidth, configure an RSVP-TE tunnel.
Data Preparation
To adjust the flood threshold of the bandwidth, you need the following data.
No. Data
1 Flood threshold of the bandwidth

3.15.2 Configuring Flooding Threshold

This section describes how to configure the flooding threshold. The bandwidth flooding
threshold indicates the ratio of the link bandwidth used or released by a TE tunnel to the link
bandwidth remaining in the TEDB.
Context
The bandwidth flooding threshold is the ratio of the link bandwidth used or released by a TE
tunnel to the link bandwidth remained in the TEDB.
If the link bandwidth changes little, bandwidth flooding wastes network resources. For example,
if link bandwidth is 100 Mbit/s and 100 TE tunnels (with bandwidth as 1 Mbit/s) are created
along this link, bandwidth flooding needs to be performed for 100 times.
If the flooding threshold is set to 10%, bandwidth flooding is not performed when tunnels 1 to
9 are created. When tunnel 10 is created, the bandwidth of tunnels 1 to 10 (10 Mbit/s in total) is
flooded. Similarly, bandwidth flooding is not performed when tunnels 11 to 18 are created. When
tunnel 19 is created, the bandwidth of tunnels 11 to 19 is flooded. Therefore, configuring the
bandwidth flooding threshold can reduce the times of bandwidth flooding and ensure the efficient
use of network resources.
By default, on a link, IGP floods information about this link, and CSPF updates the TEDB if
one of the following conditions is met:
l The ratio of the bandwidth reserved for an MPLS TE tunnel to the bandwidth remaining
in the TEDB is equal to or higher than 10%.
l The ratio of the bandwidth released by an MPLS TE tunnel to the bandwidth remaining in
the TEDB is equal to or higher than 10%.
Perform the following steps on the ingress or transit node along a CR-LSP tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the MPLS-TE-enabled interface is displayed.
Step 3 Run:
mpls te bandwidth change thresholds { down | up } percent
The threshold of bandwidth flooding is set.
----End

After adjusting flooding threshold of bandwidth change, you can view the information about the
flooding threshold of bandwidth.

Prerequisites
The flooding threshold of bandwidth change has been adjusted.
Procedure
Step 1 Run the display current-configuration command to view information about the flooding
threshold of bandwidth.
----End
Example
If the configurations are successful, run the preceding commands to view the following items:
l The flooding threshold of bandwidth.
3.16 Configuring Automatic Adjustment of the Tunnel

Bandwidth
By being enabled with the automatic bandwidth adjustment, the system can adjust the bandwidth
of a tunnel automatically according to the actual traffic volume.

Before configuring the automatic bandwidth adjustment, familiarize yourself with the usage
Usage Scenario
When the automatic bandwidth adjustment is enabled, the bandwidth of the tunnel can be
automatically adjusted according to traffic.
The system periodically collects the traffic rates of outgoing interfaces on the tunnel and
calculates the average bandwidth of the tunnel within a period of time. The establishment of an
LSP is requested according to the bandwidth constraint of the sampled maximum value of
average bandwidth. After the LSP is set up, the old LSP is torn down through the make-before-
break feature and the traffic is switched to the new LSP.
Before configuring the bandwidth automatic adjustment, configure an RSVP-TE tunnel.
Data Preparation
To configure the automatic adjustment of the tunnel bandwidth, you need the following data.
No. Data
1 Sampling interval

No. Data
2 Interval for automatic bandwidth adjustment
3 Allowable maximum bandwidth
4 Allowable minimum bandwidth
3.16.2 Configuring Auto Bandwidth Adjustment

This section describes how to configure auto bandwidth adjustment. If automatic bandwidth
adjustment is enabled, the CR-LSP re-optimization or route pinning cannot be configured.
Context
By default, automatic bandwidth adjustment is disabled.
The sampling interval is configured in the MPLS view, and is valid for all MPLS TE tunnels.
The rate of the outbound interface on an MPLS TE tunnel is recorded at each sampling interval.
The actual average bandwidth allocated to the MPLS TE tunnel in a sampling interval can be
obtained.
After automatic bandwidth adjustment is enabled, running the mpls te timer auto-bandwidth
command to configure periodic sampling to help the system obtain the average bandwidth of
the MPLS TE tunnel during a sampling interval. The system recalculates an average bandwidth
based on sampling during a sampling interval and uses the bandwidth to establish an MPLS TE
tunnel. After the MPLS TE tunnel is established, traffic switches to the new MPLS TE tunnel,
and the original MPLS TE tunnel is torn down. If the MPLS TE tunnel fails to be established,
traffic is still being transmitted along the original MPLS TE tunnel. The bandwidth will be
adjusted after the next sampling interval expires.
Configuring threshold controls whether to adjust the bandwidth of an MPLS TE tunnel.
The system checks whether the difference between the sampled average bandwidth and the actual
bandwidth if the ratio of the difference to the actual bandwidth is greater than the threshold
value. If the difference is greater than or equal to the threshold value, the system automatically
adjusts the bandwidth.
If the traffic volume changes frequently on a network but the bandwidth does not need to be
adjusted, set the threshold value to a large value.
NOTE
The mpls te auto-bandwidth command cannot be configured together with any of the following commands
on one tunnel interface:
l mpls te route-pinning
l mpls te resv-style ff
l mpls te bandwidth (tunnel interface view) with the multi-CT specified

Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te timer auto-bandwidth [ interval ]
The automatic bandwidth adjustment is enabled, and the sampling interval is specified.
By default, the system automatically adjusts bandwidth every 24 hours, and bandwidth range is
not restricted unless interval is specified.
Step 4 Run:
quit
Step 5 Run:
Step 6 To configure automatic bandwidth adjustment, run either of the following commands.
l To configure the frequency and allowable bandwidth range for adjustment, run:
mpls te auto-bandwidth adjustment [ threshold percent ] [ frequency interval ]
[ max-bw max-bandwidth min-bw min-bandwidth ]
l To configure the frequency and allowable bandwidth range for collection, run:
mpls te auto-bandwidth collect-bw [ frequency interval ] [ max-bw max-bandwidth
min-bw min-bandwidth ]
Step 7 Run:
mpls te commit
----End

After the configuration of the automatic bandwidth adjustment, you can view information about
the bandwidth of a TE tunnel.
Prerequisites
All configurations of the automatic adjustment of the tunnel bandwidth are complete.

Procedure
Step 1 Run the display current-configuration command to check configuration information about
automatic adjustment of the tunnel bandwidth.
----End
Example
After the configuration is successful, run the display current-configuration command on the
ingress of the tunnel to view the following configuration information about the tunnel.
l Automatically-adjusted frequency
l Minimum bandwidth that can be adjusted
l Maximum bandwidth that can be adjusted
3.17 Configuring the Limit Rate of MPLS TE Traffic

This section describes how to configure the limit rate of MPLS TE traffic to limit TE tunnel
traffic within the bandwidth range that is actually configured.

Before setting a limit rate for the TE tunnel traffic, familiarize yourself with the usage scenario,
Usage Scenario
For a physical link of a TE tunnel, besides traffic on the TE tunnel, the physical link may bear
MPLS traffic of other TE tunnels, MPLS traffic of other non-CR-LSPs, or even IP traffic
simultaneously. To limit the TE tunnel traffic within a bandwidth range that is actually
configured, set a limit rate for TE tunnel traffic.
After the configuration of the limit rate, TE traffic is limited to a bandwidth range that is actually
configured. TE traffic with the bandwidth higher than the set bandwidth is dropped.
Before configuring the limit rate of MPLS TE traffic, configure a static CR-LSP or an RSVP-
TE tunnel.
Data Preparation
To configure the limit rate of MPLS TE traffic, you need the following data.
No. Data
1 Interface number of the TE tunnel on which the traffic rate is to be limited

3.17.2 Configuring the Limit Rate of MPLS TE Traffic

This section describes how to set the limit rate of MPLS TE traffic. Before you set a limit rate
for MPLS TE traffic, you must configure the bandwidth of the tunnel interfaces.
Context
NOTE
Before you configure the limit rate of MPLS TE traffic, run the mpls te bandwidth command on a tunnel
interface. If this command is not run, the limit rate of MPLS TE traffic is unavailable.
Perform the following steps on the ingress of a tunnel:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mpls te lsp-tp outbound
The TE traffic policing is configured.

Step 4 Run:
mpls te commit
----End

After the configuration of a limit rate for MPLS TE traffic, you can view information about the
TE traffic policing.
Prerequisites
The limit rate of MPLS TE traffic function has been configured.
Procedure
l Run the display mpls te tunnel-interface [ tunnel interface-number ] command to check
information about the tunnel interface.
----End
Example
Run the display mpls te tunnel-interface command. The CAR policy is enabled.

3.18 Configuring DS-TE Tunnel

By integrating traditional TE tunnels with DiffServ models, DS-TE can provide QoS according
to specific service types.

Before configuring DS-TE, familiarize yourself with the usage scenario, complete the pre-
Usage Scenario
MPLS TE tunnel application may have the following four scenarios:
l One TE tunnel bears all types (such as, video, voice, and data) of non-VPN services.
l One TE tunnel bears different types of services of a VPN.
l One TE tunnel bears different types of different VPN services.
l One TE tunnel bears different types of VPN and non-VPN services.
MPLS TE tunnel without Diff-Serv (Differentiated Services) cannot provide the QoS according
to each traffic type. For example, voice flow and video flow are transmitted over a TE tunnel.
The video data frames may be transmitted more repeatedly than the voice flow. The video data
requires a higher drop precedence than the voice data. The MPLS TE tunnel, however, allocates
the same drop precedence for voice and video flows irrespective of traffic types.
To prevent service interference in one tunnel, you can set up a TE tunnel for each type of each
VPN or non-VPN service. This scheme may waste resources because multiple tunnels need to
be set up if there are large numbers of VPNs bearing different types of services over the network.
In the above listed scenarios, deployment of DS-TE tunnels is the best scheme. The edge nodes
in the DS-TE area divide the traffic into several classes, and add the class information into the
EXP field in packets. The internal node chooses a proper PHB (Per Hop Behavior) for the packet
according to the EXP value.
DS-TE optimizes network resources, classify service types, and reserve resources for different
types of services. One DS-TE tunnel can carry up to 8 types of service.
NOTE
l To configure standard DS-TE tunnel services, configure the ingress and egress to support HQoS. This,
however, is not required on the Non-standard DS-TE tunnel.
l When services of the same type of multiple VPNs are carried on the same CE of the DS-TE tunnel,
you can limit the bandwidth of each type of services for each VPN on the access CE to prevent source
competition among services of the same type of multiple VPNs.
l To prevent non-VPN services and VPN services from completing resources, you can configure DS-
TE to carry VPN services only or configure the bandwidth for non-VPN services in DS-TE.
Before configuring DS-TE, complete the following tasks:

l Configure unicast static routes or IGP on each LSR to implement the reachability between
LSRs at the network layer.
l Configuring the LSR ID on each LSR.
l Enable MPLS in system and interface views on each LSR.
l Enable MPLS TE and MPLS RSVP-TE in system and interface views on each LSR.
l Enable simple traffic classification on the interfaces of each LSR.
Data Preparation
To configure DS-TE, you need the following data.
No. Data
1 DS-TE mode
2 Bandwidth constraints model
3 TE-class mapping table
4 Link bandwidth
5 Tunnel interface bandwidth
6 The flow queues bandwidth sharing mode between CTs
7 Mapping between CTs and flow queues
3.18.2 Configuring DS-TE Mode

You can configure the non-IETF mode or the IETF mode for an MPLS TE tunnel.
Context
Perform the following steps on each LSR in a DS-TE domain:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te ds-te mode { ietf | non-ietf }
The DS-TE mode is configured.

By default, the non-IETF mode is used.
----End
Follow-up Procedure
In the NE80E/40E, the non-IETF mode and the IETF mode can be switched to each other. When
the IETF mode is switched to the Non-IETF mode, part LSPs may be deleted or the interworking
may fail. Therefore, be cautious when using the switch command.
NOTE
When the non-IETF DS-TE mode is switched to the IETF DS-TE mode, the user configurations cannot be
lost or modified; however, when the IETF DS-TE mode is switched to the non-IETF DS-TE mode, the
user configurations that are supported in the non-IETF mode but are not supported in the non-IETF mode
are lost or modified as follows:
l The extended-MAM configured in IETF DS-TE mode is automatically switched to the MAM. which
may cause an interworking problem.
l The interface bandwidth values set for BC2 to BC7 in IETF DS-TE mode are deleted.
Table 3-2 describes how DS-TE modes are switched.
Table 3-2 DS-TE mode switching
Item Non-IETF --> IETF IETF --> Non-IETF
Change in The bandwidth constraints model The bandwidth constraints model is

the is unchanged. changed as follows:
bandwidth The extended-MAM is changed to the
constraint MAM.
s model
The RDM is unchanged.
The MAM is unchanged.
Change in The bandwidth values of BC0 and Other BC values are reset to zero except
the BC1 are unchanged. values of BC0 and BC1.
bandwidth
TE-class If the TE-class mapping table is The TE-Class mapping table is not
mapping configured, it is applied. applied.
table Otherwise, the default one is l If a TE-class mapping table is
applied. configured, it is not deleted.
NOTE
For information about the default TE- l If no TE-class mapping table is
class mapping table, see Table 3-3. configured, the default one is deleted.
LSP LSPs whose combination of <CT, The following LSPs are deleted:
deletion set-priority> or <CT, hold- l Multi-CT LSPs
priority> is not in the TE-class
mapping table are deleted. l LSPs of single CT from CT2 to CT7

3.18.3 Configuring DS-TE Bandwidth Constraints Model

If preemption for CT bandwidth is enabled, you are recommended to use the RDM, which
effectively uses bandwidth. If preemption for CT bandwidth is disabled on a network, you are
recommended to use the MAM or the extended-MAM.
Context
Perform the following steps on each LSR in a DS-TE domain:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te ds-te bcm { extend-mam | mam | rdm }
The DS-TE bandwidth constraints model is configured.
By default, the DS-TE bandwidth constraints model is the RDM.
The DS-TE non-IETF mode does not support the extended-MAM.
----End
3.18.4 (Optional) Configuring TE-Class Mapping Table

You are recommended to configure the same TE class mapping table in an entire DS-TE domain.
Otherwise, LSPs may be incorrectly set up.
Context
This configuration procedure is unnecessary to the non-IETF DS-TE.
For IETF DS-TE, it is recommended that the TE-class mapping tables applied to the entire DS-
TE domain are the same. Otherwise, Some LSPs may not be set up correctly.
Perform the following steps on each LSR of a DS-TE domain in DS-TE IETF mode:
Procedure
Step 1 Run:
system-view
Step 2 Run:
te-class-mapping

A TE-class mapping table is configured and the TE-Class mapping table view is displayed.
Step 3 Run one or multiple commands as follows to configured TE-Classes:
l To configure TE-Class0, run:

te-class0 class-type { ct0 | ct1 | ct2 | ct3 | ct4 | ct5 | ct6 | ct7 } priority
priority [ description description-info ]







When configuring a TE-class mapping table, pay attention to the following information:
l Each DS-TE node has one TE-class mapping table at most.

l TE-class is a global concept, that is , TE-class is applied to all DS-TE tunnels of the LSR.
l A TE-class indicates the combination of a Class-Type (CT) and priority. The priority
indicates the priority for CR-LSP preemption rather than the value of the EXP field in the
MPLS packet header. The value of the preemption priority ranges from 0 to 7. The smaller
the value is, the higher the priority is. A CR-LSP can be set up only when both the combination
of its CT and setup priority (<CT, setup-priority>) and the combination of its CT and holding
priority (<CT, hold-priority>) exist in the TE-class mapping table. For example, suppose the
TE-class mapping table of a certain node contains only TE-Class[0] = <CT0, 6> and TE-
Class[1] = <CT0, 7>. Only the following types of CR-LSPs can be set up successfully:
– Class-Type = CT0, setup-priority = 6, hold-priority = 6
NOTE
The setup-priority cannot be higher than the hold-priority. Therefore, the LSP , whose Class-Type is
CT0, setup-priority is 6, holding priority is 7, does not exist.
l In the MAM and extended-MAM, the CT of a higher priority can preempt the bandwidth of
CTs of the same type. CTs of different types do not preempt the bandwidth of each other.
l In the RDM, the preemption of bandwidth among CTs is determined by the preemption
priority and the corresponding bandwidth constraint. Assume m and n are preemption
priorities (0<=m<n<=7) and i and j are CT values (0<=i<j<=7).

– CTi with priority m can preempt the bandwidth of CTi with priority n or the bandwidth
of CTj with priority n.
– The total bandwidth of CTi is equal to or less than the bandwidth of BCi.
l When the bandwidth of all CTs along an LSP meets the requirements, the preemption can
be performed and the LSP can be set up.
In DS-TE IETF mode, when the TE-class mapping table is not configured, the default TE-class
mapping table is applied. See Table 3-3.
Table 3-3 Default TE-class mapping table
TE-Class CT Priority
TE-Class[0] 0 0
TE-Class[1] 1 0
TE-Class[2] 2 0
TE-Class[3] 3 0
TE-Class[4] 0 7
TE-Class[5] 1 7
TE-Class[6] 2 7
TE-Class[7] 3 7
NOTE
After a TE-class is configured, you can run the { te-class0 | te-class1 | te-class2 | te-class3 | te-class4 | te-
class5 | te-class6 | te-class7 } description description-info command to modify the TE-class description.
----End
3.18.5 Configuring Link Bandwidth

By configuring the link bandwidth, you can limit the bandwidth of a DS-TE tunnel.
Context
Perform the following steps on each outgoing interface along the LSP in a DS-TE domain:
Procedure
Step 1 Run:
system-view
Step 2 Run:

The view of the outgoing interface of the link is displayed.
Step 3 Run:
The maximum reservable bandwidth of the link is configured.
Step 4 Run:
mpls te bandwidth { bc0 bc0-bw-value | bc1 bc1-bw-value | bc2 bc2-bw-value | bc3
bc3-bw-value | bc4 bc4-bw-value | bc5 bc5-bw-value | bc6 bc6-bw-value | bc7 bc7-bw-
value }*
----End
Follow-up Procedure
In different bandwidth constraints models, the relationships between the reservable bandwidth
and the bandwidth of each BC are different.
l In the RDM: max-reservable-bandwidth >= bc0-bw-value >= bc1-bw-value >= bc2-bw-

value >= bc3-bw-value >= bc4-bw-value >= bc5-bw-value >= bc6-bw-value >= bc7-bw-
value
l In the MAM: max-reservable-bandwidth >= bc0-bw-value + bc1-bw-value + bc2-bw-
value + bc3-bw-value + bc4-bw-value + bc5-bw-value + bc6-bw-value + bc7-bw-value
l In the extended-MAM: It is the same as the MAM.
BC is the bandwidth constraint for outgoing interface, while CT bandwidth is the bandwidth of
the class type of DS-TE tunnel. The total bandwidth of BCi (0 <= i <= 7) of an interface is equal
to or greater than the CTi bandwidth of all tunnels passing through this outgoing interface. For
example, three LSPs of CT1 pass through a link and their bandwidth values are x, y, and z
respectively. The bandwidth of BC1 of the link should be equal to or greater than the total
bandwidth of x, y, and z.
3.18.6 Configuring the Tunnel Interface

To set up a DS-TE tunnel, you must create a tunnel interface and configure other tunnel attributes
on the tunnel interface.
Context
Perform the following steps on the ingress of a TE tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The tunnel interface is created and the tunnel interface view is displayed.


description text
The tunnel description information is configured.
Step 4 Run one of the following commands to configure the IP address of the tunnel interface.
l ip address ip-address { mask | mask-length } [ sub ]
The IP address of the tunnel interface is configured.

The secondary IP address can be configured on the tunnel interface only when the primary
IP address is configured. ip_address_unnumbered
l ip address unnumbered interface interface-type interface-number
The tunnel interface borrows the IP address of another interface.
To forward traffic, the tunnel interface must be configured with an IP address. Because that an
MPLS TE tunnel is unidirectional, no peer address exists. Therefore, a tunnel interface needs
not to be assigned with an IP address. Instead, the tunnel interface takes the LSR ID of the local
node as its IP address.
Step 5 Run:
MPLS TE is configured as the tunnel protocol.
Step 6 Run:
The LSR ID of the egress is configured as the destination address of the tunnel.
By default, the tunnel is a GRE tunnel. Different tunnels require different destination addresses.
When the tunnel protocol is changed from another protocol to MPLS TE, the preceding
destination address is deleted and a new one needs to be configured.
Step 7 Run:
The tunnel ID is configured.
Step 8 Run:
mpls te signal-protocol { cr-static | rsvp-te }
The signaling protocol of the tunnel is configured.
Step 9 (Optional) run:

mpls te priority setup-priority [ hold-priority ]
The priority for the tunnel is configured.
By default, both the setup-priority and the hold-priority are 7. Both the setup-priority and the
hold-priority range from 0 to 7. The smaller the value is, the higher the priority is.
NOTE
The setup priority should not be higher than the holding priority. When the holding priority is not specified,
it is the same as the setup priority.
Step 10 Run:
mpls te commit

The configuration of the tunnel is committed.
When the MPLS TE parameters are modified each time, run the mpls te commit command to
commit the configuration.
----End
3.18.7 Configuring the Static CR-LSP and the Bandwidth

A static CR-LSP supports eight CTs in standard DS-TE mode and supports CT0 and CT1 in
non-standard DS-TE mode.
Procedure
l Configure the ingress of the static CR-LSP.
Perform the following steps on the ingress of the static CR-LSP:
1. Run:
system-view

2. Run:
static-cr-lsp ingress { tunnel-interface tunnel interface-number | tunnel-
name } destination destination-address { nexthop next-hop-address |
outgoing-interface interface-type interface-number }* out-label out-label
bandwidth { ct0 | ct1 | ct2 | ct3 | ct4 | ct5 | ct6 | ct7 } bandwidth
The ingress of the static CR-LSP is configured and its CT and the bandwidth are
specified.
NOTE
l tunnel interface-number is the interface number of the MPLS TE tunnel of the static CR-
LSP.
l The static CR-LSP supports eight CTs in DS-TE IETF mode and supports only CT0 and
CT1 in DS-TE non-IETF mode. That is, the CT of the static CR-LSP in IETF mode can be
whichever of the CT0 to CT7; the static CR-LSP in non-IETF mode can only be CT0 or
CT1.
l The tunnel bandwidth cannot exceed the max-reservable bandwidth of the link.
l tunnel-name must be the same as that in the interface tunnel interface-number command.
The value is a case-sensitive string without blank space or abbreviation. Assume a tunnel
interface is created through the interface tunnel 2/0/0 command. The tunnel name is
Tunnel 2/0/0 and the parameter of the ingress of the static CR-LSP must be Tunnel 2/0/0.
Otherwise, the tunnel is set up incorrectly. This rule is inapplicable to transit LSRs or the
egress.
The static CR-LSP supports the single CT only in DS-TE IETF mode. The static CR-LSP
has the highest priority whose value is zero, and does not support bandwidth preemption.
That is, when a static CR-LSP is being set up, it does not preempt the resources of other
LSPs regardless whether the unreserved bandwidth of its out interface is enough or not. In
addition, after a static CR-LSP is set up, its bandwidth cannot be preempted by other LSPs.
On one node (ingress, transit LSR, or egress) in any Bandwidth Constraints model, the total
bandwidth of CTi is not more than the bandwidth of BCi (0 <= i <= 7). That is, CTi can
use only bandwidth of BCi.

For instance, the bandwidth of BC1 on PE is x. Two static CR-LSPs with the CT1 bandwidth
being y and z respectively are set up on the PE. The total bandwidth of CT1s (y + z) is not
more than the bandwidth of BC1 (x).
NOTE
If the bandwidth of the MPLS TE tunnel is configured more than 28630 kbit/s, the actual bandwidth
allocation on the MPLS TE tunnel may not be precise. The MPLS TE tunnel, however, can be set
up successfully.
l Configure the transit LSR of the static CR-LSP.
The configuration is unnecessary if the static CR-LSP has only the ingress and egress. When
transit LSRs reside in the static CR-LSP, perform the following steps on each transit LSR:
1. Run:
system-view

2. Run:
static-cr-lsp transit lsp-name incoming-interface interface-type
interface-number in-label in-label-value { nexthop next-hop-address |
outgoing-interface interface-type interface-number }* out-label out-label-
value bandwidth { ct0 | ct1 | ct2 | ct3 | ct4 | ct5 | ct6 | ct7 } bandwidth
The transit LSR of the static CR-LSP is configured.
On the transit LSR and egress, tunnel-name cannot be specified as the same as the
name of an existing tunnel on the node. The name of the MPLS TE tunnel interface
associated with the static CR-LSP can be used, such as Tunnel2/0/0.
l Configure the egress of the static CR-LSP.
Perform the following steps on the egress of the static CR-LSP:
1. Run:
system-view

2. Run:
static-cr-lsp egress lsp-name incoming-interface interface-type interface-
number in-label in-label [ lsrid ingress-lsr-id tunnel-id tunnel-id ]
The egress of the static CR-LSP is configured.
----End
3.18.8 Configuring the RSVP CR-LSP and Its Bandwidth

When establishing an RSVP CR-LSP and specifying the bandwidth, ensure that the bandwidth
of LSPs of all CTs is not greater than the bandwidth of all BCs.
Procedure
l Configuring IGP TE
For detailed configurations, see the section Configuring OSPF TE or Configuring IS-IS
TE.
l Configuring CSPF

For detailed configurations, see the section Configuring CSPF.

l Configure the bandwidth of the MPLS TE tunnel
Perform the following steps on the ingress of an MPLS TE tunnel:
1. Run:
system-view

2. Run:
The MPLS TE tunnel interface view is displayed.

3. Run one of the following commands to configure the bandwidth of the MPLS TE
tunnel interface.
– To configure the single CT, run:

mpls te bandwidth { ct0 bw-value [ flow-queue flow-queue ] | ct1 bw-
value [ flow-queue flow-queue ] }
NOTE
l If you specify the name of the flow queue template referenced by the tunnel in this
command, traffic over the tunnel is then scheduled and assigned bandwidth based on
the flow queue template.
l If the flow queue template referenced by the tunnel is not specified, the system
automatically generates the flow queue template referenced by the tunnel according to
the CT and flow queue mapping configured in the ct-flow-mapping view.
– To configure the multi-CT, run
mpls te bandwidth { ct0 bw-value | ct1 bw-value | ct2 bw-value | ct3 bw-
value | ct4 bw-value | ct5 bw-value | ct6 bw-value | ct7 bw-value } *
NOTE
If the flow queue template needs to be referenced when the single CT is configured, configure
the flow queue template first. For detailed configurations of the flow queue template, refer to
the HUAWEI NetEngine80E/40E Router Configuration Guide - QoS.
In tunnel policy, the multiple class type (multi-CT) CR-LSP supports only the VPN tunnel
binding mode rather than the select-sequence mode.
4. Run:
mpls te commit
On one node in any the Bandwidth Constraints model, the total bandwidth of CTi is not
more than the bandwidth of BCi (0 <= i <= 7) irrespective of. That is, CTi can use only the
bandwidth of BCi.
For instance, the bandwidth of BC1 on a PE is x and two CR-LSPs are set up on the node
with their CT1 bandwidth being y and z respectively. The total bandwidth of CT1 (y + z)
is not more than the bandwidth of BC1 (x).
NOTE
If the bandwidth of the MPLS TE tunnel is configured as more than 28630 kbit/s, the bandwidth
allocation on the MPLS TE tunnel may not be precise. The MPLS TE tunnel, however, can be set
up successfully.
l (Optional) Configure the explicit path of the tunnel.

To specify the path used by the tunnel, perform the following steps on the ingress of the
tunnel:
1. Create and configure the explicit path. See Configuring MPLS-TE Explicit Path.
2. Run:
quit

3. Run:

4. Run:
The explicit path used by the tunnel is configured.

5. Run:
mpls te commit
----End
3.18.9 Configuring Mappings Between CTs and Flow Queues
Context
Perform the following steps on the ingress of a DS-TE tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
ct-flow-mapping template name
The template of mappings between CTs and flow queues is created and the ct-flow-mapping
view is displayed.
Step 3 Run:
map ct ct-number to { cs7 | cs6 | ef | af4 | af3 | af2 | af1 | be } [ pq | wfq |
lpq ]
The mappings between CTs and flow queues are configured.

NOTE
l The system supports flexible mapping between CTs and flow queues.
l The system supports a maximum of eight templates of the mappings between CTs and flow queues. Seven
templates can be manually configured. One default template cannot be modified.
l By default, the default template is used. The default template defines the following mappings between CTs
and flow queues:
l Maps CT 0 to be lpq.
l Maps CT 1 to af1 wfq.
l Maps CT 5 to ef pq.
l Maps CT 6 to cs6 pq.
l Maps CT 7 to cs7 pq.
l Based on the parameters of a flow queue configured using the map ct ct-number to { cs7 | cs6 | ef | af4 |
af3 | af2 | af1 | be } [ pq | wfq | lpq ] command, the system automatically generates a template applicable
to the DS-TE tunnel.
Step 4 Run:
ct-flow-mapping commit
The mappings between CTs and flow queues defined in the template are committed so that the
mappings can take effect.
Step 5 Run:
quit
Return to the system view from the ct-flow-mapping view.
Step 6 Run:
NOTE
The interface is the physical interface that is bound to the DS-TE tunnel on the ingress.
Step 7 Run:
mpls te ct-flow-mapping mapping-name
The template of mappings between CTs and flow queues is applied to the interface.

mpls te ct-bandwidth unshared
CTs do not share the bandwidth of each other on the interface enabled with DS-TE.

NOTE
l When the interface enabled with DS-TE is configured to share bandwidths of CTs, eight CTs of a DS-TE
tunnel can share the bandwidth of each other, which allows the bandwidth of the DS-TE tunnel to be
efficiently used. It is recommended you to use the shared attribute by default.
l When CTs can share the bandwidth of each other on the interface enabled with DS-TE, the shaping parameter
of the flow queue parameters is the CIR of the SQ, which is equal to the total bandwidths of CTs.
l When CTs cannot share the bandwidth of each other on the interface enabled with DS-TE, the shaping
parameter of the flow queue parameters is the bandwidth of a specific CT.
l When an interface supports DS-TE and is selected as the outbound interface of a tunnel working in Up state,
reset the tunnel to make the changed shared or unshared attribute on the interface take effect.
----End
3.18.10 (Optional) Configuring the Interface Class Queue
Context
Perform the following steps on the interface on the network side on the ingress of a DS-TE
tunnel:
NOTE
l The interface class queue is an interface-specific scheduling policy. You can configure the interface class
queue based on the actual networking.
l It is recommended that traffic of the same service type applies the same queue scheduling mode to the flow
queue and the class queue.
Procedure
Step 1 Run:
system-view
Step 2 Run:
port-wred port-wred-name
A port WRED object is created, and the port WRED view is displayed.
Step 3 Run:
color { green | yellow | red } low-limit low-limit-value high-limit high-limit-
value discard-percentage discard-percentage-value
A WRED object for a class queue is configured, and the upper limit, the lower limit, and the
discard probability are set for packets of different colors.
NOTE
l If you do not configure a WRED object for a class queue, the system uses the default tail-drop policy.
l You can create multiple port-wred objects to be referenced by class queues as required. The system
provides one default port-wred object. You can configure a maximum of seven port-wred objects.
Step 4 Run:
quit

Step 5 Run:
Step 6 Run:
port-queue cos-value { { pq | wfq weight weight-value | lpq} | shaping { shaping-
value | shaping-percentage shaping-percentage-value } [ pbs pbs-value ] | port-
wred wred-name | low-latency } * outbound
A class queue is configured and a scheduling policy is set for queues of different priorities.
You can configure scheduling parameters for eight class queues on one interface.
If you do not configure a class queue template, the system uses the default class queue template.
The default class queue template contains the following parameters:
l By default, the system performs PQ on class queues ef, cs6, and cs7.
l The system performs WFQ on class queues be, af1, af2, af3, and af4. The scheduling weight
is 10:10:10:15:15.
l The default shaping value is the maximum bandwidth of the interface.
l The default discard policy is tail drop.
----End

After a DS-TE tunnel is configured, you can view information about DS-TE and traffic of each
CT on the tunnel interface.
Prerequisites
The DS-TE tunnel function has been configured.
Procedure
l Run the display mpls te ds-te { summary | te-class-mapping [ default | config |
verbose ] } command to check information about DS-TE.
l Run display mpls te te-class-tunnel { all | { ct0 | ct1 | ct2 | ct3 | ct4 | ct5 | ct6 | ct7 }
priority priority } command to check TE tunnels associated with the TE-classes.
l Run the display interface tunnel interface-number command to check information about
traffic of each CT on the tunnel interface.
NOTE
Before viewing traffic information about each CT configured for a DS-TE tunnel, run the mpls te
lsp-tp outbound command in the tunnel interface view to limit the rate at which TE traffic is
transmitted.
----End
Example
After completing the configuration, run the following commands to view the information.

l Run the display mpls te ds-te command on the ingress of the tunnel to view information
about DS-TE.
l Run the display mpls te te-class-tunnel command on the ingress of the tunnel to view TE
tunnels associated with the TE-classes.
l Run the display interface tunnel interface-number command on the ingress of the tunnel
to view information about traffic of each CT on the tunnel.
3.19 Configuring TE Manual FRR

TE manual FRR is a local protection mechanism used on MPLS TE networks. TE manual FRR
switches traffic on a primary MPLS TE tunnel to a manually configured bypass tunnel if a link
or node on the primary tunnel fails.

Before configuring TE manual FRR, familiarize yourself with the usage scenario, complete the
Usage Scenario
FRR provides rapid local protection for MPLS TE networks requiring high reliability. If a local
failure occurs, FRR rapidly switches traffic to a bypass tunnel, minimizing the impact on traffic.
A backbone network has a large capacity and its reliability requirements are high. If a link or
node failure occurs on the backbone network, a mechanism is required to provide automatic
protection and rapidly remove the fault. The Resource Reservation Protocol (RSVP) usually
establishes MPLS TE LSPs in Downstream on Demand (DoD) mode. If a failure occurs,
Constraint Shortest Path First (CSPF) can re-calculate a reachable path only after the ingress is
notified of the failure. The failure may trigger reestablishment of multiple LSPs and the
reestablishment fails if bandwidth is insufficient. Either the CSPF failure or bandwidth
insufficiency delays the recovery of the MPLS TE network.
Configuring TE FRR on MPLS TE-enabled interfaces allows traffic to automatically switch to

a protection link if a link or node on a primary tunnel fails. After the primary tunnel recovers or
is reestablished, traffic switches back to the primary tunnel. This process meets the reliability
requirements of the MPLS TE network.
NOTE
l FRR requires reserved bandwidth for a bypass tunnel that needs to be pre-established. If available
bandwidth is insufficient, FRR protects only important nodes or links along a tunnel.
l RSVP-TE tunnels using bandwidth reserved in Shared Explicit (SE) style support FRR, but static TE
tunnels do not.
TE FRR can be used together with either of the following features:
l Board removal protection

If an interface board is removed, on which the outbound interface of a primary tunnel on
a Point of Local Repair (PLR) resides, MPLS TE traffic rapidly switches to a bypass tunnel.
After the removed interface board is installed, MPLS TE traffic switches back if the
outbound interface of the primary tunnel is available. Board removal protection applies to
the outbound interface of the primary tunnel on the PLR.

When TE FRR and board removal protection are used on the PLR, ensure that tunnel
interfaces on the primary and bypass tunnels and the outbound interface on the bypass
tunnel are configured on an interface board different from the interface board to be removed.
Configuring the bypass TE tunnel interface on a main control board of the PLR is
recommended.
NOTE
After an interface connected to an LSR or a CR-LSP is deleted or its board is removed, the interface
enters the stale state. If the number of stale interfaces on a node reaches the maximum number allowed
by the license, the node does not implement FRR for the primary tunnel if the interface providing
the outbound interface for the primary tunnel is removed or faulty.
l RSVP GR
On the NE80E/40E, FRR can be performed during the RSVP GR process. This protects
traffic on the primary tunnel and speeds up troubleshooting in the situation where a traffic
switchover or a reboot is triggered after a fault occurs on an MP, the MP's downstream
node, a PLR, or the PLR' upstream node, meanwhile the outbound interface of a primary
tunnel on the PLR fails.
During the RSVP GR process, FRR switching is triggered if the outbound interface of a
primary tunnel on the PLR goes Down.
Before configuring TE manual FRR, complete the following tasks:
l Set up a primary RSVP-TE tunnel.

l Enable MPLS TE and RSVP-TE in the MPLS and physical interface views on every node
along a bypass tunnel. (See 3.5.2 Enabling MPLS TE and RSVP-TE.)
l (Optional) Configure physical link bandwidth for the bypass tunnel. (See 3.2.3 (Optional)
Configuring Link Bandwidth.)
l Enable CSPF on a PLR.
l (Optional) Configure an explicit path for the bypass tunnel.
Data Preparation
To configure TE manual FRR, you need the following data.
No. Data
1 FRR protection policy, either link or node protection
2 Name of a physical interface that a bypass tunnel protects
3 (Optional) Explicit path and bandwidth for the bypass tunnel
4 (Optional) TE FRR scanning interval
5 (Optional) Path State Block (PSB) and Reservation State Block (RSB) timeout
multiplier

3.19.2 Enabling TE FRR

TE FRR must be enabled for a primary tunnel before a bypass tunnel is established.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The interface view of a primary tunnel is displayed.
Step 3 Run:
mpls te fast-reroute [ bandwidth ]
TE FRR is enabled.
NOTE
Only the primary tunnel in a tunnel protection group can be configured together with TE FRR on the ingress.
Neither the protection tunnel nor the tunnel protection group itself can be used together with TE FRR. If
the tunnel protection group and TE FRR are used, neither of them takes effect.
For example, Tunnel 1/0/0 and Tunnel 2/0/0 are tunnel interfaces on MPLS TE tunnels and the tunnel
named Tunnel 2/0/0 has a tunnel ID of 200. The mpls te protection tunnel 200 and mpls te fast-
reroute commands can be both configured on Tunnel 1/0/0. This means that the tunnel named Tunnel
1/0/0 can be a primary tunnel in a tunnel protection group and a TE FRR primary tunnel. A configuration
failure will occur if the mpls te protection tunnel 200 command is run on Tunnel 1/0/0 and the mpls te
fast-reroute command is run on Tunnel 2/0/0.
Step 4 Run:
mpls te commit
----End
3.19.3 Configuring a Bypass Tunnel

A bypass tunnel provides protection for a link or node on a primary tunnel. An explicit path and
attributes must be specified for a bypass tunnel when TE manual FRR is being configured.
Context
Bypass tunnels are established on selected links or nodes that are not on the protected primary
tunnel. If a link or node on the protected primary tunnel is used for a bypass tunnel and fails, the
bypass tunnel also fails to protect the primary tunnel.

NOTE
l FRR does not take effect if multiple nodes or links fail simultaneously. After FRR switching is
performed to switch data from the primary tunnel to a bypass tunnel, the bypass tunnel must remain
Up when forwarding data. If the bypass tunnel goes Down, the protected traffic is interrupted and FRR
fails. Even though the bypass tunnel goes Up again, traffic is unable to flow through the bypass tunnel
but travels through the primary tunnel after the primary tunnel recovers or is reestablished.
l By default, the system searches for an optimal manual FRR tunnel for each primary tunnel every 1
second and binds the bypass tunnel to the primary tunnel if there is an optimal bypass tunnel.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The tunnel interface view of a bypass tunnel is displayed.
Step 3 Run either of the following commands to configure the IP address for the tunnel interface:
l To configure an IP address for the interface, run:
l To configure the tunnel interface to borrow the IP address of another interface, run:
NOTE
A tunnel interface must have an IP address to forward traffic. An MPLS TE tunnel is unidirectional and
does not need a peer address. Therefore, there is no need to configure a separate IP address for the tunnel
interface. The tunnel interface usually borrows the IP address of the local loopback interface used as an
LSR ID.
Step 4 Run:
Step 5 Run:
The LSR ID of an MP is specified as the destination address of the bypass tunnel.
Step 6 Run:
The tunnel ID is set for the bypass tunnel.

An explicit path is specified for the bypass tunnel.
NOTE
Physical links of a bypass tunnel cannot overlap protected physical links of the primary tunnel.

Step 8 (Optional) Run either of the following commands to set the bandwidth for the bypass tunnel:
l mpls te bandwidth { ct0 ct0-bw-value | ct1 ct1-bw-value } [ flow-queue flow-
queue ]
l mpls te bandwidth { { ct0 ct0-bw-value | ct1 ct1-bw-value | ct2 ct2-bw-value |

ct3 ct3-bw-value | ct4 ct4-bw-value | ct5 ct5-bw-value | ct6 ct6-bw-value | ct7
ct7-bw-value } *
Step 9 Run:
mpls te bypass-tunnel
The bypass tunnel function is enabled.
After a bypass tunnel is configured, the system automatically records routes related to the bypass
tunnel.
NOTE
Note the following settings to prevent a protection failure:

l A tunnel interface cannot be used for both a bypass tunnel and a backup tunnel. A protection failure
will occur if the mpls te bypass-tunnel and mpls te backup commands are both configured on the
tunnel interface.
l A tunnel interface cannot be used for both a bypass tunnel and a primary tunnel. A protection failure
will occur if the mpls te bypass-tunnel and mpls te fast-reroute commands are both configured on
the tunnel interface.
l A tunnel interface cannot be used for both a bypass tunnel and a protection tunnel in a tunnel protection
group. A protection failure will occur if the mpls te bypass-tunnel and mpls te protection tunnel
commands are both configured on the tunnel interface.
Step 10 Run:
mpls te protected-interface interface-type interface-number
An interface to be protected by a bypass tunnel is specified.
NOTE
l A bypass tunnel protects a maximum of six physical interfaces.

l A tunnel interface cannot be used for both a bypass tunnel and a backup tunnel. A protection failure
will occur if the mpls te protected-interface and mpls te backup commands are both configured on
the tunnel interface.
Step 11 Run:
mpls te commit
----End
3.19.4 (Optional) Configuring a TE FRR Scanning Timer

A TE FRR-enabled device periodically refreshes the binding between a TE FRR LSPs and a
primary LSP at a specified interval. The PLR searches for the optimal TE bypass LSP and binds
it to a primary LSP. A TE FRR scanning timer is set to determine the interval at which the binding
between a TE FRR LSP and a primary LSP is refreshed.
Procedure
Step 1 Run:

system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te timer fast-reroute [ weight ]
Set the interval at which the binding between a TE FRR LSP and a primary LSP is refreshed.
By default, the time weight used to calculate the interval is 300 (weight). And the actual interval
at which the binding between a TE FRR LSP and a primary LSP is refreshed depends on device
performance and the maximum number of LSPs that can be established on the device.
----End
3.19.5 (Optional) Changing the PSB and RSB Timeout Multiplier

To help allow TE FRR to operate during the RSVP GR process, the timeout multiplier of the
Path State Block (PSB) and Reservation State Block (RSB) can be set. The setting prevents the
situation where information in PSBs and RSBs is dropped due to a timeout before the GR
processes are complete for a large number of CR-LSPs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
The PSB and RSB timeout multiplier is set.
The default timeout multiplier is 3.
NOTE
Setting the timeout multiplier to 5 or greater is recommended for a network where a large number of CR-
LSPs are established and RSVP GR is configured.
----End

After completing the TE manual FRR configuration, you can view information about the primary
and bypass tunnels.

Prerequisites
MPLS TE manual FRR has been configured.
Procedure
l Run the display mpls lsp [ lsp-id ingress-lsr-id session-id lsp-id ] [ verbose ] command
to check information about a specified primary tunnel.
l Run the display mpls lsp attribute bypass-inuse { inuse | not-exists | exists-not-used }
command to check information about the attribute of a specified bypass LSP.
l Run the display mpls lsp attribute bypass-tunnel tunnel-name command to check
information about the attribute of a bypass tunnel.
l Run the display mpls te tunnel-interface [ tunnel tunnel-number | auto-bypass-tunnel
[ tunnel-name ] ] command to check detailed information about the tunnel interface of a
specified primary or bypass tunnel.
l Run the display mpls te tunnel path [ [ [ tunnel-name ] tunnel-name ] [ lsp-id ingress-
lsr-id session-id local-lsp-id ] | fast-reroute { local-protection-available | local-
protection-inuse } | lsr-role { ingress | transit | egress } ] command to check information
about paths of a specified primary or bypass tunnel.
----End
Example
Run the display mpls te tunnel-interface command to view information about the tunnel
interface of a primary or bypass tunnel.
<HUAWEI> display mpls te tunnel-interface tunnel 1/0/0
----------------------------------------------------------------
Tunnel1/0/0
----------------------------------------------------------------
Tunnel State Desc : GRACEFUL SWITCH
Active LSP : Best-Effort LSP
Traffic Switch : Best-Effort LSP -> Ordinary LSP
Session ID : 50
Ingress LSR ID : 1.1.1.1 Egress LSR ID: 2.2.2.2
Admin State : UP Oper State : UP
Primary LSP State : DOWN
Main LSP State : SETTING UP
Hot-Standby LSP State : UP
Main LSP State : READY LSP ID : 32799
Modify LSP State : SETTING UP
Ordinary LSP State : UP
Best-Effort LSP State : UP
Run the display mpls te tunnel path command to view information about the paths of a primary
or bypass tunnel.
<HUAWEI> display mpls te tunnel path
Tunnel Interface Name : Tunnel1/0/0
Lsp ID : 1.1.1.9 :100 :1024
Hop Information
Hop 0 10.1.1.1
Hop 1 10.1.1.2
Hop 2 2.2.2.9
Hop 3 20.1.1.1
Hop 4 20.1.1.2

Hop 5 3.3.3.9
Lsp ID : 1.1.1.9 :100 :2048
Hop Information
Hop 0 30.1.1.1
Hop 1 30.1.1.2
Hop 2 4.4.4.9
Hop 3 40.1.1.1
Hop 4 40.1.1.2
Hop 5 3.3.3.9
3.20 Configuring MPLS TE Auto FRR

This section describes how to configure MPLS TE Auto FRR. MPLS TE Auto FRR is a local
protection technique and is used to protect a CR-LSP against link faults and node faults. MPLS
TE Auto FRR does not need to be configured manually.

Before configuring MPLS TE Auto FRR, familiarize yourself with the usage scenario, complete
Usage Scenario
On the network that requires high reliability, FRR protection is configured to improve network
reliability. If the network topology is complex, and multiple links need to be configured, the
configuration procedure is complicated. Auto FRR can set up a bypass tunnel automatically to
meet the requirements to reduce the workload and improve network reliability.
Similar to common MPLS TE FRR, MPLS TE Auto FRR also supports board hot pulling-out
protection and FRR during RSVP GR. For more information, see Configuring TE Manual
FRR.
Before configuring MPLS TE Auto FRR, complete the following tasks:
l Establish the primary LSP by using the RSVP-TE signaling protocol.

l Enable MPLS, MPLS TE and RSVP TE globally and in the physical interface view of the
node along the bypass tunnel. (See 3.5.2 Enabling MPLS TE and RSVP-TE.)
l (Optional) Configure physical bandwidth of the bypass tunnel. (See (Optional) Configure
link bandwidth.)
l Enable CSPF on the ingress node and the transit node of the primary tunnel.
Data Preparation
To configure the MPLS Auto FRR, you need the following data.
No. Data
1 Auto FRR protection policy to determine whether a link or node is to be protected
2 (Optional) Bandwidth of the bypass tunnel

No. Data
3 (Optional) Scanning interval of TE FRR
3.20.2 Enabling TE Auto FRR

This section describes how to enable TE Auto FRR. Before you configure TE Auto FRR, you
must enable TE Auto FRR.
Context
Perform the following steps on the ingress and transit nodes of a tunnel:
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls te auto-frr [ self-adapting ]
TE Auto FRR is enabled globally.

To enable an automatic bypass tunnel to dynamically select node or link protection based on
network conditions, configure self-adapting.
Step 4 Run:
quit

Step 5 Run:
The interface view of the outbound interface of the primary tunnel is displayed.
mpls te auto-frr { link | node | default | self-adapting }
TE Auto FRR is enabled on the outbound interface on the ingress of the primary tunnel.
By default, after Auto FRR is enabled globally, all MPLS TE interfaces are automatically
configured with the mpls te auto-frr default command. To disable Auto FRR on some
interfaces, run the mpls te auto-frr block command on these interfaces. Then, these interfaces
no longer have the Auto FRR capability even if Auto FRR is enabled or is to be re-enabled
globally.
By default, the TE Auto FRR is disabled.

To enable an automatic bypass tunnel bound to the current tunnel to dynamically select node or
link protection based on network conditions, configure self-adapting.
NOTE
l If the mpls te auto-frr default command is configured in the interface view, the Auto FRR capability
of the interface is consistent with the global Auto FRR capability.
l If the mpls te auto-frr node command without self-adapting configured is run, and the requirement
for node protection is not met, the penultimate hop (but not other hops) on the primary tunnel attempts
to set up an automatic bypass tunnel for link protection.
----End
3.20.3 Enabling TE FRR and Configuring Auto Bypass Tunnel

Attributes
This section describes how to enable TE FRR and configure Auto bypass tunnel attributes. A
TE Auto FRR-enabled device can automatically set up a bypass tunnel.
Context
Perform the following steps on the ingress of the primary tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The tunnel interface view of the primary tunnel is displayed.
Step 3 Run:
MPLS TE is configured as a tunneling protocol.
Step 4 Run:
mpls te fast-reroute [ bandwidth ]
TE FRR is enabled.
To guarantee tunnel bandwidth, specify the bandwidth parameter.

mpls te bypass-attributes bandwidth bandwidth [ priority setup-priority [ hold-
priority ] ]
The attributes of the bypass tunnel are configured.

NOTE
l The bypass tunnel attributes can be configured only after the mpls te fast-reroute bandwidth
command is run on the primary tunnel.
l The bandwidth of the bypass tunnel cannot be higher than the bandwidth of the primary tunnel.
l When the attributes of the automatic bypass tunnel are not configured, by default, the bandwidth of the
automatic bypass tunnel is the same as the bandwidth of the primary tunnel.
l The setup priority of the bypass tunnel cannot be higher than the holding priority. The setup priority
of the bypass tunnel cannot be higher than that of the primary tunnel. The holding priority of the bypass
tunnel cannot be higher than that of the primary tunnel.
l If the bandwidth of the primary tunnel is changed or FRR is disabled, bypass tunnel attributes are
cleared automatically.
l On one TE tunnel interface, the bandwidth of the bypass tunnel cannot be configured together with the
multi-CT.
Step 6 Run:
mpls te commit
----End
3.20.4 (Optional) Configuring the Scanning Timer for FRR

A TE FRR-enabled device periodically refreshes the binding between a TE FRR LSPs and a
primary LSP at a specified interval. The PLR searches for the optimal TE bypass LSP and binds
it to a primary LSP. A TE FRR scanning timer is set to determine the interval at which the binding
between a TE FRR LSP and a primary LSP is refreshed.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls te timer fast-reroute [ weight ]
Set the interval at which the binding between a TE FRR LSP and a primary LSP is refreshed.
By default, the time weight used to calculate the interval is 300 (weight). And the actual interval
at which the binding between a TE FRR LSP and a primary LSP is refreshed depends on device
performance and the maximum number of LSPs that can be established on the device.
----End
3.20.5 (Optional) Modifying PSB and RSB Timeout Multiplier

To help allow TE FRR to operate during the RSVP GR process, the timeout multiplier of the
Path State Block (PSB) and Reservation State Block (RSB) can be set. The setting prevents the

situation where information in PSBs and RSBs is dropped due to a timeout before the GR
processes are complete for a large number of CR-LSPs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
The PSB and RSB timeout multiplier is set.
The default timeout multiplier is 3.
NOTE
Setting the timeout multiplier to 5 or greater is recommended for a network where a large number of CR-
LSPs are established and RSVP GR is configured.
----End
3.20.6 (Optional) Configuring Auto Bypass Tunnel Re-

Optimization
Auto Bypass tunnel re-optimization allows paths to be recalculated at certain intervals for an
auto bypass tunnel. If an optimal path is recalculated, a new auto bypass tunnel will be set up
over this optimal path. In this manner, network resources are optimized.
Context
Network changes often cause the changes in optimal paths. Auto bypass tunnel re-optimization
allows the system to re-optimize an auto bypass tunnel if an optimal path to the same destination
is found due to some reasons, such as the changes in the cost. In this manner, network resources
are optimized.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:

mpls te auto-frr reoptimization [ frequency interval ]
Auto bypass tunnel re-optimization is enabled.
By default, auto bypass tunnel re-optimization is disabled. If re-optimization is enabled, the

default interval at which auto bypass tunnel re-optimization is performed is 3600 seconds.

return
Return to the user view.

mpls te reoptimization
After you configure the automatic re-optimization in the tunnel interface view, you can return
to the user view and run the mpls te reoptimization command to immediately re-optimize the
tunnels on which the automatic re-optimization is enabled. After you perform the manual re-
optimization, the timer of the automatic re-optimization is reset and counts again.
----End

After the configuration of MPLS TE Auto FRR, you can view detailed information about a
bypass tunnel.
Prerequisites
The MPLS TE auto FRR function has been configured.
Procedure
l Run the display mpls te tunnel verbose command to check binding information about the
primary tunnel and the auto bypass tunnel.
l Run the display mpls lsp attribute bypass-inuse { inuse | not-exists | exists-not-used }
command to check information about the attribute of a specified bypass LSP.
l Run the display mpls te tunnel-interface [ tunnel interface-number | auto-bypass-
tunnel [ tunnel-name ] ] command to check detailed information about the auto bypass
tunnel.
l Run the display mpls te tunnel path [ [ [ tunnel-name ] tunnel-name ] [ lsp-id ingress-
lsr-id session-id local-lsp-id ] | fast-reroute { local-protection-available | local-
protection-inuse } | lsr-role { ingress | transit | egress } ] command to check path
information about the primary tunnel and the auto bypass tunnel.
----End
Example
Run the display mpls te tunnel verbose command to view information about the binding
between the primary tunnel and the auto bypass tunnel.
<HUAWEI> display mpls te tunnel name Tunnel2/0/0 verbose

No : 1
Tunnel-Name : Tunnel2/0/0
TunnelIndex : 1 LSP Index : 3072
Session ID : 200 LSP ID : 1
LSR Role : Ingress LSP Type : Primary
Ingress LSR ID : 1.1.1.1
Egress LSR ID : 3.3.3.3
In-Interface : -
Out-Interface : GE2/0/0
Sign-Protocol : RSVP TE Resv Style : SE
IncludeAnyAff : 0x0 ExcludeAnyAff : 0x0
IncludeAllAff : 0x0
LspConstraint : -
ER-Hop Table Index : - AR-Hop Table Index: 2
C-Hop Table Index : -
PrevTunnelIndexInSession: - NextTunnelIndexInSession: -
PSB Handle : 65546
Created Time : 2009/03/30 09:52:03
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
Bandwidth Reserved Flag : Reserved
CT0 Bandwidth(Kbit/sec) : 10000 CT1 Bandwidth(Kbit/sec): 0
Setup-Priority : 7 Hold-Priority : 7
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
TE Attribute Flag : 0x63 Protected Flag : 0x1
Bypass In Use : Not Used
Bypass Tunnel Id : 67141670
BypassTunnel : Tunnel Index[Tunnel0/0/2048], InnerLabel[3]
Bypass LSP ID : - FrrNextHop : 10.1.1.1
ReferAutoBypassHandle : 2049
FrrPrevTunnelTableIndex : - FrrNextTunnelTableIndex: -
Bypass Attribute(Not configured)
Setup Priority : - Hold Priority : -
HopLimit : - Bandwidth : -
IncludeAnyGroup : - ExcludeAnyGroup : -
IncludeAllGroup : -
Bypass Unbound Bandwidth Info(Kbit/sec)
CT0 Unbound Bandwidth : - CT1 Unbound Bandwidth: -
--------------------------------
BFD Information
--------------------------------
NextSessionTunnelIndex : - PrevSessionTunnelIndex: -
NextLspId : - PrevLspId : -
3.21 Configuring CR-LSP Backup

CR-LSP backup is configured to provide end-to-end protection for traffic on CR-LSPs.

Before configuring CR-LSP backup, familiarize yourself with the usage scenario, complete the
pre-configuration tasks, and obtain the data required for the configuration. This can help you
complete the configuration task quickly and accurately.

Usage Scenario
Backup CR-LSPs are established on networks requiring high reliability to provide end-to-end
protection, ensuring network reliability. If a primary CR-LSP fails, traffic rapidly switches to a
backup CR-LSP, ensuring uninterrupted traffic transmission.
Hot standby and ordinary backup modes are supported. If both primary and backup CR-LSPs
fail, best-effort paths are established. Table 3-4 lists CR-LSP backup modes.
Table 3-4 CR-LSP backup modes
Backup Configuration Advantage Shortcomin

Mode Description Mode g
Hot A hot-standby CR-LSP Manually A rapid traffic If dynamic

standby is set up over a separate configured. switchover can bandwidth
path immediately after Configured using be performed. adjustment is
a primary CR-LSP is a TE attribute disabled,
set up. template. additional
bandwidth
needs to be
reserved for a
hot-standby
CR-LSP.
Ordinary The system attempts to Manually No additional Ordinary

backup set up an ordinary configured. bandwidth is backup
backup CR-LSP if a Configured using needed. performs a
primary CR-LSP fails. a TE attribute traffic
template. switchover
slower than
hot standby.
Best-effort The system establishes Manually Establishing a Some quality

path a best-effort path over configured. best-effort of service
an available path if both path is easy (QoS)
the primary and backup and a few requirements
CR-LSPs fail. constraints are cannot be
needed. met.
On the network shown in Figure 3-1, a primary CR-LSP is set up over a path PE1 -> P1 -> PE2;
a backup CR-LSP is set up over a path PE1 -> P2 -> PE2; a best-effort path is set up over a path
PE1 -> P2 -> P1 -> PE2.

Figure 3-1 Schematic diagram for a best-effort path

P1 P2
Primary path
PE1 PE2 Backup path
Best-effort path
A CR-LSP backup mode can be configured as needed. Table 3-5 lists supported combinations
(marked "√") of CR-LSP backup modes.
Table 3-5 Combinations of CR-LSP backup modes
Ordinary Best-Effort
Hot Hot Standby Ordinary Backup Path
Standby (Configured Backup (Configured
(Manually Using a TE (Manually Using a TE
Configured Attribute Configured Attribute
) Template) ) Template)
√ √
√ √
√ √
√ √ √
√ √
Before configuring CR-LSP backup, complete the following tasks:
l Sett up a primary RSVP-TE tunnel.

l Enable MPLS, MPLS TE, and RSVP-TE globally and on interfaces of each node along a
backup CR-LSP. (For the configuration procedure, see 3.5.2 Enabling MPLS TE and
RSVP-TE.)
Data Preparation
To configure CR-LSP backup, you need the following data.
No. Data
1 Backup mode
2 (Optional) Explicit path for a backup CR-LSP
3 (Optional) Affinity property of a backup CR-LSP
4 (Optional) Hop limit of a backup CR-LSP
3.21.2 Configuring CR-LSP Backup

CR-LSP backup can be configured to allow traffic to switch from a primary CR-LSP to a backup
CR-LSP, providing end-to-end protection.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mpls te backup { hot-standby [ wtr interval ] | ordinary }
The mode of establishing a backup CR-LSP is configured.
NOTE
A tunnel interface cannot be used for both a bypass tunnel and a backup tunnel. A protection failure will
occur if the mpls te backup and mpls te bypass-tunnel commands are run on the tunnel interface, or if
the mpls te backup and mpls te protected-interface commands are run on the tunnel interface.
A tunnel interface cannot be used for both a bypass tunnel and a protection tunnel in a tunnel protection
group. A protection failure will occur if the mpls te backup and mpls te protection tunnel commands
are run on the tunnel interface.
After hot standby or ordinary backup is configured, the system automatically selects a path for
a backup CR-LSP. To specify a path for a backup CR-LSP, repeatedly perform one or more of
the following steps.
mpls te path explicit-path path-name secondary

An explicit path is specified for the backup CR-LSP.
NOTE
Use a separate explicit path for the backup CR-LSP to prevent the backup CR-LSP from completely
overlapping its primary CR-LSP. Protection will fail if the backup CR-LSP completely overlaps its primary
CR-LSP.
The mpls te path explicit-path command can be run successfully only after an explicit path is set up by
running the explicit-path command in the system view, and the nodes on the path are specified.

mpls te affinity property properties [ mask mask-value ] secondary
The affinity property is configured for the backup CR-LSP.
The default affinity property is 0x0.

mpls te hop-limit hop-limit-value secondary
The hop limit is set for the backup CR-LSP.
The default hop limit is 32.

mpls te backup hot-standby overlap-path
The path overlapping function is configured for the hot-standby CR-LSP.
By default, a primary CR-LSP and hot-standby CR-LSP are separated. If the network topology
does not meet this requirement, the hot-standby CR-LSP cannot be established. The path
overlapping function allows a hot-standby CR-LSP to use some links of a primary CR-LSP, to
secure the establishment of the hot-standby CR-LSP.
Step 8 Run:
mpls te commit
----End
3.21.3 (Optional) Configuring Forcible Switchover

If a backup CR-LSP has been established and a primary CR-LSP needs to be adjusted, configure
the forcible switchover function to switch traffic from the primary CR-LSP to the backup CR-
LSP. After adjusting the primary CR-LSP, switch traffic back to the primary CR-LSP. This
process prevents traffic loss during the primary CR-LSP adjustment.
Procedure
l Before adjusting a primary CR-LSP, perform the following steps:
1. Run:
system-view

2. Run:


3. Run:
hotstandby-switch force
Traffic is switched to a backup CR-LSP.
NOTE
To prevent traffic loss, check that a backup CR-LSP has been established before running the
hotstandby-switch force command.
4. Run:
mpls te commit

l After adjusting the primary CR-LSP, perform the following steps:
1. Run:
system-view

2. Run:

3. Run:
hotstandby-switch clear
Traffic is switched backup to the primary CR-LSP.

4. Run:
mpls te commit
----End
3.21.4 (Optional) Locking a Backup CR-LSP Attribute Template

A CR-LSP attribute template can be locked on the ingress. If a CR-LSP has been established
using the locked CR-LSP attribute template, the CR-LSP will not be unnecessarily reestablished
using another template with a higher priority, efficiently using system resources.
Context
A maximum of three hot-standby or ordinary backup attribute templates can be used for
establishing a hot-standby or an ordinary CR-LSP. TE attribute templates are prioritized. The
system attempts to use each template in ascending order by priority to establish a backup CR-
LSP.
If an existing backup CR-LSP is set up using a lower-priority attribute template, the system
automatically attempts to set up a new backup CR-LSP using a higher-priority attribute template,
which is unneeded sometimes. Locking a CR-LSP attribute template allows the existing CR-
LSP to keep transmitting traffic without triggering unneeded traffic switchovers, efficiently
using system resources.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mpls te primary-lsp-constraint { dynamic | lsp-attribute lsp-attribute-name }
An attribute template is specified for setting up a primary CR-LSP.

Step 4 Run either of the following commands as needed to establish a backup CR-LSP:
l To establish an ordinary backup CR-LSP, run:
mpls te ordinary-lsp-constraint number { dynamic | lsp-attribute lsp-attribute-
name }
l To establish a hot-standby CR-LSP, run:

mpls te hotstandby-lsp-constraint number { dynamic | lsp-attribute lsp-
attribute-name }
Step 5 Run either of the following commands as needed to lock a backup CR-LSP attribute template:
l To lock an attribute template for an ordinary backup CR-LSP, run:
mpls te backup ordinary-lsp-constraint lock
l To lock an attribute template for a hot-standby CR-LSP, run:

mpls te backup hotstandby-lsp-constraint lock
NOTE
A used attribute template can be unlocked after the undo mpls te backup ordinary-lsp-constraint lock or
undo mpls te backup hotstandby-lsp-constraint lock command is run. After unlocking templates, the system
uses each available template in ascending order by priority. If a template has a higher priority than that of the
currently used template, the system establishes a CR-LSP using the higher-priority template.
Step 6 Run:
mpls te commit
----End
3.21.5 (Optional) Configuring Dynamic Bandwidth for Hot-

Standby CR-LSPs
Dynamic bandwidth can be configured on the ingress for hot-standby CR-LSPs. This allows
hot-standby CR-LSPs to be established only if the primary CR-LSP fails, efficiently using
bandwidth resources.
Context
Hot-standby CR-LSPs are established using reserved bandwidth resources by default. The
dynamic bandwidth function can be configured to allow the system to create a primary CR-LSP
and a hot-standby CR-LSP with the bandwidth of 0 bit/s simultaneously. The hot-standby CR-

LSP does not use bandwidth resources before the primary CR-LSP fails. If the primary tunnel
fails, the system uses the make-before-break mechanism to reestablish a hot-standby CR-LSP
with the desired bandwidth. If bandwidth resources are insufficient, the system is unable to
reestablish a hot-standby CR-LSP with the desired bandwidth, and therefore switches traffic to
the hot-standby CR-LSP with no bandwidth, ensuring uninterrupted traffic transmission.
Procedure
l Perform the following steps to enable the dynamic bandwidth function for hot-standby CR-
LSPs that are established not using attribute templates:
1. Run:
system-view

2. Run:

3. Run:

4. Run:
mpls te backup hot-standby dynamic-bandwidth
The dynamic bandwidth function is enabled for hot-standby CR-LSPs.
NOTE
l If a hot-standby CR-LSP has been established before the dynamic bandwidth function is enabled,
the system uses the make-before-break mechanism to establish a new hot-standby CR-LSP with
the bandwidth of 0 bit/s to replace the existing hot-standby CR-LSP.
l The undo mpls te backup hot-standby dynamic-bandwidth command can be used to disable
the dynamic bandwidth function. This allows the hot-standby CR-LSP with no bandwidth to
obtain bandwidth.
5. Run:
mpls te commit

l Perform the following steps to enable the dynamic bandwidth function for hot-standby CR-
LSPs that are established using attribute templates:
1. Run:
system-view

2. Run:

3. Run:

4. Run:
mpls te backup hotstandby-lsp-constraint dynamic-bandwidth
The dynamic bandwidth function is enabled for hot-standby CR-LSPs.
NOTE
l If a hot-standby CR-LSP has been established before the dynamic bandwidth function is enabled,
the system uses the make-before-break mechanism to establish a new hot-standby CR-LSP with
no bandwidth to replace the existing hot-standby CR-LSP.
l The undo mpls te backup hot-standby dynamic-bandwidth command can be used to disable
the dynamic bandwidth function. This allows the hot-standby CR-LSP with no bandwidth to
obtain bandwidth.
5. Run:
mpls te commit
----End
3.21.6 (Optional) Configuring a Best-Effort Path

A best-effort path is configured on the ingress of a primary CR-LSP to take over traffic if both
the primary and backup CR-LSPs fail.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls te backup ordinary best-effort
A best-effort path is configured.
NOTE
A tunnel interface cannot be used for both a best-effort path and a manually configured ordinary backup
tunnel. A protection failure will occur if the mpls te backup ordinary best-effort and mpls te backup
ordinary commands are run on the tunnel interface.
To establish a best-effort path over a specified path, run either or both of step 4 and step 5.

mpls te affinity property properties [ mask mask-value ] best-effort
The affinity property of the best-effort path is configured.
The default affinity property is 0x0.

mpls te hop-limit hop-limit-value best-effort

The hop limit of the best-effort path is set.
The default hop limit is 32.
Step 6 Run:
mpls te commit
----End

After configuring CR-LSP backup, you can view information about the tunnel interface and
backup status.
Prerequisites
CR-LSP backup has been configured.
Procedure
l Run the display mpls te tunnel-interface [ tunnel tunnel-number ] command to check
information about a tunnel interface on the ingress.
l Run the display mpls te hot-standby state { all [ verbose ] | interface tunnel interface-
number } command to check information about the hot-standby status.
id local-lsp-id ] [ lsr-role { all | egress | ingress | remote | transit } ] [ name tunnel-
name ] [ { incoming-interface | interface | outgoing-interface } interface-type interface-
number ] [ te-class0 | te-class1 | te-class2 | te-class3 | te-class4 | te-class5 | te-class6 | te-
class7 ] [ verbose ] command to check CR-LSP information.
----End
Example
After configuring hot standby, run the display mpls te tunnel-interface command to view
information about the path used by a hot-standby CR-LSP.
<HUAWEI> display mpls te tunnel-interface
----------------------------------------------------------------
Tunnel1/0/0
----------------------------------------------------------------
Tunnel State Desc : UP
Active LSP : Hot-Standby LSP
Session ID : 100
Run the display mpls te hot-standby state command to view the status of the hot-standby CR-
LSP.
<HUAWEI> display mpls te hot-standby state interface Tunnel 1/0/0

----------------------------------------------------------------
Verbose information about the Tunnel1/0/0 hot-standby state
----------------------------------------------------------------
tunnel name : Tunnel1/0/0
session id : 100
main LSP token : 0x100201a
hot-standby LSP token : 0x100201b
HSB switch result : Best-Effort LSP
HSB switch reason : -
WTR config time : 20s
WTR remain time : -
using overlapped path : -
current state : wait to restore
3.22 Configuring Synchronization of the Bypass Tunnel and

the Backup CR-LSP
This section describes that after the primary CR-LSP is faulty, the system starts the TE FRR
bypass tunnel and tries to restore the primary CR-LSP the same time it sets up a backup CR-
LSP.

Before configuring synchronization of the bypass tunnel and the backup CR-LSP, familiarize
yourself with the usage scenario, complete the pre-configuration tasks, and obtain the data
Usage Scenario
To protect important links and nodes, you can configure the TE FRR bypass tunnel and the end-
to-end backup CR-LSP together. The backup CR-LSP is more reliable than the TE FRR bypass
tunnel. Therefore, to improve the security of the tunnel, you are recommended to configure
synchronization of the TE FRR bypass tunnel and the backup CR-LSP.
l In ordinary backup mode, the following situations occur:

– When the protected link or node is faulty, the system switches traffic to the TE FRR
bypass tunnel and tries to restore the primary CR-LSP. At the same time, the system
tries to set up a backup CR-LSP.
– When the backup CR-LSP is set up successfully and the primary CR-LSP is not restored,
traffic is switched to the backup CR-LSP.
– When the backup CR-LSP fails to be set up and the primary CR-LSP is not restored,
traffic still passes through the TE FRR bypass tunnel.
l In hot standby mode, the following situations occur:
– If the backup CR-LSP is in the Up state and the protected link or node is faulty, traffic
is switched to the TE FRR bypass tunnel and then immediately switched to the backup
CR-LSP. At the same time, the system tries to restore the primary CR-LSP.
– If the backup CR-LSP is in the Down state, the processing of hot standby is the same
as the processing of ordinary backup.
When the primary CR-LSP is Up and the hot standby CR-LSP is also in the Up state, more
bandwidth resources are needed. The ordinary CR-LSP is set up only when the primary CR-LSP

is in the FRR-in-use state. That is, when the primary CR-LSP works normally, no more
bandwidth resources are needed. Therefore, the ordinary backup is recommended.
Before configuring synchronization of the bypass tunnel and the backup CR-LSP, complete the
following tasks:
l Set up a primary RSVP-TE tunnel.

l Configure manual MPLS TE FRR or MPLS TE Auto FRR. (See the section Configuring
TE Manual FRR or the section Configuring MPLS Auto TE FRR.)
l Configure the backup CR-LSP (except for the best-effort path) in either hot standby or
ordinary backup mode. (See the section Configuring CR-LSP Backup.)
Data Preparation
To configure synchronization of the bypass tunnel and the backup CR-LSP, you need the
following data.
No. Data
1 Protection policy of TE FRR, that is, to protect the link or the node
2 Backup mode
3.22.2 Enabling Synchronization of the Bypass Tunnel and the

Backup CR-LSP
By configuring synchronization of the bypass tunnel and the backup CR-LSP, you can protect
the entire CR-LSP.
Context
Perform the following steps on the ingress LSR of the primary tunnel:
NOTE
Before the configuration, you must configure the end-to-end protection (except for the best-effort path) in
either hot standby mode or ordinary backup mode and the TE FRR partial protection.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
mpls te backup frr-in-use
When the primary CR-LSP is faulty (that is, the primary CR-LSP is in FRR-in-use state), the
system starts the TE FRR bypass tunnel and tries to restore the primary CR-LSP. At the same
time, the system tries to set up a backup CR-LSP.
Step 4 Run:
mpls te commit
The tunnel configurations are committed.
Step 5 Run:
quit
----End

After the configuration of synchronization of the bypass tunnel and the backup CR-LSP, you
can view information about the bypass tunnel and the backup CR-LSP.
Prerequisites
All configurations of synchronization of the bypass tunnel and the backup CR-LSP are complete.
Procedure
l Run the display mpls te tunnel-interface [ tunnel interface-number | auto-bypass-
tunnel [ tunnel-name ] ] command to view information about the tunnel.
----End
3.23 Configuring RSVP GR

This section describes how to configure RSVP-TE GR so that devices along an RSVP-TE tunnel
can retain RSVP sessions during a master/slave switchover.

Before configuring RSVP-TE GR, familiarize yourself with the usage scenario, complete the
Usage Scenario
When an RSVP node performs an active/standby switchover, an RSVP adjacency relationship
between the local node and its neighbor is torn down because of signaling protocol timeout,
which results in removal of a CR-LSP and a temporary traffic interruption.
RSVP GR resolves the preceding problem. The RSVP GR mechanism allows the adjacency
relationship to be reestablished between neighbors without tearing down RSVP sessions.

The NE80E/40E performs FRR switching during the RSVP GR process. FRR protects traffic if
a switchover is performed on the PLR node, PLR upstream node, MP, or MP downstream node
and if the outbound interface of the PLR primary tunnel fails. FRR helps reduce the fault period.
NOTE
When FRR is performed during the RSVP GR process, set the timeout multiplier in the PSB and RSB to
a value greater than or equal to five, which prevents PSB and RSB loss due to oversized data. For detailed
configurations, see (Optional) Modifying the PSB and RSB Timeout Multiplier.
Before configuring RSVP GR, complete the following tasks:
l Configure an RSVP-TE tunnel.

l Enable IS-IS GR or OSPF GR on each LSR.
Data Preparation
To configure RSVP GR, you need the following data.
No. Data
1 IGP parameters:
l IS-IS: IS-IS process ID, Network Entity Title (NET), and IS-IS level of each node
l OSPF: OSPF process ID and AS number
2 MPLS LSR ID of each node
3 Tunnel interface number and tunnel ID
4 (Optional) Basic RSVP GR time
3.23.2 Enabling the RSVP Hello Extension Function

This section describes how to enable the RSVP Hello extension function, which enables a device
to quickly check reachability between RSVP nodes.
Context
Perform the following steps on a GR node and its neighboring nodes:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls

Step 3 Run:
mpls rsvp-te hello
The RSVP Hello extension function is enabled globally.
Step 4 Run:
quit
Step 5 Run:
The RSVP interface view is displayed.
Step 6 Run:
mpls rsvp-te hello
The RSVP Hello extension function is enabled on the interface.
By default, although the RSVP Hello extension function has been enabled globally, this function
is disabled on RSVP-enabled interfaces.
----End
3.23.3 Enabling Full GR of RSVP

This section describes how to configure RSVP full GR, which helps ensure uninterrupted data
transmission on the forwarding plane.
Context
Perform the following steps on a GR node:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls rsvp-te hello full-gr
The RSVP GR function and the function of supporting RSVP GR on a neighbor are enabled.
By default, the RSVP GR function and RSVP GR support function are disabled.
----End

3.23.4 (Optional) Enabling the RSVP GR Support Function

This section describes how to enable the RSVP GR support function, which enables a device to
support the GR capability of its neighbor.
Context
RSVP GR takes effect on the RSVP GR-enabled neighbor automatically after the neighbor is
enabled with RSVP full GR. If the GR node's neighbor is a GR node, do not perform the following
steps. If the GR node's neighbor is not a GR node, perform the following steps:
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls rsvp-te
RSVP-TE is enabled.
Step 4 Run:
mpls rsvp-te hello
The RSVP Hello function is enabled on the local node.

Step 5 Run:
mpls rsvp-te hello support-peer-gr
The local node is enabled to support RSVP GR on its neighbor.
----End
3.23.5 (Optional) Configuring Hello Sessions Between RSVP GR

Nodes
This section describes how to configure the Hello sessions between RSVP GR nodes. On a
network enabled with TE FRR, a Hello session needs to be set up between a PLR and an MP.
Context
If TE FRR is deployed, a Hello session must be established between a PLR and an MP. Perform
the following steps on the PLR and MP:
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls
Step 3 Run:
mpls rsvp-te
RSVP-TE is enabled.
Step 4 Run:
mpls rsvp-te hello
The RSVP Hello function is enabled on the local node.
Step 5 Run:
mpls rsvp-te hello nodeid-session ip-address
A Hello session is set up between a Restarter and its neighbor node.
The ip-address value is the LSR ID of the RSVP neighbor.
----End
3.23.6 (Optional) Modifying Basic Time

This section describes how to modify the basic time. By setting the basic time and the number
of ingress LSPs, you can modify the restart time.
Context
After an active/standby switchover starts, an RSVP GR node starts an RSVP smoothing period,
during which the data plane continues forwarding data if the control plane is not restored. After
RSVP smoothing is completed, a restart timer is started.
Restart timer value = Basic time + Number of ingress LSPs x 60 ms
In this formula, the default basic time is 90 seconds. The basic time can be set., and the number
of LSPs is the number of LSPs with the local node functioning as the ingress.
After the restart timer expires, the recovery timer is started.
Recovery timer = Restart time + Total number of LSPs x 40 ms
Perform the following steps on the GR node to modify the basic time:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls

Step 3 Run:
mpls rsvp-te hello basic-restart-time basic-restart-time
The RSVP GR basic time is set.
By default, the RSVP GR basic time is 90 seconds.
----End

After the configuration of RSVP GR is complete, you can see that the TE tunnel is properly
forwards data during the GR process.
Procedure
l Run the display mpls rsvp-te graceful-restart command to check the local RSVP GR
status.
l Run the display mpls rsvp-te graceful-restart peer [ { interface interface-type interface-
number | node-id } [ ip-address ] ] command to check the RSVP GR status on a neighbor.
----End
Example
Run the display mpls rsvp-te graceful-restart command on a restarted node. If GR-Self GR-
Support is displayed in the Graceful-Restart Capability field, the local device has the RSVP
GR function. During the GR process, in the command output, Restart time going on or
Recovery time going on is displayed in the GR Status field.
<HUAWEI> display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 2.2.2.2 Graceful-Restart Capability: GR-Self GR-Support
Restart Time: 90060 Milli Second
Recovery Time: 0 Milli Second
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr Path message count: 0
Send Gr Path message count: 0
Received RecoveryPath message count: 0
Send RecoveryPath message count: 0
Run the display mpls rsvp-te graceful-restart peer command on the restarted node.
Information displayed in the Neighbor Capability field has specific meanings:
l Can Do Self GR: The neighbor node is enabled with the RSVP GR capability.
l Can Support GR: The neighbor node is enabled with the RSVP GR supporting capability.
l Both Can Do Self GR and Can Support GR: The neighbor node is enabled with the RSVP
GR function, and the RSVP GR support function.
<HUAWEI> display mpls rsvp-te graceful-restart peer
Neighbor on Interface GigabitEthernet1/0/0
Neighbor Addr: 10.1.1.1
SrcInstance: 47860 NbrSrcInstance: 49409
Neighbor Capability:

Can Do Self GR
Can Support GR
GR Status: Normal
Stored GR message number: 0
PSB Count: 0 RSB Count: 0
Total to be Recover PSB Count: 0 Recovered PSB Count: 0
Total to be Recover RSB Count: 0 Recovered RSB Count: 0
P2MP PSB Count: 0 P2MP RSB Count: 0
Total to be Recover P2MP PSB Count: 0 Recovered P2MP PSB Count: 0
Total to be Recover P2MP RSB Count: 0 Recovered P2MP RSB Count: 0
Run the ping lsp te tunnel command on the neighbor node and immediately run the slave
switchover command in the system view on the restarted node. Data forwarded along the TE
tunnel is not interrupted during GR.
3.24 Configuring Static BFD for CR-LSP

This section describes how to configure a static BFD session to detect link faults in static CR-
LSPs or RSVP CR-LSPs.

Before configuring static BFD for CR-LSP, familiarize yourself with the usage scenario,
Usage Scenario
BFD monitors static or RSVP CR-LSPs.
BFD for static CR-LSP and BFD for RSVP CR-LSP can be used to replace MPLS OAM to
monitor the MPLS TE tunnel protection groups and trigger primary/backup CR-LSP
switchovers. BFD for CR-LSP monitors primary and hot-standby CR-LSPs and triggers CR-
LSP switchovers.
For details about MPLS OAM configuration, see "MPLS OAM Configuration" in NE80E/40E
Configuration Guide - MPLS.
NOTE
For the same CR-LSP, MPLS OAM and BFD cannot be configured simultaneously.
BFD for LSP can function properly even though the forward path is an LSP and the reverse path is an IP
link. The forward path and the reverse path must be established over the same link. If the forward and its
reverse paths use different links, and a fault occurs, BFD cannot identify the faulty path. Before you deploy
BFD, ensure that the forward and reverse paths are over the same link so that BFD can correctly identify
the faulty path.
Before configuring static BFD for CR-LSP, complete one of the following tasks:
l Configure a static CR-LSP.

l Configure an RSVP-TE tunnel.
l Configure CR-LSP backup.

l Configure a tunnel protection group.

NOTE
For details about the configuration of the MPLS TE tunnel protection group for the MPLS TE tunnel, see
"MPLS OAM Configuration" in HUAWEI NetEngine80E/40E Router Configuration Guide - MPLS.
Data Preparation
To configure static BFD for CR-LSP, you need the following data.
No. Data
1 BFD session name
2 Reverse channel (IP link, dynamic LSP, static LSP, or MPLS TE tunnel)
3 Local and remote discriminators of the BFD session
4 Minimum interval between BFD packet transmissions
5 Minimum interval between BFD packet receipts
6 Local BFD detection multiplier
3.24.2 Enabling BFD Globally

This section describes how to enable BFD globally. To configure static BFD for CR-LSP, you
must enable BFD globally on the ingress and the egress of a tunnel.
Context
Perform the following steps on the ingress and egress of a tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
----End
3.24.3 Configuring BFD Parameters on the Ingress of the Tunnel

This section describes how to configure BFD parameters on the ingress of the tunnel. The BFD
parameters configured include the local and remote discriminators, local minimum intervals at
which BFD packets are sent and received, and BFD detection multiplier.

Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd bfd-name bind mpls-te interface tunnel interface-number te-lsp [ backup ]
BFD is configured to monitor the primary or backup CR-LSP bound to a specified tunnel.
The backup parameter enables BFD to monitor backup CR-LSPs.
Step 3 Run:
Step 4 Run:

By default, the value is 10 milliseconds.


By default, the local detection multiplier is 3.

NOTE
Actual local sending interval = MAX { Configured local sending interval, Configured remote receiving
interval }
Actual local receiving interval = MAX { Configured remote sending interval, Configured local receiving
interval }
Actual local detection interval = Actual local receiving interval x Configured remote detection multiplier
For example:
l The local sending and receiving intervals are set to 200 ms and 300 ms respectively and the detection
multiplier is set to 4.
l The remote sending and receiving intervals are set to 100 ms and 600 ms respectively and the detection
Then,
l Actual local sending interval = MAX {200 ms, 600 ms} = 600 ms; Actual local receiving interval =
MAX {100 ms, 300 ms} = 300 ms; Actual local detection interval is 300 ms x 5 = 1500 ms.
l Actual remote sending interval = MAX {100 ms, 300 ms} = 300 ms; Actual remote receiving interval
= MAX {200 ms, 600 ms} = 600 ms; Actual remote detection interval is 600 ms x 4 = 2400 ms.
Step 8 Run:
process-pst
The system is enabled to change the port status table (PST) when the BFD status changes.
When the BFD status changes, BFD notifies the application of the change, triggering a fast
switchover between the primary and bypass CR-LSPs.
Step 9 Run:
notify neighbor-down
A BFD session is configured to notify the upper layer protocol when the BFD session detects a
neighbor Down event.
In most cases, when you use a BFD session to detect link faults, the BFD session notifies the
upper layer protocol of a link fault in the following scenarios:
l When the BFD detection time expires, the BFD session notifies the upper layer protocol.
BFD sessions must be configured on both ends. If the BFD session on the local end does not
receive any BFD packets from the remote end within the detection time, the BFD session on
the local end concludes that the link fails and notifies the upper layer protocol of the link
fault.
l When a BFD session detects a neighbor Down event, the BFD session notifies the upper
layer protocol. If the BFD session on the local end detects a neighbor Down event within the
detection time, the BFD session on the local end directly notifies the upper layer protocol of
the neighbor Down event.
When you use a BFD session to detect faults on an LSP, you need only be concerned about
whether a fault occurs on the link from the local end to remote end. In this situation, run the
notify neighbor-down command to configure the BFD session to notify the upper layer protocol
only when the BFD session detects a neighbor Down event. This configuration prevents the BFD
session from notifying the upper layer protocol when the BFD detection time expires and ensures
that services are not interrupted.
Step 10 Run:
commit

----End
3.24.4 Configuring BFD Parameters on the Egress of the Tunnel

This section describes how to configure BFD parameters on the ingress of a tunnel. The BFD
parameters include the local and remote discriminators, local minimum intervals at which BFD
packets are sent and received, and BFD detection multiplier.
Context
Perform the following steps on the egress of a tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Configure a reverse tunnel to inform the ingress of a fault if the fault occurs. The reverse tunnel
can be the IP link, LSP, or TE tunnel. To ensure that the forward and reverse paths are over the
same link, a CR-LSP is preferentially selected to notify the ingress of an LSP fault. Choose one
of the following configurations as required:
bfd bfd-name bind peer-ip ip-address [ vpn-instance vpn-name ] [ interface
interface-type interface-number] [ source-ip ip-address ]
l For an LDP LSP, run:


l For a CR-LSP, run:

bfd bfd-name bind mpls-te interface tunnel interface-number te-lsp [ backup ]
l For a TE tunnel, run:

bfd bfd-name bind mpls-te interface tunnel interface-number
Step 3 Run:
Step 4 Run:

The minimum interval at which the local end sends BFD packets is set.


The minimum interval at which the local end receives BFD packets is set.

By default, the value is 3.

process-pst
single-hop IP link is used as a reverse tunnel, this command can be configured, because the
process-pst command can be only configured for BFD single-link detection.
Step 9 Run:
fault.
Step 10 Run:
commit
----End


After the configuration of static BFD for CR-LSP, you can view that the status of a BFD session
is Up.
Procedure
l Run the display bfd configuration mpls-te interface tunnel interface-number te-lsp
[ verbose ] command to check BFD configurations on the ingress.
l Run the following commands to check BFD configurations on the egress:
– Run the display bfd configuration all [ for-ip | for-lsp | for-te ] [ verbose ] command
to check all BFD configurations.
– Run the display bfd configuration static [ for-ip | for-lsp | for-te | name bfd-name ]
[ verbose ] command to check the static BFD configurations.
– Run the display bfd configuration peer-ip peer-ip [ vpn-instance vpn-instance-
name ] [ verbose ] command to check the configurations of BFD with the reverse path
over an IP link.
– Run the display bfd configuration static-lsp lsp-name [ verbose ] command to check
the configurations of BFD with the reverse path over a static LSP.
– Run the display bfd configuration ldp-lsp peer-ip peer-ip nexthop nexthop [
interface interface-type interface-number ] [ verbose ] command to check the
configurations of BFD with the reverse path over an LDP LSP.
– Run the display bfd configuration mpls-te interface tunnel interface-number te-lsp
[ verbose ] command to check the configurations of BFD with the reverse path over a
CR-LSP.
– Run the display bfd configuration mpls-te interface tunnel interface-number
[ verbose ] command to check the configurations of BFD with the reverse path over a
TE tunnel.
l Run the display bfd session mpls-te interface tunnel interface-number te-lsp
[ verbose ] command to check BFD session configurations on the ingress.
l Run the following commands to check BFD session configurations on the egress:
– Run the display bfd session all [ for-ip | for-lsp | for-te ] [ slot slot-id | verbose ]
command to check all the BFD configurations.
– Run the display bfd session static [ for-ip | for-lsp | for-te ] [ slot slot-id | verbose ]
command to check the static BFD configurations.
– Run the display bfd session peer-ip peer-ip [ vpn-instance vpn-instance-name ]
[ slot slot-id | verbose ] command to check the configurations of BFD with the backward
channel being an IP link.
– Run the display bfd session static-lsp lsp-name [ verbose ] command to check the
configurations of BFD with the backward channel being a static LSP.
– Run the display bfd session ldp-lsp peer-ip peer-ip [ interface interface-type
interface-number ] [ verbose ] command to check the configurations of BFD with the
backward channel being an LDP LSP.

– Run the display bfd session mpls-te interface tunnel interface-number te-lsp
[ verbose ] command to check the configurations of BFD with the backward channel
being a CR-LSP.
– Run the display bfd session mpls-te interface tunnel interface-number [ verbose ]
command to check the configurations of BFD with the backward channel being a TE
tunnel.
l Run the following command to check BFD statistics:
– Run the display bfd statistics [ slot slot-id ] command to check all BFD statistics.
– Run the display bfd statistics session all [ for-ip | for-lsp | for-te ] [ slot slot-id ]
command to check all BFD session statistics.
– Run the display bfd statistics session peer-ip peer-ip [ vpn-instance vpn-instance-
name ] [ slot slot-id ] command to check statistics about the BFD session that detects
faults in the IP link.
– Run the display bfd statistics session static-lsp lsp-name command to check statistics
about the BFD session that detects faults in the static LSP.
– Run the display bfd statistics session ldp-lsp peer-ip peer-ip [ interface interface-
type interface-number ] command to check statistics of the BFD session that detects
faults in the LDP LSP.
– Run the display bfd statistics session mpls-te interface tunnel interface-number te-
lsp command to check statistics about the BFD session that detects faults in the CR-
LSP.
----End
Example
After completing the configuration, run the preceding commands to check BFD session status.
The BFD session is Up.
3.25 Configuring Static BFD for TE

This section describes how to configure a static BFD session to detect faults in a TE tunnel.

Before configuring static BFD for TE, familiarize yourself with the usage scenario, complete
Usage Scenario
BFD for TE allows applications, such as VPN FRR or VLL FRR to fast switch traffic if the
primary tunnel fails, preventing service interruptions.
NOTE
MPLS OAM and BFD cannot be configured together on a TE tunnel.

BFD for LSP can function properly though the forward path is an LSP and the backward path is an IP link.
The forward path and the backward path must be established over the same link; otherwise, if a fault occurs,
BFD cannot identify the faulty path. Before deploying BFD, ensure that the forward and backward paths
are over the same link so that BFD can correctly identify the faulty path.

Before configuring static BFD for TE, configure static CR-LSP or an MPLS TE tunnel.
Data Preparation
To configure static BFD for TE, you need the following data.
No. Data
1 Name of the BFD session
2 Backward channel (IP link, dynamic LSP, static LSP, or MPLS TE tunnel)
3 Local and remote discriminators of the BFD session
4 (Optional) Local minimum interval at which BFD packets are sent
5 (Optional) Local minimum interval at which BFD packets are received
6 (Optional) Local detection multiplier

To configure static BFD for TE, enable BFD globally on the ingress and egress nodes of a tunnel.
Context
Perform the following steps on the ingress and egress of a tunnel:
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
----End
3.25.3 Configuring BFD Parameters on the Ingress of the Tunnel

The BFD parameters configured on the ingress node include the local and remote discriminators,
local minimum intervals at which BFD packets are sent and received, and BFD detection
multiplier, which determine the establishment of a BFD session.
Context

Procedure
Step 1 Run:
system-view
Step 2 Run:
BFD is configured to detect faults in a specified tunnel.
Step 3 Run:
The local discriminator is configured.
Step 4 Run:
The remote discriminator is configured.



Step 8 Run:
process-pst
Modifying the protection status table is enabled.
This command is used to notify an application protocol of TE tunnel status changes.
Step 9 Run:

fault.
Step 10 Run:
commit
The BFD configuration is committed.
NOTE
If the status of the tunnel to be checked is Down, the BFD session cannot be set up.
interval }
interval }
Actual local detection interval = Actual local receiving interval x Configured remote detection multiplier.
For example:
l The local sending and receiving intervals are set to 200 ms and 300 ms respectively and the detection
l The remote sending and receiving intervals are set to 100 ms and 600 ms respectively and the detection
Then,
l Actual local sending interval = MAX {200 ms, 600 ms} = 600 ms; Actual local receiving interval =
MAX {100 ms, 300 ms} = 300 ms; actual local detection interval is 300 ms x 5 = 1500 ms.
l Actual remote sending interval = MAX {100 ms, 300 ms} = 300 ms; Actual remote receiving interval
= MAX {200 ms, 600 ms} = 600 ms; Actual remote detection interval is 600 ms x 4 = 2400 ms.
----End
3.25.4 Configuring BFD Parameters on the Egress of the Tunnel

The BFD parameters configured on the egress node include the local and remote discriminators,
local minimum intervals at which BFD packets are sent and received, and BFD detection
multiplier, which determine the establishment of a BFD session.
Context
Perform the following steps on the egress node of a tunnel:
Procedure
Step 1 Run:

system-view
Step 2 Configure a reverse tunnel to inform the ingress of a fault if the fault occurs. The reverse tunnel
can be the IP link, LSP, or TE tunnel. To ensure that the forward and reverse paths are over the
same link, a TE tunnel is preferentially selected to notify the ingress of an LSP fault. Choose
one of the following configurations as required:
bfd bfd-name bind peer-ip ip-address [ vpn-instance vpn-name ] [ interface
interface-type interface-number] [ source-ip ip-address ]
l For an LDP LSP, run:


l For a TE tunnel, run:

Step 3 Run:
The local discriminator is configured.
Step 4 Run:
The remote discriminator is configured.



By default, the value is 3.

process-pst

single-hop IP link is used as a reverse tunnel, this command can be configured. Because the
process-pst command can be only configured for BFD single-link detection.
Step 9 Run:
fault.
Step 10 Run:
commit
----End

After the configuration of static BFD for TE, you can view that the status of a BFD session is
Up.
Procedure
l Run the display bfd configuration mpls-te interface tunnel interface-number
[ verbose ] command to check BFD configurations on the ingress.
l Run the following commands to check BFD configurations on the egress:
– Run the display bfd configuration all [ for-ip | for-lsp | for-te ] [ verbose ] command
to check all information about BFD.
– Run the display bfd configuration static [ for-ip | for-lsp | for-te | name bfd-name ]
[ verbose ] command to check the static BFD configurations.
– Run the display bfd configuration peer-ip peer-ip [ vpn-instance vpn-instance-
name ] [ verbose ] command to check the configurations of BFD with the backward

– Run the display bfd configuration static-lsp lsp-name [ verbose ] command to check
the configurations of BFD with the backward channel being a static LSP.
– Run the display bfd configuration ldp-lsp peer-ip peer-ip nexthop nexthop [
interface interface-type interface-number ] [ verbose ] command to check the
configurations of BFD with the backward channel being an LDP LSP.
– Run the display bfd configuration mpls-te interface tunnel interface-number te-lsp
being a CR-LSP.
– Run the display bfd configuration mpls-te interface tunnel interface-number
being a TE tunnel.
l Run the display bfd session mpls-te interface tunnel interface-number [ verbose ]
command to check BFD session configurations on the ingress.
l Run the following commands to check BFD session configurations on the egress:
– Run the display bfd session all [ for-ip | for-lsp | for-te ] [ slot slot-id | verbose ]
command to check all BFD configurations.
– Run the display bfd session static [ for-ip | for-lsp | for-te ] [ slot slot-id | verbose ]
command to check the configurations of static BFD.
– Run the display bfd session peer-ip peer-ip [ vpn-instance vpn-instance-name ]
[ slot slot-id | verbose ] command to check the configurations of BFD with the backward
– Run the display bfd session static-lsp lsp-name [ verbose ] command to check the
configurations of BFD with the backward channel being a static LSP.
– Run the display bfd session ldp-lsp peer-ip peer-ip [ interface interface-type
interface-number ] [ verbose ] command to check the configurations of BFD with the
backward channel being an LDP LSP.
– Run the display bfd session mpls-te interface tunnel interface-number te-lsp
being a CR-LSP.
– Run the display bfd session mpls-te interface tunnel interface-number [ verbose ]
command to check the configurations of BFD with the backward channel being a TE
tunnel.
l Run the following command to check BFD statistics:
– Run the display bfd statistics [ slot slot-id ] command to check all BFD statistics.
– Run the display bfd statistics session all [ for-ip | for-lsp | for-te ] [ slot slot-id ]
command to check all BFD session statistics.
– Run the display bfd statistics session peer-ip peer-ip [ vpn-instance vpn-instance-
name ] [ slot slot-id ] command to check statistics of the BFD session that detects faults
in the IP link.
– Run the display bfd statistics session static-lsp lsp-name command to check statistics
about the BFD session that detects faults in the static LSP.
– Run the display bfd statistics session ldp-lsp peer-ip peer-ip [ interface interface-
type interface-number ] command to check statistics of the BFD session that detects
faults in the LDP LSP.

– Run the display bfd statistics session mpls-te interface tunnel interface-number te-
lsp command to check statistics of the BFD session that detects faults in the CR-LSP.
----End
Example
After completing the configuration, run the preceding commands to check BFD session status.
The BFD session is Up.
3.26 Configuring Dynamic BFD for CR-LSP

This section describes how to configure a dynamic BFD session to detect link faults in a static
CR-LSP or an RSVP CR-LSP.

Before configuring dynamic BFD for CR-LSP, familiarize yourself with the usage scenario,
Usage Scenario
Compared with static BFD, dynamically creating BFD sessions simplifies configurations and
reduces configuration errors.
BFD detects faults in the following CR-LSPs:
l Static CR-LSP
l RSVP CR-LSP
Currently, dynamic BFD for CR-LSP cannot detect faults in the entire TE tunnel.
NOTE
MPLS OAM and BFD cannot be configured together for one CR-LSP.
Before configuring dynamic BFD for CR-LSP, configure a static CR-LSP or an MPLS TE
tunnel.
Data Preparation
To configure dynamic BFD for CR-LSP, you need the following data.
No. Data
1 Local minimum interval at which BFD packets are sent

No. Data
2 Local minimum interval at which BFD packets are received

To configure dynamic BFD for CR-LSP, enable BFD globally on the ingress node and the egress
node of a tunnel.
Context
Perform the following steps on the ingress and the egress of a TE tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
----End
3.26.3 Enabling the Capability of Dynamically Creating BFD

Sessions on the Ingress
You can enable the ingress node to dynamically create BFD sessions on a TE tunnel in either
of two modes, that is, enabling BFD globally and enabling BFD on a tunnel interface.
Context
Enabling the capability of dynamically creating BFD sessions on a TE tunnel can be
implemented in either of the following methods:
l Enabling MPLS TE BFD Globally if most TE tunnels on the ingress need to dynamically
create BFD sessions
l Enabling MPLS TE BFD on the Tunnel Interface if certain TE tunnels on the ingress
need to dynamically create BFD sessions
Procedure
l Enable MPLS TE BFD globally.

1. Run:
system-view

2. Run:
mpls

3. Run:
mpls te bfd enable
The capability of dynamically creating BFD sessions is enabled on the TE tunnel.

After this command is run in the MPLS view, dynamic BFD for TE is enabled on all
the tunnel interfaces, excluding the interfaces on which dynamic BFD for TE are
blocked.
4. (Optional) Block the capability of dynamically creating BFD sessions for TE on the
tunnel interfaces of the TE tunnels that do not need dynamic BFD for TE.
a. Run:

b. Run:
mpls te bfd block
The capability of dynamically creating BFD sessions on the tunnel interface is

blocked.
c. Run:
mpls te commit
The current configuration on this tunnel interface is committed.

l Enable MPLS TE BFD on a tunnel interface.
1. Run:
system-view

2. Run:

3. Run:
mpls te bfd enable
The capability of dynamically creating BFD sessions is enabled on the TE tunnel.

The command configured in the tunnel interface view takes effect only on the current
tunnel interface.
4. Run:
mpls te commit
The configuration of the TE tunnel is committed.

----End

3.26.4 Enabling the Capability of Passively Creating BFD Sessions

on the Egress
On a unidirectional LSP, creating a BFD session on the active role (ingress node) triggers the
sending of LSP ping request messages to the passive role (egress node). Only after the passive
role receives the ping packets, a BFD session can be automatically set up.
Context
Perform the following steps on the egress:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Step 3 Run:
mpls-passive
The capability of passively creating BFD sessions is enabled.
After this command is run, a BFD session can be created only after the egress receives an LSP
Ping request containing a BFD TLV from the ingress.
----End

BFD parameters are adjusted on the ingress of a tunnel in either of two modes, that is, adjusting
BFD parameters globally and on a tunnel interface.
Context
BFD parameters are adjusted on the ingress of a TE tunnel either of the following modes:
l Adjusting Global BFD Parameters if most TE tunnels on the ingress use the same BFD
parameters
l Adjusting BFD Parameters on an Interface if certain TE tunnels on the ingress need
BFD parameters different from global BFD parameters

NOTE
interval }
interval }
Actual local detection interval = Actual local receiving interval x Configured remote detection multiplier
On the egress of the TE tunnel enabled with the capability of passively creating BFD sessions, the default
values of the receiving interval, sending interval and detection multiplier cannot be adjusted. The default
values of these three parameters are the minimum configurable values on the ingress. Therefore, the BFD
detection interval on the ingress and that on the egress of a TE tunnel are as follows:
l Actual detection interval on the ingress = Configured receiving interval on the ingress x 3
l Actual detection interval on the egress = Configured sending interval on the ingress x Configured
detection multiplier on the ingress
Procedure
l Adjust global BFD parameters.
Perform the following steps on the ingress of a TE tunnel:
1. Run:
system-view

2. Run:
mpls

3. Run:
mpls te bfd { min-tx-interval tx-interval | min-rx-interval tx-interval |
BFD time parameters are adjusted globally.

l Adjust BFD parameters on the tunnel interface.
1. Run:
system-view

2. Run:

3. Run:
mpls te bfd { min-tx-interval tx-interval | min-rx-interval rx-interval |
BFD time parameters are adjusted.

4. Run:
mpls te commit
The current configurations of the TE tunnel interface are committed.
----End


After the configuration of dynamic BFD for CR-LSP, you can view that a CR-LSP is Up and a
BFD session is successfully set up.
Procedure
l Run the display bfd configuration dynamic [ verbose ] command to check the
configuration of dynamic BFD on the ingress.
l Run the display bfd configuration passive-dynamic [ peer-ip peer-ip remote-
discriminator discriminator ] [ verbose ] command to check the configuration of dynamic
BFD on the egress.
l Run the display bfd session dynamic [slot slot-id ] [ verbose ] command to check
information about the BFD session on the ingress.
l Run the display bfd session passive-dynamic [ peer-ip peer-ip remote-discriminator
discriminator ] [slot slot-id ] [ verbose ] command to check information about the BFD
session passively created on the egress.
l Check the BFD statistics.
– Run the display bfd statistics [slot slot-id ] command to check statistics about all BFD
sessions.
– Run the display bfd statistics session dynamic [ slot slot-id ] command to check
statistics about dynamic BFD sessions.
l Run the display mpls bfd session [ statistics | [ protocol { ldp | cr-static | rsvp-te } ] |
[ outgoing-interface interface-type interface-number ] | [ nexthop ip-address ] | [ fec fec-
address ] | verbose | monitor ] command to check information about the MPLS BFD
session.
----End
Example
Run the display bfd session all verbose command on the ingress. The status of the BFD sessions
is Up and the links bound to the sessions are TE LSPs.
Run the display bfd session passive-dynamic verbose command on the egress. The BFD
session created on the egress is a multi-hop BFD session bound to the peer IP address.
3.27 Configuring Dynamic BFD for RSVP

This section describes how to configure a dynamic BFD session to detect faults in links between
RSVP neighbors.

Before configuring dynamic BFD for RSVP, familiarize yourself with the usage scenario,

Usage Scenario
BFD for RSVP is applied to a scenario where TE FRR is used and a Layer 2 device exists on
the primary LSP between a PLR and its downstream neighbors. On a network where GR is
enabled on the PLR and MP, BFD for RSVP is also recommended.
By default, the interval at which RSVP Hello messages are sent is 3 seconds. The interval at
which a neighbor is declared Down is three times the interval at which RSVP Hello messages
are sent. This allows devices to detect a fault in an RSVP neighbor at seconds level.
If a Layer 2 device exists on a link between RSVP neighboring nodes, the neighboring node
cannot rapidly detect the fault after the link fails, resulting in a great loss of data.
BFD detects faults at millisecond level in protected links or nodes. BFD for RSVP rapidly detects
faults in an RSVP neighbor, allowing packets to switch to a backup LSP rapidly.
NOTE
Before configuring BFD for RSVP, configure an RSVP-TE tunnel.
Data Preparation
To configure BFD for RSVP, you need the following data.
No. Data
1 Local minimum interval at which BFD packets are sent
2 Local minimum interval at which BFD packets are received
When modifying BFD session parameters, select the parameters for the BFD sessions shared by
different protocols as follows:
l If the interval at which BFD packets are sent, interval at which BFD packets are received,
and local detection multiplier are set globally and on the interfaces of a node, the parameters
configured on the interfaces are used by a local RSVP protocol.
l If BFD for RSVP and other protocols share a BFD session on a node, the node selects the
smallest time parameters among all protocols as the local parameters.
l The following formulas are applied:
– Actual local sending interval = MAX { Configured local sending interval, Configured
remote receiving interval }
– Actual local receiving interval = MAX { Configured remote sending interval,
Configured local receiving interval }

– Actual local detection interval = Actual local receiving interval x Configured remote
detection multiplier

To configure dynamic BFD for RSVP, you must enable BFD on both ends of RSVP neighbors.
Context
Perform the following steps on the two RSVP neighboring nodes between which a Layer 2 device
resides:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
----End
3.27.3 Enabling BFD for RSVP

You can enable BFD for RSVP in either of two modes, that is, enabling BFD for RSVP globally
and enabling BFD for RSVP on RSVP interfaces.
Context
Enabling BFD for RSVP in the following manners:
l Enabling BFD for RSVP Globally if most RSVP interfaces on a node need BFD for
RSVP.
l Enabling BFD for RSVP on the RSVP Interface if certain RSVP interfaces on a node
need BFD for RSVP.
Procedure
l Enable BFD for RSVP globally.
Perform the following steps on both RSVP neighboring nodes between which a Layer 2
device resides:
1. Run:
system-view

2. Run:
mpls


3. Run:
mpls rsvp-te bfd all-interfaces enable
BFD for RSVP is enabled globally.
After this command is run in the MPLS view, BFD for RSVP is enabled on all RSVP
interfaces except the interfaces with BFD for RSVP that are blocked.
4. (Optional) Block BFD for RSVP on the RSVP interfaces that need not BFD for RSVP.
a. Run:
The view of the RSVP-TE-enabled interface is displayed.

b. Run:
mpls rsvp-te bfd block
BFD for RSVP is blocked on the interface.

l Enable BFD for RSVP on the RSVP interface.
Perform the following steps on the two RSVP neighboring nodes between which a Layer
2 device resides:
1. Run:
system-view

2. Run:

3. Run:
mpls rsvp-te bfd enable
BFD for RSVP is enabled on the RSVP interface.
----End

BFD parameters can be adjusted either globally or on a specific RSVP interface when BFD for
RSVP is configured.
Context
BFD for RSVP parameters are adjusted on the ingress of a TE tunnel either of the following
modes:
l Adjusting Global BFD Parameters if most RSVP interfaces on a node use the same BFD
parameters
l Adjusting BFD Parameters on an RSVP Interface if certain RSVP interfaces require
BFD parameters different from global BFD parameters

Procedure
l Adjust global BFD parameters globally.
2 device resides:
1. Run:
system-view

2. Run:
mpls

3. Run:
mpls rsvp-te bfd all-interfaces { min-tx-interval tx-interval | min-rx-
interval rx-interval | detect-multiplier multiplier }*
BFD parameters are set globally.
NOTE
Parameters are described as follows:

l tx-interval indicates the Desired Min Tx Interval (DMTI), that is, the desired minimum
interval for the local end sending BFD control packets.
l rx-interval indicates the Required Min Rx Interval (RMRI), that is, the supported minimum
interval for the local end receiving BFD control packets.
l multiplier indicates the BFD detection multiplier.
BFD detection parameters that take effect on the local node may be different from the
configured parameters:
l Actual local sending interval = MAX { Locally-configured DMTI, Remotely-configured
RMRI }
l Actual local receiving interval = MAX { Remotely-configured DMTI, Locally-configured
RMRI }
l Actual local detection interval = Actual local receiving interval x Configured remote
detection multiplier
l Adjust BFD parameters on an RSVP interface.
2 device resides:
1. Run:
system-view

2. Run:

3. Run:
mpls rsvp-te bfd { min-tx-interval tx-interval | min-rx-interval rx-
interval | detect-multiplier multiplier }*

BFD parameters on the RSVP interface are adjusted.

----End

After the configuration of dynamic BFD for RSVP, you can view that the status of a BFD session
for RSVP is Up.
Procedure
l Run the display mpls rsvp-te bfd session { all | interface interface-type interface-
number | peer ip-address } [ verbose ] command to check information about the BFD for
RSVP session.
l Run the display mpls rsvp-te [ interface [ interface-type interface-number ] ] command
to check the configuration of RSVP-TE.
l Run the display mpls rsvp-te peer [ interface interface-type interface-number ] command
to check information about the RSVP neighbor.
number ] } command to check statistics about RSVP-TE.
----End
Example
If the configurations are successful, you can view that the status of the BFD session for RSVP
is Up.
NOTE
Information about the BFD session can be checked only after the BFD session parameters are configured
and the session is created successfully.
3.28 Configuring an Automatic P2MP TE Tunnel

An automatic P2MP TE tunnel must be configured before it can be automatically established to
transmit multicast services when the multicast services arrive in an IP/MPLS backbone network.

Before configuring an automatic P2MP TE tunnel, familiarize yourself with the usage scenario,
Usage Scenario
There is an increasing diversity of multicast services, such as IPTV, massively multiplayer online
role-playing games (MMORPGs), and multimedia conferences. These services are transmitted
over service bearer networks that must meet the following requirements:
l Forward multicast traffic even during traffic congestion.
l Rapidly detect network faults and switch traffic to standby links.
The multicast virtual private LAN service (VPLS) solution meets these requirements. In this
solution, when multicast VPLS traffic arrives, the IP/MPLS network enables nodes to

automatically establish a P2MP TE tunnel and direct multicast traffic to the tunnel. This solution
eliminates the need to deploy Protocol Independent Multicast (PIM) or hierarchical virtual
private LAN service (HVPLS) and fully uses MPLS advantages of TE, QoS, and reliability.
NOTE
After the configuration is complete, a P2MP TE tunnel can be established automatically when multicast
VPLS is being deployed.
Before configuring an automatic P2MP TE tunnel, complete the following tasks:
l Configure OSPF or IS-IS to implement network layer connectivity.

l Enable MPLS TE and RSVP-TE.
l Configure CSPF.
l Configure OSPF TE or IS-IS TE.
Data Preparation
Before configuring an automatic P2MP TE tunnel, you need the following data.
No. Data
1 (Optional) Names of explicit paths used by leaf nodes

(Optional) Leaf list name
2 Name of a P2MP tunnel template

(Optional) Resource reservation style
(Optional) Link metric type used to select links
(Optional) Affinity value and its mask
(Optional) Hop limit
3.28.2 Enabling P2MP TE Globally

P2MP TE must be enabled globally on nodes along an automatic P2MP TE tunnel to be
automatically established.
Context
P2MP TE LSPs destined for leaf nodes can be established only after P2MP TE is globally enabled
on each node and P2MP forwarding is enabled on each outbound interface along the tunnel to
be established.
NOTE
The display mpls te p2mp-te interface [ interface-type interface-number ] command displays whether
P2MP forwarding is enabled or disabled on a specified or all interfaces.

Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls te p2mp-te
P2MP TE is enabled globally.

By default, P2MP TE is disabled.
----End
3.28.3 (Optional) Disabling P2MP TE on an Interface

You can disable P2MP TE on a specific interface during the network planning.
Context
By default, after P2MP TE is globally enabled, P2MP TE is automatically enabled on each MPLS
TE-enabled interface on a local node. To disable P2MP TE on a specific interface during network
planning or there is no need to have P2MP TE enabled on a specific interface because it does
not support P2MP forwarding, disable P2MP TE on the specific interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
mpls te p2mp-te disable
P2MP TE is disabled on the interface.

After the mpls te p2mp-te disable command is run, P2MP TE LSPs established on the interface
are torn down, and newly configured P2MP TE LSPs on the interface fail to be established.
----End
3.28.4 (Optional) Configuring a Leaf List

A leaf list can be configured before you specify leaf nodes on an automatic P2MP TE tunnel or
before you specify an explicit path for a leaf node.

Context
By default, an MPLS network that transmits multicast services dynamically selects leaf nodes
and uses Constrained Shortest Path First (CSPF) to calculate a path destined for each leaf node.
To control the leaf nodes of an automatic P2MP TE tunnel, configure a leaf list. If explicit paths
are specified for leaf nodes, a configured explicit path can be referenced in the view of a specific
leaf node in the leaf list.
NOTE
Plan explicit paths for leaf nodes, while preventing re-merge and crossover events:
l Re-merge: occurs when two sub-LSPs have different inbound interfaces but the same outbound
interface on a single transit node. Figure 3-2 illustrates a re-merge event.
l Crossover: occurs when two sub-LSPs have different inbound interfaces and outbound interfaces on
a single transit node. Figure 3-2 illustrates a crossover event.
Figure 3-2 Re-merge and crossover events
Re-merge Cross-over
Sub-LSP1
Sub-LSP2
Procedure
Step 1 Run:
system-view
Step 2 (Optional) Create an explicit path for each leaf node.

1. Run:
An explicit path is created, and the explicit path view is displayed.

2. Run:
next hop ip-address [ include [ strict | loose ] | exclude ]
A next-hop address is specified for the explicit path.

3. (Optional) Run:
add hop ip-address1 [ include [ strict | loose ] | exclude ] { after |
before } ip-address2
A node is added to the explicit path.

4. (Optional) Run:
modify hop ip-address1 ip-address2 [ include [ strict | loose ] | exclude ]
The address of a node is changed to allow another specified node to be used by the explicit
path.

NOTE
include means that a LSP must pass through a specified node; exclude means that a LSP cannot pass
through a specified node.
By default, the include strict parameters are configured, meaning that a hop and its next hop must
be directly connected. An explicit path can be configured to pass through a specified node or not to
pass through a specified node.
5. (Optional) Run:
delete hop ip-address
A node is removed from the explicit path.

6. Run:
quit
You can create explicit paths for some or all leaf nodes on a P2MP TE tunnel.
Step 3 Run:
mpls te leaf-list leaf-list-name
The leaf list is created, and the leaf list view is displayed.
Step 4 Run:
destination leaf-address
A leaf node is created in the leaf list, and the leaf node view is displayed.
The leaf-address value is equal to the MPLS LSR ID of the leaf node.

path explicit-path path-name
An explicit path is specified for the leaf node.
The path-name value is equal to the configured explicit path name. No explicit paths are specified
for a leaf node by default.
NOTE
Repeat Steps 3 and 4 to specify explicit paths for all leaf nodes on an automatic P2MP TE tunnel to be
established.
----End
3.28.5 Configuring a P2MP Tunnel Template

A P2MP tunnel template defines P2MP TE tunnel attributes and is used to automatically establish
P2MP TE tunnels.
Context
Attributes of an automatic P2MP TE tunnel can only be defined in a P2MP tunnel template, but
cannot be configured on a tunnel interface because the automatic P2MP TE tunnel has no tunnel
interface. Nodes that transmit multicast VPLS traffic can reference the template and use
attributes defined in the template to automatically establish P2MP TE tunnels.

Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls te p2mp-template template-name
A P2MP tunnel template is created, and the P2MP tunnel template view is displayed.
Step 3 Run either of the following commands:
l Run:
leaf-list leaf-list-name
A leaf list is configured.

By default, when multicast services arrive at a node, a P2MP TE tunnel is automatically
established, and CSPF calculates a sub-LSP destined for each leaf node.
This step enables a node that multicast VPLS services access to select leaf nodes in a
specified leaf list.
NOTE
Before running the leaf-list command, the task described in configuring a leaf list must be complete.
The leaf-list-name value in this step must specify an existing leaf list.
l Run:
record-route[ label ]
The route and label record function is enabled.

By default, the route and label record is disabled. This step enables nodes along an automatic
P2MP TE tunnel to use RSVP messages to record detailed P2MP TE tunnel information,
including the IP address of each hop. The label parameter in the record-route command
enables RSVP messages to record label values.
l Run:
resv-style { se | ff }
A resource reservation style is specified.

The shared explicit (SE) style is used by default.
l Run:
path metric-type { igp | te }
A link metric type used to select links is specified.

The TE metric is used by default.
l Run:
affinity property properties [ mask mask-value ]
An affinity and its mask are specified.

An affinity is a 32-bit vector value used to describe an MPLS link. An affinity and an
administrative group attribute define the nodes through which an MPLS TE tunnel passes.
Affinity masks determine the link properties that a device must check. If some bits in the
mask are 1, at least one bit in an administrative group is 1, and the corresponding bit in the
affinity must be 1. If the bits in the affinity are 0s, the corresponding bits in the
administrative group cannot be 1.
You can use an affinity to control the nodes through which an automatic P2MP TE tunnel
passes.

NOTE
For more information about administrative groups and affinities, see the section "Principles" in
NE80E/40E Feature Description - MPLS TE.
l Run:
hop-limit hop-limit-value
The hop limit is set.

The hop-limit command sets the maximum number of hops that each sub-LSP in an
automatic P2MP TE tunnel supports.
NOTE
If the hop limit is not set, a P2MP LSP established using the P2MP tunnel template contains a
maximum of 64 hops.
----End

After configuring an automatic P2MP TE tunnel, you can view the information about automatic
P2MP TE tunnels and P2MP TE LSPs.
Prerequisites
An automatic P2MP TE tunnel has been configured so that the establishment of an automatic
P2MP TE tunnel can be triggered when multicast VPLS is deployed.
Procedure
l Run the display mpls multicast-lsp protocol p2mp-te [ lsp-id ingress-lsr-id session-id
p2mp-id lsp-id ] command on any node to check information about P2MP TE LSPs working
in the Up state.
l Run the display mpls te p2mp tunnel-interface [ auto-tunnel [ auto-tunnel-name ] ]
[ s2l-destination s2l-destination-address ] command on the ingress (root node) to check
information about tunnel interfaces of automatic P2MP TE tunnels.
l Run the display mpls te leaf-list [ [ name ] leaf-list-name ] [ verbose ] command on the
ingress (root node) to check information about a specific or all configured leaf lists.
l Run the display mpls te p2mp-template [ [ name ] template-name ] [ verbose ] command
on the ingress (root node) to check the configurations of a P2MP tunnel template used to
automatically establish P2MP TE tunnels.
----End
Example
Run the preceding commands to obtain the following results:
# Run the display mpls multicast-lsp protocol p2mp-te command to view information about
all P2MP TE LSPs working in the Up state on the ingress.
<HUAWEI> display mpls multicast-lsp protocol p2mp-te
-------------------------------------------------------------------------------
LSP Information: RSVP P2MP-LSP
-------------------------------------------------------------------------------
No : 1

Session ID : 16002 Ingress LSR ID : 1.1.1.1

Local LSP ID : 2 P2MP ID : 0x1010101
Tunnel Name : P2MPaa16002
Forward ID : 0xa LSR Type : Ingress
LSP Age : 2013-05-08 16:05:50-08:00
Insegment Count: 0 Outsegment Count: 1

Outsegment :
Out Label : 900012 Out Interface : Ethernet0/0/3
Next Hop : 103.101.100.103 Token : 0x809
MTU : 1500
# Run the display mpls te p2mp tunnel-interface command on the ingress to view information
about all tunnel interfaces of automatic P2MP TE tunnels.
<HUAWEI> display mpls te p2mp tunnel-interface
----------------------------------------------------------------
P2MPaa16002
----------------------------------------------------------------
P2MP Template : aa
Tunnel State : UP
Session ID : 16002
Ingress LSR ID : 1.1.1.1 P2MP ID : 0x1010101
Primary LSP State : UP

----------------------------------------------------------------
Main LSP State : UP LSP ID : 2
----------------------------------------------------------------
S2L Dest Addr : 3.3.3.3 State : UP
# Run the display mpls te leaf-list verbose command on the ingress to view detailed information
about all leaf lists.
<HUAWEI> display mpls te leaf-list verbose
------------------------------------------------------------
p2mp-leaf-list
------------------------------------------------------------
Name : list1 Status : Enabled
1 1.1.1.1
2 2.2.2.2 with path path_abc
List of p2mp tunnels using this leaflist:
Number of p2mp tunnels using this leaflist: 0
List of P2MP templates using this leaf-list:
aa
Number of P2MP templates using this leaf-list: 1
# Run the display mpls te p2mp-template verbose command on the ingress to view detailed
information about all P2MP tunnel templates.
<HUAWEI> display mpls te p2mp-template verbose
------------------------------------------------------------
P2MP-Template
------------------------------------------------------------
Name : aaa
Tie-breaking Policy : None Metric Type : None
Bfd Capability : None Resv Style : SE
Bfd Minimum Tx(ms) : 1000 Bfd Minimum Rx(ms): 1000
Bfd Detect Multiplier: 3
Reoptimization : Disabled Reopt Freq(sec): --

IncludeAll : 0x0 IncludeAny : 0x0
ExcludeAny : 0x0
Setup Priority : 7 Hold Priority : 7
Record Route : Disabled Record Label : Disabled
Lsp-tp Outbound : Disabled Hop Limit : 32
Leaf-list Name : --

FRR Flag : Disabled FRR Bandwidth : Disabled

Bypass Bandwidth : --
Bypass Setup Priority: -- Bypass Hold Priority: --
Configured Bandwidth Information:
CT0 Bandwidth(Kbit/sec): 0 CT1 Bandwidth(Kbit/sec): 0
List of P2MP auto-tunnels using this template:

P2MPaaa16001
Number of P2MP auto-tunnels using this template: 1
3.29 Maintaining MPLS TE

This section describes how to clear operation information about MPLS TE, and reset the
automatic bandwidth adjustment.
3.29.1 Checking the Connectivity of the TE Tunnel

This section describes how to check connectivity of a TE tunnel between the ingress and egress.
Prerequisites
The TE tunnel detection has been configured.
Procedure
reply-mode | -s packet-size | -t time-out | -v ] * te tunnel interface-number [ hot-
standby ] [ draft6 ] command to check the connectivity of the TE tunnel between the
ingress and egress.
If draft6 is specified, the ping lsp command is implemented according to draft-ietf-mpls-

lsp-ping-06. By default, the command is implemented according to RFC 4379. If the hot-
standby parameter is specified, the hot-standby CR-LSP can be tested.
out ] * te tunnel interface-number [ hot-standby ] [ draft6 ] command to trace the hops
of a TE tunnel.
If draft6 is specified, the tracert lsp command is implemented according to draft-ietf-mpls-

lsp-ping-06. By default, the command is implemented according to RFC 4379. If the hot-
standby parameter is specified, the hot-standby CR-LSP can be tested.
----End
Example
After configuring MPLS TE, run the ping lsp command on the ingress of the TE tunnel to view
the ping result. If the ping fails, run the tracert lsp command to locate the fault.
3.29.2 Checking a TE Tunnel by Using NQA

After the configuration of MPLS TE, you can use NQA to detect the connectivity and jitter of
a TE tunnel.

Context
After configuring MPLS TE, you can use NQA to check the connectivity and jitter of the TE
tunnel. For detailed configurations, see the chapter "NQA Configuration" in HUAWEI
NetEngine80E/40E Router Configuration Guide - System Management.
3.29.3 Checking Information About Tunnel Faults

If an RSVP-TE tunnel interface goes Down, you can view information about the fault.
Context
If an RSVP-TE tunnel interface goes Down, you can run the following command to view
information about tunnel faults.
Procedure
Step 1 Run display mpls te tunnel-interface last-error [ tunnel-name ] command to view information
about tunnel faults.
----End
Example
Run the display mpls te tunnel-interface last-error command on the ingress to view last errors
of a local node or last errors carried in a PathErr message received from the downstream node.
The errors can be as follows:
l CSPF computation failures
l Errors that occur during the RSVP GR process
l Errors that occur when the RSVP signaling is triggered
l Errors that are carried in the received RSVP PathErr messages
This command shows the last 20 recorded errors of the TE tunnel.
3.29.4 Clearing the Operation Information

This section describes how to clear statistics about RSVP-TE.
Context
Run the reset command in the user view to clear the operation information.
Procedure
Step 1 Run the reset mpls rsvp-te statistics { global | interface [ interface-type interface-number ] }
command in the user view to clear statistics about RSVP-TE.
Step 2 Run the reset mpls rsvp-te p2mp statistics command in the user view to delete RSVP-TE P2MP
service statistics.
----End

3.29.5 Resetting the Tunnel Interface

By resetting a tunnel interface, you can activate configurations of the tunnel.
Context
To make the tunnel-related configuration take effect, you can run the mpls te commit command
in the tunnel interface view and run the reset command in the user view.
NOTE
If the configuration is modified in the interface view of the TE tunnel but the mpls te commit command
is not configured, the system cannot execute the reset mpls te tunnel-interface tunnel command to re-
establish the tunnel.
Procedure
Step 1 Run the reset mpls te tunnel-interface tunnel interface-number command to reset the tunnel
interface.
----End
3.29.6 Resetting the RSVP Process

By resetting the RSVP process, you can re-establish all RSVP CR-LSPs or verify the RSVP
operation process.
Context
NOTICE
Resetting the RSVP process results in the release and reestablishment of all RSVP CR-LSPs.
To re-establish all RSVP CR-LSPs or verify the operation process of RSVP, run the following
reset command in the user view.
Procedure
l Run the reset mpls rsvp-te command to reset the RSVP process.
----End
3.29.7 Deleting or Resetting the Bypass Tunnel

In the scenario where MPLS TE Auto FRR is enabled, you can delete or re-establish a bypass
tunnel.
Context
In a scenario where MPLS TE Auto FRR is used, you can run the following reset command to
release or re-establish bypass tunnels.

Procedure
l Run the reset mpls te auto-frr { lsp-id ingress-lsr-id tunnel-id | name bypass-tunnel-
name } command to delete or reset the Auto FRR bypass tunnel.
----End
3.29.8 Enabling the LSP Trap Function

By configuring the trap function on an LSP, you can notify the NMS of the changes in the LSP
status.
Context
Run the following commands in the system view to notify the Network Management System
(NMS) of LSP status changes.
By default, the trap function is disabled during the setup of the TE LSP.
Procedure
command in the system view to enable the trap function for the LSP and enable the
----End
3.29.9 Configuring Alarm Thresholds for RSVP LSPs

This section describes how to configure alarm thresholds for RSVP LSPs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls rsvp-lsp-number threshold-alarm upper-limit upper-limit-value lower-limit
lower-limit-value
The upper and lower thresholds of alarms for RSVP LSP usage are configured.
The parameters in this command are described as follows:
l upper-limit-value specifies the upper threshold of alarms for RSVP LSP usage. An alarm is
generated when the proportion of established RSVP LSPs to total supported RSVP LSPs
reaches the upper limit.

l lower-limit-value specifies the lower threshold of clear alarms for RSVP LSP usage. A clear
alarm is generated when the proportion of established RSVP LSPs to total supported RSVP
LSPs falls below the lower limit.
l The value of upper-limit-value must be greater than that of lower-limit-value.
The default upper limit of an alarm for RSVP LSP usage is 80%. The default lower limit of a
clear alarm for RSVP LSP usage is 75%. Using the default upper limit and lower limit is
recommended.
NOTE
l This command configures the alarm threshold for RSVP LSP usage. The alarm that the number of
RSVP LSPs reached the upper threshold is generated only when the command snmp-agent trap enable
feature-name mpls_lspm trap-name hwmplslspthresholdexceed is configured, and the actual RSVP
LSP usage reaches the upper limit of the alarm threshold. The alarm that the number of RSVP LSPs
fell below the lower threshold is generated only when the command snmp-agent trap enable feature-
name mpls_lspm trap-name hwmplslspthresholdexceedclear is configured, and the actual RSVP
LSP usage falls below the lower limit of the clear alarm threshold.
l After the snmp-agent trap enable feature-name mpls_lspm trap-name
{ hwmplslsptotalcountexceed | hwmplslsptotalcountexceedclear } command is run to enable LSP
limit-crossing alarm and LSP limit-crossing clear alarm, an alarm is generated in the following
situations:
l If the total number of RSVP LSPs reaches the upper limit, a limit-crossing alarm is generated.
l If the total number of RSVP LSPs falls below 95% of the upper limit, a limit-crossing clear alarm
is generated.
----End
3.29.10 Configuring Alarm Thresholds for Total CR-LSPs

This section describes how to configure alarm thresholds for total CR-LSPs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls total-crlsp-number threshold-alarm upper-limit upper-limit-value lower-limit
lower-limit-value
The upper and lower thresholds of alarms for total CR-LSP usage are configured.
l upper-limit-value specifies the upper threshold of alarms for total CR-LSP usage. An alarm
is generated when the proportion of established CR-LSPs to total supported CR-LSPs reaches
the upper limit.

l lower-limit-value specifies the lower threshold of clear alarms for total CR-LSP usage. A
clear alarm is generated when the proportion of established CR-LSPs to total supported CR-
The default upper limit of an alarm for total CR-LSP usage is 80%. The default lower limit of
a clear alarm for total CR-LSP usage is 75%. Using the default upper limit and lower limit is
recommended.
NOTE
l This command configures the alarm threshold for total CR-LSP usage. The alarm that the number of
total CR-LSPs reached the upper threshold is generated only when the command snmp-agent trap
enable feature-name mpls_lspm trap-name hwmplslspthresholdexceed is configured, and the
actual total CR-LSP usage reaches the upper limit of the alarm threshold. The alarm that the number
of total CR-LSPs fell below the lower threshold is generated only when the command snmp-agent
trap enable feature-name mpls_lspm trap-name hwmplslspthresholdexceedclear is configured,
and the actual total CR-LSP usage falls below the lower limit of the clear alarm threshold.
situations:
l If the total number of CR-LSPs reaches the upper limit, a limit-crossing alarm is generated.
l If the total number of CR-LSPs falls below 95% of the upper limit, a limit-crossing clear alarm is
generated.
----End

The following sections provide several examples for configuring MPLS TE.Each configuration
example consists of the networking requirements, configuration precautions, configuration
roadmap, configuration procedures, and configuration files.
3.30.1 Example for Establishing a Static MPLS TE Tunnel

This section provides an example for configuring a static MPLS TE tunnel, which involves
enabling MPLS TE, configuring the MPLS TE bandwidth, setting up an MPLS TE tunnel, and
setting up a static CR-LSP.
On the network shown in Figure 3-3, a static TE tunnel from LSRA to LSRC and a static TE
tunnel from LSRC to LSRA need to be set up. The bandwidth of both tunnels is 10 Mbit/s.
Figure 3-3 Networking diagram for static CR-LSP configuration

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
ATM1/0/0 ATM1/0/0 ATM2/0/0 ATM2/0/0
2.1.1.1/24 2.1.1.2/24 3.2.1.1/24 3.2.1.2/24
LSRA LSRB LSRC

1. Assign an IP address to each interface on each LSR, configure the loopback address as the
MPLS LSR ID, and configure OSPF to advertise the route to the network segment
connecting to each interface and LSR ID.
2. Configure the LSR ID and globally enable MPLS and MPLS TE on each node and interface.
3. Configure the maximum reservable bandwidth and BC0 bandwidth for the link on each
outgoing interface of each LSR along the tunnel. (The tunnel obtains bandwidth from
BC0).
4. Create a tunnel interface on the ingress and specify the IP address of the tunnel, tunnel
protocol, destination address, tunnel ID, and the signaling protocol used to establish the
tunnel.
5. Configure a static LSP associated with the tunnel, and specify the outgoing label and next-
hop address on the ingress, the incoming interface, the next-hop address, and the outgoing
label on the transit node, and the incoming label and inbound interface on the egress to
establish the LSP.
NOTE
l The outgoing label of each node is the incoming label of the next node.
l When running the static-cr-lsp ingress { tunnel-interface tunnel interface-number | tunnel-name }
destination destination-address { nexthop next-hop-address | outgoing-interface interface-type
interface-number } out-label out-label-value [ bandwidth [ ct0 | ct1 ] bandwidth ] command to
configure the ingress of a CR-LSP, note that tunnel-name must be the same as the tunnel name created
by using the interface tunnel interface -number command. tunnel-name is a case-sensitive character
string with no spaces. For example, the name of the tunnel created by using the interface tunnel
2/0/0 command is Tunnel2/0/0. In this case, the parameter of the static CR-LSP on the ingress is
Tunnel2/0/0. This restriction does not apply to transit nodes or egresses.
Data Preparation
l OSPF process ID and area ID of each LSR
l Tunnel interface names, tunnel interface IP addresses, destination addresses, tunnel IDs,
and tunnel signaling protocol (CR-Static) on LSRA and LSRC
l The maximum reservable bandwidth and BC bandwidth for links
l Next-hop address and outgoing label of the ingress on the static CR-LSP
l Incoming interface, next-hop address, and outgoing label of the transit node on the static
CR-LSP
l Incoming interface of the egress on the static CR-LSP
Procedure
Step 1 Assign the IP address to each interface and configure a routing protocol.
# Assign the IP address to each interface and configure the routing protocol using the information
in Figure 3-3 to implement reachability between LSRs.

For configuration details, see Configuration Files in this section.

Step 2 Configure the basic MPLS functions and enable MPLS TE.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
[LSRA] interface atm 1/0/0
[LSRA-Atm1/0/0] pvc 1/100
[LSRA-atm-pvc-Atm1/0/0-1/100] map ip 2.1.1.2 broadcast
[LSRA-atm-pvc-Atm1/0/0-1/100] quit
[LSRA-Atm1/0/0] ospf network-type p2p
[LSRA-Atm1/0/0] mpls
[LSRA-Atm1/0/0] mpls te
[LSRA-Atm1/0/0] quit
Repeat this step for LSRB and LSRC. For configuration details, see Configuration Files in this
section.
Step 3 Configure MPLS-TE bandwidth attributes for links.
# Configure the maximum reservable link bandwidth and BC0 bandwidth on each outbound
interface of each LSR along the tunnel. The BC0 bandwidth for links must be greater than the
tunnel bandwidth (10 Mbit/s).
# Configure LSRA.
[LSRA] interface atm 1/0/0
[LSRA-Atm1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRA-Atm1/0/0] mpls te bandwidth bc0 100000
[LSRA-Atm1/0/0] quit
# Configure LSRB.
[LSRB] interface atm 1/0/0
[LSRB-Atm1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRB-Atm1/0/0] mpls te bandwidth bc0 100000
[LSRB-Atm1/0/0] quit
[LSRB] interface atm 2/0/0
[LSRB-Atm2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRB-Atm2/0/0] mpls te bandwidth bc0 100000
[LSRB-Atm2/0/0] quit
# Configure LSRC.
[LSRC] interface atm 2/0/0
[LSRC-Atm2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRC-Atm2/0/0] mpls te bandwidth bc0 100000
[LSRC-Atm2/0/0] quit
Step 4 Configure an MPLS TE tunnel.

# Create the MPLS TE tunnel from LSRA to LSRC on LSRA.
[LSRA-Tunnel1/0/0] ip address unnumbered interface loopback 1
[LSRA-Tunnel1/0/0] tunnel-protocol mpls te
[LSRA-Tunnel1/0/0] mpls te tunnel-id 100
[LSRA-Tunnel1/0/0] mpls te signal-protocol cr-static
[LSRA-Tunnel1/0/0] mpls te commit
# Create the MPLS TE tunnel from LSRC to LSRA on LSRC.


[LSRC-Tunnel2/0/0] ip address unnumbered interface loopback 1
[LSRC-Tunnel2/0/0] tunnel-protocol mpls te
[LSRC-Tunnel2/0/0] mpls te tunnel-id 200
[LSRC-Tunnel2/0/0] mpls te signal-protocol cr-static
[LSRC-Tunnel2/0/0] mpls te commit
Step 5 Create a static CR-LSP from LSRA to LSRC.
# Configure LSRA as the ingress of the static CR-LSP.

[LSRA] static-cr-lsp ingress tunnel-interface tunnel1/0/0 destination 3.3.3.3
nexthop 2.1.1.2 out-label 20 bandwidth ct0 10000
# Configure LSRB as the transit node of the static CR-LSP.

[LSRB] static-cr-lsp transit tunnel1/0/0 incoming-interface atm 1/0/0 in-label 20
# Configure LSRC as the egress of the static CR-LSP.

[LSRC] static-cr-lsp egress tunnel1/0/0 incoming-interface atm 2/0/0 in-label 30
Step 6 Create a static CR-LSP from LSRC to LSRA.
# Configure LSRC as the ingress of the static CR-LSP.

[LSRC] static-cr-lsp ingress tunnel-interface tunnel2/0/0 destination 1.1.1.1
# Configure LSRB as the transit node of the static CR-LSP.

[LSRB] static-cr-lsp transit tunnel2/0/0 incoming-interface atm 2/0/0 in-label 120
# Configure LSRA as the egress of the static CR-LSP.

[LSRA] static-cr-lsp egress tunnel2/0/0 incoming-interface atm 1/0/0 in-label 130
After completing the configuration, run the display interface tunnel command on LSRA. The
command output shows that the status of the tunnel interface is Up.
Run the display mpls te tunnel command on each LSR to view the establishment status of the
MPLS TE tunnel.
[LSRA] display mpls te tunnel
------------------------------------------------------------------------------
Ingress LsrId Destination LSPID In/Out Label R Tunnel-name
------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 1 --/20 I Tunnel1/0/0
- - - 130/-- E Tunnel2/0/0
[LSRB] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
- - - 20/30 T Tunnel1/0/0
- - - 120/130 T Tunnel2/0/0
[LSRC] display mpls te tunnel
------------------------------------------------------------------------------

------------------------------------------------------------------------------
- - - 30/-- E Tunnel1/0/0
3.3.3.3 1.1.1.1 1 --/120 I Tunnel2/0/0
Run the display mpls lsp or display mpls static-cr-lsp command on each LSR to view the
establishment status of the static CR-LSP.
# Display the configuration on LSRA.

----------------------------------------------------------------------
LSP Information: STATIC CRLSP
----------------------------------------------------------------------
3.3.3.3/32 NULL/20 -/Atm1/0/0
-/- 130/NULL Atm1/0/0/-
[LSRA] display mpls static-cr-lsp
TOTAL : 2 STATIC CRLSP(S)
UP : 2 STATIC CRLSP(S)
DOWN : 0 STATIC CRLSP(S)
Tunnel1/0/0 3.3.3.3/32 NULL/20 -/Atm1/0/0 Up
tunnel2/0/0 -/- 130/NULL Atm1/0/0/- Up
# Display the configuration on LSRB.

----------------------------------------------------------------------
----------------------------------------------------------------------
-/- 20/30 GE1/0/0/GE2/0/0
-/- 120/130 GE2/0/0/GE1/0/0
[LSRB] display mpls static-cr-lsp
tunnel1/0/0 -/- 20/30 Atm1/0/0/Atm2/0/0 Up
tunnel2/0/0 -/- 120/130 Atm2/0/0/Atm1/0/0 Up
# Display the configuration on LSRC.

[LSRC] display mpls lsp
----------------------------------------------------------------------
----------------------------------------------------------------------
1.1.1.1/32 NULL/120 -/GE2/0/0
-/- 30/NULL GE2/0/0/-
[LSRC] display mpls static-cr-lsp
Tunnel2/0/0 1.1.1.1/32 NULL/120 -/GE2/0/0 Up
tunnel1/0/0 -/- 30/NULL GE2/0/0/- Up
When the static CR-LSP is used to establish the MPLS TE tunnel, the packets on the transit node
and the egress are forwarded directly based on the specified incoming and outgoing labels.
Therefore, no FEC information is displayed on LSRB or LSRC.
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
#
interface Atm1/0/0
ip address 2.1.1.1 255.255.255.0
pvc 1/100
map ip 2.1.1.2 broadcast
ospf network-type p2p
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 3.3.3.3
mpls te commit
#
ospf 1
area 0.0.0.0
network 2.1.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
static-cr-lsp ingress tunnel-interface Tunnel1/0/0 destination 3.3.3.3 nexthop
2.1.1.2 out-label 20 bandwidth ct0 10000
static-cr-lsp egress tunnel2/0/0 incoming-interface Atm1/0/0 in-label 130
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
#
interface Atm1/0/0
ip address 2.1.1.2 255.255.255.0
pvc 1/100
mpls
mpls te
#
interface Atm2/0/0
ip address 3.2.1.1 255.255.255.0
pvc 1/100
mpls
mpls te


#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.1.1.0 0.0.0.255
network 3.2.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
static-cr-lsp transit tunnel1/0/0 incoming-interface Atm1/0/0 in-label 20
static-cr-lsp transit tunnel2/0/0 incoming-interface Atm2/0/0 in-label 120
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
#
interface Atm2/0/0
ip address 3.2.1.2 255.255.255.0
pvc 1/100
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
destination 1.1.1.1
mpls te commit
#
ospf 1
area 0.0.0.0
network 3.2.1.0 0.0.0.255
network 3.3.3.3 0.0.0.0
#
static-cr-lsp ingress tunnel-interface Tunnel2/0/0 destination 1.1.1.1 nexthop
static-cr-lsp egress tunnel1/0/0 incoming-interface Atm2/0/0 in-label 30
#
return
3.30.2 Example for Configuring a Static Bidirectional Co-routed LSP

This section uses an example to describe the procedure for configuring a static bidirectional co-
routed LSP, including how to enable MPLS TE, configure MPLS TE bandwidth attributes,
configure an MPLS TE tunnel, and create a static bidirectional co-routed LSP.

Context
MPLS-TP is widely used on transport networks. Although MPLS-TP supports OAM, OAM
itself only supports the network element-level management system, which cannot meet the
requirements for network management over public telecommunication networks. MPLS-TP
OAM supporting static bidirectional co-routed LSP is an effective operation and management
method and can detect, identify, and locate faults in the MPLS-TP user plane.
As shown in Figure 3-4, a static bidirectional co-routed LSP originates from LSRA and
terminates on LSRC. OAM PDUs travel through this LSP and any transit node can send a
response along the same path in the opposite direction. The links for the static bidirectional co-
routed LSP between LSRA and LSRC has the bandwidth of 10 Mbit/s.
Figure 3-4 Networking diagram for a static bidirectional co-routed LSP

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
POS1/0/0 POS1/0/0 POS2/0/0 POS1/0/0
2.1.1.1/24 2.1.1.2/24 3.2.1.1/24 3.2.1.2/24
LSRA LSRB LSRC
1. Assign an IP address to each interface and configure a routing protocol.

2. Configure basic MPLS functions and enable MPLS TE.
3. Configure MPLS TE attributes for links.
4. Configure MPLS TE tunnels.
5. Configure the ingress, a transit node, and the egress for the static bidirectional co-routed
LSP.
6. Bind the tunnel interface configured on LSRC to the static bidirectional co-routed LSP.
Data Preparation
l Tunnel interface's name and IP address, destination address, tunnel ID, and static CR-LSP
signaling on LSRA and LSRC
l Maximum reservable bandwidth and BC bandwidth of each link
l Next-hop address and outgoing label on the ingress
l Inbound interface, next-hop address, and outgoing label on the transit node
l Inbound interface on the egress

Procedure
Step 1 Assign an IP address to each interface and configure a routing protocol.
# Configure an IP address and a mask for each interface and configure OSPF so that all LSRs
can interconnect with each other.
The configuration details are not provided here.
Step 2 Configure basic MPLS functions and enable MPLS TE.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
[LSRA-Pos1/0/0] mpls te
The configurations on LSRB and LSRC are similar to the configuration on LSRA.
Step 3 Configure MPLS TE attributes for links.
# Configure the maximum reservable bandwidth and BC0 bandwidth for the link on the outbound
interface of each LSR. The BC0 bandwidth of links must be greater than the tunnel bandwidth
(10 Mbit/s).
# Configure LSRA.
[LSRA-Pos1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRA-Pos1/0/0] mpls te bandwidth bc0 100000
# Configure LSRB.
# Configure LSRC.
Step 4 Configure MPLS TE tunnel interfaces.
# Create an MPLS TE tunnel on LSRA to reach LSRC.


[LSRA-Tunnel1/0/0] mpls te bidirectional

# Create an MPLS TE tunnel on LSRC to reach LSRA.

Step 5 Configure the ingress, a transit node, and the egress of the static bidirectional co-routed LSP.
# Configure LSRA as the ingress.
[LSRA] bidirectional static-cr-lsp ingress Tunnel1/0/0
[LSRA-bi-static-ingress-Tunnell/0/0] forward nexthop 2.1.1.2 out-label 20
bandwidth ct0 10000
[LSRA-bi-static-ingress-Tunnell/0/0] backward in-label 20
# Configure LSRB as a transit node.

[LSRB]bidirectional static-cr-lsp transit lsp1
[LSRB-bi-static-transit-lsp1] forward in-label 20 nexthop 3.2.1.2 out-label 40
bandwidth ct0 10000
[LSRB-bi-static-transit-lsp1] backward in-label 16 nexthop 2.1.1.1 out-label 20
bandwidth ct0 10000
# Configure LSRC as the egress.

[LSRC] bidirectional static-cr-lsp egress lsp1
[LSRC-bi-static-egress-lsp1] forward in-label 40 lsrid 1.1.1.1 tunnel-id 100
[LSRC-bi-static-egress-lsp1] backward nexthop 3.2.1.1 out-label 16 bandwidth ct0
10000
Step 6 Bind the tunnel interface on LSRC to the static bidirectional co-routed LSP.
[LSRC] interface Tunnel2/0/0
[LSRC-Tunnel2/0/0] mpls te passive-tunnel
[LSRC-Tunnel2/0/0] mpls te binding bidirectional static-cr-lsp egress lsp1

After completing the configuration, run the display interface tunnel command on LSRA. You
can see that the tunnel interface is Up.
Run the display mpls te tunnel command on each LSR to check that MPLS TE tunnels are set
up.
# Check the configuration results on LSRA.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 1 --/20 I Tunnel1/0/0
20/--

------------------------------------------------------------------------------


------------------------------------------------------------------------------
- - - 20/40 T lsp1
16/20

------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 - 40/-- E lsp1
--/16
Run the display mpls te bidirectional static-cr-lsp command on each LSR. Information about
the static bidirectional co-routed LSP is displayed.

[LSRA] display mpls te bidirectional static-cr-lsp
Name FEC I/O Label I/O If Stat
Tunnel1/0/0 3.3.3.3/32 NULL/20 -/Pos1/0/0
20/NULL Pos1/0/0- Up

[LSRB] display mpls te bidirectional static-cr-lsp
lsp1 -/32 20/40 -/Pos1/0/0
16/20 Pos2/0/0- Up

[LSRC] display mpls te bidirectional static-cr-lsp
lsp1 1.1.1.1/32 40/NULL Pos1/0/0/-
NULL/16 -/Pos1/0/0 Up
After completing the configurations, run the ping command on LSRA. The static bidirectional
co-routed LSP is reachable.
[LSRA] ping lsp te Tunnel 1/0/0
LSP PING FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1/0/0 : 100 data bytes, pres
s CTRL_C to break
Reply from 3.3.3.3: bytes=100 Sequence=1 time = 110 ms
--- FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1/0/0 ping statistics ---
0.00% packet loss
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
#
bidirectional static-cr-lsp ingress Tunnel1/0/0
forward nexthop 2.1.1.2 out-label 20 bandwidth ct0 10000
backward in-label 20
#
interface Pos1/0/0
undo shutdown
ip address 2.1.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 3.3.3.3
mpls te bidirectional
mpls te commit
#
ip route-static 2.2.2.2 255.255.255.255 2.1.1.2
ip route-static 3.3.3.3 255.255.255.255 2.1.1.2
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
#
bidirectional static-cr-lsp transit lsp1
forward in-label 20 nexthop 3.2.1.2 out-label 40 bandwidth ct0 10000
backward in-label 16 nexthop 2.1.1.1 out-label 20 bandwidth ct0 10000
#
interface Pos1/0/0
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
#
interface Pos2/0/0
undo shutdown
ip address 3.2.1.1 255.255.255.0
mpls
mpls te
#

interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 2.1.1.1
ip route-static 3.3.3.3 255.255.255.255 3.2.1.2
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
#
bidirectional static-cr-lsp egress lsp1
forward in-label 40 lsrid 1.1.1.1 tunnel-id 100
backward nexthop 3.2.1.1 out-label 16 bandwidth ct0 10000
#
interface Pos1/0/0
undo shutdown
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
destination 1.1.1.1
mpls te passive-tunnel
mpls te binding bidirectional static-cr-lsp egress lsp1
mpls te commit
#
ip route-static 1.1.1.1 255.255.255.255 3.2.1.1
ip route-static 2.2.2.2 255.255.255.255 3.2.1.1
#
return
3.30.3 Example for Configuring a 1:1 Tunnel Protection Group Over

a Bidirectional LSP
A tunnel protection group provides end to end protection for a tunnel if a network fault occurs.
This example describes how to configure a 1:1 tunnel protection group.
Context
Figure 3-5 shows an MPLS network. APS is configured on PE1 and PE2. The working tunnel
is established along the path PE1 -> PE2 and the protection tunnel is established along the path
PE1 -> P -> PE2. When the MPLS network operates properly, the working tunnel transmits
MPLS traffic. If the working tunnel fails, MPLS traffic switches to the protection tunnel.

Figure 3-5 Networking diagram for a 1:1 bidirectional tunnel protection group
Loopback1
3.3.3.3/32
P
GE1/0/0 GE2/0/0
10.1.1.2/24 10.1.2.2/24
GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.2.1/24
PE1 PE2
GE1/0/0 GE1/0/0
10.1.3.1/24 10.1.3.2/24
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
Primary path
Backup path

3. Configure MPLS TE bandwidth attributes for links.
LSP of primary tunnel.
LSP of protect tunnel.
6. Configure MPLS TE tunnels.
7. Configure APS.
Data Preparation
l Tunnel interface's name and IP address, destination address, tunnel ID, and static CR-LSP
signaling on PE1 and PE2

Procedure
Configure an IP address and a mask for each interface and configure OSPF to allow all LSRs to
interconnect with each other.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] quit
[PE1-GigabitEthernet1/0/0] mpls te
The configurations on PE2 and P are similar to the configuration on PE1.
# Configure the maximum reservable bandwidth and BC0 bandwidth for the link on the outbound
interface of each node. The BC0 bandwidth of links must be greater than the tunnel bandwidth
(10 Mbit/s).
# Configure PE1.
[PE1-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[PE1-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
# Configure P.
[P] interface GigabitEthernet 1/0/0
[P-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[P-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
[P] interface GigabitEthernet 2/0/0
[P-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000
# Configure PE2.



# Create a working tunnel on PE1 to reach PE2.
[PE1] interface tunnel 2/0/0
[PE1-Tunnel2/0/0] ip address unnumbered interface loopback 1
[PE1-Tunnel2/0/0] tunnel-protocol mpls te
[PE1-Tunnel2/0/0] destination 2.2.2.2
[PE1-Tunnel2/0/0] mpls te tunnel-id 100
[PE1-Tunnel2/0/0] mpls te signal-protocol cr-static
[PE1-Tunnel2/0/0] mpls te bidirectional
[PE1-Tunnel2/0/0] mpls te commit
[PE1-Tunnel2/0/0] quit
# Create a protection tunnel on PE1 to reach PE2.

[PE1-Tunnel1/0/0] ip address 1.1.1.9 32
[PE1-Tunnel1/0/0] mpls te bidirectional
# Create a working tunnel on PE2 to reach PE1.

# Create a protection tunnel on PE2 to reach PE1.

[PE2-Tunnel1/0/0] ip address 2.2.2.9 32
Step 5 Configure the ingress and the egress for the static bidirectional co-routed LSP of primary tunnel.
# Configure PE1 as the ingress.
[PE1] bidirectional static-cr-lsp ingress Tunnel2/0/0
[PE1-bi-static-ingress-Tunnel2/0/0] forward nexthop 10.1.3.2 out-label 80
bandwidth ct0 10000
[PE1-bi-static-ingress-Tunnel2/0/0] backward in-label 90
[PE1-bi-static-ingress-Tunnel2/0/0] quit
# Configure PE2 as the egress.

[PE2] bidirectional static-cr-lsp egress tunnel2/0/0
[PE2-bi-static-egress-Tunnel2/0/0] forward in-label 80 lsrid 1.1.1.1 tunnel-id 100
[PE2-bi-static-egress-Tunnel2/0/0] backward nexthop 10.1.3.1 out-label 90
bandwidth ct0 10000
[PE2-bi-static-egress-Tunnel2/0/0] quit
# Bind the tunnel interface on PE2 to the static bidirectional co-routed LSP.

[PE2-Tunnel2/0/0] mpls te passive-tunnel

[PE2-Tunnel2/0/0] mpls te binding bidirectional static-cr-lsp egress Tunnel2/0/0
Step 6 Configure the ingress, a transit node, and the egress for the static bidirectional co-routed LSP
of protect tunnel.
# Configure PE1 as the ingress.

[PE1] bidirectional static-cr-lsp ingress Tunnel1/0/0
[PE1-bi-static-ingress-Tunnel1/0/0] forward nexthop 10.1.1.2 out-label 20
bandwidth ct0 10000
[PE1-bi-static-ingress-Tunnel1/0/0] backward in-label 20
# Configure P as a transit node.

[P]bidirectional static-cr-lsp transit lsp1
[P-bi-static-transit-lsp1] forward in-label 20 nexthop 10.1.2.1 out-label 40
bandwidth ct0 10000
[P-bi-static-transit-lsp1] backward in-label 16 nexthop 10.1.1.1 out-label 20
bandwidth ct0 10000
# Configure PE2 as the egress.

[PE2] bidirectional static-cr-lsp egress tunnel1/0/0
[PE2-bi-static-egress-Tunnel1/0/0] forward in-label 40 lsrid 1.1.1.1 tunnel-id 200
[PE2-bi-static-egress-Tunnel1/0/0] backward nexthop 10.1.2.2 out-label 16
bandwidth ct0 10000
[PE2-bi-static-egress-Tunnel1/0/0] quit
# Bind the tunnel interface on PE2 to the static bidirectional co-routed LSP.
[PE2-Tunnel1/0/0] mpls te passive-tunnel
[PE2-Tunnel1/0/0] mpls te binding bidirectional static-cr-lsp egress Tunnel1/0/0
Step 7 Configure APS.

[PE1-Tunnel2/0/0] mpls te protection tunnel 200 mode revertive wtr 1
After completing the configuration, run the display mpls te protection tunnel all verbose
command on PE1. You can see that the tunnel interface is Up.
# Check the configurations on PE1.

[PE1] display mpls te protection tunnel all verbose
----------------------------------------------------------------
Verbose information about the No.1 protection-group
----------------------------------------------------------------
Work-tunnel id : 100
Protect-tunnel id : 200
Work-tunnel name : Tunnel2/0/0
Protect-tunnel name : Tunnel1/0/0
Work-tunnel reverse-lsp : -
Protect-tunnel reverse-lsp : -
Switch result : work-tunnel
Tunnel using Best-Effort : none
Tunnel using Ordinary : none

Work-tunnel frr in use : none

Work-tunnel defect state : non-defect
Protect-tunnel defect state : non-defect
Work-tunnel forward-lsp defect state : non-defect
Protect-tunnel forward-lsp defect state : non-defect
Work-tunnel reverse-lsp defect state : non-defect
Protect-tunnel reverse-lsp defect state : non-defect
HoldOff config time : 0ms
HoldOff remain time : -
WTR config time : 30s
WTR remain time : -
Mode : revertive
Using same path : -
Local state : no request
Far end request : no request
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
#
#
#
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 2.2.2.2
mpls te protection tunnel 200 mode revertive wtr 1
mpls te commit
#

ip address 1.1.1.9 255.255.255.255
destination 2.2.2.2
#
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
network 1.1.1.1 0.0.0.0
network 2.2.2.2 0.0.0.0
network 3.3.3.3 0.0.0.0
network 1.1.1.9 0.0.0.0
#
return
#
sysname P
#
mpls lsr-id 3.3.3.3
mpls
mpls te
#
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
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
network 1.1.1.1 0.0.0.0
network 2.2.2.2 0.0.0.0
network 3.3.3.3 0.0.0.0
network 1.1.1.9 0.0.0.0
#
return

#
sysname PE2
#

mpls lsr-id 2.2.2.2

mpls
mpls te
#
bidirectional static-cr-lsp egress Tunnel2/0/0
#
bidirectional static-cr-lsp egress Tunnel1/0/0
#
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
destination 1.1.1.1
mpls te binding bidirectional static-cr-lsp egress Tunnel2/0/0
mpls te commit
#
ip address 2.2.2.9 255.255.255.255
destination 1.1.1.1
mpls te binding bidirectional static-cr-lsp egress Tunnel1/0/0
mpls te commit
#
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
network 1.1.1.1 0.0.0.0
network 2.2.2.2 0.0.0.0
network 3.3.3.3 0.0.0.0
network 1.1.1.9 0.0.0.0
#
return

3.30.4 Example for Configuring an RSVP-TE Tunnel

This section provides an example for configuring an RSVP-TE tunnel, which involves enabling
MPLS, MPLS TE, RSVP-TE, and CSPF.
On the network shown in Figure 3-6, LSRA, LSRB, LSRC, and LSRD are Level 2 devices that
run IS-IS.
RSVP-TE is used to establish a TE tunnel from LSRA to LSRD. The bandwidth is 20 Mbit/s.
The maximum reservable bandwidth for links along the tunnel is 100 Mbit/s. The bandwidth
constraints model is the default RDM and the BC0 bandwidth is 100 Mbit/s.
Figure 3-6 Networking diagram for the RSVP-TE tunnel

Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
LSRA LSRD
GE1/0/0 GE1/0/0
10.1.1.1/24 30.1.1.2/24
GE1/0/0 GE1/0/0
10.1.1.2/24 POS2/0/0 POS2/0/0 30.1.1.1/24
2.2.2.9/32 3.3.3.9/32
LSRB LSRC
1. Configure IP addresses for the interfaces on each LSR and configure a loopback address
as an LSR ID.
2. Enable IS-IS globally, configure the name of network entity, change cost type, enable IS-
IS TE and enable IS-IS on all interfaces, including loopback interfaces.
3. Configure LSR ID and enable MPLS, MPLS TE, MPLS RSVP-TE, and MPLS TE CSPF
globally.
4. Enable MPLS, MPLS TE, and MPLS RSVP-TE on each interface.
5. Configure the maximum reservable bandwidth and BC bandwidth for the links on each
LSR along the tunnel.
6. Create the tunnel interface on the ingress and specify the IP address, tunnel protocol,
destination address, tunnel ID, dynamic signaling protocol RSVP-TE, and tunnel
bandwidth.

Data Preparation
l IS-IS area ID of each LSR, originating system ID, and IS-IS level
l Maximum reservable bandwidth and BC bandwidth for all links along the tunnel
l Tunnel interface name, IP address, destination address, tunnel ID, tunnel signaling protocol
(RSVP-TE), and tunnel bandwidth
Configuration Procedure
1. Assign IP addresses to interfaces.
Assign an IP address and mask to each interface according to Figure 3-6. For configuration
2. Configure the IS-IS protocol to advertise routes.
# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] network-entity 00.0005.0000.0000.0001.00
[LSRA-isis-1] quit
[LSRA] interface gigabitethernet 1/0/0
[LSRA-GigabitEthernet1/0/0] isis enable 1
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] network-entity 00.0005.0000.0000.0002.00
[LSRB-isis-1] quit
[LSRB] interface gigabitethernet 1/0/0
[LSRB-GigabitEthernet1/0/0] isis enable 1
[LSRB-GigabitEthernet1/0/0] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] network-entity 00.0005.0000.0000.0003.00
[LSRC-isis-1] quit
[LSRC] interface gigabitethernet 1/0/0
[LSRC-GigabitEthernet1/0/0] isis enable 1
[LSRC-GigabitEthernet1/0/0] quit
# Configure LSRD.
[LSRD] isis 1
[LSRD-isis-1] network-entity 00.0005.0000.0000.0004.00

[LSRD-isis-1] quit
[LSRD] interface gigabitethernet 1/0/0
[LSRD-GigabitEthernet1/0/0] isis enable 1
[LSRD-GigabitEthernet1/0/0] quit
After completing the configuration, run the display ip routing-table command on each
LSR. LSRs have learned routes from each other.
------------------------------------------------------------------------------
2.2.2.9/32 ISIS-L2 15 10 D 10.1.1.2 GigabitEthernet1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 GigabitEthernet1/0/0
3. Configure the basic MPLS functions and enable MPLS TE, RSVP-TE, and CSPF.
# Enable MPLS, MPLS TE, and RSVP-TE globally on each LSR, enable MPLS, MPLS
TE, and RSVP-TE on all tunnel interfaces, and enable CSPF in the system view on the
ingress.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] mpls rsvp-te
[LSRA-mpls] mpls te cspf
[LSRA-mpls] quit
[LSRA-GigabitEthernet1/0/0] mpls te
[LSRA-GigabitEthernet1/0/0] mpls rsvp-te
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] mpls te
[LSRB-mpls] quit
[LSRB-GigabitEthernet1/0/0] mpls
[LSRB-GigabitEthernet1/0/0] mpls te
[LSRB-GigabitEthernet1/0/0] mpls rsvp-te
# Configure LSRC.

[LSRC] mpls
[LSRC-mpls] mpls te
[LSRC-mpls] quit
[LSRC-GigabitEthernet1/0/0] mpls
[LSRC-GigabitEthernet1/0/0] mpls te
[LSRC-GigabitEthernet1/0/0] mpls rsvp-te
# Configure LSRD.
[LSRD] mpls
[LSRD-mpls] mpls te
[LSRD-mpls] quit
[LSRD-GigabitEthernet1/0/0] mpls
[LSRD-GigabitEthernet1/0/0] mpls te
[LSRD-GigabitEthernet1/0/0] mpls rsvp-te
4. Configure IS-IS TE.

# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] traffic-eng level-2
[LSRA-isis-1] quit
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] quit
# Configure LSRD.
[LSRD] isis 1
[LSRD-isis-1] quit
5. Configure the MPLS TE link bandwidth.

# Configure the maximum reservable bandwidth and the maximum BC0 bandwidth of the
link on all tunnel interfaces.
# Configure LSRA.
[LSRA-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRA-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
# Configure LSRB.
[LSRB] interface pos2/0/0


# Configure LSRC.
[LSRC-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRC-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000
6. Configure MPLS TE tunnel interface.

# Create tunnel interfaces on the ingress. Then configure IP addresses for the tunnel
interfaces, tunnel protocol, destination address, tunnel ID, dynamic signaling protocol, and
tunnel bandwidth. Finally, commit the configurations to validate them using the mpls te
commit command.
# Configure LSRA.
[LSRA-Tunnel1/0/0] mpls te signal-protocol rsvp-te
[LSRA-Tunnel1/0/0] mpls te bandwidth ct0 20000
7. Verify the configuration.

After completing the configuration, run the display interface tunnel command on LSRA.
The status of the tunnel interface is Up.
[LSRA] display interface tunnel
Last up time: 2009-01-15, 16:35:10
Description : Tunnel1/0/0 Interface
...
Run the display mpls te tunnel-interface command on LSRA to view tunnel information.
[LSRA] display mpls te tunnel-interface tunnel1/0/0
No : 1
LSR Role : Ingress Lsp Type : Primary
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
ER-Hop Table Index : - AR-Hop Table Index: -
C-Hop Table Index : 0
PSB Handle : 1024
Created Time : 2010/06/07 16:01:18 UTC-08:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------

--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass In Use : Not Exists
Bypass Tunnel Id : -
BypassTunnel : -
Bypass LSP ID : - FrrNextHop : -
ReferAutoBypassHandle : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
Run the display mpls te cspf tedb all command on LSRA to view TEDB link information.
[LSRA] display mpls te cspf tedb all
Maximum Node Supported: 128 Maximum Link Supported: 256
Current Total Node Number: 4 Current Total Link Number: 6
Id Router-Id IGP Process-Id Area Link-Count
1 3.3.3.9 ISIS 1 Level-2 2
2 2.2.2.9 ISIS 1 Level-2 2
3 4.4.4.9 ISIS 1 Level-2 1
4 1.1.1.9 ISIS 1 Level-2 1
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1

ip address 1.1.1.9 255.255.255.255

isis enable 1
#
destination 4.4.4.9
mpls te commit
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
clock master
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#

ip address 30.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
3.30.5 Example for Configuring IGP Shortcut to Import Traffic to

an MPLS TE Tunnel
This section provides an example of how to configure Interior Gateway Protocol (IGP) shortcut
to import traffic to a Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnel.
An MPLS TE tunnel does not automatically import traffic. To import traffic to an MPLS TE
tunnel, you can configure Interior Gateway Protocol (IGP) shortcut. IGP shortcut enables a
device to use a TE tunnel as a logical link for IGP route calculation. You can set a proper metric

for an MPLS TE tunnel so that the route passing through the MPLS TE tunnel is selected with
precedence, allowing traffic to be imported to the MPLS TE tunnel.
On the network shown in Figure 3-7, the label switching routers (LSRs) use Intermediate
System-Intermediate System (IS-IS) to communicate with each other. An MPLS TE tunnel is
established from LSRA and LSRD. The MPLS TE tunnel passes through LSRC. The number
marked on each link indicates the link cost. If LSRA has traffic destined for LSRE and LSRD,
LSRA uses GE 1/0/0 to send the traffic based on the IS-IS route selection result. If the bandwidth
of the link between LSRA and LSRB is 10 Mbit/s and LSRA requires 5 Mbit/s bandwidth to
send traffic to LSRD and 6 Mbit/s bandwidth to send traffic to LSRE, the link between LSRA
and LSRB is congested. As a result, traffic transmission is delayed or packet loss occurs.
To resolve this problem, configure IGP shortcut on the tunnel interface of LSRA to import traffic
destined for LSRD to the MPLS TE tunnel. Then some traffic destined for LSRD is forwarded
through GE 1/0/1. Therefore, network congestion is avoided.
NOTE
After IGP shortcut is configured on the tunnel interface of LSRA, LSRA does not advertise the MPLS TE
tunnel to its peers as a route. The MPLS TE tunnel is used only for local route calculation.
Figure 3-7 IGP shortcut
Loopback1
2.2.2.2/32
LSRE
LSRB
GE1/0/0
10.1.1.2/24
GE1/0/1
GE1/0/0 10.1.3.1/24
10.1.1.1/24 10
LSRA
Loopback1
10
1.1.1.1/32 TE Metric=10 GE1/0/0
GE1/0/1 10.1.3.2/24
10.1.2.1/24 15 LSRD
Loopback1
GE1/0/0 10 4.4.4.4/32
10.1.2.2/24 GE1/0/1
GE1/0/1
LSRC 10.1.4.2/24
10.1.4.1/24
Loopback1
3.3.3.3/32
1. Configure IP addresses for the LSR interfaces (including loopback interfaces), as shown
in Figure 3-7.
2. Enable IS-IS on the LSRs and interfaces, including loopback interfaces, and set a cost for
each IS-IS interface, as shown in Figure 3-7.

3. Establish a Resource Reservation Protocol (RSVP)-TE tunnel from LSRA to LSRD and
configure the RSVP-TE tunnel to pass through LSRC.
4. Enable IGP shortcut on the TE tunnel interface of LSRA and configure an IGP metric for
the TE tunnel, as shown in Figure 3-7.
Data Preparation

l IS-IS area ID, originating system ID, and IS-IS level of each LSR
l Cost of each IS-IS interface, as shown in Figure 3-7
l ID of each LSR (the address of the loopback interface on each LSR is used as the LSR ID)
l Maximum reservable link bandwidth (100000 kbit/s) and BC0 bandwidth (80000 kbit/s)
of each outbound interface on an MPLS TE tunnel
l Number (tunnel 1/0/0) and IP address (borrowed from a loopback interface) of an MPLS
TE tunnel interface, and ID (100), destination address (4.4.4.4), signaling protocol (RSVP-
TE), and bandwidth (50000 kbit/s) of an MPLS TE tunnel
l Absolute IGP metric (10) of an MPLS TE tunnel
Procedure
Configure an IP address for each interface, as shown in Figure 3-7, and create a loopback
interface on each LSR. For configuration details, see Configuration Files in this section.
Step 2 Configure IS-IS to advertise routes.
Create an IS-IS process on each LSR, configure a network entity title (NET) name and an IS-IS
level for the IS-IS process, set the cost style to wide, enable IS-IS on each interface, and set a
cost for each interface.
# Configure LSRA.
<LSRA> system-view
[LSRA] isis 1
[LSRA-isis-1] quit
[LSRA-GigabitEthernet1/0/0] isis cost 10
# Configure LSRB.
<LSRB> system-view
[LSRB] isis 1


[LSRB-isis-1] quit
[LSRB-GigabitEthernet1/0/0] isis cost 10
# Configure LSRC.
<LSRC> system-view
[LSRC] isis 1
[LSRC-isis-1] quit
[LSRC-GigabitEthernet1/0/0] isis cost 15
# Configure LSRD.
<LSRD> system-view
[LSRD] isis 1
[LSRD-isis-1] quit
[LSRD-GigabitEthernet1/0/0] isis cost 10
After you complete the preceding configurations, run the display ip routing-table command
on LSRA. The command output shows that the next-hop address of the route destined for LSRD
is 10.1.1.2 and the outbound interface of this route is GE 1/0/0.
------------------------------------------------------------------------------


2.2.2.2/32 ISIS-L2 15 10 D 10.1.1.2
3.3.3.3/32 ISIS-L2 15 15 D 10.1.2.2
4.4.4.4/32 ISIS-L2 15 20 D 10.1.1.2
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.2.0/24 Direct 0 0 D 10.1.2.1
10.1.2.1/32 Direct 0 0 D 127.0.0.1
10.1.3.0/24 ISIS-L2 15 20 D 10.1.1.2
10.1.4.0/24 ISIS-L2 15 25 D 10.1.2.2
Step 3 Configure basic MPLS functions and enable MPLS TE, RSVP-TE, and Constraint Shortest Path
First (CSPF).
Enable MPLS, MPLS TE, and RSVP-TE on each LSR and their interfaces along the tunnel, and
enable CSPF in the MPLS view of LSRA.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] mpls te
[LSRC-mpls] quit
# Configure LSRD.
[LSRD] mpls
[LSRD-mpls] mpls te

[LSRD-mpls] quit
Step 4 Configure IS-IS TE.
# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] quit
# Configure LSRD.
[LSRD] isis 1
[LSRD-isis-1] quit
# Configure LSRA.
# Configure LSRC.
Step 6 Configure an MPLS TE tunnel interface.
# Configure LSRA.
[LSRA-Tunnel1/0/0] ip address unnumbered interface LoopBack1
Step 7 Configure IGP shortcut.
Enable IGP shortcut on a TE tunnel interface, set the absolute IGP metric to 10, and enable IS-
IS.
# Configure LSRA.
[LSRA-Tunnel1/0/0] mpls te igp shortcut isis
[LSRA-Tunnel1/0/0] mpls te igp metric absolute 10
[LSRA-Tunnel1/0/0] isis enable 1

# Run the display ip routing-table command on LSRA. The command output shows that the
next-hop address of the route destined for LSRD is 1.1.1.1 and the outbound interface of this
route is tunnel 1/0/0. The traffic destined for LSRD has been imported to the MPLS TE tunnel.
------------------------------------------------------------------------------

2.2.2.2/32 ISIS-L2 15 10 D 10.1.1.2
3.3.3.3/32 ISIS-L2 15 15 D 10.1.2.2
4.4.4.4/32 ISIS-L2 15 10 D 1.1.1.1 Tunnel1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1
10.1.2.1/32 Direct 0 0 D 127.0.0.1
10.1.3.0/24 ISIS-L2 15 20 D 10.1.1.2
ISIS-L2 15 20 D 1.1.1.1
10.1.4.0/24 ISIS-L2 15 20 D 1.1.1.1
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis cost 10
#
undo shutdown

ip address 10.1.2.1 255.255.255.0

isis enable 1
isis cost 15
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 4.4.4.4
mpls te igp shortcut isis
mpls te commit
isis enable 1
#
return

#
sysname LSRB
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
isis cost 10
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
isis cost 10
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2

#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
isis cost 15
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.1 255.255.255.0
isis enable 1
isis cost 10
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
isis cost 10
#
undo shutdown
ip address 10.1.4.2 255.255.255.0
isis enable 1
isis cost 10
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return

3.30.6 Example for Configuring Forwarding Adjacency to Import

Traffic to an MPLS TE Tunnel
This section provides an example of how to configure forwarding adjacency to import traffic to
a Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnel.
An MPLS TE tunnel does not automatically import traffic. To import traffic to an MPLS TE
tunnel, you can configure forwarding adjacency. Unlike Interior Gateway Protocol (IGP)
shortcut, forwarding adjacency enables a device to advertise a TE tunnel to its peers as an IGP
route. You can set a proper metric for an MPLS TE tunnel so that the route passing through the
MPLS TE tunnel is preferred, allowing traffic to be imported to the MPLS TE tunnel.
On the network shown in Figure 3-8, the label switching routers (LSRs) use Intermediate
System-Intermediate System (IS-IS) to communicate with each other. An MPLS TE tunnel is
established from LSRA and LSRD. The MPLS TE tunnel passes through LSRC. The number
marked on each link indicates the link cost. If LSRA and LSRE have traffic destined for LSRD,
the traffic passes through the link between LSRB and LSRD based on the IS-IS route selection
result. If the bandwidth of the link between LSRB and LSRD is 5 Mbit/s and both LSRA and
LSRE require 5 Mbit/s bandwidth to send traffic to LSRD, the link between LSRB and LSRD
is congested. As a result, traffic transmission is delayed or packet loss occurs.
To resolve this problem, configure forwarding adjacency on the MPLS TE tunnel interface of
LSRA. Then traffic from LSRA to LSRD is forwarded over the MPLS TE tunnel, whereas some
traffic from LSRE to LSRD is forwarded by LSRB and the other traffic is sent to the LSRA and
forwarded over the MPLS TE tunnel. Therefore, traffic congestion is prevented over the link
between LSRB and LSRD.
NOTE
After you configure forwarding adjacency, LSRA advertises the MPLS TE tunnel to its peer as an IS-IS
route. Because IS-IS requires bidirectional link detection, the MPLS TE tunnel from LSRD to LSRA must
be established and forwarding adjacency must be configured on the tunnel interface of LSRD.

Figure 3-8 Forwarding adjacency
Loopback1 Loopback1
10 GE1/0/2 LSRB
LSRE
GE1/0/1 GE1/0/1
GE1/0/0
GE1/0/0
10
10 10
GE1/0/2 GE1/0/0
GE1/0/0
TE Metric=10
Loopback1 Loopback1
LSRA GE1/0/1 LSRC GE1/0/1 LSRD
15 10
GE1/0/0 GE1/0/1
Loopback1
Device Interface IP Address Device Interface IP Address

Name Name and Mask Name Name and Mask
LSRA Loopback1 1.1.1.1/32 LSRB Loopback1 2.2.2.2/32
GE 1/0/0 10.1.1.1/24 GE 1/0/0 10.1.1.2/24
GE 1/0/1 10.1.2.1/24 GE 1/0/1 10.1.3.1/24
GE 1/0/2 10.1.5.1/24 GE 1/0/2 10.1.6.2/24
LSRC Loopback1 3.3.3.3/32 LSRD Loopback1 4.4.4.4/32
GE 1/0/0 10.1.2.2/24 GE 1/0/0 10.1.3.2/24
GE 1/0/1 10.1.4.1/24 GE 1/0/1 10.1.4.2/24
LSRE Loopback1 5.5.5.5/32
GE 1/0/0 10.1.5.2/24
GE 1/0/1 10.1.6.1/24
1. Configure IP addresses for the LSR interfaces (including loopback interfaces), as shown
in Figure 3-8.

2. Enable IS-IS on the LSRs and interfaces, including loopback interfaces, and set a cost for
each IS-IS interface, as shown in Figure 3-8.
3. Establish a Resource Reservation Protocol (RSVP)-TE tunnel from LSRA to LSRD and
an RSVP-TE tunnel from LSRD to LSRA, and configure the RSVP-TE tunnels to pass
through LSRC.
4. Enable forwarding adjacency on the TE tunnel interfaces of LSRA and LSRD, and
configure an IGP metric for each TE tunnel, as shown in Figure 3-8.
Data Preparation
l IS-IS area ID, originating system ID, and IS-IS level of each LSR
l Cost of each IS-IS interface, as shown in Figure 3-8
l ID of each LSR (the address of the loopback interface on each LSR is used as the LSR ID)
l Maximum reservable link bandwidth (100000 kbit/s) and BC0 bandwidth (80000 kbit/s)
of each outbound interface on each MPLS TE tunnel
l Number (tunnel 1/0/0) and IP address (borrowed from a loopback interface) of the MPLS
TE tunnel interface on LSRA, and ID (100), destination address (4.4.4.4), signaling
protocol (RSVP-TE), and bandwidth (50000 kbit/s) of an MPLS TE tunnel
l Number (tunnel 1/0/0) and IP address (borrowed from a loopback interface) of the MPLS
TE tunnel interface on LSRD, and ID (101), destination address (1.1.1.1), signaling
protocol (RSVP-TE), and bandwidth (50000 kbit/s) of an MPLS TE tunnel
l Absolute IGP metric (10) of each MPLS TE tunnel
Procedure
Configure an IP address for each interface, as shown in Figure 3-8, and create a loopback
interface on each LSR. For configuration details, see Configuration Files in this section
Create an IS-IS process on each LSR, configure a network entity title (NET) name and an IS-IS
level for the IS-IS process, set the cost style to wide, enable IS-IS on each interface, and set a
cost for each interface.
# Configure LSRA.
<LSRA> system-view
[LSRA] isis 1
[LSRA-isis-1] quit


# Configure LSRB.
<LSRB> system-view
[LSRB] isis 1
[LSRB-isis-1] quit
# Configure LSRC.
<LSRC> system-view
[LSRC] isis 1
[LSRC-isis-1] quit
# Configure LSRD.
<LSRD> system-view
[LSRD] isis 1
[LSRD-isis-1] quit


# Configure LSRE.
<LSRE> system-view
[LSRE] isis 1
[LSRE-isis-1] network-entity 00.0005.0000.0000.0005.00
[LSRE-isis-1] quit
[LSRE] interface gigabitethernet 1/0/0
[LSRE-GigabitEthernet1/0/0] isis enable 1
[LSRE-GigabitEthernet1/0/0] isis cost 10
[LSRE-GigabitEthernet1/0/0] quit
[LSRE-GigabitEthernet1/0/1] isis cost 10
After you complete the preceding configurations, run the display ip routing-table command
on LSRA. The command output shows that the next-hop address of the route destined for LSRD
is 10.1.1.2 and the outbound interface of this route is GE 1/0/0.
------------------------------------------------------------------------------

2.2.2.2/32 ISIS-L2 15 10 D 10.1.1.2
3.3.3.3/32 ISIS-L2 15 15 D 10.1.2.2
4.4.4.4/32 ISIS-L2 15 20 D 10.1.1.2
5.5.5.5/32 ISIS-L2 15 10 D 10.1.5.2
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.2.0/24 Direct 0 0 D 10.1.2.1
10.1.2.1/32 Direct 0 0 D 127.0.0.1
10.1.3.0/24 ISIS-L2 15 20 D 10.1.1.2
10.1.4.0/24 ISIS-L2 15 25 D 10.1.2.2
10.1.5.0/24 Direct 0 0 D 10.1.5.1
10.1.5.1/32 Direct 0 0 D 127.0.0.1
10.1.6.0/24 ISIS-L2 15 20 D 10.1.5.2
ISIS-L2 15 20 D 10.1.1.2

# Run the display ip routing-table command on LSRE. The command output shows that the
route is GE 1/0/1.
------------------------------------------------------------------------------
1.1.1.1/32 ISIS-L2 15 10 D 10.1.5.1

2.2.2.2/32 ISIS-L2 15 10 D 10.1.6.2
3.3.3.3/32 ISIS-L2 15 25 D 10.1.5.1
4.4.4.4/32 ISIS-L2 15 20 D 10.1.6.2
10.1.1.0/24 ISIS-L2 15 20 D 10.1.5.1
ISIS-L2 15 20 D 10.1.6.2
10.1.2.0/24 ISIS-L2 15 25 D 10.1.5.1
10.1.3.0/24 ISIS-L2 15 20 D 10.1.6.2
10.1.4.0/24 ISIS-L2 15 30 D 10.1.6.2
10.1.5.0/24 Direct 0 0 D 10.1.5.2
10.1.5.2/32 Direct 0 0 D 127.0.0.1
10.1.6.0/24 Direct 0 0 D 10.1.6.1
10.1.6.1/32 Direct 0 0 D 127.0.0.1
Step 3 Configure basic MPLS functions and enable MPLS TE, RSVP-TE, and Constraint Shortest Path
First (CSPF).
Enable MPLS, MPLS TE, and RSVP-TE on each LSR and their interfaces along each tunnel,
and enable CSPF in the MPLS view of LSRA and LSRD.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] mpls te


[LSRC-mpls] quit
# Configure LSRD.
[LSRD] mpls
[LSRD-mpls] mpls te
[LSRD-mpls] quit
[LSRD-GigabitEthernet1/0/1] mpls te cspf

# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] quit
# Configure LSRD.
[LSRD] isis 1
[LSRD-isis-1] quit

# Configure LSRA.
# Configure LSRC.
# Configure LSRD.


[LSRD-GigabitEthernet1/0/1] mpls te bandwidth max-reservable-bandwidth 100000
[LSRD-GigabitEthernet1/0/1] mpls te bandwidth bc0 80000

# Configure LSRA.
# Configure LSRD.
[LSRD] interface tunnel 1/0/0
[LSRD-Tunnel1/0/0] ip address unnumbered interface LoopBack1
[LSRD-Tunnel1/0/0] tunnel-protocol mpls te
[LSRD-Tunnel1/0/0] destination 1.1.1.1
[LSRD-Tunnel1/0/0] mpls te tunnel-id 101
[LSRD-Tunnel1/0/0] mpls te signal-protocol rsvp-te
[LSRD-Tunnel1/0/0] mpls te bandwidth ct0 50000
Step 7 Configure forwarding adjacency.

Enable forwarding adjacency on the tunnel interfaces of LSRA and LSRD, set the absolute IGP
metric to 10 for each tunnel, and enable IS-IS.
# Configure LSRA.
[LSRA-Tunnel1/0/0] mpls te igp advertise
[LSRA-Tunnel1/0/0] isis enable 1
# Configure LSRD.
[LSRD-Tunnel1/0/0] mpls te igp advertise
[LSRD-Tunnel1/0/0] mpls te igp metric absolute 10
[LSRD-Tunnel1/0/0] isis enable 1
[LSRD-Tunnel1/0/0] quit

# Run the display ip routing-table command on LSRA. The command output shows that the
route is tunnel 1/0/0. The traffic destined for LSRD has been imported to the MPLS TE tunnel.
------------------------------------------------------------------------------

2.2.2.2/32 ISIS-L2 15 10 D 10.1.1.2

3.3.3.3/32 ISIS-L2 15 15 D 10.1.2.2

4.4.4.4/32 ISIS-L2 15 10 D 1.1.1.1 Tunnel1/0/0
5.5.5.5/32 ISIS-L2 15 10 D 10.1.5.2
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.2.0/24 Direct 0 0 D 10.1.2.1
10.1.2.1/32 Direct 0 0 D 127.0.0.1
10.1.3.0/24 ISIS-L2 15 20 D 10.1.1.2
ISIS-L2 15 20 D 1.1.1.1 Tunnel1/0/0
10.1.4.0/24 ISIS-L2 15 20 D 1.1.1.1 Tunnel1/0/0
10.1.5.0/24 Direct 0 0 D 10.1.5.1
10.1.5.1/32 Direct 0 0 D 127.0.0.1
10.1.6.0/24 ISIS-L2 15 20 D 10.1.5.2
ISIS-L2 15 20 D 10.1.1.2
# Run the display ip routing-table command on LSRE. The command output shows that there
are two equal-cost routes destined for LSRD. The next-hop address and outbound interface of
one route are 10.1.6.2 and GE 1/0/1, and the next-hop address and outbound interface of the
other route are 10.1.5.1 and GE 1/0/0. Traffic destined for LSRD is forwarded over two paths.
The traffic sent out from GE 1/0/0 is forwarded to LSRA and over the MPLS TE tunnel.
------------------------------------------------------------------------------
1.1.1.1/32 ISIS-L2 15 10 D 10.1.5.1

2.2.2.2/32 ISIS-L2 15 10 D 10.1.6.2
3.3.3.3/32 ISIS-L2 15 25 D 10.1.5.1
4.4.4.4/32 ISIS-L2 15 20 D 10.1.6.2
ISIS-L2 15 20 D 10.1.5.1
10.1.1.0/24 ISIS-L2 15 20 D 10.1.5.1
ISIS-L2 15 20 D 10.1.6.2
10.1.2.0/24 ISIS-L2 15 25 D 10.1.5.1
10.1.3.0/24 ISIS-L2 15 20 D 10.1.6.2
10.1.4.0/24 ISIS-L2 15 30 D 10.1.6.2
ISIS-L2 15 30 D 10.1.5.1
10.1.5.0/24 Direct 0 0 D 10.1.5.2

10.1.5.2/32 Direct 0 0 D 127.0.0.1

10.1.6.0/24 Direct 0 0 D 10.1.6.1
10.1.6.1/32 Direct 0 0 D 127.0.0.1
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis cost 10
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
isis cost 15
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.1 255.255.255.0
isis enable 1
isis cost 10
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 4.4.4.4
mpls te commit
isis enable 1

#
return

#
sysname LSRB
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
isis cost 10
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
isis cost 10
#
undo shutdown
ip address 10.1.6.2 255.255.255.0
isis enable 1
isis cost 10
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
isis cost 15
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.1 255.255.255.0
isis enable 1
isis cost 10

mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
isis cost 10
#
undo shutdown
ip address 10.1.4.2 255.255.255.0
isis enable 1
isis cost 10
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
destination 1.1.1.1
mpls te commit
isis enable 1
#
return

#
sysname LSRE
#
isis 1
is-level level-2

cost-style wide
network-entity 00.0005.0000.0000.0005.00
#
undo shutdown
ip address 10.1.5.2 255.255.255.0
isis enable 1
isis cost 10
#
undo shutdown
ip address 10.1.6.1 255.255.255.0
isis enable 1
isis cost 10
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
3.30.7 Example for Configuring a Tunnel Protection Group

This section provides an example for configuring a tunnel protection group.
Two CR-LSPs are established between PE1 and PE2 on the network shown in Figure 3-9. One
CR-LSP is bound to a working tunnel configured on Tunnel 1/0/10, and the other CR-LSP is
bound to a protection tunnel configured on Tunnel 1/0/11.
These two tunnels can form a tunnel protection group to protect the working tunnel. This allows
MPLS TE to use its own detection mechanism to detect faults instead of other detection
mechanisms, such as BFD and OAM.

Figure 3-9 MPLS TE tunnel protection group
Loopback1
3.3.3.3/32
GE1/0/0 GE1/0/1
10.1.2.2/30 10.1.4.1/30
P2
GE1/0/1 Loopback1
2.2.2.2/32 GE1/0/1
10.1.2.1/30 10.1.4.2/30
GE1/0/0 GE1/0/0
1.1.1.1/32 GE1/0/0 GE1/0/1 4.4.4.4/32
PE1 10.1.1.2/30 P1 10.1.3.1/30 PE2
Working tunnel
Protection tunnel
1. Assign an IP address to each interface on every device shown in Figure 3-9 and set IS-IS
parameters to ensure network layer connectivity.
2. Configure RSVP-TE tunnels between PE1 and PE2 over separate explicit paths.
3. Bind the protection tunnel to the working tunnel to form a tunnel protection group.
Data Preparation
l IP address of each interface on every device shown in Figure 3-9

l IGP protocol (IS-IS), process ID (1), system ID (loopback1 address), and IS-IS level
(level-2)
l LSR ID (loopback interface address) of every MPLS device
l Maximum reservable bandwidth (100,000 kbit/s) on every outbound interface of the
working and protection tunnels and BC0 bandwidth (100,000 kbit/s)
l Explicit path name for the working tunnel (tope2–main) and protection tunnel (tope2–
backup)
l Working tunnel's tunnel interface number (Tunnel 1/0/10) and tunnel ID (100) and
protection tunnel's tunnel interface number (Tunnel 1/0/11) and tunnel ID (101); tunnel IP
address (loopback interface address); tunnel bandwidth (20,000 kbit/s)

l Switchback mode (revertive) and WTR time (wtr-time is 4, which is multiplied by 30

seconds to obtain 120 seconds.)
Procedure
the host route to each loopback address (used as an LSR ID).
Configure IS-IS on each node to ensure device connectivity. For configuration details, see
Step 3 Configure MPLS, MPLS TE, and RSVP-TE on each node and interface, and enable CSPF on
the ingress PE1.
# Configure PE1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] mpls rsvp-te
[PE1-mpls] mpls te cspf
[PE1-mpls] quit
[PE1] interface gigabitethernet 1/0/0
[PE1-GigabitEthernet1/0/0] mpls rsvp-te
# Configure P1.
<P1> system-view
[P1] mpls
[P1-mpls] mpls te
[P1-mpls] mpls rsvp-te
[P1-mpls] quit
[P1] interface gigabitethernet 1/0/0
[P1-GigabitEthernet1/0/0] mpls
[P1-GigabitEthernet1/0/0] mpls te
[P1-GigabitEthernet1/0/0] mpls rsvp-te
[P1-GigabitEthernet1/0/0] quit
# Configure P2.
<P2> system-view
[P2] mpls
[P2-mpls] mpls te

[P2-mpls] quit
# Configure PE2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] mpls te
[PE2-mpls] quit

# Configure PE1.
[PE1] isis 1
[PE1-isis-1] cost-style wide
[PE1-isis-1] traffic-eng level-2
[PE1-isis-1] quit
# Configure P1.
[P1] isis 1
[P1-isis-1] cost-style wide
[P1-isis-1] traffic-eng level-2
[P1-isis-1] quit
# Configure P2.
[P2] isis 1
[P2-isis-1] quit
# Configure PE2.
[PE2] isis 1
[PE2-isis-1] quit
Step 5 Configure the maximum reservable bandwidth and BC0 bandwidth for a link connected to the
outbound interface of each node.
# Configure PE1.


# Configure P1.
[P1-GigabitEthernet1/0/1] mpls te bandwidth max-reservable-bandwidth 100000
[P1-GigabitEthernet1/0/1] mpls te bandwidth bc0 100000
# Configure P2.
Step 6 Configure explicit paths on PE1.
# Configure PE1.
[PE1] explicit-path tope2-main
[PE1-explicit-path-tope2-main] next hop 10.1.1.2
[PE1-explicit-path-tope2-main] quit
[PE1] explicit-path tope2-backup
[PE1-explicit-path-tope2-backup] next hop 10.1.2.2
[PE1-explicit-path-tope2-backup] quit
Step 7 Configure the working and protection tunnels.
Create tunnel interfaces for the working and protection tunnels on PE1. Configure an IP address
of a tunnel interface, a tunnel protocol, a destination IP address, a tunnel ID, a dynamic signaling
protocol, and bandwidth for each tunnel. Bind each of the tunnels to an explicit path.
# Configure PE1.
[PE1-Tunnel1/0/10] mpls te signal-protocol rsvp-te
[PE1-Tunnel1/0/10] mpls te bandwidth ct0 20000
[PE1-Tunnel1/0/10] mpls te path explicit-path tope2-main
[PE1-Tunnel1/0/11] mpls te path explicit-path tope2-backup
Step 8 Configure a tunnel protection group.

# Configure the tunnel on Tunnel 1/0/10 as a working tunnel and the tunnel on Tunnel 1/0/11
as a protection tunnel. Configure both of them to work in revertive mode. Set the WTR time to
120s.
# After completing the configuration, run the display mpls te protection tunnel tunnel-id
verbose command on PE1 to view details about the tunnel protection group.
[PE1] display mpls te protection tunnel 100 verbose
----------------------------------------------------------------
----------------------------------------------------------------
Work-tunnel reverse-lsp : --
Protect-tunnel reverse-lsp : --
Bridge type : 1:1
Switch type : unidirectional
HoldOff : 0ms
WTR : 120s
Mode : revertive
Using same path : --
# Run the display interface tunnel interface-number command on PE1 to view information
about tunnel interfaces of the working and protection tunnels.
[PE1] display interface tunnel 1/0/10
Last line protocol up time : 2012-05-28 17:33:00 UTC-08:00
Description:HUAWEI, Tunnel1/0/10 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack1(1.1.1.1/32)
Encapsulation is TUNNEL, loopback not set
Tunnel destination 4.4.4.4
Tunnel up/down statistics 1
Tunnel protocol/transport MPLS/MPLS, ILM is available,
primary tunnel id is 0x800803, secondary tunnel id is 0x800802
Switch Result is working tunnel
Current system time: 2012-05-28 17:55:55-08:00
300 seconds output rate 0 bits/sec, 0 packets/sec
0 packets output, 0 bytes
0 output error
0 output drop
ct0:0 packets output, 0 bytes

0 output error
0 packets output drop
Input bandwidth utilization : --
Output bandwidth utilization : --
0 output error
0 output drop
0 output error
# Run the tracert lsp te tunnel interface-number command on PE1 to view information about
the path of the working tunnel.
[PE1] tracert lsp te Tunnel 1/0/10
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1/0/10 , press CTRL_C
to break.
TTL Replier Time Type Downstream
0 Ingress 10.1.1.2/[1026 ]
1 10.1.1.2 80 ms Transit 10.1.3.2/[3 ]
2 4.4.4.4 70 ms Egress
# Run the shutdown command on GE 1/0/0/ of PE1 to simulate a working tunnel failure.
[PE1-GigabitEthernet1/0/0] shutdown
Switch Result is protection tunnel
0 output error
0 output drop


0 output error
0 output error
0 output drop
0 output error
Run the tracert lsp te tunnel interface-number command on PE1. The command output shows
that traffic has switched to the protection tunnel.
to break.
0 Ingress 10.1.2.2/[1025 ]
1 10.1.2.2 90 ms Transit 10.1.4.2/[3 ]
2 4.4.4.4 80 ms Egress
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path tope2-backup
next hop 10.1.2.2
next hop 10.1.4.2
#
explicit-path tope2-main
next hop 10.1.1.2
next hop 10.1.3.2
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00

traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.2.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 4.4.4.4
mpls te path explicit-path tope2-main
mpls te commit
#
destination 4.4.4.4
mpls te path explicit-path tope2-backup
mpls te commit
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls

mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.2.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#

isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.3.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return
3.30.8 Example for Configuring a Tunnel Protection Group Using

Dynamic BFD to Detect Faults
This section provides an example for configuring a tunnel protection group using dynamic BFD
to detect the faults of CR-LSPs.
Two CR-LSPs are established between PE1 and PE2 on the network shown in Figure 3-10. One
CR-LSP is bound to a working tunnel configured on Tunnel 1/0/10, and the other CR-LSP is
bound to a protection tunnel configured on Tunnel 1/0/11.
These two tunnels can form a tunnel protection group to protect the working tunnel. This allows
MPLS TE to use dynamic BFD to detect faults.

Figure 3-10 MPLS TE tunnel protection group
Loopback1
3.3.3.3/32
GE1/0/0 GE1/0/1
10.1.2.2/30 10.1.4.1/30
P2
GE1/0/1 Loopback1
2.2.2.2/32 GE1/0/1
10.1.2.1/30 10.1.4.2/30
GE1/0/0 GE1/0/0
1.1.1.1/32 GE1/0/0 GE1/0/1 4.4.4.4/32
PE1 10.1.1.2/30 P1 10.1.3.1/30 PE2
Working tunnel
Protection tunnel
1. Assign an IP address to each interface on every device shown in Figure 3-10 and set IS-
IS parameters to ensure network layer connectivity.
2. Configure RSVP-TE tunnels between PE1 and PE2 over separate explicit paths.
3. Bind the protection tunnel to the working tunnel to form a tunnel protection group.
4. Enable the capability of dynamically creating BFD sessions on the ingress of working
tunnel, and enable the capability of passively creating BFD sessions on the egress of
working tunnel.
Data Preparation
l IP address of each interface on every device shown in Figure 3-10

l IGP protocol (IS-IS), process ID (1), system ID (loopback1 address), and IS-IS level
(level-2)
l LSR ID (loopback interface address) of every MPLS device
l Maximum reservable bandwidth (100,000 kbit/s) on every outbound interface of the
working and protection tunnels and BC0 bandwidth (100,000 kbit/s)
l Explicit path name for the working tunnel (tope2–main) and protection tunnel (tope2–
backup)

l Working tunnel's tunnel interface number (Tunnel 1/0/10) and tunnel ID (100) and
protection tunnel's tunnel interface number (Tunnel 1/0/11) and tunnel ID (101); tunnel IP
address (loopback interface address); tunnel bandwidth (20,000 kbit/s)
l Switchback mode (revertive) and WTR time (wtr-time is 4, which is multiplied by 30
seconds to obtain 120 seconds.)
l The minimum interval for sending packets of a BFD session on the ingress (100 ms), the
minimum interval for receiving packets of a BFD session (100 ms) and the local detection
multiplier value (3). (The default values are specified in the License.)
Procedure
the host route to each loopback address (used as an LSR ID).
Configure IS-IS on each node to ensure device connectivity. For configuration details, see
Step 3 Configure MPLS, MPLS TE, and RSVP-TE on each node and interface, and enable CSPF on
the ingress PE1.
# Configure PE1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] quit
# Configure P1.
<P1> system-view
[P1] mpls
[P1-mpls] mpls te
[P1-mpls] quit

# Configure P2.
<P2> system-view
[P2] mpls
[P2-mpls] mpls te
[P2-mpls] quit
# Configure PE2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] mpls te
[PE2-mpls] quit
# Configure PE1.
[PE1] isis 1
[PE1-isis-1] quit
# Configure P1.
[P1] isis 1
[P1-isis-1] quit
# Configure P2.
[P2] isis 1
[P2-isis-1] quit
# Configure PE2.
[PE2] isis 1

[PE2-isis-1] quit
Step 5 Configure the maximum reservable bandwidth and BC0 bandwidth for a link connected to the
outbound interface of each node.
# Configure PE1.
# Configure P1.
# Configure P2.
Step 6 Configure explicit paths on PE1.

# Configure PE1.
[PE1] explicit-path tope2-main
[PE1-explicit-path-tope2-main] quit
[PE1] explicit-path tope2-backup
[PE1-explicit-path-tope2-backup] quit
Step 7 Configure the working and protection tunnels.

Create tunnel interfaces for the working and protection tunnels on PE1. Configure an IP address
of a tunnel interface, a tunnel protocol, a destination IP address, a tunnel ID, a dynamic signaling
protocol, and bandwidth for each tunnel. Bind each of the tunnels to an explicit path.
# Configure PE1.
[PE1-Tunnel1/0/10] mpls te path explicit-path tope2-main


[PE1-Tunnel1/0/11] mpls te path explicit-path tope2-backup
# Configure the tunnel on Tunnel 1/0/10 as a working tunnel and the tunnel on Tunnel 1/0/11
as a protection tunnel. Configure both of them to work in revertive mode. Set the WTR time to
120s.
Step 9 Configure dynamic BFD
# Enable BFD on the ingress of the tunnel (PE1) and configure MPLS TE BFD.
[PE1] bfd
[PE1-bfd] quit
[PE1-Tunnel1/0/10] mpls te bfd enable
[PE1-Tunnel1/0/10] mpls te bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 3
# Enable the capability of passively creating BFD sessions on the egress of the tunnel (PE2).
[PE2] bfd
[PE2-bfd] mpls-passive
[PE2-bfd] quit
# After completing the configuration, run the display mpls te protection tunnel tunnel-id
verbose command on PE1 to view details about the tunnel protection group.
[PE1] display mpls te protection tunnel 100 verbose
----------------------------------------------------------------
----------------------------------------------------------------
Work-tunnel reverse-lsp : --
Protect-tunnel reverse-lsp : --
Bridge type : 1:1
Switch type : unidirectional
HoldOff : 0ms
WTR : 120s
Mode : revertive


# Run the display bfd session all command on PE1. The status of the BFD sessions is Up.
[PE1] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
8196 8197 4.4.4.4 Up D_TE_LSP Tunnel1/0/10
--------------------------------------------------------------------------------
Switch Result is working tunnel
0 output error
0 output drop
0 output error
0 output error
0 output drop
0 output error
# Run the tracert lsp te tunnel interface-number command on PE1 to view information about
the path of the working tunnel.

to break.
0 Ingress 10.1.1.2/[1026 ]
1 10.1.1.2 80 ms Transit 10.1.3.2/[3 ]
2 4.4.4.4 70 ms Egress
# Run the shutdown command on GE 1/0/0/ of PE1 to simulate a working tunnel failure.
Switch Result is protection tunnel
0 output error
0 output drop
0 output error
0 output error
0 output drop
0 output error
Run the tracert lsp te tunnel interface-number command on PE1. The command output shows
that traffic has switched to the protection tunnel.

to break.
0 Ingress 10.1.2.2/[1025 ]
1 10.1.2.2 90 ms Transit 10.1.4.2/[3 ]
2 4.4.4.4 80 ms Egress
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path tope2-backup
next hop 10.1.2.2
next hop 10.1.4.2
#
explicit-path tope2-main
next hop 10.1.1.2
next hop 10.1.3.2
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.2.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 4.4.4.4


mpls te bfd enable
mpls te bfd min-tx-interval 100 min-rx-interval 100
mpls te path explicit-path tope2-main
mpls te commit
#
destination 4.4.4.4
mpls te path explicit-path tope2-backup
mpls te commit
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1

is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.2.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
bfd
mpls-passive
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.3.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1

#
return
3.30.9 Example for Configuring an Associated Bidirectional

Dynamic LSP
This section uses an example to describe the procedure for configuring an associated
bidirectional dynamic LSP, including the establishment of MPLS TE tunnels in opposite
directions and the configuration of reverse LSPs.
On an MPLS network shown in Figure 3-11, two MPLS TE tunnels in opposite directions
(LSRA-LSRB-LSRC and LSRC-LSRB-LSRA) are established. To ensure that traffic switching
is performed at the same time on tunnels in opposite directions, perform the configuration related
to the associated bidirectional dynamic LSP in the interface view of each tunnel.
Figure 3-11 Networking diagram for configuring an associated bidirectional dynamic LSP
Loopback1
2.2.2.2/32
0 GE2
/0 /
Loopback1 GE1 /24 2 0 .1 /0 /0 Loopback1
1 . 2 . 1 . 1
1.1.1.1/32 0.1. /24 3.3.3.3/32
1
0 LSRB G
1 /0/ /24 20.1 E1/0/0
E
G .1.1 . 1 .1 .2
0 /24
1
LSRE LSRA LSRC LSRF
LSRD
1. Configure an IP address for every interface and the loopback interface address used as an
LSR ID.
2. Enable IS-IS globally.
3. Enable MPLS TE, RSVP-TE, and CSPF globally.
4. Enable IS-IS TE.
5. Configure an MPLS TE explicit path.
6. Configure forward and backward TE tunnel interfaces.
7. Configure the egress to assign a non-null label to the penultimate hop, and configure a
reverse LSP so that the reverse LSP and the forward LSP can form an associated
bidirectional dynamic LSP.

Data Preparation
l IS-IS area ID, initial system ID, IS-IS level of each node
l Interface number and IP address of each tunnel interface as well as destination address,
tunnel ID, and tunnel signaling protocol to be specified on each tunnel interface
Procedure
Step 1 Configure an IP address for every interface.
Configure an IP address and mask for each interface as shown in Figure 3-11. For configuration
# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] quit
Step 3 Configure basic MPLS functions and enable MPLS TE, RSVP-TE, and CSPF.
# Enable MPLS, MPLS TE, and RSVP-TE globally and in the interface view on each node, and
enable CSPF on the ingress of the forward tunnel (LSRA) and the backward tunnel (LSRC).

# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] mpls te
[LSRB-mpls] quit
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] mpls te
[LSRC-mpls] quit
# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] quit
# Configure LSRC.
[LSRC] isis 1

[LSRC-isis-1] quit
Step 5 Configure an MPLS TE explicit path.
# Configure LSRA.
[LSRA] explicit-path a-b-c
[LSRA-explicit-path-a-b-c] next hop 10.1.1.2 include strict
[LSRA-explicit-path-a-b-c] quit
# Configure LSRC.
[LSRC] explicit-path c-b-a
[LSRC-explicit-path-c-b-a] next hop 20.1.1.1 include strict
[LSRC-explicit-path-c-b-a] quit
Step 6 Configure TE tunnel interfaces.
# Configure LSRA and the forward TE tunnel interface.

[LSRA-Tunnel1/0/0] mpls te path explicit-path a-b-c
# Configure LSRC and the reverse TE tunnel interface.

[LSRC-Tunnel1/0/0] mpls te signal-protocol rsvp-te
[LSRC-Tunnel1/0/0] mpls te path explicit-path c-b-a
Step 7 Configure the egress to assign a non-null label to the penultimate hop, and configure a reverse
LSP so that the reverse LSP and the forward LSP can form an associated bidirectional dynamic
LSP.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] label advertise non-null
[LSRA-mpls] quit
[LSRA-Tunnel1/0/0] mpls te reverse-lsp protocol rsvp-te ingress-lsr-id 3.3.3.3
tunnel-id 100
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] label advertise non-null
[LSRC-mpls] quit
[LSRC-Tunnel1/0/0] mpls te reverse-lsp protocol rsvp-te ingress-lsr-id 1.1.1.1
tunnel-id 100


Check information about the associated bidirectional dynamic LSP on LSRA. You can view that
the associated bidirectional dynamic LSP has been established and is in the Up state.
[LSRA] display mpls te reverse-lsp tunnel-interface tunnel 1/0/0
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
IngressLsrID SessionID InLabel State SignalledTunnelName ObverseTunnel
-------------------------------------------------------------------------------
3.3.3.3 1 3241 Up Tunnel1/0/0 Tunnel1/0/0
Check information about the associated bidirectional dynamic LSP on LSRC. You can view that
the associated bidirectional dynamic LSP has been established and is in the Up state.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
label advertise non-null
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
explicit-path backup a-b-c
next hop 10.1.1.2
next hop 20.1.1.1
next hop 20.1.1.2
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 3.3.3.3
mpls te reverse-lsp protocol rsvp-te ingress-lsr-id 3.3.3.3 tunnel-id 100
mpls te path explicit-path a-b-c
mpls te commit
#

return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
explicit-path backup c-b-a
next hop 20.1.1.1
next hop 10.1.1.2
next hop 10.1.1.1
#
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1

ip address 3.3.3.3 255.255.255.255

isis enable 1
#
destination 1.1.1.1
mpls te reverse-lsp protocol rsvp-te ingress-lsr-id 1.1.1.1 tunnel-id 100
mpls te path explicit-path c-b-a
mpls te commit
#
return
3.30.10 Example for Setting Up a CR-LSP by Using the CR-LSP

Attribute Template
This section provides an example for setting up a CR-LSP by using a CR-LSP attribute template,
including the configurations of enabling MPLS and MPLS TE, configuring a CR-LSP attribute
template, and using the CR-LSP attribute template to set up a CR-LSP.
On the network shown in Figure 3-12, a primary CR-LSP is set up, with LSRA being the ingress
and LSRD being the egress. The primary CR-LSP needs to be configured with a hot-standby
CR-LSP and an ordinary backup CR-LSP. In this manner, when the primary CR-LSP fails, traffic
can be switched to the hot-standby CR-LSP or ordinary backup CR-LSP.
Figure 3-12 Networking diagram for setting up a CR-LSP by using a CR-LSP attribute template
LSRC
/0 PO
1 /0 4 1 S2
S 2 0 .1.4 /0/0
PO .1.2/ .1/2 PO
/0 .1 41 S
1.1.1.1/32 S1/0 4 10 0.1 1/0/0 4.4.4.4/32
/2 .
PO .1.1 4.2
0 .1 POS2/0/0 LSRE POS2/0/0 /24
1
10.1.3.1/24 10.1.6.2/24
PO POS1/0/0 POS2/0/0
/0
LSRA 10 S3/
.1. 0/0
10.1.3.2/24 10.1.6.1/24
S 3/0 /24 LSRD
2.1 PO .5.2
/24 PO 0 .1
10 S1/ / 0/ 10
.1. 0/0 S2 /24
2.2
/24 PO .5.1
.1
10
LSRB
1. Configure an IP address and a routing protocol for each interface so that they can
communicate with each other at the network layer.
2. Enable MPLS and MPLS TE in the system view and in each interface view.

3. Configure a CR-LSP attribute template on the ingress of the CR-LSP.

4. Create a CR-LSP on the TE tunnel interface by using the CR-LSP attribute template.
Data Preparation
l LSR ID of each device

l Name of each CR-LSP attribute template and attributes of each template
l IP address of the tunnel interface, destination address of the tunnel, and tunnel ID
Procedure
Step 1 Configure an IP address and an IGP for each interface so that they can communicate with each
other at the network layer.
Step 2 Configure the LSR ID for each device, and enable MPLS and MPLS TE in the system and
interface views on each device.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
[LSRA-Pos1/0/0] mpls rsvp-te
NOTE
Repeat this step for LSRB, LSRC, LSRD, and LSRE. For configuration details, see Configuration Files
in this section.
Step 3 Configure a CR-LSP attribute template and its explicit paths.
# On LSRA, configure the path LSRA->LSRC->LSRD as the explicit path named up_path.
[LSRA] explicit-path up_path
[LSRA-explicit-path-up_path] next hop 10.1.1.2
[LSRA-explicit-path-up_path] quit
# On LSRA, configure the path LSRA->LSRB->LSRD as the explicit path named

down_path.

[LSRA] explicit-path down_path

[LSRA-explicit-path-down_path] next hop 10.1.2.2
[LSRA-explicit-path-down_path] quit
# On LSRA, configure the path LSRA->LSRE->LSRD as the explicit path named

middle_path.
[LSRA] explicit-path middle_path
[LSRA-explicit-path-middle_path] next hop 10.1.3.2
[LSRA-explicit-path-middle_path] quit
# On LSRA, configure the CR-LSP attribute template named lsp_attribute_1.

[LSRA] lsp-attribute lsp_attribute_1
[LSRA-lsp-attribuLSP_attribute_1] explicit-path up_path
[LSRA-lsp-attribuLSP_attribute_1] priority 5 5
[LSRA-lsp-attribuLSP_attribute_1] hop-limit 12
[LSRA-lsp-attribuLSP_attribute_1] commit

[LSRA-lsp-attribuLSP_attribute_2] explicit-path down_path

[LSRA-lsp-attribuLSP_attribute_3] explicit-path middle_path
NOTE
The priorities of the CR-LSP attribute templates configured on the same tunnel interface must be the same.
Step 4 Set up a CR-LSP by using the CR-LSP attribute template, with LSRA being the ingress and
LSRD being the egress.
# Set up a CR-LSP, with LSRA being the ingress and LSRD being the egress.
[LSRA] interface tunnel1/0/0
[LSRA-Tunnel1/0/0] mpls te primary-lsp-constraint lsp-attribute lsp_attribute_1
[LSRA-Tunnel1/0/0] mpls te hotstandby-lsp-constraint 1 lsp-attribute
lsp_attribute_2
[LSRA-Tunnel1/0/0] mpls te ordinary-lsp-constraint 1 lsp-attribute lsp_attribute_3
# Run the display mpls te tunnel-interface lsp-constraint command on LSRA. You can view
the configurations of the LSP attribute template.
<LARA> display mpls te tunnel-interface lsp-constraint
Tunnel Name : Tunnel1/0/0
Primary-lsp-constraint Name : lsp_attribute_1
Hotstandby-lsp-constraint Number: 1
Hotstandby-lsp-constraint Name : lsp_attribute_2
Ordinary-lsp-constraint Number : 1
Ordinary-lsp-constraint Name : lsp_attribute_3

# Run the display mpls te tunnel verbose on LSRA. You can see that the LSP attribute template
is used to set up a CR-LSP.
<LSRA> display mpls te tunnel verbose
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : 1
ER-Hop Table Index : 0 AR-Hop Table Index: 0
PrevTunnelIndexInSession: 1 NextTunnelIndexInSession: -
PSB Handle : 1024
Created Time : 2010/07/01 17:40:35 UTC-08:00
RSVP LSP Type : Primary
--------------------------------
DS-TE Information
--------------------------------
Bandwidth Reserved Flag : Unreserved
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
No : 2
LSR Role : Ingress LSP Type : Hot-Standby

In-Interface : -
IncludeAllAff : 0x0
LspConstraint : 1
PrevTunnelIndexInSession: - NextTunnelIndexInSession: 0
PSB Handle : 1025
Created Time : 2010/07/01 17:40:36 UTC-08:00
RSVP LSP Type : Hot-Standby
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# After shutting down POS 1/0/0 on LSRC and POS 1/0/0 on LSRB, you can see that the LSP
attribute template is used to set up an ordinary CR-LSP.
No : 1
LSR Role : Ingress LSP Type : Ordinary
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : 1

PSB Handle : 1212
Created Time : 2010/07/02 15:24:18 UTC-08:00
RSVP LSP Type : Ordinary
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
#
explicit-path middle_path
next hop 10.1.3.2
next hop 10.1.6.2
#
explicit-path up_path
next hop 10.1.1.2
next hop 10.1.4.2
#
explicit-path down_path
next hop 10.1.2.2
next hop 10.1.5.2
#
lsp-attribute lsp_attribute_1

priority 5
hop-limit 12
commit
#
priority 5
hop-limit 15
commit
#
priority 5
commit
#
interface Pos1/0/0
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.3.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
ip address 10.1.2.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 4.4.4.4
mpls te primary-lsp-constraint lsp-attribute lsp_attribute_1
mpls te hotstandby-lsp-constraint 1 lsp-attribute lsp_attribute_2
mpls te ordinary-lsp-constraint 1 lsp-attribute lsp_attribute_3
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.1 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
mpls-te enable
#
return

#
sysname LSRB
#
mpls lsr-id 10.1.5.1
mpls
mpls te
mpls rsvp-te
#

interface Pos1/0/0
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.5.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.5.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRC
#
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.4.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.4.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
ip address 10.1.4.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0

ip address 10.1.6.2 255.255.255.0

mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
ip address 10.1.5.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
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 10.1.4.0 0.0.0.255
network 10.1.5.0 0.0.0.255
network 10.1.6.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRE
#
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
ip address 10.1.3.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.6.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
network 10.1.3.0 0.0.0.255
network 10.1.6.0 0.0.0.255
mpls-te enable
#
return
3.30.11 Example for Configuring RSVP Authentication

This section provides an example for configuring RSVP authentication, which improves network
security.
On the network shown in Figure 3-13, Eth-Trunk 1 member interfaces on LSRA and LSRB are
GE 1/0/0, GE 2/0/0, and GE 3/0/0. An MPLS TE tunnel using RSVP is established between
LSRA and LSRC.

The handshake function is required to implement RSVP key authentication between LSRA and
LSRB and prevent forged RSVP requests for reserving resources from exhausting resources. In
addition, the message window function is required to prevent RSVP message mis-sequence.
Figure 3-13 Networking diagram for RSVP authentication

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
Eth-Trunk 1 Eth-Trunk 1
10.1.1.1/24 10.1.1.2/24
GE1/0/0 GE1/0/0 GE4/0/0 GE1/0/0

LSRA LSRB 20.1.1.1/24 20.1.1.2/24 LSRC
GE2/0/0 GE2/0/0
GE3/0/0 GE3/0/0
1. Configure an MPLS network and set up an MPLS TE tunnel.
2. Configure authentication on every interface to authenticate RSVP messages.
3. Configure the handshake on every interface.
4. Configure the window size on every interface to enable the interface to save 32 sequence
numbers.
NOTE
A sliding window greater than 32 is recommended. If the sliding window is too small, RSVP messages
with the sequence number out of the window size are discarded, resulting in the termination of an RSVP
neighbor relationship.
Data Preparation
l OSPF process ID and area ID of the interface on each LSR
l RSVP authentication key
l Window size for RSVP authentication
Procedure
Assign an IP address and mask to each interface according to Figure 3-13. For detailed
configuration, see Configuration Files in this example.
Step 2 Configure OSPF.
Configure OSPF on all LSRs to advertise the route to the network segment of each interface and
the host route of each LSR ID. For detailed configuration, see Configuration Files in this
example.

The command output shows that the LSRs have learned routes from each other.
Step 3 Configure basic MPLS functions and enable MPLS TE, MPLS RSVP-TE, and CSPF.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
[LSRA] interface eth-trunk 1
[LSRA-Eth-Trunk1] mpls
[LSRA-Eth-Trunk1] mpls te
[LSRA-Eth-Trunk1] mpls rsvp-te
[LSRA-Eth-Trunk1] quit
NOTE
Repeat this step for LSRB and LSRC. For configuration details, see Configuration Files in this section.
Step 4 Configure OSPF TE.
# Configure LSRA.
[LSRA] ospf 1
[LSRA-ospf-1-area-0.0.0.0] mpls-te enable
# Configure LSRB.
[LSRB] ospf 1
[LSRB-ospf-1-area-0.0.0.0] mpls-te enable
# Configure LSRC.
[LSRC] ospf 1
[LSRC-ospf-1-area-0.0.0.0] mpls-te enable
Step 5 Configure the MPLS TE tunnel.
# Configure the MPLS TE tunnel on LSRA.

command output shows that the tunnel interface is Up.
[LSRA] display interface tunnel 1/0/0


Last up time: 2007-9-27, 16:38:41
Description : Tunnel1/0/0 Interface, Route Port
...
Step 6 Configure the RSVP authentication on interfaces of the MPLS TE links on LSRA and LSRB.
# Configure LSRA.
[LSRA] interface eth-trunk 1
[LSRA-Eth-Trunk1] mpls rsvp-te authentication cipher Huawei_123456789
[LSRA-Eth-Trunk1] mpls rsvp-te authentication handshake
[LSRA-Eth-Trunk1] mpls rsvp-te authentication window-size 32
# Configure LSRB.
[LSRB] interface eth-trunk 1
[LSRB-Eth-Trunk1] mpls rsvp-te authentication cipher Huawei_123456789
[LSRB-Eth-Trunk1] mpls rsvp-te authentication handshake
[LSRB-Eth-Trunk1] mpls rsvp-te authentication window-size 32
Run the reset mpls rsvp-te command and then run the display interface tunnel command on
LSRA. The command output shows that the tunnel interface is Up.
Run the display mpls rsvp-te interface command on LSRA or LSRB to view information about
RSVP authentication.
[LSRA] display mpls rsvp-te interface eth-trunk 1
Interface: Eth-Trunk1
Interface Address: 10.1.1.1
Interface state: UP Interface Index: 0x406
Total-BW: 0 Used-BW: 0
Hello configured: NO Num of Neighbors: 1
SRefresh feature: DISABLE SRefresh Interval: 30 sec
Mpls Mtu: 1500 Retransmit Interval: 500 msec
Increment Value: 1
Authentication: ENABLE
Challenge: ENABLE WindowSize: 32
Next Seq # to be sent:3570642420 4 Key ID: d5d7adf41800
Bfd Enabled: DISABLE Bfd Min-Tx: 10
Bfd Min-Rx: 10 Bfd Detect-Multi: 3
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
interface Eth-Trunk1
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
mpls rsvp-te authentication cipher @%@%^1%rCnn(+B'T-mX0oFQ/$~JL@%@%

mpls rsvp-te authentication window-size 32

#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 3.3.3.3
mpls te tunnel-id 1
mpls te commit
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
mpls-te enable
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
interface Eth-Trunk1
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
mpls rsvp-te authentication cipher @%@%^1%rCnn(+B'T-mX0oFQ/$~JL@%@%
mpls rsvp-te authentication window-size 32
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
undo shutdown
eth-trunk 1
#
ip address 20.1.1.1 255.255.255.0
mpls
mpls te

mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
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
network 2.2.2.2 0.0.0.0
mpls-te enable
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
interface GigabiEthernet1/0/0
ip address 20.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 3.3.3.3 0.0.0.0
mpls-te enable
#
Return
3.30.12 Example for Configuring Tunnel Properties

This section provides an example for configuring the properties of an MPLS TE tunnel, including
the maximum available bandwidth, maximum reservable bandwidth, and the Color field, which
is an administrative group property for each link.
Figure 3-14 Networking diagram for configuring tunnel properties

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
POS1/0/0 POS2/0/0 POS1/0/0
192.168.1.1/24 192.168.2.1/24 192.168.2.2/24
POS1/0/0
LSRA 192.168.1.2/24 LSRB POS3/0/0 POS2/0/0 LSRC
192.168.3.1/24 192.168.3.2/24

On the network shown in Figure 3-14, the bandwidth of the link LSRA -> LSRB is 50 Mbit/s.
The maximum reservable bandwidth of other links is 100 Mbit/s and BC0 bandwidth is 100
Mbit/s.
LSRA has two tunnels to LSRC, Tunnel 1/0/0 and Tunnel 1/0/1, each of which requires 40 Mbit/
s bandwidth. These two tunnels provide the total bandwidth of 80 Mbit/s, greater than the
bandwidth (50 Mbit/s) of the link between LSRA and LSRB. In addition, Tunnel 1/0/1 has a
higher priority than Tunnel 1/0/0, and preemption is allowed.
It is required to use the tunnel affinity and mask based on the administrative group. Tunnel 1/0/0
on LSRA uses one physical link from LSRB to LSRC, and Tunnel 1/0/1 uses another physical
link from LSRB to LSRC.
1. Configure basic MPLS TE capability. (See "Configuration Roadmap" in Example for

Configuring the RSVP-TE Tunnel.)
2. Configure administrative group properties of the outbound interface of the tunnel on each
node along the tunnel.
3. Determine the affinity and mask of each tunnel based on the administrative group properties
and networking requirements.
4. Specify the priority of tunnels.
Data Preparation
l OSPF process ID and OSPF area ID of each LSR

l Maximum reservable bandwidth and BC bandwidth for the link along the tunnel
l Administrative group property of the link LSRA --> LSRB and administrative group
property of the link LSRB --> LSRC
l Affinity property and its mask
l Tunnel interface name, IP address, destination address, tunnel ID, tunnel bandwidth, tunnel
priority, and tunnel signaling protocol (by default, RSVP-TE is used.)
Procedure
Step 1 Assign IP addresses to interfaces.
Assign an IP address and mask to each interface, including the loopback interfaces, according
to Figure 3-14.
Step 2 Configure the IGP protocol.
Configure OSPF on all LSRs to advertise the route to network segment of each interface and
LSR ID.

Step 3 Configure the basic MPLS functions, and enable MPLS TE, RSVP-TE, and OSPF TE. Enable
CSPF on the ingress.
# Configure the basic MPLS functions, and enable MPLS TE and RSVP-TE on LSRA, LSRB,
and LSRC.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
# Configure OSPF TE on LSRA, LSRB, and LSRC. The following example uses the command
output on LSRA.
[LSRA] ospf
[LSRA-ospf-1] quit
section.
# Enable CSPF on LSRA, the ingress node.
[LSRA] mpls
[LSRA-mpls] quit
Step 4 Configure MPLS TE properties for the links.

# Set the maximum reservable bandwidth to 100 Mbit/s, and the BC0 bandwidth to 100 Mbit/
s.
# Set the administrative group property to 0x10001 for the link on LSRA.
[LSRA-Pos1/0/0] mpls te link administrative group 10001
# Set the MPLS TE properties for the links on LSRB.

[LSRB-Pos2/0/0] mpls te link administrative group 10101
[LSRB-Pos3/0/0] mpls te link administrative group 10011
After the configuration, check the TEDB on LSRA for the following properties:

l Maximum bandwidth
l Maximum reservable bandwidth
l Color field, that is, the administrative group property of the links
[LSRA] display mpls te cspf tedb node
Router ID: 1.1.1.1
IGP Type: OSPF Process Id: 1
MPLS-TE Link Count: 1
Link[1]:
Interface IP Address(es): 192.168.1.1
Peer IP Address: 192.168.1.2
Peer Router Id: 2.2.2.2
Peer OSPF Router Id: 2.2.2.2
IGP Area: 0
Link Type: point-to-point Link Status: Active
IGP Metric: 1 TE Metric: 1 Color: 0x10001
Bandwidth Allocation Model : Russian Doll Model
Maximum Link-Bandwidth: 50000 (kbps)
Maximum Reservable Bandwidth: 50000 (kbps)
Bandwidth Constraints: Local Overbooking Multiplier:
BC[0]: 50000 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 50000 (kbps), [1]: 50000 (kbps)

[2]: 50000 (kbps), [3]: 50000 (kbps)
[4]: 50000 (kbps), [5]: 50000 (kbps)
[6]: 50000 (kbps), [7]: 50000 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Router ID: 2.2.2.2
Link[1]:
IGP Area: 0
BC[0]: 100000 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)

[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)

[6]: 100000 (kbps), [7]: 100000 (kbps)

[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Link[2]:
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Link[3]:
IGP Area: 0
BC[0]: 100000 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)

[2]: 100000 (kbps), [3]: 100000 (kbps)

[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 100000 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Router ID: 3.3.3.3
Link[1]:
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Link[2]:
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1

BC[1]: 0 (kbps) LOM[1]: 1

BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Step 5 Create MPLS TE tunnels.

# Create Tunnel 1/0/0 on LSRA.
[LSRA-Tunnel1/0/0] mpls te affinity property 10101 mask 11011
The tunnels use the default setup and holding priorities, which are the lowest priority with the
value being 7.
The affinity of the tunnel is 0x10101, and the mask is 0x11011, both of which match the
administrative group of the links along the tunnel.
Check the status of the tunnel on LSRA.
[LSRA] display mpls te tunnel-interface
----------------------------------------------------------------
Tunnel1/0/0
----------------------------------------------------------------
Active LSP : Primary LSP
Session ID : 100
Check the TEDB. You can view the change in bandwidth used by the links.
[LSRA] display mpls te cspf tedb node
Router ID: 1.1.1.1
Link[1]:

IGP Area: 0
BC[0]: 50000 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 50000 (kbps), [1]: 50000 (kbps)
[2]: 50000 (kbps), [3]: 50000 (kbps)
[4]: 50000 (kbps), [5]: 50000 (kbps)
[6]: 50000 (kbps), [7]: 10000 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Router ID: 2.2.2.2
Link[1]:
IGP Area: 0
BC[0]: 100000 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 60000 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Link[2]:


IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Link[3]:
IGP Area: 0
BC[0]: 100000 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 100000 (kbps), [1]: 100000 (kbps)
[2]: 100000 (kbps), [3]: 100000 (kbps)
[4]: 100000 (kbps), [5]: 100000 (kbps)
[6]: 100000 (kbps), [7]: 100000 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)

Router ID: 3.3.3.3

Link[1]:
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
Link[2]:
IGP Area: 0
BC[0]: 0 (kbps) LOM[0]: 1
BC[1]: 0 (kbps) LOM[1]: 1
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)
[8]: 0 (kbps), [9]: 0 (kbps)
[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved:
Class ID:
[0]: 0 (kbps), [1]: 0 (kbps)
[2]: 0 (kbps), [3]: 0 (kbps)
[4]: 0 (kbps), [5]: 0 (kbps)
[6]: 0 (kbps), [7]: 0 (kbps)

[8]: 0 (kbps), [9]: 0 (kbps)

[10]: 0 (kbps), [11]: 0 (kbps)
[12]: 0 (kbps), [13]: 0 (kbps)
[14]: 0 (kbps), [15]: 0 (kbps)
BW Unreserved for Class type 0 indicates the available bandwidth from the maximum
reservable bandwidth for various priorities. The command output shows that the unreserved
bandwidth changes for CT7 on the outbound interfaces on each LSR along the tunnel. This
means that some tunnels successfully reserve 40 Mbit/s bandwidth with priority 7. The
bandwidth allocation also shows the path that the tunnel uses. This indicates that the affinity and
the mask of the tunnel must match the administrative group of the links.
Run the display mpls te tunnel command on LSRB to view the outbound interface of the tunnel.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 1 3/-- I Tunnel1/0/0
# Create Tunnel 1/0/1 on LSRA.

[LSRA-Tunnel1/0/1] mpls te affinity property 10011 mask 11101
[LSRA-Tunnel1/0/1] mpls te priority 6
After completing the configuration, run the display interface Tunnel or display mpls te tunnel-
interface command to check the status of the tunnel on LSRA. The command output shows that
the status of Tunnel 1/0/0 is Down. This is because the maximum reservable bandwidth of the
physical link (LSRA --> LSRB) is insufficient, and the bandwidth of Tunnel 1/0/0 is preempted
by Tunnel 1/0/1 with a higher priority.
Run the display mpls te cspf tedb node command to check the TEDB and the changes in
bandwidth used on the links. The command output proves that Tunnel 1/0/1 passes by POS 3/0/0
on LSRB.
Run the display mpls te tunnel command on LSRB. You can view the outbound interface of
the tunnel.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 1 3/-- I Tunnel1/0/1
----End
Configuration Files
#

sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
mpls
mpls te
mpls te link administrative group 10001
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 3.3.3.3
mpls te affinity property 10101 mask 11011
mpls te commit
#
destination 3.3.3.3
mpls te priority 6
mpls te affinity property 10001 mask 11101
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp

ip address 192.168.2.1 255.255.255.0

mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
link-protocol ppp
ip address 192.168.3.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
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 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
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 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
mpls-te enable
#
return

3.30.13 Example for Configuring SRLG (TE Auto FRR)

This section provides an example for configuring the Shared Risk Link Group (SRLG) based
on TE Auto FRR, including configuring the SRLG number and configuring the SRLG path
calculation mode.
Figure 3-15 shows a Networking diagram for an MPLS network. An RSVP-TE tunnel has been
set up between PE1 and PE2, the path of the tunnel is PE1 --> P1 --> PE2, and the outbound
interface of the tunnel on P1 is GE 2/0/0.
Links to network segments 10.2.1.0/30 and 10.5.1.0/30 are in SRLG 1.
To enhance the reliability of the tunnel, it is required that TE Auto FRR be enabled on P1 and
that the auto bypass tunnel's path is preferred to avoid the links that have a member in the same
SRLG as the link of the primary tunnel. If no path is available, the path calculation is performed
regardless of the SRLG attribute.
Figure 3-15 Networking diagram for TE Auto FRR

Loopback1
2.2.2.2/32
G
P2 10 E2/0
.4. /0
1.1
/3 0
GE1/0/0
10.3.1.2/30
Loopback1 10 GE
4.4.4.4/32 GE4/0/0 .4 . 3 /0
1 .2 /0
10.3.1.1 /30 /30
GE2/0/0 GE1/0/0
PE1 P1 10.2.1.1/30 10.2.1.2/30 PE2
GE1/0/0 GE1/0/0 GE3/0/0 GE2/0/0
10.1.1.1/30 10.1.1.2/30 10.5.1.1/30 SRLG1 10.5.1.2/30
Loopback1 Loopback1
1.1.1.1/32 5.5.5.5/32
Path of the primary CR-LSP
1. Configure IP address and enable IGP on each node.

2. Enable MPLS, MPLS TE and MPLS RSVP-TE globally and in the interfaces view of each
node.
3. Configure IS-IS TE on each node and enable CSPF on PE1 and P1.
4. Configure SRLG numbers for SRLG member interfaces.

5. Configure the SRLG path calculation mode in the system view on the PLR node.
6. Set up an RSVP-TE tunnel between PE1 and PE2, with the explicit path being PE1 --> P1
--> PE2.
7. Enable TE FRR in the tunnel interface view of the ingress and enable TE Auto FRR on the
outbound interface of the primary tunnel on PLR node.
Data Preparation
l SRLG number
l SRLG path calculation mode (preferred or strict)
Procedure
As shown in Figure 3-15, configure an IP address for each interface, create loopback interface
on each node, and then configure the IP address of the loopback interface as the MPLS LSR ID.
Step 2 Configure an IGP.
Configure OSPF or IS-IS on each node to ensure that nodes can communicate with each other.
The example in this document use IS-IS. For configuration details, see Configuration Files in
this section.
On each node, configure an LSR ID and enable MPLS in the system view. Enable MPLS in the
interface view. For configuration details, see Configuration Files in this section.
Step 4 Configure basic MPLS TE functions.
On each node, enable MPLS-TE and MPLS RSVP-TE in the MPLS view and in the interface
view. Configure the maximum bandwidth and maximum reservable bandwidth for each
interface. For configuration details, see the configuration file of this example.
Step 5 Configure IS-IS TE and CSPF.
Configure IS-IS TE on each node and CSPF on PE1 and P1. For configuration details, see
Step 6 Configure SRLG
# On P1, add links to network segments 10.2.1.0/30 10.5.1.0/30 to SRLG 1.

[P1-GigabitEthernet2/0/0] mpls te srlg 1
[P1-GigabitEthernet3/0/0] mpls te srlg 1
# Configure the SRLG path calculation mode on the PLR node.

[P1] mpls
[P1-mpls] mpls te srlg path-calculation preferred

# Run the display mpls te srlg command on P1 to view information about the SRLG and the
interfaces that belong to the SRLG.
[P1] display mpls te srlg all
Total SRLG supported : 512
Total SRLG configured : 2
SRLG 1: GE2/0/0 GE3/0/0
# Run the display mpls te link-administration srlg-information command on P1 to view

information about the SRLG memberships of the interfaces.
[P1] display mpls te link-administration srlg-information
SRLGs on GigabitEthernet2/0/0:
1
SRLGs on GigabitEthernet3/0/0:
1
# Run the display mpls te cspf tedb srlg command on P1 to view TEDB information of the
specified SRLG.
[P1] display mpls te cspf tedb srlg 1
Interface-Address IGP-Type Area
10.2.1.1 ISIS 1
10.5.1.1 ISIS 1
10.2.1.1 ISIS 2
10.5.1.1 ISIS 2
Step 7 Configure the explicit path of the primary tunnel.
# Configure the explicit path of the primary tunnel on PE1.

<PE1> system-view
[PE1] explicit-path main
[PE1-explicit-path-main] next hop 10.1.1.2
[PE1-explicit-path-main] quit
# Display information about the explicit path on PE1.

[PE1] display explicit-path main
Path Name : main Path Status : Enabled
1 10.1.1.2 Strict Include
Step 8 Configure the tunnel interfaces for the primary tunnel.
# Create a tunnel interface on PE1, specify an explicit path, and configure the tunnel bandwidth.
[PE1-Tunnel1/0/0] mpls te path explicit-path main
# Run the display interface tunnel 1/0/0 command on PE1. The status of the tunnel is Up.
...

NOTE
Take note of the preceding items that appear in the display interface tunnel 1/0/0 command output.
Information in "..." can be ignored.
Step 9 Configure TE Auto FRR.

# Enable TE auto FRR on the GE2/0/0 of P1.
[P1-GigabitEthernet2/0/0] mpls te auto-frr link
# Enable TE FRR in the tunnel interface view of PE1.

[PE1-Tunnel1/0/0] mpls te fast-reroute
Run the display mpls te tunnel path Tunnel1/0/0 command on PE1. The local protection is
available on the outbound interface (10.2.1.1) of the primary tunnel on P1.
[PE1] display mpls te tunnel path Tunnel1/0/0
Lsp ID : 5.5.5.5 :1
Hop Information
Hop 0 10.1.1.1
Hop 1 10.1.1.2 Label 65536
Hop 2 1.1.1.1 Label 65536
Hop 3 10.2.1.1 Local-Protection available
Hop 4 10.2.1.2 Label 3
Hop 5 5.5.5.5 Label 3

# Run the display mpls te tunnel name Tunnel1/0/0 verbose command on P1. The primary
tunnel is bound with a bypass tunnel, tunnel 0/0/2048. The FRR next hop is 10.4.1.2.
[P1] display mpls te tunnel name Tunnel1/0/0 verbose
No : 1
LSR Role : Transit LSP Type : Primary
In-Interface : GE1/0/0
IncludeAllAff : 0x0
LspConstraint : -

PSB Handle : 65546
Created Time : 2009/03/30 09:52:03
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------

--------------------------------
FRR Information
--------------------------------
Primary LSP Info
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# Run the display mpls te tunnel path Tunnel0/0/2048 command on the P1 to check the path
of the bypass tunnel, you can see that the path of the bypass tunnel is P1-->P2-->PE2.
[P1] display mpls te tunnel path Tunnel0/0/2048
Lsp ID : 1.1.1.1 :2049 :1
Hop Information
Hop 0 10.3.1.1
Hop 1 10.3.1.2
Hop 2 2.2.2.2
Hop 3 10.4.1.1
Hop 4 10.4.1.2
Hop 5 5.5.5.5
# Run the shutdown command on GE 4/0/0 of P1.

[P1] interface gigabitethernet4/0/0
[P1-GigabitEthernet4/0/0] shutdown
[P1-GigabitEthernet4/0/0] return
# Run the display interface tunnel 1/0/0 command on PE1. The status of the primary tunnel is
Up.
...
NOTE
Take note of the preceding items that appear in the display interface tunnel 1/0/0 command output.
# Run the display mpls te tunnel name Tunnel1/0/0 verbose command on P1. The primary
tunnel is still bound with the tunnel 0/0/2048 and the FRR next hop is 10.5.1.2.
<P1> display mpls te tunnel name Tunnel1/0/0 verbose
No : 1


LSR Role : Transit
IncludeAllAff : 0x0
PSB Handle : 65547
Created Time : 2009/03/30 09:52:03
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# Run the display mpls te tunnel path Tunnel0/0/2048 command on P1, you can see the path
of the auto bypass tunnel.
[P1] display mpls te tunnel path Tunnel0/0/2048
Lsp ID : 1.1.1.1 :2049 :2
Hop Information
Hop 0 10.5.1.1
Hop 1 10.5.1.2
Hop 2 5.5.5.5
# You can see that the path of the auto bypass tunnel is P1-->PE2 rather than P1-->P2-->PE2.
That is because that the SRLG path calculation mode is configured as preferred. Therefore,

CSPF tries to calculate the path of the bypass tunnel to avoid the links in the same SRLG as the
protected interface(s); if the calculation fails, CSPF does not take the SRLG as a constraint.
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path main
next hop 10.1.1.2
next hop 10.2.1.2
next hop 5.5.5.5
#
isis 1
cost-style wide
network-entity 10.0000.0000.0004.00
traffic-eng level-1-2
#
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
destination 5.5.5.5
mpls te record-route
mpls te path explicit-path main
mpls te fast-reroute
mpls te commit
#
return
#
sysname P1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te srlg path-calculation preferred
mpls te cspf
#
isis 1

cost-style wide
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls te auto-frr link
mpls te srlg 1
mpls rsvp-te
#
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls te srlg 1
mpls rsvp-te
#
ip address 10.3.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls

mpls te
mpls rsvp-te
#
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0006.00
#
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return

3.30.14 Example for Configuring SRLG (Hot-standby)

This section provides an example for configuring the Shared Risk Link Group (SRLG) based
on hot standby, including configuring the SRLG number and configuring SRLG path calculation
mode.
Figure 3-16 shows a Networking diagram for an MPLS network. An RSVP-TE tunnel has been
set up between the PE1 and PE2 and the path of the tunnel is PE1 --> P1 --> PE2.
The link PE1 --> P1 and the link PE1 --> PE2 are in the same SRLG (SRLG1 for example).
To enhance the reliability of the tunnel, a hot standby CR-LSP is required and the backup tunnel's
path should avoid the links that have a member in the same SRLG as the link of the primary
tunnel.
Figure 3-16 Networking diagram for TE FRR

Loopback0
3.3.3.3/32
GE1/0/4 GE1/0/0
10.1.3.2/24 10.1.5.1/24
P2
GE1/0/3 Loopback0 GE1/0/2
10.1.3.1/24 2.2.2.2/32 10.1.5.2/24
PE1 GE1/0/1 GE1/0/0 PE2
1.1.1.1/32 4.4.4.4/32
GE1/0/1 GE1/0/0
GE1/0/0 10.1.2.2/24 P1 10.1.4.2/24 GE1/0/1
10.1.1.1/24 SRLG 1 10.1.1.2/24
1. Configure IP address and enable IGP on each node.
2. Enable MPLS, MPLS TE and MPLS RSVP-TE globally and in the interface view on all
nodes.
3. Set up an RSVP-TE tunnel between PE1 and PE2, and the explicit path is PE1 --> P1 -->
PE2.
4. Configure SRLG number on the outbound interface of the link that is in the same SRLG
as the link of the primary tunnel.
5. Configure SRLG path calculation mode in the system view on the ingress.
6. Configure a hot-standby CR-LSP.
Data Preparation

l SRLG number (1)

l SRLG path calculation mode (strict)
Procedure
As shown in Figure 3-16, configure an IP address for each interface, create the loopback
interface on each node, and then configure the IP addresses of the loopback interfaces as the
MPLS LSR ID. For configuration details, see Configuration Files in this section.
Step 2 Configure IGP.
Configure OSPF or IS-IS on each node to ensure that nodes can communicate with each other.
The example in this document use IS-IS. For configuration details, see Configuration Files in
this section.
On each node, configure an LSR ID and enable MPLS in the system view. Enable MPLS in the
interface view. For configuration details, see Configuration Files in this section.
Step 4 Configure basic MPLS TE functions and enable MPLS RSVP-TE.
On each node, enable MPLS-TE and MPLS RSVP-TE in the system view and in the interface
view. For configuration details, see Configuration Files in this section.
Configure IS-IS TE on each node and CSPF on PE1. For configuration details, see
Step 6 Configure the explicit path of the primary CR-LSP.
# Configure the explicit path of the primary CR-LSP on PE1.
<PE1> system-view
Step 7 Configure the tunnel interfaces for the primary tunnel.

# Configure PE1.
Step 8 Configure SRLG

# Configure SRLG1 for the link PE1 --> P1 and the link PE1 --> PE2.
[PE1-GigabitEthernet1/0/0] mpls te srlg 1


[PE1-GigabitEthernet1/0/1] mpls te srlg 1
# Configure the SRLG path calculation mode on the ingress.

[PE1] mpls
[PE1-mpls] mpls te srlg path-calculation strict
[PE1-mpls] quit
Step 9 Configure a hot-standby CR-LSP on the ingress.
# Configure PE1.
[PE1-Tunnel1/0/0] mpls te backup hot-standby
Run the display mpls te tunnel-interface tunnel 1/0/0 command on PE1. You can see that the
primary and backup CR-LSPs have been established.
[PE1] display mpls te tunnel-interface tunnel 1/0/0
----------------------------------------------------------------
Tunnel1/0/0
----------------------------------------------------------------
Session ID : 100
Run the display mpls te tunnel path command on PE1 to view the information about path
attributes of MPLS TE tunnels. And you can see that the path of hot standby CR-LSP is PE1 --
> P1 --> PE2, which is not a member in the same SRLG as the link of the primary CR-LSP.
[PE1] display mpls te tunnel path
Lsp ID : 1.1.1.1 :100 :2
Hop Information
Hop 0 10.1.2.1
Hop 1 10.1.2.2
Hop 2 2.2.2.2
Hop 3 10.1.4.1
Hop 4 10.1.4.2
Hop 5 4.4.4.4

Lsp ID : 1.1.1.1 :100 :32771
Hop Information
Hop 0 10.1.3.1
Hop 1 10.1.3.2
Hop 2 3.3.3.3
Hop 3 10.1.5.1
Hop 4 10.1.5.2
Hop 5 4.4.4.4
----End

Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls te srlg path-calculation strict
mpls rsvp-te
mpls te cspf
#
explicit-path main
next hop 10.1.2.2
next hop 10.1.4.2
next hop 4.4.4.4
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0010.0100.1001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls te srlg 1
mpls rsvp-te
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls te srlg 1
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 4.4.4.4
mpls te backup hot-standby
mpls te commit
#
return

#
sysname P1
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0020.0200.2002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.4.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0030.0300.3003.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.5.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.3.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#

interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0040.0400.4004.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.4.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.5.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return
3.30.15 Example for Configuring the Limit Rate for TE Tunnel

Traffic
On the network shown in Figure 3-17, LSRA, LSRB, LSRC, and LSRD run IS-IS. An RSVP-
TE tunnel from LSRA to LSRD is established, and the BC0 bandwidth of the TE tunnel is 20
Mbit/s. The maximum reservable bandwidth of the link along the tunnel is 100 Mbit/s, and
the bandwidth constraints model is RDM, and BC0 bandwidth is 100 Mbit/s.
The rate at which TE traffic is transmitted needs to be limited at 20 Mbit/s or lower. TE traffic
at the rate greater than 20 Mbit/s is dropped.

Figure 3-17 Networking diagram for an RSVP-TE tunnel

Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
LSRA LSRD
GE1/0/0 GE1/0/0
10.1.1.1/24 30.1.1.2/24
GE1/0/0 GE1/0/0
10.1.1.2/24 POS2/0/0 POS2/0/0 30.1.1.1/24
2.2.2.9/32 3.3.3.9/32
LSRB LSRC
1. Configure an MPLS TE tunnel.

2. Configure TE traffic policing.
Data Preparation
l IS-IS area IDs, original system IDs, and IS-IS levels of each LSR
l Maximum reservable bandwidth and BC0 bandwidth of the tunnel
l Interface number, IP address, destination IP address, tunnel ID, tunnel signaling protocol
(RSVP-TE), and bandwidth of the tunnel
1. Configure an MPLS TE tunnel.
For configuration details, see Configuring an RSVP-TE Tunnel.
2. Configure TE traffic policing.
# Configure LSRA.
[LSRA-Tunnel1/0/0] mpls te lsp-tp outbound

After completing the configuration, run the display current-configuration command in
the tunnel interface view of Tunnel1/0/0 on LSRA. The command output contains the mpls
te lsp-tp outbound commandt.

Configuration File
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
destination 4.4.4.9
mpls te commit
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0

link-protocol ppp
clock master
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
ip address 30.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls te mpls te bandwidth max-reservable-bandwidth 100000
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1

is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls te mpls te bandwidth max-reservable-bandwidth 100000
mpls rsvp-te
#
destination 1.1.1.9
mpls te commit
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return
3.30.16 Example for Configuring a DS-TE Tunnel in Non-IETF

Mode (MAM)
This section provides an example for configuring a DS-TE tunnel in non-IETF mode, including
configuring the DS-TE mode, bandwidth constraint module, and mapping of CTs and service
types.
As shown in Figure 3-18, PEs and P on the MPLS backbone network are enabled with OSPF
to interwork with each other. PE1 accesses VPN-A and PE2 accesses VPN-B. VPN-A transmits
EF traffic and VPN-B transmits BE traffic. The QoS requirements of different types of traffic
are as follows:
Traffic Bandwidth Jitter
EF traffic on VPN-A 100 Mbit/s Shorter than 50 ms
BE traffic on VPN-B 200 Mbit/s None
A static DS-TE tunnel between PE1 and PE2 is required to be set up in non-IETF mode to
transmit the preceding traffic. The bandwidth constraints model is required to be MAM and the
bandwidth preemption is not allowed between CTs.

Figure 3-18 Networking diagram for a DS-TE in non-IETF mode
AS: 65410 AS: 65430

VPN-A VPN-A
CE1 CE3
GE1/0/0 GE1/0/0
10.1.1.1/24 10.3.1.1/24
Loopback1
GE1/0/0 2.2.2.9/32 GE1/0/0
10.1.1.2/24 PE1 GE1/0/0 GE2/0/0 PE2 10.3.1.2/24
1.1.1.9/32 GE3/0/0 GE3/0/0 3.3.3.9/32
GE2/0/0 10.10.1.1/24 P 10.11.1.2/24 GE2/0/0
10.2.1.2/24 10.4.1.2/24
MPLS backbone
AS: 100
GE1/0/0 GE1/0/0
10.2.1.1/24 10.4.1.1/24
CE2 CE4
VPN-B VPN-B
AS: 65420 AS: 65440
1. A static CR-LSP is set up for each type of traffic on each VPN because the static TE tunnel
supports the single CT only.
2. Two static CR-LSPs are created in non-IETF mode, with tunnel interfaces of static CR-
LSPs being tunnel 3/0/0 and tunnel 3/0/1 and CTs being CT0 and CT1 separately.
3. Tunnel 3/0/0 is configured to transmit EF traffic of VPN-A and tunnel 3/0/1 is configured
to transmit BE traffic of VPN-B.
4. The reservable bandwidth of the link should be equal to or greater than the total bandwidth
of BCs. The reservable bandwidth of the link is equal to or greater than 300 Mbit/s.
Data Preparation
To configure DS-TE in MAM, you need the following data.
l LSR IDs of PEs and P

l Interface number of the TE tunnel
l Values of the maximum reservable bandwidth and bandwidth values for BCs on each link
l VPN instance name, Route-Distinguisher (RD), VPN target, and name of the tunnel policy
of VPN-A and VPN-B

Procedure
Step 1 Configure IP addresses for interfaces on the PEs and P. Enable OSPF to ensure that the PEs and
P can communicate with each other.
After the configurations, OSPF adjacencies can be created between PE1, P, and PE2. By using
the display ospf peer command, you can see that the status of the adjacency is Full. By using
the display ip routing-table command, you can see that PEs can learn the route to Loopback1
from each other.
Step 2 Configure LSR ID and enable MPLS and MPLS-TE on each PE and P.
# Configuration PE1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] quit
# Configure P.
<P> system-view
[P] mpls
[P-mpls] mpls te
[P-mpls] quit
[P] interface gigabitethernet 1/0/0
[P-GigabitEthernet1/0/0] mpls te
# Configure PE2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] mpls te
[PE2-mpls] quit
Step 3 Configure the DS-TE mode and the bandwidth constraints model on each PE and P.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls te ds-te mode non-ietf
[PE1-mpls] mpls te ds-te bcm mam
[PE1-mpls] quit
# Configure P.
[P] mpls

[P-mpls] mpls te ds-te mode non-ietf

[P-mpls] mpls te ds-te bcm mam
[P-mpls] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] mpls te ds-te mode non-ietf
[PE2-mpls] mpls te ds-te bcm mam
[PE2-mpls] quit
After completing the configuration, run the display mpls te ds-te summary command on a PE
or P to view information about DS-TE configuration.
In the following example, the display on PE1 is used.
[PE1] display mpls te ds-te summary
DS-TE IETF Supported :YES
DS-TE MODE :NON-IETF
Bandwidth Constraint Model :MAM
Step 4 Configure link bandwidth on each PE and P.

# Configure PE1.
[PE1-GigabitEthernet3/0/0] mpls te bandwidth bc0 100000 bc1 200000
# Configure P.
[P-GigabitEthernet1/0/0] mpls te bandwidth bc0 100000 bc1 200000
[P-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000 bc1 200000
# Configure PE2.
[PE2-GigabitEthernet3/0/0] mpls te bandwidth bc0 100000 bc1 200000
After completing the configuration, run the display mpls te link-administration bandwidth-
allocation command on the PE to view information about BC bandwidth allocation for
interfaces.
[PE1] display mpls te link-administration bandwidth-allocation interface
gigabitethernet 3/0/0
Bandwidth Constraint Model : Maximum Allocation Model (MAM)
Maximum Link Reservable Bandwidth(Kbit/sec): 300000
Reservable Bandwidth BC0(Kbit/sec) : 100000
Downstream Bandwidth (Kbit/sec) : 0
----------------------------------------------------------------------

----------------------------------------------------------------------
0 0 0 0 100000 0
1 0 1 0 100000 0
2 0 2 0 100000 0
3 0 3 0 100000 0
4 0 4 0 100000 0
5 0 5 0 100000 0
6 0 6 0 100000 0
7 0 7 0 100000 0
8 1 0 0 200000 0
9 1 1 0 200000 0
10 1 2 0 200000 0
11 1 3 0 200000 0
12 1 4 0 200000 0
13 1 5 0 200000 0
14 1 6 0 200000 0
15 1 7 0 200000 0
----------------------------------------------------------------------
Step 5 Configure tunnel interfaces on PEs.

# Configure PE1.
[PE1] interface tunnel3/0/0
[PE1-Tunnel3/0/0] description For VPN-A_EF
[PE1-Tunnel3/0/1] description For VPN-B_BE
# Configure PE2.
[PE2-Tunnel3/0/0] description For VPN-A_EF
[PE2-Tunnel3/0/1] description For VPN-B_BE
Step 6 Configure a static CR-LSP on each PE and P.

# Configure PE1.
[PE1] static-cr-lsp ingress tunnel-interface tunnel 3/0/0 destination 3.3.3.9


[PE1] static-cr-lsp egress VPN-A_EF incoming-interface gigabitethernet 3/0/0 in-
label 101
[PE1] static-cr-lsp egress VPN-B_BE incoming-interface gigabitethernet 3/0/0 in-
label 201
# Configure P.
[P] static-cr-lsp transit VPN-A_EF-1to2 incoming-interface gigabitethernet1/0/0 in-
label 100 nexthop 10.11.1.2 out-label 100 bandwidth ct0 100000
[P] static-cr-lsp transit VPN-B_BE-1to2 incoming-interface gigabitethernet1/0/0 in-
[P] static-cr-lsp transit VPN-A_EF-2to1 incoming-interface gigabitethernet2/0/0 in-
[P] static-cr-lsp transit VPN-B_BE-2to1 incoming-interface gigabitethernet2/0/0 in-
Configure PE2.
[PE2] static-cr-lsp egress VPN-A_EF incoming-interface gigabitethernet 3/0/0 in-
label 100
[PE2] static-cr-lsp egress VPN-B_BE incoming-interface gigabitethernet 3/0/0 in-
label 200
After completing the configuration, run the display mpls static-cr-lsp command on a PE. The
static CR-LSP goes Up.
In the following example, the display on 3/0/0 of PE1 is used.
[PE1] display mpls static-cr-lsp Tunnel3/0/0
Tunnel3/0/0 3.3.3.9/32 NULL/100 -/S1/0/1 Up
Run the display interface tunnel interface-number command on a PE. The tunnel interface goes
Up.
In the following example, the display on 3/0/0 of PE1 is used.
Last up time: 2008-05-23, 10:03:07
Description :For VPN-A_EF
primary tunnel id is 0x8201002c, secondary tunnel id is 0x0
...
Run the display mpls te link-administration bandwidth-allocation command again. The

bandwidth has been allocated for CT0 and CT1 with priorities of 0.
Bandwidth Constraint Model : Maximum Allocation Model (MAM)


----------------------------------------------------------------------
----------------------------------------------------------------------
0 0 0 100000 0 0
1 0 1 0 0 0
2 0 2 0 0 0
3 0 3 0 0 0
4 0 4 0 0 0
5 0 5 0 0 0
6 0 6 0 0 0
7 0 7 0 0 0
8 1 0 200000 0 0
9 1 1 0 0 0
10 1 2 0 0 0
11 1 3 0 0 0
12 1 4 0 0 0
13 1 5 0 0 0
14 1 6 0 0 0
15 1 7 0 0 0
----------------------------------------------------------------------
Step 7 Bind the inbound interface with the DS domain on a PE.
# Configure PE1.
[PE1-GigabitEthernet1/0/0] trust upstream default
# Configure P.
[P-GigabitEthernet1/0/0] trust upstream default
# Configure PE2.
After completing the configuration, run the display diffserv domain default command on a PE
to view information about the default traffic policy for traffic classification in a DS domain.

[PE1] display diffserv domain default

Diffserv domain name:default
...
mpls-exp-inbound 0 phb be green
mpls-exp-inbound 1 phb af1 green
mpls-exp-inbound 5 phb ef green
mpls-exp-inbound 6 phb cs6 green
mpls-exp-outbound be green map 0
mpls-exp-outbound af1 green map 1
mpls-exp-outbound af1 yellow map 1
mpls-exp-outbound af1 red map 1
mpls-exp-outbound ef green map 5
mpls-exp-outbound cs6 green map 6
...
NOTE
Take note of the preceding items that appear in the display diffserv domain default command output.
Step 8 Configure the mapping of the CT and service type on the PEs and P.
# Configure PE1.
[PE1] ct-flow-mapping mapping1
[PE1-ct-flow-mapping-mapping1] map ct 0 to ef pq
[PE1-ct-flow-mapping-mapping1] map ct 1 to be lpq
[PE1-ct-flow-mapping-mapping1] ct-flow-mapping commit
[PE1-ct-flow-mapping-mapping1] quit
[PE1-GigabitEthernet3/0/0] mpls te ct-flow-mapping mapping1
[PE1-GigabitEthernet3/0/0] mpls te ct-bandwidth unshared
# Configure PE2.
[PE2-GigabitEthernet3/0/0] mpls te ct-bandwidth unshared
# After completing the configuration, run the display ct-flow-mapping command on PEs to
view the mapping relationship between CTs and flow queues.

[PE1] display ct-flow-mapping all
Totle template: 2

template-name:default
map CT 0 to be lpq
map CT 1 to af1 wfq
map CT 2 to af2 wfq
map CT 3 to af3 wfq
map CT 4 to af4 wfq
map CT 5 to ef pq
map CT 6 to cs6 pq
map CT 7 to cs6 pq
template-name:mapping1
map CT 0 to ef pq
map CT 1 to be lpq
Step 9 Create the MP-IBGP peer relationship between PEs, and create the EBGP peer relationship
between PEs and CEs.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] peer 3.3.3.9 as-number 100
[PE1-bgp] peer 3.3.3.9 connect-interface loopback 1
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[PE1-bgp-vpna] import-route direct
[PE1-bgp-vpna] quit
[PE1-bgp] ipv4-family vpn-instance vpnb
[PE1-bgp-vpnb] peer 10.2.1.1 as-number 65420
[PE1-bgp-vpnb] import-route direct
[PE1-bgp-vpnb] quit
NOTE
The configuration of PE2 is similar to that of PE1. The configuration detail is not provided here.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] peer 10.1.1.2 as-number 100
[CE1-bgp] import-route direct
NOTE
The configuration of other CEs (CE2, CE3, and CE4) is similar to that of CE1. The configuration details
are not provided here.
After completing the configuration, run the display bgp vpnv4 all peer command on the PE.
The BGP peer relationship is created between PEs and its status is Established.
[PE1] display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 3 Peers in established state : 3
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
3.3.3.9 4 100 12 18 0 00:09:38 Established 0

Peer of vpn instance:
VPN-Instance vpna, Router ID 1.1.1.9:
10.1.1.1 4 65410 25 25 0 00:17:57 Established 1
VPN-Instance vpnb, Router ID 1.1.1.9:
10.2.1.1 4 65420 21 22 0 00:17:10 Established 1
Step 10 Configure a tunnel policy on the PE.
# Configure PE1.

[PE1] tunnel-policy policya

[PE1-tunnel-policy-policya] tunnel binding destination 3.3.3.9 te tunnel 3/0/0
[PE1-tunnel-policy-policya] quit
[PE1] tunnel-policy policyb
[PE1-tunnel-policy-policyb] tunnel binding destination 3.3.3.9 te tunnel 3/0/1
[PE1-tunnel-policy-policyb] quit
# Configure PE2.
Step 11 Configure VPN instances on PEs and connect CEs to PEs.

# Configure PE1.
[PE1] ip vpn-instance vpna
[PE1-vpn-instance-vpna] ipv4-family
[PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[PE1-vpn-instance-vpna-af-ipv4] tnl-policy policya
[PE1-vpn-instance-vpna-af-ipv] quit
[PE1-vpn-instance-vpna] quit
[PE1] ip vpn-instance vpnb
[PE1-vpn-instance-vpnb] ipv4-family
[PE1-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[PE1-vpn-instance-vpnb-af-ipv4] tnl-policy policyb
[PE1-vpn-instance-vpnb-af-ipv4] quit
[PE1-vpn-instance-vpnb] quit
[PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[PE1-GigabitEthernet1/0/0] ip address 10.1.1.2 24
[PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpnb
# Configure PE2.
[PE2-vpn-instance-vpna-af-ipv4] quit


# Configure IP addresses for interfaces of CEs. The configuration details are not provided here.
After completing the configuration, run the display ipvpn-instance verbose command on the
PE to view the configuration of VPN instances. PEs can ping through the CEs connecting to the
PEs.
After the configuration, connect CE1, CE2, CE3, and CE4 to port 1, port 2, port 3, and port 4
of a tester. Inject EF traffic from port 1 and port 2 to port 2 and port 1 respectively, with the
bandwidth being 100 Mbit/s. Inject BE traffic from port 3 and port 4 to port 2 and port 1
respectively, with the bandwidth being 200 Mbit/s. All the packets are not discarded and the
jitter of EF traffic is shorter than 50 ms.
----End
Configuration Files
#
sysname PE1
#
ip vpn-instance vpna
ipv4-family
route-distinguisher 100:1
tnl-policy policya
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
ip vpn-instance vpnb
ipv4-family
tnl-policy policyb
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls te ds-te bcm mam
#
ct-flow-mapping mapping1
map ct 0 to ef pq
map ct 1 to be lpq
#
undo shutdown
ip binding vpn-instance vpna
ip address 10.1.1.2 255.255.255.0
trust upstream default
#
undo shutdown
ip binding vpn-instance vpnb
ip address 10.2.1.2 255.255.255.0
#
undo shutdown

ip address 10.10.1.1 255.255.255.0

mpls
mpls te
mpls te bandwidth bc0 100000 bc1 200000
mpls te ct-flow-mapping mapping1
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
description For VPN-A_EF
destination 3.3.3.9
mpls te commit
#
description For VPN-B_BE
destination 3.3.3.9
mpls te commit
#
bgp 100
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpna
import-route direct
#
ipv4-family vpn-instance vpnb
import-route direct
#
ospf 1
area 0.0.0.0
network 10.10.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
mpls-te enable
#
static-cr-lsp ingress tunnel-interface Tunnel 3/0/0 destination 3.3.3.9
static-cr-lsp ingress tunnel-interface tunnel 3/0/1 destination 3.3.3.9
static-cr-lsp egress VPN-A_EF incoming-interface gigabitethernet 3/0/0 in-
label 101
static-cr-lsp egress VPN-B_BE incoming-interface gigabitethernet 3/0/0 in-
label 201
#
tunnel-policy policya

tunnel binding destination 3.3.3.9 te Tunnel3/0/0

#
tunnel-policy policyb
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
mpls te
#
undo shutdown
ip address 10.10.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.10.1.0 0.0.0.255
network 10.11.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
mpls-te enable
#
static-cr-lsp transit VPN-A_EF-1to2 incoming-interface gigabitethernet1/0/0
in-label 100 nexthop 10.11.1.2 out-label 100 bandwidth ct0 100000
static-cr-lsp transit VPN-B_BE-1to2 incoming-interface gigabitethernet1/0/0
#
return

#
sysname PE2
#
ipv4-family
tnl-policy policya
#

ipv4-family
tnl-policy policyb
#
mpls lsr-id 3.3.3.9
mpls
mpls te
#
map ct 0 to ef pq
map ct 1 to be lpq
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
#
undo shutdown
ip address 10.11.1.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
destination 1.1.1.9
mpls te commit
#
destination 1.1.1.9
mpls te commit
#
bgp 100
#
ipv4-family unicast

peer 1.1.1.9 enable

#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.11.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
mpls-te enable
#
label 100
label 200
#
#
#
return
l CE1 configuration file

#
sysname CE1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
peer 10.1.1.2 enable
#
return
l Configuration file of CE2

#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#

ipv4-family unicast
import-route direct
#
return

#
sysname CE3
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE4
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
#
bgp 65440
#
ipv4-family unicast
import-route direct
#
return
3.30.17 Example for Configuring a DS-TE Tunnel in IETF Mode

(RDM)
This section provides an example for configuring a DS-TE tunnel in IETF mode.
As shown in Figure 3-19, PEs and P on the MPLS backbone network are enabled with OSPF
to communicate with each other. The P, however, does not support MPLS LDP. PE1 accesses
VPN-A and PE2 accesses VPN-B. An LDP LSP needs to be set up along the path PE3 --> PE1
--> P --> PE2 --> PE4. As shown in Figure 3-19, VPN-A transmits EF and AF traffic; VPN-B
transmits EF, AF, and BE traffic; the LDP LSP transmits BE traffic. The QoS requirements of
different types of traffic are as follows:
EF traffic on VPN-A 100 Mbit/s Shorter than 50 ms

AF traffic on VPN-A 50 Mbit/s Shorter than 200 ms
EF traffic on VPN-B 100 Mbit/s Shorter than 50 ms
AF traffic on VPN-B 50 Mbit/s Shorter than 200 ms
BE traffic on VPN-B 50 Mbit/s None
BE traffic on the LDP LSP 50 Mbit/s None
The networking requires that a DS-TE tunnel be set up between PE1 and PE2 to transmit the
preceding traffic and meet different QoS requirements of different traffic types. The bandwidth
constraints model is RDM. CTi can preempt the bandwidth of CTj (0 <= i < j <= 7). This means
that bandwidths will first be allocated for CTs with higher priorities.
Figure 3-19 Networking diagram for a DS-TE tunnel in IETF mode
AS 65410 AS 65430
VPN-A VPN-A
CE1 CE3
GE1/0/0 GE1/0/0
10.1.1.1/24 10.3.1.1/24
MPLS backbone AS 100

Loopback 1 Loopback 1 Loopback 1
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE1/0/0 GE1/0/0
10.1.1.2/24 GE3/0/0 10.3.1.2/24
GE3/0/0
Loopback 1 PE1 10.10.1.1/24 10.11.1.2/24 Loopback 1
PE2
4.4.4.9/32 5.5.5.9/32
GE4/0/0 GE1/0/0 GE2/0/0 GE4/0/0
10.5.1.1/24 10.10.1.2/24 P 10.11.1.1/24 10.6.1.1/24
PE3 GE2/0/0 GE2/0/0 PE4
10.2.1.2/24 10.4.1.2/24 GE1/0/0
GE1/0/0
10.6.1.2/24
10.5.1.2/24
GE1/0/0 GE1/0/0
10.2.1.1/24 10.4.1.1/24
CE2 CE4
VPN-B VPN-B
AS 65420 AS 65440

NOTE
l In this example, the bandwidth and delay time are guaranteed for all service traffic of each VPN in DS-
TE tunnels.
l If guarantee the bandwidth and delay time for all service traffic only in DS-TE tunnels irrespective of
VPNs, you can set up only one DS-TE tunnel to transmit all the traffic.
l You can limit the service traffic of different VPNs in DS-TE tunnels by limiting the ingress PE to
access VPNs and the service traffic of VPNs.
1. Set up two TE tunnels to transmit EF and AF traffic of VPN-A and VPN-B.

2. Set up different tunnels for VPN-B and the LDP LSP when VPN-B and LDP LSP have
same traffic.
3. Set up one TE tunnel when VPN-A and the LDP LSP have three types of traffic.
4. Set up two RSVP-TE tunnels on tunnel 3/0/0 and tunnel 3/0/1. Each tunnel is configured
with three CTs with the priority being 0, that is, CT0, CT1, and CT2. CT0, CT1, and CT2
bear EF, AF, and BE traffic respectively.
5. CT2 and CT1 of tunnel 3/0/0 transmit EF and AF traffic of VPN-A. CT0 of tunnel 3/0/0
transmits BE traffic of the LDP LSP. CT2, CT1, and CT0 of tunnel 3/0/1 transmit EF, AF,
and BE traffic of VPN-B.
6. Paths of the two tunnels are the same. The BCi bandwidth should be equal to or greater
than the total bandwidth of CTi to CT7 of all the TE tunnels. In addition, the maximum
reservable bandwidth for links should be equal to or greater than the bandwidth of BC0.
Therefore, the bandwidth relationships between BCi and CT1 to CT7 is as follows:
Bandwidth of BC2 on the link => Bandwidth of CT2 of Tunnel 3/0/0 and Tunnel 3/0/1 =
100 Mbit/s
Bandwidth of BC1 => Bandwidth of BC2 + CT1 of Tunnel 3/0/0 and Tunnel 3/0/1 = 200
Mbit/s
Bandwidth of BC0 => Bandwidth of BC1 + Bandwidth of CT0 of Tunnel 3/0/0 + Bandwidth
of CT0 of Tunnel 3/0/1 = 400 Mbit/s
Reservable bandwidth of the link = Bandwidth of BC0 = 400 Mbit/s
7. Services of the same type in two TE tunnels require the same bandwidth and jitter.
Therefore, the CT template is used to configure the TE tunnel.
Data Preparation
To configure a DS-TE tunnel in IETF mode (RDM), you need the following data.
l LSR IDs of PEs and P

l Interface number of the TE tunnel
l TE-class mapping table
l Values of the maximum reservable bandwidth and BC bandwidth of links
l VPN-A instance name, VPN-B instance name, route-distinguisher, VPN target, and name
of the tunnel policy

Procedure
Step 1 Configure IP addresses for interfaces on PEs and the P. Enable OSPF to ensure that PEs and the
P can communicate with each other.
After the configurations, OSPF adjacencies can be created between PE1, P, and PE2. By using
the display ospf peer command, you can view that the status of the adjacency is Full. By using
the display ip routing-table command, you can see that PEs can learn the Loopback1 route
from each other.
Step 2 Configure LSR ID and enable MPLS on each PE and P. Enable MPLS TE and RSVP-TE on
PE1, PE2, and the P. Enable MPLS LDP on all PEs.
# Configure PE3.
<PE3> system-view
[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
# Configure PE1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure the P.
<P> system-view
[P] mpls
[P-mpls] mpls te
[P-mpls] mpls rsvp-te
[P-mpls] quit
[P-GigabitEthernet1/0/0] mpls rsvp-te
[P-GigabitEthernet2/0/0] mpls rsvp-te

# Configure PE2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] mpls te
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls] quit
# Configure PE4.
<PE4> system-view
[PE4] mpls
[PE4-mpls] quit
[PE4] mpls ldp
[PE4-mpls-ldp] quit
After completing the configuration, run the display mpls rsvp-te interface command on PE1,
PE2, or the P to view interfaces enabled with RSVP and information about RSVP. Run the
display mpls ldp lsp command on PE1, PE2, PE3, or PE4. An LDP LSP exists between PE3
and PE1, and between PE2 and PE4.
Step 3 Configure OSPF TE on PE1, PE2, and the P and enable CSPF.
# Configure OSPF TE on PE1, PE2, and the P and enable CSPF on the ingress of the TE tunnel.
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] opaque-capability enable
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] mpls-te enable
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
[PE1] mpls
# Configure P.
[P] ospf 1
[P-ospf-1] opaque-capability enable
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] mpls-te enable
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
# Configure PE2.
[PE2] ospf 1
[PE2-ospf-1] area 0


[PE2-ospf-1] quit
[PE2] mpls
[PE2-mpls] quit
After completing the configuration, run the display ospf mpls-te command to view the TE LSA
information in the OSPF Link State Database (LSDB).
Step 4 Configure the DS-TE mode and the bandwidth constraints model on PE1, PE2, and the P.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls te ds-te mode ietf
[PE1-mpls] mpls te ds-te bcm rdm
[PE1-mpls] quit
# Configure P.
[P] mpls
[P-mpls] mpls te ds-te mode ietf
[P-mpls] mpls te ds-te bcm rdm
[P-mpls] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] mpls te ds-te bcm rdm
[PE2-mpls] quit
After completing the configuration, run the display mpls te ds-te summary command on a PE
or P to view information about DS-TE configuration.

[PE1] display mpls te ds-te summary
DS-TE IETF Supported :YES
DS-TE MODE :IETF
Bandwidth Constraint Model :RDM
TEClass Mapping (default):
TE-Class ID Class Type Priority
TE-Class 0 0 0
TE-Class 1 1 0
TE-Class 2 2 0
TE-Class 3 3 0
TE-Class 4 0 7
TE-Class 5 1 7
TE-Class 6 2 7
TE-Class 7 3 7
Step 5 Configure link bandwidth on the PEs and P.
# Configure PE1.
[PE1-GigabitEthernet3/0/0] mpls te bandwidth bc0 400000 bc1 200000 bc2 100000
# Configure the P.
[P-GigabitEthernet1/0/0] mpls te bandwidth bc0 400000 bc1 200000 bc2 100000

[P-GigabitEthernet2/0/0] mpls te bandwidth bc0 400000 bc1 200000 bc2 100000
# Configure PE2.
[PE2-GigabitEthernet3/0/0] mpls te bandwidth bc0 400000 bc1 200000 bc2 100000
After completing the configuration, run the display mpls te link-administration bandwidth-
allocation interface command on the PE and you can view information about BC bandwidth
allocation for interfaces.

----------------------------------------------------------------------
----------------------------------------------------------------------
0 0 0 0 400000 0
1 1 0 0 200000 0
2 2 0 0 100000 0
3 0 7 0 400000 0
4 1 7 0 200000 0
5 2 7 0 100000 0
6 - - - - -
7 - - - - -
8 - - - - -
9 - - - - -
10 - - - - -
11 - - - - -
12 - - - - -
13 - - - - -
14 - - - - -
15 - - - - -
----------------------------------------------------------------------
Step 6 Configure a TE-class mapping table on each PE.
# Configure PE1.
[PE1] te-class-mapping
[PE1-te-class-mapping] te-class0 class-type ct0 priority 0 description For-EF
[PE1-te-class-mapping] te-class1 class-type ct1 priority 0 description For-AF
[PE1-te-class-mapping] te-class2 class-type ct2 priority 0 description For-BE
[PE1-te-class-mapping] quit

[PE2] te-class-mapping
[PE2-te-class-mapping] te-class0 class-type ct0 priority 0 description For-EF
[PE2-te-class-mapping] te-class1 class-type ct1 priority 0 description For-AF
[PE2-te-class-mapping] te-class2 class-type ct2 priority 0 description For-BE
[PE2-te-class-mapping] quit
After completing the configuration, run the display mpls te ds-te te-class-mapping command
on a PE to view information about the TE-class mapping table.
[PE1] display mpls te ds-te te-class-mapping
TE-Class ID Class Type Priority Description
TE-Class0 0 0 For-EF
TE-Class1 1 0 For-AF
TE-Class2 2 0 For-BE
TE-Class3 - - -
TE-Class4 - - -
TE-Class5 - - -
TE-Class6 - - -
TE-Class7 - - -
Step 7 Configure an explicit path on the PE.

# Configure PE1.
[PE1] explicit-path path1
[PE1-explicit-path-path1] next hop 10.10.1.2
[PE1-explicit-path-path1] quit
# Configure PE2.
[PE2] explicit-path path1
[PE2-explicit-path-path1] quit
After completing the configuration, run the display explicit-path command on a PE to view
information about the explicit path.
[PE1] display explicit-path path1
Path Name : path1 Path Status : Enabled
Step 8 Configure the tunnel interface on the PE.

# Configure PE1.
[PE1-Tunnel3/0/0] description For VPN-A & Non-VPN
[PE1-Tunnel3/0/0] mpls te path explicit-path path1
[PE1-Tunnel3/0/0] mpls te priority 0
[PE1-Tunnel3/0/0] mpls te bandwidth ct0 100000 ct1 50000 ct2 50000


[PE1-Tunnel3/0/1] description For VPN-B
# Configure PE2.
[PE2-Tunnel3/0/0] description For VPN-A & Non-VPN
[PE2-Tunnel3/0/1] description For VPN-B
Run the display interface tunnel interface-number command on a PE. The tunnel interface goes
Up.
The following example uses the command output on tunnel 3/0/0 of PE1.
[PE1] display interface tunnel3/0/0
Last up time: 2008-05-23, 11:15:01
Description :For VPN-A & Non-VPN
primary tunnel id is 0x8201002c, secondary tunnel id is 0x0
...
Run the display mpls te te-class-tunnel command on a PE to view the TE tunnel associated
with the TE-class.

[PE1] display mpls te te-class-tunnel all
------------------------------------------------------------------------
No. CT priority status tunnel name tunnel commit
------------------------------------------------------------------------
1 CT0 0 Valid Tunnel3/0/0 Yes


Step 9 Bind the outbound interface with a DS domain on a PE.
# Configure PE1.
# Configure P.
# Configure PE2.
After completing the configuration, run the display diffserv domain default command on a PE
to view information about the default traffic policy for traffic classification in a DS domain.

[PE1] display diffserv domain default
Diffserv domain name:default
...
mpls-exp-inbound 0 phb be green
mpls-exp-inbound 5 phb ef green
mpls-exp-outbound be green map 0


mpls-exp-outbound ef green map 5
...
NOTE
Take note of the preceding items that appear in the display diffserv domain default command output.
Step 10 Configure the mapping of the CT and service type on the PEs and P.
# Bind the outbound interface of services with the DS domain on PEs for simple traffic
classification.
# Configure PE1.
[PE1-ct-flow-mapping-mapping1] map ct 1 to af1 wfq
# Configure PE2.
[PE2-ct-flow-mapping-mapping1] map ct 1 to af1 wfq
# After completing the configuration, run the display ct-flow-mapping command on PEs to
view the mapping relationship of CTs and traffic queues.

[PE1] display ct-flow-mapping all
Totle template: 2
template-name:default
map CT 0 to be lpq
map CT 1 to af1 wfq
map CT 2 to af2 wfq
map CT 3 to af3 wfq
map CT 4 to af4 wfq
map CT 5 to ef pq
map CT 6 to cs6 pq
map CT 7 to cs6 pq
template-name:mapping1
map CT 0 to ef pq

map CT 1 to af1 wfq

map CT 2 to be lpq
Step 11 Configure port queue.
# Configure PE1.
[PE1-GigabitEthernet3/0/0] port-queue ef pq shaping 220000 outbound
[PE1-GigabitEthernet3/0/0] port-queue af1 wfq weight 15 shaping 120000 outbound
[PE1-GigabitEthernet3/0/0] port-queue be lpq shaping 150000 outbound
# Configure PE2.
[PE2-GigabitEthernet3/0/0] port-queue ef pq shaping 220000 outbound
[PE2-GigabitEthernet3/0/0] port-queue af1 wfq weight 15 shaping 120000 outbound
[PE2-GigabitEthernet3/0/0] port-queue be lpq shaping 150000 outbound
Step 12 Configure LDP over TE.
# Configure the forwarding adjacency on the TE tunnel and create the MPLS LDP peer
relationship between both ends on the TE tunnel.
# Configure PE1.
[PE1-Tunnel3/0/0] mpls te igp advertise
[PE1-Tunnel3/0/0] mpls te igp metric absolute 1
[PE1-Tunnel3/0/0] mpls
[PE1] ospf 1
[PE1-ospf-1] enable traffic-adjustment advertise
[PE1-ospf-1] quit
[PE1-] mpls ldp remote-peer pe1tope2
[PE1-mpls-ldp-remote-pe1tope2] remote-ip 3.3.3.9
# Configure PE2.
[PE2-Tunnel3/0/0] mpls te igp advertise
[PE2-Tunnel3/0/0] mpls te igp metric absolute 1
[PE2-Tunnel3/0/0] mpls
[PE2] ospf 1
[PE2-ospf-1] enable traffic-adjustment advertise
[PE2-ospf-1] quit
[PE2-] mpls ldp remote-peer pe2tope1
[PE2-mpls-ldp-remote-pe2tope1] remote-ip 1.1.1.9
After completing the configuration, run the display ip routing-table command on PE1 or PE2
to view route information. The outbound interface destined for 5.5.5.9 is tunnel 3/0/0 on PE1
and the outbound interface destined for 4.4.4.9 is tunnel 3/0/0 on PE2.
Step 13 Create the MP-IBGP remote peer relationship between PEs, and create the EBGP peer
relationship between PEs and CEs.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] peer 3.3.3.9 as-number 100
[PE1-bgp] peer 3.3.3.9 connect-interface loopback 1

[PE1-bgp] ipv4-family vpnv4

[PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[PE1-bgp-vpna] import-route direct
[PE1-bgp-vpna] quit
[PE1-bgp] ipv4-family vpn-instance vpnb
[PE1-bgp-vpnb] peer 10.2.1.1 as-number 65420
[PE1-bgp-vpnb] import-route direct
[PE1-bgp-vpnb] quit
NOTE
Repeat this step for PE2. For configuration details, see Configuration Files in this section.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] peer 10.1.1.2 as-number 100
[CE1-bgp] import-route direct
NOTE
Repeat this step for CE2, CE3, and CE4. For configuration details, see Configuration Files in this section.
After completing the configuration, run the display bgp vpnv4 all peer command on the PE.
The BGP peer relationship is created between PEs and its status is Established.
[PE1] display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 3 Peers in established state : 3
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
3.3.3.9 4 100 12 18 0 00:09:38 Established 0

Peer of vpn instance:
VPN-Instance vpna, Router ID 1.1.1.9:
10.1.1.1 4 65410 25 25 0 00:17:57 Established 1
VPN-Instance vpnb, Router ID 1.1.1.9:
10.2.1.1 4 65420 21 22 0 00:17:10 Established 1
Step 14 Configure the tunnel policy on PEs.
# Configure PE1.
# Configure PE2.
Step 15 Configure VPN instances on PEs and connect CEs to PEs.
# Configure PE1.


# Configure PE2.
# Configure IP addresses for interfaces of CEs. The configuration details are not provided here.
After completing the configuration, run the display ipvpn-instance verbose command on the
PE to view the configuration of VPN instances. PEs can ping CEs connecting to PEs.
After the configuration, connect the tester to PE3, PE4, and all CEs and inject the following
traffic to the connected interfaces.
Traffic Type Bandwidth
Between CE1 and CE2 EF 100 Mbit/s
AF 50 Mbit/s

Traffic Type Bandwidth
Between CE3 and CE4 EF 100 Mbit/s
AF 50 Mbit/s
BE 50 Mbit/s
Between PE3 and PE4 BE 50 Mbit/s
You can see that all packets are not discarded. The jitter of EF traffic is shorter than 50 ms, and
the jitter of AF traffic is shorter than 200 ms.
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy policya
#
ipv4-family
tnl-policy policyb
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls te ds-te mode ietf
mpls rsvp-te
#
mpls ldp
#
mpls ldp remote-peer pe1tope2
remote-ip 3.3.3.9
#
explicit-path path1
next hop 10.10.1.2
next hop 10.11.1.2
next hop 3.3.3.9
#
map ct 0 to be lpq
map ct 1 to af1 wfq
map ct 2 to ef pq
#
te-class-mapping
te-class0 class-type ct0 priority 0 description For-BE
te-class1 class-type ct1 priority 0 description For-AF
te-class2 class-type ct2 priority 0 description For-EF

#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.10.1.1 255.255.255.0
mpls
mpls te
mpls te bandwidth bc0 400000 bc1 300000 bc2 200000
mpls rsvp-te
port-queue ef pq shaping 220000 outbound
port-queue af1 wfq weight 15 shaping 120000 outbound
port-queue be lpq shaping 150000 outbound
#
undo shutdown
ip address 10.5.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
description For VPN-A & Non-VPN
destination 3.3.3.9
mpls te priority 0
mpls te bandwidth ct0 50000 ct1 50000 ct2 100000
mpls te path explicit-path path1
mpls te commit
mpls
#
description For VPN-B
destination 3.3.3.9
mpls te priority 0
mpls te commit
#
bgp 100
#
ipv4-family unicast

peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
enable traffic-adjustment advertise
area 0.0.0.0
network 10.10.1.0 0.0.0.255
network 10.5.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
mpls-te enable
#
#
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.10.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0

network 10.10.1.0 0.0.0.255
network 10.11.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
mpls-te enable
#
return

#
sysname PE2
#
ipv4-family
tnl-policy policya
#
ipv4-family
tnl-policy policyb
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls te rsvp-te
#
mpls ldp
#
mpls ldp remote-peer pe2tope1
remote-ip 1.1.1.9
#
explicit-path path1
next hop 10.10.1.1
next hop 10.11.1.1
next hop 1.1.1.9
#
map ct 0 to ef pq
map ct 1 to af1 wfq
map ct 2 to be lpq
#
te-class-mapping
te-class0 class-type ct0 priority 0 description For-EF
te-class1 class-type ct1 priority 0 description For-AF
te-class2 class-type ct2 priority 0 description For-BE
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
#
undo shutdown

ip address 10.11.1.2 255.255.255.0

mpls
mpls te
mpls rsvp-te
port-queue ef pq shaping 220000 outbound
port-queue af1 wfq weight 15 shaping 120000 outbound
port-queue be lpq shaping 150000 outbound
#
undo shutdown
ip address 10.6.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
description For VPN-A & Non-VPN
destination 1.1.1.9
mpls te priority 0
mpls te commit
#
description For VPN-B
destination 1.1.1.9
mpls te priority 0
mpls te commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
enable traffic-adjustment advertise

area 0.0.0.0
network 10.11.1.0 0.0.0.255
network 10.6.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
mpls-te enable
#
#
#
return

#
sysname PE3
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
undo shutdown
ip address 10.5.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.5.1.0 0.0.0.255
network 4.4.4.9 0.0.0.0
#
return

#
sysname PE4
#
mpls lsr-id 5.5.5.9
mpls
#
mpls ldp
#
undo shutdown
ip address 10.6.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.6.1.0 0.0.0.255
network 5.5.5.9 0.0.0.0
#
return

#
sysname CE1
#

undo shutdown
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE3
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE4
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
#
bgp 65440
#
ipv4-family unicast
import-route direct
#
return

3.30.18 Example for Switching the Non-IETF Mode to the IETF

Mode
This section provides an example for switching the non-IETF mode to the IETF mode.
On the network shown in the following figure, two static DS-TE tunnels between PE1 and PE2
are set up in non-IETF mode for transmitting EF traffic of VPN-A and BE traffic of VPN-B.
The DS-TE tunnel set up in non-IETF mode supports only the single CT, namely, CT0 or CT1.
In the case of network expansion, it is required that the non-IETF mode be switched to the IETF
mode supporting eight CTs.
Figure 3-20 Networking diagram for switching the non-IETF mode to the IETF mode
AS: 65410 AS: 65430

VPN-A VPN-A
CE1 CE3
GE1/0/0 GE1/0/0
10.1.1.1/24 10.3.1.1/24
Loopback1
GE1/0/0 2.2.2.9/32 GE1/0/0
10.1.1.2/24 PE1 GE1/0/0 GE2/0/0 PE2 10.3.1.2/24
1.1.1.9/32 GE3/0/0 GE3/0/0 3.3.3.9/32
GE2/0/0 10.10.1.1/24 P 10.11.1.2/24 GE2/0/0
10.2.1.2/24 10.4.1.2/24
MPLS backbone
AS: 100
GE1/0/0 GE1/0/0
10.2.1.1/24 10.4.1.1/24
CE2 CE4
VPN-B VPN-B
AS: 65420 AS: 65440

NOTE
l In this example, the bandwidth and delay time are guaranteed for all service traffic of each VPN in DS-
TE tunnels.
l If guarantee the bandwidth and delay time for all service traffic only in DS-TE tunnels irrespective of
VPNs, you can set up only one DS-TE tunnel to transmit all the traffic.
l You can limit the service traffic of different VPNs in DS-TE tunnels by limiting the ingress PE to
access VPNs and the service traffic of VPNs.
1. When the non-IETF mode is switched to the IETF mode, the system automatically deletes
the CR-LSPs whose combination of <CT, set-priority> or combination of <CT, hold-
priority> does not exist in the TE-class mapping table. If the TE-class mapping table is
improperly configured, the CR-LSP that transmits traffic may be deleted incorrectly,
resulting in service interruption. Therefore, before switching the DS-TE mode, check the
CTs, setup priority, and holding priority of the ingress and transit CR-LSPs, and the
configuration of TE-class mapping table.
2. For certain CR-LSPs, if the combination of the CT and setup priority or the combination
of the CT and holding priority does not exist in the TE-class mapping table, configure or
modify the TE-class mapping table.
3. Switch the DS-TE mode.
4. Configure related DS-TE items or related services.
Data Preparation
None
Procedure
Step 1 Run the display current-configuration | include static-cr-lsp ingress and display current-
configuration | include static-cr-lsp transit commands on PE1, P, and PE2 to view the CTs of
the static ingress and transit CR-LSPs, and the TE-class mapping table.
NOTE
l For static CR-LSPs, both the setup priority and the holding priority are 0 and the two priorities need
not to be checked.
l For RSVP CR-LSPs, run the display current-configuration interface tunnel command to view the
configured mpls te bandwidth and mpls te priority commands, CTs, setup priority, and holding
priority on each tunnel interface.
# Run the display current-configuration | include static-cr-lsp ingress and display current-
configuration | include static-cr-lsp transit commands on the PE and P to view CTs, setup and
holding priorities of the static ingress and transit CR-LSPs. Then, run the display mpls te ds-
te te-class-mapping config command to view the configuration of the TE-class mapping table.
# In the following example, the display on PE1 is used. Repeat this step for other nodes. For
<PE1> display current-configuration | include static-cr-lsp ingress
static-cr-lsp ingress tunnel-interface Tunnel 3/0/0 destination 3.3.3.9 nexthop
static-cr-lsp ingress tunnel-interface tunnel 3/0/1 destination 3.3.3.9 nexthop
<PE1> display current-configuration | include static-cr-lsp transit
<PE1> display mpls te ds-te te-class-mapping config Info: Configure TE-Class first.

NOTE
The display current-configuration | include static-cr-lsp transit command output is null, indicating that
no static transit CR-LSP is set up on PE1.
The display mpls te ds-te te-class-mapping config command output shows "Info: Configure TE-Class
first.", indicating that no TE-class mapping table is configured on PE1.
# The command output indicates that the static CR-LSPs of CT0 and CT1 are set up on PE1. In
addition, because the setup and holding priorities of the static CR-LSPs are 0, the following TE-
classes must exist in the TE-class mapping table:
l <CT = CT0, Priority = 0>
l <CT = CT1, Priority = 0>
Step 2 Configure TE-classes on PE1, P, and PE2.
In this example, the TE-classes of <CT = CT0, Priority = 0> and <CT = CT1, Priority = 0> need
to be configured. Because the two TE-classes already exist in the default TE-class mapping table,
no other TE-class mapping table needs to be configured in this example. After the non-IETF
mode is switched to the IETF mode, the system uses the default TE-class mapping table.
NOTE
For information about the default TE-class mapping table, see Table 3-3.
Step 3 Switch the DS-TE modes on PE1, P, and PE2.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
# Configure P.
[P] mpls
[P-mpls] mpls te ds-te mode ietf
[P-mpls] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
NOTE
After the non-IETF mode is switched to the IETF mode, the bandwidth constraints model remains
unchanged and does not need to be configured again.
In addition, related configurations of DS-TE and services accesses are required according to the service.
The configurations are not provided in this example.
----End
Configuration Files
#
sysname PE1
#
ipv4-family

tnl-policy policya
#
ipv4-family
tnl-policy policyb
#
mpls lsr-id 1.1.1.9
mpls
#
map ct 0 to ef pq
map ct 1 to be lpq
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
#
undo shutdown
ip address 10.10.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
destination 3.3.3.9
mpls te commit
#
destination 3.3.3.9
mpls te commit
#
bgp 100


#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.10.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
mpls-te enable
#
static-cr-lsp ingress tunnel-interface Tunnel 3/0/0 destination 3.3.3.9
label 101
label 201
#
#
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
mpls te
#
undo shutdown
ip address 10.10.1.2 255.255.255.0
mpls
mpls te
#
undo shutdown
ip address 10.11.1.1 255.255.255.0
mpls
mpls te


#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.10.1.0 0.0.0.255
network 10.11.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
mpls-te enable
#
#
return

#
sysname PE2
#
ipv4-family
tnl-policy policya
#
ipv4-family
tnl-policy policyb
#
mpls lsr-id 3.3.3.9
mpls
mpls te
#
map ct 0 to ef pq
map ct 1 to be lpq
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
#

undo shutdown
ip address 10.11.1.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
destination 1.1.1.9
mpls te commit
#
destination 1.1.1.9
mpls te commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.11.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
mpls-te enable
#
label 100
label 200
#

#
#
return
3.30.19 Example for Configuring MPLS TE FRR

This section provides an example for configuring MPLS TE FRR to implemen link protection.
On the network shown in Figure 3-21, the primary LSP is along the path LSRA --> LSRB -->
LSRC --> LSRD, and the link from LSRB to LSRC requires FRR link protection.
A bypass LSP is set up over the path LSRB --> LSRE --> LSRC. LSRB is a PLR, and LSRC is
an MP.
An explicit path is used to protect traffic on the MPLS TE primary and the bypass tunnels. The
RSVP-TE signaling protocol is used.
Figure 3-21 Networking diagram for MPLS TE FRR configuration

Loopback1
4.4.4.4/32
LSRD
GE1/0/0
4.1.1.2/24
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32 Loopback1
3.3.3.3/32 GE1/0/0
LSRA LSRB 4.1.1.1/24
GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0 LSRC

2.1.1.1/24 2.1.1.2/24 3.1.1.1/24 3.1.1.2/24 POS3/0/0
POS3/0/0 Loopback1 3.3.1.2/24
3.2.1.1/24 5.5.5.5/32
Primary LSP POS1/0/0 POS2/0/0
Bypass LSP 3.2.1.2/24 3.3.1.1/24
LSRE

1. Establish the primary tunnel and enable TE FRR in the tunnel interface view.
2. Configure the bypass tunnel on the PLR (LSRB) and specify the protectable bandwidth
and the interface to be protected.
Data Preparation
l IS-IS area ID on each LSR, original system ID, and IS-IS level
l Maximum reservable bandwidth and BC bandwidth for the link along the tunnel
l Explicit paths of the primary and the bypass tunnels
l Interface names, IP addresses, destination addresses, tunnel IDs, tunnel signaling protocol
(RSVP-TE) of the primary and bypass tunnels
l Bandwidth that the bypass tunnel can protect and the protected link interface
Procedure
Assign an IP address and mask to each interface, including the loopback interface, according to
The IS-IS protocol is configured on all LSRs to advertise routes of LSR IDs. For configuration
The command output shows that the LSRs learned routes from one another.
Step 3 Configure the basic MPLS functions and enable MPLS TE, CSPF, RSVP-TE, and IS-IS TE.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
[LSRA] isis
NOTE
in this section.
CSPF is enabled only on LSRA and LSRB.
Step 4 Configure the MPLS TE attributes for links.

# Set the maximum reservable link bandwidth to 100 Mbit/s and BC bandwidth to 100 Mbit/s
on LSRA, LSRB, LSRC, LSRD, and LSRE.

# Configure LSRA.
# Configure LSRB.
[LSRB-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRB-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000
# Configure LSRC.
# Configure LSRE.
[LSRE-Pos2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRE-Pos2/0/0] mpls te bandwidth bc0 100000
Step 5 Establish an MPLS TE tunnel as the primary LSP on LSRA.

# Configure the explicit path for the primary LSP.
[LSRA] explicit-path pri-path
[LSRA-explicit-path-pri-path] next hop 2.1.1.2
[LSRA-explicit-path-pri-path] quit
# Configure the MPLS TE tunnel as the primary LSP.

[LSRA-Tunnel1/0/0] mpls te path explicit-path pri-path
# Enable FRR.
[LSRA-Tunnel1/0/0] mpls te fast-reroute
status of Tunnel 1/0/0 is Up.
[LSRA] display interface tunnel 1/0/0
Last up time: 2009-01-12, 09:35:10

...
Run the display mpls te tunnel verbose command on LSRA to view information about the
tunnel interface.
[LSRA] display mpls te tunnel verbose
No : 1
LSR Role : Ingress Lsp Type : Primary
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 1081
Created Time : 2010/07/01 15:02:57 UTC-08:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
Step 6 Configure the bypass tunnel on LSRB that functions as PLR.
# Configure the explicit path of the bypass LSP.

[LSRB] explicit-path by-path
[LSRB-explicit-path-by-path] next hop 3.2.1.2


[LSRB-explicit-path-by-path] quit
# Configure the bypass tunnel.

[LSRB] interface tunnel 3/0/0
[LSRB-Tunnel3/0/0] ip address unnumbered interface loopback 1
[LSRB-Tunnel3/0/0] tunnel-protocol mpls te
[LSRB-Tunnel3/0/0] destination 3.3.3.3
[LSRB-Tunnel3/0/0] mpls te tunnel-id 300
[LSRB-Tunnel3/0/0] mpls te signal-protocol rsvp-te
[LSRB-Tunnel3/0/0] mpls te path explicit-path by-path
[LSRB-Tunnel3/0/0] mpls te bandwidth ct0 100000
# Configure bandwidth that can be protected by the bypass tunnel.

[LSRB-Tunnel3/0/0] mpls te bypass-tunnel
# Bind the bypass tunnel to the protected interface.

[LSRB-Tunnel3/0/0] mpls te protected-interface gigabitethernet 2/0/0
[LSRB-Tunnel3/0/0] mpls te commit
[LSRB-Tunnel3/0/0] quit
After completing the configuration, run the display interface tunnel command on LSRB. The
command output shows that the status of the Tunnel 3/0/0 interface is Up.
Run the display mpls lsp command on all LSRs to check LSP entries. The command output
shows that LSPs pass through LSRB and LSRC.
------------------------------------------------------------------
------------------------------------------------------------------
4.4.4.4/32 NULL/1024 -/GE1/0/0
------------------------------------------------------------------
------------------------------------------------------------------
4.4.4.4/32 1024/1024 GE1/0/0/GE2/0/0
3.3.3.3/32 NULL/1024 -/Pos3/0/0
[LSRC] display mpls lsp
------------------------------------------------------------------
------------------------------------------------------------------
4.4.4.4/32 1024/3 GE2/0/0/GE1/0/0
3.3.3.3/32 3/NULL Pos3/0/0/-
------------------------------------------------------------------
------------------------------------------------------------------
4.4.4.4/32 3/NULL GE1/0/0/-
[LSRE] display mpls lsp
------------------------------------------------------------------
------------------------------------------------------------------
3.3.3.3/32 1024/3 Pos1/0/0/Pos2/0/0
Run the display mpls te tunnel command on all the LSRs to check the establishment status of
the tunnel. The command output shows that two tunnels pass through LSRB and LSRC.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 4.4.4.4 1 --/3 I Tunnel1/0/0
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 4.4.4.4 1 1026/3 T Tunnel1/0/0
2.2.2.2 3.3.3.3 1 --/3 I Tunnel3/0/0
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 4.4.4.4 1 1024/3 T Tunnel1/0/0
2.2.2.2 3.3.3.3 1 3/-- E Tunnel3/0/0
[LSRE] display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.2 3.3.3.3 1 1025/3 T Tunnel3/0/0
Run the display mpls te tunnel name Tunnel1/0/0 verbose command on LSRB. The command
output shows that the bypass tunnel is bound to GE 2/0/0 and remains unused.
[LSRB] display mpls te tunnel name Tunnel1/0/0 verbose
No : 1
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 65546
Created Time : 2009/01/12 09:42:04
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info


Bypass LSP ID : 9 FrrNextHop : 3.2.1.2
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# Shut down the protected outgoing interface on the PLR.

[LSRB-GigabitEthernet2/0/0] shutdown
%Oct 20 17:21:19 2005 LSRB IFNET/5/UPDOWN:Line protocol on the interface
GigabitEthernet2/0/0 turns into DOWN state
Run the display interface tunnel 1/0/0 command on LSRA to view the status of the primary
LSP. The status of the tunnel interface is still Up.
Run the tracert lsp te tunnel 1/0/0 command on LSRA to view the path over which the tunnel
is established.
[LSRA] tracert lsp te tunnel 1/0/0
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1/0/0 , press CTRL_C to
break.
0 Ingress 2.1.1.2/[13312 ]
1 2.1.1.2 1 ms Transit
2 3.2.1.2 16 ms Transit
3 3.3.1.2 1 ms Transit
4 4.1.1.2 1 ms Egress
The preceding information shows that the link is already switched to the bypass tunnel.
NOTE
After FRR switching, run the display mpls te tunnel-interface command immediately. Two CR-LSPs are
in the Up state because FRR establishes a new LSP using make-before-break. The previous LSP is torn
down only after the new LSP has been established successfully.
Run the display mpls te tunnel name Tunnel1/0/0 verbose command on LSRB. The command
output shows that the bypass tunnel is used.
[LSRB] display mpls te tunnel name Tunnel1/0/0 verbose
No : 1
LSR Role : Transit

IncludeAllAff : 0x0
PSB Handle : 66000
Created Time : 2009/01/12 10:09:10
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
Bypass In Use : In Use
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# Set the scanning timer of FRR on PLR to 5 seconds.

[LSRB] mpls
[LSRB-mpls] mpls te timer fast-reroute 5
[LSRB-mpls] quit
# Re-enable the protected interface on PLR.

[LSRB-GigabitEthernet2/0/0] undo shutdown
Run the display interface tunnel 1/0/0 command to view the status of the primary LSP on
LSRA. The tunnel interface is in Up state.
After a while, run the display mpls te tunnel name Tunnel1/0/0 verbose command on LSRB.
The command output shows that Tunnel 3/0/0 is bound to GE 2/0/0 and is unused.
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path pri-path
next hop 2.1.1.2
next hop 3.1.1.2
next hop 4.1.1.2
next hop 4.4.4.4
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
ip address 2.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 4.4.4.4
mpls te record-route label
mpls te path explicit-path pri-path
mpls te commit
#
return

#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls te timer fast-reroute 5
mpls rsvp-te
mpls te cspf
#
explicit-path by-path
next hop 3.2.1.2
next hop 3.3.1.2
next hop 3.3.3.3
#
isis 1
is-level level-2
cost-style wide

network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
ip address 2.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 3.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
link-protocol ppp
ip address 3.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
destination 3.3.3.3
mpls te path explicit-path by-path
mpls te protected-interface GigabitEthernet 2/0/0
mpls te commit
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
ip address 4.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te


mpls rsvp-te
#
ip address 3.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
link-protocol ppp
ip address 3.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
ip address 4.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return

#
sysname LSRE
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0005.00
traffic-eng level-2

#
interface Pos1/0/0
link-protocol ppp
clock master
ip address 3.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
clock master
ip address 3.3.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
3.30.20 Example for Configuring MPLS TE Auto FRR

This section provides an example for establishing a bypass tunnel for node protection on the
ingress and a bypass tunnel for link protection on a transit node and providing bandwidth
protection for the primary tunnel.
On the network shown in Figure 3-22, a primary tunnel is set up over the explicit path LSRA
--> LSRB --> LSRC. A bypass tunnel is set up on the headend LSRA for node protection, and
a bypass tunnel is set up on the transit LSRB for link protection, and both of them provide
bandwidth protection.
Figure 3-22 Networking diagram for MPLS TE Auto FRR

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE3/0/0 GE2/0/0 GE3/0/0

LSRA LSRC
2.1.1.2/24 3.1.1.1/24 3.1.1.2/24
GE1/0/0 GE2/0/0 LSRB GE1/0/0
10.1.1.2/24 2.1.1.1/24 GE1/0/0 10.1.1.1/24
Loopback1 GE2/0/0
3.2.1.1/24 4.4.4.4/32 4.1.1.2/24
GE3/0/0 GE2/0/0
3.2.1.2/24 4.1.1.1/24
LSRD

1. Establish a primary tunnel, enable TE FRR in the tunnel interface view, and enable TE
Auto FRR in the MPLS view.
Data Preparation
l OSPF process ID and OSPF area ID of each LSR

l Maximum reservable bandwidth and BC bandwidth of the link
l Explicit path through which the primary tunnel passes
l Name of the primary tunnel interface, IP address, destination address, tunnel ID, tunnel
signaling protocol (RSVP-TE), and tunnel bandwidth
Procedure
Assign an IP address and mask to each interface, including Loopback interfaces, according to
Step 2 Configure OSPF on all LSRs to advertise the routes of each network segment and the host route
of each LSR ID.
Configure OSPF on all LSRs to advertise the host route of each LSR ID. For configuration
The command output shows that the LSRs have learned the host routes of LSR IDs from each
other.
Step 3 Configure the basic MPLS functions and enable MPLS TE, RSVP-TE, and CSPF.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
NOTE
Repeat this step for LSRB, LSRC, and LSRD. For configuration details, see Configuration Files in this
section.

Step 4 Configure OSPF TE.

# Configure LSRA.
[LSRA] ospf
[LSRA-ospf-1] quit
# Configure LSRB.
[LSRB] ospf
[LSRB-ospf-1-area-0.0.0.0] mpls-te enable
[LSRB-ospf-1] quit
# Configure LSRC.
[LSRC] ospf
[LSRC-ospf-1-area-0.0.0.0] mpls-te enable
[LSRC-ospf-1] quit
# Configure LSRD.
[LSRD] ospf
[LSRD-ospf-1] opaque-capability enable
[LSRD-ospf-1] area 0
[LSRD-ospf-1-area-0.0.0.0] mpls-te enable
[LSRD-ospf-1-area-0.0.0.0] quit
[LSRD-ospf-1] quit
Step 5 Configure the MPLS TE link bandwidth.

Set the maximum reservable bandwidth for the link to 10 Mbit/s, the BC0 bandwidth to 10 Mbit/
s and the BC1 bandwidth to 3 Mbit/s.
# Configure LSRA.
[LSRA-GigabitEthernet2/0/0] mpls te bandwidth bc0 10000 bc1 3000
The outbound interfaces on the link through which the primary have similar configurations. For
Step 6 Configure the explicit path for the primary tunnel.
[LSRA] explicit-path master
[LSRA-explicit-path-master] next hop 2.1.1.2
Step 7 Enable TE Auto FRR.

# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te auto-frr
# Configure LSRB.
[LSRB] mpls

[LSRB-mpls] mpls te auto-frr
Step 8 Configure the primary tunnel.

[LSRA-Tunnel2/0/0] ip address unnumbered interface loopBack1
[LSRA-Tunnel2/0/0] mpls te record-route label
[LSRA-Tunnel2/0/0] mpls te path explicit-path master
[LSRA-Tunnel2/0/0] mpls te priority 4 3
[LSRA-Tunnel2/0/0] mpls te fast-reroute bandwidth
[LSRA-Tunnel2/0/0] mpls te bypass-attributes bandwidth 200 priority 5 4

Run the display mpls te tunnel name Tunnel2/0/0 verbose command on the ingress LSRA to
view information about the primary tunnel and the auto bypass tunnel.
[LSRA] display mpls te tunnel name Tunnel2/0/0 verbose
No : 1

In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 65546
Created Time : 2009/03/30 09:52:03
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info

IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
The command output shows that the primary tunnel is bound to the Auto bypass tunnel, that is,
Tunnel 0/0/2048.
Run the display mpls te tunnel path command on LSRA. You can view information about the
primary tunnel and the Auto bypass tunnel, and node and bandwidth protection provided for the
outbound interface of the primary tunnel.
[LSRA] display mpls te tunnel path
Lsp ID : 1.1.1.1 :200:1
Hop Information
Hop 1 2.1.1.2 Label 106497
Hop 2 2.2.2.2
Hop 4 3.1.1.2 Label 3
Hop 5 3.3.3.3
Lsp ID : 1.1.1.1 :2049:3
Hop Information
Hop 0 10.1.1.2
Hop 1 10.1.1.1
Hop 2 3.3.3.3
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
#
explicit-path master
next hop 2.1.1.2
next hop 3.1.1.2
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 2.1.1.1 255.255.255.0
mpls
mpls te


mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 3.3.3.3
mpls te path explicit-path master
mpls te priority 4 3
mpls te fast-reroute bandwidth
mpls te bypass-attributes bandwidth 200 priority 5 4
mpls te commit
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 2.1.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
mpls-te enable
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
#
ip address 3.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 3.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1

area 0.0.0.0
network 3.1.1.0 0.0.0.255
network 3.2.1.0 0.0.0.255
network 2.1.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
mpls-te enable
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 4.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 3.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 3.1.1.0 0.0.0.255
network 4.1.1.0 0.0.0.255
network 3.3.3.3 0.0.0.0
mpls-te enable
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ip address 4.1.1.1 255.255.255.0
mpls
mpls te


mpls rsvp-te
#
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.2.1.0 0.0.0.255
network 4.1.1.0 0.0.0.255
network 4.4.4.4 0.0.0.0
mpls-te enable
#
return
3.30.21 Example for Configuring RSVP Key Authentication (RSVP-

TE FRR)
This section provides an example for configuring RSVP authentication in the MPLS view to
improve network security in the TE FRR networking.
On the network shown in Figure 3-23, the primary tunnel is along the path LSRA -> LSRB ->
LSRC -> LSRD, and FRR is required on the link between LSRB and LSRC for protection.
A bypass tunnel is set up along the path LSRB -> LSRE -> LSRC. LSRB functions as the PLR
and LSRC functions as the MP.
The primary and bypass MPLS TE tunnels are set up by using explicit paths. RSVP-TE is used
as the signaling protocol.
The RSVP authentication needs to be configured on LSRB and LSRC. In this example, LSRB
and LSRC are configured as neighboring nodes by using their LSR IDs, and RSVP key
authentication is enabled to achieve higher reliability.

Figure 3-23 Networking diagram for the MPLS TE FRR-based RSVP key authentication
Loopback1
4.4.4.4/32
LSRD
GE1/0/0
4.1.1.2/24
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32 Loopback1
3.3.3.3/32 GE1/0/0
GE2/0/0 GE2/0/0 LSRC

GE1/0/0 GE1/0/0
2.1.1.1/24 2.1.1.2/24 3.1.1.1/24 3.1.1.2/24 POS3/0/0
POS3/0/0 3.3.1.2/24
3.2.1.1/24
Bypass LSP 3.2.1.2/24 3.3.1.1/24
LSRE
Loopback1
5.5.5.5/32
1. Configure MPLS TE FRR based on Example for Configuring MPLS TE FRR.

2. Configure RSVP key authentication on LSRB and LSRC of the tunnel, preventing forged
Resv messages from consuming network resources.
Data Preparation
l MPLS LSR ID of each device

l Local key for RSVP authentication
l Data listed in "Data Preparation" of Example for Configuring MPLS TE FRR
Procedure
Step 1 Configure MPLS TE FRR.
Configure the primary tunnel and bypass tunnel based on Example for Configuring MPLS TE
FRR and then bind the two tunnels.

Step 2 Configure RSVP key authentication on LSRB and LSRC to enhance security of packet
transmission. In addition, check whether the RSVP key authentication is successfully
configured, configure the RSVP-TE handshake function.
# Configure RSVP key authentication on LSRB.

[LSRB] mpls rsvp-te peer 3.3.3.3
[LSRB-mpls-rsvp-te-peer-3.3.3.3] mpls rsvp-te authentication plain huaweiHW
[LSRB-mpls-rsvp-te-peer-3.3.3.3] mpls rsvp-te authentication handshake
# Configure RSVP key authentication on LSRC.

[LSRC] mpls rsvp-te peer 2.2.2.2
[LSRC-mpls-rsvp-te-peer-2.2.2.2] mpls rsvp-te authentication plain huaweiHW
[LSRC-mpls-rsvp-te-peer-2.2.2.2] mpls rsvp-te authentication handshake
# Run the display mpls rsvp-te statistics global command on LSRB. You can view the status
of the RSVP key authentication. If the command output shows that the values of the
SendChallengeMsgCounter field, RecChallengeMsgCounter field, SendResponseMsgCounter
field, and RecResponseMsgCounter field are not zero, it indicates that the PLR and the MP
successfully shake hands with each other and RSVP key authentication is configured
successfully.
<LSRB> display mpls rsvp-te statistics global
LSR ID: 2.2.2.2 LSP Count: 2
RFSB Count: 0
Total Statistics Information:

PSB CleanupTimeOutCounter: 0 RSB CleanupTimeOutCounter: 0
SendPacketCounter: 104 RecPacketCounter: 216
SendCreatePathCounter: 7 RecCreatePathCounter: 57
SendRefreshPathCounter: 48 RecRefreshPathCounter: 28
SendCreateResvCounter: 4 RecCreateResvCounter: 4
SendRefreshResvCounter: 26 RecRefreshResvCounter: 49
SendResvConfCounter: 0 RecResvConfCounter: 0
SendHelloCounter: 0 RecHelloCounter: 0
SendAckCounter: 0 RecAckCounter: 0
SendPathErrCounter: 1 RecPathErrCounter: 0
SendResvErrCounter: 0 RecResvErrCounter: 0
SendPathTearCounter: 0 RecPathTearCounter: 1
SendResvTearCounter: 1 RecResvTearCounter: 1
SendSrefreshCounter: 0 RecSrefreshCounter: 0
SendAckMsgCounter: 0 RecAckMsgCounter: 0
SendChallengeMsgCounter: 1 RecChallengeMsgCounter: 1
SendResponseMsgCounter: 1 RecResponseMsgCounter: 1
SendErrMsgCounter: 1 RecErrMsgCounter: 0
ResourceReqFaultCounter: 0
Bfd neighbor count: 1 Bfd session count: 0
# Shut down the protected outbound interface on the PLR.

# Run the display interface tunnel 1/0/0 command on LSRA to view the status of the primary
tunnel. You can see that the tunnel interface is Up.
# Run the tracert lsp te tunnel 1/0/0 command on LSRA. You can view the path by which the
tunnel passes.

break.
0 Ingress 2.1.1.2/[13312 ]
1 2.1.1.2 1 ms Transit 3.2.1.2/[13312 13312 ]
2 3.2.1.2 16 ms Transit 3.3.1.2/[3 ]
3 3.3.1.2 1 ms Transit 4.1.1.2/[3 ]
4 4.1.1.2 1 ms Egress
The command output shows that traffic is switched to the bypass tunnel.
# Run the display mpls te tunnel name tunnel1/0/0 verbose command on LSRB. You can see
that the bypass tunnel is working.
[LSRB] display mpls te tunnel name tunnel1/0/0 verbose
No : 1
IncludeAllAff : 0x0
PSB Handle : 66000
Created Time : 2009/01/12 10:09:10
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------

# Run the display mpls rsvp-te peer command. You can see whether the bypass tunnel is
successfully set up.
[LSRB] display mpls rsvp-te peer
Remote Node id Neighbor
Neighbor Addr: -----
SrcInstance: 0xDAC29CB4 NbrSrcInstance: 0x0
Hello Type Sent: NONE
SRefresh Enable: NO
Last valid seq # rcvd: NULL
Interface: gigabitethernet1/0/0
SRefresh Enable: NO
Interface: gigabitethernet2/0/0
SRefresh Enable: NO
Interface: POS1/0/0
SRefresh Enable: NO
The command output shows that the number of RSBs on POS 1/0/0 of LSRB is not zero. This
indicates that RSVP key authentication is successfully configured on LSRB and its neighbor
LSRE, and the resources are successfully reserved.
----End
Configuration Files
l Configuration file of LSRA
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 2.1.1.2
next hop 3.1.1.2
next hop 4.1.1.2
next hop 4.4.4.4
#
isis 1
is-level level-2

cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
ip address 2.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 4.4.4.4
mpls te commit
#
return
l Configuration file of LSRB

#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 3.2.1.2
next hop 3.3.1.2
next hop 3.3.3.3
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
ip address 2.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 3.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0

link-protocol ppp
ip address 3.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
destination 3.3.3.3
mpls te commit
mpls rsvp-te peer 3.3.3.3
mpls rsvp-te authentication plain huaweiHW
#
return
l Configuration file of LSRC

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
ip address 4.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 3.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
link-protocol ppp
ip address 3.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te

mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
mpls rsvp-te peer 2.2.2.2
mpls rsvp-te authentication plain huaweiHW
#
return
l Configuration file of LSRD

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
ip address 4.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return
l Configuration file of LSRE

#
sysname LSRE
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0005.00
traffic-eng level-2
#
interface Pos1/0/0
link-protocol ppp
clock master
ip address 3.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
clock master
ip address 3.3.1.1 255.255.255.0

isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
3.30.22 Example for Configuring RSVP-TE Summary Refresh

(RSVP-TE FRR)
This section provides an example for configuring RSVP Summary Refresh (Srefresh) to improve
resource usage in the TE FRR networking.
As shown in Figure 3-24, the primary tunnel is along the path LSRA -> LSRB -> LSRC ->
LSRD, and the link between LSRB and LSRC requires FRR for protection. In addition, the
summary refresh (Srefresh) function needs to be configured on LSRB and LSRC.
A bypass tunnel is set up along the path LSRB -> LSRE -> LSRC. LSRB functions as the PLR
and LSRC functions as the MP.
The primary and bypass MPLS TE tunnels are set up by using explicit paths. RSVP-TE is used
as the signaling protocol.
The Srefresh function needs to be configured on LSRB and LSRC. In addition, RSVP key
authentication is configured in the MPLS view. This helps the Srefresh function to achieve higher
reliability.

Figure 3-24 Networking diagram for the MPLS TE FRR-based Srefresh function
Loopback1
4.4.4.4/32
LSRD
GE1/0/0
4.1.1.2/24
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32 Loopback1
3.3.3.3/32 GE1/0/0
GE2/0/0 GE2/0/0 LSRC

GE1/0/0 GE1/0/0
2.1.1.1/24 2.1.1.2/24 3.1.1.1/24 3.1.1.2/24 POS3/0/0
POS3/0/0 3.3.1.2/24
3.2.1.1/24
Bypass LSP 3.2.1.2/24 3.3.1.1/24
LSRE
Loopback1
5.5.5.5/32
1. Configure MPLS TE FRR based on Example for Configuring MPLS TE FRR.

2. Configure the Srefresh function on the PLR and MP along a tunnel to enhance transmission
reliability of RSVP messages and improve resource usage.
Data Preparation
Data listed in "Data Preparation" of Example for Configuring MPLS TE FRR
Procedure
Step 1 Configure MPLS TE FRR.
You can configure the primary and bypass MPLS TE tunnels based on Example for
Configuring MPLS TE FRR, and then bind the two tunnels.
Step 2 Configure the Srefresh function on LSRB functioning as the PLR and LSRC functioning as the
MP.

# Configure the Srefresh function on LSRB.

[LSRB] mpls
[LSRB-mpls] mpls rsvp-te srefresh
[LSRB-mpls] quit
# Configure the Srefresh function on LSRC.

[LSRC] mpls
[LSRC-mpls] mpls rsvp-te srefresh
[LSRC-mpls] quit

# Run the display mpls rsvp-te statistics global command on LSRB. You can view the status
of the Srefresh function. If the command output shows that the values of the
SendSrefreshCounter field, RecSrefreshCounter field, SendAckMsgCounter field, and
RecAckMsgCounter field are not zero, it indicates that the Srefresh packets are successfully
transmitted.
[LSRB] display mpls rsvp-te statistics global
RFSB Count: 0

# Shut down the protected outbound interface GE 2/0/0.

# Run the display interface tunnel 1/0/0 command on LSRA to view the status of the primary
tunnel. You can view that the tunnel interface is Up.
# Run the tracert lsp te tunnel 1/0/0 command on LSRA. You can view the path by which the
tunnel passes.
break.
0 Ingress 2.1.1.2/[13312 ]
1 2.1.1.2 1 ms Transit 3.2.1.2/[13312 13312 ]
2 3.2.1.2 16 ms Transit 3.3.1.2/[3 ]
3 3.3.1.2 1 ms Transit 4.1.1.2/[3 ]

4 4.1.1.2 1 ms Egress
# The command output shows that traffic is switched to the bypass tunnel.
# Run the display mpls te tunnel name tunnel1/0/0 verbose command on LSRB. You can view
that the bypass tunnel is working.
[LSRB] display mpls te tunnel name tunnel1/0/0 verbose
No : 1
IncludeAllAff : 0x0
PSB Handle : 66000
Created Time : 2009/01/12 10:09:10
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# Run the display mpls rsvp-te statistics global command. You can view the statistics about
the Srefresh function.
[LSRB]display mpls rsvp-te statistics global


RFSB Count: 1

After the Srefresh function is configured on LSRB and LSRC globally, the Srefresh function on
LSRB and LSRC takes effect when the primary tunnel fails.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 2.1.1.2
next hop 3.1.1.2
next hop 4.1.1.2
next hop 4.4.4.4
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
ip address 2.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1

#
destination 4.4.4.4
mpls te commit
#
return

#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 3.2.1.2
next hop 3.3.1.2
next hop 3.3.3.3
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2
#
ip address 2.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 3.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
link-protocol ppp
ip address 3.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#

destination 3.3.3.3
mpls te commit
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
ip address 4.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 3.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
link-protocol ppp
ip address 3.3.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#

isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0004.00
traffic-eng level-2
#
ip address 4.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return

#
sysname LSRE
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0005.0000.0000.0005.00
traffic-eng level-2
#
interface Pos1/0/0
link-protocol ppp
clock master
ip address 3.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
clock master
ip address 3.3.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
3.30.23 Example for Configuring Board Removal Protection

This section provides an example for implementing the switchover and switchback of TE traffic
between the installation and removal of an interface board.

Figure 3-25 illustrates the MPLS TE FRR networking. The primary tunnel is along the path
PLR → LSR1→ MP → LSR3, and its bypass tunnel is along the path PLR → LSR2 → MP.
After the interface board on which POS 1/0/0 of the PLR resides is removed, TE traffic of the
primary tunnel needs to switch to the bypass tunnel. After the interface board is installed back,
traffic switches back to the primary tunnel.
Figure 3-25 Networking diagram for MPLS TE FRR

Loopback 1
2.2.2.2/32
PO
/0 30 S
1/0 /30 .1. 2/0
Loopback 1 S
PO 1.1.2
1.1/ /0 Loopback 1 Loopback 1
1.1.1.1/32 /0 . 30 PO 4.4.4.4/32 5.5.5.5/32
LSR1
1/0 0 10 30 S1
.1 /
S /3 .1. 0/0
PO 1.1.1 2/3 POS3/0/0
0 . 0 50.1.1.1/30
1
POS1/0/0
P /0
PLR 2 OS /0 MP 50.1.1.2/30 LSR3
0.1 2/0
.1. /0 O S2 .2/30
1/3 LSR2 P 1.1
0 POS .
20 1 / 0/0 40
.1. /0/0 2 30
1.2 P OS .1.1/
/30 .1
40 : primary LSP
Loopback 1 : bypass LSP
3.3.3.3/32
1. Configure the tunnel interfaces of the primary and bypass tunnels on the master control
board.
2. Specify the explicit paths of the primary tunnel and the bypass tunnel when configuring
MPLS TE FRR. Note that the explicit paths of the primary tunnel and the bypass tunnel
must pass through different interface boards of the PLR, and the primary tunnel cannot be
on the board to be removed; otherwise, board removal protection cannot be implemented.
Data Preparation
l Slot number of the main control board on the PLR

l Tunnel interfaces of the primary and bypass tunnels
l Outgoing interfaces of the primary and bypass tunnels
l Explicit paths of the primary and bypass tunnels

Procedure
Assign an IP address and mask to each interface, including the loopback interface, according to
Step 2 Configure OSPF on all LSRs to advertise the routes of each network segment and the host route
of each LSR ID.
Configure OSPF on all LSRs to advertise the host route of each LSR ID. For configuration
The command output shows that the LSRs learn the host route of the LSR ID from each other.
Step 3 Configure the basic MPLS functions and enable MPLS TE and RSVP-TE.
# Configure a PLR.
[PLR] mpls lsr-id 1.1.1.1
[PLR] mpls
[PLR-mpls] mpls te
[PLR-mpls] mpls rsvp-te
[PLR-mpls] quit
[PLR] interface pos 1/0/0
[PLR-Pos1/0/0] mpls
[PLR-Pos1/0/0] mpls te
[PLR-Pos1/0/0] mpls rsvp-te
[PLR-Pos1/0/0] quit
[PLR] interface pos2/0/0
[PLR-Pos2/0/0] mpls
[PLR-Pos2/0/0] mpls te
[PLR-Pos2/0/0] mpls rsvp-te
[PLR-Pos2/0/0] quit
NOTE
Repeat this step for LSR1, LSR2, the MP, and LSR3. For configuration details, see Configuration Files
in this section.
Step 4 Configure OSPF TE on all LSRs and enable CSPF on the ingress of the primary tunnel.
# Configure OSPF TE.
[PLR] ospf
[PLR-ospf-1] opaque-capability enable
[PLR-ospf-1] area 0
[PLR-ospf-1-area-0.0.0.0] mpls-te enable
[PLR-ospf-1-area-0.0.0.0] quit
[PLR-ospf-1] quit
NOTE
Repeat this step for LSR1, LSR2, the MP, and LSR3. For configuration details, see Configuration Files
in this section.
# Enable CSPF on the ingress of the primary tunnel.

[PLR] mpls
[PLR-mpls] mpls te cspf
Step 5 Configure the reservable bandwidth for the interfaces on each link.
Set the maximum reservable bandwidth of the link to 10 Mbit/s, the BC0 bandwidth to 10 Mbit/
s, and the BC1 bandwidth to 3 Mbit/s.

# Configure the PLR.

[PLR-Pos1/0/0] mpls te bandwidth max-reservable-bandwidth 10000
[PLR-Pos1/0/0] mpls te bandwidth bc0 10000 bc1 3000
[PLR-Pos1/0/0] quit
[PLR-Pos2/0/0] mpls te bandwidth max-reservable-bandwidth 10000
[PLR-Pos2/0/0] mpls te bandwidth bc0 10000 bc1 3000
[PLR-Pos2/0/0] quit
# Configure link bandwidth on all the outbound interfaces of the link along the primary and
bypass tunnels. For configuration details, see Configuration Files in this section.
# Configure the explicit path for the primary tunnel on the PLR.
[PLR] explicit-path master
[PLR-explicit-path-master] next hop 10.1.1.2
[PLR-explicit-path-master] quit
# Configure the tunnel interface of the primary tunnel.

[PLR] interface tunnel0/0/1
[PLR-Tunnel0/0/1] ip address unnumbered interface loopback1
[PLR-Tunnel0/0/1] tunnel-protocol mpls te
[PLR-Tunnel0/0/1] destination 5.5.5.5
[PLR-Tunnel0/0/1] mpls te tunnel-id 100
[PLR-Tunnel0/0/1] mpls te signal-protocol rsvp-te
[PLR-Tunnel0/0/1] mpls te path explicit-path master
[PLR-Tunnel0/0/1] mpls te bandwidth ct0 400
# Enable MPLS TE FRR.

[PLR-Tunnel0/0/1] mpls te fast-reroute
[PLR-Tunnel0/0/1] mpls te commit
[PLR-Tunnel0/0/1] quit
# Run the display interface tunnel command on PLR. The command output shows that the
status of Tunnel 0/0/1 of the primary tunnel is Up.
[PLR] display interface tunnel 0/0/1
Last up time: 2009-03-29, 16:35:10
...
Step 7 Configure the bypass tunnel.
# Configure the explicit path for the bypass tunnel on the PLR.
[PLR] explicit-path by-path
[PLR-explicit-path-by-path] next hop 20.1.1.2
# Configure the tunnel interface of the bypass tunnel.

[PLR] interface tunnel 0/0/2
[PLR-Tunnel0/0/2] ip address unnumbered interface loopback 1
[PLR-Tunnel0/0/2] tunnel-protocol mpls te
[PLR-Tunnel0/0/2] destination 4.4.4.4

[PLR-Tunnel0/0/2] mpls te tunnel-id 200

[PLR-Tunnel0/0/2] mpls te signal-protocol rsvp-te
[PLR-Tunnel0/0/2] mpls te path explicit-path by-path
[PLR-Tunnel0/0/2] mpls te bypass-tunnel
# Configure the interface protected by the bypass tunnel.

[PLR-Tunnel0/0/2] mpls te protected-interface pos 1/0/0
[PLR-Tunnel0/0/2] mpls te commit
# Run the display interface tunnel command on PLR. The command output shows that the
status of Tunnel 0/0/2 of the bypass tunnel is Up.
<PLR> display interface tunnel 0/0/2
Last up time: 2009-03-29, 16:43:34
...

# Run the tracert lsp te tunnel command on the PLR. The command output shows that TE
traffic is transmitted through the primary tunnel.
<PLR> tracert lsp te tunnel 0/0/1
break.
0 Ingress 10.1.1.2/[65536 ]
1 10.1.1.2 50 ms Transit 30.1.1.2/[131072 ]
2 30.1.1.2 40 ms Transit 50.1.1.2/[3 ]
3 5.5.5.5 70 ms Egress
# After removing the interface board where the outbound interface of the primary tunnel (POS
1/0/0) resides, run the display interface tunnel and display mpls te tunnel stale-interface
interface-index verbose commands. The command output shows that the tunnel interface of the
primary tunnel remains Up.
# Run the display mpls te tunnel stale-interface command on the PLR. The command output
shows that the outbound interface of the primary tunnel is in the Stale state.
<PLR> display mpls stale-interface
Stale-interface Status TE Attri LSP Count CRLSP Count Effective MTU
0x018000106 Up Dis 0 1 -
<PLR> display mpls te tunnel stale-interface 18000106 verbose
No : 1
LSR Role : Ingress LSP Type : -
In-Interface : -
Out-Interface : 0x800086
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 1024
Created Time : 2009-03-29, 16:43:34
RSVP LSP Type : -
--------------------------------

DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# Run the display mpls te tunnel path command on the PLR to view the path information of
the primary tunnel.
<PLR> display mpls te tunnel path Tunnel0/0/1
Lsp ID : 1.1.1.1 :100 :1
Hop Information
Hop 0 20.1.1.1 Local-Protection in use
Hop 1 20.1.1.2 Label 65536
Hop 2 3.3.3.3 Label 65536
Hop 3 40.1.1.1
Hop 4 40.1.1.2 Label 131072
Hop 5 4.4.4.4 Label 131072
Hop 6 50.1.1.1
Hop 7 50.1.1.2 Label 3
Hop 8 5.5.5.5 Label 3
# Run the tracert lsp te tunnel command. The command output shows that TE traffic is
transmitted through the bypass tunnel.
break.
0 Ingress 20.1.1.2/[65536 15360 ]
1 20.1.1.2 50 ms Transit 40.1.1.2/[131073 ]
2 40.1.1.2 50 ms Transit 30.1.1.1/[3 ]
3 30.1.1.1 4 ms Transit
4 30.1.1.2 15 ms Transit 50.1.1.2/[3 ]
5 11.1.1.1 6 ms Egress

# After you re-install the interface board where the outbound interface of the primary tunnel
resides, run the tracert lsp te tunnel command. The command output shows that traffic switches
back to the primary tunnel.
break.
0 Ingress 10.1.1.2/[65537 ]
1 10.1.1.2 40 ms Transit 30.1.1.2/[131074 ]
2 30.1.1.2 50 ms Transit 50.1.1.2/[3 ]
3 5.5.5.5 60 ms Egress
----End
Configuration Files
l PLR configuration file
#
sysname PLR
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 10.1.1.2
next hop 30.1.1.2
next hop 50.1.1.2
next hop 5.5.5.5
#
next hop 20.1.1.2
next hop 40.1.1.2
next hop 4.4.4.4
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 5.5.5.5


mpls te commit
#
destination 4.4.4.4
mpls te protected-interface Pos1/0/0
mpls te commit
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 20.1.1.0 0.0.0.3
network 1.1.1.1 0.0.0.0
mpls-te enable
#
return
l LSR1 configuration file

#
sysname LSR1
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 30.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 30.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
mpls-te enable
#
return

#
sysname LSR2
#

mpls lsr-id 3.3.3.3

mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 40.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.3
network 30.1.1.0 0.0.0.3
network 3.3.3.3 0.0.0.0
mpls-te enable
#
return
l MP configuration file
#
sysname MP
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
link-protocol ppp
ip address 30.1.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 40.1.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
link-protocol ppp
ip address 50.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1

ip address 4.4.4.4 255.255.255.255

#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.3
network 40.1.1.0 0.0.0.3
network 50.1.1.0 0.0.0.3
network 4.4.4.4 0.0.0.0
mpls-te enable
#
return

#
sysname LSR3
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
link-protocol ppp
ip address 50.1.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
ospf 1
area 0.0.0.0
network 50.1.1.0 0.0.0.3
network 5.5.5.5 0.0.0.0
mpls-te enable
#
return
3.30.24 Example for Configuring CR-LSP Hot Standby

This section provides an example for establishing a hot-standby CR-LSP, which involves
configuring a hot-standby CR-LSP and a best-effort path.
Figure 3-26 illustrates an MPLS VPN. A TE tunnel originates from the ingress PE1 and
terminates at the egress PE2. CR-LSP hot backup and best-effort LSPs need to be configured.
The following LSPs need to be established:
l Primary CR-LSP along the path PE1 --> P1 --> PE2
l Backup CR-LSP along the path PE1 --> P2 --> PE2
If the primary CR-LSP fails, traffic switches to the backup CR-LSP. After the primary CR-LSP
recovers from the fault, traffic switches back to the primary CR-LSP in 15 seconds. If both the
primary and backup CR-LSPs fail, traffic switches to the best-effort LSP. If both the primary
and backup CR-LSPs fail, traffic switches to the best-effort path. Explicit paths can be configured
for the primary and backup CR-LSPs. A best-effort path can be generated automatically. In this
example, the best-effort path is PE1 -> P2 -> P1 -> PE2. The calculated best-effort path varies
according to the faulty node.

Figure 3-26 Networking diagram for CR-LSP hot backup

Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
GE1/0/0 GE1/0/0
P1 10.1.1.1/30 10.1.1.2/30 P2
GE3/0/0 GE3/0/0
GE2/0/0 10.2.1.1/30 10.3.1.2/30 GE2/0/0
10.4.1.2/30 10.5.1.1/30
GE2/0/0 GE2/0/0
10.4.1.1/30 10.5.1.2 /30
GE1/0/0 GE1/0/0
PE1 PE2
10.3.1.1/30 10.2.1.2/30
Loopback1 Loopback1
4.4.4.4/32 3.3.3.3/32
: Primary path
: Backup path
: Best-effort path
1. Configure IP addresses and an IGP on all LSRs.

2. Configure basic MPLS functions and MPLS TE functions.
3. Specify explicit paths for the primary and backup CR-LSPs on PE1.
4. Create the tunnel interface with PE2 as the egress on PE1 and specify the explicit path.
Enable hot standby. Enable the device to attempt to create a best-effort path to protect traffic
if both the primary and backup CR-LSPs fail. Set the switching delay time to 15 seconds.
Data Preparation
l IGP protocol and data required for configuring an IGP

l MPLS LSR ID
l Tunnel interface and bandwidth used by the tunnel
l Explicit paths of the primary and backup CR-LSPs

Procedure
Assigne an IP address and mask to each interface, create loopback interfaces on LSRs, and
configure the IP addresses of loopback interfaces as MPLS LSR IDs, according to Figure
3-26. For configuration details, see Configuration Files in this section.
Configure OSPF or IS-IS on each LSR to enable communication between LSRs. In this example,
IS-IS is configured. For configuration details, see Configuration Files in this section.
On each LSR, configure an LSR ID and enable MPLS in the system view and in the interface
view. For configuration details, see Configuration Files in this section.
Enable MPLS-TE and MPLS RSVP-TE in the MPLS view and the interface view on each LSR.
Set the maximum reservable bandwidth of links to 100 Mbit/s and the bandwidth of BC0 to 100
Mbit/s. For configuration details, see Configuration Files in this section.
Configure IS-IS TE on each LSR and CSPF on PE1. For detailed configuration, see Configuring
an RSVP-TE Tunnel.
Step 6 Configure the explicit paths for the primary and backup CR-LSPs respectively.
# Configure the explicit path for the primary CR-LSP on PE1.

<PE1> system-view
# Configure the explicit path for the backup CR-LSP on PE1.

[PE1] explicit-path backup
[PE1-explicit-path-backup] next hop 10.3.1.2
[PE1-explicit-path-backup] quit
# Display information about the explicit path on PE1.

[PE1] display explicit-path main
Path Name : main Path Status : Enabled
[PE1] display explicit-path backup
Path Name : backup Path Status : Enabled
Step 7 Configure the tunnel interfaces.

# Configure a tunnel interface on PE1; specify the explicit path; set the tunnel bandwidth to 10
Mbit/s.
# Configure hot standby on the tunnel interface, set the switch delay time to 15 seconds, specify
the explicit path, and configure the best-effort LSP.
[PE1-Tunnel1/0/0] mpls te backup hot-standby wtr 15
[PE1-Tunnel1/0/0] mpls te path explicit-path backup secondary
[PE1-Tunnel1/0/0] mpls te backup ordinary best-effort
Run the display mpls te tunnel-interface tunnel 1/0/0 command on PE1. The command output
shows that the primary and backup CR-LSPs have been established.
----------------------------------------------------------------
Tunnel1/0/0
----------------------------------------------------------------
Session ID : 100
# Display information about hot backup.

[PE1] display mpls te hot-standby state interface Tunnel 1/0/0
----------------------------------------------------------------
----------------------------------------------------------------
session id : 100
main LSP token : 0x100201a
HSB switch result : Primary LSP
WTR : 15s
using same path : no
# Run the ping lsp te command to check the connection of the backup CR-LSP.
[PE1] ping lsp te tunnel 1/0/0 hot-standby
LSP PING FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1/0/0 : 100 data bytes, press
CTRL_C to break
0.00% packet loss
# Run the tracert lsp te command to trace the path of the backup CR-LSP.

[PE1] tracert lsp te tunnel 1/0/0 hot-standby

break.
0 Ingress 10.3.1.2/[13313 ]
1 10.3.1.2 90 ms Transit 10.5.1.2/[3 ]
2 3.3.3.3 130 ms Egress
Connect port 1 and port 2 on a tester to PE1 and PE2, respectively. Inject MPLS traffic destined
for Port 2 into Port 1. After the cable attached to GE 2/0/0 on PE1 or P1 is removed, the fault
rectified within milliseconds. Run the display mpls te hot-standby state interface tunnel
1/0/0 command on PE1. The command output shows that traffic has switched to the backup CR-
LSP.
[PE1] display mpls te hot-standby state interface tunnel 1/0/0
----------------------------------------------------------------
----------------------------------------------------------------
session id : 100
main LSP token : 0x0
HSB switch result : Hot-standby LSP
WTR : 15s
using same path : no
After the cable is reconnected to GE 2/0/0, traffic switches back to the primary CR-LSP after a
15–second delay.
After you remove the cable from GE 2/0/0 on PE1 or P1 and the cable from GE 2/0/0 on PE2
or P2, the tunnel interface goes Down and then Up. This means that the best-effort path has been
established, and traffic has switched to the best-effort path.
----------------------------------------------------------------
Tunnel1/0/0
----------------------------------------------------------------
Active LSP : Best-Effort LSP
Session ID : 100
Hot-Standby LSP State : DOWN
Best-Effort LSP State : UP
Lsp ID : 4.4.4.4 :100 :32776
Hop Information
Hop 0 10.3.1.1
Hop 1 10.3.1.2
Hop 2 2.2.2.2
Hop 3 10.1.1.2
Hop 4 10.1.1.1
Hop 5 1.1.1.1
Hop 6 10.2.1.1
Hop 7 10.2.1.2
Hop 8 3.3.3.3
----End

Configuration Files
#
sysname PE1
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path backup
next hop 10.3.1.2
next hop 10.5.1.2
next hop 3.3.3.3
#
explicit-path main
next hop 10.4.1.2
next hop 10.2.1.2
next hop 3.3.3.3
#
isis 1
cost-style wide
network-entity 10.0000.0000.0004.00
#
ip address 10.3.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
destination 3.3.3.3
mpls te path explicit-path backup secondary
mpls te backup hot-standby wtr 15
mpls te commit
#
return
#
sysname P1

#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls

mpls te
mpls rsvp-te
#
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
3.30.25 Example for Configuring Isolated LSP Computation

This section provides an example of how to configure isolated label switched path (LSP)
computation.
Isolated primary and hot-standby LSPs are necessary to improve the LSP reliability on IP radio
access networks (IP RANs) that use Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE). The constrained shortest path first (CSPF) algorithm does not meet this reliability
requirement because CSPF may compute two LSPs that intersect at aggregation nodes.
Specifying explicit paths for LSPs can improve reliability but this method does not adapt to

topology changes. Each time a node is added to or deleted from the IP RAN, operators must
configure new explicit paths, which is time-consuming and laborious. Isolated LSP computation
is another method to improve reliability. After this feature is configured, the device uses both
the disjoint and CSPF algorithms to compute isolated primary and hot-standby LSPs.
Figure 3-27 shows the topology of an IP RAN that uses a Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) tunnel. Devices on this network use the Open Shortest Path
First (OSPF) protocol for communication. The numeral on each link represents the link's TE
metric. An RSVP-TE tunnel needs to be established between LSRA and LSRF. The constraint-
based routed label switched path (CR-LSP) hot standby feature needs to be enabled.
Two isolated LSPs exist on this topology: LSRA -> LSRC -> LSRE -> LSRF and LSRA ->
LSRB -> LSRD -> LSRF. However, if the disjoint algorithm is not enabled, CSPF computes
LSRA -> LSRC-> LSRD-> LSRF as the primary LSP and cannot compute an isolated hot-
standby LSP. To improve LSP reliability, configure isolated LSP computation.
Figure 3-27 RSVP-TE tunnel networking diagram
LSRC
GE1/0/0 GE1/0/2
1 5
LSRA GE1/0/0 GE1/0/0
GE1/0/1
1
GE1/0/1 RSV G
NodeB P-TE
10 tu nnel 1
GE1/0/0 G
LSRB 10 GE1/0/1
GE1/0/1 1 GE1/0/0
GE1/0/0 GE1/0/2
LSRD
Table 3-6 Interfaces and IP addresses

LSRA Loopback1 1.1.1.1/32 LSRB Loopback1 2.2.2.2/32
GE 1/0/0 1.3.0.1/24 GE 1/0/0 1.2.0.2/24
GE 1/0/1 1.2.0.1/24 GE 1/0/1 2.4.0.2/24


LSRC Loopback1 3.3.3.3/32 LSRD Loopback1 4.4.4.4/32
GE 1/0/0 1.3.0.3/24 GE 1/0/0 2.4.0.4/24
GE 1/0/1 3.4.0.3/24 GE 1/0/1 3.4.0.4/24
GE 1/0/2 3.5.0.3/24 GE 1/0/2 4.6.0.4/24
LSRE Loopback1 5.5.5.5/32 LSRF Loopback1 6.6.6.6/32
GE 1/0/0 3.5.0.5/24 GE 1/0/0 4.6.0.6/24
GE 1/0/1 5.6.0.5/24 GE 1/0/1 5.6.0.6/24
1. Set addresses for all physical and loopback interfaces listed in Table 3-6.
2. Globally enable OSPF on each device, so that OSPF advertises segment routes of each
physical and loopback interface. Enable OSPF TE in the area where the devices reside.
3. Set MPLS label switching router (LSR) IDs for all the devices and globally enable MPLS,
TE, RSVP-TE, and CSPF.
4. Enable MPLS, TE, and RSVP-TE on the outbound interfaces of all links along the TE
tunnel. Set a TE metric for each link, as specified in Figure 3-27.
5. Create a tunnel interface on LSRA and specify the IP address, tunnel protocol, destination
address, tunnel ID, and signaling protocol for the tunnel interface.
6. Enable the CR-LSP hot standby feature and then the disjoint algorithm on the tunnel
interface.
Data Preparation
l IP address for each interface (see Table 3-6)

l OSPF process ID (1) and area ID (0.0.0.0)
l TE metric for each link (see Figure 3-27)
l Loopback interface address for each MPLS LSR ID
l Tunnel interface number (Tunnel 0/0/1), tunnel ID (1), loopback interface address to be
borrowed, destination address (6.6.6.6), and signaling protocol (RSVP-TE)
Procedure
Step 1 Set an IP address for each interface.
Set an IP address for each interface and create a loopback interface on each device. For
configuration details, see interfaces and IP addresses in this section.

Step 2 Enable OSPF on each device.

Enable basic OSPF functions and MPLS TE on each device.
# Configure LSRA.
<LSRA> system-view
[LSRA] ospf 1
[LSRA-ospf-1] area 0.0.0.0
[LSRA-ospf-1] quit
The configurations of LSRB, LSRC, LSRD, LSRE, and LSRF are similar to the configuration
of LSRA. For configuration details, see Configuration Files in this section.
Step 3 Configure basic MPLS functions and enable MPLS TE, RSVP-TE, and CSPF.
Enable MPLS, MPLS TE, RSVP-TE, and CSPF on each device. Enable MPLS, TE, and RSVP-
TE on the outbound interface of each link. Set a TE metric for each link.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
[LSRA-GigabitEthernet1/0/0] mpls te metric 1
[LSRA-GigabitEthernet1/0/1] mpls te metric 10
The configurations of LSRB, LSRC, LSRD, LSRE, and LSRF are similar to the configuration
of LSRA. For configuration details, see Configuration Files in this section.
Step 4 Configure an MPLS TE tunnel interface.
# Configure LSRA.
Step 5 Configure isolated LSP computation.

Enable the CR-LSP hot standby feature and then the disjoint algorithm on the tunnel interface.
# Configure LSRA.

[LSRA-Tunnel0/0/1] mpls te backup hot-standby

[LSRA-Tunnel0/0/1] mpls te cspf disjoint

# Run the display mpls te cspf destination 6.6.6.6 computation-mode disjoint command on
LSRA. The command output shows that the primary LSP is LSRA -> LSRC -> LSRE -> LSRF
and the hot-standby LSP is LSRA-> LSRB-> LSRD-> LSRF. The two LSPs do not intersect.
[LSRA] display mpls te cspf destination 6.6.6.6 computation-mode disjoint
Main path for the given constraints is:
1.3.0.1 Include
1.3.0.3 Include
3.5.0.3 Include
3.5.0.5 Include
5.6.0.5 Include
5.6.0.6 Include
The total metrics of the calculated path is : 16
Hot-standby path for the given constraints is:

1.2.0.1 Include
1.2.0.2 Include
2.4.0.2 Include
2.4.0.4 Include
4.6.0.4 Include
4.6.0.6 Include
Complete disjoint path computed and the total metrics of the calculated path is
: 21
# Run the display mpls te tunnel-interface Tunnel 0/0/1 and display mpls te tunnel path
Tunnel0/0/1 commands on LSRA to view information about the primary and hot-standby LSPs.
[LSRA] display mpls te tunnel-interface Tunnel 0/0/1
----------------------------------------------------------------
Tunnel0/0/1
----------------------------------------------------------------
Session ID : 1
[LSRA] display mpls te tunnel path Tunnel0/0/1
Lsp ID : 1.1.1.1 :1 :32773
Hop Information
Hop 0 1.2.0.1
Hop 1 1.2.0.2 Label 1025
Hop 2 2.2.2.2 Label 1025
Hop 3 2.4.0.2
Hop 4 2.4.0.4 Label 1025
Hop 5 4.4.4.4 Label 1025
Hop 6 4.6.0.4
Hop 7 4.6.0.6 Label 3

Hop 8 6.6.6.6 Label 3

Lsp ID : 1.1.1.1 :1 :2
Hop Information
Hop 0 1.3.0.1
Hop 1 1.3.0.3 Label 1025
Hop 2 3.3.3.3 Label 1025
Hop 3 3.5.0.3
Hop 4 3.5.0.5 Label 1028
Hop 5 5.5.5.5 Label 1028
Hop 6 5.6.0.5
Hop 7 5.6.0.6 Label 3
Hop 8 6.6.6.6 Label 3
The command outputs show that the computed primary and hot-standby LSPs are the same as
the actual primary and hot-standby LSPs, indicating that the device has computed two isolated
LSPs.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 1.3.0.1 255.255.255.0
mpls
mpls te
mpls te metric 1
mpls rsvp-te
#
undo shutdown
ip address 1.2.0.1 255.255.255.0
mpls
mpls te
mpls metric 10
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface
Tunnel0/0/1
tunnel-protocol mpls
te
destination
6.6.6.6
mpls te tunnel-id
1
label
mpls te backup hot-
standby
mpls te cspf

disjoint
mpls te commit
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.1.1.1
0.0.0.0
network 1.2.0.0
0.0.0.255
network 1.3.0.0
0.0.0.255
mpls-te enable
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 1.2.0.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 2.4.0.2 255.255.255.0
mpls
mpls te
mpls te metric 10
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.2.0.0
0.0.0.255
network 2.2.2.2
0.0.0.0
network 2.4.0.0
0.0.0.255
mpls-te enable
#
return

#
sysname LSRC
#

mpls lsr-id 3.3.3.3

mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 1.3.0.3 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 3.4.0.3 255.255.255.0
mpls
mpls te
mpls te metric 1
mpls rsvp-te
#
undo shutdown
ip address 3.5.0.3 255.255.255.0
mpls
mpls te
mpls te metric 5
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.3.0.0
0.0.0.255
network 3.3.3.3
0.0.0.0
network 3.4.0.0
0.0.0.255
network 3.5.0.0
0.0.0.255
mpls-te enable
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 2.4.0.4 255.255.255.0
mpls
mpls te
mpls rsvp-te
#

undo shutdown
ip address 3.4.0.4 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 4.6.0.4 255.255.255.0
mpls
mpls te
mpls te metric 1
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 2.4.0.0
0.0.0.255
network 3.4.0.0
0.0.0.255
network 4.4.4.4
0.0.0.0
network 4.6.0.0
0.0.0.255
mpls-te enable
#
return

#
sysname LSRE
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 3.5.0.5 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 5.6.0.5 255.255.255.0
mpls
mpls te
mpls te metric 10
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
ospf
1
opaque-capability

enable
area
0.0.0.0
network 3.5.0.0
0.0.0.255
network 5.5.5.5
0.0.0.0
network 5.6.0.0
0.0.0.255
mpls-te enable
#
return
l LSRF configuration file

#
sysname LSRF
#
mpls lsr-id 6.6.6.6
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 4.6.0.6 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 5.6.0.6 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 4.6.0.0
0.0.0.255
network 5.6.0.0
0.0.0.255
network 6.6.6.6
0.0.0.0
mpls-te enable
#
return
3.30.26 Example for Locking an Attribute Template for Hot-standby

CR-LSPs
This section describes how to lock an attribute template for hot-standby CR-LSPs. You can
configure an attribute template for hot-standby CR-LSPs, preventing an unwanted CR-LSP
switchover and reducing resource consumption.

On a network as shown in Figure 3-28, a primary CR-LSP needs to be set up from LSRA to
LSRD, and a hot-standby CR-LSP needs to be set up for the primary CR-LSP.
A maximum of three attribute templates can be created for a backup CR-LSP. In the event that
a CR-LSP established using any of the three templates is stable, you can lock a CR-LSP attribute
template, avoiding unnecessary traffic switchover and reducing consumption of system
resources.
When an attribute template for hot-standby CR-LSPs is locked, the following effects can be
achieved:
l If a hot-standby CR-LSP is established through a lower-priority attribute template, the

system will not use a higher-priority attribute template to create a new hot-standby CR-
LSP.
l When the attribute template of hot-standby CR-LSPs is unlocked, the system uses a higher-
priority attribute template to create a new hot-standby CR-LSP according to the make-
before-break mechanism.
Figure 3-28 Networking diagram for locking an attribute template of hot-standby CR-LSPs
LSRC
/0 PO
S 1/0 24 10. S2/0
PO .1.2/ 1.4 /0
1 .1/2 PO
/0 0 . 41 S
1.1.1.1/32 S1/0 4 1 0.1 1/0/0 4.4.4.4/32
O /2 .4
P .1.1 .2/2
1 POS2/0/0 LSRE POS2/0/0 4
10.
10.1.3.1/24 10.1.6.2/24
PO POS1/0/0 POS2/0/0
0
LSRA 10 S3/ 10.1.3.2/24 10.1.6.1/24 3/0/ 4 LSRD
.1. 0
2.1 /0
S /2
PO .5.2
/24 PO .1
10 S1/ /0 10
.1. 0/0 S 2/0 /24
2.2
/24 PO .5.1
.1
10
LSRB
1. Configure IP addresses and a routing protocol for interfaces to ensure the connectivity on
the network layer.
2. Enable MPLS, MPLS TE, RSVP-TE, and CSPF in the system view and the interface view.
3. Configure CR-LSP attribute templates on the ingress of a primary CR-LSP.
4. Use CR-LSP attribute templates to establish CR-LSPs on a tunnel interface, and lock a CR-
LSP attribute template of hot-standby CR-LSPs.

Data Preparation
l LSR ID of each device
l Name of each CR-LSP attribute template and attributes of each template
l IP address of the tunnel interface, destination address of the tunnel, and tunnel ID
Procedure
Step 1 Configure IP addresses and an IGP (OSPF, in this example) for interfaces to ensure connectivity
at the network layer.
Step 2 Configure the MPLS LSR ID for each device, and enable MPLS and MPLS TE in the system
view and in each interface view of each device.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
NOTE
in this section.
Step 3 Configure CR-LSP attribute templates and their explicit paths.

# On LSRA, configure the explicit path named up_path as LSRA → LSRC → LSRD.
[LSRA] explicit-path up_path
[LSRA-explicit-path-up_path] quit
# On LSRA, configure the explicit path named down_path as LSRA → LSRB → LSRD.
[LSRA] explicit-path down_path
[LSRA-explicit-path-down_path] quit
# On LSRA, configure the explicit path named middle_path as LSRA → LSRE → LSRD.

[LSRA] explicit-path middle_path

[LSRA-explicit-path-middle_path] quit

[LSRA-lsp-attribuLSP_attribute_1] explicit-path up_path
[LSRA-lsp-attribuLSP_attribute_1] quit

[LSRA-lsp-attribuLSP_attribute_2] explicit-path middle_path

[LSRA-lsp-attribuLSP_attribute_3] explicit-path down_path
NOTE
The priorities of the CR-LSP attribute templates configured on the same tunnel interface must be the same.
Step 4 Use a CR-LSP attribute template to set up a CR-LSP with LSRA being the ingress and LSRD
being the egress.
# To trigger LSRA to use a lower-priority attribute template to set up a hot-standby CR-LSP,

run the shutdown command to shut down the explicit path named down_path.
[LSRA] interface POS3/0/0
[LSRA-Pos3/0/0] shutdown
# Set up a CR-LSP from LSRA to LSRD, and lock an attribute template for hot-standby CR-
LSPs.
[LSRA-Tunnel1/0/0] mpls te primary-lsp-constraint lsp-attribute lsp_attribute_1
lsp_attribute_3
lsp_attribute_2
[LSRA-Tunnel1/0/0] mpls te backup hotstandby-lsp-constraint lock
# On LSRA, run the undo shutdown command on POS 3/0/0 to reenable the explicit path named
down_path and make the attribute template named lsp_attribute_3 effective.
[LSRA-Pos3/0/0] undo shutdown


# After completing the configuration, run the shutdown command on the tunnel interface of the
primary CR-LSP. You can switch traffic to a hot-standby CR-LSP.
[LSRA-POS1/0/0] shutdown
[LSRA-POS1/0/0] quit
# After the traffic switchover, run the tracert lsp te tunnel command on LSRA. You can view
that the hot-standby CR-LSP is set up by using the explicit path configured in the attribute
template named lsp_attribute_2.
<LSRA> tracert lsp te tunnel
break.
0 Ingress 10.1.3.2/[1024 ]
1 10.1.3.2 120 ms Transit 10.1.6.2/[3 ]
2 4.4.4.4 100 ms Egress
# Run the display mpls te tunnel verbose command on LSRA. You can view that the hot-
standby CR-LSP is set up by using the attribute template named lsp_attribute_2 that is not
upgraded.
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : 2
PSB Handle : 1026
Created Time : 2010/02/21 12:00:50
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -


IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
# Run the undo mpls te backup hotstandby-lsp-constraint lock command on LSRA to unlock
the attribute template of hot-standby CR-LSPs.
[LSRA-Tunnel1/0/0] undo mpls te backup hotstandby-lsp-constraint lock
# Run the tracert lsp te tunnel1/0/0 command on LSRA. You can view that the hot-standby
CR-LSP is set up by using the explicit path configured in the attribute template named
lsp_attribute_3.
<LSRA> tracert lsp te tunnel1/0/0
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1/0/0 , press CTRL_C t
o break.
0 Ingress 10.1.2.2/[1024 ]
1 10.1.2.2 90 ms Transit 10.1.5.2/[3 ]
2 4.4.4.4 100 ms Egress
# Run the display mpls te tunnel verbose command on LSRA. You can view that the hot-
standby CR-LSP is set up by using the attribute template named lsp_attribute_1 that is not
upgraded. This indicates that the system automatically upgrades the attribute template after the
attribute template of hot-standby CR-LSPs is unlocked.
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : 1
PSB Handle : 1182
Created Time : 2010/02/21 18:14:23
--------------------------------
DS-TE Information
--------------------------------


--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 10.1.3.2
next hop 10.1.6.2
#
next hop 10.1.1.2
next hop 10.1.4.2
#
next hop 10.1.2.2
next hop 10.1.5.2
#
priority 5 5
hop-limit 12
commit
#
priority 5 5
commit

#
priority 5 5
commit
#
interface Pos1/0/0
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.3.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
ip address 10.1.2.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 4.4.4.4
mpls te primary-lsp-constraint lsp-attribute lsp_attribute_1
mpls te hotstandby-lsp-constraint 2 lsp-attribute lsp_attribute_2
mpls te ordinary-lsp-constraint 1 lsp-attribute lsp_attribute_3
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.1 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
mpls-te enable
#
return

#
sysname LSRB
#
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.5.1 255.255.255.0
mpls

mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.5.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRC
#
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.4.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.4.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
ip address 10.1.4.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.6.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos3/0/0
ip address 10.1.5.2 255.255.255.0
mpls
mpls te

mpls rsvp-te
#
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 10.1.4.0 0.0.0.255
network 10.1.5.0 0.0.0.255
network 10.1.6.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRE
#
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
ip address 10.1.3.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
ip address 10.1.6.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
network 10.1.3.0 0.0.0.255
network 10.1.6.0 0.0.0.255
mpls-te enable
#
return
3.30.27 Example for Configuring the Dynamic Bandwidth Function

for a Hot-standby CR-LSP
This section describes how to configure the dynamic bandwidth function for a hot-standby CR-
LSP. This function can save system resources.
Figure 3-29 is a Networking diagram for CR-LSP hot standby. A TE tunnel is established from
PE1 to PE2. The tunnel is enabled with hot standby and configured with the best-effort path. In
this manner, traffic is switched to the backup CR-LSP when the primary CR-LSP fails. If the
backup CR-LSP also fails, this triggers the establishment of a best-effort path, and then the traffic
switches to the best-effort path.
It is required that the dynamic bandwidth function for a hot-standby CR-LSP be configured on
the tunnel interface. This can achieve the following effects:

l When the primary CR-LSP works properly, the hot-standby CR-LSP does not occupy
bandwidth, saving bandwidth resources.
l If the primary tunnel fails, traffic switches to the hot-standby CR-LSP and then forwarded
in a best-effort manner. The system then sets up a new CR-LSP with user-requested
bandwidth according to the make-before-break mechanism. After the new hot-standby CR-
LSP is set up, the system switches traffic to this CR-LSP and deletes the hot-standby CR-
LSP with bandwidth at 0 bit/s.
Figure 3-29 Networking diagram for the dynamic bandwidth function of a hot-standby CR-LSP
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
GE1/0/0 GE1/0/0
P1 10.1.1.1/30 10.1.1.2/30 P2
GE3/0/0 GE3/0/0
GE2/0/0 10.2.1.1/30 10.3.1.2/30 GE2/0/0
10.4.1.2/30 10.5.1.1/30
GE2/0/0 GE2/0/0
10.4.1.1/30 10.5.1.2 /30
GE1/0/0 GE1/0/0
PE1 PE2
10.3.1.1/30 10.2.1.2/30
Loopback1 Loopback1
4.4.4.4/32 3.3.3.3/32
: Primary path
: Backup path
: Best-effort path
1. Configure CR-LSP hot standby according to Example for Configuring CR-LSP Hot
Standby.
2. Enable the dynamic bandwidth function for a hot-standby CR-LSP on PE1.
Data Preparation
Data in "Data Preparation" of Example for Configuring CR-LSP Hot Standby

Procedure
Step 1 Configure CR-LSP hot standby.
Configure a primary CR-LSP, a backup CR-LSP, and a best-effort path according to Example
for Configuring CR-LSP Hot Standby.
Step 2 Configure the dynamic bandwidth function for a hot-standby CR-LSP.
# Configure PE1.
[PE1-Tunnel1/0/0] mpls te backup hot-standby dynamic-bandwidth

# After completing the configuration, run the display mpls te tunnel verbose command and the
display mpls te link-administration bandwidth-allocation command on PE1. You can view
that the hot-standby CR-LSP does not occupy bandwidth.
[PE1] display mpls te tunnel verbose
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PrevTunnelIndexInSession: 1 NextTunnelIndexInSession: -
PSB Handle : 1024
Created Time : 2010/02/22 11:29:14
RSVP LSP Type : Primary
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -

IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
No : 2
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PrevTunnelIndexInSession: - NextTunnelIndexInSession: 0
PSB Handle : 1025
Created Time : 2010/02/22 11:29:15
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------

[PE1] display mpls te link-administration bandwidth-allocation
----------------------------------------------------------------------
----------------------------------------------------------------------
0 0 0 0 0 0
1 0 1 0 0 0
2 0 2 0 0 0
3 0 3 0 0 0
4 0 4 0 0 0
5 0 5 0 0 0
6 0 6 0 0 0
7 0 7 0 0 0
8 1 0 0 0 0
9 1 1 0 0 0
10 1 2 0 0 0
11 1 3 0 0 0
12 1 4 0 0 0
13 1 5 0 0 0
14 1 6 0 0 0
15 1 7 0 0 0
----------------------------------------------------------------------

----------------------------------------------------------------------
----------------------------------------------------------------------
0 0 0 0 100000 0
1 0 1 0 100000 0
2 0 2 0 100000 0
3 0 3 0 100000 0
4 0 4 0 100000 0
5 0 5 0 100000 0
6 0 6 0 100000 0
7 0 7 10000 90000 1
8 1 0 0 50000 0
9 1 1 0 50000 0
10 1 2 0 50000 0
11 1 3 0 50000 0
12 1 4 0 50000 0
13 1 5 0 50000 0
14 1 6 0 50000 0
15 1 7 0 50000 0
----------------------------------------------------------------------
# Run the shutdown command on PE1 to shut down the primary CR-LSP.
[PE1] interface gigabitethernet2/0/0

# Run the display mpls te tunnel-interface command on PE1. You can view that the hot-standby
CR-LSP goes Up and is being reestablished after the primary CR-LSP fails.
[PE1-GigabitEthernet1/0/0] display mpls te tunnel-interface
----------------------------------------------------------------
Tunnel1/0/0
----------------------------------------------------------------
Active LSP : Hot-Standby LSP
Session ID : 100
# After the successful reestablishment, run the display mpls te tunnel verbose command and
the display mpls te link-administration bandwidth-allocation command on PE1. You can
view that the hot-standby CR-LSP occupies the bandwidth.
[PE1] display mpls te tunnel verbose
No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
PSB Handle : 1026
Created Time : 2010/02/22 14:22:36
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -


--------------------------------
BFD Information
--------------------------------
[PE1] display mpls te link-administration bandwidth-allocation
----------------------------------------------------------------------
----------------------------------------------------------------------
0 0 0 0 100000 0
1 0 1 0 100000 0
2 0 2 0 100000 0
3 0 3 0 100000 0
4 0 4 0 100000 0
5 0 5 0 100000 0
6 0 6 0 100000 0
7 0 7 10000 90000 1
8 1 0 0 50000 0
9 1 1 0 50000 0
10 1 2 0 50000 0
11 1 3 0 50000 0
12 1 4 0 50000 0
13 1 5 0 50000 0
14 1 6 0 50000 0
15 1 7 0 50000 0
----------------------------------------------------------------------

IPUpdown Link Status : DOWN
PhysicalUpdown Link Status : DOWN
----------------------------------------------------------------------
----------------------------------------------------------------------
0 0 0 0 100000 0
1 0 1 0 100000 0
2 0 2 0 100000 0
3 0 3 0 100000 0
4 0 4 0 100000 0
5 0 5 0 100000 0
6 0 6 0 100000 0
7 0 7 0 100000 0
8 1 0 0 50000 0
9 1 1 0 50000 0
10 1 2 0 50000 0
11 1 3 0 50000 0
12 1 4 0 50000 0
13 1 5 0 50000 0

14 1 6 0 50000 0
15 1 7 0 50000 0
----------------------------------------------------------------------
----End
Configuration Files
l Configuration file of PE1
#
sysname PE1
#
bfd
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 10.3.1.2
next hop 10.5.1.2
next hop 3.3.3.3
#
explicit-path main
next hop 10.4.1.2
next hop 10.2.1.2
next hop 3.3.3.3
#
isis 1
cost-style wide
network-entity 10.0000.0000.0004.00
#
ip address 10.3.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
destination 3.3.3.3


mpls te backup hot-standby dynamic-bandwidth
mpls te commit
#
return
l Configuration file of P1
#
sysname P1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.252

isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
l Configuration file of PE2

#
sysname PE2
#
bfd
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

3.30.28 Example for Configuring TE FRR and CR-LSP Hot Standby

to Implement Combined Protection
This section provides an example for configuring TE FRR and CR-LSP hot standby to implement
combined protection.
Background Information
To protect specific links and nodes on an RSVP-TE tunnel, TE FRR can be configured to provide
local traffic protection, and CR-LSP backup can be established to provide E2E traffic protection.
The following combinations of TE FRR and CR-LSP backup are supported:
l Ordinary combined protection
If a primary CR-LSP's link or node that TE FRR protects fails, the PLR rapidly switches
traffic to a TE FRR bypass CR-LSP and notifies the ingress on the primary CR-LSP of the
fault. In this situation, either CR-LSP hot backup or ordinary CR-LSP backup is used:
– TE FRR and CR-LSP hot standby: After the ingress detects the preceding fault, the
ingress switches the traffic from the TE FRR bypass CR-LSP to the hot-standby CR-
LSP.
– TE FRR and ordinary CR-LSP backup: Only if the primary CR-LSP and TE FRR bypass
CR-LSP both fail, the ingress attempts to establish an ordinary backup CR-LSP and
switches traffic to the ordinary backup CR-LSP.
NOTE
If the primary CR-LSP's node or link that TE FRR does not protect fails, the ingress only establishes
a backup CR-LSP and switches traffic to this CR-LSP.
l Association protection
If a primary CR-LSP fails (that is, a primary CR-LSP is in the FRR-in-use state), the ingress
switches traffic to a TE FRR bypass CR-LSP. The ingress attempts to restore the primary
CR-LSP, while establishing a backup CR-LSP.
For information about how to configure the association of TE FRR and ordinary CR-LSP
backup to protect traffic, see Example for Configuring Synchronization of the Bypass
Tunnel and the Backup CR-LSP. The configuration of the association of TE FRR and
CR-LSP hot standby is the same as that of TE FRR and ordinary CR-LSP backup, except
that a hot-standby CR-LSP must be specified when CR-LSP hot standby is used.
The combined protection of TE FRR and CR-LSP hot standby provides high traffic reliability.
The combined protection of TE FRR and ordinary CR-LSP backup helps efficiently use
bandwidth resources.
The following example describes how to configure TE FRR and CR-LSP hot standby to
implement ordinary combined protection. The configuration of the combined protection of TE
FRR and CR-LSP hot-standby is the same as that of TE FRR and ordinary CR-LSP backup,
except that an ordinary backup mode must be specified when ordinary CR-LSP backup is used.
Networking Description
On the network shown in Figure 3-30, an RSVP-TE tunnel originates from PE1 and is destined
for PE2. To improve traffic reliability, TE FRR can be configured to provide local protection,
and CR-LSP hot standby can be configured to provide E2E traffic protection. The primary CR-
LSP is established over the path PE1 -> P1 -> PE2, a TE FRR bypass CR-LSP is established

over the path P1 -> P2 -> PE2, and a hot-standby CR-LSP is established over the path PE1 ->
P2 -> PE2. To rapidly detect faults, dynamic BFD for CR-LSP is configured to monitor the CR-
LSP that is transmitting traffic.
Figure 3-30 Network diagram for configuring TE FRR and CR-LSP hot standby to implement
ordinary combined protection

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE1/0/0 GE1/0/2 GE1/0/0
10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
PE1 PE2
GE1/0/1 P1
GE1/0/1 10.2.2.1/24 GE1/0/3
10.1.2.1/24 10.2.3.2/24
GE1/0/0
10.2.2.2/24
GE1/0/3
GE1/0/1 10.2.3.1/24
10.1.2.2/24
P2
Loopback0
Primary CR-LSP
4.4.4.4/32
Bypass CR-LSP
Hot-standby CR-LSP
1. Configure an RSVP-TE tunnel.

2. Configure CR-LSP hot standby.
3. Configure TE Auto FRR.
4. Configure dynamic BFD for CR-LSP.
Data Preparation
l IP address of each interface, including each loopback interface, as shown in Figure 3-30
l IS-IS process ID (1), area ID (10.0001), system ID converted using the loopback address
of each node, IS-IS level (Level-2)
l MPLS LSR ID equal to the loopback address of each node
l Name (main-path) of an explicit path over which the primary CR-LSP is established on
PE1.

l RSVP-TE tunnel interface name (Tunnel1/0/0), unnumbered IP address (equal to PE1's

loopback address), tunnel ID (100), and tunnel destination address (3.3.3.3)
Procedure
Assign an IP address and mask to each interface, including each loopback interface, according
to Figure 3-30. For configuration details, see Configuration Files in this section.
Step 2 Configure IS-IS.
Configure IS-IS to advertise the route to each network segment to which each interface is
connected and to advertise the host route to each loopback address which is used as an LSR ID.
Step 3 Configure MPLS, MPLS TE, and MPLS RSVP-TE.
# Configure PE1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] quit
Repeat this step for PE2, P1, and P2. For configuration details, see Configuration Files in this
section.
Step 4 Configure an RSVP-TE tunnel.
# Configure an explicit path for the primary CR-LSP on PE1.

[PE1] explicit-path main-path
[PE1-explicit-path-main-path] next hop 10.1.1.2
[PE1-explicit-path-main-path] next hop 10.2.1.2
[PE1-explicit-path-main-path] quit
# Configure an RSVP-TE tunnel interface.

[PE1] interface Tunnel1/0/0
[PE1-Tunnel1/0/0] ip address unnumbered interface LoopBack0
[PE1-Tunnel1/0/0] mpls te path explicit-path main-path
# Configure PE1.

[PE1-Tunnel1/0/0] mpls te backup hot-standby

Step 6 Configure TE Auto FRR.
# Enable TE Auto FRR and CSPF on P1.

<P1> system-view
[P1] mpls
[P1-mpls] mpls te auto-frr
[P1-mpls] mpls te cspf
[P1-mpls] quit
# Enable TE FRR on the TE tunnel interface on PE1.

Step 7 Configure dynamic BFD for CR-LSP.
# Configure PE1.
[PE1] bfd
[PE1-bfd] quit
# Configure PE2.
<PE2> system-view
[PE2] bfd
[PE2-bfd] quit
# After completing the configuration, run the display mpls te tunnel-interface Tunnel1/0/0
command on PE1. The command output shows that the primary and hot-standby CR-LSPs in
the RSVP-TE tunnel have been established.
[PE1] display mpls te tunnel-interface Tunnel1/0/0
----------------------------------------------------------------
Tunnel1/0/0
----------------------------------------------------------------
Session ID : 100
# Run the display mpls te tunnel path command on PE1 to view information about the primary
and hot-standby CR-LSPs. The Local-Protection available field in the command output shows
that TE FRR has been enabled for the outbound interface on P1 on the primary CR-LSP.
Lsp ID : 1.1.1.1 :100 :3

Hop Information
Hop 0 10.1.1.1
Hop 1 10.1.1.2 Label 900007
Hop 2 2.2.2.2 Label 900007
Hop 4 10.2.1.2 Label 3
Hop 5 3.3.3.3 Label 3

Lsp ID : 1.1.1.1 :100 :32775
Hop Information
Hop 0 10.1.2.1
Hop 1 10.1.2.2 Label 1028
Hop 2 4.4.4.4 Label 1028
Hop 3 10.2.3.1
Hop 4 10.2.3.2 Label 3
Hop 5 3.3.3.3 Label 3
# Run the display mpls te auto-tunnel auto-bypass-tunnel command on P1. A TE Auto FRR
bypass CR-LSP has been established on P1.
[P1] display mpls te auto-tunnel auto-bypass-tunnel
List of auto-bypass-tunnels:
Tunnel0/0/4097
Total Num: 1
# Run the display mpls bfd session command on PE1 to view information about the BFD session
that monitors the RSVP-TE tunnel.
[PE1] display mpls bfd session
-------------------------------------------------------------------------------
BFD Information: TE TUNNEL
-------------------------------------------------------------------------------
3.3.3.3 8196 GE1/0/0 10.1.1.2 Tun1/0/0 Up
# When the primary CR-LSP is working properly, run the tracert lsp te Tunnel 1/0/0 command
on PE1. The command output shows that traffic is transmitting along the primary CR-LSP.
break.
0 Ingress 10.1.1.2/[900007 ]
1 10.1.1.2 100 ms Transit 10.2.1.2/[3 ]
2 3.3.3.3 120 ms Egress
If a link between P1 and PE2 fails, run the tracert lsp te Tunnel 1/0/0 command on PE1. The
command output shows that P1 forwards traffic to the bypass CR-LSP.
break.
0 Ingress 10.1.1.2/[900007 ]
1 10.1.1.2 100 ms Transit 10.2.2.2/[3 1029 ]
2 10.2.2.2 80 ms Transit 10.2.3.2/[3 ]
3 3.3.3.3 110 ms Egress
A few seconds later, run the tracert lsp te Tunnel 1/0/0 command on PE1. The command output
shows that P1 has switched traffic to the hot-standby CR-LSP.
break.

0 Ingress 10.1.2.2/[1031 ]
1 10.1.2.2 110 ms Transit 10.2.3.2/[3 ]
2 3.3.3.3 80 ms Egress
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path main-path
next hop 10.1.1.2
next hop 10.2.1.2
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0010.0100.1001.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 3.3.3.3
mpls te bfd enable
mpls te path explicit-path main-path
mpls te backup hot-standby
mpls te commit
#
return

#
sysname P1
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0020.0200.2002.00
traffic-eng level-2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.2.2.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0040.0400.4004.00
traffic-eng level-2
#
undo shutdown
ip address 10.2.2.2 255.255.255.0
isis enable 1
mpls
mpls te

mpls rsvp-te
#
undo shutdown
ip address 10.1.2.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.2.3.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
bfd
mpls-passive
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0001.0030.0300.3003.00
traffic-eng level-2
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.2.3.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

3.30.29 Example for Configuring Synchronization of the Bypass

Tunnel and the Backup CR-LSP
This section provides an example for configuring synchronization of the bypass CR-LSP and
backup CR-LSP. When the primary CR-LSP fails (in the FRR-in-use state), the system uses a
TE FRR bypass tunnel and attempts to restore the primary CR-LSP and simultaneously establish
a backup CR-LSP.
On the network shown in Figure 3-31, a primary tunnel is set up by using the explicit path LSRA
--> LSRB --> LSRC. A TE FRR bypass tunnel is set up on the transit LSRB along the path
LSRB --> LSRE --> LSRC; an ordinary CR-LSP is set up on the ingress LSRA along the path
LSRA --> LSRC.
After the link between LSRB and LSRC is faulty, the system starts the TE FRR bypass tunnel
(the primary CR-LSP is in FRR-in-use state) and tries to restore the primary CR-LSP. At the
same time, the system tries to set up the backup CR-LSP.
Figure 3-31 Networking diagram for configuring synchronization of the bypass tunnel and the
backup CR-LSP

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE3/0/0 GE2/0/0 GE3/0/0

LSRA LSRC
2.1.1.2/24 3.1.1.1/24 3.1.1.2/24
GE1/0/0 GE2/0/0 LSRB GE1/0/0
10.1.1.2/24 2.1.1.1/24 GE1/0/0 10.1.1.1/24
Loopback1 GE2/0/0
3.2.1.1/24 4.4.4.4/32 4.1.1.2/24
GE3/0/0 GE2/0/0
3.2.1.2/24 4.1.1.1/24
LSRD
1. On the ingress LSRA, set up a primary tunnel destined for LSRC.

2. On the transit LSRB, set up a TE FRR bypass tun.nel along the path LSRB --> LSRE -->
LSRC to protect the link between LSRB and LSRC.
3. On the ingress LSRA, set up an ordinary CR-LSP along the path LSRA --> LSRC.
4. Configure synchronization of the bypass tunnel and the backup CR-LSP in the tunnel
interface view.

Data Preparation
l An IGP and its parameters

l Maximum reservable bandwidth for the link and the BC bandwidth
l Explicit paths of the primary CR-LSP and the backup CR-LSP
l TE FRR protection mode and the protected links or nodes
l Name and IP address of the primary tunnel interface, destination address, tunnel ID, tunnel
signaling protocol (RSVP-TE), and tunnel bandwidth
Procedure
Step 1 Configure the IP address for each interface.
Configure the IP address and mask for each interface including each Loopback interface as
shown in Figure 3-31. For configuration details, see Configuration Files in this section.
Step 2 Enable an IGP.
Enable OSPF or IS-IS on each LSR to ensure connectivity between devices. The example in this
document uses OSPF as IGP. For configuration details, see Configuration Files in this section.
On each LSR, configure an LSR ID and enable MPLS in the system and interface views. For
On each LSR, enable MPLS-TE and MPLS RSVP-TE in the MPLS view and interface views
of the link. Set the maximum reservable bandwidth of the link to 100 Mbit/s and the bandwidth
of BC0 to 100 Mbit/s. For configuration details, see Configuration Files in this section.
Step 5 Enable OSPF TE and configure the CSPF.
Enable OSPF TE on each LSR and configure the CSPF on LSRA and LSRB. For configuration
details, see Configuring the RSVP-TE Tunnel.
Step 6 Configure the explicit paths of the primary and backup CR-LSPs.
# Configure the explicit path of the primary CR-LSP on LSRA.

[LSRA] explicit-path master
# Configure the explicit path of the backup CR-LSP on LSRA.

[LSRA] explicit-path backup
[LSRA-explicit-path-backup] next hop 10.1.1.1
Step 7 Configure the tunnel interface.
# Create a tunnel interface on LSRA, specify an explicit path for the primary tunnel, and set the
tunnel bandwidth to 20 Mbit/s.
[LSRA-Tunnel2/0/0] ip address unnumbered interface loopback1


[LSRA-Tunnel2/0/0] mpls te record-route label
[LSRA-Tunnel2/0/0] mpls te path explicit-path master
Step 8 Enable TE Auto FRR and configure link protection.

# Configure LSRA.
[LSRA-Tunnel2/0/0] mpls te fast-reroute
# Configure LSRB.
[LSRB] interface gigabitethernet2/0/0
[LSRB-GigabitEthernet2/0/0] mpls te auto-frr link
After the configurations, run the display mpls te tunnel path lsp-id 1.1.1.1 1 1 command on
LSRA. The bypass tunnel is set up successfully.
[LSRA] display mpls te tunnel path lsp-id 1.1.1.1 1 1
Lsp ID : 1.1.1.1 :1 :1
Hop Information
Hop 0 2.1.1.1
Hop 1 2.1.1.2 Label 11264
Hop 2 2.2.2.2 Label 11264
Hop 4 3.1.1.2 Label 3
Hop 5 3.3.3.3 Label 3
Step 9 Configure an ordinary CR-LSP and specify its explicit path.

# Configure LSRA.
[LSRA-Tunnel2/0/0] mpls te backup ordinary
[LSRA-Tunnel2/0/0] mpls te path explicit-path backup secondary
Step 10 Configure synchronization of the bypass tunnel and the backup CR-LSP on the ingress LSRA
of the primary CR-LSP.
# Configure LSRA.
[LSRA-Tunnel2/0/0] mpls te backup frr-in-use
Run the display mpls te tunnel-interface tunnel2/0/0 command on the ingress LSRA to view
information about the primary CR-LSP.
[LSRA] display mpls te tunnel-interface tunnel2/0/0
----------------------------------------------------------------
Tunnel2/0/0
----------------------------------------------------------------

Session ID : 1

# Disable the outbound interface that is protected on LSRB.
# Configure the affinity property of the tunnel on LSRA.

[LSRA-Tunnel2/0/0] mpls te affinity property f0 mask ff secondary
Run the display mpls te tunnel-interface command on LSRA. The tunnel status is Up. The
primary tunnel is in FRR-in-use state; the ordinary CR-LSP is being set up; the primary CR-
LSP is being restored.
----------------------------------------------------------------
Tunnel2/0/0
----------------------------------------------------------------
Session ID : 1
Modify LSP State : SETTING UP LSP ID : 6
Ordinary LSP State : DOWN
When the primary CR-LSP is faulty (the primary CR-LSP is in FRR-in-use state), the system
starts the TE FRR bypass tunnel and tries to restore the primary CR-LSP. At the same time, the
system tries to set up a backup CR-LSP.
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 2.1.1.2
next hop 3.1.1.2
#
next hop 10.1.1.2

undo shutdown
ip address 2.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
destination 3.3.3.3
mpls te tunnel-id 1
mpls te affinity property f0 mask ff secondary
mpls te backup ordinary
mpls te backup frr-in-use
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 2.1.1.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 3.2.1.1 255.255.255.0
mpls

mpls te
mpls rsvp-te
#
undo shutdown
ip address 3.1.1.1 255.255.255.0
mpls
mpls te
mpls te auto-frr link
mpls rsvp-te
#
interface LoopBack0
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 2.1.1.0 0.0.0.255
network 3.1.1.0 0.0.0.255
network 3.2.1.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 4.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 3.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0

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 3.1.1.0 0.0.0.255
network 4.1.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRE
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
undo shutdown
ip address 4.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
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 3.2.1.0 0.0.0.255
network 4.1.1.0 0.0.0.255
mpls-te enable
#
return
3.30.30 Example for Configuring RSVP GR

This section provides an example for configuring RSVP GR to implement uninterrupted MPLS
forwarding during the AMB/SMB switchover.
On the network shown in Figure 3-32, LSRA, LSRB, and LSRC are equipped with dual main
control boards. Three LSRs learn routes from one another using the IS-IS protocol and then use
the RSVP protocol to establish a TE tunnel from LSRA to LSRC.

RSVP GR is required to ensure that MPLS forwarding is not interrupted when ae master/slave
switchover of main control boards occurs on LSRA, LSRB, or LSRC.
Figure 3-32 Networking diagram for RSVP-TE GR

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.1.2/24 20.1.1.1/24 20.1.1.2/24
LSRA LSRB LSRC
1. Assign IP addresses to interfaces on each LSR and loopback addresses that function as the
LSR IDs.
2. Configure the IS-IS protocol and enable IS-IS TE.
3. Configure LSR IDs.
4. Enable MPLS, MPLS TE, and MPLS RSVP-TE globally.
5. Enable MPLS, MPLS TE, and MPLS RSVP-TE on each interface, and configure bandwidth
attributes of the MPLS TE link.
6. Enable MPLS CSPF on the ingress node. Create the tunnel interface at the ingress node.
Specify the tunnel IP address, tunnel protocol, destination address, tunnel ID, and signaling
protocol.
7. Enable IS-IS GR on each node.
8. Enable RSVP GR on all RSVP enabled interfaces of each node.
Data Preparation
l IP addresses of interfaces on each node

l IS-IS network entity and IS-IS level which each node belongs to
l MPLS LSR ID of each node
l Bandwidth attributes of links along the tunnel
l Tunnel interface number of the Ingress node, tunnel ID, and tunnel bandwidth
Procedure
Step 1 Assign IP addresses to interfaces on each LSR. For configuration details, see Configuration
Step 2 Configure basic IS-IS functions.
# Configure LSRA.

[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] quit
LSRs have learned routes from each other.
Step 3 Configure basic MPLS capability and enable MPLS TE, RSVP-TE, and CSPF. Configure
maximum bandwidth and maximum reservable bandwidth of interfaces.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] mpls te


[LSRB-mpls] quit
[LSRB-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRB-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] mpls te
[LSRC-mpls] quit
Step 4 Configure IS-IS TE and enable IS-IS GR.

# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] is-name LSRA
[LSRA-isis-1] graceful-restart
[LSRA-isis-1] quit
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] is-name LSRB
[LSRB-isis-1] graceful-restart
[LSRB-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] is-name LSRC
[LSRC-isis-1] graceful-restart
[LSRC-isis-1] quit

# Configure an MPLS TE tunnel on LSRA.


interface status of the MPLS TE tunnel is Up.
[LSRA] display interface tunnel
Last up time: 2007-10-29, 16:35:10
Description : Tunnel1/0/0 Interface
...
Step 6 Enable RSVP GR.

# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls rsvp-te hello
[LSRA-mpls] mpls rsvp-te hello full-gr
[LSRA-mpls] quit
[LSRA-GigabitEthernet1/0/0] mpls rsvp-te hello
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] mpls rsvp-te hello
[LSRB-mpls] mpls rsvp-te hello full-gr
[LSRB-mpls] quit
[LSRB-GigabitEthernet1/0/0] mpls rsvp-te hello
[LSRB-GigabitEthernet2/0/0] mpls rsvp-te hello
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] mpls rsvp-te hello
[LSRC-mpls] mpls rsvp-te hello full-gr
[LSRC-mpls] quit
[LSRC-GigabitEthernet2/0/0] mpls rsvp-te hello

After completing the configuration, run the display mpls rsvp-te graceful-restart command
on LSRB to view the local GR status, restart time, and recovery time.
[LSRB] display mpls rsvp-te graceful-restart
Display Mpls Rsvp te graceful restart information
LSR ID: 2.2.2.2
Graceful-Restart Capability: GR-Self GR-Support
GR Status: Gracefully Restart Not going on
Number of Restarting neighbors: 0
Number of LSPs recovered: 0
Received Gr Path message count: 0
Send Gr Path message count: 0
Received RecoveryPath message count: 0
Send RecoveryPath message count: 0
Run the display mpls rsvp-te graceful-restart peer command on LSRB to view the GR status
of the neighboring LSR.
[LSRB] display mpls rsvp-te graceful-restart peer

Neighbor on Interface GigabitEthernet1/0/0

SrcInstance: 47860 NbrSrcInstance: 49409
Neighbor Capability:
Can Do Self GR
Can Support GR
GR Status: Normal
Stored GR message number: 0
Total to be Recover PSB Count: 0 Recovered PSB Count: 0
Total to be Recover RSB Count: 0 Recovered RSB Count: 0
P2MP PSB Count: 0 P2MP RSB Count: 0
Total to be Recover P2MP PSB Count: 0 Recovered P2MP PSB Count: 0
Total to be Recover P2MP RSB Count: 0 Recovered P2MP RSB Count: 0
If a master/slave switchover is performed, during the graceful restart, Tunnel 1/0/0 keeps up.
Run the display this interface command on LSRA. The Tunnel up/down statistics value is 0,
indicating that the tunnel has never flapped.
[LSRA-Tunnel1/0/0] display this interface
Last line protocol up time : 2010-07-13 16:10:09
Description: Tunnel1/0/0 Interface
Internet protocol processing : disabled
...
# Run the slave switchover command on LSRB to forcibly perform a master/slave switchover
of main control boards.
[LSRB] slave switchover enable
[LSRB] slave switchover
Caution!!! Confirm switch slave to master[Y/N] ?
[LSRB] y
Run the display this interface command on LSRA again to view that the value of Tunnel up/
down statistics is still 0, indicating that the tunnel did not flap after the master/slave switchover
of main control boards on LSRB. This means that RSVP GR has been configured successfully.
[LSRA-Tunnel1/0/0] display this interface
Last line protocol up time : 2010-07-13 16:13:53
Description: Tunnel1/0/0 Interface
Internet protocol processing : disabled
...
----End

Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
mpls rsvp-te hello
#
isis 1
graceful-restart
is-level level-2
cost-style wide
is-name LSRA
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-2
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 3.3.3.3
mpls te commit
#
return

#
sysname LSRB
#
slave switchover enable
slave switchover
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
isis 1
graceful-restart
is-level level-2
cost-style wide
is-name LSRB
network-entity 00.0005.0000.0000.0002.00
traffic-eng level-2

#
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
ip address 20.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
isis 1
graceful-restart
is-level level-2
cost-style wide
is-name LSRC
network-entity 00.0005.0000.0000.0003.00
traffic-eng level-2
#
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return
3.30.31 Example for Configuring Static BFD for CR-LSP

This section provides an example for configuring static BFD for CR-LSP after hot standby is
enabled and a best-effect path is established on a tunnel.

Figure 3-33 illustrates the CR-LSP hot standby networking. A TE tunnel with the ingress PE1
and egress PE2 is established on PE1. Hot standby and a best-effort LSP are configured for the
tunnel. If the primary CR-LSP fails, traffic switches to the backup CR-LSP. After the primary
CR-LSP recovers, traffic switches back to the primary CR-LSP after a 15–second delay. If both
the primary and the backup CR-LSPs fail, traffic switches to the best-effort LSP.
Two static BFD sessions must be set up to monitor the primary and backup CR-LSPs. After
static BFD is configured for CR-LSPs, the following objectives are achieved:
l If the primary CR-LSP fails, traffic switches to the backup CR-LSP within milliseconds.
l If the backup CR-SLP fails within 15 seconds after the primary CR-LSP recovers, traffic
switches back to the primary CR-LSP.

Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
GE1/0/0 GE1/0/0
P1 10.1.1.1/30 10.1.1.2/30 P2
GE3/0/0 GE3/0/0
GE2/0/0 10.2.1.1/30 10.3.1.2/30 GE2/0/0
10.4.1.2/30 10.5.1.1/30
GE2/0/0 GE2/0/0
10.4.1.1/30 10.5.1.2 /30
GE1/0/0 GE1/0/0
PE1 PE2
10.3.1.1/30 10.2.1.2/30
Loopback1 Loopback1
4.4.4.4/32 3.3.3.3/32
: Primary path
: Backup path
: Best-effort path
1. Configure CR-LSP hot standby based on Example for Configuring CR-LSP Hot.
2. On PE1, create two BFD sessions and bind one to the primary CR-LSP and the other to
backup CR-LSP; on PE2, create two BFD sessions and bind both sessions to the IP link
(PE2 --> PE1).

Data Preparation
l BFD session name, local discriminator, and remote discriminator
l Minimum intervals at which BFD packets are sent and received
l Local BFD detection multiplier
l For other data, see Example for Configuring CR-LSP Hot Standby.
Procedure
Configure the primary CR-LSP, backup CR-LSP, and best-effort path according to Example
for Configuring CR-LSP Hot Standby.
Step 2 Configuring BFD for CR-LSP.
# Create BFD sessions on PE1 and PE2 to monitor the primary and backup CR-LSPs. Bind one
BFD session on PE1 to the primary CR-LSP and the other to the backup CR-LSP; bind the BFD
session on PE2 to the IP link. Set the minimum intervals at which BFD packets are sent and
received to 100 milliseconds and the local BFD detection multiplier to 3.
# Configure PE1.
[PE1] bfd
[PE1-bfd] quit
[PE1] bfd mainlsptope2 bind mpls-te interface tunnel1/0/0 te-lsp
[PE1-bfd-lsp-session-mainlsptope2] discriminator local 413
[PE1-bfd-lsp-session-mainlsptope2] discriminator remote 314
[PE1-bfd-lsp-session-mainlsptope2] min-tx-interval 100
[PE1-bfd-lsp-session-mainlsptope2] min-rx-interval 100
[PE1-bfd-lsp-session-mainlsptope2] detect-multiplier 3
[PE1-bfd-lsp-session-mainlsptope2] process-pst
[PE1-bfd-lsp-session-mainlsptope2] commit
[PE1-bfd-lsp-session-mainlsptope2] quit
[PE1] bfd backuplsptope2 bind mpls-te interface tunnel1/0/0 te-lsp backup
[PE1-bfd-lsp-session-backuplsptope2] discriminator local 423
[PE1-bfd-lsp-session-backuplsptope2] discriminator remote 324
[PE1-bfd-lsp-session-backuplsptope2] min-tx-interval 100
[PE1-bfd-lsp-session-backuplsptope2] min-rx-interval 100
[PE1-bfd-lsp-session-backuplsptope2] detect-multiplier 3
[PE1-bfd-lsp-session-backuplsptope2] process-pst
[PE1-bfd-lsp-session-backuplsptope2] commit
[PE1-bfd-lsp-session-backuplsptope2] quit
# Configure PE2.
[PE2] bfd
[PE2-bfd] quit
[PE2] bfd mainlsptope2 bind peer-ip 4.4.4.4
[PE2-bfd-lsp-session-mainlsptope2] discriminator local 314
[PE2-bfd-lsp-session-mainlsptope2] discriminator remote 413
[PE2-bfd-lsp-session-mainlsptope2] min-tx-interval 100
[PE2-bfd-lsp-session-mainlsptope2] min-rx-interval 100
[PE2-bfd-lsp-session-mainlsptope2] detect-multiplier 3
[PE2-bfd-lsp-session-mainlsptope2] commit
[PE2-bfd-lsp-session-mainlsptope2] quit
[PE2] bfd backuplsptope2 bind peer-ip 4.4.4.4
[PE2-bfd-lsp-session-backuplsptope2] discriminator local 324
[PE2-bfd-lsp-session-backuplsptope2] discriminator remote 423
[PE2-bfd-lsp-session-backuplsptope2] min-tx-interval 100

[PE2-bfd-lsp-session-backuplsptope2] min-rx-interval 100

[PE2-bfd-lsp-session-backuplsptope2] detect-multiplier 3
[PE2-bfd-lsp-session-backuplsptope2] commit
[PE2-bfd-lsp-session-backuplsptope2] quit
# Run the display bfd session discriminator local-discriminator-value command on PE1 and
PE2. The command output shows that the status of BFD sessions is Up.
[PE1] display bfd session discriminator 413
--------------------------------------------------------------------------------
Local Remote PeerIpAddr InterfaceName State Type
--------------------------------------------------------------------------------
413 314 3.3.3.3 Tunnel1/0/0 Up S_TE_LSP
--------------------------------------------------------------------------------
[PE1] display bfd session discriminator 423
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
423 324 3.3.3.3 Tunnel1/0/0 Up S_TE_LSP
--------------------------------------------------------------------------------

for port 2 into port 1. After the cable is removed from GE 2/0/0 on PE1 or P1, the fault is rectified
within milliseconds.
After the cable is reconnected to GE 2/0/0 and the cable is removed from GE 1/0/0 on PE1 within
15 seconds, the fault is rectified within milliseconds.
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 4.4.4.4
mpls
lsp-trigger all
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 10.3.1.2
next hop 10.5.1.2
next hop 3.3.3.3
#
explicit-path main
next hop 10.4.1.2
next hop 10.2.1.2
next hop 3.3.3.3
#
isis 1
cost-style wide
network-entity 10.0000.0000.0004.00
#

ip address 10.3.1.1 255.255.255.252

isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
destination 3.3.3.3
mpls te commit
#
bfd backuplsptope2 bind mpls-te interface Tunnel1/0/0 te-lsp backup
min-tx-interval 100
min-rx-interval 100
process-pst
commit
#
bfd mainlsptope2 bind mpls-te interface Tunnel1/0/0 te-lsp
min-tx-interval 100
min-rx-interval 100
process-pst
commit
#
return
#
sysname P1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#

ip address 10.1.1.1 255.255.255.252

isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#

interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
bfd
#
mpls lsr-id 3.3.3.3
mpls
lsp-trigger all
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bfd backuplsptope2 bind peer-ip 4.4.4.4
min-tx-interval 100
min-rx-interval 100
commit
#
bfd mainlsptope2 bind peer-ip 4.4.4.4
min-tx-interval 100
min-rx-interval 100
commit
#
return
3.30.32 Example for Configuring Static BFD for TE

This section provides an example for configuring BFD for TE to monitor the primary tunnel.
This enables a VPN to quickly detect faults in a tunnel and perform a traffic switchover to reduce
the fault duration.

Figure 3-34 illustrates an MPLS network, on which a switch (a Layer 2 device) exists between
PE1 and PE2. PVPN FRR and an MPLS TE tunnel are configured on PE1. The primary path of
VPN FRR is PE1 → Switch → PE2, and the backup path of VPN FRR is PE1 → PE3. If the
primary path fails, VPN traffic switches to the backup path. BFD for TE is configured monitor
the TE tunnel over the primary path and enable VPN to rapidly detect tunnel faults. Traffic can
rapidly switch between the primary and backup paths when necessary, and the fault recovery
time is shortened.
Figure 3-34 Networking diagram for static BFD for TE

Loopback1
2.2.2.2/32
0/0
S1/
PO .2/30
.1
10.1
el PE3
0/0
S1/ /30 ry tunn
O a
P .1 ond
.1.1 Sec
CE1 PE1 10
CE2
Prim
GE2 a
ry tun
/0/0 nel
10.2 PE2
.1.1/2
Loopback1 4
G
1.1.1.1/32 Switch 10 E2/0/0
.2.1.
2/24
Loopback1
3.3.3.3/32
NOTE
For simplicity, the IP addresses of interfaces connecting PEs to CEs are not shown in Figure 3-34.
1. Configure basic MPLS functions, and establish bidirectional TE tunnels between PE1 and
PE2, and between PE1 and PE3.
2. Configure VPN FRR.
3. Enable global BFD on PE1, PE2, and PE3.
4. Configure a BFD session on PE1 to detect the TE tunnel over the primary path.
5. Configure one BFD session each on PE2 and PE3 and specify the TE tunnel as the BFD
backward channel.
Data Preparation

l Type of an IGP and data required for configuring an IGP

l BGP AS number and interfaces for BGP sessions
l MPLS LSR ID
l Maximum reservable bandwidth and BC bandwidth of the outbound interfaces of links
along the tunnel
l Tunnel interface number, bandwidth for the tunnel, and explicit paths
l VPN instance name, RD, and route target (RT)
l Tunnel policy name
l Data required for configuring VPN FRR, such as IP prefix name and routing policy name
l BFD name, local discriminator, and remote discriminator
Procedure
Assign an IP address and mask to each interface according to Figure 3-34, create loopback
interfaces on LSRs, and configure IP addresses of the loopback interfaces as MPLS LSR IDs.
Step 2 Configure the switch.
Configure the switch so that PE1 and PE2 can communicate with each other. For configuration
Configure OSPF or IS-IS on each LSR so that PE1 and PE2, and PE1 and PE3 can communicate.
In this example, OSPF is used. For configuration details, see Configuration Files in this section.
Configure the LSR ID and enable MPLS in the system view on each LSR and enable MPLS in
the interface view. For configuration details, see Configuration Files in this section.
Enable MPLS-TE and MPLS RSVP-TE in the MPLS and interface views on each LSR. Set the
maximum reservable bandwidth for the MPLS TE on the outbound interfaces of links along the
tunnel to 100 Mbit/s and the BC bandwidth to 100 Mbit/s. For configuration details, see
Step 6 Configure OSPF TE and CSPF.
Configure OSPF TE on each LSR and CSPF on PE1. For configuration details, see Configuring
the RSVP-TE Tunnel.
Step 7 Configure the tunnel interface.
# Specify two explicit paths on PE1 and one each on PE2 and PE3.
# Configure PE1.
<PE1> system-view
[PE1] explicit-path tope2
[PE1-explicit-path-tope2] next hop 10.2.1.2

[PE1-explicit-path-tope2] quit
# Configure PE2.
<PE2> system-view
# Configure PE3.
<PE3> system-view
# Create two tunnel interfaces on PE1 and one each on PE2 and PE3, specify explicit paths and
set the tunnel bandwidth to 10 Mbit/s. Bind the tunnel to the specified VPN.
# Configure PE1.
[PE1-Tunnel2/0/0] mpls te path explicit-path tope2
[PE1-Tunnel2/0/0] mpls te reserved-for-binding
# Configure PE2.
# Configure PE3.


# Run the display mpls te tunnel-interface tunnel interface-number command on PEs The
status of Tunnel 1/0/0 and Tunnel 2/0/0 on PE1, Tunnel 2/0/0 on PE2, and Tunnel 1/0/0 on PE3
is Up.
Step 8 Configure VPN FRR.
# Create one VPN instance each on PE1, PE2, and PE3. Set all VPN instance names to vpn1;
set the RDs to 100:1, 100:2, and 100:3, separately, and set all RTs to 100:1. Configure CEs to
access PEs. The configuration details are not provided here.
# Establish an MP IBGP peer relationship between PE1 and PE2, and between PE1 and PE3.
The BGP AS number for all of the PEs is 100. The loopback interface Loopback1 is used to set
up BGP sessions. For configuration details, see Configuration Files in this section.
# Configure tunnel policies for PE1, PE2, and PE3 and apply the policies to the VPN instances.
# Configure PE1.
[PE1] tunnel-policy policy1
[PE1-tunnel-policy-policy1] tunnel binding destination 3.3.3.3 te tunnel 2/0/0
[PE1-tunnel-policy-policy1] quit
[PE1] ip vpn-instance vpn1
[PE1-ip-vpn-instance-vpn1] ipv4-family
[PE1-ip-vpn-instance-vpn1-af-ipv4] tnl-policy policy1
[PE1-ip-vpn-instance-vpn1-af-ipv4] quit
[PE1-ip-vpn-instance-vpn1] quit
# Configure PE2.
# Configure PE3.
# Configure VPN FRR on PE1.

[PE1] ip ip-prefix vpn_frr_list permit 3.3.3.3 32
[PE1] route-policy vpn_frr_rp permit node 10
[PE1-route-policy] if-match ip next-hop ip-prefix vpn_frr_list
[PE1-route-policy] apply backup-nexthop 2.2.2.2
[PE1-route-policy] quit
[PE1-vpn-instance-vpn1] ipv4-family

[PE1-vpn-instance-vpn1-af-ipv4] vpn frr route-policy vpn_frr_rp

[PE1-vpn-instance-vpn1-af-ipv4] quit
[PE1-vpn-instance-vpn1] quit
# With these configurations, CEs can communicate with each other, and traffic passes through
PE1, switch, and PE2. After the cable of any interface connecting PE1 and PE2 is removed, or
the switch or PE2 fails, VPN traffic switches to the backup path PE1 → PE3. Fault recovery
takes about as long as IGP convergence.
Step 9 Configure BFD for TE.
# Configure a BFD session on PE1 to monitor the TE tunnel of the primary path. Set the minimum
interval at which BFD packets are sent and received to 100 milliseconds and the local BFD
detection multiplier to 3.
[PE1] bfd
[PE1-bfd] quit
[PE1] bfd test bind mpls-te interface tunnel2/0/0
[PE1-bfd-lsp-session-test] discriminator local 12
[PE1-bfd-lsp-session-test] discriminator remote 21
[PE1-bfd-lsp-session-test] min-tx-interval 100
[PE1-bfd-lsp-session-test] min-rx-interval 100
[PE1-bfd-lsp-session-test] detect-multiplier 3
[PE1-bfd-lsp-session-test] process-pst
[PE1-bfd-lsp-session-test] commit
# Configure a BFD session on PE2 and specify the TE tunnel as the BFD revese channel. Set
the minimum interval at which BFD packets are sent and received to 100 milliseconds and the
local BFD detection multiplier to 3.
[PE2] bfd
[PE2-bfd] quit
[PE2] bfd test bind mpls-te interface tunnel2/0/0
[PE2-bfd-lsp-session-test] discriminator local 21
[PE2-bfd-lsp-session-test] discriminator remote 12
[PE2-bfd-lsp-session-test] min-tx-interval 100
[PE2-bfd-lsp-session-test] min-rx-interval 100
[PE2-bfd-lsp-session-test] detect-multiplier 3
[PE2-bfd-lsp-session-test] commit
# Run the display bfd session { all | discriminator discr-value | mpls-te | [ slot slot-id ]
[ verbose ] command on PE1 and PE2. The status of the BFD sessions is Up.
Connect port 1 and port 2 on a tester to CE1 and CE2, respectively. Inject MPLS traffic destined
for port 2 into port 1. After a cable is removed, fault is rectified within milliseconds.
----End
Configuration Files
NOTE
Configuration files for CE1, CE2, and switch are not listed here. Configurations related to CEs accessing
PEs are also not listed.
#
sysname PE1
#
ip vpn-instance vpn1
ipv4-family

vpn frr route-policy vpn_frr_rp
tnl-policy policy1
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path tope2
next hop 10.2.1.2
next hop 3.3.3.3
#
explicit-path tope3
next hop 10.1.1.2
next hop 2.2.2.2
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 2.2.2.2
mpls te path explicit-path tope3
mpls te reserved-for-binding
mpls te commit
#
destination 3.3.3.3
mpls te commit
#
bgp 100


#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
import-route direct
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
mpls-te enable
#
route-policy vpn_frr_rp permit node 10
if-match ip next-hop ip-prefix vpn_frr_list
apply backup-nexthop 2.2.2.2
#
ip ip-prefix vpn_frr_list permit 3.3.3.3 32
#
tunnel-policy policy1
#
bfd test bind mpls-te interface Tunnel2/0/0
min-tx-interval 100
min-rx-interval 100
process-pst
commit
#
#
return

#
sysname PE2
#
ipv4-family
tnl-policy policy1
#
bfd
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path tope1
next hop 10.2.1.1
next hop 1.1.1.1

#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
destination 1.1.1.1
mpls te commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.2.1.0 0.0.0.255
network 3.3.3.3 0.0.0.0
mpls-te enable
#
#
bfd test bind mpls-te interface Tunnel2/0/0
min-tx-interval 100
min-rx-interval 100
commit
#
return

#
sysname PE3
#
ipv4-family
tnl-policy policy1

#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path tope1
next hop 10.1.1.1
next hop 1.1.1.1
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
destination 1.1.1.1
mpls te commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
mpls-te enable
#
#
return
3.30.33 Example for Configuring Dynamic BFD for CR-LSP

This section provides an example for configuring dynamic BFD for CR-LSP after hot standby
is enabled and a best-effect LSP is established in a tunnel.

Figure 3-35 illustrates the CR-LSP hot standby networking. A TE tunnel is established between
PE1 and PE2. Hot standby and a best-effort LSP is configured for the tunnel. If the primary CR-
LSP fails, traffic can be switched to the backup CR-LSP. After the primary CR-LSP recovers,
traffic can be switched back to the primary CR-LSP in 15 seconds. If both the primary and
backup CR-LSPs fail, traffic can be switched to the best-effort LSP.
Dynamic BFD for CR-LSP is required to detect the primary and backup CR-LSPs. After the
configuration, the following objects should be achieved:
l If the primary CR-LSP fails, traffic can be switched to the backup CR-LSP at the
millisecond level.
l If the backup CR-LSP fails within 15 seconds after the primary CR-LSP recovers, traffic
is switched back to the primary CR-LSP.
NOTE
Compared with static BFD, dynamic BFD is simpler in terms of configurations. In addition, dynamic BFD
can reduce the number of BFD sessions, and use less network resources because only one BFD session can
be created on a tunnel interface.

Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
GE1/0/0 GE1/0/0
P1 10.1.1.1/30 10.1.1.2/30 P2
GE3/0/0 GE3/0/0
GE2/0/0 10.2.1.1/30 10.3.1.2/30 GE2/0/0
10.4.1.2/30 10.5.1.1/30
GE2/0/0 GE2/0/0
10.4.1.1/30 10.5.1.2 /30
GE1/0/0 GE1/0/0
PE1 PE2
10.3.1.1/30 10.2.1.2/30
Loopback1 Loopback1
4.4.4.4/32 3.3.3.3/32
: Primary path
: Backup path
: Best-effort path

1. Configure CR-LSP hot standby based on Example for Configuring CR-LSP Hot.
2. Enable BFD on the ingress of the tunnel. Configure MPLS TE BFD. Set the minimum
interval at which BFD packets are sent and received, and the local BFD detection multiplier.
3. Enable the capability of passively creating BFD sessions on the egress.
Data Preparation
l Minimum intervals at which BFD packets are sent and received on the ingress (The default
values are specified in the License.)
l Local BFD detection multiplier (The default values are specified in the License.)
l For other data, see Example for Configuring CR-LSP Hot Standby
Procedure
Configure the primary CR-LSP, backup CR-LSP, and best-effort LSP based on Example for
Configuring CR-LSP Standby.
Step 2 Enable BFD on the ingress of the tunnel and configure MPLS TE BFD.
# Enable MPLS TE BFD on the tunnel interface of PE1. Set the minimum intervals at which
BFD packets are sent and received to 100 milliseconds and the local BFD detection multiplier
to 3.
<PE1> system-view
[PE1] bfd
[PE1-bfd] quit
[PE1-Tunenl1/0/0] mpls te bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 3
[PE1-Tunenl1/0/0] mpls te commit
Step 3 Enable the capability of passively creating BFD sessions on the egress of the tunnel.
<PE2> system-view
[PE2] bfd
[PE2-bfd] quit
# Run the display bfd session discriminator local-discriminator-value command on PE1 and
PE2. The status of BFD sessions is Up.
[PE1] display bfd session mpls-te interface Tunnel 1/0/0 te-lsp
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
8208 8217 3.3.3.3 Tunnel1/0/0 Up D_TE_LSP
--------------------------------------------------------------------------------
for port 2 into port 1. After the cable is removed from GE 2/0/0 on PE1 or P1, the fault is rectified
within milliseconds.

After the cable is reconnected to GE 2/0/0 and the cable is removed from GE 1/0/0 on PE1 in
15 seconds, the fault is rectified within milliseconds.
----End
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
next hop 10.3.1.2
next hop 10.5.1.2
next hop 3.3.3.3
#
explicit-path main
next hop 10.4.1.2
next hop 10.2.1.2
next hop 3.3.3.3
#
isis 1
cost-style wide
network-entity 10.0000.0000.0004.00
#
ip address 10.3.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
destination 3.3.3.3
mpls te bfd enable


mpls te commit
#
return
#
sysname P1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.4.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.2.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.252
isis enable 1
mpls

mpls te
mpls rsvp-te
#
ip address 10.5.1.1 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.3.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
bfd
mpls-passive
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
cost-style wide
network-entity 10.0000.0000.0003.00
#
ip address 10.2.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 10.5.1.2 255.255.255.252
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

3.30.34 Example for Configuring Dynamic BFD for RSVP

This section provides an example for configuring dynamic BFD for RSVP, which allows nodes
to detect link failure and perform the TE FRR switchovers provided there is a Layer 2 devices
exist between the two nodes involved.
Figure 3-36 illustrates an MPLS network with a switch (a Layer 2 device) between P1 and P2.
An MPLS TE tunnel between PE1 and PE2 is established. TE FRR is configured on P1
functioning as a PLR and PE2 functioning as an MP. The primary CR-LSP is PE1 --> P1 -->
Switch --> P2 --> PE2; the bypass CR-LSP is P1 --> P3 --> PE2. In addition, RSVP GR is
configured on each device.
GE 2/0/0 on P1 cannot receive RSVP Hello messages from its neighbors if either of the following
conditions are met:
l P2 is performing RSVP GR.
l The link or the switch between P1 and P2 fails.
In these situations, P1 cannot identify whether the failure to receive RSVP Hello messages is
because a fault on the link or switch or because its neighbor is performing RSVP GR; therefore,
P1 cannot determine whether to perform the TE FRR switchover.
The default interval at which RSVP Hello messages are sent is 3 seconds. The interval at which
a neighbor is declared Down is three times longer than the interval at which Hello messages are
sent. Therefore, an LSR can sense a fault on an RSVP neighbor within seconds. BFD, however,
can detect a fault within milliseconds.
If BFD for RSVP is configured on the preceding network, P1 can rapidly detect the fault in the
link or switch between P1 and P2 and then perform a TE FRR switchover.
Figure 3-36 Networking diagram for BFD for RSVP

Loopback1
4.4.4.4/32
/0 PO
S1/0 0 10. S2/0
PO 1.2/3 5.1 /0
3. .1/3
10. 0 PO
Loopback1 /0/0 P3 10. S2/0
O S3 1/30 5.1 /0
1.1.1.1/32 P 3.1. .2/3
10. 0
POS1/0/0
10.1.1.1/30 P1 PE2
GE2 Switch
/0
PE1 POS1/0/0 10.2 /0/0 P2 S 1/0 0
10.1.1.2/30 .1.1 PO 1.2/3
/24 G .4.
Loopback1 10.2 E2/0/0 1/0/0 010 Loopback1
S 3
2.2.2.2/32 .1.2
/24 PO 4.1.1/ 5.5.5.5/32
10 .
Loopback1
3.3.3.3/32
: Primary CR-LSP
: Bypass CR-LSP

1. Assign an IP address to each interface and enable IGP on each LSR so that LSRs can
communicate. Enable IGP GR to support RSVP GR.
2. Configure the MPLS network and basic MPLS TE functions.
3. Configure explicit paths for the primary and bypass tunnels.
4. Create a TE primary tunnel interface and enable TE FRR on PE1. Configure the bypass
tunnel on P1.
5. Configure RSVP GR on all LSRs and establish a Hello session between P1 and PE2.
NOTE
On a network with TE FRR configured, a Hello session is required between a PLR and an MP of the
bypass tunnel if you want to configure RSVP GR. If the Hello session is not configured, when traffic
switches to the bypass tunnel because the primary tunnel fails, the primary tunnel goes Down if the
PLR or MP performs RSVP GR.
6. Configure BFD for RSVP on P1 and P2.
Data Preparation
l Type of an IGP and data required for configuring an IGP

l MPLS LSR ID
l Bandwidth attributes of the outbound interfaces of links along the tunnel
l Primary tunnel interface number, bandwidth for the primary tunnel, and explicit path
l Bypass tunnel interface number, bandwidth for the bypass tunnel, and explicit path
l Physical interfaces to be protected by the bypass tunnel
l Minimum intervals at which BFD packets are sent and received (The default values are
specified in the License.)
l Local BFD detection multiplier (The default values are specified in the license.)
Procedure
Assign an IP address and mask to each interface according to Figure 3-36, create loopback
interfaces on LSRs, and then configure the IP addresses of the loopback interfaces as MPLS
LSR IDs. For configuration details, see Configuration Files in this section.
Step 2 Configure the switch.
Configure the switch so that P1 and P2 can communicate. For configuration details, see
Step 3 Configure an IGP and IGP GR.

Configure OSPF or IS-IS on each LSR so that LSRs can communicate. Configure IGP GR to
support RSVP GR. In this example, OSPF is used. For configuration details, see Configuration
Step 4 Configuring basic MPLS functions.
Configure the LSR ID and enable MPLS in the system view on each LSR and enable MPLS in
the interface view. For configuration details, see Configuration Files in this section.
Enable MPLS-TE and MPLS RSVP-TE in the MPLS and interface views on each LSR. Set the
maximum reservable bandwidth for the outbound interfaces of links along the tunnel to 100
Mbit/s and the BC0 bandwidth to 100 Mbit/s. For configuration details, see Configuration
Step 6 Configure OSPF TE and CSPF.
Enable OSPF TE on each node and configure CSPF on PE1 and PE2. For configuration details,
see Configuring the RSVP-TE Tunnel.
# Specify an explicit path for the primary tunnel on PE1.
<PE1> system-view
# Create a tunnel interface on PE1, specify an explicit path, set the tunnel bandwidth to 10 Mbit/
s, and enable TE FRR.
# Run the display mpls te tunnel-interface tunnel interface-number command on PE1. The
status of tunnel 1/0/0 on PE1 is Up.
Step 8 Configure the bypass tunnel.
# Specify the explicit path for the bypass tunnel on P1.
<P1> system-view
[P1] explicit-path tope2
[P1-explicit-path-tope2] next hop 10.3.1.2
[P1-explicit-path-tope2] quit
# Configure a bypass tunnel interface and specify an explicit path for the bypass tunnel. Set the
tunnel bandwidth to 20 Mbit/s and the protected bandwidth to 10 Mbit/s. Specify the physical
interface to be protected by the bypass tunnel.

[P1] interface tunnel 3/0/0

[P1-Tunnel3/0/0] ip address unnumbered interface loopback 1
[P1-Tunnel3/0/0] tunnel-protocol mpls te
[P1-Tunnel3/0/0] destination 5.5.5.5
[P1-Tunnel3/0/0] mpls te tunnel-id 300
[P1-Tunnel3/0/0] mpls te path explicit-path tope2
[P1-Tunnel3/0/0] mpls te bandwidth ct0 20000
[P1-Tunnel3/0/0] mpls te bypass-tunnel
[P1-Tunnel3/0/0] mpls te protected-interface gigabitethernet 2/0/0
[P1-Tunnel3/0/0] mpls te commit
[P1-Tunnel3/0/0] quit
Step 9 Configure RSVP GR.
# Configure RSVP GR on all LSRs and establish Hello sessions between P1 and PE2.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls rsvp-te hello
[PE1-mpls] mpls rsvp-te hello full-gr
[PE1-mpls] quit
[PE1] interface pos1/0/0
[PE1-Pos1/0/0] mpls rsvp-te hello
# Configure P1.
[P1] mpls
[P1-mpls] mpls rsvp-te hello
[P1-mpls] mpls rsvp-te hello full-gr
[P1-mpls] mpls rsvp-te hello nodeid-session 5.5.5.5
[P1-mpls] quit
[P1] interface pos1/0/0
[P1-Pos1/0/0] mpls rsvp-te hello
[P1-Pos1/0/0] quit
[P1-GigabitEthernet2/0/0] mpls rsvp-te hello
[P1-Pos3/0/0] quit
# Configure P2.
[P2] mpls
[P2-mpls] quit
[P2-Pos1/0/0] quit
[P2-GigabitEthernet2/0/0] mpls rsvp-te hello
# Configure P3.
[P3] mpls
[P3-mpls] quit
[P3-Pos1/0/0] quit
[P3-Pos2/0/0] quit

# Configure PE2.
[PE2] mpls
[PE2-mpls] mpls rsvp-te hello
[PE2-mpls] mpls rsvp-te hello full-gr
[PE2-mpls] mpls rsvp-te hello nodeid-session 2.2.2.2
[PE2-mpls] quit
[PE2] interface pos1/0/0
[PE2-Pos1/0/0] quit
[PE2-Pos2/0/0] quit
Step 10 Configure BFD for RSVP.

# Enable BFD for RSVP on GE 2/0/0 on P1 and P2. Set the minimum interval at which BFD
packets are sent and received and the local BFD detection multiplier.
# Configure P1.
[P1] bfd
[P1-bfd] quit
[P1-GigabitEthernet2/0/0] mpls rsvp-te bfd enable
[P1-GigabitEthernet2/0/0] mpls rsvp-te bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 3
# Configure P2.
[P2] bfd
[P2-bfd] quit
[P2-GigabitEthernet2/0/0] mpls rsvp-te bfd enable
[P2-GigabitEthernet2/0/0] mpls rsvp-te bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 3
# Run the display mpls rsvp-te bfd session { all | interface interface-name | peer ip-addr }
command on PE1 and PE2. The status of the BFD sessions is Up.
for port 2 into port 1. (Write down the label value). After the cable is removed from any interface
on P1 and P2, the fault is rectified within milliseconds.
----End
Configuration Files
NOTE
The configuration file for the switch is not listed here.

#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello


mpls te cspf
#
explicit-path tope2
next hop 10.1.1.2
next hop 10.2.1.2
next hop 10.4.1.2
next hop 5.5.5.5
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 5.5.5.5
mpls te commit
#
ospf 1
graceful-restart
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 1.1.1.1 0.0.0.0
mpls-te enable
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls rsvp-te hello nodeid-session 5.5.5.5
mpls te cspf
#
explicit-path tope2
next hop 10.3.1.2
next hop 10.5.1.2
next hop 5.5.5.5
#
bfd
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.252

mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
mpls rsvp-te bfd min-tx-interval 100 min-rx-interval 100
mpls rsvp-te hello
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 10.3.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
destination 5.5.5.5
mpls te commit
#
ospf 1
graceful-restart
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
mpls-te enable
#
return
#
sysname P2
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
bfd
#

interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.4.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
mpls rsvp-te bfd min-tx-interval 100 min-rx-interval 100
mpls rsvp-te hello
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
graceful-restart
area 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.4.1.0 0.0.0.3
network 3.3.3.3 0.0.0.0
mpls-te enable
#
return
#
sysname P3
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.3.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.5.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1

ip address 4.4.4.4 255.255.255.255

#
ospf 1
graceful-restart
area 0.0.0.0
network 10.3.1.0 0.0.0.3
network 10.5.1.0 0.0.0.3
network 4.4.4.4 0.0.0.0
mpls-te enable
#
return

#
sysname PE2
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls rsvp-te hello nodeid-session 2.2.2.2
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.4.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.5.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
ospf 1
graceful-restart
area 0.0.0.0
network 10.4.1.0 0.0.0.3
network 10.5.1.0 0.0.0.3
network 5.5.5.5 0.0.0.0
mpls-te enable
#
return
3.30.35 Example for Advertising MPLS LSR IDs to Multiple OSPF

Areas
On the network shown in Figure 3-37, OSPF runs on LSRA, LSRB, and LSRC. LSRA and
LSRB reside in Area 0; LSRB and LSRC reside in Area 1; LSRB is an ABR. It is required that

a tunnel be set up on LSRA and LSRC separately destined for LSRB and that IGP shortcut be
enabled on LSRA and LSRC so that routes on LSRA and LSRC to LSRB use the tunnel interfaces
as the outbound interfaces.
Figure 3-37 Networking for configuring inter-area tunnels

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0
10.0.0.1/24 10.0.0.2/24 20.0.0.1/24 20.0.0.2/24
LSRA LSRB LSRC
1. Configure an IP address for each interface on the LSRs and the loopback interface address
used as the LSR ID, and configure OSPF to advertise the network segments connected to
the interfaces on the LSRs and host routes of LSR IDs.
2. Configure the LSR ID of each LSR and enable MPLS, MPLS TE, and MPLS RSVP-TE
on each LSR and interface.
3. Set up a tunnel destined to LSRB on LSRA and LSRC separately and enable IGP shortcut
on LSRA and LSRC.
4. Run the advertise mpls-lsr-id command on LSRB so that the host route 2.2.2.2, an inter-
area route, is advertised to both Area 0 and Area 1.
Data Preparation
l OSPF process ID and area ID of each LSR

l Interface number, IP address, destination address, and tunnel ID of each tunnel interface
on LSRA and LSRC
Procedure
Step 1 Configure an IP address for each interface on the LSRs and configure OSPF.
Configure an IP address and a mask for each interface and configure OSPF so that all LSRs can
communicate with each other.
Step 2 Configure basic MPLS functions and enable MPLS TE and MPLS RSVP-TE.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te


[LSRA-mpls] quit
[LSRA-GigabitEthernet1/0/0] ospf network-type p2p
section.
Step 3 Configure an MPLS TE tunnel and IGP shortcut.
# Set up an MPLS TE tunnel from LSRA to LSRB and configure IGP shortcut. The OSPF cost
of the tunnel is smaller than that of the physical link.
[LSRA-Tunnel1/0/0] mpls te igp shortcut ospf
# Set up an MPLS TE tunnel from LSRC to LSRB and configure IGP shortcut. The OSPF cost
of the tunnel is smaller than that of the physical link.
[LSRC-Tunnel2/0/0] mpls te igp shortcut ospf
[LSRC-Tunnel2/0/0] mpls te igp metric absolute 1
After the configurations are complete, run the display interface tunnel command on LSRA.
You can see that the tunnel interface is Up.
# Run the display mpls te tunnel command on LSRA and LSRC. You can view information
about each MPLS TE tunnel.
<LSRA> display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 2.2.2.2 1 --/3 I Tunnel1/0/0
<LSRC> display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
3.3.3.3 2.2.2.2 1 --/3 I Tunnel2/0/0
Step 4 Configure the ABR so that LSRB can advertise MPLS LSR IDs to multiple OSPF areas.
[LSRB] ospf 1
[LSRB-ospf-1] advertise mpls-lsr-id

# Run the display ospf peer brief command on LSRB. You can see that each Area 0 and Area
1 has a neighbor in the Full state.
[LSRB] display ospf peer brief
OSPF Process 1 with Router ID 2.2.2.2

Peer Statistic Informations
------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet1/0/0 1.1.1.1 Full
0.0.0.1 GigabitEthernet2/0/0 3.3.3.3 Full
------------------------------------------------------------------------
Total Peer(s): 2
# Run the display ip routing-table 2.2.2.2 command on LSRA. You can see that in the routing
table, the outbound interface of the route to 2.2.2.2 is a tunnel interface.
<LSRA> display ip routing-table 2.2.2.2
------------------------------------------------------------------------------
Summary Count : 1
2.2.2.2/32 OSPF 10 1 D 1.1.1.1 Tunnel1/0/0
<LSRC> display ip routing-table 2.2.2.2

------------------------------------------------------------------------------
Summary Count : 1
2.2.2.2/32 OSPF 10 1 D 3.3.3.3 Tunnel2/0/0
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.0.0.1 255.255.255.0
ospf cost 10
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 2.2.2.2
mpls te igp shortcut ospf


mpls te commit
#
ospf 1 router-id 1.1.1.1
enable traffic-adjustment
area 0.0.0.0
network 10.0.0.0 0.0.0.255
network 1.1.1.1 0.0.0.0
mpls-te enable
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.0.0.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 20.0.0.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
advertise mpls-lsr-id
area 0.0.0.0
network 10.0.0.0 0.0.0.255
mpls-te enable
area 0.0.0.1
network 20.0.0.0 0.0.0.255
mpls-te enable
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 20.0.0.2 255.255.255.0
ospf cost 10
mpls
mpls te

mpls rsvp-te
#
interface NULL0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
destination 2.2.2.2
mpls te igp shortcut ospf
mpls te commit
#
area 0.0.0.1
network 20.0.0.0 0.0.0.255
network 3.3.3.3 0.0.0.0
mpls-te enable
#
return
3.30.36 Example for Configuring an Inter-Area Tunnel

This section provides an example for configuring a TE tunnel between IS-IS areas.
On the network shown in Figure 3-38,
l IS-IS is run on LSRA, LSRB, LSRC, LSRD, and LSRE.

– LSRA and LSRE are Level-1 devices.
– LSRB and LSRD are Level-1-2 devices.
– LSRC is Level-2 devices.
l A TE tunnel is established from LSRA to LSRE using RSVP-TE. The tunnel traverses the
IS-IS area with the bandwidth of 20 Mbit/s.
l The maximum reservable bandwidth of the link that the tunnel traverses is 100 Mbit/s and
the BC0 bandwidth is 100 Mbit/s.

Figure 3-38 Networking diagram for configuring an inter-area tunnel
Area address: 00.0005 Area address: 00.0006 Area address: 00.0007

2.2.2.2/32 3.3.3.3/32 4.4.4.4/32
GE1/0/0
LSRB POS2/0/0 LSRD
30.1.1.1/24
L1/2 20.1.1.1/24 L1/2
POS2/0/0
GE1/0/0 LSRC GE1/0/0 GE2/0/0
20.1.1.2/24
10.1.1.2/24 L2 30.1.1.2/24 40.1.1.1/24
GE1/0/0 GE1/0/0
10.1.1.1/24 40.1.1.2/24
LSRA LSRE
L1 L1
Loopback1 Loopback1
1.1.1.1/32 5.5.5.5/32
1. Assign IP addresses to interfaces on each LSR, configure loopback address as LSR IDs.
2. Enable the IS-IS protocol globally and enable IS-IS TE.
3. Configure the loose explicit path, including ABR (LSRB, LSRC, and LSRD).
4. Enable MPLS RSVP-TE.
5. Configure the bandwidth attributes for the outbound interfaces of links along the TE tunnel.
6. Establish the tunnel interface on the ingress, specify the IP address of the tunnel, the tunnel
protocol, the destination address, the tunnel ID, the RSVP-TE protocol, and the tunnel
bandwidth.
Data Preparation
l IS-IS area ID of each LSR, originating system ID, and IS-IS level
l Maximum reservable bandwidth and BC bandwidth for outbound interfaces of links along
the tunnel
l Name of the tunnel interface, IP address, destination address, tunnel ID, tunnel signaling
protocol (RSVP-TE), and tunnel bandwidth
Procedure
Assign an IP address and mask to each interface, including the loopback interface according to
Figure 3-38.


Step 2 Configure the IS-IS protocol to advertise routes.
# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] is-level level-1-2
[LSRB-isis-1] import-route isis level-2 into level-1
[LSRB-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] quit
# Configure LSRD.
[LSRD] isis 1
[LSRD-isis-1] is-level level-1-2
[LSRD-isis-1] import-route isis level-2 into level-1
[LSRD-isis-1] quit
# Configure LSRE.

[LSRE] isis 1
[LSRE-isis-1] network-entity 00.0007.0000.0000.0005.00
[LSRE-isis-1] quit
Step 3 Configure basic MPLS functions, enable MPLS TE, RSVP-TE, and enable CSPF on the ingress
of the tunnel.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] mpls te
[LSRB-mpls] quit
# Configure LSRC.
[LSRC] mpls
[LSRC-mpls] mpls te
[LSRC-mpls] quit
# Configure LSRD.

[LSRD] mpls
[LSRD-mpls] mpls te
[LSRD-mpls] quit
# Configure LSRE.
[LSRE] mpls lsr-id 5.5.5.5
[LSRE] mpls
[LSRE-mpls] mpls te
[LSRE-mpls] mpls rsvp-te
[LSRE-mpls] quit
[LSRE-GigabitEthernet1/0/0] mpls
[LSRE-GigabitEthernet1/0/0] mpls te
[LSRE-GigabitEthernet1/0/0] mpls rsvp-te

# Configure LSRA.
[LSRA] isis 1
[LSRA-isis-1] quit
# Configure LSRB.
[LSRB] isis 1
[LSRB-isis-1] traffic-eng level-1-2
[LSRB-isis-1] quit
# Configure LSRC.
[LSRC] isis 1
[LSRC-isis-1] quit
# Configure LSRD.
[LSRD] isis 1
[LSRD-isis-1] traffic-eng level-1-2
[LSRD-isis-1] quit
# Configure LSRE.
[LSRE] isis 1
[LSRE-isis-1] traffic-eng level-1
[LSRE-isis-1] quit
Step 5 Configure the loose explicit path.

[LSRA] explicit-path atoe
[LSRA-explicit-path-atoe] next hop 10.1.1.2 include loose


Step 6 Configure MPLS TE attributes for the link.
# Configure the maximum reservable bandwidth and the BC0 bandwidth for the link on LSRA.
# Configure the maximum bandwidth and the maximum reservable bandwidth for the link on
LSRB.
LSRC.
LSRD.
[LSRD-GigabitEthernet2/0/0] mpls te bandwidth max-reservable-bandwidth 100000
[LSRD-GigabitEthernet2/0/0] mpls te bandwidth bc0 100000
# Configure an MPLS TE tunnel on LSRA.

[LSRA-Tunnel1/0/0] mpls te path explicit-path atoe
status of the tunnel interface is Up.
[LSRA] display interface Tunnel
Last up time: 2009-01-16, 10:36:20
...
# Run the display mpls te tunnel verbose command on LSRA to display information about the
tunnel.

[LSRA] display mpls te tunnel verbose

No : 1
In-Interface : -
IncludeAllAff : 0x0
LspConstraint : -
ER-Hop Table Index : 0 AR-Hop Table Index: -
PSB Handle : 1024
Created Time : 2010/09/09 16:40:44 UTC-08:00
RSVP LSP Type : -
--------------------------------
DS-TE Information
--------------------------------
--------------------------------
FRR Information
--------------------------------
Primary LSP Info
BypassTunnel : -
IncludeAllGroup : -
--------------------------------
BFD Information
--------------------------------
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls

mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path atoe
next hop 10.1.1.2 include loose
#
isis 1
is-level level-1
cost-style wide
network-entity 00.0005.0000.0000.0001.00
traffic-eng level-1
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
destination 5.5.5.5
mpls te path explicit-path atoe
mpls te commit
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-1-2
cost-style wide
import-route isis level-2 into level-1
network-entity 00.0005.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
clock master
ip address 20.1.1.1 255.255.255.0

isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-2
cost-style wide
network-entity 00.0006.0000.0000.0003.00
traffic-eng level-2
#
ip address 30.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-1-2
cost-style wide
network-entity 00.0007.0000.0000.0004.00
import-route isis level-2 into level-1
#

ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
ip address 40.1.1.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
return

#
sysname LSRE
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
#
isis 1
is-level level-1
cost-style wide
network-entity 00.0007.0000.0000.0005.00
traffic-eng level-1
#
ip address 40.1.1.2 255.255.255.0
isis enable 1
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return

Configuration Guide - MPLS 4 MPLS Common Configuration
4 MPLS Common Configuration
About This Chapter
MPLS common configurations include the MPLS TTL handling mode, Layer 3 MPLS load
balancing, PBR to the LSP on the public network, and MPLS optimization.
4.1 Introduction
MPLS supports multiple labels, and the MPLS forwarding plane is connection-oriented, which
enables MPLS to be of well expansibility. With these features, MPLS provides various services
based on the MPLS and IP-integrated network architecture.
4.2 Configuring a Mode in Which MPLS Processes the EXP Field

This section describes how to configure a mode in which MPLS processes the EXP field. This
section describes the Usage Scenario and procedures for configuring a mode for Multiprotocol
Label Switching (MPLS) to process the experimental bits (EXP) field.
4.3 Configuring the Mode in Which MPLS Handles the TTL

This section describes how to configure the mode in which MPLS handles the TTL in packets.
You can configure an MPLS TTL handling mode only after enabling MPLS or configuring the
MPLS VPN.
4.4 Configuring MPLS Load Balancing

MPLS supports Equal-Cost Multiple Path (ECMP) and Unequal-Cost Multiple Path (UCMP).
The ingress node on an MPLS network can load-balance traffic in per-flow or per-packet mode.
4.5 Configuring Dynamic BFD to Monitor a BGP Tunnel

BFD for BGP tunnel rapidly detects faults in E2E BGP tunnels.
4.6 Optimizing MPLS

This section describes how to optimize MPLS performance. To optimize MPLS performance,
you can adjust parameters of the PHP function, MPLS MTU on an interface, and Layer 3 MPLS
load balancing function.
4.7 Maintaining MPLS Common Configuration

MPLS common configurations involves checking LSP connectivity and reachability, setting
dynamic label thresholds for triggering an alarm, and maintaining the PBR to an LSP.

The following sections provide several examples of MPLS common configurations.

4.1 Introduction
MPLS supports multiple labels, and the MPLS forwarding plane is connection-oriented, which
enables MPLS to be of well expansibility. With these features, MPLS provides various services
based on the MPLS and IP-integrated network architecture.
4.1.1 Overview
MPLS speeds up the forwarding of networks and can provide various new services.
Originally, MPLS is set forth for improving the forwarding rate of the device, but this means
little now with the improvement of hardware technology. After all, MPLS is connection-oriented
with well expansibility and supports multiple-layer label. With these features, MPLS can provide
various services based on fundamental MPLS and IP-integrated network architecture. MPLS
gradually becomes a basic technology applicable to large-scale networks.
MPLS VPN is highly evaluated by the IP network carrier in providing value-added services.
With MPLS VPN technology, the current IP network is divided into logically-isolated networks.
This technology is applicable to interconnection among companies and various new services.
For example, despite of lacking IP network addresses, a VPN can be established especially for
IP telephone services to provide QoS and new services.
4.1.2 MPLS Common Features Supported by the NE80E/40E

The system supports the MPLS common features, including the MPLS TTL handling mode,
PBR to LSP, and MPLS ping and traceroute.
MPLS TTL Processing Modes

The MPLS label contains an 8-bit TTL field. The meaning of the TTL field is similar to that of
the TTL field in an IP header. The TTL can be used to prevent routing loops and to implement
the traceroute function.
In the NE80E/40E, you can set different TTL processing modes for VPN packets and public
network packets to obtain different traceroute results.
MPLS Ping/Traceroute
The MPLS ping and traceroute help to detect LSP faults and locate faulty nodes.
Similar to IP ping and traceroute, MPLS ping and traceroute use the echo request and echo reply
messages to check the availability of the LSP. Echo request and echo reply messages are
transferred in User Datagram Protocol (UDP) datagrams using port 3503.
BFD for BGP Tunnel

In the scenarios, such as the inter-AS VPN Option C and seamless MPLS, a routing policy can
be configured to assign MPLS labels for BGP routes to establish an E2E BGP tunnel consisting
of the primary and backup BGP LSPs. VPN services can then travel along the BGP tunnel. To
rapidly detect faults in an E2E BGP tunnel, BFD for BGP tunnel is used. If both the primary
and backup LSPs fail, a BFD session detects the fault and triggers VPN FRR switching.

4.2 Configuring a Mode in Which MPLS Processes the EXP

Field
This section describes how to configure a mode in which MPLS processes the EXP field. This
section describes the Usage Scenario and procedures for configuring a mode for Multiprotocol
Label Switching (MPLS) to process the experimental bits (EXP) field.
Usage Scenario
On a network where penultimate hop popping (PHP) is enabled, a P at the penultimate hop copies
the EXP value of the outer label to that of the inner label, pops out the outer label, retains the
inner label, and forwards the inner label to the last hop. The provider edge (PE) at the last hop
uses the modified EXP value of the inner label to provide quality of service (QoS) guarantee.
Whether the modified EXP value is used depends on the following parameters in the mpls lsp
exp-mode command executed on the P:
l pipe : prevents the P from using the modified EXP value of the inner label for QoS
scheduling.
l uniform: allows the P to use the modified EXP value of the inner label for QoS scheduling.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls lsp exp-mode { pipe | uniform }
A Mode in which MPLS Processes the EXP field is configured.

By default, MPLS processes the EXP field in Uniform mode. The EXP value of the outer label
is copied to that of the inner label.
NOTE
If an MPLS label switched path (LSP) has been established, you must run the refresh fib slot slot-id
command before running the mpls lsp exp-mode command. Otherwise, the mpls lsp exp-mode command
does not take effect.
----End
Checking the Configuration

Run the display this command in the MPLS view. If the mode for MPLS to process the EXP
field is displayed, the configuration is succeeful.
[HUAWEI-mpls] display this

#
mpls lsp exp-mode pipe
#
return
The command output in bold indicates that MPLS processes the EXP field in Pipe mode.
4.3 Configuring the Mode in Which MPLS Handles the TTL

This section describes how to configure the mode in which MPLS handles the TTL in packets.
You can configure an MPLS TTL handling mode only after enabling MPLS or configuring the
MPLS VPN.

Before configuring an MPLS TTL handling mode, familiarize yourself with the usage scenario,
Usage Scenario
MPLS TTL process is related to the following aspects:
l MPLS TTL process modes

– If the ingress is configured with the Uniform mode or enabled with the IP TTL
propagation function, the IP TTL decreases by one at each hop. Therefore, the output
of the traceroute test reflects the actual path traversed by the packet.
– If the ingress is configured with the Pipe mode or the IP TTL copy function is disabled
on the ingress, the IP TTL value does not decrease by one at each hop. The output of
the traceroute test does not reflect all the hops in the MPLS backbone network, as if the
ingress is directly connected to the egress.
When using MPLS IP TTL propagation, note that:
– Multi-level labels of MPLS packets mutually propagate their TTLs within an MPLS
domain.
– The MPLS IP TTL propagation function does not take effect on packets originating
from the local LSR. The TTLs of all local packets are propagated, and the local
administrators can analyze the network using the tracert command.
In the MPLS VPN application, the MPLS backbone network structure can be hidden for
security purpose. The ingress cannot use the TTL propagation function for private network
packets.
l ICMP response packets
For the MPLS packets only with one layer of label, you can configure MPLS to send back
the ICMP response packet only over IP routes, not the LSP after the TTL expires.
Generally, in the MPLS domain, the P device maintains public network routes only, and
MPLS packets with one layer of label carry public network payload.
NOTE
For detailed information about HoVPN and SPE, see the HUAWEI NetEngine80E/40E Router
Configuration Guide - VPN.

Before configuring the MPLS TTL process mode, enable MPLS or MPLS VPN.
Data Preparation
To configure the MPLS TTL process mode, you need the following data.
No. Data
1 MPLS TTL process mode
2 Information about the path through which an ICMP Echo Reply

message passes
4.3.2 Configuring a Mode for Processing TTLs in Packets

Transmitted over an MPLS LDP LSP
This section describes how to configure a mode for processing TTLs in packets transmitted over
an MPLS LDP LSP. TTLs in packets transmitted over an MPLS LDP LSP are processed in
either uniform or pipe mode. The mode on the ingress must be the same as that on the egress of
the LDP LSP.
Context
In an MPLS domain, virtual circuit connectivity verification (VCCV) monitors the connectivity
of a multi-segment pseudo wire (MS-PW) based on TTLs. If PEs along an LSP over which the
MS-PW is established use different TTL processing modes, the inconsistency causes a VCCV
failure. Therefore, the TTL processing modes on PEs within the MPLS domain must be the
same.
On the network shown in Figure 4-1, the same TTL processing mode needs to be configured
on T-PE1, S-PE1, S-PE2, and T-PE2 before VCCV monitors the connectivity of an MS-PW
between T-PE1 and T-PE2. Similarly, the same TTL processing mode needs to be configured
on T-PE1 and S-PE1 before VCCV monitors the connectivity of a PW segment between T-PE1
and S-PE1.
Figure 4-1 MPLS network

PW Segment PW Segment PW Segment
T-PE1 T-PE2
CE S-PE1 S-PE2 CE

Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls ldp ttl-mode { pipe | uniform }
A mode for processing TTLs in packets transmitted over an MPLS LDP LSP is specified.
By default, the uniform mode is used.

The egress is configured to assign labels to the LSR at the penultimate hop of the LSP.
NOTE
This command must be run on the egress if the pipe mode is used.
----End
4.3.3 Configuring a Mode for Processing TTLs in Packets

Transmitted over an MPLS TE LSP
This section describes how to configure a mode for processing TTLs in packets transmitted over
an MPLS TE LSP. TTLs in packets transmitted over an MPLS TE LSP are processed in either
uniform or pipe mode. The mode on the ingress must be the same as that on the egress of the
TE LSP.
Context
In an MPLS domain, virtual circuit connectivity verification (VCCV) monitors the connectivity
of a multi-segment pseudo wire (MS-PW) based on TTLs. If PEs along an LSP over which the
MS-PW is established use different TTL processing modes, the inconsistency causes a VCCV
failure. Therefore, the TTL processing modes on PEs within the MPLS domain must be the
same.
On the network shown in Figure 4-2, the same TTL processing mode needs to be configured
on T-PE1, S-PE1, S-PE2, and T-PE2 before VCCV monitors the connectivity of an MS-PW
between T-PE1 and T-PE2. Similarly, the same TTL processing mode needs to be configured
on T-PE1 and S-PE1 before VCCV monitors the connectivity of a PW segment between T-PE1
and S-PE1.

Figure 4-2 MPLS network

PW Segment PW Segment PW Segment
T-PE1 T-PE2
CE S-PE1 S-PE2 CE
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls te ttl-mode { pipe | uniform }
A mode for processing TTLs in packets transmitted over an MPLS TE LSP is specified.
By default, the uniform mode is used.
The egress is configured to assign labels to the LSR at the penultimate hop of the LSP.
NOTE
This command must be run on the egress if the pipe mode is used.
----End
4.3.4 Configuring the Mode in Which MPLS L3VPN Handles the

TTL
MPLS L3VPN handles TTLs in Uniform mode and Pipe mode.
Context
The effect of configuring the MPLS uniform mode and that of configuring the IP TTL copy
function are the same. The TTL of a packet transmitted in an MPLS network decreases by one
at each hop.
The effect of configuring the MPLS Pipe mode and that of disabling the MPLS IP TTL
propagation function are the same. That is, when packets pass through an MPLS network, the

ingress and egress are perceived as directly connected. The IP TTL decreases by one only on
the ingress and the egress respectively.
Procedure
l Configuring MPLS Uniform mode
Perform the following steps on the ingress PE:
1. Run:
system-view

2. Run:
ip vpn-instance vpn-instance-name
The VPN instance view is displayed.

3. Run:
ttl-mode uniform
MPLS Uniform mode is configured.
By default, the MPLS Pipe mode is used.

l Configuring MPLS Pipe Mode
Perform the following steps on the ingress PE:
1. Run:
system-view

2. Run:

3. Run:
ttl-mode pipe
The MPLS Pipe mode is configured.
By default, the MPLS Pipe mode is used.
----End
4.3.5 Configuring the Path for ICMP Reply Messages

This section describes how to configure a path for ICMP Reply packets. Before setting up a path
for ICMP Reply messages, configure the ingress and egress.
Context
Perform the following steps on the ingress and egress PEs:

Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Perform either of the following steps:
To enable ICMP Reply messages to travel over IP routes, run:
ttl expiration pop
To enable ICMP Reply messages to travel along an LSP, run:

undo ttl expiration pop
For the MPLS packet with one layer of a label, ICMP Reply messages are sent back along the
local IP route by default.
----End
4.4 Configuring MPLS Load Balancing

MPLS supports Equal-Cost Multiple Path (ECMP) and Unequal-Cost Multiple Path (UCMP).
The ingress node on an MPLS network can load-balance traffic in per-flow or per-packet mode.

Before configuring the MPLS load balancing function, familiarize yourself with the usage
scenario, complete the pre-configuration tasks, and obtain the required data.
Usage Scenario
On an existing MPLS network, devices in the core area support TE, and devices in other areas
use LDP. LDP over TE is used to allow a TE tunnel to function as a hop of an entire LDP LSP.
On MPLS VPNs where LDP is widely used, LDP over TE is used to prevent VPN traffic
congestions on some nodes. If multiple tunnels on a transit node have the same downstream
node, load balancing can be configured on the transit node. This allows each link to carry traffic
based on the proportion of the specific weight to the total weight.
Before configuring load balancing of MPLS Layer 3 forwarding, complete the following tasks:
l Configure LSR IDs.
l Enable MPLS.
Data Preparation
None.

4.4.2 Configuring Layer 3 MPLS Forwarding in UCMP Mode

This section describes how to configure Layer 3 MPLS forwarding in UCMP mode. To configure
the MPLS load balancing function in UMP Mode, you need to configure each transit node.
Context
Perform the following steps on each transit node:
Procedure
Step 1 Run:
system-view
Step 2 Run:
load-balance unequal-cost enable
Unequal-cost load balancing is enabled.
If multiple equal-cost links of different bandwidths exist, traffic can be proportionally balanced
over these links. All links can transmit traffic in proportion to their bandwidths.
Step 3 Run:
load-balance unequal-cost weight
Unequal-cost load balancing weights are configured for all links.
Note the following issues when configuring UCMP weights:

l If only some load balancing links are configured with load balancing weights, ECMP is
carried out among links. This means that the configured weights do not take effect.
l If all links are configured with load balancing weights, UCMP is carried out among links.
Each link carries traffic based on the actual load balancing weight calculated using the
formula:
Actual load balancing weight of a link = 32 x Weight configured for the link/Sum of weights
of all links
As the sum of weights may not divide 32 exactly, the traffic volume of each link may deviate
from the calculated result, but the sum of weights remains 32. For example, there is link A,
link B, and link C, and their load balancing weights are 10, 10, and 13, respectively. Since
the sum of the weights cannot divide 32 exactly, the weights of the links will be adjusted to
10, 10, 12, respectively.
----End
4.4.3 Configuring Layer 3 MPLS Forwarding in the Label-based

Load Balancing Mode
This section describes how to configure Layer 3 MPLS forwarding in the label-based load
balancing mode. To configure Layer 3 MPLS forwarding in the label-based load balancing mode,
you need to configure the label-based load balancing mode on transit nodes.

Context
Perform the following steps on transit nodes:
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface 100ge interface-number.subinterface-number
The 100GE interface view is displayed.
Step 3 Run:
mpls load-sharing payload-header inbound
Load sharing based on the IP quintuple in the upstream direction is enabled.
Step 4 Run:
mpls load-sharing per-label outbound
Label-based load sharing in the downstream direction is enabled.
----End
4.4.4 Configuring an MPLS Load Balancing Mode

To implement MPLS load balancing, configure a load balancing mode on the ingress and transit
nodes.
Context
The ingress node on an MPLS network supports ECMP or UCMP, in either per-flow or per-
packet mode.
Transit nodes also support ECMP or UCMP, however, they do not support per-flow or per-
packet mode. UCMP takes effect only for LDP LSPs.
Procedure
l Perform the following steps on the ingress node:
1. Run:
system-view

2. Run either of the following commands:
– To configure per-flow load balancing, run the load-balance flow [ all | slot slot-
id ] command.
– To configure per-packet load balancing, run the load-balance packet [ all | slot
slot-id ] command.

By default, per-flow load balancing is implemented for Layer 3 MPLS forwarding.

3. (Optional) Run:
load-balance unequal-cost enable
UCMP is enabled.
If multiple equal-cost physical links with different bandwidths are available to a

destination, traffic is load-balanced among these links based on bandwidth ratios,
improving load balancing efficiency.
l Perform the following steps on a transit node:
1. Run:
system-view

2. (Optional) Run:
load-balance mpls unequal-cost enable
UCMP is enabled for LDP LSPs.
By default, UCMP is disabled for LDP LSPs.
----End
4.5 Configuring Dynamic BFD to Monitor a BGP Tunnel

BFD for BGP tunnel rapidly detects faults in E2E BGP tunnels.

Before configuring dynamic BFD to monitor a BGP tunnel, familiarize yourself with the usage
Usage Scenario
On an IP/MPLS network transmitting VPN services, PEs establish a multi-segment MPLS tunnel
between each other. Therefore VPN services are sent to multiple PEs. In this case, VPN service
provision on PEs becomes complex, and the VPN service scalability decreases. As PEs establish
BGP peer relationships, a routing policy can be used to assign MPLS labels for BGP routes so
that an E2E BGP tunnel can be established. The BGP tunnel consists of a primary BGP LSP and
a backup BGP LSP. VPN services can travel along the E2E BGP tunnel, which simplifies service
provision and improves VPN service scalability.
To rapidly detect faults in an E2E BGP tunnel, BFD for BGP tunnel is used. BFD for BGP tunnel
establish a dynamic BFD session, also called a BGP BFD session, which is bound to both the
primary and backup BGP LSPs. If both BGP LSPs fail, the BGP BFD session detects the faults
and triggers VPN FRR switching.
Before configuring dynamic BFD to monitor a BGP tunnel, configure basic MPLS functions.

Data Preparation
To configure dynamic BFD to monitor a BGP tunnel, you need the following data.
No. Data
1 Policy for dynamically establishing a BFD session
2 (Optional) Name of an IP address prefix list
3 (Optional) BGP BFD parameters
4.5.2 Enabling an MPLS Device to Dynamically Establish a BGP

BFD Session
Before a dynamic BGP BFD session is established, the capability to dynamically establish BGP
BFD sessions must be enabled on each MPLS devices.
Procedure
l Perform the following steps on the ingress of an E2E BGP tunnel:
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

4. Run:
mpls

5. Run:
mpls bgp bfd enable
The ability to dynamically establish BGP BFD sessions is enabled on the ingress.
The mpls bgp bfd enable command does not create a BFD session. A BGP BFD
session can only be dynamically established only after a policy for dynamically
establish BGP BFD session is configured.
l Perform the following steps on the egress of an E2E BGP tunnel:
1. Run:
system-view

2. Run:
bfd
BFD is enabled globally, and the BFD view is displayed.

3. Run:
mpls-passive
The capability of passively creating a BFD session is configured on the egress.
The mpls-passive command does not create a BFD session. The egress has to receive
an LSP ping request carrying a BFD TLV before creating a BFD session with the
ingress.
----End
4.5.3 Configuring a Policy for Dynamically Establishing a BGP BFD

Session
BGP BFD sessions can be dynamically established based on either host addresses or an IP
address prefix list.
Context
The policies for dynamically establishing BGP BFD sessions are as follows:
l Host address-based policy: used when all host addresses are available to trigger the creation
of BGP BFD sessions.
l IP address prefix list-based policy: used when only some host addresses can be used to
establish BFD sessions.
Perform the following steps on the ingress of an E2E BGP tunnel:
Procedure
Step 1 Run:
system-view

ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ipv4-address
mask-length [ match-network ] [ greater-equal greater-equal-value ] [ less-equal
less-equal-value ]
An IPv4 address prefix list is configured, and list entries are configured.
You can perform this step when you want to use an IP address prefix list to dynamically establish
BGP BFD sessions. For configuration details about how to configure an IP address prefix list,
see Configuring an IPv4 Address Prefix List.
Step 3 Run:
mpls

Step 4 Run:
mpls bgp bfd-trigger-tunnel { host | ip-prefix ip-prefix-name }
A policy for dynamically establishing a BGP BFD session is configured.
After a policy is configured, the device starts to dynamically establish a BFD session.
----End
4.5.4 (Optional) Adjusting BGP BFD Parameters

You can adjust BGP BFD parameters, including the minimum interval at which BGP BFD
packets are sent, the minimum interval at which BGP BFD packets are received, and the BGP
BFD detection multiplier.
Context
Perform the following steps on the ingress of an E2E BGP tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Step 3 Run:
The default interval is 60s.
Step 4 Run:
quit
Step 5 Run:
mpls
Step 6 Run:
mpls bgp bfd { min-tx-interval interval | min-rx-interval interval | detect-
multiplier multiplier }*
BGP BFD time parameters are set.
Effective BFD time parameters are calculated using the following formulas:

l Effective local interval at which BFD packets are sent = MAX { Locally configured minimum
interval at which BFD packets are sent, Remotely configured minimum interval at which
BFD packets are received }
l Effective local interval at which BFD packets are received = MAX { Remotely configured
minimum interval at which BFD packets are sent, Locally configured minimum interval at
which BFD packets are received }
l Local BFD detection period = Effective local interval at which BFD packets are received x
Remotely configured BFD detection multiplier
which BFD packets are received are 100 ms, and the detection multiplier is 3 on the egress.
update BFD detection time parameters on both the ingress and egress.
----End

After configuring a dynamic BFD session to monitor a BGP tunnel, you can view BGP BFD
session information on the ingress of the BGP tunnel.
Prerequisites
The dynamic BFD for BGP tunnel function has been configured.
Procedure
l Run the display mpls bfd session protocol bgp [ fec fec-address [ verbose ] ] command
to check information about a BFD session with the protocol type of BGP on the ingress on
an E2E BGP tunnel.
l Run the display mpls lsp protocol bgp verbose command to check the BFD session status
of BGP LSPs.
----End
Example
# Run the display mpls bfd session protocol bgp command on the ingress of an E2E BGP
tunnel. The command output shows information about a BFD session that monitors the BGP
tunnel.
<HUAWEI> display mpls bfd session protocol bgp
-------------------------------------------------------------------------------
BFD Information: BGP Tunnel
-------------------------------------------------------------------------------
5.5.5.5 8192 - 2.2.2.2 - Up
# Run the display mpls lsp protocol bgp verbose command on the ingress of an E2E BGP
tunnel to view detailed information about all BGP LSPs. The command output shows that the
BFD session is Up.

<HUAWEI> display mpls lsp protocol bgp verbose

-------------------------------------------------------------------------------
LSP Information: BGP LSP
-------------------------------------------------------------------------------
No : 1
VrfIndex :
RD Value : 0:0
Fec : 5.5.5.5/32
Nexthop : 2.2.2.2
In-Label : NULL
Out-Label : 900004
In-Interface : ----------
Out-Interface : ----------
LspIndex : 22528
Token : 0x800804
LsrType : Ingress
Outgoing token : 0x800802
Label Operation : PUSH
Mpls-Mtu : ------
TimeStamp : 238059sec
FrrToken : 0x0
FrrOutgoingToken : 0x0
BGPKey : -------
BackupBGPKey : -------
FrrOutLabel : -------
Bfd-State : Up
Exp-Mode : Uniform
4.6 Optimizing MPLS

This section describes how to optimize MPLS performance. To optimize MPLS performance,
you can adjust parameters of the PHP function, MPLS MTU on an interface, and Layer 3 MPLS
load balancing function.

Before optimizing MPLS, familiarize yourself with the usage scenario, complete the pre-
Usage Scenario
MPLS has many basic parameters that can be adjusted in different environments:
l PHP
The penultimate hop popping (PHP) is configured on the egress. The label is distributed
based on the PHP functions that a PHP node supports.
l MPLS MTU of the interface
Before sending the packet along the LSP, the MPLS interface checks the packet size and
determines whether to fragment the packet based on its MPLS MTU. Generally, the MPLS
MTU of the interface is the default MTU in the IP packet.
Before adjusting the MPLS parameters, configure MPLS functions.

Data Preparation
To adjust the MPLS parameters, you need the following data.
No. Data
1 MTU of the interface
2 Interval at which MPLS statistics are collected
4.6.2 Configuring PHP

This section describes how to configure the penultimate hop popping (PHP) function. To
configure the PHP function, configure labels to be allocated to the penultimate pop.
Context
Perform the following steps on the egress:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
label advertise { explicit-null | implicit-null | non-null }
The label of the penultimate hop on the egress node is configured.
l By default, implicit-null is set for supporting PHP. The egress assigns a label with value 3
to the PHP node. The value of the label is 3.
l If explicit-null is specified, the PHP is not supported. The egress assigns a label with value
0 to the PHP node.
l If non-null is specified, the PHP is not supported. The egress allocates a normal label to PHP
node. The value of a normal label is not less than 16.
NOTE
The modification of the PHP feature takes effect only on the LSP that is set up later than the modification.
----End
4.6.3 Configuring the MPLS MTU of the Interface

By configuring the LDP MTU signaling, you can determine the size of MPLS packets to be
forwarded.

Context
The relationship between the MPLS MTU and the MTU of an interface is as follows:
l By default, if the MPLS MTU value is not set, the value of the MPLS MTU is equal to that
of the interface MTU.
l If the MPLS MTU value is set, the smaller one between the MPLS MTU value and the
interface MTU value is used. If the MPLS MTU value is not set, the interface MTU value
is used.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The MPLS-enabled interface view is displayed.
Step 3 Run:
mpls mtu mtu
The MPLS MTU of the interface is set.
The MPLS MTU configured for the interface takes effect without the interface restarted.
----End

After the configurations of optimizing MPLS, you can view information about the interface
enabled with MPLS.
Prerequisites
The MPLS function has been optimized.
Procedure
Step 1 Run the display mpls interface [ interface-type interface-number ] [ verbose ] command to
check information about the interface enabled with MPLS.
----End
Example
If the configurations are successful, you can view the following information:
<HUAWEI> display mpls interface
Interface Status TE Attr LSP Count CRLSP Count Effective MTU
GE1/0/0 Up Dis 0 0 1500

4.7 Maintaining MPLS Common Configuration

MPLS common configurations involves checking LSP connectivity and reachability, setting
dynamic label thresholds for triggering an alarm, and maintaining the PBR to an LSP.

command.
Context
Procedure


----End
4.7.2 Configuring Alarm Thresholds for Dynamic Labels

This section describes how to set the dynamic label thresholds for triggering an alarm. If the
number of dynamic labels that the system uses reaches a specific threshold, the system generates
an alarm, which facilitates operation and maintenance.
Context
If dynamic labels run out but the system receives new dynamic label requests, the system fails
to satisfy the requests because the dynamic labels are insufficient. The module that fails to be
assigned labels works abnormally. The modules that apply for labels include MPLS TE, MPLS
LDP, BGP, L3VPN and L2VPN.
To help facilitate operation and maintenance, you can set dynamic label thresholds for triggering
alarms to alert users.
Procedure
Step 1 Run:

system-view
Step 2 Run:
mpls
Step 3 Run:
mpls dynamic-label-number threshold-alarm upper-limit upper-limit-value lower-
limit lower-limit-value
The thresholds for triggering dynamic label alarms are set.
You can set the following parameters:
l upper-limit-value: a percent indicating the upper limit of dynamic labels. If dynamic label
usage reaches the upper limit, an alarm is generated. An upper limit less than or equal to 95%
is recommended.
l lower-limit-value: a percent indicating the lower limit of dynamic labels. If dynamic label
usage falls below the lower limit, an alarm is generated.
l The upper limit must be greater than the lower limit.
By default, the upper limit is 80%, and the lower limit is 70%, which are recommended.
NOTE
l Each command only configures the trigger conditions for an alarm and its clear alarm. Although trigger
conditions are met, the alarm and its clear alarm can be generated only after the snmp-agent trap
enable feature-name mpls_lspm trap-name { hwMplsDynamicLabelThresholdExceed |
hwMplsDynamicLabelThresholdExceedClear } command is run to enable the device to generate a
dynamic label insufficiency alarm and its clear alarm.
{ hwMplsDynamicLabelTotalCountExceed | hwMplsDynamicLabelTotalCountExceedClear }
command is run to enable the device to generate limit-reaching alarms and their clear alarms, the
following situations occur:
l If the number of dynamic labels reaches the maximum number of dynamic labels supported by a
device, a limit-reaching alarm is generated.
l If the number of dynamic labels falls below 95% of the maximum number of dynamic labels
supported by the device, a clear alarm is generated.
----End
4.7.3 Configuring Alarm Thresholds for BGP LSPs

This section describes how to configure alarm thresholds for BGP LSPs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls

Step 3 Run:
mpls bgp-lsp-number threshold-alarm upper-limit upper-limit-value lower-limit
lower-limit-value
The upper and lower thresholds of alarms for BGP LSP usage are configured.
l upper-limit-value specifies the upper threshold of alarms for BGP LSP usage. An alarm is
generated when the proportion of established BGP LSPs to total supported BGP LSPs reaches
the upper limit.
l lower-limit-value specifies the lower threshold of clear alarms for BGP LSP usage. A clear
alarm is generated when the proportion of established BGP LSPs to total supported BGP
The default upper limit of an alarm for BGP LSP usage is 80%. The default lower limit of a clear
alarm for BGP LSP usage is 75%. Using the default upper limit and lower limit is recommended.
NOTE
l This command configures the alarm threshold for BGP LSP usage. The alarm that the number of LSPs
reached the upper threshold is generated only when the command snmp-agent trap enable feature-
name mpls_lspm trap-name hwmplslspthresholdexceed is configured, and the actual BGP LSP
usage reaches the upper limit of the alarm threshold. The alarm that the number of LSPs fell below the
lower threshold is generated only when the command snmp-agent trap enable feature-name
mpls_lspm trap-name hwmplslspthresholdexceedclear is configured, and the actual BGP LSP usage
falls below the lower limit of the clear alarm threshold.
situations:
l If the total number of BGP LSPs reaches the upper limit, a limit-crossing alarm is generated.
l If the total number of BGP LSPs falls below 95% of the upper limit, a limit-crossing clear alarm
is generated.
----End
4.7.4 Configuring Alarm Thresholds for BGP IPv6 LSPs

This section describes how to configure alarm thresholds for BGP IPv6 LSPs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls

Step 3 Run:
mpls bgpv6-lsp-number threshold-alarm upper-limit upper-limit-value lower-limit
lower-limit-value
The upper and lower thresholds of alarms for BGP IPv6 LSP usage are configured.
l upper-limit-value specifies the upper threshold of alarms for BGP IPv6 LSP usage. An alarm
is generated when the proportion of established BGP IPv6 LSPs to total supported BGP IPv6
LSPs reaches the upper limit.
l lower-limit-value specifies the lower threshold of clear alarms for BGP IPv6 LSP usage. A
clear alarm is generated when the proportion of established BGP IPv6 LSPs to total supported
BGP IPv6 LSPs falls below the lower limit.
The default upper limit of an alarm for BGP IPv6 LSP usage is 80%. The default lower limit of
a clear alarm for BGP IPv6 LSP usage is 75%. Using the default upper limit and lower limit is
recommended.
NOTE
l This command configures the alarm threshold for BGP IPv6 LSP usage. The alarm that the number of
LSPs reached the upper threshold is generated only when the command snmp-agent trap enable
feature-name mpls_lspm trap-name hwmplslspthresholdexceed is configured, and the actual BGP
IPv6 LSP usage reaches the upper limit of the alarm threshold. The alarm that the number of LSPs fell
below the lower threshold is generated only when the command snmp-agent trap enable feature-
name mpls_lspm trap-name hwmplslspthresholdexceedclear is configured, and the actual BGP
IPv6 LSP usage falls below the lower limit of the clear alarm threshold.
situations:
l If the total number of BGP IPv6 LSPs reaches the upper limit, a limit-crossing alarm is generated.
l If the total number of BGP IPv6 LSPs falls below 95% of the upper limit, a limit-crossing clear
alarm is generated.
----End
4.7.5 Configuring Alarm Thresholds for Total LSPs

This section describes how to configure alarm thresholds for Total LSPs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:

mpls total-lsp-number threshold-alarm upper-limit upper-limit-value lower-limit

lower-limit-value
The upper and lower thresholds of alarms for total LSP usage are configured.
l upper-limit-value specifies the upper threshold of alarms for total LSP usage. An alarm is
generated when the proportion of established LSPs to total supported LSPs reaches the upper
limit.
l lower-limit-value specifies the lower threshold of clear alarms for total LSP usage. A clear
alarm is generated when the proportion of established LSPs to total supported LSPs falls
below the lower limit.
The default upper limit of an alarm for total LSP usage is 80%. The default lower limit of a clear
alarm for total LSP usage is 75%. Using the default upper limit and lower limit is recommended.
NOTE
l This command configures the alarm threshold for total LSP usage. The alarm that the number of LSPs
reached the upper threshold is generated only when the command snmp-agent trap enable feature-
name mpls_lspm trap-name hwmplslspthresholdexceed is configured, and the actual total LSP
usage reaches the upper limit of the alarm threshold. The alarm that the number of LSPs fell below the
lower threshold is generated only when the command snmp-agent trap enable feature-name
mpls_lspm trap-name hwmplslspthresholdexceedclear is configured, and the actual total LSP usage
falls below the lower limit of the clear alarm threshold.
situations:
l If the total number of LSPs reaches the upper limit, a limit-crossing alarm is generated.
l If the total number of LSPs falls below 95% of the upper limit, a limit-crossing clear alarm is
generated.
----End

The following sections provide several examples of MPLS common configurations.
4.8.1 Example for Configuring Load Balancing for MPLS Layer 3

Forwarding
This section provides an example for configuring Layer 3 MPLS load balancing, which consists
of setting up an LDP LSP and configuring load balancing.
On the network shown in Figure 4-3, each node supports MPLS, and devices on the MPLS
backbone network runs OSPF. There are two LSPs from LSRA to LSRD are established over
the path LSRA → LSRB → LSRD and the path LSRA → LSRC → LSRD. Load balancing
needs to be configured on LSRA to implement packet-by-packet load balancing between the
two LSPs.

Figure 4-3 Load balancing for MPLS Layer 3 forwarding

Loopback1
2.2.2.9/32
P
/0 10 OS2
S 1/0 /30 .2. /0
PO 1.1.
2 1.1 /0
. /30 P
0 0 10 OS1
Loopback1 /0/ 0 1 LSRB Loopback1
1.1.1.9/32 OS1 .1/3 .2. /0/ 4.4.4.9/32
1.2 0
P 1.1 /30
.
10
P
LSRA 1 OS 0
0.3 2/0 2/0/ 30 LSRD
.1. /0 S 2/
1/3 LSRC PO 4.1.
0 POS .
10 /0 10
.3. 1/0/
1.2 0 S 2/0 /30
/30 PO 4.1.1
.
10
Loopback1
3.3.3.9/32
1. Set up LDP LSPs between LSRA and LSRD.
2. Configure packet-by-packet load balancing only on the LSP on LSRA.
Data Preparation
l IP addresses of all interfaces, as shown in Figure 4-3, OSPF process number, and area IDs.
Procedure
Assign an IP address and mask to each interface, including loopback interfaces according to
Step 2 Configure OSPF to advertise routes.
After completing the preceding configurations, run the display ip routing-table command on
each LSR. LSRs learn routes from each other.
------------------------------------------------------------------------------



2.2.2.9/32 OSPF 10 1 D 10.1.1.2 Pos1/0/0
3.3.3.9/32 OSPF 10 1 D 10.3.1.2 Pos2/0/0
4.4.4.9/32 OSPF 10 2 D 10.1.1.2 Pos1/0/0
OSPF 10 2 D 10.3.1.2 Pos2/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.2.1.0/30 OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.3.1.0/30 Direct 0 0 D 10.3.1.1 Pos2/0/0
10.3.1.1/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
10.3.1.2/32 Direct 0 0 D 10.3.1.2 Pos2/0/0
10.4.1.0/30 OSPF 10 2 D 10.3.1.2 Pos2/0/0
Step 3 Enable MPLS and MPLS LDP on each node and each interface.
# Configure LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
# Configure LSRB.
<LSRB> system-view
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
# Configure LSRC.
<LSRC> system-view
[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp

# Configure LSRD.
<LSRD> system-view
[LSRD] mpls
[LSRD-mpls] quit
[LSRD] mpls ldp
After completing the preceding configurations, run the display mpls lsp protocol ldp command
on LSRA and LSRD. Two LDP LSPs are set up between LSRA and LSRD.

[LSRA] display mpls lsp protocol ldp
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.9/32 NULL/3 -/Pos1/0/0
4.4.4.9/32 NULL/1025 -/Pos1/0/0
2.2.2.9/32 1024/3 -/Pos1/0/0
3.3.3.9/32 NULL/3 -/Pos2/0/0
3.3.3.9/32 1026/3 -/Pos2/0/0
4.4.4.9/32 NULL/1026 -/Pos2/0/0
Step 4 On LSRA, configure packet-by-packet load balancing only on the LSP.

<LSRA> system-view
[LSRA] load-balance packet
After completing the configurations, run the tracert lsp command on LSRA to check the path
to destination address 4.4.4.9.
<LSRA> tracert lsp ip 4.4.4.9 32
LSP Trace Route FEC: IPV4 PREFIX 4.4.4.9/32 , press CTRL_C to break.
0 Ingress 10.1.1.2/[1025 ]
1 10.1.1.2 140 ms Transit 10.2.1.2/[3 ]
2 4.4.4.9 40 ms Egress
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.9

mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.3.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.3.1.0 0.0.0.3
#
load-balance packet lsp slot 6
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.3.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.4.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.3.1.0 0.0.0.3
network 10.4.1.0 0.0.0.3
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.2 255.255.255.252
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.4.1.2 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 10.2.1.0 0.0.0.3
network 10.4.1.0 0.0.0.3
#
return

4.8.2 Example for Configuring PBR to LSP for Public Network

Packets
This section provides an example for configuring a PBR policy for directing traffic to anLSP.
The configuration procedure involves setting up an LDP LSP and configuring a route filtering
policy.
On the MPLS backbone network shown in Figure 4-4, PE1, PE2, P1, and P2 are LSRs. The
primary LSP is established along the path PE1 → P1 → PE2, and the bypass LSP is along the
patch PE1 → P2 → PE2.
The LDP FRR and PBR are configured for the packets sent from PE1 to PE2. The packets are
forwarded through the bypass LSP that is generated by LDP FRR.
Figure 4-4 Networking diagram for PBR to an LSP for public network packets
Loopback1
2.2.2.9/32
0 P
/0/ /24 17 OS2
1
S .2 2.2. /0/0
PO .1.1 1.1
/24 P
7 2
Loopback1
/ 0 0
/ 41 P1 17 OS Loopback1
1.1.1.9/32 S .11 / 2 2.2 1/0 3.3.3.9/32
PO .1.1 .1. /0
2/2
7 2 4
1
MPLS backbone
PE1 1 POS /0 PE2

72
.3. 2/0/0 S 2/0 /24
.2
1.1
/24 P2 PO .4.1
P 2
17 OS1 /0 17
2.3 /0 S 2/0 1/24
.1. /0 .
2/3 PO .4.1
0 2
17
Loopback1
4.4.4.9/32
1. Establish two or more LSPs on the PE that uses PBR to LSP.

2. Specify the PBR policy name and the policy node on the PE that uses PBR. Set the matching
rules for IP packets and specify the LSP for the filtered public network packets in the policy-
based-route view.
3. Apply the local PBR policy to the PE.

Data Preparation
l IP address of the interfaces, OSPF process ID, and area ID

l PBR name, policy node mode, and precedence of the policy node
l Destination address of the LDP FRR bypass LSP
1. Configure the basic MPLS function to set up LSPs.
For details about configuration, see "Basic MPLS Configuration" in this manual.
In this instance, both RBP to LSP and LDP FRR are used. For detailed information about
LDP FRR configuration, see "Basic MPLS Configuration" in this manual.
In this example, the default policy of triggering LSP establishment. Run the display mpls
lsp command on PE1 to view the two LSPs to PE2 and the bypass LSP passing through
P2.
[PE1] display mpls lsp
----------------------------------------------------------------------
----------------------------------------------------------------------
2.2.2.9/32 NULL/3 -/Pos1/0/0
2.2.2.9/32 1024/3 -/Pos1/0/0
3.3.3.9/32 NULL/1025 -/Pos1/0/0
**LDP FRR** /1025 /Pos2/0/0
4.4.4.9/32 NULL/1026 -/Pos1/0/0
**LDP FRR** /3 /Pos2/0/0
4.4.4.9/32 1025/1026 -/Pos1/0/0
**LDP FRR** /3 /Pos2/0/0
3.3.3.9/32 1026/1025 -/Pos1/0/0
**LDP FRR** /1025 /Pos2/0/0
Traceroute can be successfully performed between PE1 and PE2.

[PE1] tracert 172.2.1.2
traceroute to 172.2.1.2(172.2.1.2) 30 hops max,40 bytes packet
1 172.1.1.2 2 ms 1 ms 1 ms
2 172.2.1.2 3 ms 3 ms 3 ms
The preceding information shows that the packet travel over routes based on the routing
table.
2. Configure an ACL on PE1 to permit the packets destined for POS 1/0/0 on PE2 to pass.
[PE1] acl 3000
[PE-acl-adv-3000] rule permit ip destination 172.2.1.2 0.0.0.0
[PE-acl-adv-3000] quit
3. Configure PBR to direct traffic to a specified LSP on PE1.

[PE1] policy-based-route policy1 permit node 10
[PE1-policy-based-route-policy1-10] if-match acl 3000
[PE1-policy-based-route-policy1-10] apply lsp public 3.3.3.9 secondary
[PE1-policy-based-route-policy1-10] quit
4. Apply the local PBR policy to PE1.

[PE1] ip local policy-based-route policy1

Perform traceroute on PE1. The packets that are transmitted through the specified LSP.

[PE1] tracert 172.2.1.2

traceroute to 172.2.1.2(172.2.1.2) 30 hops max,40 bytes packet
1 * * *
2 172.3.1.2 3 ms 1 ms 1 ms
3 172.4.1.2 16 ms 5 ms 2 ms
Configuration Files
#
sysname PE1
#
ip local policy-based-route policy1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
acl number 3000
rule 5 permit ip destination 172.2.1.2 0
#
interface Pos1/0/0
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
mpls ldp frr nexthop 172.3.1.2
#
interface Pos2/0/0
link-protocol ppp
ip address 172.3.1.1 255.255.255.0
ospf cost 2500
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.3.1.0 0.0.0.255
network 172.1.1.0 0.0.0.255
#
policy-based-route policy1 permit node 10
if-match acl 3000
apply lsp public 3.3.3.9 secondary
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#

interface Pos2/0/0
link-protocol ppp
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 172.4.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 172.3.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 172.4.1.1 255.255.255.0

mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 172.3.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
#
return
4.8.3 Example for Configuring Dynamic BFD to Monitor a BGP

Tunnel
This section provides an example for configuring dynamic BFD to monitor a BGP tunnel. The
configuration involves configuring a BGP tunnel and configuring dynamic BFD for BGP tunnel.
Seamless MPLS integrates the access, aggregation, and core layers on the same MPLS network
to transmit VPN services. Seamless MPLS establishes an E2E BGP tunnel to provide E2E access
services. To rapidly detect faults in BGP tunnels, BFD for BGP tunnel needs to be configured.
In Figure 4-5, the access and aggregation layers belong to one AS, and the core layer belongs
to another AS. NodeBs need to communicate with an MME or SGW over a VPN. To meet this
requirement, inter-AS seamless MPLS can be configured between the CSG and MASG. To
monitor the connectivity of the BGP tunnel, BFD for BGP tunnel needs to be configured.
Figure 4-5 Inter-AS seamless MPLS networking

Access Aggragtion Core
Loopback0 Loopback0 Loopback0 Loopback0 Loopback0

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32 4.4.4.4/32 5.5.5.5/32
GE1/0/0 GE1/0/2 GE1/0/1 GE1/0/2

GE1/0/0 GE1/0/0 GE1/0/0 GE1/0/1
AGG Core
CSG AGG MASG
ASBR ASBR
AS 100 AS 200
NodeB MME/SGW
Table 4-1 Interface parameters
Device Name Interface Name IP Address and Mask
CSG GE 1/0/0 10.1.1.1/24
AGG GE 1/0/0 10.1.1.2/24

Device Name Interface Name IP Address and Mask
GE 1/0/2 10.2.1.1/24
AGG ASBR GE 1/0/0 10.2.1.2/24
GE 1/0/1 10.3.1.1/24
Core ASBR GE 1/0/0 10.3.1.2/24
GE 1/0/2 10.4.1.1/24
MASG GE 1/0/1 10.4.1.2/24
1. Configure inter-AS seamless MPLS.

2. Configure BGP for BGP tunnel.
Data Preparation
l OSPF process ID (1) at the access layer, IS-IS process ID (1) at the aggregation layer, and
OSPF process ID (2) at the core layer
l IS-IS area number (10.0001) and IS-IS system IDs (which are obtained based on loopback0
addresses)
l MPLS LSR IDs: 1.1.1.1 for the CSG, 2.2.2.2 for the AGG, 3.3.3.3 for the AGG ASBR,
4.4.4.4 for the core ASBR, and 5.5.5.5 for the MASG
l Name of a routing policy (policy1)
Procedure
Assign an IP address and mask to each interface, including each loopback interface, according
to Figure 4-5. For configuration details, see Configuration Files in this section.
Configure OSPF with process ID 1 at the access layer, IS-IS with process ID 1 at the aggregation
layer, and OSPF with process ID 2 at the core layer. Configure IGP protocols to advertise the
route to each network segment to which each interface is connected and to advertise the host
route to each loopback address which is used as an LSR ID. For configuration details, see
Step 3 Configure basic MPLS and MPLS LDP functions.
Enable MPLS and MPLS LDP globally on each device and on interfaces in each AS. For

Step 4 Establish IBGP peer relationships at each layer and enable devices to exchange labeled routes.
# Configure CSG.
[CSG] bgp 100
[CSG-bgp] peer 2.2.2.2 as-number 100
[CSG-bgp] peer 2.2.2.2 connect-interface LoopBack 0
[CSG-bgp] peer 2.2.2.2 label-route-capability
[CSG-bgp] network 1.1.1.1 32
[CSG-bgp] quit
# Configure the AGG.

[AGG] bgp 100
[AGG-bgp] peer 1.1.1.1 as-number 100
[AGG-bgp] peer 1.1.1.1 connect-interface LoopBack 0
[AGG-bgp] peer 1.1.1.1 label-route-capability
[AGG-bgp] quit
# Configure the AGG ASBR.

<AGG ASBR> system-view
[AGG ASBR] bgp 100
[AGG ASBR-bgp] peer 2.2.2.2 as-number 100
[AGG ASBR-bgp] peer 2.2.2.2 connect-interface LoopBack 0
[AGG ASBR-bgp] peer 2.2.2.2 label-route-capability
[AGG ASBR-bgp] quit
# Configure the core ASBR.

<Core ASBR> system-view
[Core ASBR] bgp 200
[Core ASBR-bgp] peer 5.5.5.5 as-number 200
[Core ASBR-bgp] peer 5.5.5.5 connect-interface LoopBack 0
[Core ASBR-bgp] peer 5.5.5.5 label-route-capability
[Core ASBR-bgp] quit
# Configure the MASG.

[MASG] bgp 100
[MASG-bgp] peer 4.4.4.4 as-number 100
[MASG-bgp] peer 4.4.4.4 connect-interface LoopBack 0
[MASG-bgp] peer 4.4.4.4 label-route-capability
[MASG-bgp] network 5.5.5.5 32
[MASG-bgp] quit
Step 5 Establish an EBGP peer relationship between the AGG ASBR and core ASBR and enable these
devices to exchange labeled routes.

[AGG ASBR] interface GigabitEthernet 1/0/1
[AGG ASBR-GigabitEthernet1/0/1] ip address 10.3.1.1 24
[AGG ASBR-GigabitEthernet1/0/1] mpls
[AGG ASBR-GigabitEthernet1/0/1] quit
[AGG ASBR] bgp 100
[AGG ASBR-bgp] peer 10.3.1.2 label-route-capability check-tunnel-reachable
[AGG ASBR-bgp] quit

[Core ASBR] interface GigabitEthernet 1/0/0
[Core ASBR-GigabitEthernet1/0/0] ip address 10.3.1.2 24

[Core ASBR-GigabitEthernet1/0/0] mpls

[Core ASBR-GigabitEthernet1/0/0] quit
[Core ASBR] bgp 200
[Core ASBR-bgp] peer 10.3.1.1 label-route-capability check-tunnel-reachable
Step 6 Configure each AGG as an RR to help the CSG and MASG obtain the route destined for each
other's loopback interface.

[AGG] bgp 100
[AGG-bgp] peer 1.1.1.1 reflect-client
[AGG-bgp] peer 1.1.1.1 next-hop-local
[AGG-bgp] quit
Step 7 Configure a routing policy on each device to establish a BGP LSP in a BGP tunnel.
# Configure a routing policy for advertising routes matching Route-Policy conditions to the
CSG's BGP peer.
[CSG] route-policy policy1 permit node 1
[CSG-route-policy] apply mpls-label
[CSG-route-policy] quit
[CSG] bgp 100
[CSG-bgp] peer 2.2.2.2 route-policy policy1 export
[CSG-bgp] quit
Repeat this step for the MASG. For configuration details, see Configuration Files in this section.
AGG's BGP peer.
[AGG] route-policy policy1 permit node 1
[AGG-route-policy] if-match mpls-label
[AGG-route-policy] apply mpls-label
[AGG-route-policy] quit
[AGG] bgp 100
[AGG-bgp] peer 1.1.1.1 route-policy policy1 export
[AGG-bgp] quit
Repeat this step for the AGG ASBR and core ASBR. For configuration details, see
Step 8 Configure BFD for BGP tunnel.
# On the CSG, enable the MPLS capability to dynamically establish BGP BFD sessions based
on host addresses.
[CSG] bfd
[CSG-bfd] quit
[CSG] mpls
[CSG-mpls] mpls bgp bfd enable
[CSG-mpls] mpls bgp bfd-trigger-tunnel host
[CSG-mpls] quit
# On the MASG, enable the MPLS capability of passively creating a BFD session.
[MASG] bfd
[MASG-bfd] mpls-passive
[MASG-bfd] quit

After completing the preceding configurations, run the display mpls bfd session command on
the CSG to view information about the BFD session that monitors a BGP tunnel.
[CSG] display mpls bfd session protocol bgp
-------------------------------------------------------------------------------
BFD Information: BGP Tunnel
-------------------------------------------------------------------------------
5.5.5.5 8192 - 2.2.2.2 - Up
Run the display mpls lsp protocol bgp verbose command on the CSG to view detailed
information about all BGP LSPs. The command output shows that the BFD session is Up.
[CSG] display mpls lsp protocol bgp verbose
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No : 1
VrfIndex :
RD Value : 0:0
Fec : 5.5.5.5/32
Nexthop : 2.2.2.2
In-Label : NULL
Out-Label : 900004
LspIndex : 22528
Token : 0x800804
LsrType : Ingress
Label Operation : PUSH
Mpls-Mtu : ------
FrrToken : 0x0
BGPKey : -------
Bfd-State : Up
Exp-Mode : ----
No : 2
VrfIndex :
RD Value : 0:0
Fec : 1.1.1.1/32
Nexthop : -------
In-Label : 900003
Out-Label : NULL
LspIndex : 22529
Token : 0x0
LsrType : Egress
Label Operation : POP
Mpls-Mtu : ------
FrrToken : 0x0
BGPKey : -------

Bfd-State : ---
Exp-Mode : ----
----End
Configuration Files
l CSG configuration file
#
sysname CSG
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
mpls bgp bfd enable
mpls bgp bfd-trigger-Tunnel host
#
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 1.1.1.1 255.255.255.255
peer 2.2.2.2 enable
peer 2.2.2.2 route-policy policy1 export
peer 2.2.2.2 label-route-capability
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
route-policy policy1 permit node 1
apply mpls-label
#
return
l AGG configuration file

#
sysname AGG
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
isis 1
network-entity 10.0001.0020.0200.2002.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
mpls

mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 1.1.1.1 reflect-client
peer 1.1.1.1 next-hop-local
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
#
if-match mpls-label
apply mpls-label
#
return
l AGG ASBR configuration file

#
sysname AGG ASBR
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
isis 1
network-entity 10.0001.0030.0300.3003.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
mpls
#

interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 10.3.1.2 label-route-capability check-tunnel-reachable
#
if-match mpls-label
apply mpls-label
#
return
l Core ASBR configuration file

#
sysname Core ASBR
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
mpls
#
undo shutdown
ip address 10.4.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 5.5.5.5 enable
#
ospf 2
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.4.1.0 0.0.0.255
#

if-match mpls-label
apply mpls-label
#
return
l MASG configuration file

#
sysname MASG
#
bfd
mpls-passive
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 5.5.5.5 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 5.5.5.5 255.255.255.255
peer 4.4.4.4 enable
#
ospf 2
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 10.4.1.0 0.0.0.255
#
apply mpls-label
#
return

Configuration Guide - MPLS 5 MPLS OAM Configuration
5 MPLS OAM Configuration
About This Chapter
This chapter describes the principles of Multiprotocol Label Switching Operation,

Administration and Maintenance (MPLS OAM), procedures of configuring protection switching
and remote advertisement of the link status, and provides configuration examples.
5.1 Introduction to MPLS OAM

MPLS OAM is applied to the MPLS layer for operation, maintenance, and management.
5.2 Configuring Basic MPLS OAM Functions of LSP

MPLS OAM is configured on the ingress and egress of an LSP to detect connectivity of the LSP.
MPLS OAM can also detect the connectivity of a TE LSP.
5.3 Configuring MPLS OAM Protection Switching of LSP

MPLS OAM protection switching enables a tunnel to protect one or more tunnels. The tunnel
under protection is a working tunnel, and the tunnel providing protection is a protection tunnel.
When a protection tunnel protects one working tunnel, tunnel protection is in 1:1 mode.
5.4 Configuring MPLS OAM to Monitor a Static Bidirectional Co-routed LSP

MPLS OAM can be configured to monitor the connectivity of a static bidirectional co-routed
LSP.
5.5 Setting the Trap Threshold for Bandwidth Consumption in the Fast Packet Transmission
Channel
You can set the trap threshold for the bandwidth consumption in the fast packet transmission
channel on the LPU to control the bandwidth consumption.
5.6 Configuring MPLS OAM to Monitor PW Connectivity

MPLS OAM can be configured to monitor connectivity of VLL PWs including SS-PWs, MS-
PWs, static PWs, and dynamic PWs.
5.7 Maintaining MPLS OAM

You can use display commands to monitor MPLS OAM and the tunnel protection group.

The following sections provide several examples for configuring MPLS OAM to detect LSPs
and configuring the association between MPLS OAM and a protection group for performing
protection switching.

5.1 Introduction to MPLS OAM

MPLS OAM is applied to the MPLS layer for operation, maintenance, and management.
5.1.1 MPLS OAM Overview

MPLS OAM can effectively detect, identify, and locate faults on the MPLS user plane.
The operation, administration and maintenance (OAM) is an effective method of reducing the
cost of network maintenance. The MPLS OAM mechanism is used on the MPLS layer.
MPLS OAM mechanism is independent of the upper and lower layers and provides the following
functions:
l Detects, identifies, and locates faults on the MPLS user plane.

l Performs protection switching in the case of link or node failure to shorten the defect
duration and improve the availability.
For details about requirements for OAM functionality for MPLS networks, refer to the ITU-T
Recommendation Y.1710. For details about the OAM mechanism for MPLS networks, see ITU-
T Recommendation Y.1711.
5.1.2 MPLS OAM Features Supported by the NE80E/40E

MPLS OAM provides functions such as connectivity detection, fault detection, and protection
switching.
Basic MPLS OAM Detection

The basic detection function of MPLS OAM refers to the detection on the connectivity of an
LSP.
Figure 5-1 Schematic diagram of MPLS OAM connectivity detection
CV
F D /F
/F F D
C V
Ingress Egress
BD I
I BD
As shown in Figure 5-1, procedures of MPLS OAM connectivity detection are as follows:

1. The ingress sends a connectivity verification ( CV ) or an fast failure detection ( FFD )

packet to the egress along the LSP to be detected.
2. The egress judges whether the received packet is correct by comparing the packet type,
frequency, and trail termination source identifier( TTSI ) in the received packet with
expected values recorded on the egress. It counts the number of the correct packets and the
error packets received within a certain period, and monitors the LSP connectivity.
3. When the egress detects a defect on the LSP, it analyzes the defect type and sends a
Backward Defect Indication (BDI) packet carrying the defect information to the ingress
through the backward tunnel. This enables the ingress to know the defect status in real time.
If a protection group has been configured in the correct manner, the corresponding
switching is triggered.
Backward Tunnel
When configuring the basic OAM detection function, bind a backward tunnel to the detected
LSP.
A backward tunnel is an LSP with its ingress and egress being converse to the ingress and egress
of the detected LSP. It also can be a non-MPLS path connected to the ingress and egress of the
detected LSP.
There are three types of backward tunnels:
l Private backward LSP

l Shared backward LSP
l A non-MPLS backward path
NOTE
At current, only LSPs can function as backward tunnels on the NE80E/40E.
Auto-protocol Function of MPLS OAM

The ITU-T Y.1710 protocol has the following drawbacks:
l If the OAM function on the LSP ingress starts later than that on the LSP egress, or the
egress is enabled with the OAM function but the ingress is not, the egress generates a Loss
of Connectivity Verification defect (dLOCV) alarm.
l If the OAM function is disabled on the ingress whereas is enabled on the egress, the egress
generates a dLOCV alarm .
l To modify the type of the detection packet or the frequency at which detection packets are
sent, you must disable the OAM function on the egress and the ingress separately.
l OAM parameters need to be configured separately on the ingress and egress. This may
cause the detection packet type and the frequency at which detection packets are sent to be
different on the ingress and egress.
The NE80E/40E uses the OAM auto-protocol to solve problems existing in the ITU-T Y.1710.
The OAM auto-protocol is configured on the egress. It provides functions of initial packet
triggering and dynamic enabling or disabling.

Protection Switching
In protection switching, a protection tunnel (backup tunnel) is set up for the working tunnel
(primary tunnel). A working tunnel and a protection tunnel compose a protection group. When
the working tunnel fails, the data flow switches to the protection tunnel; improving the network
reliability.
The difference between protection switching and CR-LSP backup are as follows:
l Protection switching uses one tunnel to protect another tunnel. Attributes of every tunnel
in the tunnel protection group are independent. For example, the protection tunnel with the
bandwidth being 10 Mbit/s can protect the working tunnel that requires 100 Mbit/s
bandwidth protection.
l CR-LSP backup has the primary and backup CR-LSPs in the same tunnel group. The
backup CR-LSP protects the primary CR-LSP. Except for TE FRR, attributes of the primary
and backup CR-LSPs, such as the bandwidth, setup priority, and holding priority, are
identical.
Protection Mode
The NE80E/40E supports the following protection switching modes:
l 1:1 protection
One working tunnel and one protection tunnel exist between the ingress and the egress.
– Data is generally forwarded through the working tunnel.
– When the working tunnel fails, the ingress performs protection switching and switches
the data flow to the protection tunnel for transmission.
l N:1 protection
As shown in Figure 5-2, one tunnel provides protection for several working tunnels.
This mode is applicable to a mesh network for saving bandwidth.
Figure 5-2 N:1 protection mode
Working tunnel-1
RouterA Working tunnel-2 RouterB
Protection tunnel
Backward tunnel
: Traffic of working tunnel-1
: Traffic of working tunnel-2
As shown in Figure 5-3, when one of the working tunnels fails, its traffic switches to the
shared protection tunnel.

Figure 5-3 N:1 protection mode - working tunnel fails
Working tunnel-1
Working tunnel-2 Rou

Router A
Protection tunnel
Reverse tunnel
: Traffic of working tunn

: Traffic of working tunn
: Working tunnel-1 fails
5.2 Configuring Basic MPLS OAM Functions of LSP

MPLS OAM is configured on the ingress and egress of an LSP to detect connectivity of the LSP.
MPLS OAM can also detect the connectivity of a TE LSP.

MPLS OAM can detect an ordinary LSP and a TE LSP. Before configuring MPLS OAM, create
an LSP. The following sections describe the usage scenario, pre-configuration tasks, and the
data required for the configuration.
Usage Scenario
The NE80E/40E provides MPLS OAM to detect the connectivity of an RSVP-TE LSP, a static
CR-LSP, and a static LSP.
To implement MPLS OAM functions, create a backward LSP for bearing BDI packets. The type
of the backward LSP can be different from that of the tested LSP, but the backward LSP must
be bound to a TE tunnel.
Before configuring basic MPLS OAM functions, complete the following tasks:

l Create a forward LSP, the LSP to be detected by OAM and is bound to the TE tunnel.
l Create a backward LSP.

NOTE
If the forward LSP is static and the backward LSP is dynamic, and the backward LSP is in the shared mode,
you must specify lsrid ingress-lsr-id and tunnel-id tunnel-id when running the static-lsp egress command
or the static-cr-lsp egress command to create a forward LSP. For creating the LSP bound to a TE tunnel,
refer to the chapter "MPLS TE Configuration."
Data Preparation
To configure basic MPLS OAM functions, you need the following data.
No. Data
1 Ingress: Number of tunnel interfaces bound to the detected LSP
2 (Optional) Ingress: reverse tunnel

l If a static LSP or a static CR-LSP acts as the backward tunnel, the name of the
static LSP or the static CR-LSP is required.
l If a dynamic LSP (RSVP-TE LSP) acts as the backward tunnel, the LSP ID and
tunnel ID are required.
3 Egress: Number of the tunnel interface that is bound to the backward LSP and the
protection mode
4 Egress: detected LSP

l If a static LSP or a static CR-LSP is to be detected, the name of the LSP, LSR ID,
and tunnel ID are required.
l If a dynamic LSP (RSVP-TE LSP) is to be detected, the LSR ID and the tunnel
ID are required.
5 (Optional) MPLS OAM parameters

l Parameters for the ingress: detection type, frequency at which FFD packets are
sent, and priority of the detection packet.
l Parameters for the egress: detection type, frequency at which FFD packets are
sent, status of the auto-protocol (enabled or disabled), timeout period of the auto-
protocol, and frequency at which BDI packets are sent.
NOTE
l The backward LSP must be specified on the egress; otherwise, BDI packets cannot be correctly sent
to the source end.
l If a shared backward LSP is used, you do not need to specify the backward LSP on the ingress.
5.2.2 Configuring MPLS OAM on the Ingress

When configuring OAM on the ingress of an LSP, you can configure a backward tunnel as
required.
Context
Perform the following steps on the ingress of the LSP:

Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls oam
MPLS OAM is enabled globally.
By default, MPLS OAM is disabled globally.
Step 4 Run:
quit
Step 5 Configure MPLS OAM parameters for the ingress.
If the PHP function is not configured when a backward LSP is set up, you must specify the
backward LSP when configuring parameters for the MPLS OAM ingress.
l If no backward LSP is specified, run:

mpls oam ingress tunnel interface-number [ type { cv | ffd frequency ffd-fre } ]
[ backward-lsp share ] [ compatibility-mode { ptn-mode | router-mode } ] [ bdi-
frequency { detect-freq | per-second } ]
NOTE
Parameters of the backward LSP depend on the configuration of the egress.

l If a backward LSP is specified, run:
mpls oam ingress tunnel interface-number [ type { cv | ffd frequency ffd-fre } ]
backward-lsp { lsp-name lsp-name | lsr-id rev-ingress-lsr-id tunnel-id rev-
tunnel-id } [ compatibility-mode { ptn-mode | router-mode} ] [ bdi-frequency
{ detect-freq | per-second } ]
If the backward LSP is a static LSP or a static CR-LSP, you cannot configure it in private
mode.
If lsrid ingress-lsr-id and tunnel-id tunnel-id are specified when you run the static-lsp
egress lsp-name incoming-interface interface-type interface-number in-label in-label
[ lsrid ingress-lsr-id tunnel-id tunnel-id ] command or the static-cr-lsp egress lsp-name
incoming-interface interface-type interface-number in-label in-label [ lsrid ingress-lsr-id
tunnel-id tunnel-id ] command to create a backward LSP, you can use these two parameters
specify parameters in this step; otherwise, you can specify only the parameter lsp-name lsp-
name.

NOTE
l Different types of devices to be connected must be configured with the same compatible mode,
either PTN or router model. Inconsistent compatible mode settings lead to a connection failure.
l If automatic OAM is configured on two devices, its parameters must be modified when both the
devices work in the same mode, either PTN or router mode. Inconsistent compatible mode settings
lead to a connection failure.
By default, the type of the detection packet is CV. The frequency at which CV packets are
sent is one second.
Step 6 Run:
mpls oam ingress enable { all | tunnel interface-number }
OAM is enabled on the ingress.
----End
5.2.3 Configuring MPLS OAM on the Egress

When configuring OAM on the egress of an LSP, enable or disable the OAM auto protocol. By
default, the OAM auto protocol is enabled.
Context
Perform the following steps on the egress of the LSP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
mpls
Step 3 Run:
mpls oam
Step 4 Run:
quit
Step 5 Configure OAM parameters for the egress.

l Run:
mpls oam egress { lsp-name lsp-name | lsr-id ingress-lsr-id tunnel-id tunnel-
id } [ auto-protocol [ overtime over-time ] ] [ backward-lsp tunnel interface-
number [ private | share ] [ bdi-frequency { detect-freq | per-second } ] ]
The auto-protocol extension of OAM is enabled.

l Run:

mpls oam egress { lsp-name lsp-name | lsr-id ingress-lsr-id tunnel-id tunnel-

id } type { cv | ffd frequency ffd-fre } [ backward-lsp tunnel interface-number
[ private | share ] [ bdi-frequency { detect-freq | per-second } ] ]
OAM parameters are configured for the egress when the auto-protocol extension of OAM is
disabled.
If lsrid ingress-lsr-id and tunnel-id tunnel-id are specified when you run the static-lsp egress
lsp-name incoming-interface interface-type interface-number in-label in-label [ lsrid ingress-
lsr-id tunnel-id tunnel-id ] command or the static-cr-lsp egress lsp-name incoming-
interface interface-type interface-number in-label in-label [ lsrid ingress-lsr-id tunnel-id
tunnel-id ] command to create a forward tunnel, you can use these two parameters in this step;
otherwise, you can specify only the parameter lsp-name lsp-name.
By default, the auto-protocol function of OAM is enabled. The timeout period for the first packet
to wait for response is five minutes.
By default, the backward LSP is in the shared mode. When the backward LSP is a static LSP or
a CR-LSP, it is in the private mode.
By default, the frequency at which BDI packets are sent through the backward LSP is detect-
freq.
NOTE
If a shared backward LSP is used to enable the OAM auto-protocol extension in Step 5, Step 6 is not
necessary. When the egress receives the first CV/FFD packet, it automatically records the packet type and
the frequency at which CV/FFD packets are sent, and starts to detect the connectivity.
Step 6 Run:
mpls oam egress enable { all | lsp-name lsp-name | lsr-id ingress-lsr-id tunnel-id
tunnel-id }
OAM is enabled on the egress.
----End

After the configuration, you can use display commands on the ingress and egress of an LSP to
view information about the LSP, OAM detection, and OAM backward LSP.
Prerequisites
The basic MPLS OAM functions have been configured.
Procedure
l Run display mpls oam ingress { all | tunnel interface-number } [ slot slot-id | verbose ]
command to view MPLS OAM information on the ingress.
l Run display mpls oam egress { all | lsp-name lsp-name | lsr-id ingress-lsr-id tunnel-id
tunnel-id } [ slot slot-id | verbose ] command to view MPLS OAM information on the
egress.
----End

Example
If the configurations succeed, run the commands mentioned above and you can view the
following results:
l Basic information about the LSP, including the tunnel name, LSP type, LSP ingress LSR
ID, and LSP tunnel ID
l Basic information about OAM, including the tunnel name, TTSI, packet type, and
frequency
l OAM detection information, including the packet type, frequency at which detection
packets are sent, detection status, and defect status. If the link works properly, the detection
status is Start and the defect status is non-defect
l Information about backward LSP, including the sharing mode and configurations of the
backward LSP
5.3 Configuring MPLS OAM Protection Switching of LSP

MPLS OAM protection switching enables a tunnel to protect one or more tunnels. The tunnel
under protection is a working tunnel, and the tunnel providing protection is a protection tunnel.
When a protection tunnel protects one working tunnel, tunnel protection is in 1:1 mode.

MPLS OAM protection switching is a high-reliability technology for tunnel protection. After
one or more working tunnels and a protection tunnel are configured, the protection tunnel can
protect the working tunnels, which improves reliability of the working tunnels. The following
sections describe the usage scenario, pre-configuration tasks, and the data required for the
configuration.
Usage Scenario
If the tunnel requires high availability, you can configure the MPLS OAM protection switching
to protect the tunnel.
MPLS OAM protection switching enables one tunnel to protect one or multiple tunnels. The
tunnel under protection is a working tunnel, and the tunnel providing protection is a protection
tunnel. A working tunnel and a protection tunnel compose a protection group.
One protection tunnel can protect one or more working tunnels. The protection mechanism in
which one protection tunnel protects only one working tunnel is called 1:1 protection; one
protection tunnel protects two or more working tunnel is called N:1 protection. "N" indicates
the number of the working tunnels in the same protection group. Working tunnels in the same
protection group use the same ingress and egress.
The NE80E/40E supports 1:1 protection and N:1 protection.
l Working tunnel and protection tunnel
Attributes of every tunnel in the tunnel protection group are not related. For example, the
protection tunnel with the bandwidth being 50 Mbit/s can protect the working tunnel with
the bandwidth being 100 Mbit/s.
You can configure TE FRR on the working tunnel in the protection group to provide dual
protection for the working tunnel. The protection tunnel cannot serve as the TE FRR

primary tunnel to be protected by other tunnels. In addition, the protection tunnel cannot
be enabled with TE FRR.
l Protection switching trigger mechanism
The NE80E/40E complies the following switch request criteria to initiate (or prevent) a
Table 5-1 Switch Request Criteria
Switch Request Order of Priority Description
Clear Highest Clears all switching requests

initiated through commands,
including forced switching and
manual switching. Traffic switching
is not performed in the case of signal
failure.
Lockout of ↑ Prevents traffic from switching to the

Protection protection tunnel even though the
working tunnel fails.
Forced Switch ↑ Forcibly switches traffic form the

working tunnel to the protection
tunnel regardless of whether the
protection tunnel functions properly
(unless a higher priority switch
request is in effect).
Signal Fail ↑ Automatically triggers the protection

switching between the working
tunnel and the protection tunnel in
the case of a signal failure.
Manual Switch ↑ Switches traffic from the working

tunnel to the protection tunnel only
when the protection tunnel functions
properly or switches traffic from the
protection tunnel to the working
tunnel only when the working tunnel
functions properly.
Wait To Restore ↑ Switches traffic from the protection

tunnel to the working tunnel after the
working tunnel recovers for a certain
period specified by the wait-to-
restore (WTR) timer.
No Request Lowest Indicates that there is no switching

request.

Before configuring MPLS OAM protection switching, complete the following tasks:
l Create the working tunnel and protection tunnel.

l Configure basic MPLS OAM functions.
Data Preparation
To configure MPLS OAM protection switching, you need the following data.
No. Data
1 Number of the working tunnel in the protection group

NOTE
The maximum number of working tunnels in a protection group is equal to or smaller than 16
depending on the License.
2 Tunnel ID of the protection tunnel in the protection group
3 Parameters for the protection group, such as the hold off time, revertive mode, and
WTR time
5.3.2 Configuring a Tunnel Protection Group

You can configure a tunnel protection group for the primary tunnel on the ingress of a tunnel.
In addition, you can configure the switchback delay time and the switchback mode. The
switchback mode can be classified into the revertive mode and non-revertive mode. By default,
revertive mode is used. In revertive mode, you can set the switchback delay time .
Context
Perform the following steps on the ingress of the tunnel:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
mpls te protection tunnel tunnel-id [ holdoff holdoff-time ] [ mode { non-
revertive | revertive [ wtr wtr-time ] } ]
The working tunnel is added to the protection group.
Note the following parameters or concepts before perform this step:

l The tunnel-id indicates the tunnel ID of the protection tunnel.

l The hold-off time indicates the time between declaration of signal failure and the initialization
of the protection switching algorithm. holdoff-time specifies the number of steps for the hold-
off time, ranging from 0 to 100. By default, the hold-off time is 0. The value of each step is
100, in milliseconds.
NOTE
Multiplying 100 milliseconds by holdoff-time, you can get the hold-off time.
l Non-revertive mode indicates that traffic does not switch back to the working tunnel even
though the working tunnel recovers.
l Revertive mode indicates that traffic switches back to the working tunnel when the working
tunnel recovers.
By default, the protection group is in revertive mode.
l Wait to Restore time (WTR time) indicates the time to be waited before traffic switching.
The parameter wtr-time indicates the number of steps, ranging from 0 to 60. The default value
is 24. The value of each step is 30, in seconds.
NOTE
Multiplying 30 seconds by wtr-time, you can get the value of WTR time.
NOTE
If the number of the working tunnels in the same protection group is N, perform Step 2 and Step 3 for N
times by using different interface-number.
Step 4 Run:
mpls te commit
The current configuration of the tunnel protection group is committed.
----End
Follow-up Procedure
Configurations described in this section are also applicable in modifying the configuration of
the tunnel protection group.
Besides configuring a tunnel protection group to protect the working tunnel, you can configure
TE FRR on the working tunnel in the protection group to provide dual protection for the working
tunnel. The protection tunnel cannot serve as the working tunnel to be protected by other tunnels.
In addition, the protection tunnel cannot be enabled with TE FRR.
5.3.3 (Optional) Configuring the Protection Switching Trigger

Mechanism
After configuring a tunnel protection group, you can configure a trigger mechanism of protection
switching to force traffic to switch to the primary LSP or the backup LSP. Alternatively, you
can perform switchover manually.
Context
Pay attention to the switch request criteria before configuring the protection switching trigger
mechanism.

Perform the following steps on the ingress of the tunnel protection group as required:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Select one of the following protection switching trigger methods as required:
l To switch traffic to the protection tunnel, run:
mpls te protect-switch manual
l To cancel the configuration of the protection switching trigger mechanism, run:

mpls te protect-switch clear
Step 4 Run:
mpls te commit
----End
5.3.4 (Optional) Enabling MPLS OAM to Detect Bidirectional LSPs

When the working and the protection tunnels have backward LSPs, you can enable MPLS OAM.
MPLS OAM to detect bidirectional LSPs.
Context
Before performing the following configurations, configure backward LSPs for the working and
protection tunnels. The working LSP and protection LSP, and their reverse LSPs compose
bidirectional LSPs.
NOTE
The backward LSP must be a static LSP or static CR-LSP. The working LSP and protection LSP can be a
static LSP, static CR-LSP, or RSVP LSP.
It is recommended that the LSP and the backward LSP of a bidirectional LSP be both static LSPs or both
static CR-LSPs; the protection LSP and the backward LSP are all static LSPs or all static CR-LSPs.
On the ingress, the inbound interface of the backward LSP and the outbound interface of the working LSP
or the protection LSP must be the same.
Procedure
l Enable MPLS OAM to detect the bidirectional LSP of the working tunnel.
Perform the following steps on the ingress of the working tunnel:
1. Run:
system-view


2. Run:
The tunnel interface view of the working tunnel is displayed.

3. Run:
The backward LSP of the working tunnel is specified.

4. Run:
mpls te commit
The current configuration of the working tunnel is committed.

l Enable MPLS OAM to detect the bidirectional LSP of the protection tunnel.
Perform the following steps on the ingress of the protection tunnel:
1. Run:
system-view

2. Run:
The tunnel interface view of the protection tunnel is displayed.

3. Run:
The backward LSP of the protection tunnel is specified.

4. Run:
mpls te commit
The current configuration of the protection tunnel is committed.
----End

After the configurations, you can use the display commands to view information about the tunnel
protection group and tunnel bindings.
Prerequisites
The MPLS OAM protection switching function has been configured.
Procedure
l Run display mpls te protection tunnel { all | tunnel-id | interface tunnel interface-
number } [ verbose ] command to check information about a tunnel protection group.
l Run display mpls te protection binding protect-tunnel { tunnel-id | interface tunnel
interface-number } command to check the protection relationship of the tunnel.
----End

Example
After the configuration succeeds, run the preceding commands to view information about the
protection group.
5.4 Configuring MPLS OAM to Monitor a Static

Bidirectional Co-routed LSP
MPLS OAM can be configured to monitor the connectivity of a static bidirectional co-routed
LSP.

Before configuring MPLS OAM to monitor a static bidirectional co-routed LSP, familiarize
yourself with the usage scenario, complete the pre-configuration tasks, and obtain the data
Usage Scenario
The bidirectional co-routed LSP technique constitutes the fundamentals of the next-generation
packet-switching transport networks. Carriers combine MPLS-based packet switching
techniques with their experience of operating conventional transport networks, such as
Synchronous Digital Hierarchy (SDH) networks and optical transport networks (OTNs). The
combination enables the next-generation transport network to support the same services and
operation and management (O&M) methods that optical transport networks support. To measure
up the O&M and reliability benchmarks set by optical transport networks, the next-generation
transport networks provide comprehensive OAM capabilities for bidirectional co-routed LSPs.
MPLS OAM monitors the connectivity of bidirectional co-routed LSPs and can trigger a traffic
switchover after detecting a fault, minimizing traffic loss. MPLS OAM also supports flexible
detection frequency settings.
Before configuring MPLS OAM to monitor a static bidirectional co-routed LSP, complete the
following task:
l 3.3 Configuring a Static Bidirectional Co-routed CR-LSP

NOTE
The NE80E/40E supports only static bidirectional co-routed LSPs.
Data Preparation
To configure MPLS OAM to monitor a static bidirectional co-routed LSP, you need the
following data.

No. Data
1 Tunnel numbers of a static bidirectional co-routed LSP and MPLS OAM parameters,
including:
l Detection type
l Interval at which connectivity verification (CV) or fast failure detection (FFD)
packets and the interval at which backward defect indication (BDI) packets are
sent
l OAM auto protocol extension
l Timeout period of the OAM auto protocol
5.4.2 Configuring MPLS OAM Parameters

Correct MPLS OAM parameters need to be configured on both ends of a static bidirectional co-
routed LSP.
Context
Perform the following steps on both ends of a static bidirectional co-routed LSP:
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls oam

MPLS OAM is disabled globally by default.
Step 4 Run:
quit

Step 5 Run:
mpls-oam
The MPLS-OAM view is created and displayed.

Step 6 Run:
mpls oam bidirectional-tunnel tunnel interface-number type { cv | ffd frequency ffd-
fre } [ auto-protocol [ overtime overtime ] ] [ compatibility-mode mode ] [ bdi-
frequency { per-second | detect-freq } ]

MPLS OAM parameters are set.
NOTE
The same compatibility mode must be configured on the two ends of a static bidirectional co-routed LSP.
A compatibility mode inconsistency causes a communication failure in the following situations:
l Two devices of different types communicate with each other.
l The OAM auto protocol is used on the two ends of a static bidirectional co-routed LSP.
----End
5.4.3 Enabling MPLS OAM

MPLS OAM can be manually enabled when the OAM auto protocol is not configured.
Context
MPLS OAM does not start automatically if the mpls oam bidirectional-tunnel command
without the auto-protocol parameter is configured. To manually enable MPLS OAM, run the
mpls oam bidirectional-tunnel enable command.
Perform the following steps on both ends of a static bidirectional co-routed LSP:
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls-oam
The MPLS-OAM view is created and displayed.

Step 3 Run:
mpls oam bidirectional-tunnel enable { send | receive } { all | tunnel interface-
number }
MPLS OAM is configured to monitor a static bidirectional co-routed LSP.
NOTE
Run the mpls oam bidirectional-tunnel enable send command and mpls oam bidirectional-tunnel
enable receive command to enable MPLS OAM on a node. Run the undo mpls oam bidirectional-tunnel
enable receive command and undo mpls oam bidirectional-tunnel enable send command to disable
MPLS OAM on a node. Running commands in reverse order causes a detection error.
----End

After completing the configuration, run the display command to check MPLS OAM
configurations on both ends of a static bidirectional co-routed LSP.
Prerequisites
MPLS OAM that monitors a static bidirectional co-routed LSP has been configured.

Procedure
l Run the display mpls oam bidirectional-tunnel { all | tunnel tunnel-number }
{ verbose | slot slot-id } command to check MPLS OAM parameters and the MPS OAM
status.
----End
Example
Run the display mpls oam bidirectional-tunnel command to view MPLS OAM parameters
and the MPLS OAM status.
<HUAWEI> display mpls oam bidirectional-tunnel tunnel1/0/0 verbose
--------------------------------------------------------------------
Verbose information about NO.1 OAM
--------------------------------------------------------------------
bidirectional Tunnel basic information:
-------------------------------------------------
Tunnel-name : Tunnel1/0/0
Lsp signal status : Up
Lsp establish type : Rsvp lsp
Lsp ingress lsr-id : 1.1.1.1
Lsp tnl-id : 1
Lsp-id : 1
-------------------------------------------------
OAM basic information:
-------------------------------------------------
OAM Index : 256
OAM Select Board : --
OAM Enable Direction : Send & Receive
Auto Protocol : Disable
Auto Overtime (s) : --
Compatibility Mode : PTN Mode
-------------------------------------------------
OAM detect information:
-------------------------------------------------
Send Type : FFD
Send Frequency (ms) : 500
Receive Type : FFD
Receive Frequency (ms) : 500
Detect State : Stop
Defect State : Non-defect
BDI Defect State : --
Bdi-frequency : Detect frequency
Available State : Available
Unavailable Time (s) : 0
Hardware Error Info : No error
5.5 Setting the Trap Threshold for Bandwidth Consumption

in the Fast Packet Transmission Channel
You can set the trap threshold for the bandwidth consumption in the fast packet transmission
channel on the LPU to control the bandwidth consumption.
Applicable Environment
If ETH-OAM 802.1ag(CFM), BFD, MPLS OAM, or MQEis configured on the router, protocol
packets of these services are frequently transmitted. For example, ETH-OAM 802.1ag packets

are transmitted at an interval of 3.3 ms. Therefore, a large number of sessions are created, causing
great bandwidth consumption in the fast packet transmission channel on the LPU. If the
bandwidth consumption reaches the trap threshold, service packets may be randomly dropped;
the sessions may frequently alternate between Up and Down; MQE data may be inaccurate.
You can set the trap threshold for the bandwidth that is consumed by each service that runs in
the fast packet transmission channel, in percentage. If the bandwidth consumed by a service
session exceeds the set threshold, the device reports a trap to the NMS.
Procedure
Step 1 Run:
system-view

Step 2 Run:
oam-bandwidth threshold alarm-threshold slot slot-id
The trap threshold is set for the bandwidth consumption in the fast packet transmission channel.
alarm-threshold is an integer ranging from 70 to 99. The default value is 80.
----End

After the configuration is complete, perform the following operation to verify that the
configuration is correct.
Run the display oam-bandwidth slot slot-id command to check the OAM bandwidth
consumption. For example:
[HUAWEI] display oam-bandwidth slot 2
OAM bandwidth information on slot 2:
Current tx bandwidth is 0 bps
Current rx bandwidth is 0 bps
Max bandwidth is 2850000000 bps
Free bandwidth is 2850000000 bps
Bandwidth alarm threshold is 80%
Bandwidth exceed threshold: NO
OAM bandwidth detail information on slot 2:

EOAM-1ag bandwidth-usage info:
Session tx total bandwidth is: 0 bps
Session rx total bandwidth is: 0 bps
BFD bandwidth-usage info:
MPLS OAM bandwidth-usage info:

MPLS-TP OAM bandwidth-usage info:

MQE bandwidth-usage info:


5.6 Configuring MPLS OAM to Monitor PW Connectivity

MPLS OAM can be configured to monitor connectivity of VLL PWs including SS-PWs, MS-
PWs, static PWs, and dynamic PWs.
Usage Scenario
On a Layer 2 Virtual Private Network ( L2VPN ) MPLS network, traditional detection techniques
can monitor the Pseudo-Wire ( PW ) status but cannot send defect packets or report a defect
type. The shortcoming delays fault detection and link switchover performed by an upper-layer
application. To address this problem, MPLS OAM can be configured to monitor the PW.
MPLS OAM is a detection mechanism for the user plane separated from the network plane and
is able to notify users of the PW status. A network administrator or maintenance engineer uses
the information to evaluate the network performance and maintain the network.
MPLS OAM is able to monitor the status of all PWs between two nodes or use a peer IP address,
virtual circuit ( VC ) encapsulation type, and VC ID to identify a PW and obtain detailed
information including basic PW and OAM information and OAM detection information. The
information can be used to maintain the network.
On the network shown in Figure 5-4, PE1 and PE2 are configured with OAM parameters and
enabled to send and receive OAM detection packets, which allows OAM to monitor the PW
between PE1 and PE2. OAM can obtain basic PW information, and send a BDI packet over a
reverse PW if OAM detects a default. Users can use the information provided by OAM to
maintain the network. CE1 is connected to PE1 over a VLAN and CE2 is connected to PE2 over
the same VLAN. PE1 and PE2 are connected over an MPLS backbone network.
Figure 5-4 Networking diagram for configuring MPLS OAM to monitor PW connectivity
MPLS network
PE1 P PE2
PW
CE1

Before configuring MPLS OAM to monitor PW connectivity, complete the following tasks:

l Establish a PW that MPLS OAM monitors.
Procedure
Step 1 Run:
system-view

Step 2 Run:
mpls

Step 3 Run:
mpls oam

Step 4 Run:
quit

Step 5 Run:
mpls-oam
The MPLS-OAM view is displayed.

Step 6 Run:
mpls oam l2vc peer-ip peer-ip vc-id vc-id vc-type vc-type type { cv | ffd
frequency ffd-fre } [ auto-protocol [ overtime overtime ] ] [ compatibility-mode
{ ptn-mode | router-mode} [ bdi-frequency { detect-freq | per-second } ]
MPLS OAM parameters are configured on nodes at both ends of the PW.
NOTE
l If auto-protocol is configured in the mpls oam l2vc command, an MPLS OAM-enabled device
automatically sends and receives OAM detection packets. There is no need to run the mpls oam l2vc
enable command.
l If auto-protocol is not configured, the mpls oam l2vc enable command can be run to enable the MPLS
OAM-enabled device to send, receive, or both send and receive OAM detection packets.
l Different types of devices to be connected must be configured with the same compatible mode, either
PTN or router model. Inconsistent compatible mode settings lead to a connection failure.
l If automatic OAM is configured on two devices, its parameters must be modified when both the devices
work in the same mode, either PTN or router mode. Inconsistent compatible mode settings lead to a
connection failure.

mpls oam l2vc enable { send | receive } { all | peer-ip peer-ip vc-id vc-id vc-
type vc-type }

MPLS OAM is enabled.

----End
Checking the Configuration

After completing the MPLS OAM configuration on nodes at both ends of a PW, run the following
commands and verify the configuration.
Run the display mpls oam l2vc all command to view information about and OAM status of all
PWs. For example:
<HUAWEI> display mpls oam l2vc all
----------------------------------------------------------------------
Total Oam Num: 1
Total Start Oam Num: 0
Total Defect Oam Num: 0
----------------------------------------------------------------------
No. Peer IP VC Type VC ID Status
----------------------------------------------------------------------
1 2.2.2.2 vlan 100 Stop/Non-defect
----------------------------------------------------------------------
Run the display mpls oam l2vc peer-ip peer-ip vc-id vc-id vc-type vc-type verbose command
to view information about a specified PW, OAM configurations, and OAM status on the main
control board. For example:
<HUAWEI> display mpls oam l2vc peer-ip 2.2.2.2 vc-id 100 vc-type vlan verbose
--------------------------------------------------------------------
Verbose information about NO.1 oam at the TPE
--------------------------------------------------------------------
PW basic information:
-------------------------------------------------
Service Type : VLL PW
PW Status : Down
Peer IP : 2.2.2.2
VC Type : vlan
VC ID : 100
Local VC Label : 100
Remote VC Label : 100
AC Interface : gigabitethernet 1/0/0.1
-------------------------------------------------
-------------------------------------------------

Oam Index : 256
Remote Peer IP : --
-------------------------------------------------
-------------------------------------------------
Send Type : FFD
Send Frequency : 500 ms
Receive Type : FFD
Receive Frequency : 500 ms
Detect State : Stop
Run the display mpls oam l2vc peer-ip peer-ip vc-id vc-id vc-type vc-type slot slot-id command
to view information about a specified PW, OAM configurations, and OAM status on a specified
interface board. For example:
<HUAWEI> display mpls oam l2vc peer-ip 2.2.2.2 vc-id 100 vc-type vlan slot 1
----------------------------------------------------------------------
Verbose information about NO.1 oam at the TPE

----------------------------------------------------------------------
PW basic information:
-------------------------------------------------
Service Type : VLL PW
PW Status : Down
Peer IP : 2.2.2.2
VC Type : vlan
VC ID : 100
Local VC Label : 100
Remote VC Label : 100
AC Interface : gigabitethernet 1/0/0.1
-------------------------------------------------
-------------------------------------------------
Oam Index : 256
Remote Peer IP : --
-------------------------------------------------

-------------------------------------------------
Send Type : FFD
Send Frequency : 500 ms
Receive Type : FFD
Receive Frequency : 500 ms
Detect State : Stop
5.7 Maintaining MPLS OAM

You can use display commands to monitor MPLS OAM and the tunnel protection group.
5.7.1 Monitoring the Running of MPLS OAM

You can use display commands to view the MPLS OAM operating status including the status
of OAM-enabled LSPs on the ingress and egress.
Context
In routine maintenance, you can run the following commands in any view to check the MPLS
OAM operating status.
Procedure
l Run the display mpls oam egress { all | lsp-name lsp-name | lsr-id ingress-lsr-id tunnel-
id tunnel-id } [ slot slot-id | verbose ] command to view information about the status and
configuration of the OAM-enabled LSP on the egress.
l Run the display mpls oam ingress { all | tunnel interface-number } [ slot slot-id |
verbose ] command to view information about the MPLS OAM parameters and status of
the LSP on the ingress.
l Run the display mpls oam oam-index index-value [ slot slot-id ] command to view
information about parameters and status of MPLS OAM.
----End
5.7.2 Monitoring the Running of Protection Group

You can use display commands to view the operation of a tunnel protection group and
information about tunnels in the tunnel protection group.
Context
In routine maintenance, you can run the following commands in any view to check the operating
status of the protection group.
Procedure
l Run the display mpls te protection tunnel { all | tunnel-id | interface tunnel interface-
number } [ verbose ] command to view information about the tunnel protection group.

l Run the display mpls te protection binding protect-tunnel { tunnel-id | interface

tunnel interface-number } command to view information about tunnels in the tunnel
protection group.
----End

The following sections provide several examples for configuring MPLS OAM to detect LSPs
and configuring the association between MPLS OAM and a protection group for performing
5.8.1 Example for Configuring MPLS OAM to Detect a Static LSP

The section provides an example for creating a static LSP and configuring MPLS OAM to detect
connectivity of the static LSP.
As shown in Figure 5-5, on an MPLS network, a static LSP along LSRA -> LSRB -> LSRC is
set up.
MPLS OAM is configured to detect the static LSP so that when a connectivity fault occurs, the
egress LSRC can notify the ingress LSRA of the fault.
Figure 5-5 Networking diagram for MPLS OAM detection
Loopback1
4.4.4.4/32
T
P Tu unn
/0 10 OS nn el
1/0 /24 el- 1/0
S .2 .1. 2/0 id /0
PO .1.1 LSRD 4. /0
1/ 10
0 24 0
/0 1 P
1/0 /24 10 OS
S .1 .1 1/0
.4
Loopback1 PO .1.1 Loopback1 .2 /0 Loopback1
/2
1.1.1.1/32 10 2.2.2.2/32 4 3.3.3.3/32
POS1/0/0 POS2/0/0
10.1.2.2/24 10.1.3.1/24
POS2/0/0 POS2/0/0
LSRA 10.1.2.1/24 LSRB 10.1.3.2/24 LSRC
Tunnel 2/0/0
Tunnel-id 200

1. Create a static LSP TE tunnel between LSRA and LSRC.

2. Set up a static CR-LSP along LSRC → LSRD → LSRA.
3. Configure OAM parameters on LSRA and enable OAM.
4. Configure OAM parameters on LSRC and use the OAM auto-protocol.
Data Preparation
l IP addresses for interfaces on each LSR, the tunnel interface name, and the tunnel ID
l Types of the detection packets to be sent
l Mode of the backward tunnel (share or private)
Procedure
Step 1 Configure IP addresses and the routing protocols for interfaces.
According to Figure 5-5, configure IP addresses and masks for interfaces including the loopback
interfaces.
Configure OSPF on all LSRs to advertise routes of their loopback interfaces. For configuration
After the configuration, LSRs can ping each other. Run the display ip routing-table command
on each LSR to display routes to each LSR-ID.
<LSRA> display ip routing-table
------------------------------------------------------------------------------
2.2.2.2/32 OSPF 10 2 D 10.1.2.2 Pos2/0/0
3.3.3.3/32 OSPF 10 3 D 10.1.1.2 Pos1/0/0
OSPF 10 3 D 10.1.2.2 Pos2/0/0
4.4.4.4/32 OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/24 OSPF 10 2 D 10.1.2.2 Pos2/0/0
10.1.4.0/24 OSPF 10 2 D 10.1.1.2 Pos1/0/0
Step 2 Set up a static LSP to be monitored.

# Configure basic MPLS and MPLS TE functions on LSRA.
<LSRA> system-view
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit

Other LSRs have the same configuration as LSRA.

# Create an MPLS TE tunnel that is based on the static LSP from LSRA to LSRC.
[LSRA-Tunnel2/0/0] mpls te signal-protocol static
# Configure LSRA to be the ingress of the static LSP and enable the TE tunnel.
[LSRA] static-lsp ingress tunnel-interface tunnel 2/0/0 destination 3.3.3.3 nexthop
10.1.2.2 out-label 20
# Configure LSRB to be the transit node of the static LSP.

<LSRB> system-view
[LSRB] static-lsp transit oamlsp incoming-interface pos 1/0/0 in-label 20 nexthop
10.1.3.2 out-label 30
# Configure LSRC to be the egress of the static LSP and specify lsr-id and tunnel-id.
<LSRC> system-view
[LSRC] static-lsp egress oamlsp incoming-interface pos 2/0/0 in-label 30 lsrid
1.1.1.1 tunnel-id 200
After completing the configuration, run the display mpls te tunnel-interface command on
LSRA. The TE tunnel is UP.
================================================================
Tunnel2/0/0
================================================================
Session ID : 200
Run the display mpls static-lsp command on LSRA. The static LSP corresponding to Tunnel
2/0/0 is Up.
[LSRA] display mpls static-lsp
Tunnel2/0/0 3.3.3.3/32 NULL/20 -/Pos2/0/0 Up
Step 3 Set up a backward tunnel.

# Create an MPLS TE tunnel that is based on the static CR-LSP from LSRC to LSRA.
[LSRC] interface Tunnel 1/0/0


# Configure LSRC to be the ingress of the static CR-LSP.

[LSRC] static-cr-lsp ingress tunnel-interface tunnel1/0/0 destination 1.1.1.1
nexthop 10.1.4.1 out-label 70
# Configure LSRD to be the transit node of the CR-LSP.

<LSRD> system-view
[LSRD] static-cr-lsp transit tunnel1/0/0 incoming-interface pos 2/0/0 in-label 70
# Configure LSRA to be the egress of the static CR-LSP and specify lsr-id and tunnel-id.
[LSRA] static-cr-lsp egress Tunnel1/0/0 incoming-interface pos 1/0/0 in-label 80
lsrid 3.3.3.3 tunnel-id 100
After completing the configuration, run the display mpls te tunnel-interface command on
LSRC. The backward tunnel is UP.
[LSRC] display mpls te tunnel-interface
================================================================
Tunnel1/0/0
================================================================
Session ID : 100
Run the display mpls static-cr-lsp command on LSRC. The static CR-LSP is Up.
[LSRC] display mpls static-cr-lsp
Tunnel1/0/0 1.1.1.1/32 NULL/70 -/Pos1/0/0 Up
Step 4 Configure MPLS OAM.
# Configure MPLS OAM for the ingress on LSRA. By default, sending CV packets is enabled.
Parameters for the backward tunnel depend on the configuration of the egress.
[LSRA] mpls
[LSRA-mpls] mpls oam
[LSRA-mpls] quit
[LSRA] mpls oam ingress Tunnel 2/0/0 backward-lsp lsp-name Tunnel1/0/0
[LSRA] mpls oam ingress enable all
# Configure MPLS OAM on LSRC.

[LSRC] mpls
[LSRC-mpls] mpls oam
[LSRC-mpls] quit
# Configure the OAM auto-protocol on LSRC to detect the LSP named oamlsp. The backward
tunnel is the LSP bound to tunnel 1/0/0. It is in the private mode.

[LSRC] mpls oam egress lsp-name oamlsp auto-protocol backward-lsp tunnel 1/0/0
private
After the OAM auto-protocol is configured on the egress, OAM is enabled automatically when
the egress receives the first correct detention packet.
After the configuration, check the MPLS OAM parameters and status of LSPs on LSRA and
LSRC. You can view that both ingress and egress are active in normal detection status.
[LSRA] display mpls oam ingress all verbose
-------------------------------------------------------------------------
Verbose information about the 1th oam at the ingress
-------------------------------------------------------------------------
lsp basic information: oam basic information:
----------------------------------- -----------------------------------
Tunnel-name : Tunnel2/0/0 Oam-Index : 256
Lsp signal status : Up Oam select board : 1
Lsp establish type : Static lsp Enable-state : Manual enable
Lsp ingress lsr-id : 1.1.1.1 Ttsi/lsr-id : 1.1.1.1
Lsp tnl-id/Lsp-id : 200/1 Ttsi/tunnel-id : 200
oam detect information: oam backward information:
----------------------------------- -----------------------------------
Type : CV Share attribute : Private
Frequency : 1 s Lsp-name : Tunnel1/0/0
Detect-state : Start Lsp ingress lsr-id : 3.3.3.3
Defect-state : Non-defect Lsp tnl-id/lsp id : 100/1
Available-state : available Lsp-inLabel : 80
Unavailable time (s): 0 Lsp signal status : Up
-------------------------------------------------------------------------
Total Oam Num: 1
Total Unavaliable Oam Num: 0
[LSRC] display mpls oam egress all verbose
-------------------------------------------------------------------------
Verbose information about the 1th oam at the egress
-------------------------------------------------------------------------
----------------------------------- -----------------------------------
Lsp name : oamlsp Oam-Index : 256
Lsp establish type : Static lsp Enable-state : --
Lsp incoming Label : 30 Auto-protocol : Enable
Lsp ingress lsr-id : 1.1.1.1 Auto-overtime (s) : 300
Lsp tnl-id/lsp-id : 200/1 Ttsi/lsr-id : 1.1.1.1
Lsp Incoming-int Pos 2/0/0 Ttsi/tunnel-id : 200
----------------------------------- -----------------------------------
Type : CV Tunnel name : Tunnel1/0/0
Frequency : 1 s Share attribute : Private
Detect-state : Start Lsp signal status : Up
Defect-state : Non-defect Bdi-frequency : Detect-freq
Available state : Available
Unavailable time (s): 0
-------------------------------------------------------------------------
Total Oam Num: 1
# Run the shutdown command on POS 2/0/0 of LSRB to simulate a link fault.
[LSRB-Pos2/0/0] shutdown

# Run the display mpls oam egress all verbose command on LSRC. LSRC has detected the
link fault and changed its status to In-defect.
<LSRC> display mpls oam egress all verbose
-------------------------------------------------------------------------
Verbose information about the 1th oam at the egress
-------------------------------------------------------------------------
---------------------------------- ------------------------------------
Lsp name : oamlsp Oam-Index : 256
Lsp establish type : Static lsp Enable-state : --
Lsp incoming Label : 30 Auto-protocol : Enable
Lsp ingress lsr-id : 1.1.1.1 Auto-overtime (s) : 300
Lsp tnl-id/lsp-id : 200/1 Ttsi/lsr-id : 1.1.1.1
Lsp Incoming-int Pos 2/0/0 Ttsi/tunnel-id : 200
---------------------------------- -----------------------------------
Type : CV Tunnel name : Tunnel1/0/0
Frequency : 1 s Share attribute : Private
Detect-state : Start Lsp signal status : Up
Defect-type : dLocv Bdi-frequency : Detect-freq
Available state : Unavailable
Unavailable time (s): 0
-------------------------------------------------------------------------
Total Oam Num: 1
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls oam
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.2.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 3.3.3.3
mpls te signal-protocol static
mpls te commit
#

ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
#
static-lsp ingress tunnel-interface Tunnel2/0/0 destination 3.3.3.3 nexthop
10.1.2.2 out-label 20
static-cr-lsp egress tunnel1/0/0 incoming-interface Pos1/0/0 in-label 80
lsrid 3.3.3.3 tunnel-id 1
#
mpls oam ingress Tunnel 2/0/0 backward-lsp lsp-name Tunnel1/0/0
mpls oam ingress enable Tunnel2/0/0
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.3.1 255.255.255.0
mpls
mpls te
#
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 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
#
static-lsp transit oamlsp incoming-interface Pos1/0/0 in-label 20 nexthop
10.1.3.2 out-label 30
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls oam
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.4.2 255.255.255.0
mpls
mpls te
#
interface Pos2/0/0
link-protocol ppp

ip address 10.1.3.2 255.255.255.0

mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
destination 1.1.1.1
mpls te commit
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.3.0 0.0.0.255
network 10.1.4.0 0.0.0.255
#
static-lsp egress oamlsp incoming-interface Pos2/0/0 in-label 30 lsrid
1.1.1.1 tunnel-id 200
static-cr-lsp ingress tunnel-interface tunnel1/0/0 destination 1.1.1.1
nexthop 10.1.4.1 out-label 70 bandwidth bc0 0
#
mpls oam egress lsp-name oamlsp backward-lsp Tunnel1/0/0 private
#
return

#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
mpls te
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.4.1 255.255.255.0
mpls
mpls te
#
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 10.1.1.0 0.0.0.255
network 10.1.4.0 0.0.0.255
#
static-cr-lsp transit tunnel1/0/0 incoming-interface Pos2/0/0 in-label 70
nexthop 10.1.1.1 out-label 80 bandwidth bc0 0
#
return

5.8.2 Example for Configuring MPLS OAM to Monitor a Static

Bidirectional Co-routed LSP
This section describes how to configure MPLS OAM to monitor a static bidirectional co-routed
LSP and how to verify the configuration.
Context
Bidirectional co-routed LSPs are widely used on a transport network. Their own O&M
capabilities, however, cannot meet telecom network requirements. MPLS OAM is an effective
O&M method that can detect faults in static bidirectional co-routed LSPs.
A static bidirectional co-routed LSP is established between LSRA and LSRC and transmits OAM
packets on the MPLS-TP network shown in Figure 5-6. If any transit node on the LSP receives
an OAM packet, the node replies with a response over the same path. The bandwidth of the LSP
between LSRA and LSRC is 10 Mbit/s.
Figure 5-6 MPLS OAM for monitoring a static bidirectional co-routed LSP
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
POS1/0/0 POS1/0/0 POS2/0/0 POS1/0/0
2.1.1.1/24 2.1.1.2/24 3.2.1.1/24 3.2.1.2/24
LSRA LSRB LSRC

3. Set MPLS TE bandwidth attributes for links.
4. Configure MPLS TE tunnel interfaces.
5. Configure the ingress, transit node, and egress for a static bidirectional co-routed LSP.
6. Configure a reverse tunnel attribute on the tunnel interface of LSRC and bind the tunnel
interface to the static bidirectional co-routed LSP.
7. Configure MPLS OAM.
Data Preparation
l Tunnel interface's name and IP address, destination address, tunnel ID, and tunnel signaling
protocol (CR-Static) on LSRA and LSRC


Procedure
Assign an IP address and a mask to each interface and configure a routing protocol on each LSR
to ensure network layer connectivity.
# Configure LSRA.
[LSRA] mpls
[LSRA-mpls] mpls te
[LSRA-mpls] quit
section.
Step 3 Set MPLS TE bandwidth attributes for links.
# Configure the maximum reservable bandwidth and BC0 bandwidth for a link on the outbound
interface of each LSR. Ensure that the BC0 bandwidth of links is higher than the tunnel
bandwidth (10 Mbit/s).
# Configure LSRA.
# Configure LSRB.
# Configure LSRC.

# Create an MPLS TE tunnel interface for an LSP that originates from LSRA and is destined
for LSRC.
[LSRA-Tunnel1/0/0] mpls te bidirectional
# Create an MPLS TE tunnel interface for an LSP that originates from LSRC and is destined for
LSRA.
Step 5 Configure the ingress, transit node, and egress for a static bidirectional co-routed LSP.
# Configure LSRA as the ingress.
[LSRA] bidirectional static-cr-lsp ingress Tunnel/0/0
[LSRA-bi-static-ingress-Tunnell/0/0] forward nexthop 2.1.1.2 out-label 20
bandwidth ct0 10000
[LSRA-bi-static-ingress-Tunnell/0/0] backward in-label 20
# Configure LSRB as a transit node.

[LSRB]bidirectional static-cr-lsp transit lsp1
[LSRB-bi-static-transit-lsp1] forward in-label 20 nexthop 3.2.1.2 out-label 40
bandwidth ct0 10000
[LSRB-bi-static-transit-lsp1] backward in-label 16 nexthop 2.1.1.1 out-label 20
bandwidth ct0 10000
# Configure LSRC as the egress.

[LSRC] bidirectional static-cr-lsp egress lsp1
[LSRC-bi-static-egress-lsp1] forward in-label 40 lsrid 1.1.1.1 tunnel-id 100
[LSRC-bi-static-egress-lsp1] backward nexthop 3.2.1.1 out-label 16 bandwidth ct0
10000
Step 6 Configure a reverse tunnel attribute on the tunnel interface of LSRC and bind the tunnel interface
to the static bidirectional co-routed LSP.
[LSRC] interface Tunnel2/0/0
[LSRC-Tunnel2/0/0] mpls te passive-tunnel
[LSRC-Tunnel2/0/0] mpls te binding bidirectional static-cr-lsp egress lsp1
Step 7 Configure MPLS OAM.

# Configure LSRA.
[LSRA] mpls-oam
[LSRA-mpls-oam] mpls oam bidirectional-tunnel tunnel 1/0/0 type cv auto-protocol
overtime 30
[LSRA-mpls-oam] mpls oam bidirectional-tunnel enable send all
[LSRA-mpls-oam] mpls oam bidirectional-tunnel enable receive all
[LSRA-mpls-oam] quit
# Configure LSRC.

[LSRC] mpls-oam
[LSRC-mpls-oam] mpls oam bidirectional-tunnel tunnel 2/0/0 type cv auto-protocol
overtime 30
[LSRC-mpls-oam] mpls oam bidirectional-tunnel enable send all
[LSRC-mpls-oam] mpls oam bidirectional-tunnel enable receive all
[LSRC-mpls-oam] quit

tunnel interface is Up.
Run the display mpls te tunnel command on each LSR to view information about MPLS TE
tunnels.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 3.3.3.3 1 NULL/20 I Tunnel1/0/0
- - - 20/NULL E Tunnel2/0/0
# Check the configuration results on LSRB.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
- - - 20/40 T Tunnel1/0/0
- - - 16/20 T Tunnel2/0/0
# Check the configuration results on LSRC.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
3.3.3.3 1.1.1.1 1 NULL/16 I Tunnel2/0/0
- - - 40/NULL E Tunnel1/0/0
Run the display mpls te bidirectional static-cr-lsp command on each LSR to view information
about the static bidirectional co-routed LSP.
[LSRA] display mpls te bidirectional static-cr-lsp
Tunnel1/0/0 3.3.3.3/32 NULL/20 -/Pos1/0/0
20/NULL Pos1/0/0- Up
# Check the configuration results on LSRB.

[LSRB] display mpls te bidirectional static-cr-lsp
lsp1 -/32 20/40 -/Pos1/0/0
16/20 Pos2/0/0- Up

# Check the configuration results on LSRC.

[LSRC] display mpls te bidirectional static-cr-lsp
lsp1 1.1.1.1/32 40/NULL Pos1/0/0/-
NULL/16 -/Pos1/0/0 Up
Run the ping command on LSRA. The ping succeeds, which means that the static bidirectional
co-routed LSP is reachable.
[LSRA] ping lsp te Tunnel 1/0/0
LSP PING FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel1/0/0 : 100 data bytes, pres
s CTRL_C to break
0.00% packet loss
Run the display mpls oam bidirectional-tunnel all command on LSRA. The command output
shows the configuration about OAM.
[LSRA] display mpls oam bidirectional-tunnel all
----------------------------------------------------------------------
Total Oam Num: 1
----------------------------------------------------------------------
No. Tunnel-name Ttsi Status
----------------------------------------------------------------------
1 Tunnel1/0/0 1.1.1.1 : 100 Start/No-defect
----------------------------------------------------------------------
----End
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
mpls te
#
#
interface Pos1/0/0
undo shutdown
ip address 2.1.1.1 255.255.255.0
mpls
mpls te


#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
destination 3.3.3.3
mpls te commit
#
ip route-static 2.2.2.2 255.255.255.255 2.1.1.2
ip route-static 3.3.3.3 255.255.255.255 2.1.1.2
#
mpls-oam
mpls oam bidirectional-tunnel tunnel 1/0/0 type cv auto-protocol overtime 30
mpls oam bidirectional-tunnel enable send all
mpls oam bidirectional-tunnel enable receive all
#
return

#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
mpls te
#
#
interface Pos1/0/0
undo shutdown
ip address 2.1.1.2 255.255.255.0
mpls
mpls te
#
interface Pos2/0/0
undo shutdown
ip address 3.2.1.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 2.1.1.1
ip route-static 3.3.3.3 255.255.255.255 3.2.1.2
#
return

#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
mpls te

#
bidirectional static-cr-lsp egress lsp1
#
interface Pos1/0/0
undo shutdown
ip address 3.2.1.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
destination 1.1.1.1
mpls te binding bidirectional static-cr-lsp egress lsp1
mpls te commit
#
ip route-static 1.1.1.1 255.255.255.255 3.2.1.1
ip route-static 2.2.2.2 255.255.255.255 3.2.1.1
#
mpls-oam
mpls oam bidirectional-tunnel tunnel 2/0/0 type cv auto-protocol overtime 30
mpls oam bidirectional-tunnel enable send all
mpls oam bidirectional-tunnel enable receive all
#
return
5.8.3 Example for Configuring MPLS OAM Protection Switching

This section provides an example for creating a working tunnel and a protection tunnel, and
configuring MPLS OAM protection switching.
As shown in Figure 5-7, on an MPLS network, there are three bidirectional static CR-LSPs
between PE1 and PE2. These bidirectional static CR-LSPs are bound to tunnel 1/0/10, tunnel
1/0/11, and tunnel 1/0/12 respectively. Tunnel 1/0/10 and tunnel 1/0/11 serve as working tunnels.
Tunnel 1/0/12 serves as a protection tunnel.
MPLS OAM protection switching is enabled on the MPLS network. Tunnel 1/0/12 protects
tunnel 1/0/10 and tunnel 1/0/11 simultaneously. When either of the working tunnels (tunnel
1/0/10 and tunnel 1/0/11) fails, traffic on the failed working tunnel switches to the protection
tunnel (tunnel 1/0/12).

Figure 5-7 Networking diagram for configuring an MPLS OAM protection group
Loopback1 Loopback1
2.2.2.2 GE2/0/0 GE1/0/0 5.5.5.5
10.1.5.2/30 10.1.5.1/30
P2 /0 PE2
E 2/0
1 G
GE1/0/0 ack GE4/0/0
10.1.1.2/30 o
b
op 3.3 0 3 / 0/0 /30 10.1.6.1/30
L .3. /
3 4/ 0 / 30 GE 1.8.1
GE 1.7.2 10
.
.
10 0 / 0
3 /0 30
/ 0 . 7 .1/ GE1 .8.2/
2/ 0 30 .1 .1
GE .2.2/ 10 10
.1
0 10 /0 P1
/
E 2/0 /30 E 3/0 .2/30
G 2.1 G 1.3
GE1/0/0 .1. . GE2/0/0
1 0 0 /0 10
10.1.1.1/30 3 / /3 0 10.1.6.2/30
GE 1.3.1
.
10
PE1 GE4/0/0 GE1/0/0 P3
1.1.1.1/32 4.4.4.4/32
Working tunnel-1
Reverse working tunnel-1
Working tunnel-2
Reverse working tunnel-2
Protection tunnel
Reverse protection tunnel
1. Configure IP addresses and OSPF on interfaces

2. Enable MPLS, MPLS TE, and MPLS OAM.
3. Create three TE tunnel interfaces (tunnel 1/0/10, tunnel 1/0/11 and tunnel 1/0/12) on PE1
and PE2. Two of them serve as working tunnels and the third one serves as a protection
tunnel.
4. Configure two static CR-LSPs from PE1 to PE2, and bind one of them with tunnel 1/0/10
and bind the other one with tunnel 1/0/12.
5. Configure an RSVP-TE tunnel from PE1 to PE2.
6. Configure three static CR-LSPs from PE2 to PE1, and bind them with tunnel 1/0/10, tunnel
1/0/11 and tunnel 1/0/12 respectively on PE2.
7. Set OAM parameters and enable MPLS OAM to detect bidirectional LSPs.
Data Preparation

l IP addresses of interfaces, tunnel interface names, and tunnel IDs

l Types of packets to be detected by MPLS OAM
l Parameters for a protection group, including the delay of the protection switching, revertive
mode, and WTR time
Procedure
Step 1 Configure IP addresses and routing protocols on interfaces.
As shown in Figure 5-7, configure IP addresses and masks for interfaces, including loopback
interfaces.
Configure the OSPF protocol on all LSRs to advertise host routes of their loopback interfaces.
After the configuration, LSRs can ping the LSR ID of each other.
Step 2 Enable MPLS and MPLS TE globally and on the physical interfaces.
Step 3 Configure TE tunnel interfaces.
# On PE1 and PE2, configure tunnel 1/0/10 and tunnel 1/0/11 as working tunnels and tunnel
1/0/12 as a protection tunnel. Tunnel 1/0/12 protects tunnel 1/0/10 and tunnel 1/0/11
simultaneously. The signaling protocol of tunnel 1/0/11 is RSVP-TE and the signaling protocol
of tunnel 1/0/10 and tunnel 1/0/12 is CR-Static.
# Configure PE1.
<PE1> system-view
[PE1-Tunnel1/0/10] description Working tunnel-1 to PE2
[PE1-Tunnel1/0/12] description Protection tunnel to PE2
# Configure PE2.
<PE2> system-view


[PE2-Tunnel1/0/12] description Protection tunnel to PE1
Step 4 Configure three static CR-LSPs from PE1 to PE2, and bind them to the tunnel interfaces on PE1.
# Configure PE1.
[PE1] static-cr-lsp ingress tunnel-interface Tunnel1/0/10 destination 5.5.5.5
# Configure P1.
<P1> system-view
[P1] static-cr-lsp transit PE1toPE2-2 incoming-interface gigabitethernet2/0/0 in-
label 16 nexthop 10.1.7.1 out-label 17
# Configure P3.
<P3> system-view
# Configure PE2.
[PE2] static-cr-lsp egress PE1toPE2-2 incoming-interface gigabitethernet2/0/0 in-
label 17 lsrid 1.1.1.1 tunnel-id 1010
After completing the configuration, run the display mpls te tunnel command on PE1 and PE2
to view the created TE tunnel.

[PE1]display mpls te tunnel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
1.1.1.1 5.5.5.5 1 --/16 I Tunnel1/0/10
1.1.1.1 5.5.5.5 1 --/30 I Tunnel1/0/12

Step 5 Configure an RSVP-TE tunnel.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
# Configure P1.
[P1] mpls
[P1-mpls] mpls te cspf
[P1-mpls] quit
[P1] ospf 1
[P1-ospf-1] opaque-capability enable
[P1-ospf-1] area 0
[P1-ospf-1-area-0.0.0.0] mpls-te enable
[P1-ospf-1-area-0.0.0.0] quit
[P1-ospf-1] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] ospf 1
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
Run the display mpls te tunnel-interface command to view information oabout tunnel 1/0/11.
[PE1] display mpls te tunnel-interface tunnel1/0/11
================================================================
Tunnel1/0/11
================================================================
Session ID : 1011

Step 6 Configure three static CR-LSPs from PE2 to PE1, and bind them to the tunnel interfaces on PE2.
# Configure PE2.
# Configure P1.
# Configure P2.
<P2> system-view
# Configure PE1.
Step 7 Bind the backward LSPs to the tunnel interfaces.

# Configure PE1.
[PE1-Tunnel1/0/10] mpls te reverse-lsp lsp-name PE2toPE1-1
# Configure PE2.
Step 8 Enable MPLS OAM to detect the static CR-LSPs.

# Configure PE1.

[PE1] mpls
[PE1-mpls] mpls oam
[PE1-mpls] quit
[PE1] mpls oam ingress Tunnel1/0/10
[PE1] mpls oam ingress enable all
[PE1] mpls oam egress lsp-name PE2toPE1-1
[PE1] mpls oam egress enable all
# Configure PE2.
[PE2] mpls
[PE2-mpls] mpls oam
[PE2-mpls] quit
[PE2] mpls oam ingress enable all
[PE2] mpls oam egress enable all
After completing the configuration, run the display mpls oam ingress all verbose command to
view the MPLS OAM parameters and status of LSPs on PE1 and PE2. You can view that the
LSP to be detected is in the "Non-Defect" state.

[PE1] display mpls oam ingress all verbose
--------------------------------------------------------------------------------
Verbose information about NO.1 oam at the ingress

--------------------------------------------------------------------------------

--------------------------------------- --------------------------------------
Lsp establish type : Static lsp Enable-state : Manual disable

------------------------------------- ----------------------------------
Type : CV Share attribute : Share
Frequency : 1 s Lsp-name : --
Detect-state : Start Lsp ingress lsr-id : --
Defect-state : Non-defect Lsp tnl-id : --
Available-state : Available Lsp-id : --
Unavailable time (s): 0 Lsp-inLabel : --
Packet-priority : 7 Lsp signal status : --
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------- --------------------------------------


Lsp establish type : RSVP-TE Enable-state : Manual disable

------------------------------------- ----------------------------------
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------- --------------------------------------
Lsp establish type : Static lsp Enable-state : Manual disable

------------------------------------- ----------------------------------
--------------------------------------------------------------------------------
Total Oam Num: 3

Total Unavailable Oam Num: 0

# On PE1, configure tunnel 1/0/10 and tunnel 1/0/11 as working tunnels and tunnel 1/0/12 as a
protection tunnel. Use the revertive mode and set the WTR time to 2 minutes.
[PE1-Tunnel1/0/10] mpls te protection tunnel 1/0/12 mode revertive wtr 4
[PE1-Tunnel1/0/11] mpls te protection tunnel 1/0/12 mode revertive wtr 4
# After completing the configuration, run the display mpls te protection tunnel all command
on PEs. Interfaces of all tunnels are in the Non-defect state and traffic is forwarded through the
working tunnel.
[PE1] display mpls te protection tunnel all

------------------------------------------------------------------------
------------------------------------------------------------------------
# Run the display mpls te protection binding protect-tunnel command on PEs. Tunnel 1/0/12
protects tunnel 1/0/10 and tunnel 1/0/11 simultaneously.

[PE1] display mpls te protection binding protect-tunnel 1012
------------------------------------------------------------------------
Binding information of( tunnel id: 1012 )
------------------------------------------------------------------------
Protect-tunnel id :1012
Protect-tunnel name :Tunnel1/0/12
Maximum number of bound work-tunnels :8
Currently bound work-tunnels :Total( 2 )
:Tunnel1/0/10
:Tunnel1/0/11
Run the display mpls te protection tunnel interface tunnel interface-number verbose
command on PEs to view details about the specified tunnel protection group. The following
example uses the command output on tunnel 1/0/10 of PE1.
[PE1] display mpls te protection tunnel interface tunnel 1010 verbose
----------------------------------------------------------------
Verbose information about the 1th proteciton-group
----------------------------------------------------------------
Work-tunnel reverse-lsp name : PE2toPE1-1
Protect-tunnel reverse-lsp name : PE2toPE1-3
switch result : work-tunnel
work-tunnel defect state : non-defect
protect-tunnel defect state : non-defect
work-tunnel reverse-lsp defect state : non-defect
protect-tunnel reverse-lsp defect state : non-defect
HoldOff : 0ms
WTR : 120s
Mode : revertive
# Run the mpls te protect-switch manual work-lsp command on tunnel 1/0/10 of PE1 to
perform traffic switching.
[PE1-Tunnel1/0/10] mpls te protect-switch manual work-lsp
# Run the display mpls te protection tunnel all command on PE1. The Switch-Result of tunnel
1/0/10 is protect-tunnel.
------------------------------------------------------------------------
------------------------------------------------------------------------
1 non-defect /1010 non-defect /1012 protect-tunnel

# Run the shutdown command on the GE 4/0/0 on PE1 to simulate the physical link failure on
the protection tunnel.
# Run the display mpls te protection tunnel all command on PE1. The Protect-tunnel
status of tunnel 1/0/10 is in-defect, and the Switch-Result is work-tunnel.
------------------------------------------------------------------------
------------------------------------------------------------------------
1 non-defect /1010 in-defect /1012 work-tunnel
NOTE
When all tunnels work properly, and the mpls te protect-switch manual work-lsp command is configured
on the tunnel interface view of the working tunnel, traffic switches to the protection tunnel. In this case, if
the link of the protection tunnel fails, traffic switches back to the working tunnel and the mpls te protect-
switch manual work-lsp command on the tunnel interface view of the working tunnel is deleted. That is
because the link failure belongs to signaling failure and the priority of signaling failure is higher than that
of manual switching.
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
mpls oam
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
#
ip address 10.1.2.1 255.255.255.0
mpls
mpls te
#
ip address 10.1.3.1 255.255.255.0
mpls
mpls te
mpls te rsvp-te
#
ip address 10.1.4.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#

description Working tunnel-1 to PE2

destination 5.5.5.5
mpls te protection tunnel 1/0/12 mode revertive wtr 4
mpls te reverse-lsp lsp-name PE2toPE1-1
mpls te commit
#
destination 5.5.5.5
mpls te commit
#
description Protection tunnel to PE2
destination 5.5.5.5
mpls te commit
#
ospf 100
area 0.0.0.0
network 1.1.1.1 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
network 10.1.4.0 0.0.0.255
mpls-te enable
#
static-cr-lsp ingress tunnel-interface Tunnel1/0/10 destination 5.5.5.5
static-cr-lsp egress PE2toPE1-2 incoming-interface gigabitethernet2/0/0 in-
#
mpls oam ingress Tunnel1/0/10
mpls oam ingress enable all
mpls oam egress lsp-name PE2toPE1-1
mpls oam egress enable all
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.2

mpls
mpls te
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
#
ip address 10.1.5.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 100
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.5.0 0.0.0.255
#
static-cr-lsp transit PE2toPE1-3 incoming-interface gigabitethernet2/0/0 in-
#
return
#
sysname P1
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ip address 10.1.8.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.2.2 255.255.255.0
mpls
mpls te
#
ip address 10.1.3.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.7.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 100
area 0.0.0.0
network 3.3.3.3 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.7.0 0.0.0.255
network 10.1.8.0 0.0.0.255
mpls-te enable
#
#
return
#
sysname P3
#
mpls lsr-id 4.4.4.4
mpls
mpls te
#
ip address 10.1.4.2 255.255.255.0
mpls
mpls te
#
ip address 10.1.6.2 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
ospf 100
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.1.4.0 0.0.0.255
network 10.1.6.0 0.0.0.255
#
#
return

#
sysname PE2
#
mpls lsr-id 5.5.5.5
mpls
mpls te
mpls rsvp-te
mpls te cspf
mpls oam
#
ip address 10.1.5.1 255.255.255.0
mpls
mpls te
#
ip address 10.1.7.1 255.255.255.0
mpls
mpls te
#

ip address 10.1.8.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.6.1 255.255.255.0
mpls
mpls te
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
destination 1.1.1.1
mpls te commit
#
destination 1.1.1.1
mpls te commit
#
description Protection tunnel to PE1
destination 1.1.1.1
mpls te commit
#
ospf 100
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 10.1.5.0 0.0.0.255
network 10.1.6.0 0.0.0.255
network 10.1.7.0 0.0.0.255
network 10.1.8.0 0.0.0.255
mpls-te enable
#
#


mpls oam ingress enable all
mpls oam egress lsr-id 1.1.1.1 tunnel-id 1011
mpls oam egress enable all
#
return

Configuration Guide - MPLS 6 Seamless MPLS Configuration
6 Seamless MPLS Configuration
About This Chapter
This section describes how to configure seamless Multiprotocol Label Switching (MPLS) in
various usage scenarios.
6.1 Introduction
Seamless Multiprotocol Label Switching (MPLS) can establish a label switched path (LSP)
across the access, aggregation, and core layers to implement E2E service connectivity.
6.2 Configuring Intra-AS Seamless MPLS

In the intra-seamless MPLS networking, the access, aggregation, and core layers are within a
single AS. A BGP LSP is established across the three layers within the AS to implement E2E
service connectivity.
6.3 Configuring Inter-AS Seamless MPLS

In the inter-AS seamless MPLS networking, the access and aggregation layers belong to one
AS, and the core layer belong to another AS. An inter-AS BGP LSP is established across the
three layers to implement E2E service connectivity.
6.4 Configuring Inter-AS Seamless MPLS+HVPN

In the inter-AS seamless MPLS+HVPN networking, an HVPN between each CSG and AGG is
configured, and inter-AS seamless MPLS is configured for the link between each AGG and
MASG. The networking integrates the seamless MPLS and HVPN advantages.
6.5 Maintaining Seamless MPLS

The seamless MPLS maintenance involves checking the connectivity and reachability of
seamless MPLS networks.

This section provides examples for configuring seamless MPLS networks. In each configuration
example, the networking requirements, configuration notes, configuration roadmap,
configuration procedures, and configuration files are provided.

6.1 Introduction
Seamless Multiprotocol Label Switching (MPLS) can establish a label switched path (LSP)
across the access, aggregation, and core layers to implement E2E service connectivity.
6.1.1 Overview
Seamless MPLS is a bearer technique that extends MPLS techniques to access networks.
Seamless MPLS establishes an E2E LSP across the access, aggregation, and core layers. All
services can be encapsulated using MPLS at the access layer and transmitted along the E2E LSP
across the three layers.
With current trends moving towards a flat network structure, metropolitan area networks
(MANs) are steadily evolving into the Ethernet architecture, which calls for the application of
MPLS on the MAN and access networks. To meet this requirement, seamless MPLS was
developed. Seamless MPLS uses existing BGP, IGP, and MPLS techniques to establish an E2E
LSP across the access, aggregation, and core layers, allowing end-to-end traffic to be
encapsulated and forwarded using MPLS.
6.1.2 Seamless MPLS Networks Supported by the NE80E/40E

The NE80E/40E supports intra-AS seamless MPLS, inter-AS seamless MPLS, and inter-AS
seamless MPLS+HVPN networking.
Intra-Seamless MPLS
Figure 6-1 illustrates the intra-AS seamless MPLS networking. The access, aggregation, and
core layers are within a single AS. Intra-AS seamless MPLS applies to mobile bearer networks.
Figure 6-1 Intra-AS seamless MPLS networking

Inter-AS Seamless MPLS

Figure 6-2 illustrates the inter-AS seamless MPLS networking. The access and aggregation
layers are within a single AS, and the core layer belongs to another AS. Inter-AS seamless MPLS
transmits enterprise services.
Inter-AS Seamless MPLS+HVPN

Figure 6-3 illustrates the inter-AS seamless MPLS+HVPN networking: A cell site gateway
(CSG) and an aggregation (AGG) node establish an HVPN connection, and the AGG and a
mobile aggregate service gateway (MASG) establish a seamless MPLS LSP. The AGG
hierarchically provides L3VPN access services and routing management services. Seamless
MPLS+HVPN combines the advantages of both MPLS and HVPN. Seamless MPLS allows any
two nodes on an inter-AS LSP to transmit services at the access, aggregation, and core layers,
providing high service scalability. HVPN enables carriers to cut down network deployment costs
by deploying devices with layer-specific capacities to meet service requirements.

Figure 6-3 Inter-AS seamless MPLS networking+HVPN
6.2 Configuring Intra-AS Seamless MPLS

In the intra-seamless MPLS networking, the access, aggregation, and core layers are within a
single AS. A BGP LSP is established across the three layers within the AS to implement E2E
service connectivity.

Before configuring intra-AS seamless MPLS, familiarize yourself with the usage scenario,
Usage Scenario
As shown in Figure 6-4, the access, aggregation, and core layers belong to the same AS. Intra-
AS seamless MPLS can be configured to transmit services between NodeBs (Ethernet stations)
and a mobility management entity (MME) or serving gateway (SGW). Intra-AS seamless MPLS
applies to mobile bearer networks.

Figure 6-4 Intra-AS seamless MPLS networking
Single AS
IBGP label IBGP label IBGP label
CSG1 AGG1 Core ABR1 MASG1
NodeB/
eNodeB Aggregation
Access Core
MME/
SGW
CSG2 AGG2 Core ABR2 MASG2
NodeB/
eNodeB MPLS LDP/ MPLS LDP/ MPLS LDP/
MPLS TE MPLS TE MPLS TE
Before configuring intra-AS seamless MPLS, complete the following tasks:
l Configure IGP protocols to implement connectivity at the access, aggregation, and core
layers and enable MPLS LDP or MPLS TE to implement MPLS forwarding on a public
network.
l Configure IBGP peer relationships between each Cell Site Gateway (CSG) and
Aggregation (AGG), between each AGG and Core ABR, and between each Core ABR and
Mobile Aggregate Service Gateway (MASG).
NOTE
If MPLS TE tunnels are used across the three layers, a tunnel policy or tunnel selector must be configured.
For configuration details, see Tunnel Management Configuration.
Data Preparation
To configure intra-AS seamless MPLS, you need the following data.
No. Data
1 IP address of each interface connecting each CSG to a NodeB and IP address of an

interface connecting each MASG to an MME or SGW
2 Number of an AS to which the access, aggregation, and core layers belong
3 IP addresses of interfaces between all devices
4 The names of routing policies used on each device

6.2.2 Configuring an AGG and a Core ABR as RRs

In the intra-AS seamless MPLS networking, the AGG and core ABR can be configured as RRs
so that CSGs and MASGs can learn one another's loopback routes. The loopback route
information is used to establish an MP-IBPG peer relationship between each CSG and MASG.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp { as-number-plain | as-number-dot }
The BGP view is displayed.
Step 3 Run:
ipv4-family unicast
The IPv4 unicast address family view is displayed.
Step 4 Run:
peer { ipv4-address | group-name } reflect-client
An RR is configured, and the peer is specified as a client.
The AGG's clients are its connected CSG and core ABR. The core ABR's clients are its connected
AGG and MASG.
Step 5 Run:
peer { ipv4-address | group-name } next-hop-local
The device is configured to use its own IP address as the next-hop address of routes when
advertising these routes.
To enable the AGG or core ABR to advertise routes with the next-hop address set to a local
address, run the peer next-hop-local command on the AGG or core ABR.
----End
6.2.3 Enabling BGP Peers to Exchange Labeled IPv4 Routes

In the seamless MPLS networking, before an E2E BGP LSP is established, BGP peers must be
able to exchange labeled IPv4 routes with each other.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
peer { ipv4-address | group-name } label-route-capability [ check-tunnel-
reachable ]
The ability to exchange labeled IPv4 routes with a BGP peer is enabled.
l If the check-tunnel-reachable is configured, a local device advertises an IPv4 unicast route

to its peer if a tunnel between the local and remote devices is unreachable and advertises a
labeled IPv4 route if the tunnel is reachable. This parameter helps prevent a data forwarding
failure when an MP-IBGP peer relationship between the CSG and MASG is established but
an LSP over the peer relationship fails to be established.
l If the check-tunnel-reachable parameter is not configured, the local device advertises a
labeled IPv4 route, regardless of whether a tunnel between the local and remote devices is
unreachable.
----End
6.2.4 Configuring a BGP LSP

Before a BGP LSP is established, a routing policy must be configured to control label
distribution. The egress of the BGP LSP to be established needs to assign an MPLS label to the
route advertised to an upstream node. If a transit node receives a labeled IPv4 route from
downstream, the downstream node must re-assign an MPLS label to the transit node and
advertises the label upstream.
Procedure
l Perform the following steps on each CSG and MASG:
1. Run:
system-view

2. Run:
route-policy route-policy-name permit node node
A Route-Policy node is created.

3. Run:
apply mpls-label
The local device is enabled to assign a label to an IPv4 route.

4. Run:
quit

5. Run:

6. Run:
peer { ipv4-address | group-name } route-policy route-policy-name export

A routing policy for advertising routes matching Route-Policy conditions to a BGP

peer or a BGP peer group is configured.
NOTE
Repeat this step for each BGP peer.

7. Run:
network ip-address [ mask | mask-length ] [ route-policy route-policy-
name ]
The route destined for the loopback interface address is advertised.
This route is labeled and advertised along a path over which a BGP LSP is established.
8. (Optional) Configure the load balancing for BGP labeled routes.
a. To configure the maximum number of BGP labeled routes to balance traffic, run:
maximum load-balancing
ingress-lsp number
By default, the maximum number of labeled BGP routes for load balancing is 1.
After the maximum load-balancing ingress-lsp command is run on the ingress
of a BGP LSP, labeled BGP routes can load-balance traffic as long as equal-cost
labeled BGP routes exist, which improves network bandwidth utilization.
b. (Optional) To ignore IGP metric during BGP routing, run:
bestroute igp-metric-ignore
By default, BGP labeled routes with the same destination but different next-hop
metric values cannot balance traffic. To enable these routes to balance traffic,
run the bestroute igp-metric-ignore command. After this command is run,
routes can be selected to balance traffic, regardless of their IGP metric values.
Exercise caution when using this command.
l Perform the following steps on each AGG and core ABR:
1. Run:
system-view

2. Run:

3. Run:
if-match mpls-label
An IPv4 route is enabled to match an MPLS label.

4. Run:
apply mpls-label

5. Run:
quit

6. Run:


7. Run:

NOTE
----End
6.2.5 (Optional) Configuring the Protection Switching Function

A protection switching function, such as link or node protection, can be configured to provide
high availability for an intra-AS seamless MPLS network.
Context
On an intra-AS seamless MPLS network that has protection switching enabled, if a link or node
fails, traffic switches to a backup path, which implements uninterrupted traffic transmission.
NOTE
If both LDP FRR and BGP Auto FRR functions are configured, only BGP Auto FRR takes effect.
Procedure
l Use an LSP attribute template to configure CR-LSP hot standby.
After configuring a CR-LSP attribute template, perform the following steps:
1. Run:
system-view

2. Run:

3. Run:
attribute-name }
The hot-standby CR-LSP is established using the specified CR-LSP attribute template.
A maximum of three hot-standby CR-LSP attribute templates can be configured, The

setup priority, holding priority, and bandwidth type in these templates must be the
same as those of the primary CR-LSP. To establish a hot-standby CR-LSP, a device
keeps on attempting to use CR-LSP attribute templates one by one in ascending order
of the numbers of the attribute templates until the hot-standby CR-LSP is established.
If the dynamic parameter is configured, a device uses a hot-standby CR-LSP template,

inherits the bandwidth and priorities of the primary CR-LSP, and uses a different path
from the primary LSP to establish a hot-standby CR-LSP.

4. (Optional) Run:
A hot-standby CR-LSP attribute template is locked out.
If an existing hot-standby CR-LSP is established using a lower-priority attribute

template, the device keeps attempting to establish a new hot-standby CR-LSP using
a higher-priority attribute template. To keep traffic traveling on the existing hot-
standby CR-LSP, the hot-standby CR-LSP attribute template used to establish the
existing hot-standby CR-LSP can be locked out, which prevents unwanted traffic
switchovers and efficiently uses device resources.
5. Run:
mpls te commit
The MPLS TE tunnel configuration is committed.

l Configure CR-LSP hot standby without an LSP attribute template.
1. Run:
system-view

2. Run:

3. Run:
mpls te backup hot-standby { wtr interval [ dynamic-bandwidth ] | dynamic-
bandwidth wtr interval }
CR-LSP hot standby is configured.
The dynamic-bandwidth parameter is configured to enable the dynamic bandwidth

function for the hot-standby CR-LSP. With the dynamic bandwidth function enabled,
a device creates a hot-standby CR-LSP without bandwidth assigned, while creating a
primary tunnel. The hot-standby CR-LSP does not use the bandwidth resources before
the primary CR-LSP fails. If the primary CR-LSP fails, the device uses the make-
before-break mechanism to re-establish a hot-standby CR-LSP with specified
bandwidth. If the bandwidth resources are insufficient, traffic switches from the
primary CR-LSP to the hot-standby CR-LSP without bandwidth assigned.
4. Run:
mpls te commit

l Configure LDP manual FRR.
1. Run:
system-view

2. Run:

3. Run:

mpls ldp frr nexthop nexthop-address [ ip-prefix ip-prefix-name ]

[ priority priority ]
NOTE
On the same interface, a maximum of 10 LDP FRR bypass tunnels with different priorities can
be configured, and only one LDP FRR bypass tunnel can be established. The smaller the priority
value, the higher the priority. The default priority value is 50.
l Configure LDP Auto FRR.
1. Run:
system-view

2. Run:
mpls ldp

3. Run:
A policy for triggering backup LDP LSP establishment is configured.
NOTE
LDP Auto FRR depends on IGP Auto FRR. After the frr (IS-IS view) or frr (OSPF view)
command is used to enable IGP Auto FRR, LDP Auto FRR will be automatically enabled. To
change a policy for triggering backup LDP LSP establishment, run the auto-frr lsp-trigger
command.
The auto-frr lsp-trigger command is affected by the lsp-trigger command. If both the auto-
frr lsp-trigger command and the lsp-trigger command are run, the established backup LSPs
satisfy both the policy for triggering LDP LSP establishment and the policy for triggering
backup LDP LSP establishment.
During the LDP GR process, changing a policy for triggering the backup LDP LSP
establishment is not allowed.
l Configure BGP Auto FRR.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast
The BGP-IPv4 unicast address family view is displayed.

4. Run:
auto-frr
BGP Auto FRR is enabled for unicast routes.

5. Run:
bestroute nexthop-resolved tunnel

Labeled BGP IPv4 unicast routes can participate in route selection only when their
next hops are iterated to tunnels.
6. (Optional) Run:
ingress-lsp protect-mode bgp-frr
BGP FRR is enabled for BGP LSPs.
NOTE
Perform this step on each CSG and MASG to enable the protection switching function for the
whole BGP LSP.
l Configure VPN manual FRR.
1. Run:
system-view

2. Run:
route-policy route-policy-name { permit | deny } node node
The Route-Policy node is created, and the Route-Policy view is displayed.

3. Run:
apply backup-nexthop { ipv4-address | auto }
The backup next hop is specified.

4. Run:
quit

5. Run:

6. Run:
ipv4-family
The VPN instance IPv4 address family view is displayed.

7. Run:
vpn frr route-policy route-policy-name
VPN FRR is enabled.

8. (Optional) Run:
quit

9. (Optional) Run:
quit

10. (Optional) Run:

11. (Optional) Run:

ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed.

12. (Optional) Run:
A VPN route is configured to participate in route selection only when its next hop is
iterated to a tunnel. This configuration ensures that packets are not lost during a traffic
switchback.
l Configure VPN Auto FRR.
1. Run:
system-view

2. Run:

3. (Optional) Run:

4. Run:
auto-frr
VPN Auto FRR is enabled.

5. (Optional) Run:
switchback.
----End

After configuring intra-AS seamless MPLS, you can check the established LSPs and the
connectivity of the BGP LSP between the CSG and MASG.
Prerequisites
Intra-AS seamless MPLS has been configured.
Procedure
l Run the display ip routing-table command on the CSG and MASG to check the route to
each other.
l Run the display mpls lsp command to check LSP information.
reply-mode | -s packet-size | -t time-out | -v ] * bgp destination-address mask-length [ ip-
address ] command on a CSG or MASG to check BGP LSP connectivity.

out | -v ] * bgp destination-address mask-length [ ip-address ] command to perform an LSP
tracert operation on a BGP LSP.
----End
Example
Run the display ip routing-table command on a CSG or MASG to view information about a
route to a BGP peer.
<CSG> display ip routing-table
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 1 D 10.1.1.2
4.4.4.4/32 IBGP 255 0 RD 2.2.2.2
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1

<CSG> display mpls lsp
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 1025/NULL -/-
4.4.4.4/32 NULL/1027 -/-
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL -/-
2.2.2.2/32 NULL/3 -/GE1/0/0
2.2.2.2/32 1024/3 -/GE1/0/0
Run the ping lsp command on a CSG or MASG to check BGP LSP connectivity.
<CSG> ping lsp bgp 4.4.4.4 32
LSP PING FEC: BGP LABLED IPV4 PREFIX 4.4.4.4/32/ : 100 data bytes, press CTRL_C
to break
--- FEC: BGP LABLED IPV4 PREFIX 4.4.4.4/32 ping statistics ---
0.00% packet loss

Run the tracert lsp command on a CSG or MASG to perform an LSP tracert operation on a
BGP LSP.
<CSG> tracert lsp bgp 4.4.4.4 32
LSP Trace Route FEC: BGP LABLED IPV4 PREFIX 4.4.4.4/32 , press CTRL_C to break.
0 Ingress 10.1.1.2/[1027 3 ]
1 10.1.1.2 310 ms Transit 10.2.1.2/[1027 3 ]
2 10.2.1.2 190 ms Transit 10.3.1.2/[1025 3 ]
3 4.4.4.4 120 ms Egress
6.3 Configuring Inter-AS Seamless MPLS

In the inter-AS seamless MPLS networking, the access and aggregation layers belong to one
AS, and the core layer belong to another AS. An inter-AS BGP LSP is established across the
three layers to implement E2E service connectivity.

Before configuring inter-AS seamless MPLS, familiarize yourself with the usage scenario,
Usage Scenario
to another AS. Inter-AS seamless MPLS can be configured to transmit services between NodeBs
that are Ethernet stations and an Mobility Management Entity (MME) or Serving Gateway
(SGW).
AS x AS y
IBGP IBGP EBGP IBGP

label label label label
CSG1 AGG1 AGG ASBR1 Core ASBR1 MASG1
NodeB/
eNodeB Access Aggregation Core
MME/
SGW
NodeB/
Before configuring inter-AS seamless MPLS, complete the following tasks:

network.
l Configure an EBGP peer relationship between each pair of an AGG ASBR and core ASBR
and an IBGP peer relationship between each pair of the following nodes:
– Cell Site Gateway (CSG) and Aggregation (AGG)
– AGG and AGG ASBR
– Core ASBR and Mobile Aggregate Service Gateway (MASG)
NOTE
Data Preparation
To configure inter-AS seamless MPLS, you need the following data.
No. Data

2 Number of an AS to which the access and aggregation belongs and number of another
AS to which the core layer belongs
3 IP addresses of connected interfaces of all devices
6.3.2 Configure an AGG as an RR

In the inter-AS seamless MPLS networking, an AGG is configured as an RR to advertise the
route to the CSG's loopback interface to an AGG ASBR, and the AGG ASBR advertises the
route to the core layer over an EBGP peer connection. The loopback route information is used
to establish an MP-EBGP peer relationship between each CSG and MASG.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast

The IPv4 unicast address family view is displayed.
Step 4 Run:
peer { ipv4-address | group-name } reflect-client
An RR is configured, and the CSG and core ASBR are specified as clients.
Step 5 Run:
peer { ipv4-address | group-name } next-hop-local
The device is configured to use its own IP address as the next-hop address of routes when
advertising these routes.
To enable the AGG to advertise routes with the next-hop address set to a local address, run the
peer next-hop-local command on the AGG.
----End

In the seamless MPLS networking, before an E2E BGP LSP is established, BGP peers must be
able to exchange labeled IPv4 routes with each other.
Procedure
l Perform the following steps on each CSG, AGG, and MASG:
1. Run:
system-view

2. Run:

3. Run:
reachable ]
The ability to exchange labeled IPv4 routes between devices in the local AS is enabled.
– If the check-tunnel-reachable is configured, a local device advertises an IPv4

unicast route to its peer if a tunnel between the local and remote devices is
unreachable and advertises a labeled IPv4 route if the tunnel is reachable. This
parameter helps prevent a data forwarding failure when an MP-EBGP peer
relationship between the CSG and MASG is established but an LSP over the peer
relationship fails to be established.
– If the check-tunnel-reachable parameter is not configured, the local device
advertises a labeled IPv4 route, regardless of whether a tunnel between the local
and remote devices is unreachable.
l Perform the following steps on each AGG ASBR and core ASBR:
1. Run:
system-view

2. Run:
The view of the interface connected to the peer ASBR is displayed.

3. Run:
ip address ip-address { mask | mask-length }
An IP address is assigned to the interface.

4. Run:
mpls
MPLS is enabled.
5. Run:
quit

6. Run:

7. Run:
reachable ]
The ability to exchange labeled IPv4 routes between BGP peers, including the peer
ASBR and the devices in the local AS, is enabled.

----End

Procedure
l Perform the following steps on each CSG and MASG:
1. Run:
system-view


2. Run:

3. Run:
apply mpls-label

4. Run:
quit

5. Run:

6. Run:

NOTE

7. Run:
name ]
ingress-lsp number
l Perform the following steps on each AGG, AGG ASBR, and core ASBR:
1. Run:
system-view


2. Run:

3. Run:
if-match mpls-label

4. Run:
apply mpls-label

5. Run:
quit

6. Run:

7. Run:

NOTE
----End
6.3.5 (Optional) Configuring the Mode in Which a BGP Label

Inherits the QoS Priority in an Outer Tunnel Label
When data packets are transmitted from a core ASBR to an AGG ASBR, you can determine
whether a BGP label inherits the QoS priority carried in an outer tunnel label.
Context
In the inter-AS seamless MPLS or inter-AS seamless MPLS+HVPN networking, each packet
arriving at a core ASBR or AGG ASBR carries an inner private label, a BGP LSP label, and an
outer MPLS tunnel label. The core ASBR and AGG ASBR remove outer MPLS tunnel labels
from packets before sending the packets to each other. If a BGP LSP label in a packet carries a
QoS priority different from that in the outer MPLS tunnel label in the packet, you can configure
the core ASBR or AGG ASBR to determine whether the BGP LSP label inherits the QoS priority
carried in the outer MPLS tunnel label to be removed.
Procedure
Step 1 Run:
system-view

Step 2 Run:

ipv4-family unicast
Step 4 Run:
peer { group-name | ipv4-address } exp-mode { pipe | uniform }
The mode in which a BGP label inherits the QoS priority in the outer tunnel label is specified.
You can configure either of the following parameters:

l uniform: The BGP label inherits the QoS priority carried in the outer MPLS tunnel label.
l pipe: The QoS priority carried in the BGP label does not change, and the BGP label does
not inherit the QoS priority carried in the outer MPLS tunnel label.
The default QoS priority inheriting mode varies according to the outer MPLS tunnel type:
l LDP: By default, the BGP label inherits the QoS priority carried in the outer MPLS tunnel
label.
l TE: By default, the BGP label does not inherit the QoS priority carried in the outer MPLS
tunnel label.
----End

high availability for an inter-AS seamless MPLS network.
Context
On an inter-AS seamless MPLS network that has protection switching enabled, if a link or node
fails, traffic switches to a backup path, which implements uninterrupted traffic transmission.
NOTE
Procedure
1. Run:
system-view

2. Run:


3. Run:
attribute-name }


4. (Optional) Run:

5. Run:
mpls te commit

1. Run:
system-view

2. Run:

3. Run:


4. Run:
mpls te commit

1. Run:
system-view

2. Run:

3. Run:
NOTE
1. Run:
system-view

2. Run:
mpls ldp

3. Run:
NOTE
command.
1. Run:

system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
auto-frr

5. Run:
1. Run:
system-view

2. Run:

3. Run:

4. Run:
quit

5. Run:

6. Run:
ipv4-family

7. Run:
VPN FRR is enabled.

8. (Optional) Run:
quit


9. (Optional) Run:
quit

10. Run:

11. (Optional) Run:

12. (Optional) Run:
switchback.
1. Run:
system-view

2. Run:

3. (Optional) Run:

4. Run:
auto-frr

5. (Optional) Run:
switchback.
----End

After configuring inter-AS seamless MPLS, you can check the established LSPs and the
connectivity of the BGP LSP between the CSG and MASG.
Prerequisites
Inter-AS seamless MPLS has been configured.

Procedure
l Run the display ip routing-table command on the CSG and MASG to check the route to
each other.
l Run the display mpls lsp command to check LSP information.
address ] command on a CSG or MASG to check BGP LSP connectivity.
out | -v ] * bgp destination-address mask-length [ ip-address ] command to perform an LSP
tracert operation on a BGP LSP.
----End
Example
Run the display ip routing-table command on a CSG or MASG to view information about a
route to a BGP peer.
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 1 D 10.1.1.2
5.5.5.5/32 IBGP 255 0 RD 2.2.2.2
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 1025/NULL -/-
5.5.5.5/32 NULL/1028 -/-
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL -/-
2.2.2.2/32 NULL/3 -/GE1/0/0
2.2.2.2/32 1024/3 -/GE1/0/0
Run the ping lsp command on a CSG or MASG to check BGP LSP connectivity.
to break


0.00% packet loss
Run the tracert lsp command on a CSG or MASG to perform an LSP tracert operation on a
BGP LSP.
<CSG> tracert lsp bgp 5.5.5.5 32
LSP Trace Route FEC: BGP LABLED IPV4 PREFIX 5.5.5.5/32 , press CTRL_C to break.
0 Ingress 10.1.1.2/[1029 3 ]
1 10.1.1.2 30 ms Transit 10.2.1.2/[1030 3 ]
2 10.2.1.2 60 ms Transit 10.3.1.2/[1027 3 ]
3 10.3.1.2 160 ms Transit 10.4.1.2/[1025 3 ]
4 5.5.5.5 110 ms Egress
6.4 Configuring Inter-AS Seamless MPLS+HVPN

In the inter-AS seamless MPLS+HVPN networking, an HVPN between each CSG and AGG is
configured, and inter-AS seamless MPLS is configured for the link between each AGG and
MASG. The networking integrates the seamless MPLS and HVPN advantages.

Before configuring inter-AS seamless MPLS+HVPN, familiarize yourself with the usage
Usage Scenario
Figure 6-6 illustrates the inter-AS seamless MPLS+HVPN networking. A Cell Site Gateway
(CSG) and an Aggregation (AGG) establish an HVPN connection, and the AGG and an Mobile
Aggregate Service Gateway (MASG) establish a seamless MPLS LSP. The AGG hierarchically
provides L3VPN access services and routing management services. Seamless MPLS+HVPN
combines the advantages of both MPLS and HVPN. Seamless MPLS allows any two nodes on
an inter-AS LSP to transmit services at the access, aggregation, and core layers, providing high
service scalability. HVPN enables carriers to cut down network deployment costs by deploying
devices with layer-specific capacities to meet service requirements.

Figure 6-6 Inter-AS seamless MPLS+HVPN networking
AS x AS y
IBGP EBGP IBGP

label label label
NodeB/
eNodeB Access Aggregation Core
MME/
SGW
NodeB/
Before configuring inter-AS seamless MPLS+HVPN, complete the following tasks:
network.
l Configure an EBGP peer relationship between each pair of an AGG ASBR and core ASBR
and an IBGP peer relationship between each pair of the following nodes:
– CSG and AGG
– AGG and AGG ASBR
– Core ASBR and MASG
l Configure an HVPN between each pair of a CSG and AGG.
NOTE
Data Preparation
To configure inter-AS seamless MPLS+HVPN, you need the following data.
No. Data

2 Number of an AS to which the access and aggregation belongs and number of another
AS to which the core layer belongs

No. Data
3 IP addresses of connected interfaces of all devices
6.4.2 Establishing an MP-EBGP Peer Relationship Between Each

AGG and MASG
MP-EBGP supports BGP extended community attributes that are used to advertise VPNv4 routes
between each pair of the AGG and MASG.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
peer ipv4-address as-number { as-number-plain | as-number-dot }
A BGP peer is configured.

Step 4 Run:
peer { ipv4-address | group-name } connect-interface loopback interface-number
The interface on which a TCP connection to the specified BGP peer is established is specified.
NOTE
The AGG and MASG must use loopback interface addresses with 32-bit masks to establish an MP-EBGP
peer relationship so that the MP-EBGP connection can be iterated to a tunnel.
Step 5 Run:
peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops for an EBGP peer relationship is set.

Step 6 Run:
ipv4-family vpnv4
The BGP-VPNv4 address family view is displayed.

Step 7 Run:
peer { ipv4-address | group-name } enable
The ability to exchange BGP-VPNv4 routes with the specified BGP peer is enabled.
ipv4-family unicast


undo peer { ipv4-address | group-name } enable
The ability to exchange BGP-VPNv4 unicast routes between BGP peers is disabled.
If multiple links between two ASs exist, the ability to exchange BGP-VPNv4 unicast routes
between BGP peers must be disabled to prevent route loops between BGP peers that establish
MP-EBGP peer relationships.
----End

In the inter-AS seamless MPLS+HVPN networking, before an E2E BGP LSP is established
between an AGG and MASG, these two BGP peers must be able to exchange labeled IPv4 routes
with each other.
Procedure
l Perform the following steps on each AGG and MASG:
1. Run:
system-view

2. Run:

3. Run:
peer { ipv4-address | group-name } label-route-capability
The ability to exchange labeled IPv4 routes between devices in the local AS is enabled.
1. Run:
system-view

2. Run:
The view of the interface connected to the peer ASBR is displayed.

3. Run:
ip address ip-address { mask | mask-length }
An IP address is assigned to the interface.

4. Run:
mpls
MPLS is enabled.
5. Run:
quit


6. Run:

7. Run:
reachable ]
The ability to exchange labeled IPv4 routes between BGP peers, including the peer
ASBR and the devices in the local AS, is enabled.

----End

Procedure
l Perform the following steps on each AGG and MASG:
1. Run:
system-view

2. Run:

3. Run:
apply mpls-label

4. Run:
quit

5. Run:


6. Run:

NOTE

7. Run:
name ]
ingress-lsp number
1. Run:
system-view

2. Run:

3. Run:
if-match mpls-label

4. Run:
apply mpls-label

5. Run:
quit


6. Run:

7. Run:

NOTE
----End
6.4.5 (Optional) Configuring the Mode in Which a BGP Label

Inherits the QoS Priority in an Outer Tunnel Label
When data packets are transmitted from a core ASBR to an AGG ASBR, you can determine
whether a BGP label inherits the QoS priority carried in an outer tunnel label.
Context
In the inter-AS seamless MPLS or inter-AS seamless MPLS+HVPN networking, each packet
arriving at a core ASBR or AGG ASBR carries an inner private label, a BGP LSP label, and an
outer MPLS tunnel label. The core ASBR and AGG ASBR remove outer MPLS tunnel labels
from packets before sending the packets to each other. If a BGP LSP label in a packet carries a
QoS priority different from that in the outer MPLS tunnel label in the packet, you can configure
the core ASBR or AGG ASBR to determine whether the BGP LSP label inherits the QoS priority
carried in the outer MPLS tunnel label to be removed.
Procedure
Step 1 Run:
system-view

Step 2 Run:

ipv4-family unicast

Step 4 Run:
peer { group-name | ipv4-address } exp-mode { pipe | uniform }
The mode in which a BGP label inherits the QoS priority in the outer tunnel label is specified.
You can configure either of the following parameters:

l uniform: The BGP label inherits the QoS priority carried in the outer MPLS tunnel label.
l pipe: The QoS priority carried in the BGP label does not change, and the BGP label does
not inherit the QoS priority carried in the outer MPLS tunnel label.
The default QoS priority inheriting mode varies according to the outer MPLS tunnel type:
l LDP: By default, the BGP label inherits the QoS priority carried in the outer MPLS tunnel
label.
l TE: By default, the BGP label does not inherit the QoS priority carried in the outer MPLS
tunnel label.
----End

high availability for an inter-AS seamless MPLS+HVPN network.
Context
On an inter-AS seamless MPLS+HVPN network that has protection switching enabled, if a link
or node fails, traffic switches to a backup path, which implements uninterrupted traffic
transmission.
NOTE
Procedure
1. Run:
system-view

2. Run:

3. Run:
attribute-name }



4. (Optional) Run:

5. Run:
mpls te commit

1. Run:
system-view

2. Run:

3. Run:

4. Run:
mpls te commit

1. Run:
system-view

2. Run:


3. Run:
NOTE
1. Run:
system-view

2. Run:
mpls ldp

3. Run:
NOTE
command.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
auto-frr


5. Run:
1. Run:
system-view

2. Run:

3. Run:

4. Run:
quit

5. Run:

6. Run:
ipv4-family

7. Run:
VPN FRR is enabled.

8. (Optional) Run:
quit

9. (Optional) Run:
quit

10. (Optional) Run:

11. (Optional) Run:

12. (Optional) Run:

switchback.
1. Run:
system-view

2. Run:

3. (Optional) Run:

4. Run:
auto-frr

5. (Optional) Run:
switchback.
----End

After configuring inter-AS seamless MPLS+HVPN, you can check all BGP peer relationships,
VPNv4 routing information on AGGs and MASGs, and the connectivity of the BGP LSP
between each pair of an AGG and MASG.
Prerequisites
Inter-AS seamless MPLS+HVPN has been configured.
Procedure
l Run the display bgp vpnv4 all peer command on an AGG or MASG to check BGP peer
relationship information.
l Run the display bgp vpnv4 all routing-table command to check the VPNv4 routing table
on an AGG or MASG.
l Run the display bgp routing-table label command on an AGG, AGG ASBR, core ASBR,
or MASG to check label information of IPv4 routes.

l Run the display ip routing-table vpn-instance vpn-instance-name command to check the

VRF table on an AGG or MASG.
----End
Example
# Run the display bgp vpnv4 all peer command on an AGG or MASG. The command output
shows that an EBGP peer relationship between two PEs is Established.
Run the display bgp vpnv4 all routing-table command on an AGG or MASG. The command
output shows that BGP VPNv4 routes and BGP VPN instance routes are reachable on the PE,
not on the ASBR.
<HUAWEI> display bgp vpnv4 all routing-table
BGP Local router ID is 1.1.1.9

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 4

Route Distinguisher: 100:1
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 22.22.22.22/32 3.3.3.9 0 100 0 ?
Route Distinguisher: 100:4
*> 10.1.2.0/24 0.0.0.0 0 0 ?

*> 10.1.2.1/32 0.0.0.0 0 0 ?
*> 11.11.11.11/32 0.0.0.0 0 0 ?
VPN-Instance vpn1, Router ID 1.1.1.9:
Total Number of Routes: 4

*> 10.1.2.0/24 0.0.0.0 0 0 ?

*> 10.1.2.1/32 0.0.0.0 0 0 ?
*> 11.11.11.11/32 0.0.0.0 0 0 ?
*>i 22.22.22.22/32 3.3.3.9 0 100 0 ?
Run the display bgp routing-table label command on an AGG, AGG ASBR, core ASBR, or
MASG to view information about labels of IPv4 routes.
<HUAWEI> display bgp routing-table label
Total Number of Routes: 2
BGP Local router ID is 2.2.2.9
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network NextHop In/Out Label
*> 1.1.1.9 172.1.1.2 15360/NULL
*> 4.4.4.9 192.1.1.2 15361/15361
Run the display ip routing-table vpn-instance command on an AGG or MASG. The command
output shows that the VRF table has reachable VPN routes.

<HUAWEI> display ip routing-table vpn-instance vpn1

------------------------------------------------------------------------------
Routing Tables: vpn1

5.5.5.0/24 Static 60 0 RD 1.1.1.2 Ethernet2/0/0
6.5 Maintaining Seamless MPLS

The seamless MPLS maintenance involves checking the connectivity and reachability of
seamless MPLS networks.
6.5.1 Checking Network Connectivity and Reachability

Run the ping and tracert commands to check the connectivity and reachability of seamless
MPLS networks.
Context
Run the following commands in any view of a BGP LSP endpoint node to check the connectivity
and reachability of a BGP LSP.
Procedure
address ] command to check BGP LSP connectivity.
out | -v ] * bgp destination-address mask-length [ ip-address ] [ nexthop nexthop-
address | draft6 ] command to perform an LSP tracert operation on a BGP LSP.
----End

This section provides examples for configuring seamless MPLS networks. In each configuration
example, the networking requirements, configuration notes, configuration roadmap,
configuration procedures, and configuration files are provided.
6.6.1 Example for Configuring Intra-AS Seamless MPLS

When the access, aggregation, and core layers belong to the same AS, intra-AS seamless MPLS
can be configured to implement the service connectivity between NodeBs and an MME or SGW.

In Figure 6-7, the access, aggregation, and core layers belong to the same AS. NodeBs need to
communicate with an MME or SGW over a VPN. To meet this requirement, intra-AS seamless
MPLS can be configured.
Figure 6-7 Intra-AS seamless MPLS networking (1)

Core
CSG1 AGG1 ABR1 MASG1
NodeB
MME/
SGW
Access Aggregation Core
NodeB CSG2 AGG2 Core MASG2

ABR2
Addresses of interfaces are planned for CSGs, AGGs, core ABRs, and MASGs shown in Figure
6-8.
Figure 6-8 Intra-AS seamless MPLS networking (2)

Loopback1 Loopback1 Loopback1 Loopback1
1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4
GE1/0/0 GE2/0/0 GE1/0/0
20.1.1.1/24 20.2.1.1/24 20.3.1.2/24
GE1/0/0 GE1/0/0 GE2/0/0
20.1.1.2/24 20.2.1.2/24 Core 20.3.1.1/24
CSG AGG MASG
ABR
1. Configure IGP protocols at the access, aggregation, and core layers to implement network
connectivity at each layer.
2. Configure MPLS and MPLS LDP and establish MPLS LSPs on devices.
3. Establish IBGP peer relationships at each layer and enable devices to exchange labeled
routes.

4. Configure each AGG and core ABR as RRs to help a CSG and MASG obtain the route
destined for each other's loopback interface.
5. Configure a routing policy to control label distribution for a BGP LSP to be established on
each device. The egress of the BGP LSP to be established needs to assign an MPLS label
to the route advertised to an upstream node. If a transit node receives a labeled IPv4 route
from downstream, the downstream node must re-assign an MPLS label to the transit node.
Data Preparation
l MPLS LSR IDs: 1.1.1.1 for the CSG, 2.2.2.2 for the AGG, 3.3.3.3 for the core ABR, and
4.4.4.4 for the MASG
Procedure
address as an LSR ID on every device shown in Figure 6-8; configure OSPF and IS-IS to
advertise the route to the network segment of each interface and a host route to each loopback
interface address (LSR ID). For configuration details, see Configuration Files in this section.
Step 2 Enable MPLS and LDP globally on each device.
# Configure the CSG.
[CSG] mpls lsr-id 1.1.1.1
[CSG] mpls
[CSG-mpls] quit
[CSG] mpls ldp
[CSG-mpls-ldp] quit
[CSG] interface GigabitEthernet 1/0/0
[CSG-GigabitEthernet1/0/0] mpls
[CSG-GigabitEthernet1/0/0] mpls ldp
[CSG-GigabitEthernet1/0/0] quit

[AGG] mpls lsr-id 2.2.2.2
[AGG] mpls
[AGG-mpls] quit
[AGG] mpls ldp
[AGG-mpls-ldp] quit
[AGG] interface GigabitEthernet 1/0/0
[AGG-GigabitEthernet1/0/0] mpls
[AGG-GigabitEthernet1/0/0] mpls ldp
[AGG-GigabitEthernet1/0/0] quit
# Configure the core ABR.

[Core ABR] mpls lsr-id 3.3.3.3
[Core ABR] mpls

[Core ABR-mpls] quit

[Core ABR] mpls ldp
[Core ABR-mpls-ldp] quit
[Core ABR] interface GigabitEthernet 1/0/0
[Core ABR-GigabitEthernet1/0/0] mpls
[Core ABR-GigabitEthernet1/0/0] mpls ldp
[Core ABR-GigabitEthernet1/0/0] quit
[Core ABR] interface GigabitEthernet 2/0/0
[Core ABR-GigabitEthernet2/0/0] mpls
[Core ABR-GigabitEthernet2/0/0] mpls ldp
[Core ABR-GigabitEthernet2/0/0] quit

[MASG] mpls lsr-id 4.4.4.4
[MASG] mpls
[MASG-mpls] quit
[MASG] mpls ldp
[MASG-mpls-ldp] quit
[MASG] interface GigabitEthernet 1/0/0
[MASG-GigabitEthernet1/0/0] mpls
[MASG-GigabitEthernet1/0/0] mpls ldp
[MASG-GigabitEthernet1/0/0] quit
[CSG] bgp 100
[CSG-bgp] quit

[AGG] bgp 100
[AGG-bgp] quit

[Core ABR] bgp 100
[Core ABR-bgp] peer 2.2.2.2 as-number 100
[Core ABR-bgp] peer 2.2.2.2 connect-interface LoopBack 1
[Core ABR-bgp] peer 2.2.2.2 label-route-capability
[Core ABR-bgp] peer 4.4.4.4 as-number 100
[Core ABR-bgp] peer 4.4.4.4 connect-interface LoopBack 1
[Core ABR-bgp] peer 4.4.4.4 label-route-capability
[Core ABR-bgp] quit

[MASG] bgp 100
[MASG-bgp] quit
Step 4 Configure each AGG and core ABR as RRs to help a CSG and MASG obtain the route destined
for each other's loopback interface.


[AGG] bgp 100
[AGG-bgp] quit

[Core ABR] bgp 100
[Core ABR-bgp] peer 2.2.2.2 reflect-client
[Core ABR-bgp] peer 2.2.2.2 next-hop-local
[Core ABR-bgp] peer 4.4.4.4 reflect-client
[Core ABR-bgp] peer 4.4.4.4 next-hop-local
[Core ABR-bgp] quit
Step 5 Configure a routing policy on each device to establish a BGP LSP.
CSG's BGP peer.
[CSG] bgp 100
[CSG-bgp] quit
[CSG] quit
AGG's BGP peer.
[AGG] bgp 100
[AGG-bgp] quit
Repeat this step for the core ABR. For configuration details, see Configuration Files in this
section.
After completing the configuration, run the display ip routing-table command on a CSG or
MASG to view information about a route to the BGP peer's loopback interface.
The following example uses the command output on the CSG.

------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 1 D 20.1.1.2

4.4.4.4/32 IBGP 255 0 RD 2.2.2.2

20.1.1.0/24 Direct 0 0 D 20.1.1.1
20.1.1.1/32 Direct 0 0 D 127.0.0.1
Run the display mpls lsp command on the CSG or MASG to view LSP information.

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 1025/NULL -/-
4.4.4.4/32 NULL/1027 -/-
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL -/-
2.2.2.2/32 NULL/3 -/GE1/0/0
2.2.2.2/32 1024/3 -/GE1/0/0
Run the ping lsp command on the CSG or MASG to check BGP LSP connectivity.

to break
0.00% packet loss
----End
Configuration Files
#
sysname CSG
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#

interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 1.1.1.1 255.255.255.255
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 20.1.1.0 0.0.0.255
#
apply mpls-label
#
return

#
sysname AGG
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0000.0010.00
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 20.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable


#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 20.1.1.0 0.0.0.255
#
if-match mpls-label
apply mpls-label
#
return
l Core ABR configuration file

#
sysname Core ABR
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0000.0020.00
#
undo shutdown
ip address 20.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 20.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 2
area 0.0.0.0
network 3.3.3.3 0.0.0.0

network 20.3.1.0 0.0.0.255

#
if-match mpls-label
apply mpls-label
#
return

#
sysname MASG
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
undo shutdown
ip address 20.3.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 4.4.4.4 255.255.255.255
peer 3.3.3.3 enable
#
ospf 2
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 20.3.1.0 0.0.0.255
#
apply mpls-label
#
return
6.6.2 Example for Configuring Inter-AS Seamless MPLS

When the access and aggregation layers belong to one AS, and the core layer belongs to another
AS, inter-AS seamless MPLS can be configured to implement the service connectivity between
a NodeB and an MME or SGW.
to another AS. NodeBs need to communicate with an MME or SGW over a VPN. To meet this
requirement, inter-AS seamless MPLS can be configured.

Figure 6-9 Inter-AS seamless MPLS networking (1)
AS 100 AS 200
AGG Core
CSG1 AGG1 ASBR1 ASBR1 MASG1
NodeB
MME/
SGW
Access Aggregation Core
NodeB CSG2 AGG2 AGG Core MASG2

ASBR1 ASBR2
Addresses of interfaces are planned for the CSGs, AGGs, AGG ASBRs, core ASBRs, and
MASGs shown in Figure 6-10.
Figure 6-10 Inter-AS seamless MPLS networking (2)
AS 100 AS 200

1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 5.5.5.5
GE1/0/0 GE2/0/0 GE1/0/0 GE1/0/0
20.1.1.1/24 20.2.1.1/24 20.3.1.2/24 20.4.1.2/24
GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0
20.1.1.2/24 20.2.1.2/24 AGG 20.3.1.1/24 Core 20.4.1.1/24
CSG AGG MASG
ASBR ASBR
2. Configure MPLS and MPLS LDP and establish MPLS LSPs at the access, aggregation,
and core layers.
3. Establish IBGP peer relationships at each layer and enable devices to exchange labeled
routes.

4. Configure an EBGP peer relationship between each pair of an AGG ASBR and core ASBR
and enable these devices to exchange labeled routes across ASs.
5. Configure each AGG as an RR to help the CSG and MASG obtain the route destined for
each other's loopback interface.
each device. The egress of the BGP LSP to be established needs to assign an MPLS label
to the route advertised to an upstream node. If a transit node receives a labeled IPv4 route
from downstream, the downstream node must re-assign an MPLS label to the transit node.
Data Preparation
4.4.4.4 for the core ASBR, and 5.5.5.5 for the MASG.
Procedure

[CSG] mpls
[CSG-mpls] quit
[CSG] mpls ldp
[CSG-mpls-ldp] quit

<AGG> system-view
[AGG] mpls
[AGG-mpls] quit
[AGG] mpls ldp
[AGG-mpls-ldp] quit


[AGG ASBR] mpls lsr-id 3.3.3.3
[AGG ASBR] mpls
[AGG ASBR-mpls] quit
[AGG ASBR] mpls ldp
[AGG ASBR-mpls-ldp] quit
[AGG ASBR-GigabitEthernet1/0/0] mpls ldp

[Core ASBR] mpls lsr-id 4.4.4.4
[Core ASBR] mpls
[Core ASBR-mpls] quit
[Core ASBR] mpls ldp
[Core ASBR-mpls-ldp] quit
[Core ASBR-GigabitEthernet2/0/0] mpls ldp

[MASG] mpls
[MASG-mpls] quit
[MASG] mpls ldp
[CSG] bgp 100
[CSG-bgp] quit

[AGG] bgp 100
[AGG-bgp] quit

<AGG ASBR> system-view
[AGG ASBR] bgp 100
[AGG ASBR-bgp] quit

<Core ASBR> system-view

[Core ASBR] bgp 200

[MASG] bgp 200
[MASG-bgp] quit
Step 4 Establish an EBGP peer relationship between each pair of an AGG ASBR and core ASBR and
enable these devices to exchange labeled routes.
[AGG ASBR] bgp 100
[AGG ASBR-bgp] quit

[Core ASBR] bgp 200
Step 5 Configure each AGG as an RR to help the CSG and MASG obtain the route destined for each
other's loopback interface.
[AGG] bgp 100
[AGG-bgp] quit

CSG's BGP peer.
[CSG] bgp 100
[CSG-bgp] quit
[CSG] quit

AGG's BGP peer.
[AGG] bgp 100
[AGG-bgp] quit
Repeat this step for the AGG ASBR and core ASBR. For configuration details, see
After completing the configuration, run the display ip routing-table command on a CSG or
MASG to view information about a route to the BGP peer's loopback interface.

------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 1 D 20.1.1.2
5.5.5.5/32 IBGP 255 0 RD 2.2.2.2
20.1.1.0/24 Direct 0 0 D 20.1.1.1
20.1.1.1/32 Direct 0 0 D 127.0.0.1
Run the display mpls lsp command on the CSG or MASG to view LSP information.

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 1025/NULL -/-
5.5.5.5/32 NULL/1028 -/-
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL -/-
2.2.2.2/32 NULL/3 -/GE1/0/0
2.2.2.2/32 1024/3 -/GE1/0/0
Run the ping lsp command on the CSG or MASG to check BGP LSP connectivity.


to break
0.00% packet loss
----End
Configuration Files
#
sysname CSG
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 1.1.1.1 255.255.255.255
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 20.1.1.0 0.0.0.255
#
apply mpls-label
#
return

#
sysname AGG
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#

isis 1
network-entity 10.0000.0000.0000.0010.00
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 20.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 20.1.1.0 0.0.0.255
#
if-match mpls-label
apply mpls-label
#
return

#
sysname AGG ASBR
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0000.0020.00
#
undo shutdown
ip address 20.2.1.2 255.255.255.0
isis enable 1
mpls

mpls ldp
#
undo shutdown
ip address 20.3.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
if-match mpls-label
apply mpls-label
#
return

#
sysname Core ASBR
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
undo shutdown
ip address 20.3.1.2 255.255.255.0
mpls
#
undo shutdown
ip address 20.4.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 5.5.5.5 enable

#
ospf 2
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 20.4.1.0 0.0.0.255
#
if-match mpls-label
apply mpls-label
#
return

#
sysname MASG
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
undo shutdown
ip address 20.4.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 5.5.5.5 255.255.255.255
peer 4.4.4.4 enable
#
ospf 2
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 20.4.1.0 0.0.0.255
#
apply mpls-label
#
return
6.6.3 Example for Configuring Inter-AS Seamless MPLS+HVPN

In the inter-AS seamless MPLS+HVPN networking, an HVPN connection between a CSG and
AGG is established, and an inter-AS seamless MPLS LSP between an AGG and MASG is
established. The inter-AS seamless MPLS+HVPN networking obtains the collective advantages
of the inter-AS seamless MPLS network and HVPN.
to another AS. Before VPN services is provisioned, the inter-AS seamless MPLS+HVPN
networking can be deployed. This networking allows NodeBs and the RNC to communicate and

has low networking construction costs because of HVPN techniques. An HVPN connection
between each pair of a CSG and AGG is established, and an inter-AS seamless MPLS LSP
between each pair of an AGG and MASG is established.
Figure 6-11 Inter-AS seamless MPLS+HVPN networking (1)
AS 100 AS 200
AGG Core
CSG1 AGG1 ASBR1 ASBR1 MASG1
NodeB
MME/
SGW
Access
Aggregation Core
HVPN
NodeB CSG2 AGG2 AGG Core MASG2

ASBR1 ASBR2
Addresses of interfaces are planned for the CSGs, AGGs, AGG ASBRs, core ASBRs, and
MASGs shown in Figure 6-12.
Figure 6-12 Inter-AS seamless MPLS+HVPN networking (2)
AS 100 AS 200

1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 5.5.5.5
GE1/0/0 GE2/0/0 GE1/0/0 GE1/0/0
20.1.1.1/24 20.2.1.1/24 20.3.1.2/24 20.4.1.2/24
GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0
CSG 20.1.1.2/24 AGG 20.2.1.2/24 AGG 20.3.1.1/24 Core 20.4.1.1/24
ASBR ASBR MASG
10.1.1.1/24
GE2/0/0
GE2/0/0
10.2.1.1/24
MME/
SGW
NodeB

2. Configure MPLS and MPLS LDP and establish MPLS LSPs at the access, aggregation,
and core layers.
3. Establish IBGP peer relationships at the aggregation and core layers and enable devices to
exchange labeled routes.
4. Configure an EBGP peer relationship between each pair of an AGG ASBR and core ASBR
and enable these devices to exchange labeled routes across ASs.
each device, except CGSs. The egress of the BGP LSP to be established needs to assign an
MPLS label to the route advertised to an upstream node. If a transit node receives a labeled
IPv4 route from downstream, the downstream node must re-assign an MPLS label to the
transit node.
6. Configure an MP-EBGP peer relationship between an AGG and MASG to allow these
devices to exchange VPNv4 route information.
7. Configure an MP-IBGP peer relationship between an CSG and AGG to allow these devices
to exchange VPNv4 route information.
8. Configure VPN instances on each CSG, AGG, and MASG.
9. Configure a default route and an IP address prefix list on each AGG so that the AGG only
advertises the default route to its directly connected CSG.
Data Preparation
4.4.4.4 for the core ASBR, and 5.5.5.5 for the MASG.
Procedure
[CSG] mpls
[CSG-mpls] quit
[CSG] mpls ldp

[CSG-mpls-ldp] quit

[AGG] mpls
[AGG-mpls] quit
[AGG] mpls ldp
[AGG-mpls-ldp] quit

[AGG ASBR] mpls lsr-id 3.3.3.3
[AGG ASBR] mpls
[AGG ASBR-mpls] quit
[AGG ASBR] mpls ldp
[AGG ASBR-mpls-ldp] quit
[AGG ASBR-GigabitEthernet1/0/0] mpls ldp

[Core ASBR] mpls lsr-id 4.4.4.4
[Core ASBR] mpls
[Core ASBR-mpls] quit
[Core ASBR] mpls ldp
[Core ASBR-mpls-ldp] quit
[Core ASBR-GigabitEthernet2/0/0] mpls ldp

[MASG] mpls
[MASG-mpls] quit
[MASG] mpls ldp
Step 3 Establish IBGP peer relationships at the aggregation and core layers and enable devices to
[AGG] bgp 100
[AGG-bgp] network 2.2.2.2 32

[AGG-bgp] quit

[AGG ASBR] bgp 100
[AGG ASBR-bgp] quit

[Core ASBR] bgp 200

[MASG] bgp 200
[MASG-bgp] quit
Step 4 Establish an EBGP peer relationship between each pair of an AGG ASBR and core ASBR and
enable these devices to exchange labeled routes.
[AGG ASBR] bgp 100
[AGG ASBR-bgp] quit

[Core ASBR] bgp 200
Step 5 Configure an MP-EBGP peer relationship between each pair of an AGG and MASG.
[AGG] bgp 100
[AGG-bgp] peer 5.5.5.5 ebgp-max-hop 10
[AGG-bgp] ipv4-family vpnv4
[AGG-bgp-af-vpnv4] peer 5.5.5.5 enable
[AGG-bgp-af-vpnv4] quit
[AGG-bgp] quit

[MASG] bgp 200


[MASG-bgp] peer 2.2.2.2 ebgp-max-hop 10
[MASG-bgp] ipv4-family vpnv4
[MASG-bgp-af-vpnv4] peer 2.2.2.2 enable
[MASG-bgp-af-vpnv4] quit
[MASG-bgp] quit
Step 6 Configure a routing policy to establish a BGP LSP.

AGG's BGP peer.
<AGG> system-view
[AGG] bgp 100
[AGG-bgp] quit
AGG ASBR's BGP peer.
[AGG ASBR] route-policy policy1 permit node 1
[AGG ASBR-route-policy] if-match mpls-label
[AGG ASBR-route-policy] apply mpls-label
[AGG ASBR-route-policy] quit
[AGG ASBR] bgp 100
[AGG ASBR-bgp] peer 2.2.2.2 route-policy policy1 export
[AGG ASBR-bgp] peer 20.3.1.2 route-policy policy1 export
[AGG ASBR-bgp] quit
Repeat this step for the core ASBR. For configuration details, see Configuration Files in this
section.
After completing the preceding configurations, run the ping lsp command on an AGG or MASG.
The command output shows that the AGG and MASG can ping each other. This indicates that
the BGP LSP between the ASS and MASG has been established.
The following example uses the command output on the AGG.
<AGG> ping lsp bgp 5.5.5.5 32
to break
0.00% packet loss
Step 7 Configure an MP-EBGP peer relationship between each pair of a CSG and MASG.
[CSG] bgp 100


[CSG-bgp] ipv4-family vpnv4
[CSG-bgp-af-vpnv4] peer 2.2.2.2 enable
[CSG-bgp-af-vpnv4] quit
[CSG-bgp] quit

[AGG] bgp 100
[AGG-bgp-af-vpnv4] peer 1.1.1.1 enable
[AGG-bgp] quit
Step 8 Configure a VPN instance and bind an interface of each device to the VPN instance.
[CSG] ip vpn-instance vpn1
[CSG-vpn-instance-vpn1] ipv4-family
[CSG-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[CSG-vpn-instance-vpn1-af-ipv4] vpn-target 1:1
[CSG-vpn-instance-vpn1-af-ipv4] quit
[CSG-vpn-instance-vpn1] quit
[CSG-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[CSG-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[CSG] bgp 100
[CSG-bgp] ipv4-family vpn-instance vpn1
[CSG-bgp-vpn1] import-route direct
[CSG-bgp-vpn1] quit
[CSG-bgp] quit
[CSG] quit
[AGG] ip vpn-instance vpn1
[AGG-vpn-instance-vpn1] ipv4-family
[AGG-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[AGG-vpn-instance-vpn1-af-ipv4] vpn-target 1:1
[AGG-vpn-instance-vpn1-af-ipv4] quit
[AGG-vpn-instance-vpn1] quit
Step 9 Configure a default route and an IP address prefix list on each AGG so that the AGG only
advertises the default route to its directly connected CSG.
[AGG] ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0
[AGG] ip ip-prefix default index 10 permit 0.0.0.0 0
[AGG] bgp 100
[AGG-bgp-af-vpnv4] peer 1.1.1.1 ip-prefix default export
[AGG-bgp-af-vpnv4] quit
[AGG-bgp] ipv4-family vpn-instance vpn1
[AGG-bgp-vpn1] network 0.0.0.0 0
[AGG-bgp-vpn1] quit
[AGG-bgp] quit

After completing the preceding configurations, run the display ip routing-table command on
the CSG. The command output shows that the CSG has a default route with its directly connected
AGG as the next hop, but does not have a VPN route to the MME or SGW. In addition, the CSG
can ping the MME or SGW.


<CSG> display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------
Routing Tables: vpn1
0.0.0.0/0 IBGP 255 0 RD 2.2.2.2

10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet2/0/0
<CSG> ping -vpn-instance vpn1 10.2.1.1
PING 10.2.1.0: 56 data bytes, press CTRL_C to break
Reply from 10.2.1.1: bytes=56 Sequence=1 ttl=252 time=100 ms
--- 10.2.1.0 ping statistics ---

0.00% packet loss
----End
Configuration Files
#
sysname CSG
#
ipv4-family
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip binding vpn-instance vpn1
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#

ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 20.1.1.0 0.0.0.255
#
apply mpls-label
#
return

#
sysname AGG
#
ipv4-family
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0000.0010.00
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 20.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
peer 5.5.5.5 ebgp-max-hop 10
#
ipv4-family unicast

network 2.2.2.2 255.255.255.255

peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 5.5.5.5 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
peer 1.1.1.1 ip-prefix default export
peer 5.5.5.5 enable
#
network 0.0.0.0
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 20.1.1.0 0.0.0.255
#
apply mpls-label
#
ip ip-prefix default index 10 permit 0.0.0.0 0
#
ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 NULL0
#
return

#
sysname AGG ASBR
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0000.0020.00
#
undo shutdown
ip address 20.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 20.3.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable


#
if-match mpls-label
apply mpls-label
#
return

#
sysname Core ASBR
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
undo shutdown
ip address 20.3.1.2 255.255.255.0
mpls
#
undo shutdown
ip address 20.4.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 5.5.5.5 enable
#
ospf 2
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 20.4.1.0 0.0.0.255
#
if-match mpls-label
apply mpls-label
#
return

#
sysname MASG
#
ipv4-family


#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
undo shutdown
ip binding vpn-instance vpn1
ip address 10.2.1.1 255.255.255.0
#
undo shutdown
ip address 20.4.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 200
peer 2.2.2.2 ebgp-max-hop 10
#
ipv4-family unicast
network 5.5.5.5 255.255.255.255
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
#
ospf 2
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 20.4.1.0 0.0.0.255
#
apply mpls-label
#
return
6.6.4 Example for Configuring Seamless MPLS to Transmit L2VPN

Services
Seamless MPLS can establish an E2E LSP to transmit L2VPN services.
Figure 6-13 illustrates the P2MP L2VPN enterprise service networking. The access,
aggregation, and core layers belong to the same AS. NodeBs need to communicate over a VPN.
To meet this requirement, intra-AS seamless MPLS can be configured. Seamless MPLS can

transmit L2VPN services, including VLL, PWE3, and VPLS. In this example, HVPLS is
configured at the access layer, and an intra-seamless MPLS LSP is established across the
aggregation and core layers to transmit the L2VPN service.
Figure 6-13 P2MP L2VPN enterprise service networking

Core Core
ABR1 ABR3
GE2/0/0 GE1/0/0
GE
3/ /0
/0
GE1/0/0
Core
GE2/0/0
0/0 3
Core Core GE
GE ABR2 ABR4
3/ /0
0/ 3 /0
0
GE2/0/0 GE1/0/0 GE
Aggregation Aggregation
GE1/0/0 GE2/0/0
GE2/0/0
GE1/0/0
GE2/0/0 GE1/0/0
GE3/0/0 GE3/0/0
AGG2 AGG4
GE3/0/0 GE3/0/0
GE1/0/0 GE1/0/0 GE2/0/0 GE2/0/0
AGG1 se AGG3
PW dary
Access Access
PW ary
co W
pr
n
im
nd
m
P
co
PW
pri
a ry
a ry
se
GE1/0/0 GE2/0/0 GE2/0/0 GE1/0/0
GE3/0/0 CSG1 GE3/0/0 CSG2
GE1/0/0 GE1/0/0
NodeB1 NodeB2

Name Name Name Name
CSG1 GE1/0/0 172.1.1.1/24 CSG2 GE1/0/0 192.1.1.1/24
GE2/0/0 172.2.1.1/24 GE2/0/0 192.2.1.1/24
GE3/0/0 - GE3/0/0 -
AGG1 GE 1/0/0 172.1.1.2/24 AGG3 GE 1/0/0 30.1.1.2/24


Name Name Name Name
GE 2/0/0 10.1.1.1/24 GE 2/0/0 192.1.1.2/24
GE 3/0/0 172.3.1.1/24 GE 3/0/0 192.3.1.1/24
AGG2 GE 1/0/0 172.2.1.2/24 AGG4 GE 1/0/0 30.2.1.2/24
GE 2/0/0 10.2.1.1/24 GE 2/0/0 192.2.1.2/24
GE 3/0/0 172.3.1.2/24 GE 3/0/0 192.3.1.2/24
Core ABR1 GE 1/0/0 10.1.1.2/24 Core ABR3 GE 1/0/0 20.1.1.2/24
GE 2/0/0 20.1.1.1/24 GE 2/0/0 30.1.1.1/24
GE 3/0/0 10.3.1.1/24 GE 3/0/0 30.3.1.1/24
Core ABR2 GE 1/0/0 10.2.1.2/24 Core ABR4 GE 1/0/0 20.2.1.1/24
GE 2/0/0 20.2.1.1/24 GE 2/0/0 30.2.1.1/24
GE 3/0/0 10.3.1.2/24 GE 3/0/0 30.3.1.2/24
NodeB1 GE 1/0/0 100.1.1.1/24 NodeB2 GE 1/0/0 100.1.1.2/24
2. Configure MPLS and MPLS LDP and establish MPLS LSPs on devices.
3. Establish IBGP peer relationships at the aggregation and core layers and enable devices to

4. Configure each core ABR as an RR to help an AGG obtain the route destined for the remote
AGG's loopback interface.
each core ABR and AGG. The egress of the BGP LSP to be established needs to assign an
MPLS label to the route advertised to an upstream node. If a transit node receives a labeled
IPv4 route from downstream, the downstream node must re-assign an MPLS label to the
transit node.
6. Configure HVPLS at the access layer.
Data Preparation
l OSPF process IDs (1 and 2) at the access layer, IS-IS process IDs (1 and 2) at the aggregation
layer, and OSPF process ID (3) at the core layer
l MPLS LSR IDs: 1.1.1.1 for CSG1, 2.2.2.2 for AGG1, 3.3.3.3 for AGG2, 4.4.4.4 for core
ABR1, 5.5.5.5 for core ABR2, 6.6.6.6 for core ABR3, 7.7.7.7 for core ABR4, 8.8.8.8 for
AGG3, 9.9.9.9 for AGG4, and 10.10.10.10 for CSG2
l VSI name (1) and VSI IDs (100 and 200)
Procedure

Step 3 Establish IBGP peer relationships at the aggregation and core layers and enable devices to
# Configure AGG1.
[AGG1] bgp 100
[AGG1-bgp] peer 4.4.4.4 as-number 100
[AGG1-bgp] peer 4.4.4.4 connect-interface LoopBack 1
[AGG1-bgp] peer 4.4.4.4 label-route-capability
[AGG1-bgp] peer 5.5.5.5 as-number 100
[AGG1-bgp] peer 5.5.5.5 connect-interface LoopBack 1
[AGG1-bgp] peer 5.5.5.5 label-route-capability
[AGG1-bgp] quit
Repeat this step on AGG2, AGG3, and AGG4. For configuration details, see Configuration
# Configure core ASBR1.

[Core ABR1] bgp 100
[Core ABR1-bgp] peer 2.2.2.2 as-number 100
[Core ABR1-bgp] peer 2.2.2.2 connect-interface LoopBack 1
[Core ABR1-bgp] peer 2.2.2.2 label-route-capability


[Core ABR1-bgp] quit
Repeat this step on core ABR2, core ABR3, and core ABR4. For configuration details, see
Step 4 Configure each core ABR as an RR to help an AGG obtain the route destined for the remote
AGG's loopback interface. In the following example, the configuration on core ABR1 is used.
[Core ABR1] bgp 100
[Core ABR1-bgp] peer 2.2.2.2 reflect-client
[Core ABR1-bgp] peer 2.2.2.2 next-hop-local

AGG's BGP peer. In the following example, the configuration on AGG1 is used.
[AGG1] route-policy policy1 permit node 1
[AGG1-route-policy] apply mpls-label
[AGG1-route-policy] quit
[AGG1] bgp 100
[AGG1-bgp] peer 4.4.4.4 route-policy policy1 export
[AGG1-bgp] peer 5.5.5.5 route-policy policy1 export
[AGG1-bgp] quit
# Configure a routing policy for advertising routes matching Route-Policy conditions to the core
AGG's BGP peer. In the following example, the configuration on core ABR1 is used.
[Core ABR1] route-policy policy1 permit node 1
[Core ABR1-route-policy] if-match mpls-label
[Core ABR1-route-policy] apply mpls-label
[Core ABR1-route-policy] quit
[Core ABR1] bgp 100
[Core ABR1-bgp] peer 2.2.2.2 route-policy policy1 export
Run the ping lsp command on an AGG to check BGP LSP connectivity.
The following example uses the command output on AGG1.
<AGG1> ping lsp bgp 8.8.8.8 32
to break

0.00% packet loss
Step 6 Configure HVPLS at the access layer.

1. Configure a remote MPLS LDP session between CSG1 and each AGG.
# Configure CSG1.
[CSG1] mpls ldp remote-peer 2.2.2.2
[CSG1-mpls-ldp-remote-2.2.2.2] remote-ip 2.2.2.2
[CSG1-mpls-ldp-remote-2.2.2.2] quit
[CSG1] mpls ldp remote-peer 3.3.3.3
[CSG1-mpls-ldp-remote-3.3.3.3] remote-ip 3.3.3.3
[CSG1-mpls-ldp-remote-3.3.3.3] quit
Repeat this step for CSG2. For configuration details, see Configuration Files in this
section.
# Configure AGG1.
[AGG1] mpls ldp remote-peer 1.1.1.1
[AGG1-mpls-ldp-remote-1.1.1.1] remote-ip 1.1.1.1
[AGG1-mpls-ldp-remote-1.1.1.1] quit
Repeat this step on AGG2, AGG3, and AGG4. For configuration details, see
2. Configure a remote MPLS LDP session between each AGG and its remote AGG.
# Configure AGG1.
3. Configure PW redundancy and a spoke PW.
# Configure CSG1.
[CSG1] mpls l2vpn
[CSG1-l2vpn] quit
[CSG1] interface gigabitethernet 3/0/0
[CSG1-GigabitEthernet3/0/0] undo shutdown
[CSG1-GigabitEthernet3/0/0] quit
[CSG1] interface gigabitethernet 3/0/0.10
[CSG1-GigabitEthernet3/0/0.10] vlan-type dot1q 10
[CSG1-GigabitEthernet3/0/0.10] mpls l2vc 2.2.2.2 100
[CSG1-GigabitEthernet3/0/0.10] mpls l2vc 3.3.3.3 200 secondary
[CSG1-GigabitEthernet3/0/0.10] mpls l2vpn redundancy master
[CSG1-GigabitEthernet3/0/0.10] quit
[CSG1] quit
Repeat this step for CSG2. For configuration details, see Configuration Files in this
section.
# Configure AGG1.
[AGG1] mpls l2vpn
[AGG1-l2vpn] quit
[AGG1] vsi 1 static
[AGG1-vsi-1] pwsignal ldp

[AGG1-vsi-1-ldp] vsi-id 100

[AGG1-vsi-1-ldp] peer 1.1.1.1 upe
[AGG1-vsi-1-ldp] peer 2.2.2.2 negotiation-vc-id 8000
[AGG1-vsi-1-ldp] peer 3.3.3.3 negotiation-vc-id 8000
[AGG1-vsi-1-ldp] quit
[AGG1-vsi-1] quit
# After completing the preceding configurations, run the display mpls l2vc brief command on
a CSG or AGG. The command output shows that VC state is up.
The following example uses the command output on CSG1.
<CSG1> display mpls l2vc brief
Total LDP VC : 2 2 up 0 down
*Client Interface : GigabitEthernet3/0/0.10

AC status : up
VC State : up
Label state : 0
Token state : 0
VC ID : 100
VC Type : VLAN
session state : up
Destination : 2.2.2.2
link state : up
*Client Interface : GigabitEthernet3/0/0.10

AC status : up
VC State : up
Label state : 0
Token state : 0
VC ID : 200
VC Type : VLAN
session state : up
Destination : 3.3.3.3
link state : up
Run the display vsi name command on an AGG. The command output shows that the VSI
named 1 status is up.
The following example uses the command output on AGG1.
<AGG1> display vsi name 1
Vsi Mem PW Mac Encap Mtu Vsi
Name Disc Type Learn Type Value State
--------------------------------------------------------------------------
1 static ldp unqualify vlan 1500 up
Assign IP address to NodeBs and run the ping command to check the connectivity of the link
between the NodeBs.
<NodeB1> ping 100.1.1.2
PING 100.1.1.2: 56 data bytes, press CTRL_C to break
--- 100.1.1.2 ping statistics ---

0.00% packet loss
----End
Configuration Files
l CSG1 configuration file
#
sysname CSG1
#
mpls lsr-id 1.1.1.1
mpls
#
mpls l2vpn
#
mpls ldp
#
mpls ldp remote-peer 2.2.2.2
remote-ip 2.2.2.2
#
remote-ip 3.3.3.3
#
undo shutdown
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
#
interface GigabitEthernet3/0/0.10
vlan-type dot1q 10
mpls l2vc 2.2.2.2 100
mpls l2vc 3.3.3.3 200 secondary
mpls l2vpn redundancy master
#
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 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return
l AGG1 configuration file

#
sysname AGG1
#
mpls lsr-id 2.2.2.2
mpls
#
mpls l2vpn

#
vsi 1 static
pwsignal ldp
vsi-id 100
peer 8.8.8.8 negotiation-vc-id 8000
peer 1.1.1.1 upe
#
mpls ldp
#
remote-ip 1.1.1.1
#
remote-ip 8.8.8.8
#
remote-ip 9.9.9.9
#
isis 1
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 172.3.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
network 2.2.2.2 255.255.255.255
peer 4.4.4.4 enable
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.3.1.0 0.0.0.255

#
apply mpls-label
#
return

#
sysname AGG2
#
mpls lsr-id 3.3.3.3
mpls
#
mpls l2vpn
#
vsi 1 static
pwsignal ldp
vsi-id 200
peer 1.1.1.1 upe
#
mpls ldp
#
remote-ip 1.1.1.1
#
#
remote-ip 9.9.9.9
#
isis 1
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 172.3.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast

network 3.3.3.3 255.255.255.255

peer 4.4.4.4 enable
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 172.2.1.0 0.0.0.255
network 172.3.1.0 0.0.0.255
#
apply mpls-label
#
return
l Core ABR1 configuration file

#
sysname Core ABR1
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast

peer 2.2.2.2 enable

peer 3.3.3.3 enable
peer 6.6.6.6 enable
peer 7.7.7.7 enable
#
ospf 3
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.3.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
if-match mpls-label
apply mpls-label
#
return

#
sysname Core ABR2
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0004.00
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
undo shutdown
ip address 20.2.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255

isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 6.6.6.6 enable
peer 7.7.7.7 enable
#
ospf 3
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 10.3.1.0 0.0.0.255
network 20.2.1.0 0.0.0.255
#
if-match mpls-label
apply mpls-label
#
return

#
sysname Core ABR3
#
mpls lsr-id 6.6.6.6
mpls
#
mpls ldp
#
isis 2
network-entity 10.0000.0000.0005.00
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown

ip address 30.1.1.1 255.255.255.0

isis enable 2
mpls
mpls ldp
#
undo shutdown
ip address 30.3.1.1 255.255.255.0
isis enable 2
mpls
mpls ldp
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
isis enable 2
#
bgp 100
#
ipv4-family unicast
peer 4.4.4.4 enable
peer 5.5.5.5 enable
peer 8.8.8.8 enable
peer 9.9.9.9 enable
#
ospf 3
area 0.0.0.0
network 6.6.6.6 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.3.1.0 0.0.0.255
#
if-match mpls-label
apply mpls-label
#
return

#
sysname Core ABR4
#
mpls lsr-id 7.7.7.7
mpls

#
mpls ldp
#
isis 2
network-entity 10.0000.0000.0007.00
#
undo shutdown
ip address 20.2.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 30.2.1.1 255.255.255.0
isis enable 2
mpls
mpls ldp
#
undo shutdown
ip address 30.3.1.2 255.255.255.0
isis enable 2
mpls
mpls ldp
#
interface LoopBack1
ip address 7.7.7.7 255.255.255.255
isis enable 2
#
bgp 100
#
ipv4-family unicast
peer 4.4.4.4 enable
peer 5.5.5.5 enable
peer 8.8.8.8 enable
peer 9.9.9.9 enable
#
ospf 3
area 0.0.0.0
network 7.7.7.7 0.0.0.0
network 20.2.1.0 0.0.0.255

network 30.3.1.0 0.0.0.255

#
if-match mpls-label
apply mpls-label
#
return

#
sysname AGG3
#
mpls lsr-id 8.8.8.8
mpls
#
mpls l2vpn
#
vsi 1 static
pwsignal ldp
vsi-id 100
peer 10.10.10.10 upe
#
mpls ldp
#
remote-ip 10.10.10.10
#
remote-ip 2.2.2.2
#
remote-ip 3.3.3.3
#
isis 2
network-entity 10.0000.0000.0008.00
#
undo shutdown
ip address 30.1.1.2 255.255.255.0
isis enable 2
mpls
mpls ldp
#
undo shutdown
ip address 192.1.1.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.3.1.1 255.255.255.0
isis enable 2
mpls
mpls ldp
#
interface LoopBack1
ip address 8.8.8.8 255.255.255.255
isis enable 2
#
bgp 100

#
ipv4-family unicast
network 8.0.0.0
network 8.8.8.8 255.255.255.255
peer 6.6.6.6 enable
peer 7.7.7.7 enable
#
ospf 2
area 0.0.0.0
network 8.8.8.8 0.0.0.0
network 192.1.1.0 0.0.0.255
network 192.3.1.0 0.0.0.255
#
apply mpls-label
#
return

#
sysname AGG4
#
mpls lsr-id 9.9.9.9
mpls
#
mpls l2vpn
#
vsi 1 static
pwsignal ldp
vsi-id 200
peer 10.10.10.10 upe
#
mpls ldp
#
remote-ip 10.10.10.10
#
remote-ip 2.2.2.2
#
remote-ip 3.3.3.3
#
isis 2
network-entity 10.0000.0000.0009.00
#
undo shutdown
ip address 30.2.1.2 255.255.255.0
isis enable 2
mpls
mpls ldp
#
undo shutdown
ip address 192.2.1.2 255.255.255.0
mpls
mpls ldp
#

undo shutdown
ip address 192.3.1.2 255.255.255.0
isis enable 2
mpls
mpls ldp
#
interface LoopBack1
ip address 9.9.9.9 255.255.255.255
isis enable 2
#
bgp 100
#
ipv4-family unicast
network 9.9.9.9 255.255.255.255
peer 6.6.6.6 enable
peer 7.7.7.7 enable
#
ospf 2
area 0.0.0.0
network 9.9.9.9 0.0.0.0
network 192.2.1.0 0.0.0.255
network 192.3.1.0 0.0.0.255
#
apply mpls-label
#
return
l CSG2 configuration file

#
sysname CSG2
#
mpls lsr-id 10.10.10.10
mpls
#
mpls l2vpn
#
mpls ldp
#
remote-ip 8.8.8.8
#
remote-ip 9.9.9.9
#
undo shutdown
ip address 192.1.1.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 192.2.1.1 255.255.255.0
mpls
mpls ldp
#

undo shutdown
#
interface GigabitEthernet3/0/0.10
vlan-type dot1q 10
mpls l2vc 8.8.8.8 100
mpls l2vc 9.9.9.9 200 secondary
mpls l2vpn redundancy master
#
interface LoopBack1
ip address 10.10.10.10 255.255.255.255
#
ospf 2
area 0.0.0.0
network 10.10.10.10 0.0.0.0
network 192.1.1.0 0.0.0.255
network 192.2.1.0 0.0.0.255
#
return

Configuration Guide - MPLS A Glossary
A Glossary
This appendix collates frequently used glossaries.
administrative group A 32-bit vector representing a set of link attributes. In RFC 3209,
administrative groups are called link-attributes.
bandwidth protection Bandwidth protection indicates that the bypass tunnel reserves
sufficient bandwidth to protect the traffic of the protected tunnel.
best-effort path When both primary and backup CR-LSPs fail, a temporary CR-
LSP, also called a best-effort path, is set up to protect the traffic.
bidirectional forwarding A rapid fault detection mechanism used to detect faults in

detection milliseconds. It can be used in the case that there is no hardware
detection mechanism, to shorten the fault period.
bypass tunnel A label switched path that protects an LSP.
constraint-based routed Established based on some constraints.

label switched path
dynamic bidirectional Local and remote discriminators are allocated automatically by

forwarding Detection the system. Bidirectional forwarding detection sessions are set up
dynamically.
dynamic label switched A label switched path set up by a signaling protocol automatically.
path

explicit path A constraint-based routed label switched path that can be

established over the specified path. This specified path is called
an explicit path, which is classified as the strict and loose explicit
paths.
egress The end node of a label switched path.
facility backup Protects one or more label switched paths using one bypass
tunnel.
flooding threshold Ratio of the changed bandwidth to the reservable bandwidth of

the link on which no flooding occurs. A flooding threshold is set
to avoid consuming excessive resources due to flooding triggered
by link bandwidth changes.
FTN Mpping between a FEC and a set of NHLFEs.
Graceful Restart In IETF,Internet Protocol/Multiprotocol Label Switching (IP/

MPLS) related protocols, such as Open Shortest Path First
(OSPF), Intermediate System-Intermediate System (IS-IS),
Border Gateway Protocol (BGP), Label Distribution Protocol
(LDP), and Resource Reservation Protocol (RSVP), are extended
to ensure that forwarding is not interrupted when the system is
restarted. GR reduces the flapping of the protocols on the control
plane when the system performs an active/standby switchover.
This series of standards is called Graceful Restart.
Graceful Restart restarter A node enabled Graceful Restart. The GR Restarter has dual main
control boards and is capable of notifying the neighbor to
maintain the adjacency during an active/standby switchover.
Graceful Restart helper Neighbor of the Graceful Restart Restarter. The GR Helper should
be able to identify the GR signaling, maintain the adjacency with
the GR Restarter during an active/standby switchover, and help
the GR Restarter restore the network topology.
hot standby A backup CR-LSP established when the primary CR-LSP is

established.

Incoming Label Map Mapping between an incoming label and a set of NHLFEs.
ingress The beginning of a label switched path. The ingress pushes a label
to a packet, encapsulates the packet as an MPLS packet, and
forward it.
label A short identifier of a fixed length with only local significance.

It is used to uniquely identify a FEC to which a packet belongs.
label distribution Packets with the same destination address belong to a FEC. A
label out of an MPLS label resource pool is allocated to the FEC.
LSRs record the relationship of the label and the FEC. Then, LSRs
send a message and advertises to upstream LSRs about the label
and FEC relationship.
label edge router An LSR that resides on the edge of an MPLS domain. When an
LSR connects to one node that runs MPLS, the LSR acts as the
LSR.
label space Value range of the label allocated to peers.
label switched path A path through which a FEC passes on an MPLS network.
label switching router routers that can swap and forward MPLS labels. An LSR is also
called an MPLS node.
LDP identifier Value used to identify a specified LSR label space.
LDP peer Two LSRs that use LDP to exchange labels or FEC mappings.
LDP sessions exist between them.
link color An administrative group property of the link that is used to select
a link. A link can support up to 32 colors. When specifying a CR-
LSP, you can add constraints to the color field to require that the
passed path be of a specified color.
link protection Link protection indicates that there is a direct link between the
PLR and the MP.
loose explicit path An explicit path in which the LSRs on the LSP are specified.
Other routers can exist between an LSR and the last hop.
LSP tunnel Label switched path tunnel. A configured connection between

two nodes that uses MPLS to carry the packets. For an LSP, if a
label is allocated to the packet, the traffic forwarding is
determined by the label. The traffic is transparent to the transit.
In this sense, an LSP is considered as an LSP tunnel.

make-before-break A mechanism that changes the MPLS TE to update the CR-LSP.

That is, a new CR-LSP is established before the original one is
removed. It can ensure that the service flow on the CR-LSP is not
broken during updating.
merge point Egress of the bypass tunnel.
NHLFE Next hop label forwarding entry (NHLFE) is used to guide the
MPLS packet forwarding. An NHLFE contains information about
the tunnel ID, outgoing interface, next hop, outgoing label, and
label operation.
node protection Node protection indicates that there is an LSR between the PLR
and the MP and the protected LSP passes through this LSR.
N:1 protection mode In N:1 protection mode, a tunnel serves as a protection tunnel for
several primary tunnels. When one of the primary tunnels fails,
its traffic is switched to the shared protection tunnel.
ordinary backup Established by an ingress only after the primary LSP fails.
Point of Local Repair Ingress node of a bypass tunnel.
preemption A processing mode in which a new CR-LSP occupies the

bandwidth of an existing path. If no path meets the bandwidth
requirement of a CR-LSP, you can remove an established path to
reclaim bandwidth and uses the reclaimed bandwidth to establish
the new CR-LSP.
protected label switched An label switched path that is protected.

path
protection switching Flow switching or copy between the primary tunnel and the
backup tunnel in MPLS OAM.
re-optimization Dynamic optimization of CR-LSPs, namely, the periodic

calculation of CR-LSP routes. If the recalculated route is better
than the current route, a new CR-LSP is created. Traffic switches
from the original CR-LSP to the new CR-LSP, and then the
original CR-LSP is deleted.

Route pinning An attribute of the link. When the network topology changes, the
established CR-LSP does not vary with the change of routes. This
attribute is used to ensure that the traffic is not broken and improve
the security.
RSVP The Resource Reservation Protocol (RSVP) is designed for

Integrated Service and is used to reserve resources on every node
along a path. RSVP operates on the transport layer; however,
RSVP does not transport application data. RSVP is a network
control protocol like Internet Control Message Protocol (ICMP).
RSVP-TE To set up CR-LSPs, RSVP is extended. The extended RSVP is

called RSVP Traffic Engineering (RSVP-TE).
Soft State RSVP sends its messages as IP datagrams with no reliability

enhancement. RSVP nodes periodically send RSVP Refresh
messages to synchronize statuses of RSVP neighboring nodes
(including PSB and RSB) and restore the lost RSVP messages.
This is called RSVP soft state mechanism.
static bidirectional Local and remote discriminators are configured manually and
forwarding detection bidirectional forwarding detection (BFD) sessions are set up
through the BFD negotiation mechanism.
static label switched path Established using manually assigned labels.
strict explicit path An explicit path in which the last hop and the next hop are directly
connected. It can precisely specify the LSRs on the LSP.
Summary Refresh The summary refresh enables the refreshing of RSVP state
without the transmission of standard Path or Resv messages. The
benefits of the summary refresh are that it reduces the amount of
information that must be transmitted.
TE FRR TE fast reroute (FRR) is a local protection mechanism to protect

Traffic Engineering LSPs from link or node failure. In TE FRR,
bypass tunnels that detour the failed link or node are pre-
established to protect the primary LSP. When the LSP or the node
fails, traffic is transmitted through the bypass tunnel, and the
ingress node can simultaneously initiate the setup of the primary
LSP without interrupting data transmission.
tie-breaking During the CSPF path computation, if there are several paths with
the same metric, CSPF selects one of them. This process is called
tie-breaking.
traffic trunk A collection of traffic that belongs to the same service type and
uses the same LSP.

tunnel interface A point-to-point virtual interface for encapsulating data over

tunnel.

Configuration Guide - MPLS B Acronyms and Abbreviations
B Acronyms and Abbreviations
This appendix collates frequently used acronyms and abbreviations in this document.
AF assured forwarding
AS autonomous system
ASIC application specific integrated circuit
ATM asynchronous transfer mode
BC bandwidth constraint
BDI backward defect indication
BFD bidirectional forwarding detection
BGP Border Gateway Protocol
CE customer edge
CLNP Connectionless Network Protocol
CMD Core Management Device
CR Constraint-based Routing
CSPF Constraint Shortest Path First
CT class type
CV Connectivity Verification

DoD Downstream-on-Demand
DU Downstream Unsolicited
EF expedited forwarding
ER explicit route
ERO explicit route object
FDI Forward Defect Indication
FEC forwarding equivalence class
FF fixed-filter
FFD fast failure detection
FIB Forward Information Base
FR Frame Relay
FRR fast reroute
FS forced switch
FTN FEC to NHLFE
GR Graceful Restart
GRE Generic Routing Encapsulation
HA high availability
HoVPN Hierarchy of VPN
ICMP Internet Control Message Protocol
IGP Interior Gateway Protocol
ILM Incoming Label Map

IPTN IP Telecommunication Network
IPX Internet Packet Exchange
IS-IS Intermediate System to Intermediate System
L2TP Layer 2 Tunneling Protocol
LAM Label Advertisement Mode
LDP Label Distribution Protocol
LER label edge router
LFIB label forward information base
LOM Local Overbooking Multipliers
LoP Lockout of Protection
LSA link state advertisement
LSP label switched path
LSR label switching router
MA management area
MAM Maximum Allocation Model
MD5 message digest 5
MP merge point
MPLS Multiprotocol Label Switching
MS manual switch
MTU maximum transmission unit
NHLFE next hop label forwarding entry
OAM operation, administration and maintenance
OSPF Open Shortest Path First

PDU Protocol Data Unit
PE provider edge
PHP penultimate hop popping
PLR Point of Local Repair
PSB path state block
QoS quality of service
RDM Russian Dolls Model
RLSN remote link status notification
RM resource management
RRO record route object
RSB reservation state block
RSVP Resource Reservation Protocol
RSVP-TE Resource Reservation Protocol-Traffic Engineering
SDH synchronous digital hierarchy
SE shared-explicit
SF signal fail
SLA Service Level Agreement
SPF Shortest Path First
SPE Superstratum PE: Service provider-end PE
TCP Transmission Control Protocol
TE traffic engineering
TEDB traffic engineering database

TLV type-length-value
ToS type of service
TTL time to live
TTSI Trail Termination Source Identifier
VCI virtual channel identifier
VLL virtual leased line
VPI virtual path identifier
VPN virtual private network
WTR wait to restore


NE40E&80E V600R008C10 Configuration Guide - MPLS 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

NE40E&80E V600R008C10 Configuration Guide - MPLS 01 PDF

Uploaded by

Copyright:

Available Formats

HUAWEI NetEngine80E/40E Router

Configuration Guide - MPLS

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2014-09-30) Huawei Proprietary and Confidential i

About This Document

Product Name Version

HUAWEI NetEngine80E/40E V600R008C10

Issue 02 (2014-09-30) Huawei Proprietary and Confidential ii

l Data configuration engineers

Indicates an imminently hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Calls attention to important information, best practices and

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

Issue 02 (2014-09-30) Huawei Proprietary and Confidential iii

[ 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 02 (2014-09-30)

Changes in Issue 01 (2014-06-30)

Issue 02 (2014-09-30) Huawei Proprietary and Confidential iv

About This Document.....................................................................................................................ii

2 MPLS LDP Configuration..........................................................................................................29

Issue 02 (2014-09-30) Huawei Proprietary and Confidential v

2.2.3 (Optional) Configuring the Dynamic LDP Advertisement Capability......................................................................37

Issue 02 (2014-09-30) Huawei Proprietary and Confidential vi

2.8.4 (Optional) Disabling mLDP P2MP on an Interface..................................................................................................80

Issue 02 (2014-09-30) Huawei Proprietary and Confidential vii

2.15.2 Enabling Synchronization Between LDP and IGP................................................................................................112

Issue 02 (2014-09-30) Huawei Proprietary and Confidential viii

2.20.12 Example for Configuring LDP Authentication...................................................................................................208

Issue 02 (2014-09-30) Huawei Proprietary and Confidential ix

3.6 Configuring Dynamic Bandwidth Reservation..........................................................................................................303

Issue 02 (2014-09-30) Huawei Proprietary and Confidential x

3.12.5 Configuring Metrics for Path Calculation.............................................................................................................340

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xi

3.18.7 Configuring the Static CR-LSP and the Bandwidth..............................................................................................374

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xii

3.24.1 Before You Start....................................................................................................................................................412

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xiii

3.29.10 Configuring Alarm Thresholds for Total CR-LSPs............................................................................................448

4 MPLS Common Configuration...............................................................................................753

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xiv

4.1.2 MPLS Common Features Supported by the NE80E/40E........................................................................................755

5 MPLS OAM Configuration.....................................................................................................796

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xv

5.2.3 Configuring MPLS OAM on the Egress.................................................................................................................804

6 Seamless MPLS Configuration...............................................................................................851

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xvi

6.3.7 Checking the Configurations...................................................................................................................................875

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xvii

1 Static LSPs Configuration

About This Chapter

1.2 Configuring Static LSPs

1.3 Configuring Static BFD for Static LSP

1.4 Maintaining Static LSPs