AR150&200&1200&2200&3200 V200R003C01 Configuration Guide-IP Routing 04 PDF

Huawei AR150&200&1200&2200&3200 Series
Enterprise Routers
V200R003C01
Configuration Guide - IP Routing
Issue 04
Date 2014-01-16
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://enterprise.huawei.com
Issue 04 (2014-01-16) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Huawei AR150&200&1200&2200&3200 Series Enterprise
Routers
Configuration Guide - IP Routing About This Document
About This Document
Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples for different application scenarios of the AR150&200&1200&2200&3200, Topics
covered include static routes, routing protocols (RIP, BGP,OSPF, and IS-IS), and routing
policies.
This document is intended for:
l Data configuration engineers

l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates 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.

which, if not avoided, may result in minor or
moderate injury.

which, if not avoided, could result in
equipment damage, data loss, performance
deterioration, or unanticipated results.
NOTICE is used to address practices not
related to personal injury.
Issue 04 (2014-01-16) Huawei Proprietary and Confidential ii

Routers
Symbol Description
NOTE 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.
[ 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.
Interface Numbering Conventions

Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Issue 04 (2014-01-16) Huawei Proprietary and Confidential iii

Routers
Changes in Issue 04 (2014-01-16)

This version has the following updates:
The following information is modified:

l 2 Static Route Configuration


l 5.6.5 Configuring OSPF NSSA Areas


l 11.2.1 Example for Configuring IP FRR on the Public Network

Initial commercial release.
Issue 04 (2014-01-16) Huawei Proprietary and Confidential iv

Routers
Configuration Guide - IP Routing Contents
Contents
About This Document.....................................................................................................................ii

1 IP Routing Overview....................................................................................................................1
1.1 Introduction to IP Routing..............................................................................................................................................2
1.2 Principles........................................................................................................................................................................2
1.2.1 Routers and Routing Principles...................................................................................................................................2
1.2.2 Static Routes and Dynamic Routes.............................................................................................................................3
1.2.3 Routing Table and FIB Table......................................................................................................................................3
1.2.4 Routing Protocol Preference........................................................................................................................................7
1.2.5 Route Metric................................................................................................................................................................8
1.2.6 Load Balancing and Route Backup.............................................................................................................................9
1.2.7 IP FRR.......................................................................................................................................................................10
1.2.8 Route Convergence....................................................................................................................................................11
1.2.9 Default Routes...........................................................................................................................................................13
1.2.10 Route Import............................................................................................................................................................13
1.2.11 Autonomous System................................................................................................................................................13
1.2.12 Indirect Next Hop....................................................................................................................................................14
1.3 References....................................................................................................................................................................16
2 Static Route Configuration........................................................................................................17

2.1 Introduction to Static Routes........................................................................................................................................18
2.2 Principles......................................................................................................................................................................18
2.2.1 Basics of Static Routes..............................................................................................................................................18
2.2.2 BFD for Static Routes................................................................................................................................................19
2.2.3 NQA for Static Routes...............................................................................................................................................19
2.2.4 Permanent Advertisement of Static Routes...............................................................................................................21
2.3 Applications..................................................................................................................................................................23
2.3.1 Load Balancing and Route Backup...........................................................................................................................23
2.3.2 Application of the Static Default Route....................................................................................................................24
2.4 Configuration Task Summary......................................................................................................................................25
2.5 Default Configuration of Static Routes........................................................................................................................27
2.6 Configuring Static Routes............................................................................................................................................27
2.6.1 Configuring IPv4 Static Routes.................................................................................................................................28
2.6.1.1 Creating IPv4 Static Routes....................................................................................................................................28
Issue 04 (2014-01-16) Huawei Proprietary and Confidential v

Routers
2.6.1.2 (Optional) Setting the Default Preference for IPv4 Static Routes..........................................................................29
2.6.1.3 (Optional) Configuring Static Route Selection Based on Iteration Depth.............................................................29
2.6.1.4 (Optional) Configuring Permanent Advertisement of IPv4 Static Routes.............................................................30
2.6.1.5 Checking the Configuration....................................................................................................................................31
2.6.2 Configuring Static BFD for IPv4 Static Routes........................................................................................................31
2.6.3 Associating IPv4 Static Routes with NQA................................................................................................................32
2.6.4 Configuring IPv6 Static Routes.................................................................................................................................34
2.6.4.1 Creating IPv6 Static Routes....................................................................................................................................34
2.6.4.2 (Optional) Setting the Default Preference for IPv6 Static Routes..........................................................................35
2.7 Configuration Examples...............................................................................................................................................36
2.7.1 Example for Configuring IPv4 Static Routes............................................................................................................36
2.7.2 Example for Configuring IPv6 Static Routes............................................................................................................39
2.7.3 Example for Configuring BFD for IPv4 Static Routes..............................................................................................42
2.7.4 Example for Configuring NQA for IPv4 Static Routes.............................................................................................45
2.8 FAQ..............................................................................................................................................................................49
2.8.1 Is the Static Route Affected If the BFD for the Static Route is in AdminDown State?............................................49
2.9 References....................................................................................................................................................................49
3 RIP Configuration.......................................................................................................................50
3.1 Introduction to RIP.......................................................................................................................................................51
3.2 Principles......................................................................................................................................................................51
3.2.1 Principles...................................................................................................................................................................51
3.2.2 RIP-2 Enhanced Features..........................................................................................................................................53
3.2.3 Split Horizon and Poison Reverse.............................................................................................................................55
3.2.4 Multi-process and Multi-instance..............................................................................................................................56
3.2.5 BFD for RIP...............................................................................................................................................................57
3.3 Configuration Task Summary......................................................................................................................................58
3.4 Default Configuration...................................................................................................................................................61
3.5 Configuring RIP...........................................................................................................................................................62
3.5.1 Configuring Basic RIP Functions..............................................................................................................................62
3.5.1.1 Enabling RIP...........................................................................................................................................................62
3.5.1.2 Enabling RIP on the Specified Network Segment..................................................................................................63
3.5.1.3 (Optional) Configuring RIP Neighbors on an NBMA Network............................................................................63
3.5.1.4 (Optional) Specifying the RIP Version..................................................................................................................64
3.5.2 Configuring RIP-2.....................................................................................................................................................65
3.5.2.1 Configuring RIP-2 Route Summarization..............................................................................................................65
3.5.2.2 Configuring RIP-2 Packet Authentication..............................................................................................................66
3.5.3 Avoiding Routing Loops...........................................................................................................................................67
3.5.3.1 Configuring Split Horizon......................................................................................................................................67
Issue 04 (2014-01-16) Huawei Proprietary and Confidential vi

Routers
3.5.3.2 Configuring Poison Reverse...................................................................................................................................68

3.5.4 Controlling RIP Routing............................................................................................................................................69
3.5.4.1 Configuring RIP Preference...................................................................................................................................69
3.5.4.2 Configuring Additional Metrics of an Interface.....................................................................................................69
3.5.4.3 Setting the Maximum Number of Equal-Cost Routes............................................................................................70
3.5.5 Controlling RIP Route Advertisement......................................................................................................................71
3.5.5.1 Configuring RIP to Advertise Default Routes........................................................................................................71
3.5.5.2 Disabling an Interface from Sending Update Packets............................................................................................72
3.5.5.3 Configuring RIP to Import Routes.........................................................................................................................73
3.5.6 Controlling Receiving of RIP Routing Information..................................................................................................74
3.5.6.1 Disabling an Interface from Receiving RIP Update Packets..................................................................................74
3.5.6.2 Configuring RIP to Deny Host Routes...................................................................................................................75
3.5.6.3 Configuring RIP to Filter Received Routes............................................................................................................76
3.5.7 Improving RIP Network Performance.......................................................................................................................77
3.5.7.1 Configuring RIP Timers.........................................................................................................................................77
3.5.7.2 Setting the Interval for Sending Update Packets and Maximum Number of Sent Packets....................................78
3.5.7.3 Enabling replay-protect Function...........................................................................................................................78
3.5.7.4 Configuring RIP to Check the Validity of Update Packets....................................................................................79
3.5.8 Configuring BFD for RIP..........................................................................................................................................81
3.5.8.1 Configuring Dynamic BFD for RIP.......................................................................................................................81
3.5.8.2 Configuring Static BFD for RIP.............................................................................................................................83
3.5.9 Configuring the Network Management Function for RIP.........................................................................................85
3.6 Maintaining RIP...........................................................................................................................................................86
3.6.1 Resetting RIP.............................................................................................................................................................86
3.6.2 Clearing RIP Statistics...............................................................................................................................................86
3.7 Configuration Examples...............................................................................................................................................87
3.7.1 Example for Configuring Basic RIP Functions.........................................................................................................87
3.7.2 Example for Importing Routes to RIP.......................................................................................................................90
3.7.3 Example for Configuring One-Arm Static BFD for RIP...........................................................................................94
3.7.4 Example for Configuring Dynamic BFD for RIP.....................................................................................................98
3.8 Common Configuration Errors...................................................................................................................................102
3.8.1 Failed to Receive RIP Update Packets from Neighbors..........................................................................................103
3.8.2 Failed to Send RIP Update Packets to Neighbors...................................................................................................103
3.8.3 Route Flapping Occurs on a RIP Network..............................................................................................................104
3.9 References..................................................................................................................................................................104
4 RIPng Configuration.................................................................................................................105
Issue 04 (2014-01-16) Huawei Proprietary and Confidential vii

Routers
4.1 Introduction to RIPng.................................................................................................................................................106

4.2 Principles....................................................................................................................................................................106
4.2.1 RIPng.......................................................................................................................................................................106
4.3 Configuration Task Summary....................................................................................................................................106
4.4 Default Configuration.................................................................................................................................................108
4.5 Configuring RIPng.....................................................................................................................................................109
4.5.1 Configuring Basic RIPng Functions........................................................................................................................109
4.5.1.1 Enabling RIPng.....................................................................................................................................................109
4.5.1.2 Enabling RIPng on Interfaces...............................................................................................................................110
4.5.1.3 Checking the Configuration..................................................................................................................................110
4.5.2 Avoiding Routing Loops.........................................................................................................................................110
4.5.2.1 Configuring Split Horizon....................................................................................................................................111
4.5.2.2 Configuring Poison Reverse.................................................................................................................................111
4.5.3 Controlling RIPng Routing......................................................................................................................................112
4.5.3.1 Configuring RIPng Preference.............................................................................................................................112
4.5.3.2 Configuring Additional Metrics of an Interface...................................................................................................113
4.5.3.3 Setting the Maximum Number of Equal-Cost Routes..........................................................................................114
4.5.4 Controlling RIPng Route Advertisement................................................................................................................114
4.5.4.1 Configuring RIPng Route Summarization...........................................................................................................115
4.5.4.2 Advertising a Default Route.................................................................................................................................115
4.5.4.3 Configuring a RIPng Process to Import External Routes.....................................................................................116
4.5.5 Controlling the Receiving of RIPng Routes............................................................................................................117
4.5.6 Improving RIPng Network Performance.................................................................................................................118
4.5.6.1 Configuring RIPng Timers...................................................................................................................................118
4.5.6.2 Setting the Interval for Sending Update Packets and Maximum Number of Sent Packets..................................119
4.5.6.3 Enabling Zero Field Check for RIPng Packets.....................................................................................................120
4.6 Maintaining RIPng.....................................................................................................................................................120
4.6.1 Clearing RIPng........................................................................................................................................................121
4.7 Configuration Examples.............................................................................................................................................121
4.7.1 Example for Configuring Basic RIPng Functions...................................................................................................121
4.8 References..................................................................................................................................................................124
5 OSPF Configuration..................................................................................................................125
5.1 Introduction to OSPF..................................................................................................................................................126
5.2 Principle......................................................................................................................................................................126
5.2.1 Fundamentals of OSPF............................................................................................................................................126
5.2.2 OSPF TE..................................................................................................................................................................137
5.2.3 BFD for OSPF.........................................................................................................................................................139
Issue 04 (2014-01-16) Huawei Proprietary and Confidential viii

Routers
5.2.4 OSPF GTSM............................................................................................................................................................140

5.2.5 OSPF Smart-discover..............................................................................................................................................141
5.2.6 OSPF VPN...............................................................................................................................................................142
5.2.7 OSPF NSSA............................................................................................................................................................149
5.2.8 OSPF Fast Convergence..........................................................................................................................................150
5.2.9 Priority-based OSPF Convergence..........................................................................................................................151
5.2.10 OSPF IP FRR.........................................................................................................................................................151
5.2.11 OSPF-BGP Association.........................................................................................................................................153
5.2.12 OSPF GR...............................................................................................................................................................154
5.2.13 OSPF-LDP Association.........................................................................................................................................158
5.2.14 OSPF Database Overflow......................................................................................................................................159
5.2.15 OSPF Mesh-Group................................................................................................................................................160
5.3 OSPF Applications.....................................................................................................................................................162
5.3.1 OSPF GR.................................................................................................................................................................162
5.3.2 OSPF GTSM............................................................................................................................................................163
5.6 Configuring OSPF......................................................................................................................................................167
5.6.1 Configuring Basic OSPF Functions........................................................................................................................168
5.6.1.1 Creating an OSPF Process....................................................................................................................................168
5.6.1.2 Creating an OSPF Area........................................................................................................................................169
5.6.1.3 Enable OSPF.........................................................................................................................................................170
5.6.1.4 (Optional) Creating OSPF Virtual Links..............................................................................................................171
5.6.1.5 (Optional) Restricting the Flooding of LSA Update Packets...............................................................................172
5.6.2 Setting Parameters for OSPF Neighbor Relationship..............................................................................................173
5.6.2.1 Setting the OSPF Packet Retransmission Limit...................................................................................................173
5.6.2.2 Configuring an Interface to Fill in the DD Packet with the Actual MTU............................................................174
5.6.3 Configuring OSPF Attributes in Different Types of Networks...............................................................................175
5.6.3.1 Configuring Network Types of OSPF Interfaces.................................................................................................177
5.6.3.2 Configuring P2MP Network Attributes................................................................................................................178
5.6.3.3 Configuring NBMA Network Attributes..............................................................................................................179
5.6.4 Configuring OSPF Stub Areas................................................................................................................................180
5.6.4.1 Defining the Current Area to be a Stub Area.......................................................................................................181
5.6.4.2 (Optional) Configuring Metrics of Default Routes Sent to Stub Areas...............................................................182
5.6.5 Configuring OSPF NSSA Areas..............................................................................................................................183
5.6.6 Adjusting OSPF Route Selection............................................................................................................................186
5.6.6.1 Setting the Link Cost for an OSPF Interface........................................................................................................186
Issue 04 (2014-01-16) Huawei Proprietary and Confidential ix

Routers
5.6.6.2 Configuring Equal-Cost Routes............................................................................................................................187

5.6.6.3 Configuring External Route Selection Rules .......................................................................................................188
5.6.6.4 Suppressing an Interface from Receiving and Sending OSPF Packets................................................................189
5.6.7 Controlling OSPF Routing Information..................................................................................................................190
5.6.7.1 Configuring OSPF to Import External Routes.....................................................................................................190
5.6.7.2 Configuring OSPF to Advertise the Default Route to the OSPF Area.................................................................191
5.6.7.3 Configuring OSPF Route Aggregation.................................................................................................................193
5.6.7.4 Configuring OSPF to Filter the Received Routes................................................................................................194
5.6.7.5 Configuring OSPF to Filter the Routes to Be Advertised....................................................................................195
5.6.7.6 Configuring the router to Filter LSAs to Be Sent.................................................................................................195
5.6.7.7 Configuring OSPF to Filter ABR Type3 LSA.....................................................................................................196
5.6.7.8 (Optional) Enabling the Mesh-Group Function....................................................................................................197
5.6.7.9 Setting the Maximum Number of External LSAs in the LSDB...........................................................................197
5.6.7.10 Checking the Configuration................................................................................................................................198
5.6.8 Configuring OSPF IP FRR......................................................................................................................................198
5.6.8.1 Enabling OSPF IP FRR........................................................................................................................................199
5.6.8.2 Binding IP FRR and BFD.....................................................................................................................................200
5.6.8.3 (Optional) Blocking FRR on an OSPF Interface..................................................................................................201
5.6.9 Configuring BFD for OSPF.....................................................................................................................................202
5.6.9.1 Configuring Global BFD......................................................................................................................................203
5.6.9.2 Configuring BFD for OSPF Feature.....................................................................................................................203
5.6.9.3 (Optional) Preventing an Interface from Dynamically Setting Up a BFD Session..............................................205
5.6.9.4 (Optional) Configuring BFD on the Specified Interface......................................................................................205
5.6.10 Configuring OSPF Fast Convergence...................................................................................................................207
5.6.10.1 Setting the Convergence Priority of OSPF Routes.............................................................................................207
5.6.10.2 Setting the Interval for Sending Hello Packets...................................................................................................208
5.6.10.3 Setting the Dead Time of the Neighbor Relationship.........................................................................................208
5.6.10.4 Configuring Smart-discover...............................................................................................................................209
5.6.10.5 Setting the Interval for Updating LSAs..............................................................................................................210
5.6.10.6 Setting the Interval for Receiving LSAs.............................................................................................................211
5.6.10.7 Setting the Interval for the SPF Calculation.......................................................................................................212
5.6.11 Configuring OSPF GR Helper...............................................................................................................................213
5.6.12 Improving the Stability of an OSPF Network.......................................................................................................214
5.6.12.1 Setting the Priority of OSPF...............................................................................................................................215
5.6.12.2 Configuring the Delay for Transmitting LSAs on the Interface.........................................................................216
5.6.12.3 Configuring the Interval for Retransmitting LSAs.............................................................................................216
5.6.12.4 Configuring Stub Routers...................................................................................................................................217
Issue 04 (2014-01-16) Huawei Proprietary and Confidential x

Routers
5.6.12.5 Suppressing an Interface from Receiving or Sending OSPF Packets................................................................217

5.6.13 Improving the Security of an OSPF Network.......................................................................................................218
5.6.13.1 Configuring the OSPF GTSM Functions...........................................................................................................219
5.6.13.2 Configuring the Area Authentication Mode.......................................................................................................220
5.6.13.3 Configuring the Interface Authentication Mode.................................................................................................221
5.6.14 Configuring the Network Management Function of OSPF...................................................................................223
5.6.14.1 Configuring OSPF MIB Binding........................................................................................................................223
5.6.14.2 Configuring OSPF Trap......................................................................................................................................224
5.6.14.3 Configuring OSPF Log.......................................................................................................................................224
5.7 Maintaining OSPF......................................................................................................................................................225
5.7.1 Clearing OSPF.........................................................................................................................................................225
5.7.2 Resetting OSPF........................................................................................................................................................225
5.8 Configuring Examples................................................................................................................................................226
5.8.1 Example for Configuring Basic OSPF Functions....................................................................................................226
5.8.2 Example for Configuring OSPF Virtual Links........................................................................................................231
5.8.3 Example for Configuring DR Election of OSPF.....................................................................................................235
5.8.4 Example for Configuring OSPF Stub Areas............................................................................................................239
5.8.5 Example for Configuring OSPF NSSAs.................................................................................................................245
5.8.6 Example for Configuring OSPF IP FRR.................................................................................................................250
5.8.7 Example for Configuring BFD for OSPF................................................................................................................253
5.8.8 Example for Configuring OSPF GTSM..................................................................................................................258
5.9 FAQ............................................................................................................................................................................261
5.9.1 Which OSPF Interfaces Require Peers?..................................................................................................................261
5.9.2 How Do I Calculate the Cost of an IGP Route?......................................................................................................261
5.9.3 Why Cannot Interfaces of Different Types Generate Equal-Cost Routes and Establish OSPF Load Balancing?
..........................................................................................................................................................................................263
5.9.4 How Can I Set the cost Value When OSPF Imports External Routes?...................................................................263
5.9.5 What Are the Rules for Selecting Routes Belonging to Different OSPF Processes?..............................................263
5.9.6 Why the Number of Routes in the OSPF Routing Table of the OSPF VPN Multi-instance Is Less than the Predicted
Number?...........................................................................................................................................................................264
5.10 References................................................................................................................................................................264
6 OSPFv3 Configuration............................................................................................................. 266

6.1 Introduction to OSPFv3..............................................................................................................................................267
6.2 Principle......................................................................................................................................................................267
6.2.1 Principle of OSPFv3................................................................................................................................................267
6.2.2 OSPFv3 GR.............................................................................................................................................................274
6.2.3 Association between OSPFv3 and BGP..................................................................................................................277
6.2.4 Comparison between OSPFv3 and OSPFv2...........................................................................................................278
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xi

Routers

6.5 Configuring OSPFv3..................................................................................................................................................285
6.5.1 Configuring Basic OSPFv3 Functions....................................................................................................................285
6.5.1.1 Enabling OSPFv3.................................................................................................................................................285
6.5.1.2 Enabling OSPFv3 on an Interface........................................................................................................................286
6.5.1.3 Entering the OSPFv3 Area View..........................................................................................................................287
6.5.2 Establishing or Maintaining OSPFv3 Neighbor Relationship.................................................................................288
6.5.2.1 Configuring the Interval for Sending Hello Packets............................................................................................288
6.5.2.2 Configuring Dead Time of Neighbor Relationship..............................................................................................289
6.5.2.3 Configuring the Interval for Retransmitting LSAs to Neighboring routers.........................................................290
6.5.2.4 Configuring the Delay for Transmitting LSAs on the Interface...........................................................................290
6.5.3 Configuring OSPFv3 Areas.....................................................................................................................................291
6.5.3.1 Configuring OSPFv3 Stub Areas.........................................................................................................................291
6.5.3.2 Configuring OSPFv3 Virtual Links......................................................................................................................292
6.5.4 Configuring OSPFv3 NSSA Areas..........................................................................................................................293
6.5.4.1 Defining the Current Area to Be an NSSA Area..................................................................................................294
6.5.5 Configuring OSPFv3 Route Attributes....................................................................................................................295
6.5.5.1 Setting the Cost of the OSPFv3 Interface.............................................................................................................295
6.5.5.2 Setting the Maximum Number of Equal-Cost Routes..........................................................................................296
6.5.6 Controlling OSPFv3 Routing Information..............................................................................................................297
6.5.6.1 Configuring OSPFv3 Route Aggregation.............................................................................................................297
6.5.6.2 Configuring OSPFv3 to Filter the Received Routes............................................................................................298
6.5.6.3 Configuring OSPFv3 to Import External Routes.................................................................................................299
6.5.6.4 (Optional) Configuring OSPFv3 to Filter LSAs in an Area.................................................................................300
6.5.7 Optimizing an OSPFv3 Network.............................................................................................................................301
6.5.7.1 Configuring the SPF Timer..................................................................................................................................302
6.5.7.2 Setting the Interval for Receiving LSAs...............................................................................................................302
6.5.7.3 Configuring an Intelligent Timer for Generating LSAs.......................................................................................303
6.5.7.4 Suppressing an Interface from Sending and Receiving OSPFv3 Packets............................................................304
6.5.7.5 Configuring DR Priority of an Interface...............................................................................................................305
6.5.7.6 Configuring Stub Routers.....................................................................................................................................305
6.5.7.7 Ignoring MTU Check on DD Packets..................................................................................................................306
6.5.8 Configuration OSPFv3 GR......................................................................................................................................307
6.5.8.1 Enabling OSPFv3 GR...........................................................................................................................................307
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xii

Routers
6.5.8.2 Enabling the Helper of OSPFv3 GR.....................................................................................................................308

6.5.8.3 Check the Configuration.......................................................................................................................................308
6.5.9 Configuring the Network Management Function of OSPFv3.................................................................................309
6.5.9.1 Configuring OSPFv3 MIB Binding......................................................................................................................309
6.5.9.2 Configuring OSPFv3 Trap....................................................................................................................................309
6.5.9.3 Check the Configuration.......................................................................................................................................310
6.6 Maintaining OSPFv3..................................................................................................................................................310
6.6.1 Resetting OSPFv3....................................................................................................................................................310
6.7.1 Example for Configuring OSPFv3 Areas................................................................................................................311
6.7.2 Example for Configuring OSPFv3 DR Election.....................................................................................................315
6.8 References..................................................................................................................................................................319
7 IPv4 IS-IS Configuration..........................................................................................................321

7.1 Introduction to IS-IS...................................................................................................................................................323
7.2 Principles....................................................................................................................................................................323
7.2.1 IS-IS Basic Concepts...............................................................................................................................................323
7.2.2 IS-IS Basic Principles..............................................................................................................................................329
7.2.3 IS-IS Authentication................................................................................................................................................335
7.2.4 IS-IS Route Leaking................................................................................................................................................336
7.2.5 IS-IS Overload.........................................................................................................................................................337
7.2.6 IS-IS Network Convergence....................................................................................................................................338
7.2.7 IS-IS Administrative Tag.........................................................................................................................................340
7.2.8 IS-IS Wide Metric...................................................................................................................................................341
7.2.9 IS-IS LSP Fragment Extension................................................................................................................................342
7.2.10 IS-IS Host Name Mapping....................................................................................................................................345
7.2.11 IS-IS GR................................................................................................................................................................346
7.2.12 BFD for IS-IS........................................................................................................................................................352
7.2.13 IS-IS Auto FRR.....................................................................................................................................................355
7.2.14 IS-IS TE.................................................................................................................................................................358
7.2.15 IS-IS Multi-Instance and Multi-Process................................................................................................................363
7.5 Configuring IS-IS (IPv4)............................................................................................................................................368
7.5.1 Configure Basic IS-IS Functions.............................................................................................................................368
7.5.1.1 Creating IS-IS Processes......................................................................................................................................368
7.5.1.2 Configuring a NET...............................................................................................................................................369
7.5.1.3 Configuring the Device Level..............................................................................................................................369
7.5.1.4 Establishing IS-IS Neighbor Relationships..........................................................................................................370
7.5.2 Improving IS-IS Network Security..........................................................................................................................373
7.5.2.1 Configuring Interface Authentication...................................................................................................................373
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xiii

Routers
7.5.2.2 Configuring Area or Domain Authentication.......................................................................................................375

7.5.2.3 Configuring the Optional Checksum....................................................................................................................376
7.5.3 Controlling IS-IS Route Selection...........................................................................................................................377
7.5.3.1 Configuring a Preference Value for IS-IS............................................................................................................377
7.5.3.2 Configuring the Cost of an IS-IS Interface...........................................................................................................378
7.5.3.3 Configuring Principles for Using Equal-Cost IS-IS Routes.................................................................................381
7.5.3.4 Configuring IS-IS Route Leaking.........................................................................................................................382
7.5.3.5 Controlling Whether a Level-1 Device Generates a IPv4 Default Route.............................................................383
7.5.4 Controlling IS-IS Route Exchange..........................................................................................................................384
7.5.4.1 Configuring IS-IS to Advertise a Default Route..................................................................................................384
7.5.4.2 Configuring IS-IS to Import External Routes.......................................................................................................385
7.5.4.3 Configuring IS-IS to Advertise Specified External Routes to an IS-IS Routing Domain....................................386
7.5.4.4 Adding Specified IS-IS Routes to the IP Routing Table......................................................................................386
7.5.5 Configuring IS-IS Route Summarization................................................................................................................387
7.5.6 Controlling IS-IS Route Convergence.....................................................................................................................388
7.5.6.1 Configuring Attributes for Hello Packets.............................................................................................................388
7.5.6.2 Configuring Attributes for LSPs...........................................................................................................................390
7.5.6.3 Configuring Attributes for CSNPs.......................................................................................................................395
7.5.6.4 Setting the SPF Calculation Interval....................................................................................................................395
7.5.6.5 Configuring Convergence Priorities for IS-IS Routes..........................................................................................396
7.5.7 Configuring LSP Fragment Extension....................................................................................................................397
7.5.8 Configuring a Mesh Group on an NBMA Network................................................................................................399
7.5.9 Configuring IS-IS Reliability..................................................................................................................................399
7.5.9.1 Enabling IS-IS Auto FRR.....................................................................................................................................400
7.5.9.2 Configuring Static BFD for IS-IS.........................................................................................................................401
7.5.9.3 Configuring Dynamic BFD for IS-IS...................................................................................................................403
7.5.9.4 Enabling IS-IS GR................................................................................................................................................405
7.5.10 Configuring the Overload Bit for an IS-IS Device................................................................................................406
7.6 Maintaining IS-IS.......................................................................................................................................................407
7.6.1 Resetting IS-IS.........................................................................................................................................................407
7.6.2 Improving the Maintainability of IS-IS...................................................................................................................408
7.6.3 Configuring the Output of IS-IS Adjacency Status.................................................................................................409
7.7.1 Example for Configuring Basic IS-IS Functions.....................................................................................................410
7.7.2 Example for Configuring IS-IS Route Summarization...........................................................................................415
7.7.3 Example for Configuring IS-IS DIS Election..........................................................................................................418
7.7.4 Example for Configuring IS-IS to Interact with BGP.............................................................................................423
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xiv

Routers
7.7.5 Example for Configuring IS-IS Fast Convergence..................................................................................................427

7.7.6 Example for Configuring IS-IS Auto FRR (IP Protecting IP).................................................................................430
7.7.7 Example for Configuring IS-IS Auto FRR (TE Protecting IP)...............................................................................436
7.7.8 Example for Configuring Static BFD for IS-IS.......................................................................................................450
7.7.9 Example for Configuring Dynamic BFD for IS-IS.................................................................................................454
7.8 Common Configuration Errors...................................................................................................................................459
7.8.1 Failed to Establish IS-IS Neighbor Relationships...................................................................................................460
7.8.2 A Device Cannot Learn IS-IS Routes from Its Neighbor........................................................................................461
7.9 FAQ............................................................................................................................................................................462
7.9.1 Why Does the IS-IS Neighbor Relationship Fail to Be Established on the DSLAM?............................................462
7.9.2 When Configured with a Link State Protocol, Why Can the Local Device Not Establish Neighbor Relationship with
the Peer Device?...............................................................................................................................................................463
7.10 References................................................................................................................................................................463
8 IPv6 IS-IS Configuration..........................................................................................................465

8.1 Introduction to IS-IS...................................................................................................................................................466
8.2 Principles....................................................................................................................................................................466
8.2.1 IS-IS IPv6................................................................................................................................................................466
8.2.2 IS-IS MT..................................................................................................................................................................467
8.5 Configuring IS-IS (IPv6)............................................................................................................................................472
8.5.1 Configuring Basic IPv6 IS-IS Functions.................................................................................................................472
8.5.1.1 Creating IS-IS Processes......................................................................................................................................473
8.5.1.2 Configuring a NET and Enabling IPv6 IS-IS.......................................................................................................473
8.5.1.3 Configuring the Device Level..............................................................................................................................474
8.5.1.4 Establishing IS-IS Neighbor Relationships..........................................................................................................475
8.5.2 Improving IPv6 IS-IS Network Security.................................................................................................................478
8.5.2.1 Configuring Interface Authentication...................................................................................................................478
8.5.2.2 Configuring Area or Domain Authentication.......................................................................................................479
8.5.2.3 Configuring the Optional Checksum....................................................................................................................481
8.5.3 Controlling IPv6 IS-IS Route Selection..................................................................................................................482
8.5.3.1 Configuring a Preference Value for IPv6 IS-IS....................................................................................................482
8.5.3.2 Configuring the Cost of an IS-IS Interface on IPv6 network...............................................................................483
8.5.3.3 Configuring Principles for Using Equal-Cost IPv6 IS-IS Routes........................................................................485
8.5.3.4 Configuring IS-IS IPv6 Route Leaking................................................................................................................486
8.5.3.5 Controlling Whether a Level-1 Device Generates a IPv6 Default Route.............................................................487
8.5.4 Controlling IPv6 IS-IS Route Exchange.................................................................................................................488
8.5.4.1 Configuring IS-IS to Advertise a Default Route..................................................................................................489
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xv

Routers
8.5.4.2 Configuring IS-IS to Import External Routes.......................................................................................................489

8.5.4.3 Configuring IS-IS to Advertise Specified External Routes to an IS-IS Routing Domain....................................490
8.5.4.4 Adding Specified IS-IS Routes to the IPv6 Routing Table..................................................................................491
8.5.5 Configuring IPv6 IS-IS Route Summarization........................................................................................................492
8.5.6 Controlling IPv6 IS-IS Route Convergence............................................................................................................492
8.5.6.1 Configuring Attributes for Hello Packets.............................................................................................................493
8.5.6.2 Configuring Attributes for LSPs...........................................................................................................................494
8.5.6.3 Configuring Attributes for CSNPs.......................................................................................................................499
8.5.6.4 Setting the SPF Calculation Interval....................................................................................................................500
8.5.6.5 Configuring Convergence Priorities for IS-IS Routes..........................................................................................501
8.5.7 Configuring LSP Fragment Extension....................................................................................................................502
8.5.8 Configuring a Mesh Group on an NBMA Network................................................................................................503
8.5.9 Configuring the Overload Bit for an IS-IS Device..................................................................................................504
8.6 Maintaining IS-IS.......................................................................................................................................................505
8.6.1 Resetting IS-IS.........................................................................................................................................................505
8.6.2 Improving the Maintainability of IS-IS...................................................................................................................506
8.6.3 Configuring the Output of IS-IS Adjacency Status.................................................................................................507
8.7.1 Example for Configuring Basic IPv6 IS-IS Functions............................................................................................507
8.8 References..................................................................................................................................................................513
9 BGP Configuration....................................................................................................................515
9.1 Introduction to BGP....................................................................................................................................................516
9.2 Principles....................................................................................................................................................................517
9.2.1 BGP Concepts..........................................................................................................................................................517
9.2.2 BGP Working Principles.........................................................................................................................................518
9.2.3 Interaction Between BGP and an IGP.....................................................................................................................520
9.2.4 BGP Security...........................................................................................................................................................522
9.2.5 BGP Route Selection Rules and Load Balancing....................................................................................................522
9.2.6 Route Reflector........................................................................................................................................................526
9.2.7 BGP Confederation..................................................................................................................................................530
9.2.8 Route Summarization..............................................................................................................................................531
9.2.9 Route Dampening....................................................................................................................................................531
9.2.10 BFD for BGP.........................................................................................................................................................532
9.2.11 BGP Tracking........................................................................................................................................................533
9.2.12 BGP GR.................................................................................................................................................................534
9.2.13 BGP ORF...............................................................................................................................................................534
9.2.14 Dynamic Update Peer-Groups...............................................................................................................................535
9.2.15 MP-BGP................................................................................................................................................................537
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xvi

Routers

9.5 Configuring BGP........................................................................................................................................................545
9.5.1 Configuring Basic BGP Functions..........................................................................................................................545
9.5.1.1 Starting a BGP Process.........................................................................................................................................546
9.5.1.2 Configuring BGP Peers........................................................................................................................................546
9.5.1.3 (Optional) Configuring a BGP Peer Group..........................................................................................................548
9.5.1.4 Configuring BGP to Import Routes......................................................................................................................550
9.5.2 Configuring BGP Security.......................................................................................................................................552
9.5.2.1 Configuring MD5 Authentication........................................................................................................................552
9.5.2.2 Configuring Keychain Authentication..................................................................................................................553
9.5.2.3 Configuring BGP GTSM......................................................................................................................................554
9.5.3 Simplifying IBGP Network Connections................................................................................................................555
9.5.3.1 Configuring a BGP Route Reflector.....................................................................................................................555
9.5.3.2 Configuring a BGP Confederation.......................................................................................................................557
9.5.4 Configuring BGP Route Selection and Load Balancing.........................................................................................558
9.5.4.1 Configuring the BGP Priority...............................................................................................................................558
9.5.4.2 Configuring the Next_Hop Attribute....................................................................................................................559
9.5.4.3 Configuring the PrefVal Attribute........................................................................................................................560
9.5.4.4 Configuring the Default Local_Pref Attribute......................................................................................................561
9.5.4.5 Configuring the AS_Path Attribute......................................................................................................................562
9.5.4.6 Configuring the MED Attribute...........................................................................................................................564
9.5.4.7 Configuring the BGP Community Attribute........................................................................................................566
9.5.4.8 Configuring BGP Load Balancing.......................................................................................................................567
9.5.5 Controlling the Receiving and Advertisement of BGP Routes...............................................................................570
9.5.5.1 Configuring a Routing Policy...............................................................................................................................570
9.5.5.2 Controlling the Advertisement of BGP Routes....................................................................................................570
9.5.5.3 Controlling the Receiving of BGP Routes...........................................................................................................572
9.5.5.4 Configuring BGP Soft Reset................................................................................................................................574
9.5.6 Adjusting the BGP Network Convergence Speed...................................................................................................576
9.5.6.1 Configuring a BGP ConnectRetry Timer.............................................................................................................577
9.5.6.2 Configuring BGP Keepalive and Hold Timers.....................................................................................................578
9.5.6.3 Configuring a Update Message Timer..................................................................................................................579
9.5.6.4 Disabling Rapid EBGP Connection Reset............................................................................................................580
9.5.6.5 Configuring the BGP Next Hop Delayed Response.............................................................................................581
9.5.6.6 Configuring BGP Route Dampening....................................................................................................................582
9.5.7 Configuring BGP Reliability...................................................................................................................................583
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xvii

Routers
9.5.7.1 Enabling BGP Tracking........................................................................................................................................584

9.5.7.2 Configuring BFD for BGP...................................................................................................................................584
9.5.7.3 Configuring the BGP GR Function......................................................................................................................586
9.5.8 Configuring BGP Route Summarization.................................................................................................................587
9.5.9 Configuring On-demand Route Advertisement.......................................................................................................589
9.5.10 Configuring BGP to Advertise Default Routes to Peers.......................................................................................589
9.5.11 Configuring Path MTU Auto Discovery...............................................................................................................591
9.5.12 Configuring MP-BGP............................................................................................................................................591
9.6 Maintaining BGP........................................................................................................................................................592
9.6.1 Resetting BGP Connections....................................................................................................................................592
9.6.2 Clearing BGP Statistics...........................................................................................................................................593
9.7.1 Example for Configuring Basic BGP Functions.....................................................................................................594
9.7.2 Example for Configuring Basic BGP4+ Functions.................................................................................................599
9.7.3 Example for Configuring Basic MBGP Functions..................................................................................................602
9.7.4 Example for Configuring BGP to Interact with an IGP..........................................................................................610
9.7.5 Example for Configuring AS_Path Filters..............................................................................................................613
9.7.6 Example for Configuring MED Attributes to Control BGP Route Selection.........................................................618
9.7.7 Example for Configuring a BGP Route Reflector...................................................................................................622
9.7.8 Example for Configuring a BGP4+ Route Reflection.............................................................................................626
9.7.9 Example for Configuring a BGP Confederation.....................................................................................................630
9.7.10 Example for Configuring the BGP Community Attribute.....................................................................................635
9.7.11 Example for Configuring Prefix-based BGP ORF................................................................................................638
9.7.12 Example for Configuring BGP Load Balancing....................................................................................................643
9.7.13 Example for Associating BGP with BFD..............................................................................................................647
9.7.14 Example for Configuring BGP GTSM..................................................................................................................652
9.8 FAQ............................................................................................................................................................................660
9.8.1 Why Are Loopback Addresses Used to Establish BGP Peer Relationships?..........................................................660
9.8.2 Why Is the BGP Connection Not Interrupted Immediately After the Interfaces Connecting Two Peers Are Shut
Down?...............................................................................................................................................................................660
9.8.3 Why Are All the Next Hop Addresses in the BGP Routing Table Displayed as 0.0.0.0 After BGP Imports Routes
from Other Protocols?......................................................................................................................................................661
9.9 References..................................................................................................................................................................661
10 Routing Policy Configuration...............................................................................................662

10.1 Introduction to Routing Policy.................................................................................................................................663
10.2 Principle....................................................................................................................................................................663
10.3 Usage Scenario.........................................................................................................................................................666
10.4 Configuration Task Summary..................................................................................................................................668
10.5 Configuring Routing Policies...................................................................................................................................671
10.5.1 Filter Configuration...............................................................................................................................................671
10.5.1.1 Configuring an IP Prefix List.............................................................................................................................671
10.5.1.2 Configuring an AS_Path Filter...........................................................................................................................672
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xviii

Routers
10.5.1.3 Configuring a Community Filter........................................................................................................................673

10.5.1.4 Configuring an Extended Community Filter......................................................................................................674
10.5.1.5 Configuring an RD Filter....................................................................................................................................674
10.5.2 Configuring a Routing Policy................................................................................................................................675
10.5.2.1 Creating a Routing Policy...................................................................................................................................675
10.5.2.2 (Optional) Configuring an if-match Clause........................................................................................................676
10.5.2.3 (Optional) Configuring an apply Clause............................................................................................................678
10.5.3 Controlling the Valid Time of the Routing policy................................................................................................680
10.6 Maintaining the Routing Policy................................................................................................................................681
10.7 Configuration Examples...........................................................................................................................................681
10.7.1 Example for Filtering Received and Advertised Routes.......................................................................................681
10.7.2 Example for Applying a Routing Policy for Importing Routes.............................................................................686
10.8 References................................................................................................................................................................690
11 Managing IP Routing Tables................................................................................................691

11.1 Managing IP Routing Tables....................................................................................................................................692
11.1.1 Displaying and Maintaining a Routing Table........................................................................................................692
11.1.2 Displaying the Routing Management Module.......................................................................................................693
11.1.3 FIB Query and Maintenance..................................................................................................................................693
11.1.4 Setting the Route Delivery Mode of an LPU........................................................................................................695
11.1.5 Configuring IP FRR on the Public Network.........................................................................................................696
11.2.1 Example for Configuring IP FRR on the Public Network.....................................................................................697
12 PBR Configuration..................................................................................................................702
12.1 Introduction to Policy-based Routing.......................................................................................................................703
12.2 Principles..................................................................................................................................................................703
12.2.1 Local PBR..............................................................................................................................................................703
12.2.2 Interface PBR........................................................................................................................................................705
12.2.3 Smart Policy Routing.............................................................................................................................................705
12.3 Applications..............................................................................................................................................................708
12.4 Configuration Tasks.................................................................................................................................................710
12.5 Configuration Notes.................................................................................................................................................711
12.6 Configuring PBR......................................................................................................................................................712
12.6.1 Configuring Local PBR.........................................................................................................................................712
12.6.1.1 Configuring Matching rules of Local PBR.........................................................................................................712
12.6.1.2 Configuring Actions of Local PBR....................................................................................................................713
12.6.1.3 Applying Local PBR..........................................................................................................................................715
12.6.2 Configuring Interface PBR....................................................................................................................................716
12.6.3 Configuring SPR....................................................................................................................................................721
12.6.3.1 Setting SPR Routing Parameters........................................................................................................................721
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xix

Routers
12.6.3.2 Associating SPR with Services...........................................................................................................................723

12.6.3.3 (Optional) Configuring an NQA Server Link.....................................................................................................725
12.7.1 Example for Configuring Local PBR....................................................................................................................727
12.7.2 Example for Configuring Interface PBR...............................................................................................................736
12.7.3 Example for Configuring SPR...............................................................................................................................744
12.8 References................................................................................................................................................................750
Issue 04 (2014-01-16) Huawei Proprietary and Confidential xx

Routers
Configuration Guide - IP Routing 1 IP Routing Overview
1 IP Routing Overview
About This Chapter
This section describes the basic infomation of IP Routing.
1.1 Introduction to IP Routing

Routing is the basic element of data communication networks. It is the process of selecting paths
on a network along which packets are sent from a source to a destination.
1.2 Principles
This section describes the implementation of IP Routing.
1.3 References
This section lists references of IP Routing.
Issue 04 (2014-01-16) Huawei Proprietary and Confidential 1

Routers
1.1 Introduction to IP Routing

Routing is the basic element of data communication networks. It is the process of selecting paths
on a network along which packets are sent from a source to a destination.
Routes are classified into the following types based on the destination address:
l Network segment route: The destination is a network segment. The subnet mask of an IPv4
destination address is less than 32 bits or the prefix length of an IPv6 destination address
is less than 128 bits.
l Host route: The destination is a host. The subnet mask of an IPv4 destination address is 32
bits or the prefix length of an IPv6 destination address is 128 bits.
Routes are classified into the following types based on whether the destination is directly
connected to a router:
l Direct route: The router is directly connected to the network where the destination is
located.
l Indirect route: The router is indirectly connected to the network where the destination is
located.
Routes are classified into the following types based on the destination address type:
l Unicast route: The destination address is a unicast address.
l Multicast route: The destination address is a multicast address.
1.2 Principles
This section describes the implementation of IP Routing.
1.2.1 Routers and Routing Principles

On the Internet, network connecting devices control traffic and ensure data transmission quality.
Common network connecting devices include hubs, bridges, switches, and routers. These
network devices have similar basic principles. The following uses a router as an example to
describe basic principles.
As a typical network connecting device, a router selects routes and forwards packets. Upon
receiving a packet, a router selects a proper path, which has one or multiple hops, to send the
packet to the next router according to the destination address in the packet. The last router is
responsible for sending the packet to the destination host.
A route is a path along which packets are sent from the source to the destination. When multiple
routes are available to send packets from a router to the destination, the router can select the
optimal route from an IP routing table to forward the packets. Optimal route selection depends
on the routing protocol preferences and metrics of routes. When multiple routes have the same
routing protocol preference and metric, load balancing can be implemented among these routes
to relieve network pressure. When multiple routes have different routing protocol preferences
and metrics, route backup can be implemented among these routes to improve network
reliability.

Routers
1.2.2 Static Routes and Dynamic Routes

Routes support static routes and dynamic routes including Routing Information Protocol (RIP)
routes, Open Shortest Path First (OSPF) routes, Intermediate System-to-Intermediate System
(IS-IS) routes, and Border Gateway Protocol (BGP) routes.
Differences Between Static Routes and Dynamic Routes

Routing protocols are the rules used by routers to discover routes, generate and maintain routing
tables, and guide packet forwarding. Routes are classified into the following types based on the
origin:
l Direct route: is discovered by link layer protocols.
l Static route: is manually configured by network administrators.
l Dynamic route: is discovered by dynamic routing protocols.
Static routes are easy to configure, have low requirements on the system, and apply to simple,
stable, and small networks. The disadvantage of static routes is that they cannot automatically
adapt to network topology changes. Therefore, static routes require subsequent maintenance.
Dynamic routing protocols have their routing algorithms. Therefore, dynamic routes can
automatically adapt to network topology changes and apply to the networks on which Layer 3
devices are deployed. The configurations of dynamic routes are complex. Dynamic routes have
higher requirements on the system than static ones and consume network resources and system
resources.
Classification of Dynamic Routing Protocols

Based on the application range, dynamic routing protocols are classified into the following types:
l Interior Gateway Protocol (IGP): runs inside an AS, such as RIP, OSPF, and IS-IS.
l Exterior Gateway Protocol (EGP): runs between different ASs, such as BGP.
Based on the type of algorithm they use, dynamic routing protocols are classified into the
following types:
l Distance-vector routing protocol: includes RIP and BGP. BGP is also called path-vector
protocol.
l Link-state routing protocol: includes OSPF and IS-IS.
The preceding algorithms differ mainly in route discovery and calculation methods.
1.2.3 Routing Table and FIB Table

Routers forward packets based on routing tables and forwarding information base (FIB) tables.
Each router maintains at least one routing table and one FIB table. Routers select routes based
on routing tables and forward packets based on FIB tables.
Routing Table
Each router maintains a local core routing table, and each routing protocol maintains its routing
table.

Routers
l Local core routing table

A router uses the local core routing table to store protocol routes and preferred routes. The
router then sends the preferred routes to the FIB table to guide packet forwarding. The
router selects routes according to the priorities of protocols and costs stored in the routing
table.
NOTE
A router that supports Layer 3 Virtual Private Network (L3VPN) maintains a local core routing table
for each VPN instance.
l Protocol routing table
A protocol routing table stores the routing information discovered by the protocol.
A routing protocol can import and advertise the routes that are discovered by other routing
protocols. For example, if a router that runs the Open Shortest Path First (OSPF) protocol
needs to use OSPF to advertise direct routes, static routes, or Intermediate System-
Intermediate System (IS-IS) routes, the router must import the routes into the OSPF routing
table.
Routing Table Contents

You can run the display ip routing-table command on a router to view brief information about
the routing table of the router. The command output is as follows:
<Huawei> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 14 Routes : 14
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 Static 60 0 RD 10.137.216.1 GigabitEthernet

2/0/0
10.10.10.0/24 Direct 0 0 D 10.10.10.10 GigabitEthernet
1/0/0
10.10.10.10/32 Direct 0 0 D 127.0.0.1 InLoopBack0
10.10.11.0/24 Direct 0 0 D 10.10.11.1 LoopBack0
10.137.216.0/23 Direct 0 0 D 10.137.217.208 GigabitEthernet
2/0/0
A routing table contains the following key data for each IP packet:
l Destination: identifies the destination IP address or the destination network address of an
IP packet.
l Mask: works with the destination address to identify the address of the network segment
where the destination host or router resides.
The network segment address of the destination host or router is obtained through the
"AND" operation on the destination address and network mask. For example, if the
destination address is 1.1.1.1 and the mask is 255.255.255.0, the address of the network
segment where the host or router resides is 1.1.1.0.

Routers
The network mask is composed of several consecutive 1s. These 1s can be expressed in
either the dotted decimal notation or the number of consecutive 1s in the mask. For example,
the network mask can be expressed either as 255.255.255.0 or 24.
l Proto: indicates the protocol through which routes are learned.
l Pre: indicates the routing protocol preference of a route. There may multiple routes to the
same destination, which have different next hops and outbound interfaces. These routes
may be discovered by different routing protocols or manually configured. A router selects
the route with the highest preference (the smallest value) as the optimal route. For the
routing protocol preference, see 1.2.4 Routing Protocol Preference.
l Cost: indicates the route cost. When multiple routes to the same destination have the same
preference, the route with the lowest cost is selected as the optimal route.
NOTE
The Preference value is used to compare the preferences of different routing protocols, while the
Cost value is used to compare the preferences of different routes of the same routing protocol.
l NextHop: indicates the IP address of the next device that an IP packet passes through.
l Interface: indicates the outbound interface through which an IP packet is forwarded.
As shown in Figure 1-1, RouterA connects to three networks, so it has three IP addresses and
three outbound interfaces. Figure 1-1 shows the routing table of RouterA.
Figure 1-1 Routing table
11.0.0.0/8
Routing Table
Destination Nexthop Interface
11.0.0.0/8 1.1.1.2 GE1/0/0 RouterB
12.0.0.0/8 2.2.2.2 GE2/0/0 1.1.1.2/24
13.0.0.0/8 3.3.3.2 GE3/0/0
GE1/0/0
1.1.1.1/24
GE2/0/0 GE3/0/0
2.2.2.1/24 3.3.3.1/24
RouterA
RouterC RouterD
2.2.2.2/24 3.3.3.2/24
12.0.0.0/8 13.0.0.0/8
Automatic Restoration After the Number of Routes Exceeds the Upper Limit
A local core routing table stores the routes of different routing protocols. If the number of routes
in the local core routing table reaches the upper limit, no route can be added to the table. The
local core routing table has the following types of route limitations:

Routers
l System route limit: specifies the maximum number of routes supported by the system.
l System route prefix limit: specifies the range of prefixes for all the routes supported by the
system.
l Multicast IGP route limit: specifies the maximum number of multicast IGP routes.
l Multi-topology route limit: specifies the maximum number of multi-topology routes.
l Private network route limit: specifies the maximum number of private network routes
supported by the system.
l VPN route limit: specifies the maximum number of VPN routes supported by the system.
l VPN route prefix limit: specifies the range of prefixes for all the VPN routes supported by
the system.
If a protocol fails to add routes to the local core routing table due to a specific route limitation,
the system records the failure with the protocol name and routing table ID.
After routes of protocols are deleted from the local core routing table, and the number of routes
falls below the upper limit, the system prompts all the protocols that failed to add routes to the
local core routing table to re-add the routes to the local core routing table. This process restores
most of the routes in the local core routing table. The size of released table space determines
whether all routes in the local core routing table can be restored.
Matching with FIB Table

After route selection, routers send active routes in the routing table to the FIB table. When a
router receives a packet, the router searches the FIB table for the optimal route to forward the
packet.
Each entry in the FIB table contains the physical or logical interface through which a packet is
sent to a network segment or host to reach the next router. An entry also indicates whether the
packet can be sent to a destination host in a directly connected network.
The router performs the "AND" operation on the destination address in the packet and the
network mask of each entry in the FIB table. The router then compares the result of the "AND"
operation with the entries in the FIB table to find a match and chooses the optimal route to
forward packets according to the longest match.
Assume that a router has the following routing table:

Routing Tables:
0.0.0.0/0 Static 60 0 D 120.0.0.2 GigabitEthernet1/0/0
8.0.0.0/8 RIP 100 3 D 120.0.0.2 GigabitEthernet1/0/0
9.0.0.0/8 OSPF 10 50 D 20.0.0.2 GigabitEthernet3/0/0
20.0.0.0/8 Direct 0 0 D 20.0.0.1 GigabitEthernet4/0/0
After receiving a packet that carries the destination address 9.1.2.1, the router searches the
following FIB table:
FIB Table:
Total number of Routes : 5
Destination/Mask Nexthop Flag TimeStamp Interface TunnelID
0.0.0.0/0 120.0.0.2 SU t[37] GigabitEthernet1/0/0 0x0
8.0.0.0/8 120.0.0.2 DU t[37] GigabitEthernet1/0/0 0x0
20.0.0.0/8 20.0.0.1 U t[9992] GigabitEthernet4/0/0 0x0

Routers
The router performs the "AND" operation on the destination address 9.1.2.1 and the masks 0,
8, and 16 to obtain the network segment addresses: 0.0.0.0/0, 9.0.0.0/8, and 9.1.0.0/16. The three
addresses match three entries in the FIB table. The router chooses the entry 9.1.0.0/16 according
to the longest match, and forwards the packet through GigabitEthernet2/0/0.
1.2.4 Routing Protocol Preference

Routing protocols (including static route) may discover different routes to the same destination,
but not all routes are optimal. At a certain moment, only one routing protocol determines the
optimal route to a destination. To select the optimal route, each routing protocol (including static
route) is assigned a preference (a smaller value indicates a higher preference). When multiple
routing information sources coexist, the route discovered by the routing protocol with the highest
preference is selected as the optimal route and added to the local routing table.
Routers define external preference and internal preference. External preference is manually
configured for each routing protocol. Table 1-1 lists the default external preferences of routing
protocols.
Table 1-1 Routing protocols and their default external preferences
Routing Protocol or Route Default External Preference

Type
Direct 0
OSPF 10
IS-IS 15
Static 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 255
EBGP 255
NOTE
In Table 1-1, the value 0 indicates direct routes and the value 255 indicates routes learned from unreliable
sources. A smaller value indicates a higher preference.
You can manually configure the preference of a routing protocol except direct routes. In addition, the
preference for each static route varies.
Internal preferences of routing protocols cannot be manually configured. Table 1-2 lists the
internal preferences of routing protocols.

Routers
Table 1-2 Internal preferences of routing protocols
Routing Protocol or Route Internal Preference

Type
Direct 0
OSPF 10
IS-IS Level-1 15
IS-IS Level-2 18
Static 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 200
EBGP 20
During route selection, a router first compares the external preferences of routes. When the same
external preference is set for different routing protocols, the router selects the optimal route
based on the internal preference. Assume that there are two routes to 10.1.1.0/24: a static route
and an OSPF route. Both routes have the same external preference that is set to 5. In this case,
the router determines the optimal route based on the internal preference listed in Table 1-2. An
OSPF route has an internal preference 10, and a static route has an internal preference 60. This
indicates that the OSPF route has a higher preference than the static route. Therefore, the router
selects the OSPF route as the optimal route.
1.2.5 Route Metric

A route metric specifies the cost of a route to a specified destination address. The following
factors often affect the route metric:
l Path length
The path length is the most common factor affecting the route metric. Link-state routing
protocols allow you to assign a link cost for each link to identify the path length of a link.
In this case, the path length is the sum of link costs of all the links that packets pass through.
Distance-vector routing protocols use the hop count to identify the path length. The hop
count is the number of devices that packets pass through from the source to the destination.
For example, the hop count from a router to its directly connected network is 0, and the
hop count from a router to a network that can be reached through another router is 1. The
rest can be deduced in the same manner.
l Network bandwidth
The network bandwidth is the transmission capability of a link. For example, a 10-Gigabit
link has a higher transmission capability than a 1-Gigabit link. Although bandwidth defines
the maximum transmission rate of a link, routes over high-bandwidth links are not

Routers
necessarily better than routes over low-bandwidth links. For example, when a high-
bandwidth link is congested, forwarding packets over this link will require more time.
l Load
The load is the degree to which a network resource is busy. You can calculate the load by
calculating the CPU usage and packets processed per second. Monitoring the CPU usage
and packets processed per second continually helps learn about network usage.
l Communication cost
The communication cost measures the operating cost of a route over a link. The
communication cost is another important indicator, especially if you do not care about
network performance but the operating expenditure.
1.2.6 Load Balancing and Route Backup

When multiple routes have the same routing protocol preference and metric, these routes are
called equal-cost routes, among which load balancing can be implemented. When multiple routes
have different routing protocol preferences and metrics, route backup can be implemented
among these routes.
Load Balancing
Routers support the multi-route mode, allowing you to configure multiple routes with the same
destination and preference. If the destinations and costs of multiple routes discovered by the
same routing protocol are the same, load balancing can be performed among the routes.
During load balancing, a router forwards packets based on the 5-tuple (source IP address,
destination IP address, source port, destination port, and transport protocol) in the packets. When
the 5-tuple information is the same, the router always chooses the next-hop address that is the
same as the last one to send packets. When the 5-tuple information is different, the router
forwards packets over idle paths.
Figure 1-2 Networking diagram of load balancing
RouterB
GE1/0/0
10.1.1.0/24
P1P6 10.1.1.0/24
RouterA 10.2.1.0/24
10.2.1.0/24
P1P6 RouterD
GE2/0/0
RouterC

Routers
As shown in Figure 1-2, RouterA forwards the first packet P1 to 10.1.1.0/24 through GE1/0/0
and needs to forward subsequent packets to 10.1.1.0/24 and 10.2.1.0/24 respectively. The
forwarding process is as follows:
l When forwarding the second packet P2 to 10.1.1.0/24, RouterA forwards P2 and

subsequent packets destined for 10.1.1.0/24 through GE1/0/0 if it finds that the 5-tuple
information of P2 is the same as that of P1 destined for 10.1.1.0/24.
l When forwarding the first packet P1 to 10.2.1.0/24, RouterA forwards this packet and
subsequent packets destined for 10.2.1.0/24 through GE2/0/0 if it finds that the 5-tuple
information of P1 destined for 10.2.1.0/24 is different from that of P1 destined for
10.1.1.0/24.
NOTE
The number of equal-cost routes for load balancing varies with products.
Route Backup
Route backup can improve network reliability. You can configure multiple routes to the same
destination as required. The route with the highest preference functions as the primary route,
and the other routes with lower preferences function as backup routes.
A router generally uses the primary route to forward data. When the primary link fails, the
primary route becomes inactive. The router selects a backup route with the highest preference
to forward data. In this manner, data is switched from the primary route to a backup route. When
the primary link recovers, the router selects the primary route to forward data again because the
primary route has the highest preference. Data is then switched back from the backup route to
the primary route.
1.2.7 IP FRR
Definition
When a router detects a fault at the physical or data link layer, IP fast reroute (FRR) enables the
router to report the fault to the upper-layer routing system and to immediately use a backup link
to forward packets. IP FRR is a method that implements fast route backup.
Purpose
On traditional IP networks, when a fault occurs at the lower layer of the forwarding link, the
physical interface on the router becomes Down. After the router detects the fault, it informs the
upper-layer routing system to recalculate routes and then update routing information. Usually,
it takes the routing system several seconds to re-select an available route.
Second-level convergence is intolerable to the services that are quite sensitive to delay and packet
loss because it may lead to service interruption. For example, Voice over Internet Protocol
(VoIP) services are only tolerant of millisecond-level interruption.
IP FRR ensures that the forwarding system rapidly detects a link fault and then uses a backup
route to restore services as soon as possible.

Routers
IP FRR Classification and Implementation

IP FRR, which is designed for routes on IP networks, is classified into IP FRR on the public
network and IP FRR on the private network.
l IP FRR on the public network: protects routers of the public network.

l IP FRR on the private network: protects Customer Edges (CEs).
IP FRR is implemented as follows:
1. If the primary link is available, you can configure an IP FRR policy to provide the
forwarding information of the backup route to the forwarding engine.
2. If the forwarding engine detects a link fault, the engine uses the backup link to forward
traffic before the routes on the control plane converge.
IP FRR Typical Applications

As shown in Figure 1-3, IP FRR is configured to improve network reliability. CE1 is dual-
homed to PE1 and PE2 and has two outbound interfaces and two next hops configured. That is,
link B functions as the backup of link A. When link A fails, traffic can be rapidly switched to
link B.
Figure 1-3 IP FRR
IP forwarding
Link A PE1
CE1 Link B
IP forwarding
PE2
1.2.8 Route Convergence
Definition
Route convergence is the action of recalculating routes to replace existing routes in the case of
network topology changes. The integration of network services urgently requires differentiated
services. Routes for key services, such as Voice over IP (VoIP), video conferences, and multicast
services, need to be converged rapidly, while routes for common services can be converged
relatively slowly. In this case, the system needs to converge routes based on their convergence
priorities to improve network reliability.
Priority-based convergence is a mechanism that allows the system to converge routes based on
the convergence priority. You can set different convergence priorities for routes: critical, high,
medium, and low, which are in descending order of priority. The system then converges routes
according to the scheduling weight to guide service forwarding.

Routers
Principles
Routing protocols first compute and deliver routes of high convergence priorities to the system.
You can reconfigure the scheduling weight values as required. Table 1-3 lists the default
convergence priorities of public routes.
Table 1-3 Default convergence priorities of public routes
Routing Protocol or Route Type Convergence Priority
Direct high
Static medium
32-bit host routes of OSPF and IS-IS medium
OSPF routes (excluding 32-bit host routes) low
IS-IS routes (excluding 32-bit host routes) low
RIP low
BGP low
NOTE
For private routes, only the convergence priority of 32-bit host routes of OSPF and IS-IS is identified as
medium and the convergence priorities of the other routes are identified as low.
Priority-based Route Convergence

Figure 1-4 shows the networking for multicast services. OSPF and IS-IS run on the network;
the receiver connects to RouterA; the multicast source server 10.10.10.10/32 connects to
RouterB. The route to the multicast source server must be converged faster than other routes,
such as 12.10.10.0/24. You can set the convergence priority of route 10.10.10.10/32 to be higher
than that of route 12.10.10.0/24. When routes are converged on the network, the route to the
multicast source server 10.10.10.10/32 is converged first. This ensures the transmission of
multicast services.
Figure 1-4 Networking diagram of priority-based route convergence
IS-IS
12.10.10.0/24
OSPF
OSPF
10.10.10.10/32
User RouterA RouterB Source

Routers
1.2.9 Default Routes

Default routes are special routes, which are used only when packets to be forwarded do not match
any routing entry in a routing table. If the destination address of a packet does not match any
entry in the routing table, the packet is sent through a default route. If no default route exists and
the destination address of the packet does not match any entry in the routing table, the packet is
discarded. An Internet Control Message Protocol (ICMP) packet is then sent, informing the
originating host that the destination host or network is unreachable.
In a routing table, a default route is the route to network 0.0.0.0 (with the mask 0.0.0.0). You
can run the display ip routing-table command to check whether a default route is configured.
Generally, administrators can manually configure default static routes. Default routes can also
be generated through dynamic routing protocols such as OSPF and IS-IS.
1.2.10 Route Import

Different routing protocols may discover different routes because they use different algorithms.
If multiple routing protocols run on a large network, the routing protocols need to re-advertise
the routes they discover.
Each routing protocol can import the routes discovered by other routing protocols, direct routes,
and static routes using its mechanism.
1.2.11 Autonomous System

An Autonomous System (AS) is a set of IP networks and routers under one entity and with
common routing policies.
Each AS supports multiple IGPs. All the networks in an AS are assigned the same AS number
and managed by the same administration group. Two types of AS numbers are available: 2-byte
AS number and 4-byte AS number. A 2-byte AS number ranges from 1 to 65535. Available AS
numbers become almost exhausted. Therefore, 2-byte AS numbers need to be extended to 4-
byte AS numbers that range from 1 to 4294967295. A 4-byte AS number is in the X.Y format,
where X ranges from 1 to 65535 and Y ranges from 0 to 65535.
AS numbers are classified into two types based on the network where they are used. Table
1-4 lists the two types of AS numbers and their ranges.
Table 1-4 AS number types and ranges
AS Number Type 2-Byte AS Number 4-Byte AS Number
Public AS number 1 to 64511 1 to 64511, 65536 to

4294967295
Private AS number 64512 to 65535 64512 to 65535

Routers
1.2.12 Indirect Next Hop

Definition
Indirect next hop is a technique that speeds up route convergence. It can change the direct
association between route prefixes and next hops into an indirect association. Then next-hop
information can be refreshed independently, and the prefixes of the same next hop do not need
to be refreshed one by one. This speeds up route convergence.
Purpose
In the scenario requiring route iteration, when IGP routes or tunnels are switched, FIB entries
are quickly refreshed. This implements fast traffic convergence and reduces the impact on
services.
Mapping Between the Route Prefix and Next Hop

The mapping between the route prefix and next hop is the basis of indirect next hop. To meet
the requirements of route iteration and tunnel iteration in different scenarios, next-hop
information involves the address family, original next-hop address, and tunnel policy. The
system assigns an index to information about each next hop, performs route iteration, notifies
the iteration result to the routing protocols, and distributes FIB entries.
On-Demand Route Iteration

In on-demand route iteration, when a dependent route is changed, only the next hop related to
the dependent route is re-iterated. If the destination address of a route is the original next-hop
address or network segment address of next-hop information, route changes affect the iteration
result of next-hop information. Otherwise, route changes do not affect next hop-information.
Therefore, when a route changes, you can re-iterate only the related next hop according to the
destination address of the route.
In tunnel iteration, when a tunnel alternates between Up and Down, you just need to re-iterate
the next-hop information whose original next-hop address is the same as the destination address
of the tunnel.
Iteration Policy
An iteration policy controls the next-hop iteration result to meet the requirements of different
application scenarios. In route iteration, iteration behaviors do not need to be controlled by the
iteration policy. Instead, iteration behaviors only need to comply with the longest matching rule.
The iteration policy needs to be used only when VPN routes are iterated to tunnels.
By default, the system selects LSPs for a VPN without performing load balancing. If load
balancing or other types of tunnels are required, you need to configure a tunnel policy and bind
the tunnel policy to a tunnel. After a tunnel policy is applied, the system uses the tunnel bound
in the tunnel policy or selects a tunnel according to the priorities of different types of tunnels.
Refreshment of Indirect Next Hop

On the forwarding plane, public network routes are forwarded based on the next hop and
outbound interface while VPN routes are forwarded based on the public network tunnel in

Routers
addition to the next hop and outbound interface. Before indirect next hop is used, forwarding
information, including the next hop, outbound interface, and tunnel token, needs to be added
into the FIB entry using the route prefix. In this case, the route convergence speed is relevant to
the number of route prefixes. After indirect next hop is used, many route prefixes correspond to
a shared next hop. Forwarding information is added into the FIB entry using the next hop, and
the traffic with the relevant route prefixes can be switched simultaneously. Therefore, the route
convergence speed becomes faster.
Figure 1-5 Schematic diagram before indirect next hop is used
Forwarding
Prefix 1 Nexthop 1
Information 1
Forwarding
Prefix 2 Nexthop 2
Information 2

Forwarding
Prefix N Nexthop N
Information N
As shown in Figure 1-5, before indirect next hop is used, prefixes are independent of each other,
each corresponding to its next hop and forwarding information. When a dependent route changes,
the next hop corresponding to each prefix is iterated and forwarding information is updated based
on the prefix. In this case, the convergence speed is related to the number of prefixes.
Actually, prefixes of a BGP neighbor have the same next hop, forwarding information, and
refreshed forwarding information.
Figure 1-6 Schematic diagram after indirect next hop is used
Prefix 1
Forwarding
Prefix 2 Nexthop
Information
Prefix N
As shown in Figure 1-6, after indirect next hop is used, prefixes of a BGP neighbor share a next
hop. When a dependent route changes, only the shared next hop is iterated and forwarding
information is updated based on the next hop. In this case, traffic of all prefixes can be converged
simultaneously. The convergence speed is irrelevant to the number of prefixes.

Routers
Comparison Between Route Iteration and Tunnel Iteration

Comparison between route iteration and tunnel iteration is shown in the following table.
Table 1-5 Comparison between route iteration and tunnel iteration
Iteration Type Description
Route iteration l Iterates BGP public routes.

l Triggered by route changes.
l Supports next-hop iteration based on the specified routing policy.
Tunnel iteration l Iterates BGP VPN routes.

l Triggered by tunnel changes or tunnel policy changes.
l Controls iteration behaviors through the tunnel policy to meet the
requirements of different application scenarios.
1.3 References
This section lists references of IP Routing.
None

Routers
Configuration Guide - IP Routing 2 Static Route Configuration
2 Static Route Configuration
About This Chapter
Static routes apply to simple networks. Proper static routes can improve network performance
and ensure bandwidth for important applications.
2.1 Introduction to Static Routes

This section describes the definition and purpose of Static Routes.
2.2 Principles
This section describes the implementation of Static Routes.
2.3 Applications
This section describes the applicable scenario of Static Routes.
2.4 Configuration Task Summary

On a network, you can accurately control route selection by configuring static routes. If other
static route functions are required, configure them according to reference sections.
2.5 Default Configuration of Static Routes

This section describes the default configuration of static routes, which can be changed according
to network requirements.
2.6 Configuring Static Routes

Static routes are applicable to the networks with simple structures. Proper configuration and
usage of static routes improve the network performance and meet the bandwidth requirement of
important applications.
2.7 Configuration Examples

This section provides configuration examples of static routes. Configuration examples explain
networking requirements, networking diagram, configuration notes, configuration roadmap, and
configuration procedure.
2.8 FAQ
This section provides the questions you may encounter during configuration and their answers.
2.9 References
This section lists references of Static Routes.

Routers
2.1 Introduction to Static Routes

This section describes the definition and purpose of Static Routes.
Definition
Static routes are routes that are manually configured by the administrator.
Purpose
Static routes provide different functions on different networks.
l On a simple network, only static routes are required to ensure normal running of the
network.
l On a complex network, static routes improve the network performance and ensure the
required bandwidth for important applications.
l The static routes associated with VPN instances are used to manage VPN routes.
2.2 Principles
This section describes the implementation of Static Routes.
2.2.1 Basics of Static Routes

A router forwards data packets based on routing entries containing route information. The
routing entries can be manually configured or calculated by dynamic routing protocols. Static
routes refer to the routes that are manually added to the routing table.
Static routes use less bandwidth than dynamic routes. No CPU resource is used for calculating
or analyzing routing update. When a fault occurs on the network or the topology changes, static
routes cannot automatically change and must be changed manually. The configuration of a static
route includes destination IP address and mask, outbound interface and next-hop address, and
preference.
Destination Address and Mask

The destination IPv4 address is expressed in dotted decimal notation. The mask can be expressed
either in dotted decimal notation or by the mask length, that is, the number of consecutive 1s in
the mask. For details about the destination IPv6 address and mask, see "Basic IPv6
Configurations - Principles - IPv6 Addresses" in the Configuration Guide - IP Service. When
the destination and mask are set to all 0s, the default static route is configured. For details about
the default static route, see 2.3.2 Application of the Static Default Route.
Outbound Interface and Next-Hop IP Address

When configuring a static route, you can specify the outbound interface and the next-hop IP
address based on outbound interfaces types.

Routers
l Configure the outbound interface for point-to-point (P2P) interfaces. For a P2P interface,
the next-hop address is specified after the outbound interface is specified. That is, the
address of the remote interface (interface on the peer device) connected to this interface is
the next-hop address. For example, the protocol used to encapsulate 10GE is the Point-to-
Point protocol (PPP). The remote IP address is obtained through PPP negotiation. You need
specify only the outbound interface.
l Configure the next hop for Non Broadcast Multiple Access (NBMA) interfaces (for
example, ATM interfaces). You need to configure the IP route and the mapping between
IP addresses and link-layer addresses.
l Configure the next hop for broadcast interfaces (for example, Ethernet interfaces) and
virtual template (VT) interfaces. The Ethernet interface is a broadcast interface, and the
VT interface can be associated with several virtual access (VA) interfaces. If the Ethernet
interface or the VT interface is specified as the outbound interface, multiple next hops exist
and the system cannot decide which next hop is to be used. Therefore, this configuration
is not recommended.
Static Route Preference

Different static routes can be configured with different preferences. A smaller preference value
indicates a higher priority of static routes. If you specify the same preference for the static routes
to the same destination, you can implement load balancing among these routes. If you specify
different preferences for the static routes, you can implement route backup among the routes.
For details, see 2.3.1 Load Balancing and Route Backup.
2.2.2 BFD for Static Routes

Different from dynamic routing protocols, static routes do not have a detection mechanism. As
a result, when a link fault occurs on the network, the administrator needs to handle it.
Bidirectional Forwarding Detection (BFD) for static route is introduced to bind a static route to
a BFD session so that the BFD session can detect the status of the link where the static route
resides.
l When the BFD session that is bound to a static route detects a link fault, BFD reports the
link fault to the Routing Management (RM) module. The RM module sets the route to
inactive. The route is unavailable in the routing table.
l When the BFD session that is bound to a static route detects that the faulty link is re-
established, BFD reports a message to the RM module. The RM module sets the route to
active. The route is available in the IP routing table.
NOTE
For details about BFD, see "BFD Configuration - Principles" in the Configuration Guide - Reliability.
2.2.3 NQA for Static Routes

As mentioned previously, static routes do not have a dedicated detection mechanism. After a
fault occurs, the corresponding static route is automatically deleted from the IP routing table.
This condition delays the link switchover and can interrupt services for a comparatively long
time. The network administrator must delete the corresponding static route to allow traffic to
switch to an available path.
An effective method is required to detect faults in links related to static routes. BFD for static
routes is applicable only to the scenario where both communicating devices support BFD. If

Routers
either of the two communicating devices supports NQA, NQA for static routes can be used to
detect faults in links where Layer 2 devices reside.
NQA for static routes refers to the association between a static route and an NQA test instance.
The system can use the NQA test instance to check the link status. Then, according to the NQA
test result, the system can determine an optimal route in time to prevent communication
interruption and ensure service quality. NQA for static routes functions as follows:
l If NQA detects a fault in the link, the system sets the static route to inactive. The route
becomes unavailable and is deleted from the IP routing table.
l If NQA finds that the link recovers, the system sets the static route to active. The route
becomes available and is added to the IP routing table.
NOTE
When a static route is associated with an NQA test instance, only ICMP test instances are used to test
whether there are reachable routes between the source and destination.
Each static route can be associated with only one NQA test instance.
For details about NQA, see "NQA Configuration - Principles" in the Configuration Guide - Network
Management.
Applications
On the network shown in Figure 2-1, each access switch provides access services for 10 users,
and a total of 100 users are connected to the network. Because dynamic routing protocols are
unavailable for communication between RouterB and users, static routes are configured on
RouterB. For network stability, RouterC, functioning as the backup for RouterB, is configured
with static routes to the same destination. RouterA, RouterB, and RouterC run a dynamic routing
protocol to learn routes from each other. RouterB and RouterC import static routes using a
dynamic routing protocol and have different costs for these static routes. After the configuration
is complete, RouterA can use the dynamic routing protocol to learn routes destined for users
from RouterB and RouterC. RouterA uses the link related to the static route with a lower cost
as the active link and the other link as the standby link.
NQA for static routes is configured on RouterB. NQA tests are performed to check the active
link of RouterB SwitchA SwitchC (SwitchD). If the active link fails, the corresponding
static route is deleted from the routing table, and traffic diverts to the standby link of RouterC
SwitchB SwitchC (SwitchD). If both links work properly, traffic travels along the active
link.

Routers
Figure 2-1 Networking to apply NQA for static routes
IP Network
Router
A
RouterB RouterC
SwitchA SwitchB
......
SwitchC SwitchD
...... ......
Client 1 Client10 Client91 Client100
2.2.4 Permanent Advertisement of Static Routes

Permanent advertisement of static routes provides a low-cost and simple link detection
mechanism and improves compatibility between Huawei devices and non-Huawei devices. If
service traffic needs to be forwarded along a specified path, you can ping the destination
addresses of static routes to detect the link connectivity.
Link connectivity determines the stability and availability of a network. Therefore, link detection
plays an important role in network maintenance. BFD, as a link detection mechanism, is
inapplicable to certain scenarios. For example, a simpler and more natural method is required
for link detection between different ISPs.
After permanent advertisement of static routes is configured, the static routes that cannot be
advertised are still preferred and are added to the routing table in the following cases:
l If an outbound interface configured with an IP address is specified for a static route, the
static route is always preferred and added to the routing table regardless of whether the
outbound interface is Up or Down.

Routers
l If no outbound interface is specified for a static route, the static route is always preferred
and added to the routing table regardless of whether the static route can be iterated to an
outbound interface.
In this way, you can enable IP packets to be always forwarded through this static route. The
permanent advertisement mechanism provides a way for you to monitor services and detect link
connectivity.
NOTICE
A device enabled with this feature always stores static routes in its IP routing table, regardless
of whether the static routes are reachable. If a path is unreachable, the corresponding static route
may become a blackhole route.
Applications
In Figure 2-2, BR1, BR2, and BR3 belong to ISP1, ISP2, and ISP3 respectively. Between BR1
and BR2 are two links, Link A and Link B. ISP1, however, requires that service traffic be
forwarded to ISP2 over Link A without traveling through ISP3.
Figure 2-2 Networking for applying permanent advertisement of static routes
ISP2
BR2
10.1.1.2/24
LinkA
BR1
ISP1
LinkB BR3
ISP3
The External Border Gateway Protocol (EBGP) peer relationship is established between BR1
and BR2. For service monitoring, a static route destined for the BGP peer (BR2) at 10.1.1.2/24
is configured on BR1, and permanent advertisement of static routes is enabled. The interface
that connects BR1 to BR2 is specified as the outbound interface of the static route. Then, the
network monitoring system periodically pings 10.1.1.2 to determine the status of Link A.
If Link A works properly, ping packets are forwarded over Link A. If Link A becomes faulty,
although service traffic can reach BR2 over Link B, the static route is still preferred because
permanent advertisement of static routes is enabled. Therefore, ping packets are still forwarded
over Link A, but packet forwarding fails. This scenario is also applicable to BGP packets. That

Routers
is, a link fault causes the BGP peer relationship to be interrupted. The monitoring system detects
service faults as returned in the ping result and prompts maintenance engineers to rectify the
faults before services are affected.
2.3 Applications
This section describes the applicable scenario of Static Routes.
2.3.1 Load Balancing and Route Backup
Load Balancing Among Static Routes

To implement load balancing, specify the same preference for multiple routes to the same
destination.
Figure 2-3 Load Balancing Among Static Routes

RouterB
Preference=60
Preference=60
RouterA RouterC
RouterD
As shown in Figure 2-3, there are two static routes with the same preference from RouterA to
RouterC. The two routes are stored in the routing table and used to forward data.
Route Backup
To implement route backup, specify different preferences for multiple routes to the same
destination.

Routers
Figure 2-4 Route backup

RouterB
Preference=60
Preference=100
RouterA RouterC
RouterD
As shown in Figure 2-4, there are two static routes with different preferences from RouterA to
RouterC. Static route B with next hop RouterB has a higher preference. The link that static route
B belongs to functions as the active link. Static route D with next hop RouterD has a lower
preference. The link that static route D belongs to functions as the standby link.
l In normal situations, static route B is activated, and the active link forwards data. Static
route D is not shown in the routing table.
l If a fault occurs on the active link, static route B is deleted from the routing table. Static
route D is activated, and the standby link forwards data.
l When the active link restores, static route B is activated again, and the active link forwards
data. Static route D is deleted from the routing table and functions as the backup route.
Static route D is also called a floating static route.
2.3.2 Application of the Static Default Route

When the destination IP address is set to all 0s, a default route is configured. The default route
can be automatically generated by a routing protocol or manually configured. The default route
manually configured simplifies network configuration. If the destination address of a packet
fails to match any entry in the routing table, the router selects the default route to forward the
packet.
Figure 2-5 Networking diagram of static routes
2 RouterB 4
1 5
RouterA RouterC

Routers
As shown in Figure 2-5, if no static default route is configured, you need to configure static
routes destined for networks 3, 4, and 5 on RouterA, configure static routes destined for networks
1 and 5 on RouterB, and configure static routes destined for networks 1, 2, and 3 on RouterC.
In this way, RouterA, RouterB, and RouterC can communicate with each other.
The next hop of the packets sent by RouterA to networks 3, 4, and 5 is RouterB. Therefore, a
default route configured on RouterA can replace the three static routes destined for networks 3,
4, and 5 in the preceding example. Similarly, only a default route from RouterC to RouterB can
replace the three static routes destined for networks 1, 2, and 3 in the preceding example.

On a network, you can accurately control route selection by configuring static routes. If other
static route functions are required, configure them according to reference sections.
Table 2-1 describes the static route configuration tasks.
Table 2-1 Static route configuration tasks
Scenario Description Task
Configuring static routes Static routes are manually l 2.6.1 Configuring IPv4
configured by the Static Routes
administrator to ensure l 2.6.4 Configuring IPv6
normal working of simple Static Routes
networks and bandwidth for
important network
applications.

Routers
Configuring other protocols In actual networking, static l 2.6.2 Configuring Static

for static routes routes are associated with BFD for IPv4 Static
other protocols to improve Routes
network performance. l 2.6.3 Associating IPv4
l BFD for static routes: Static Routes with NQA
Unlike dynamic routing
protocols, static routes do
not have the detection
mechanism. If a fault
occurs on the network, the
administrator needs to
handle it. BFD for static
routes enables a BFD
session to detect the link
status of the static route
and performs fault
detection at millisecond
level.
l Network Quality
Analysis (NQA) for static
routes: In actual
networking, link status
must be detected in real
time to ensure network
stability, and a link
switchover can be
performed according to
link status changes. ARP
and BFD are used to
detect link status. In
addition, IGP
convergence can also be
used. However, the
preceding solutions are
not applicable to the
following special
scenarios:
If only one link rather
than links of every
user on the network
needs to be detected,
ARP detection is not
applicable.
If any device on the
network does not
support BFD, BFD

Routers
detection cannot be
implemented.
If either end of the link
is a Layer 2 device,
dynamic routing
protocols cannot be
configured and
therefore IGP
convergence cannot
be implemented.
NQA for static routes
only requires one end of
the interconnected
devices to support NQA
and can be used even if
there are Layer 2 devices.
The preceding problems
are solved. When a link is
faulty, an NQA test
instance can immediately
detect the link change and
delete the static route
associated with the NQA
test instance from the IP
routing table, affecting
traffic forwarding.
2.5 Default Configuration of Static Routes

This section describes the default configuration of static routes, which can be changed according
Table 2-2 describes the default configuration of static routes.
Table 2-2 Default configuration of static routes
Parameter Default Setting
Preference of static routes 60
2.6 Configuring Static Routes

Static routes are applicable to the networks with simple structures. Proper configuration and
usage of static routes improve the network performance and meet the bandwidth requirement of
important applications.

Routers
2.6.1 Configuring IPv4 Static Routes

On a network, you can accurately control route selection by configuring IPv4 static routes.
Pre-configuration Tasks
Before configuring IPv4 static routes, complete the following task:
l Configuring link layer parameters and IP addresses for interfaces to ensure network-layer
communication between neighbor nodes
Configuration Procedures
You can perform the following configuration tasks (excluding the task of Checking the
Configuration) in any sequence as required.
2.6.1.1 Creating IPv4 Static Routes
Context
When creating static routes, you can specify both the outbound interface and next hop.
Alternatively, you can specify only the outbound interface or next hop based on the outbound
interface type.
l Specify the outbound interface for P2P interfaces.
l Specify the next hop for non broadcast multiple access (NBMA) interfaces.
l Specify the next hop for broadcast interfaces (for example, Ethernet interfaces) and virtual
template interfaces.
If you specify the same preference for static routes to the same destination, you can implement
load balancing among these routes. If you specify different preferences for static routes, you can
implement route backup among the routes.
If the destination IP address and mask are set to all 0s, an IPv4 static default route is configured.
By default, no IPv4 static default route is configured.
Procedure
Step 1 Run:
system-view
The system view is displayed.

Step 2 Configure IPv4 static routes.
l Run:
ip route-static ip-address { mask | mask-length } { nexthop-address | interface-
type interface-number [ nexthop-address ] | vpn-instance vpn-instance-name
nexthop-address } [ preference preference | tag tag ] * [ description text ]
Or:
ip route-static ip-address { mask | mask-length } interface-type interface-
number [ nexthop-address ] [ preference preference | tag tag ] * ldp-sync
[ description text ]

Routers
An IPv4 static route is configured on the public network.

l Run:
ip route-static vpn-instance vpn-source-name destination-address { mask | mask-
length } { nexthop-address [ public ] | interface-type interface-number
[ nexthop-address ] | vpn-instance vpn-instance-name nexthop-address }
[ preference preference | tag tag ] * [ description text ]
Or:
ip route-static vpn-instance vpn-source-name destination-address { mask | mask-
length } interface-type interface-number [ nexthop-address ] [ preference
preference | tag tag ] * ldp-sync [ description text ]
An IPv4 static route is configured in a VPN instance.

NOTE
To implement load balancing among an Ethernet interface's static route and other static routes, configure
the outbound interface and next hop.
----End
2.6.1.2 (Optional) Setting the Default Preference for IPv4 Static Routes
Context
The default preference of IPv4 static routes affects route selection. When an IPv4 static route is
configured, the default preference is used if no preference is specified for the static route.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip route-static default-preference preference
The default preference of static routes is set.
By default, the preference of static routes is 60.
NOTE
After the default preference is reconfigured, the new default preference is valid only for new IPv4 static
routes.
----End
2.6.1.3 (Optional) Configuring Static Route Selection Based on Iteration Depth
Context
Route iteration refers to the process of finding the directly-connected outbound interface based
on the next hop of a route. The iteration depth indicates the number of times the system searches
for routes. A smaller number of route iterations indicates a smaller iteration depth.

Routers
When there are multiple static routes with the same prefix but different iteration depths, the
system selects the static route with the smallest iteration depth as the active route and delivers
it to the FIB table after static route selection based on iteration depth is configured. The other
static routes then become inactive. A smaller iteration depth indicates a more stable route.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip route-static selection-rule relay-depth
Static route selection based on iteration depth is configured.
By default, static routes are not selected based on iteration depth.
----End
2.6.1.4 (Optional) Configuring Permanent Advertisement of IPv4 Static Routes
Context
Link connectivity directly affects network stability and availability. Monitoring link status is an
important measure for network maintenance. If service traffic needs to be forwarded along a
specified path, you can monitor the status of the path using a ping operation. In this manner, you
can monitor services at a very low cost.
With permanent advertisement of static routes, you can detect link connectivity by pinging the
destination addresses of static routes. After permanent advertisement of static routes is
configured, static routes always take effect regardless of the outbound interface status. In this
case, the system forwards ping packets along a specified path only, which helps monitor the link
status of the path.
Procedure
Step 1 Run:
system-view
Step 2 Run:
type interface-number [ nexthop-address ] | vpn-instance vpn-instance-name nexthop-
address } permanent
Permanent advertisement of IPv4 static routes is configured.
By default, permanent advertisement of IPv4 static routes is not configured.
----End

Routers
2.6.1.5 Checking the Configuration
Procedure
l Run the display ip routing-table command to check brief information about the IPv4
routing table.
l Run the display ip routing-table verbose command to check detailed information about
the IPv4 routing table.
----End
2.6.2 Configuring Static BFD for IPv4 Static Routes

Static BFD for IPv4 static routes enables a device to rapidly detect changes of a link to a
destination address of a stack route, improving network reliability.
Before configuring static BFD for IPv4 static routes, complete the following tasks:
l Configuring link layer parameters and IP addresses for interfaces to ensure network-layer
communication between neighbor nodes
l Configuring BFD sessions
For details, see "BFD Configuration" in the Huawei AR150&200&1200&2200&3200
Series Enterprise Routers - Configuration Guide - Reliability.
Procedure
Step 1 Run:
system-view
Step 2 Run:
type interface-number [ nexthop-address ] } [ preference preference | tag tag ] *
track bfd-session cfg-name [ description text ]
A public network static IPv4 route is bound to a BFD session.
NOTE
Before binding a static route to a BFD session, ensure that the BFD session and the static route reside on
the same link.
----End
Checking the Configuration

Run the following commands to check the previous configuration.
l Run the display bfd session all [ verbose ] command to check information about the BFD
session.

Routers
l Run the display current-configuration | include bfd command to check the configuration
of BFD for static routes.
2.6.3 Associating IPv4 Static Routes with NQA

If devices do not support BFD, associate IPv4 static routes with NAQ so that NQA test instances
can monitor the link status to improve network reliability.
Before associating IPv4 static routes with NQA, complete the following task:
l Configuring link layer parameters for interfaces to ensure that the link layer protocol on
the interfaces is Up
Procedure
Step 1 Configure an NQA ICMP test instance.
1. Run:
system-view

2. Run:
nqa test-instance admin-name test-name
An NQA test instance is created, and the view of the test instance is displayed.
3. Run:
test-type icmp
The test type is set to ICMP.
NOTE
When a static route is associated with an NQA test instance, only ICMP test instances are used to
test whether there are reachable routes between the source and destination.
4. Run:
destination-address ipv4 ip-address
The destination address is set.
In an NQA test instance, you can specify an NQA server by running the destination-
address command to configure a destination address for the NQA test instance.
5. (Optional) Run:
frequency interval
The interval for automatically performing an NQA test is set.
By default, no interval is set, that is, only one test is performed.

6. (Optional) Run:
probe-count number
The number of probes to be sent each time is set for the NQA test instance.
By default, the number of probes is 3.

Routers
By sending probes multiple times in an NQA test instance, you can accurately estimate
network quality based on the collected statistics.
7. Run:
start
The NQA test instance is started.
The start command can configure an NQA test instance to be started immediately, at a
specified time, or after a specified delay. You can perform one of the following operations
as required:
l Run:
start now [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay { seconds second |
hh:mm:ss } | lifetime { seconds second | hh:mm:ss } } ]
The NQA test instance is started immediately.

l Run:
start at [ yyyy/mm/dd ] hh:mm:ss [ end { at [ yyyy/mm/dd ] hh:mm:ss |
delay { seconds second | hh:mm:ss } | lifetime { seconds second |
hh:mm:ss } } ]
The NQA test instance is started at a specified time.

l Run:
start delay { seconds second | hh:mm:ss } [ end { at [ yyyy/mm/dd ]
hh:mm:ss | delay { seconds second | hh:mm:ss } | lifetime { seconds second
| hh:mm:ss } } ]
The NQA test instance is started after a specified delay.

8. Run:
quit
Return to the system view.
Step 2 Associate static routes with an NQA test instance.

1. Run:
type interface-number [ nexthop-address ] } [ preference preference | tag
tag ] * track nqa admin-name test-name [ description text ]
IPv4 static routes are associated with an NQA test instance.
NOTE
The destination address of an NQA test instance cannot be the destination address of an associated
static route.
If the static route associated with an NQA test instance is associated with another NQA test instance,
the static route is disassociated from the first NQA test instance.
----End

After IPv4 static routes are associated with NAQ, run the following commands to check the
configuration.
l Run the display current-configuration | include nqa command to check the configuration
of association between static routes and NQA.

Routers
l Run the display nqa results [ collection ] [ test-instance admin-name test-name ]

command to check the NQA test result.
The NQA test result cannot be displayed automatically. You must run the display nqa
results command to view the NQA test result. By default, the command output shows the
results of the latest five NQA tests.
2.6.4 Configuring IPv6 Static Routes

On a network, you can accurately control route selection by configuring IPv6 static routes.
Before configuring IPv6 static routes, complete the following task:
l Configuring link layer parameters and IPv6 addresses for interfaces to ensure network-
layer communication between neighbor nodes
2.6.4.1 Creating IPv6 Static Routes
Context
When creating static routes, you can specify both the outbound interface and next hop.
Alternatively, you can specify only the outbound interface or next hop based on the outbound
interface type.
l Specify the outbound interface for P2P interfaces.
l Specify the next hop for NBMA interfaces.
l Specify the outbound interface for broadcast interfaces. If the next hop address is also
specified, it does not need to be a link-local address.
If you specify the same preference for static routes to the same destination, you can implement
load balancing among these routes. If you specify different preferences for the static routes, you
can implement route backup among the routes.
If the destination IP address and mask are set to all 0s, an IPv6 static default route is configured.
By default, no IPv6 static default route is configured.
Procedure
Step 1 Run:
system-view

l Run:

Routers
ipv6 route-static dest-ipv6-address prefix-length { interface-type interface-

number [ nexthop-ipv6-address ] | nexthop-ipv6-address } [ preference
preference | tag tag ] * [ description text ]
An IPv6 static route is configured on the public network.

l Run:
ipv6 route-static vpn-instance vpn-instance-name dest-ipv6-address prefix-
length { [ interface-type interface-number ] nexthop-ipv6-address | nexthop-
ipv6-address [ public ] | vpn-instance vpn-destination-name nexthop-ipv6-
address } [ preference preference | tag tag ] * [ description text ]
An IPv6 static route is configured in a VPN instance.

NOTE
To implement load balancing among an Ethernet interface's static route and other static routes, configure
the outbound interface and next hop.
----End
2.6.4.2 (Optional) Setting the Default Preference for IPv6 Static Routes
Context
The default preference of IPv6 static routes affects route selection. When an IPv6 static route is
configured, the default preference is used if no preference is specified for the static route.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 route-static default-preference preference
The default preference of IPv6 static routes is set.
By default, the preference of static routes is 60.
After the default preference is reconfigured, the new default preference is valid only for new
IPv6 static routes.
----End
Procedure
l Run the display ipv6 routing-table command to check brief information about the IPv6
routing table.
l Run the display ipv6 routing-table verbose command to check detailed information about
----End

Routers

This section provides configuration examples of static routes. Configuration examples explain
networking requirements, networking diagram, configuration notes, configuration roadmap, and
configuration procedure.
2.7.1 Example for Configuring IPv4 Static Routes
Networking Requirements
Hosts on different network segments are connected using several Routers. Each two hosts on
different network segments can communicate with each other without using dynamic routing
protocols.
Figure 2-6 Networking diagram of configuring IPv4 static routes
PC2
1.1.2.2/24
GE3/0/0
1.1.2.1/24
GE1/0/0 GE2/0/0
1.1.4.2/30 1.1.4.5/30
RouterB
RouterA RouterC
GE1/0/0 GE1/0/0
1.1.4.1/30 1.1.4.6/30
GE2/0/0 GE2/0/0
1.1.1.1/24 1.1.3.1/24
PC1 PC3
1.1.1.2/24 1.1.3.2/24
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure IPv4 addresses for interfaces so that directly-connected interfaces can

communicate with each other.
2. Configure the default IPv4 gateway on each host, and configure IPv4 static routes and
default routes on each Router so that hosts on different network segments can communicate
with each other.

Routers
Procedure
Step 1 Configure IP addresses for interfaces on each Router.
# Configure an IP address for each interface on RouterA.

[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.4.1 30
The configurations of RouterB and RouterC are similar to the configuration of RouterA, and are
not mentioned here.
Step 2 Configure static routes.
# Configure an IPv4 default route on RouterA.

[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.4.2
# Configure two IPv4 static routes on RouterB.

[RouterB] ip route-static 1.1.1.0 255.255.255.0 1.1.4.1
# Configure an IPv4 default route on RouterC.

[RouterC] ip route-static 0.0.0.0 0.0.0.0 1.1.4.5
Step 3 Configure hosts.
Set default gateway addresses of PC1, PC2, and PC3 to 1.1.1.1, 1.1.2.1, and 1.1.3.1 respectively.
Step 4 Verify the configuration.
# Check the IP routing table of RouterA.

[RouterA] display ip routing-table
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 RD 1.1.4.2 GigabitEthernet1/0/0
# Run the ping command to verify the connectivity.

[RouterA] ping 1.1.3.1
PING 1.1.3.1: 56 data bytes, press CTRL_C to break
Reply from 1.1.3.1: bytes=56 Sequence=1 ttl=254 time=62 ms
--- 1.1.3.1 ping statistics ---
5 packet(s) transmitted

Routers
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 62/62/63 ms
# Run the tracert command to verify the connectivity.

[RouterA] tracert 1.1.3.1
traceroute to 1.1.3.1(1.1.3.1), max hops: 30 ,packet length: 40,press CTRL_C to
break
1 1.1.4.2 31 ms 32 ms 31 ms
2 1.1.4.6 62 ms 63 ms 62 ms
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
interface GigabitEthernet2/0/0
ip address 1.1.1.1 255.255.255.0
#
ip address 1.1.4.1 255.255.255.252
#
ip route-static 0.0.0.0 0.0.0.0 1.1.4.2
#
return
l Configuration file of RouterB

#
sysname RouterB
#
ip address 1.1.4.2 255.255.255.252
#
ip address 1.1.4.5 255.255.255.252
#
ip address 1.1.2.1 255.255.255.0
#
ip route-static 1.1.1.0 255.255.255.0 1.1.4.1
ip route-static 1.1.3.0 255.255.255.0 1.1.4.6
#
return
l Configuration file of RouterC

#
sysname RouterC
#
ip address 1.1.3.1 255.255.255.0
#
ip address 1.1.4.6 255.255.255.252
#
ip route-static 0.0.0.0 0.0.0.0 1.1.4.5
#
return

Routers
2.7.2 Example for Configuring IPv6 Static Routes
Networking requirements
On an IPv6 network, hosts on different network segments are connected using several Routers.
Each two hosts on different network segments can communicate with each other without using
dynamic routing protocols.
Figure 2-7 Networking diagram of configuring IPv6 static routes
PC2
2::2/64
GE0/0/0
2::1/64
GE1/0/0 GE2/0/0
10::2/64 20::1/64
RouterB
GE1/0/0 GE1/0/0
10::1/64 20::2/64
RouterA RouterC
GE2/0/0 GE2/0/0
1::1/64 3::1/64
PC1 PC3
1::2/64 3::2/64
1. Configure IPv6 addresses for interfaces so that devices can communicate with each other.
2. Configure the IPv6 default gateway on each host, and configure IPv6 static routes and
default routes on each Router so that hosts on different network segments can communicate
with each other.
Procedure
Step 1 Configure IPv6 addresses for interfaces on each Router.
# Configure IPv6 addresses for interfaces on RouterA.

[RouterA] ipv6
[RouterA-GigabitEthernet1/0/0] ipv6 enable
[RouterA-GigabitEthernet1/0/0] ipv6 address 10::1/64

Routers
[RouterA-GigabitEthernet1/0/0] ipv6 address 1::1/64
not mentioned here.
# Configure an IPv6 default route on RouterA.
[RouterA] ipv6 route-static :: 0 gigabitethernet 1/0/0 10::2
# Configure two IPv6 static routes on RouterB.

[RouterB] ipv6 route-static 1:: 64 gigabitethernet 1/0/0 10::1
[RouterB] ipv6 route-static 3:: 64 gigabitethernet 2/0/0 20::2
# Configure an IPv6 default route on RouterC.

[RouterC] ipv6 route-static :: 0 gigabitethernet 1/0/0 20::1
Step 3 Configure host addresses and gateways.

Configure IPv6 addresses for hosts according to the networking diagram, and set default gateway
addresses of PC1, PC2, and PC3 to 1::1, 2::1, and 3::1 respectively.
# Check the IPv6 routing table of RouterA.
[RouterA] display ipv6 routing-table
Routing Table : Public
Destination : :: PrefixLength : 0
NextHop : 10::2 Preference : 60
Cost : 0 Protocol : Static
RelayNextHop : :: TunnelID : 0x0
Interface : GigabitEthernet1/0/0 Flags : D
Destination : ::1 PrefixLength : 128

NextHop : ::1 Preference : 0
Cost : 0 Protocol : Direct
Interface : InLoopBack0 Flags : D
Destination : 1:: PrefixLength : 64

NextHop : 1::1 Preference : 0
Destination : 1::1 PrefixLength : 128

NextHop : ::1 Preference : 0
Destination : FE80:: PrefixLength : 10

NextHop : :: Preference : 0
Interface : NULL0 Flags : D
# Run the ping command to verify the connectivity.

[RouterA] ping ipv6 3::1
PING 3::1 : 56 data bytes, press CTRL_C to break

Routers
Reply from 3::1

bytes=56 Sequence=1 hop limit=254 time = 63 ms
Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1
--- 3::1 ping statistics ---
0.00% packet loss
# Run the tracert command to verify the connectivity.

[RouterA] tracert ipv6 3::1
traceroute to 3::1 30 hops max,60 bytes packet
1 FE80::E0:FCD5:86D4:401 11 ms 3 ms 4 ms
2 3::1 4 ms 3 ms 3 ms
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
ipv6 address 10::1/64
#
ipv6 enable
#
ipv6 route-static :: 0 GigabitEthernet1/0/0 10::2
#
return

#
sysname RouterB
#
ipv6
#
ipv6 enable
#
ipv6 enable
#
ipv6 enable
#
ipv6 route-static 1:: 64 GigabitEthernet1/0/0 10::1
ipv6 route-static 3:: 64 GigabitEthernet2/0/0 20::2
#

Routers
return

#
sysname RouterC
#
ipv6
#
ipv6 enable
#
ipv6 enable
#
ipv6 route-static :: 0 GigabitEthernet1/0/0 20::1
#
return
2.7.3 Example for Configuring BFD for IPv4 Static Routes
As shown in Figure 2-8, RouterA is connected to RouterB through SwitchC. You need to
configure static routes on RouterA so that RouterA can communicate with the external network.
Link fault detection between RouterA and RouterB must be at the millisecond level to improve
convergence speed.
Figure 2-8 Networking diagram of configuring static BFD for IPv4 static routes
GE1/0/0 GE1/0/0 GE2/0/0

1.1.1.1/24 1.1.1.2/24 2.2.2.2/24
Internet
RouterA SwitchC RouterB
1. Configure IP addresses for interfaces so that devices can communicate with each other.
2. Configure a BFD session between RouterA and RouterB.
3. Configure a default static route from RouterA to the external network and bind the default
static route to the BFD session. This configuration can implement link fault detection at
the millisecond level and improve convergence speed of static routes.
Procedure
Step 1 Configure IP addresses for interfaces on each Router.
# Configure IP addresses for interfaces on RouterA.

[RouterA-GigabitEthernet1/0/0] quit

Routers
The configuration of Router B is similar to the configuration of Router A, and is not mentioned
here.
Step 2 Configure a BFD session between RouterA and RouterB.
# Configure a BFD session on RouterA.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd aa bind peer-ip 1.1.1.2
[RouterA-bfd-session-aa] discriminator local 10
[RouterA-bfd-session-aa] discriminator remote 20
[RouterA-bfd-session-aa] commit
[RouterA-bfd-session-aa] quit
# Configure a BFD session on RouterB.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd bb bind peer-ip 1.1.1.1
[RouterB-bfd-session-bb] discriminator local 20
[RouterB-bfd-session-bb] discriminator remote 10
[RouterB-bfd-session-bb] commit
[RouterB-bfd-session-bb] quit
Step 3 Configure a default static route and bind it to a BFD session.
# Configure a default static route to the external network on RouterA and bind it to a BFD session
named aa.
[RouterA] ip route-static 0.0.0.0 0 1.1.1.2 track bfd-session aa
# After the configuration is complete, run the display bfd session all command on RouterA and
RouterB. The command output shows that a BFD session has been established and is in Up state.
Then, run the display current-configuration | include bfd command in the system view. The
command output shows that the default static route has been bound to the BFD session.
Take the display on RouterA as an example.

[RouterA] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
10 20 1.1.1.2 Up S_IP_PEER -
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
[RouterA] display current-configuration | include bfd
bfd
bfd aa bind peer-ip 1.1.1.2
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 track bfd-session aa
# Check the IP routing table of RouterA. The command output shows that the static route exists
in the routing table.
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 RD 1.1.1.2 GigabitEthernet1/0/0

Routers
# Run the shutdown command on GE1/0/0 of RouterB to simulate a link fault.

[RouterB] interface gigabitEthernet 1/0/0
[RouterB-GigabitEthernet1/0/0] shutdown
# Check the IP routing table of RouterA. The command output shows that default route 0.0.0.0/0
does not exist. This is because the default static route is bound to a BFD session. When BFD
detects a link fault, BFD rapidly notifies that the bound static route becomes unavailable. If the
static route is not bound to a BFD session, the default route 0.0.0.0/0 will always exist in IP
routing table; however, this may cause traffic loss.
------------------------------------------------------------------------------
----End
Configuration Files
#
sysname RouterA
#
bfd
#
ip address 1.1.1.1 255.255.255.0
#
bfd aa bind peer-ip 1.1.1.2
discriminator local 10
discriminator remote 20
commit
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 track bfd-session aa
#
return

sysname RouterB
#
bfd
#
ip address 1.1.1.2 255.255.255.0
#
ip address 2.2.2.2 255.255.255.0
#
bfd bb bind peer-ip 1.1.1.1
commit
#
return

Routers
2.7.4 Example for Configuring NQA for IPv4 Static Routes
As shown in Figure 2-9, multiple static routes are configured on RouterA so that packets can
be forwarded from RouterA to users. To improve link reliability when access switches do not
support BFD, customers require that packets sent from RouterA be transmitted along the primary
link RouterARouterBSwitchUser when the primary link is working properly. When the
primary link fails, the packets can be switched to the backup link RouterARouterCSwitch
User for forwarding.
Figure 2-9 Networking diagram of configuring NQA for IPv4 static routes
RouterA
GE1/0/0 GE2/0/0
172.16.3.1/24 172.16.4.1/24
GE2/0/0 GE2/0/0
172.16.3.2/24 172.16.4.2/24
RouterB RouterC
0/0
GE1/0/0 GE 3/ 4 GE1/0/0
1 3/0 GE .1/2
172.16.1.1/24 72 /0 6 .6 172.16.2.1/24
.16 2.1
.5. 17
1/2
4 17 VLA
2.1 NI
VLANIF10 6.5 F20
.2/ VLANIF10
172.16.1.2/24 0 24
IF2 2/24 172.16.2.2/24
AN 6.
VL 2.16. ......
VALNIF30 17
172.16.7.1/24 SwitchA SwitchB
...... ......
Client1 Client10 Client91 Client100
Primary link
Backup link
To improve link reliability, a link detection mechanism needs to be deployed on the device to
detect the link status in real time and then the detected link status is associated with the route
status. Access switches do not support BFD. You can associate IPv4 static routes with NQA to
meet this link reliability requirement. The configuration roadmap is as follows:
1. On RouterA, RouterB, and RouterC, configure IP addresses for interfaces and configure
static routes to Client1 (Client1 is used to represent users). Two static routes must be
configured on RouterA, and the static route with next hop RouterB must have a higher

Routers
priority than the static route with next hop RouterC so that packets sent from RouterA to
Client1 can be transmitted according to the two primary and backup static routes.
2. Configure an ICMP NQA test instance on the primary link from RouterA to SwitchA and
associate the static route of which the next hop is RouterB with the ICMP NQA test instance
to fast detect link faults for service switching.
NOTE
When a static route is associated with an NQA test instance, only ICMP test instances are used to test
whether there are reachable routes between the source and destination.
Procedure
Step 1 Configure IP addresses on Routers.
# Configure IP addresses for interfaces on RouterA.
[RouterA] interface gigabitEthernet 1/0/0
[RouterA] interface gigabitEthernet 2/0/0
not mentioned here.
Step 2 Configure static routes from RouteA, RouterB, and RouterC to Client1.
# On RouterA, configure two static routes to Client1 and set the priority of the static route with
next hop RouterC to 100.
[RouterA] ip route-static 172.16.7.0 255.255.255.0 172.16.4.2 preference 100
# On RouterB, configure a static route to Client1.

# On RouterC, configure a static route to Client1.

Step 3 Configure an NQA test instance on RouterA to test the link between RouterA and SwitchA.
[RouterA] nqa test-instance aa bb
[RouterA-nqa-aa-bb] test-type icmp
[RouterA-nqa-aa-bb] destination-address ipv4 172.16.1.2
[RouterA-nqa-aa-bb] frequency 3
[RouterA-nqa-aa-bb] probe-count 1
[RouterA-nqa-aa-bb] start now
[RouterA-nqa-aa-bb] quit
Step 4 On RouterA, associate the static route of which the next hop is RouterB with the NQA test
instance.
[RouterA] ip route-static 172.16.7.0 255.255.255.0 172.16.3.2 track nqa aa bb

# After the configuration is complete, run the display current-configuration | include nqa
command in the system view on RouterA to check whether the static route has been associated
with the NQA test instance.
[RouterA] display current-configuration | include nqa

Routers
ip route-static 172.16.7.0 255.255.255.0 172.16.3.2 track nqa aa bb

nqa test-instance aa bb
# Run the display nqa results command on RouterA to check the NQA test results. In this
example, information "Lost packet ratio: 0 %" is displayed, indicating that the link works
properly.
[RouterA] display nqa results test-instance aa bb
NQA entry(aa, bb) :testflag is active ,testtype is icmp

1 . Test 1987 result The test is finished
Send operation times: 1 Receive response times: 1
Completion:success RTD OverThresholds number: 0
Attempts number:1 Drop operation number:0
Disconnect operation number:0 Operation timeout number:0
System busy operation number:0 Connection fail number:0
Operation sequence errors number:0 RTT Status errors number:0
Destination ip address:172.16.1.2
Min/Max/Average Completion Time: 120/120/120
Sum/Square-Sum Completion Time: 120/14400
Last Good Probe Time: 2012-01-06 19:14:57.5
Lost packet ratio: 0 %
# Check the routing table on RouterA. The routing table contains a static route with the next hop
172.16.3.2.
------------------------------------------------------------------------------

172.16.3.0/24 Direct 0 0 D 172.16.3.1
GigabitEthernet1/0/0
172.16.3.1/32 Direct 0 0 D 127.0.0.1
172.16.3.255/32 Direct 0 0 D 127.0.0.1
172.16.4.0/24 Direct 0 0 D 172.16.4.1
172.16.4.1/32 Direct 0 0 D 127.0.0.1
172.16.4.255/32 Direct 0 0 D 127.0.0.1
172.16.7.0/24 Static 60 0 D 172.16.3.2
The routing table contains a route destined for 172.16.7.0/24 with next hop 172.16.3.2.
Therefore, traffic travels along the primary link.
# Shut down GE1/0/0 on RouterB to simulate a link fault.

[RouterB] interface GigabitEthernet 1/0/0
[RouterB-GigabitEthernet1/0/0] quit
# Check the NQA test results. Information "Lost packet ratio: 100 %" is displayed, indicating
that the link fails.
[RouterA] display nqa results test-instance aa bb

Routers
NQA entry(aa, bb) :testflag is active ,testtype is icmp

1 . Test 2086 result The test is finished
Send operation times: 1 Receive response times: 0
Completion:failed RTD OverThresholds number: 0
Attempts number:1 Drop operation number:1
Disconnect operation number:0 Operation timeout number:0
System busy operation number:0 Connection fail number:0
Operation sequence errors number:0 RTT Status errors number:0
Destination ip address:172.16.1.2
Min/Max/Average Completion Time: 0/0/0
Sum/Square-Sum Completion Time: 0/0
Last Good Probe Time: 0000-00-00 00:00:00.0
Lost packet ratio: 100 %
# Check the routing table on RouterA.

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

172.16.3.0/24 Direct 0 0 D 172.16.3.1
172.16.3.1/32 Direct 0 0 D 127.0.0.1
172.16.3.255/32 Direct 0 0 D 127.0.0.1
172.16.4.0/24 Direct 0 0 D 172.16.4.1
172.16.4.1/32 Direct 0 0 D 127.0.0.1
172.16.4.255/32 Direct 0 0 D 127.0.0.1
172.16.7.0/24 Static 100 0 D 172.16.4.2
The command output shows that the next hop of the route to destination network segment
172.16.7.0/24 is 172.16.4.2. After NQA detects that primary link fails, NQA notifies RouterA
that the static route to 172.16.7.0/24 becomes unavailable. Packets are then switched to the
backup link for forwarding.
----End
Configuration Files
#
sysname RouterA
#
ip address 172.16.3.1 255.255.255.0
#
ip address 172.16.4.1 255.255.255.0
#
ip route-static 172.16.7.0 255.255.255.0 172.16.3.2 track nqa aa bb
ip route-static 172.16.7.0 255.255.255.0 172.16.4.2 preference 100

Routers
#
nqa test-instance aa bb
test-type icmp
destination-address ipv4 172.16.1.2
frequency 3
probe-count 1
start now
#
return

#
sysname RouterB
#
ip address 172.16.1.1 255.255.255.0
#
ip address 172.16.3.2 255.255.255.0
#
ip address 172.16.5.1 255.255.255.0
#
ip route-static 172.16.7.0 255.255.255.0 172.16.1.2
#
return

#
sysname RouterC
#
ip address 172.16.2.1 255.255.255.0
#
ip address 172.16.4.2 255.255.255.0
#
ip address 172.16.6.1 255.255.255.0
#
ip route-static 172.16.7.0 255.255.255.0 172.16.6.2
#
return
2.8 FAQ
2.8.1 Is the Static Route Affected If the BFD for the Static Route is
in AdminDown State?
The static route is not affected. The static route is invalid only when the BFD detects a link fault.
2.9 References
This section lists references of Static Routes.
None

Routers
Configuration Guide - IP Routing 3 RIP Configuration
3 RIP Configuration
About This Chapter
Routing Information Protocol(RIP) is widely used on small-sized networks to discover routes

and generate routing information.
3.1 Introduction to RIP

This section describes the definition and purpose of RIP.
3.2 Principles
This section describes the implementation of RIP.

After basic RIP functions are configured, you can build a Layer 3 network using the RIP protocol.
If other RIP functions are required, configure them according to reference sections.
3.4 Default Configuration

This section describes the default configuration of RIP, which can be changed according to
network requirements.
3.5 Configuring RIP

RIP is widely used on small-sized networks to discover routes and generate routing information.
3.6 Maintaining RIP

RIP maintenance includes resetting RIP connections and clearing RIP statistics.

This section provides configuration examples of RIP, including networking requirements,
configuration notes, and configuration roadmap.
3.8 Common Configuration Errors

This section describes common faults caused by incorrect RIP configurations and provides the
troubleshooting procedure.
3.9 References
This section lists references of RIP.

Routers
3.1 Introduction to RIP

This section describes the definition and purpose of RIP.
Definition
Routing Information Protocol (RIP) is a simple Interior Gateway Protocol (IGP). RIP is a
Distance-Vector protocol that uses hot count to measure the distance between the local device
and the destination. RIP exchanges routing information using UDP packets on UDP port 520.
Two versions are available for RIP: RIP-1 and RIP-2. RIP-2 is an extension to RIP-1.
Purpose
RIP is easy to implement, and is easier to configure and manage than OSPF and IS-IS. Therefore,
RIP is applicable to small-sized networks, such as campus networks and simple LANs. It is not
suitable for complex environments or large-sized networks.
3.2 Principles
This section describes the implementation of RIP.
3.2.1 Principles
RIP is based on the Distance-Vector (DV) algorithm. RIP uses hop count (HC) to measure the
distance to the destination. The distance is called the metric value. In RIP, the default HC from
a router to its directly connected network is 0, and the HC from a router to a reachable network
through another router is 1, and so on. That is to say, the HC equals the number of routers passed
from the local network to the destination network. To speed up network convergence, RIP
defines the HC as an integer that ranges from 0 to 15. An HC 16 or greater is defined as infinity,
that is, the destination network or the host is unreachable. For this reason, RIP is not applied to
large-scale networks.
RIP Routing Table

When RIP starts on a router, the RIP routing table contains only the routes to the directly
connected interfaces. After neighboring routers on different network segments learn the routing
entries from each other, they can communicate with each other.
Figure 3-1 RIP routing table generation

RouterA RouterB
Request
Reponse

Routers
Figure 3-1 shows the process of RIP routing table generation.

l RIP starts, and then RouterA broadcasts Request packets to neighboring routers.
l When receiving the Request packet, RouterB encapsulates its own RIP routing table into
the Response packet and broadcasts the Response packet to the network segment connected
to the interface receiving the Request packet.
l RouterA generates a routing table based on the Response packet sent from RouterB.
RIP Update and Maintenance

RIP uses four timers to update and maintain routing information:
l Update timer: When this timer expires, a router immediately sends an Update packet.
l Age timer: If a RIP device does not receive an Update packet from a neighbor within the
aging time, the RIP device considers the route unreachable.
l Garbage-collect timer: If a RIP device does not receive an Update packet of an unreachable
route within the timeout interval, the device deletes the routing entry from the RIP routing
table.
l Suppress timer: When a RIP device receives an Update packet with the Cost field being 16
from a neighbor, the route is suppressed and the suppress timer starts. To avoid route
flapping, the RIP device does not accept any Update packet before the suppress timer
expires even if the Cost field in an Update packet is smaller than 16. After the suppress
timer expires, the RIP device accepts new Update packets.
Relationships between RIP routes and timers:
l The interval for sending Update packets is determined by the Update timer, which is 30
seconds by default.
l Each routing entry has two timers: age timer and Garbage-collect timer. When a RIP device
adds a learned route to the local RIP routing table, the age timer starts for the routing entry.
If the RIP device does not receive an Update packet from the neighbor within the age time,
the RIP device sets the Cost value of the route to 16 (unreachable) and starts the Garbage-
collect timer. If the RIP device still does not receive an Update packet within the Garbage-
collect timer, the RIP device deletes the routing entry from the RIP routing table.
Triggered Update
When routing information changes, a device immediately sends an Update packet to its
neighbors, without waiting for Update timer expiration. This function avoids loops.

Routers
Figure 3-2 Triggered update
The network to
11.4.0.0 fails The network to
11.4.0.0 fails
11.1.0.0
E0 11.2.0.0
RouterB
S0 S0 S1
RouterA
RouterC 11.3.0.0
E0 S0
The network to
11.4.0.0 fails
11.4.0.0
As shown in Figure 3-2, RouterC first learns that network 11.4.0.0 is unreachable.
l If RouterC does not support triggered update when detecting a link fault, it has to wait until
the Update timer expires. If RouterC receives an Update packet from RouterB before its
Update timer expires, RouterC learns a wrong route to network 11.4.0.0. In this case, the
next hops of the routes from RouterB or RouterC to network 11.4.0.0 are RouterC and
RouterB respectively. A routing loop is generated.
l If RouterC supports triggered update when detecting a link fault, RouterC immediately
sends an Update packet to RouterB so that a routing loop is prevented.
3.2.2 RIP-2 Enhanced Features

Two versions are available for RIP: RIP-1 and RIP-2. RIP-2 is an extension to RIP-1.
Comparison Between RIP-1 and RIP-2

RIP version 1 (RIP-1) is a classful (as opposed to classless) routing protocol. It supports the
advertisement of protocol packets only in broadcast mode. Figure 3-3 shows the packet format.
The RIP-1 protocol packet does not carry any mask, so it can identify only the routes of the
natural network segment such as Class A, Class B, and Class C, and does not support route
aggregation or discontinuous subnet.
RIP version 2 (RIP-2), is a classless routing protocol. Figure 3-4 shows the packet format.

Routers
Figure 3-3 RIP-1 packet format

0 7 15 31
Header Command Version Must be zero
Address Family Identifier Must be zero
IP Address
Route
Entries Must be zero
Must be zero
Metric
Figure 3-4 RIP-2 packet format

0 7 15 31
Header Command Version Unused
Address Family Identifier Route Tag
IP Address
Route
Subnet Mask
Entries
Next Hop
Metric
Compared with RIP-1, RIP-2 has the following advantages:

l Supports route tag and can flexibly control routes on the basis of the tag in the routing
policy.
l Has packets that contain mask information and support route summarization and Classless
Inter-Domain Routing (CIDR).
l Supports the next hop address and can select the optimal next hop address in the broadcast
network.
l Supports sending update packets in multicast mode. Only RIP-2 routers can receive
protocol packets. This reduces resource consumption.
l Provides packets authentication to enhance security.
RIP-2 Route Summarization

When different subnet routes in the same natural network segment are transmitted to other
network segments, these routes are summarized into one route of the same segment. This process
is called route summarization.
RIP-1 packets do not carry mask information, so RIP-1 can advertise only the routes with natural
masks. Because RIP-2 packets carry mask information, RIP-2 supports subnetting. RIP-2 route
summarization improves extensibility and efficiency and minimizes the routing table size of a
large-sized network.

Routers
Route summarization is classified into two types:
l RIP process-based classful summarization

Summarized routes are advertised using nature masks. For example, route 10.1.1.0/24
(metric=2) and route 10.1.2.0/24 (metric=3) are summarized as a route 10.0.0.0/8
(metric=2) in the natural network segment. RIP-2 supports classful summarization to obtain
the optimal metric.
l Interface-based summarization
A user can specify a summarized address. For example, a route 10.1.0.0/16 (metric=2) can
be configured on the interface as a summarized route of route 10.1.1.0/24 (metric=2) and
route 10.1.2.0/24 (metric=3).
3.2.3 Split Horizon and Poison Reverse
Split Horizon
Split horizon ensures that a route learned by RIP on an interface is not sent to neighbors from
the interface. This feature reduces bandwidth consumption and avoids routing loops.
Split horizon provides two models for different networks: interface-based split horizon and
neighbor-based split horizon. Broadcast, P2P, and P2MP networks use interface-based split
horizon, as shown in Figure 3-5.
Figure 3-5 Interface-based split horizon
10.0.0.0/8
RouterA RouterB
RouterA sends routing information destined for 10.0.0.0/8 to RouterB. If split horizon is not
configured, RouterB sends the route learned from RouterA back to RouterA. Thus RouterA can
learn two routes destined for 10.0.0.0/8: a direct route with hop count 0 and a route with the next
hop RouterB and hop count 2.
However, only the direct route in the RIP routing table on RouterA is active. When the route
from RouterA to network 10.0.0.0 is unreachable, RouterB does not receive the unreachable
message immediately and still notifies RouterA that network 10.0.0.0/8 is reachable. Therefore,
RouterA receives incorrect routing information that network 10.0.0.0/8 is reachable through
RouterB, and RouterB considers that network 10.0.0.0/8 is reachable through RouterA. A routing
loop is thus generated. With the split horizon feature, RouterB does not send the route destined
for 10.0.0.0/8 back to RouterA. Routing loops are avoided.
On a Non-Broadcast Multiple Access (NBMA) network, an interface connects to multiple

neighbors; therefore, split horizon is performed based on neighbors. Routes are advertised in
unicast mode. The routes received by an interface are differentiated by neighbors. The route
learned from a neighbor is not sent back through the same interface.

Routers
Figure 3-6 Neighbor-based split horizon
10.0.0.0/8 20.0.0.0/8
RouterA RouterB
RouterC
As shown in Figure 3-6, after split horizon is configured on an NBMA network, RouterA sends
route 20.0.0.0/8 learned from RouterB to RouterC, but does not send it to RouterB.
Poison Reverse
Poison reverse ensures that RIP sets the cost of the route learned from an interface of a neighbor
to 16 (unreachable) and then sends the route from the same interface back to the neighbor. This
feature deletes useless routes from the routing table and avoids routing loops.
Figure 3-7 Poison reverse
10.0.0.0/8
RouterA RouterB
As shown in Figure 3-7, after receiving a route from RouterA, RouterB sends an unreachable
message (with the route Cost being 16) to RouterA. RouterA then does not learn the route from
RouterB. A routing loop is avoided.
3.2.4 Multi-process and Multi-instance

The multi-process feature associates a RIP process with multiple interfaces, ensuring that the
specific process performs all the protocol-related operations only on these interfaces. With the
multi-process feature, multiple RIP processes can run on a device independently. Route
exchange between RIP processes is similar to route exchange between routing protocols.
RIP multi-instance associates a VPN instance with a RIP process so that the VPN instance can
be associated with all interfaces on this process.

Routers
3.2.5 BFD for RIP

A link fault or topology change causes routers to recalculate routes. Therefore, route convergence
must be quick enough to ensure network performance. A solution to speed up route convergence
is to quickly detect faults and notify routing protocols of the faults.
Bidirectional Forwarding Detection (BFD) detects faults on links between neighboring routers.
Associated with a routing protocol, BFD can rapidly detect link faults and report the faults to
the protocol so that the protocol quickly triggers route convergence. Traffic loss caused by
topology changes is minimized. After RIP is associated with BFD, BFD rapidly detects link
faults and reports the faults to RIP so that RIP quickly responds to network topology changes.
Table 3-1 lists the link fault detection mechanisms and convergence speed before and after BFD
is associated with RIP.
Table 3-1 BFD speeds up convergence
RIP and BFD Link Fault Detection Mechanism Convergence

Association Speed
Feature
Disabled The RIP age timer expires. By default, the Second-level (> 180
timeout interval is 180 seconds. seconds)
Enabled The BFD session goes Down. Second-level (< 30

seconds)
Principle
BFD is classified into static BFD and dynamic BFD:
l Static BFD
In static BFD, BFD session parameters (including local and remote discriminators) are set
manually using commands, and BFD session setup requests are manually delivered.
l Dynamic BFD
In dynamic BFD, BFD session setup is triggered by routing protocols. The local
discriminator is dynamically allocated and remote discriminator is obtained from the peer.
A routing protocol notifies BFD of the neighbor parameters (including destination and
source addresses), and then BFD sets up a session based on the received parameters. When
a link fault occurs, the protocol associated with BFD quickly detects that the BFD session
is Down, and switches traffic to the backup link. This feature minimizes data loss.
A device can implement static BFD even if the peer device does not support BFD. Dynamic
BFD is more flexible than static BFD.
Application
After RIP is associated with BFD, BFD reports link faults to RIP within several milliseconds.
The RIP router then deletes the faulty links from the local routing table and starts the backup
link. This feature increases route convergence speed.

Routers
Figure 3-8 RIP and BFD association network

RouterA RouterB RouterD
cost=1
co
0
=1
st
=1
st
co
RouterC
Implementation of RIP and BFD association:
l As shown in Figure 3-8, RouterA, RouterB, RouterC, and RouterD set up RIP neighbor
relationships. RouterB is the next hop on the route from RouterA to RouterD. RIP and BFD
association is configured on RouterA and RouterB.
l When the link between RouterA and RouterB is faulty, BFD quickly detects the fault and
notify RouterA of the fault. RouterA deletes the route with RouterB as the next hop, and
then recalculates a route. The new route passes RouterC and RouterB and reaches RouterD.
l When the link between RouterA and RouterB recovers, a session is set up again. RouterA
receives routing information from RouterB and selects the optimal route.

After basic RIP functions are configured, you can build a Layer 3 network using the RIP protocol.
If other RIP functions are required, configure them according to reference sections.
Table 3-2 describes the RIP configuration tasks.
Table 3-2 RIP configuration tasks
Configuring basic RIP Basic RIP functions include 3.5.1 Configuring Basic
functions enabling RIP, specifying the RIP Functions
network segment where RIP
runs, and specifying the RIP
version. The basic RIP
functions must be configured
before you use the RIP
features.

Routers
Configuring RIP-2 features RIP-2 is a classless routing 3.5.2 Configuring RIP-2

protocol, and the RIP-2
packets contain subnet
masks. Therefore, deploying
a RIP-2 network can save IP
addresses. Only RIP-2 can be
deployed on a network where
the IP addresses are
discontinuous, and RIP-1
cannot be used.
RIP-2 supports
authentication for protocol
packets and provides the
simple authentication and
MD5 authentication modes
to enhance security.
Preventing routing loops RIP is a routing protocol 3.5.3 Avoiding Routing

based on the distance vector Loops
algorithm. RIP devices
advertise their local routing
tables to neighbors, so
routing loops may occur.
RIP uses split horizon and
poison reverse to prevent
routing loops:
l Split horizon: A route
learnt by RIP from an
interface is not sent to
neighbors from the
interface. This reduces
bandwidth consumption
and prevents routing
loops.
l Poison reverse: RIP sets
the cost of a route learnt
from an interface to 16 (an
unreachable route), and
sends the route to
neighbors through the
interface. In this way, RIP
can delete useless routes
from the neighbor routing
table and prevent routing
loops.

Routers
Controlling RIP routing To use RIP more flexibly on 3.5.4 Controlling RIP
the existing network and Routing
meet various user
requirements, you can
configure different
parameters to control RIP
routing.
Controlling the advertising In practical applications, to 3.5.5 Controlling RIP

and receiving of RIP routes meet network requirements, Route Advertisement
you can configure different 3.5.6 Controlling Receiving
parameters to accurately of RIP Routing
control the advertising and Information
receiving of RIP routes.
Improving RIP network In practical applications, you 3.5.7 Improving RIP

performance can configure special RIP Network Performance
functions to improve RIP
network performance.
l Adjusting the value of the
RIP timer to change the
RIP network convergence
rate.
l Adjusting the number and
interval of Update packets
sent by the interface to
reduce device resource
and network bandwidth
consumption.
l Enabling the replay-
protect function to ensure
normal communication
between neighboring
devices after the RIP
process restarts.
l Checking packet validity
to meet network
requirements for high
security.

Routers
Configuring BFD for RIP In general, RIP maintains 3.5.8 Configuring BFD for
neighbor relationships by RIP
periodically sending and
receiving Update packets. If
a device does not receive the
Update packet from a
neighbor in the aging time, it
considers the neighbor
Down. The default value of
the aging timer is 180
seconds, so RIP can detect a
link fault only after the fault
lasts for 180 seconds. If high-
speed data services are
deployed on the network, a
large amount of data will be
lost during this period.
BFD provides the
millisecond-level fault
detection mechanism. It can
detect faults on the protected
links or nodes immediately,
and report the faults to RIP.
BFD improves the RIP
process's response to network
topology changes, which
implements fast convergence
of RIP routes.

This section describes the default configuration of RIP, which can be changed according to
Table 3-3 describes the default configuration of RIP.
Table 3-3 Default configuration of RIP
Maximum number of equal-cost routes On the AR150&200 series, AR1200 series,

AR2201-48FE, AR2202-48FE, and AR2204
is 4, on the AR2220, AR2240, and AR3200
series is 8.
RIP function Disabled

Routers
Split horizon Enabled
3.5 Configuring RIP

RIP is widely used on small-sized networks to discover routes and generate routing information.
3.5.1 Configuring Basic RIP Functions

Configuring basic RIP functions includes enabling RIP, specifying network segment, and setting
RIP neighbors and RIP version on a Non-Broadcast Multiple Access (NBMA) network.
Before configuring basic RIP functions, complete the following task:
l Configuring IP addresses for interfaces to ensure network-layer communication between
neighbor nodes
Configuration Process
Enabling RIP is the prerequisite for setting RIP neighbors and RIP version on an NBMA network.
3.5.1.1 Enabling RIP
Context
Enabling RIP is the prerequisite for all RIP-related configurations. If you run the RIP commands
in the interface view before enabling RIP, the configurations take effect only after RIP is enabled.
Procedure
Step 1 Run:
system-view

Step 2 Run:
rip [ process-id ] [ vpn-instance vpn-instance-name ]
RIP is enabled and the RIP view is displayed.

If a VPN instance is specified, the RIP process belongs to this VPN instance. If no VPN instance
is specified, the RIP process belongs to a public network instance.
Step 3 (Optional) Run:
description text
Descriptions for RIP processes are configured.
----End

Routers
3.5.1.2 Enabling RIP on the Specified Network Segment
Context
After enabling RIP, you need to specify the network segment in which RIP runs. RIP runs only
on the interfaces on the specified network segment. RIP does not receive, send, or forward routes
on the interfaces that do not reside on the specified network segment.
Procedure
l Enable RIP to send and receive routes on the specified network segment.
1. Run the system-view command to enter the system view.
2. Run the rip [ process-id ] command to enter the RIP view.
3. (Optional) Run the undo verify-source command to disable source check for RIP
packets.
If the IP addresses on two ends of a P2P link belong to different network segments,
the devices on the two ends cannot set up neighbor relationship unless source check
is disabled.
4. Run the network network-address command to enable RIP on the specified network
segment.
NOTE
l network-address specifies the address of a natural network segment.

l An interface can be associated with only one RIP process.
l If any network segment in which an interface configured with multiple sub-interface IP
addresses resides is associated with a RIP process, the interface cannot be associated with
any other RIP processes.
----End
3.5.1.3 (Optional) Configuring RIP Neighbors on an NBMA Network
Context
Generally, RIP uses a broadcast or multicast address to send packets. If the link running RIP
does not support broadcast or multicast packets, specify the RIP neighbors on the two ends of
the link so that packets can be sent between the two ends in unicast mode.
Procedure
Step 1 Run:
system-view

Step 2 Run:
rip [ process-id ]
The RIP view is displayed.

Step 3 Run:
peer ip-address

Routers
The RIP neighbor is configured.
----End
3.5.1.4 (Optional) Specifying the RIP Version
Context
RIP versions include RIP-1 and RIP-2. The two versions have different functions. The RIP
version must be set on the device running RIP. You only need to set the global RIP version
unless you want to specify a different RIP version on an interface.
Procedure
l Configure the global RIP version.
3. Run the version { 1 | 2 } command to set the global RIP version.
NOTE
By default, an interface sends only RIP-1 packets and receives both RIP-1 and RIP-2 packets.
l Configure the RIP version for an interface.
2. Run the interface interface-type interface-number command to enter the interface
view.
3. Run the rip version { 1 | 2 [ broadcast | multicast ] } command specify the RIP
version on the specified interface.
NOTE
l By default, an interface sends only RIP-1 packets and receives both RIP-1 and RIP-2
packets.
l If no RIP version number is configured in the interface view, the global RIP version is used.
The RIP version set on an interface takes precedence over the global RIP version.
----End
Procedure
l Run the display rip [ process-id | vpn-instance vpn-instance-name ] command to view the
running status and configurations of RIP.
l Run the display rip process-id route command to view all RIP routes learned from other
devices.
l Run the display default-parameter rip command to view default RIP configuration.
l Run the display rip process-id statistics interface { all | interface-type interface-
number [ verbose | neighbor neighbor-ip-address ] } command to view statistics on the
RIP interface.
----End

Routers
3.5.2 Configuring RIP-2

Different from RIP-1, RIP-2 supports Variable Length Subnet Mask (VLSM), Classless Inter-
Domain Routing (CIDR), and authentication to ensure higher security.
Before configuring RIP-2, complete the following task:
l Configuring Basic RIP Functions
3.5.2.1 Configuring RIP-2 Route Summarization
Context
A large RIP network must maintain large RIP routing tables, which occupy a lot of memory on
devices. Transmitting and processing the routing information requires many network resources.
Route summarization can reduce the routing table size and minimize impact of route flapping
on network.
RIP supports automatic summarization and manual summarization. Manual summarization

takes precedence over automatic summarization. To advertise all subnet routes, disable
automatic route summarization of RIP-2.
NOTE
By default, if split horizon or poison reverse has been configured, classful route summarization is invalid.
When summarized routes are sent to the natural network border, split horizon or poison reverse must be
disabled.
Procedure
l Configure automatic route summarization of RIP-2.
3. Run the version 2 command to set the RIP version to RIP-2.
4. Run the summary command to enable automatic route summarization.
5. (Optional) Run the summary always command to enable automatic route
summarization. This command can enable automatic summarization of RIP-2 no
matter whether split horizon and poison reverse are enabled.
NOTE
The summary command is used in the RIP view to enable classful network-based route
summarization of RIP-2.
l Configure manual route summarization of RIP-2.

Routers
2. Run the interface interface-type interface-number command to enter the interface

view.
3. Run the rip summary-address ip-address mask [ avoid-feedback ] command to
configure RIP-2 to advertise the local summarization IP address.
NOTE
The rip summary-address ip-address mask [ avoid-feedback ] command is run in the

interface view to enable classless network-based route summarization of RIP-2.
----End
3.5.2.2 Configuring RIP-2 Packet Authentication
Context
On the RIP network requiring high security, configure RIP-2 packet authentication.
RIP-2 can perform simple authentication or MD5 authentication on protocol packets. Simple
authentication uses the authentication key in plain text, so its security is lower than that of MD5.
NOTICE
If plain is selected during the configuration of the RIP-2 packet authentication mode, the
password is saved in the configuration file in plain text. This brings security risks. It is
recommended that you select cipher to save the password in cipher text.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface interface-type interface-number
The interface view is displayed.
Step 3 Configure RIP-2 packet authentication.

l Run the rip authentication-mode simple { plain plain-text | [ cipher ] password-key }
command to set RIP-2 authentication to simple authentication.
l Run the following commands to set RIP-2 authentication to MD5 authentication.
rip authentication-mode md5 usual { plain plain-text | [ cipher ] password-key }
rip authentication-mode md5 nonstandard { keychain keychain-name | { plain plain-
text | [ cipher ] password-key } key-id }

Routers
NOTE
If the MD5 authentication is used, you must set the packet format for MD5 authentication. If the
usual keyword is specified, the MD5 cipher text authentication packets use the universal format (private
standard). If the nonstandard keyword is specified, the MD5 cipher text authentication packets use
the non-standard format (IETF standard).
l Run the rip authentication-mode hmac-sha256 { plain plain-text | [ cipher ] password-
key } key-id command to set RIP-2 authentication to HMAC-SHA256 authentication.
----End
Procedure
l Run the display rip process-id database [ verbose ] command to view all the active routes
in the RIP database.
devices.
l Run the display rip process-id interface [ interface-type interface-number ] [ verbose ]
command to view information about the RIP interface.
----End
3.5.3 Avoiding Routing Loops

You can configure split horizon and poison reverse to prevent routing loops.
Before configuring split horizon and poison reverse, complete the following task:
3.5.3.1 Configuring Split Horizon
Context
Split horizon can prevent routing loops.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
Step 3 Run:
rip split-horizon
Split horizon is configured.
NOTE
l By default, split horizon is disabled for an NBMA network.

l If both split horizon and poison reverse are configured, only poison reverse takes effect.
----End
3.5.3.2 Configuring Poison Reverse
Context
Poison reverse can prevent routing loops.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
rip poison-reverse
Poison reverse is enabled.
NOTE
If both split horizon and poison reverse are configured, only poison reverse takes effect.
----End
Procedure
----End

Routers
3.5.4 Controlling RIP Routing

You can control RIP routing in a network with a complicated environment.
Before configuring RIP route attributes, complete the following task:
3.5.4.1 Configuring RIP Preference
Context
When different routing protocols discover the routes to the same destination, set the RIP
preference to select the required route.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
preference { preference | route-policy route-policy-name } *
The RIP preference is set.
By default, the RIP preference is 100.
----End
3.5.4.2 Configuring Additional Metrics of an Interface
Context
Configuring the additional metrics on a RIP interface can change the route selection sequence.
The additional metric is the metric (hop count) to be added to the original metric of a RIP route.
You can specify commands to set additional metrics for incoming and outgoing RIP routes.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run the following commands as required:

l Run the rip metricin { value | { acl-number | acl-name acl-name | ip-prefix ip-prefix-
name } value1 } command to set the additional metric for receiving routes.
l Run the rip metricout { value | { acl-number | acl-name acl-name | ip-prefix ip-prefix-
name } value1 } command to set the additional metric for advertising routes.
NOTE
l The rip metricin command is used to add an additional metric to an incoming route. After this route
is added to the routing table, its metric in the routing table changes. Running this command affects
route selection on the local device and other devices on the network.
l The rip metricout command is used to add an additional metric to an outgoing route. When this route
is advertised, an additional metric is added to this route, but the metric of the route in the routing table
does not change. Running this command does not affect route selection on the local device or other
devices on the network.
----End
3.5.4.3 Setting the Maximum Number of Equal-Cost Routes
Context
By setting the maximum number of equal-cost RIP routes, you can change the number of routes
for load balancing.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
maximum load-balancing number
The maximum number of equal-cost routes is set.

Routers
By default, the AR150&200 series, AR1200 series, AR2201-48FE, AR2202-48FE, and AR2204
support a maximum of four equal-cost routes, and the AR2220, AR2240, and AR3200 series
support a maximum of eight equal-cost routes.
----End
Procedure
devices.
----End
3.5.5 Controlling RIP Route Advertisement

On a complex network, RIP route advertisement must be accurate.
Before controlling RIP route advertisement, complete the following task:
3.5.5.1 Configuring RIP to Advertise Default Routes
Context
In a routing table, a default route is the route to the network segment 0.0.0.0 (with the mask
being 0.0.0.0). If the destination address of a packet does not match any entry in the routing
table, the packet is sent along the default route.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]

Routers
Step 3 Run:
default-route originate [ cost cost | { { match default | route-policy route-policy-
name } [ avoid-learning ] } ]*
The device is configured to originate a default route or advertise the default route in the routing
table to neighbors.
----End
3.5.5.2 Disabling an Interface from Sending Update Packets
Context
Routing loops can be avoided by disabling interfaces from sending Update packets.
There are two ways to prevent interfaces from sending Update packets:
l Suppress an interface in the RIP process view.
l Disable an interface from sending RIP packets in the interface view.
The configuration in the RIP process view has a higher priority than the configuration in the
interface view.
Procedure
l Configuration in a RIP process view
1. Run:
system-view

2. Run:
rip [ process-id ]

3. Run one of the following commands depending on the site requirements:
To disable all interfaces from sending Update packets, run the

silent-interface all
command.
To disable an interface from sending Update packets, run the

silent-interface interface-type interface-number
command.
You can set an interface to silent so that it only receives Update packets to update its
routing table. The silent-interface command takes precedence over the undo rip
output command in the interface view.
By default, an interface can receive and send Update packets.

l Configuration in the interface view
1. Run:
system-view

Routers

2. Run:

3. Run:
undo rip output
The interface is disabled from sending RIP Update packets.
By running this command, you can specify whether to send RIP Update packets on
an interface. The silent-interface command takes precedence over the undo rip
output command. By default, an interface is allowed to send RIP Update packets.
----End
3.5.5.3 Configuring RIP to Import Routes
Context
A RIP process can import the routes learned by other RIP processes or routing protocols.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]

default-cost cost
The default metric for imported routes is set.
If the metric of imported routes is not specified in step 4, the default metric is used.
Step 4 Run:
import-route bgp [ permit-ibgp ] [ cost { cost | transparent } | route-policy route-
policy-name ] *
Or
import-route { { static | direct | unr } | { { rip | ospf | isis } [ process-id ] } }
[ cost cost | route-policy route-policy-name ] *
External routes are imported to RIP.
NOTE
When RIP imports IBGP routes, routing loops may occur. Configure this function with caution.

Routers
filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name } export

[ protocol [ process-id ] | interface-type interface-number ]
The imported routes are filtered before being advertised.
The routing information advertised by RIP may contain the routing information imported from
other protocols. You can use the protocol parameter to filter the routing information imported
from a specified routing protocol. If the protocol parameter is not used, all the routes advertised
by RIP are filtered, including the imported routes and the local routes (direct routes).
NOTE
RIP-2 defines a 16-bit tag, while other routing protocols define 32-bit tags. If the routes of other protocols
are imported to RIP and the tag is used in the routing policy, the tag value cannot exceed 65535. If the tag
value exceeds 65535, the routing policy becomes invalid or the matching result is incorrect.
----End
Procedure
devices.
----End
3.5.6 Controlling Receiving of RIP Routing Information

To meet the requirements of complex networks, receiving of RIP routing information needs to
be accurately controlled.
Before controlling receiving of RIP routing information, complete the following task:
3.5.6.1 Disabling an Interface from Receiving RIP Update Packets
Context
Routing loops can be avoided by disabling interfaces from receiving Update packets.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
undo rip input
The interface is disabled from receiving RIP Update packets.
By default, an interface is allowed to receive RIP update packets.
----End
3.5.6.2 Configuring RIP to Deny Host Routes
Context
In certain cases, the router receives a large number of host routes with 32 bits from the same
network segment. These host routes are unnecessary for routing, and they waste network
resources. You can configure the router to reject all the host routes it receives.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
undo host-route
Host routes are not added to the RIP routing table.
By default, host routes can be added to the routing table on the router.
NOTE
The undo host-route command is invalid for RIP-2.
----End

Routers
3.5.6.3 Configuring RIP to Filter Received Routes
Context
The filtering policy can be configured on the inbound interface by configuring the ACL and IP
prefix list to filter received routes. Only the routes not filtered out by the filtering policy are
added to the local routing table.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Depending on type of desired filtering, run one of following commands to configure RIP to filter
the received routes:
l Run:
filter-policy { acl-number | acl-name acl-name } import [ interface-type
interface-number ]
The learned routing information is filtered based on an ACL.

l Run:
filter-policy gateway ip-prefix-name import
The routing information advertised by neighbors is filtered based on the IP prefix list.
l Run:
filter-policy ip-prefix ip-prefix-name [ gateway ip-prefix-name ] import
[ interface-type interface-number ]
The routes learned by the specified interface are filtered based on the IP prefix list and
neighbors.
----End
Procedure
l Run the display rip [ process-id | vpn-instance vpn-instance-name ] command to check
the running status and configuration of RIP.
l Run the display rip process-id database [ verbose ] command to check all activated RIP
routes in the database.
command to check information about the RIP interface.
l Run the display rip process-id neighbor [ verbose ] command to check information about
RIP neighbors.

Routers
l Run the display rip process-id route command to check all the RIP routes that are learned
from other routers.
----End
3.5.7 Improving RIP Network Performance

You can adjust and optimize the RIP network performance by configuring RIP functions in
special network environments, such as configuring RIP timers, setting the interval for sending
packets, and setting the maximum number of packets to be sent.
Before improving RIP network performance, complete the following task:
3.5.7.1 Configuring RIP Timers
Context
RIP uses 3 timers: Update, Age, and Garbage-collect. Changing the timer values affects the
convergence speed of RIP routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
timers rip update age garbage-collect
RIP timers are configured.
NOTE
l RIP timers take effect immediately after being changed.

l Route flapping occurs if the values of the three times are set improperly. The relationship between the
values is as follows: update must be smaller than age and update must be smaller than garbage-
collect. For example, if the update time is longer than the aging time, and a RIP route changes within
the update time, the router cannot inform its neighbors of the change on time.
l You must configure RIP timers based on the network performance and uniformly on all the devices
running RIP. This avoids unnecessary network traffic or route flapping.

Routers
By default, the Update timer is 30s; the Age timer is 180s; the Garbage-collect timer is four
times the Update timer, namely, 120s.
In practice, the Garbage-collect timer is not fixed. If the Update timer is set to 30s, the Garbage-
collect timer may range from 90s to 120s.
Before permanently deleting an unreachable route from the routing table, RIP advertises this
route (with the metric being set to 16) by periodically sending Update packets four times.
Subsequently, all the neighbors know that this route is unreachable. Because a route may not
always become unreachable at the beginning of an Update period, the Garbage-collect timer is
actually three or four times the Update timer.
----End
3.5.7.2 Setting the Interval for Sending Update Packets and Maximum Number of
Sent Packets
Context
To limit memory resources occupied by RIP Update packets, set the interval for sending RIP
Update packets and the maximum number of Update packets to be sent at a time to appropriate
values.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
rip pkt-transmit { interval interval | number pkt-count } *
The interval for sending RIP Update packets and the maximum number of Update packets to be
sent at a time are set.
----End
3.5.7.3 Enabling replay-protect Function
Context
By enabling the replay-protect function, you can obtain the Identification field in the last RIP
packet sent by a RIP interface before it goes Down. This prevents RIP routing information on
both ends from being unsynchronized or lost. For details of the Identification field in an IP
packet.
If the Identification field in the last RIP packet sent before a RIP interface goes Down is X, after
the interface goes Up, the Identification field in the subsequent RIP packet sent by this interface

Routers
becomes 0. If the remote end does not receive the RIP packet with the Identification field being
0, subsequent RIP packets will be discarded until the remote end receives the RIP packet with
the Identification field being X+1. This leads to the unsynchronization and loss of RIP routing
information of both ends.
To solve this problem, you need to enable the replay-protect function so that RIP can obtain the
Identification field in the last RIP packet sent before the RIP interface goes Down and increase
the Identification field in the subsequent RIP packet by one.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
rip authentication-mode md5 nonstandard password-key key-id
RIP-2 is configured to use MD5 authentication, and authentication packets use the nonstandard
packet format.
Step 4 Run:
rip replay-protect
The replay-protect function is enabled.
NOTE
If you run the rip replay-protect command in the same view multiple times, only the last configuration
takes effect.
----End
3.5.7.4 Configuring RIP to Check the Validity of Update Packets
Context
Checking RIP Update packet validity improves network security. Validity check includes zero
field check for RIP-1 packets and source address check for RIP Update packets.
l In a RIP-1 packet, the values of some fields must be zero. These fields are zero fields. After
zero field check is enabled, the device checks the zero fields in the RIP-1 packets and
discards the packets in which the zero field values are not 0.
l This command verifies the source IP address of the received RIP packet. Specifically, the
command checks whether the IP address of the interface that sends the packet is in the same
network segment as the IP address of the interface that receives the packet. If the addresses
are not in the same network segment, the RIP packet will not be processed.

Routers
Procedure
l Configure the zero field check for RIPv1 packets.
1. Run:
system-view

2. Run:
rip [ process-id ]

3. Run:
checkzero
The zero field check is configured for RIP-1 packets.
Configuring the zero field check is invalid in RIP-2.

l Configure the source address check for RIP Update packets.
1. Run:
system-view

2. Run:
rip [ process-id ]

3. Run:
verify-source
The source IP address check is configured for RIP Update packets.
----End
Procedure
l Run the display rip process-id neighbor [ verbose ] command to view the RIP neighbor
configuration.
devices.
----End

Routers
3.5.8 Configuring BFD for RIP

On a network that runs high-rate data services, BFD for RIP can be configured to quickly detect
and respond to network faults.
Before improving RIP network performance, complete the following task:
You can perform the following configuration tasks in any sequence as required.
3.5.8.1 Configuring Dynamic BFD for RIP
Applicable Environment
Generally, RIP uses timers to receive and send Update messages to maintain neighbor
relationships. If a RIP device does not receive an Update message from a neighbor after the Age
timer expires, the RIP device will announce that this neighbor goes Down. The default value of
the Age timer is 180s. If a link fault occurs, RIP can detect this fault after 180s. If high-rate data
services are deployed on a network, a great deal of data will be lost during the aging time.
BFD provides millisecond-level fault detection. It can rapidly detect faults in protected links or
nodes and report them to RIP. This speeds up RIP processes's response to network topology
changes and achieves rapid RIP route convergence.
Either of the following methods can be used to configure BFD for RIP:
l Enable BFD in a RIP process: This method is recommended when BFD for RIP needs to
be enabled on most RIP interfaces.
l Enable BFD on RIP interfaces: This method is recommended when BFD for RIP needs to
be enabled on a small number of RIP interfaces.
Procedure
l Enable BFD in a RIP process.
1. Run:
system-view

2. Run:
bfd
BFD is enabled globally.

3. Run:
quit

4. Run:

Routers
rip [ process-id ]

5. Run:
bfd all-interfaces enable
BFD is enabled in the RIP process to establish a BFD session.
If BFD is enabled globally, RIP will use default BFD parameters to establish BFD
sessions on all the interfaces where RIP neighbor relationships are in the Up state.
6. (Optional) Run:
bfd all-interfaces { min-rx-interval min-receive-value | min-tx-interval
min-transmit-value | detect-multiplier detect-multiplier-value } *
The values of BFD parameters used to establish the BFD session are set.
BFD parameter values are determined by the actual network situation and network
reliability requirement.
If links have a high reliability requirement, reduce the interval at which BFD
packets are sent.
If links have a low reliability requirement, increase the interval at which BFD
packets are sent.
Running the bfd all-interfaces command changes BFD session parameters on all RIP
interfaces. The default detection multiplier and interval at which BFD packets are sent
are recommended.
7. (Optional) Perform the following operations to prevent an interface in the RIP process
from establishing a BFD session:
Run the quit command to return to the system view.
Run the interface interface-type interface-number command to enter the view of
a specified interface.
Run the rip bfd block command to prevent the interface from establishing a BFD
session.
l Enable BFD on RIP interfaces.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

4. Run:
The view of the specified interface is displayed.

5. Run:

Routers
rip bfd enable
BFD is enabled on the interface to establish a BFD session.

6. (Optional) Run:
rip bfd { min-rx-interval min-receive-value | min-tx-interval min-
transmit-value | detect-multiplier detect-multiplier-value } *
The values of BFD parameters used to establish the BFD session are set.
----End

After enabling BFD for RIP at both ends of a link,
l Run the display rip process-id bfd session { interface interface-type interface-number |
neighbor-id | all } command. You can see that the BFDState field value on the local
router is displayed Up.
3.5.8.2 Configuring Static BFD for RIP
Context
BFD provides link failure detection featuring light load and high speed. Static BFD for RIP is
a mode to implement the BFD function.
Establishing BFD sessions between RIP neighbors can rapidly detect faults on links and speed
up response of RIP to network topology changes. Static BFD implements the following
functions:
l One-arm BFD: If some devices on a network support BFD but some do not, configure one-
arm BFD to implement fault detection.
l Two-arm BFD: If all the devices on a network support BFD, configure two-arm BFD to
implement fault detection.
Static BFD must be enabled using a command.
Procedure
Step 1 Enable BFD globally.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

Routers
NOTE
To configure one-arm BFD, go to Step 2. To configure two-arm BFD, go to Step 3.
Step 2 Configure one-arm BFD.

1. Run:
bfd session-name bind peer-ip peer-ip interface interface-type interface-
number [ source-ip source-ip ] one-arm-echo
BFD is enabled between the specified interface and peer device.
If a peer IP address and a local interface are specified, BFD detects only a single-hop link,
that is, a route with the interface specified in the bfd command as the outbound interface
and with the peer IP address specified in the peer-ip command as the next-hop address.
NOTE
When configuring the one-arm Echo function on the device, set the source-ip source-ip to the IP
address of an interface on the device. Ensure that the peer device can ping this IP address.
2. Run:
discriminator local discr-value
The local discriminator is set.

3. (Optional) Run:
min-echo-rx-interval interval
The minimum interval at which BFD packets are received is configured.

4. Run:
commit
The configuration is committed.

5. Run:
quit
Step 3 Configure two-arm BFD.

1. Run:
bfd session-name bind peer-ip ip-address [ interface interface-type interface-
number ] [ source-ip ip-address ]
BFD binding is created.
If a peer IP address and a local interface are specified, BFD detects only a single-hop link,
that is, a route with the interface specified in the bfd command as the outbound interface
and with the peer IP address specified in the peer-ip command as the next-hop address.
2. Set discriminators.
l Run:
The local discriminator is set.

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

Routers
The local discriminator must be the remote discriminator of the device on the other end;
otherwise, a BFD session cannot be established. The local and remote discriminators cannot
be modified after being configured.
NOTE
local discr-value set on the local device is the same as that of remote discr-value set on the remote
device.remote discr-value set on the local device is the same as that of local discr-value set on the
remote device.
3. Run:
commit
The configuration is committed.

4. Run:
quit
Step 4 Enable static BFD on an interface.

1. Run:

2. Run:
rip bfd static
Static BFD is enabled on the interface.

3. Run:
quit
----End

After configuring static BFD for RIP,
l Run the display rip process-id interface [ interface-type interface-number ] verbose
command to check BFD for RIP configurations on the specified interface.
3.5.9 Configuring the Network Management Function for RIP

By binding RIP to the MIB, you can view RIP information and configure RIP through the NMS.
Before configuring the network management function for RIP, complete the following task:
Procedure
Step 1 Run:
system-view

Routers

Step 2 Run:
rip mib-binding process-id
RIP is bound to the MIB.

This command is used to bind a RIP process ID to MIBs and specify the ID of the RIP process
that accepts Simple Network Management Protocol (SNMP) requests.
----End

l Run the display current-configuration command to view the binding relationships of RIP.
3.6 Maintaining RIP

RIP maintenance includes resetting RIP connections and clearing RIP statistics.
3.6.1 Resetting RIP

Context
NOTICE
The RIP neighbor relationship is deleted after you reset RIP connections with the reset rip
command. Exercise caution when running this command.
To reset RIP connections, run the following reset commands in the user view.
Procedure
l Run the reset rip process-id configuration command in the user view to reset the system
parameters of a RIP process. When a RIP process restarts, all the parameters of the process
retain the default values.
----End
3.6.2 Clearing RIP Statistics

Context
NOTICE
RIP information cannot be restored after it is cleared. Exercise caution when running the
commands.

Routers
To clear RIP statistics, run the following reset commands in the user view.
Procedure
l Run the reset rip process-id statistics interface { all | interface-type interface-number
[ neighbor neighbor-ip-address ] } command in the user view to clear the counters of a
RIP process.
----End

This section provides configuration examples of RIP, including networking requirements,
3.7.1 Example for Configuring Basic RIP Functions
As shown in Figure 3-9, RouterA, RouterB, RouterC, and RouterD are located on a network,
and they need to communicate with each other.
Figure 3-9 Network diagram of basic RIP functions
RouterC
GE2/0/0
172.16.1.2/24
GE1/0/0 RouterB GE2/0/0 GE3/0/0

192.168.1.1/24 172.16.1.1/24 10.1.1.2/24
GE1/0/0 GE3/0/0
RouterA 192.168.1.2/24 10.1.1.1/24 RouterD
The network size is small, so RIP-2 is recommended. The configuration roadmap is as follows:
1. Configure IP address for each interface to ensure network reachability.

2. Enable RIP on each router to implement network connections between processes.
3. Configure RIP-2 on each router to improve RIP performance.

Routers
Procedure
Step 1 Configure IP address for each interface.
# Configure Router A.
The configurations of Router B, Router C, and Router D are similar to the configuration of Router
A, and are not mentioned here.
Step 2 Configure basic RIP functions.
[RouterA] rip
[RouterA-rip-1] network 192.168.1.0
[RouterA-rip-1] quit
# Configure Router B.
[RouterB] rip
[RouterB-rip-1] network 192.168.1.0
[RouterB-rip-1] quit
# Configure Router C.
[RouterC] rip
[RouterC-rip-1] network 172.16.0.0
[RouterC-rip-1] quit
# Configure Router D.
[RouterD] rip
[RouterD-rip-1] network 10.0.0.0
[RouterD-rip-1] quit
# Check the RIP routing table of Router A.

[RouterA] display rip 1 route
Route Flags: R - RIP
A - Aging, S - Suppressed, G - Garbage-collect
-------------------------------------------------------------------------
Peer 192.168.1.2 on GigabitEthernet1/0/0
Destination/Mask Nexthop Cost Tag Flags Sec
10.0.0.0/8 192.168.1.2 1 0 RA 14
172.16.0.0/16 192.168.1.2 1 0 RA 14
The preceding display shows that the routes advertised by RIPv1 carry natural masks.
Step 3 Configure the RIP version.
# Configure RIPv2 on Router A.

[RouterA] rip
[RouterA-rip-1] version 2
# Configure RIPv2 on Router B.

[RouterB] rip
[RouterB-rip-1] version 2

Routers
# Configure RIPv2 on Router C.

[RouterC] rip
[RouterC-rip-1] version 2
# Configure RIPv2 on Router D.

[RouterD] rip
[RouterD-rip-1] version 2

# Check the RIP routing table of Router A.
[RouterA] display rip 1 route
Route Flags: R - RIP
A - Aging, S - Suppressed, G - Garbage-collect
-------------------------------------------------------------------------
Peer 192.168.1.2 on GigabitEthernet1/0/0
Destination/Mask Nexthop Cost Tag Flags Sec
10.1.1.0/24 192.168.1.2 1 0 RA 32
172.16.1.0/24 192.168.1.2 1 0 RA 32
The preceding display shows that the routes advertised by RIPv2 carry subnet masks.
----End
Configuration Files
l Configuration file of Router A
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
rip 1
version 2
network 192.168.1.0
#
return
l Configuration file of Router B

#
sysname RouterB
#
ip address 192.168.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
rip 1
version 2
network 192.168.1.0
network 172.16.0.0
network 10.0.0.0
#
return
l Configuration file of Router C

Routers
#
sysname RouterC
#
ip address 172.16.1.2 255.255.255.0
#
rip 1
version 2
network 172.16.0.0
#
return
l Configuration file of Router D

#
sysname RouterD
#
ip address 10.1.1.2 255.255.255.0
#
rip 1
version 2
network 10.0.0.0
#
return
3.7.2 Example for Importing Routes to RIP
As shown in Figure 3-10, two RIP processes, RIP100 and RIP200, run on RouterB. RouterA
needs to communicate with network segment 192.168.3.0/24.
Figure 3-10 Network diagram of configuring RIP to import external routes
GE2/0/0
192.168.0.1/24 RouterC
GE1/0/0 GE1/0/0 GE2/0/0
192.168.1.2/24 192.168.2.2/24 192.168.3.1/24
GE1/0/0 GE2/0/0 GE3/0/0
RouterA 192.168.1.1/24 192.168.2.1/24 192.168.4.1/24
RIP 100 RouterB RIP 200

2. Import routes between RIP100 and RIP200 on RouterB and set the default metric of routes
imported from RIP200 to 3.

Routers
3. Configure an ACL on RouterB to filter route 192.168.4.0/24 imported from RIP200 so that
RouterA can only communicate with network segment 192.168.3.0/24.
Procedure
Step 1 Configure an IP address for each interface.
The configurations of Router B, and Router C are similar to the configuration of Router A, and
are not mentioned here.
Step 2 Configure the basic RIP functions.
# Enable RIP process 100 on RouterA.

[RouterA] rip 100
# Enable RIP processes 100 and 200 on RouterB.

[RouterB] rip 100
[RouterB] rip 200
# Enable RIP process 200 on RouterC.

[RouterC] rip 200
# View the routing table on RouterA.

------------------------------------------------------------------------------
Step 3 Configure RIP to import external routes.
# On RouterB, set the default metric of imported routes to 3 and configure the RIP processes to
import routes into each other's routing table.
[RouterB] rip 100
[RouterB-rip-100] default-cost 3
[RouterB-rip-100] import-route rip 200

Routers
[RouterB] rip 200
[RouterB-rip-200] import-route rip 100
# View the routing table of RouterA after the routes are imported.
------------------------------------------------------------------------------
Step 4 Configure RIP to filter imported routes.

# Configure an ACL on RouterB and add a rule to the ACL. The rule denies the packets sent
from 192.168.4.0/24.
[RouterB] acl 2000
[RouterB-acl-basic-2000] rule deny source 192.168.4.0 0.0.0.255
[RouterB-acl-basic-2000] rule permit
[RouterB-acl-basic-2000] quit
# Configure RouterB to filter route 192.168.4.0/24 imported from RIP200.

[RouterB] rip 100
[RouterB-rip-100] filter-policy 2000 export

# Display the RIP routing table of RouterA after the routes are filtered.
------------------------------------------------------------------------------
----End
Configuration Files
#

Routers
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ip address 192.168.0.1 255.255.255.0
#
rip 100
network 192.168.0.0
network 192.168.1.0
#
return

#
sysname RouterB
#
acl number 2000
rule 5 deny source 192.168.4.0 0.0.0.255
rule 10 permit
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
rip 100
default-cost 3
network 192.168.1.0
filter-policy 2000 export
import-route rip 200
#
rip 200
network 192.168.2.0
import-route rip 100
#
return

#
sysname RouterC
#
ip address 192.168.2.2 255.255.255.0
#
ip address 192.168.3.1 255.255.255.0
#
ip address 192.168.4.1 255.255.255.0
#
rip 200
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
#
return

Routers
3.7.3 Example for Configuring One-Arm Static BFD for RIP
As shown in Figure 3-11, there are four routeres that communicate using RIP on a small-sized
network. Services are transmitted through the primary link Router ARouter BRouter D.
Reliability must be improved for data transmitted from Router A to Router B so that services
can be rapidly switched to another path for transmission when the primary link fails.
Figure 3-11 Networking diagram for One-Arm static BFD for RIP
RouterA GE1/0/0 GE1/0/0 RouterB GE3/0/0 RouterD

2.2.2.1/24 2.2.2.2/24 172.16.1.1/24
GE1/0/0
GE2/0/0 GE2/0/0 172.16.1.2/24
3.3.3.1/24 4.4.4.1/24
GE2/0/0 GE1/0/0
3.3.3.2/24 4.4.4.2/24
RouterC

2. Enable RIP on each switch to implement network connections between processes.
3. Configure One-Arm static BFD on Router A. BFD can rapidly detect the link status and
help RIP speed up route convergence to implement fast link switching.
Procedure
The configurations of Router B, Router C and Router D are similar to the configuration of
Router A, and are not mentioned here.
[RouterA] rip 1

Routers
[RouterB] rip 1
[RouterC] rip 1
[RouterD] rip 1
# After the configurations are complete, run the display rip neighbor command, and you can
see that RIP neighbor relationships among Router A, Router B, and Router C have been
established. Take the display on Router A as an example.
[RouterA] display rip 1 neighbor
---------------------------------------------------------------------
IP Address Interface Type Last-Heard-Time

---------------------------------------------------------------------
2.2.2.2 GigabitEthernet1/0/0 RIP 0:0:1
Number of RIP routes : 1
# Run the display ip routing-table command, and you can see that routers have learned routes
from each other. Take the display on Router A as an example.
------------------------------------------------------------------------------
2.2.2.0/24 Direct 0 0 D 2.2.2.1

2.2.2.1/32 Direct 0 0 D 127.0.0.1
3.3.3.0/24 Direct 0 0 D 3.3.3.1
3.3.3.1/32 Direct 0 0 D 127.0.0.1
4.0.0.0/8 RIP 100 1 D 2.2.2.2
RIP 100 1 D 3.3.3.2

Routers
The routing table shows that the next-hop IP address of the route destined for 172.16.0.0/16 is
2.2.2.2, the outbound interface is GigabitEthernet 1/0/0, and traffic is transmitted along the
primary link Router A Router B.
Step 3 Configure One-Arm static BFD on Router A.
# Configure one-arm BFD on Router A.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd 1 bind peer-ip 2.2.2.2 interface gigabitethernet 1/0/0 one-arm-echo
[RouterA-session-1] discriminator local 1
[RouterA-session-1] min-echo-rx-interval 200
[RouterA-session-1] commit
[RouterA-session-1] quit
# Enable static BFD on GigabitEthernet 1/0/0.

[RouterA-GigabitEthernet1/0/0] rip bfd static
# After the configurations are completed, run the display bfd session all command on Router
A and you can see that a static BFD session is set up.
----------------------------------------------------------------------------------
---------
----------------------------------------------------------------------------------
---------
1 - 2.2.2.2 Up S_IP_IF GigabitEthernet1/0/0
----------------------------------------------------------------------------------
---------
# Run the shutdown command on GE 1/0/0 on Router B to simulate a fault on the primary link.
NOTE
Fault simulation is for configuration verification. In actual application, it is not required.

[RouterB] interface gigabitethernet 1/0/0
# Check the routing table of Router A.

------------------------------------------------------------------------------
3.3.3.0/24 Direct 0 0 D 3.3.3.1

3.3.3.1/32 Direct 0 0 D 127.0.0.1
4.0.0.0/8 RIP 100 1 D 3.3.3.2
172.16.0.0/16 RIP 100 2 D 3.3.3.2

Routers
The routing table shows that the secondary link Router A Router C Router B starts to be
used after the primary link fails. The next-hop IP address of the route destined for 172.16.0.0/16
is 3.3.3.2 and the outbound interface is GE 2/0/0.
----End
Configuration files
#
sysname RouterA
#
bfd
#
ip address 2.2.2.1 255.255.255.0
rip bfd static
#
ip address 3.3.3.1 255.255.255.0
#
rip 1
version 2
network 2.0.0.0
network 3.0.0.0
#
bfd 1 bind peer-ip 2.2.2.2 interface GigabitEthernet1/0/0 one-arm-echo
min-echo-rx-interval 200
commit
#
return

#
sysname RouterB
#
bfd
#
ip address 2.2.2.2 255.255.255.0
#
ip address 4.4.4.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
rip 1
version 2
network 2.0.0.0
network 4.0.0.0
network 172.16.0.0
#
return

#
sysname RouterC
#
ip address 4.4.4.2 255.255.255.0
#
ip address 3.3.3.2 255.255.255.0

Routers
#
rip 1
version 2
network 3.0.0.0
network 4.0.0.0
#
return

#
sysname RouterD
#
ip address 172.16.1.2 255.255.255.0
#
rip 1
version 2
network 172.16.0.0
#
return
3.7.4 Example for Configuring Dynamic BFD for RIP
As shown in Figure 3-12, there are four routers that communicate using RIP on a small-sized
network. Services are transmitted through the primary link Router ARouter BRouter D.
Reliability must be improved for data transmitted from Router A to Router B so that services
can be rapidly switched to another path for transmission when the primary link fails.
Figure 3-12 Networking diagram for configuring BFD for RIP

3. Configure BFD for RIP on interfaces at both ends of the link between Router A and
Router B. BFD can rapidly detect the link status and help RIP speed up route convergence
to implement fast link switching.

Routers
Procedure
The configurations of Router B, Router C and Router D are similar to the configuration of
[RouterA] rip 1
[RouterB] rip 1
[RouterC] rip 1
[RouterD] rip 1
# After completing the preceding operations, run the display rip neighbor command. The
command output shows that Router A, Router B, and Router C have established neighbor
relationships with each other. In the following example, the display on Router A is used.
[RouterA] display rip 1 neighbor
---------------------------------------------------------------------
IP Address Interface Type Last-Heard-Time

---------------------------------------------------------------------
# Run the display ip routing-table command. The command output shows that the routers have
imported routes from each other. In the following example, the display on Router A is used.

Routers

------------------------------------------------------------------------------
2.2.2.0/24 Direct 0 0 D 2.2.2.1

2.2.2.1/32 Direct 0 0 D 127.0.0.1
3.3.3.0/24 Direct 0 0 D 3.3.3.1
3.3.3.1/32 Direct 0 0 D 127.0.0.1
4.0.0.0/8 RIP 100 1 D 2.2.2.2
RIP 100 1 D 3.3.3.2
The preceding command output shows that the next-hop address and outbound interface of the
route to destination 172.16.0.0/16 are 2.2.2.2 and GE 1/0/0 respectively, and traffic is transmitted
over the active link Router A->Router B.
Step 3 Configure BFD in RIP processes.
# Configure BFD on all interfaces of Router A.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] rip 1
[RouterA-rip-1] bfd all-interfaces enable
[RouterA-rip-1] bfd all-interfaces min-rx-interval 100 min-tx-interval 100 detect-
multiplier 10
The configuration of Router B is similar to that of Router A, and is not provided here.
# After completing the preceding operations, run the display rip bfd session command on
Router A. The command output shows that Router A and Router B have established a BFD
session and the BFDState field value is displayed as Up. In the following example, the display
on Router A is used.
[RouterA] display rip 1 bfd session all
LocalIp :2.2.2.1 RemoteIp :2.2.2.2 BFDState :Up
TX :100 RX :100 Multiplier:10
BFD Local Dis:8192 Interface :GigabitEthernet1/0/0
DiagnosticInfo: No diagnostic information
LocalIp :3.3.3.1 RemoteIp :3.3.3.2 BFDState :Down

BFD Local Dis :8200 Interface :GigabitEthernet2/0/0
Diagnostic Info:No diagnostic information
# Run the shutdown command on GE 1/0/0 of Router B to simulate a fault in the active link.
NOTE
The link fault is simulated to verify the configuration. In actual situations, the operation is not required.

Routers
# Check information about the BFD session on Router A. The command output shows that there
is no BFD session between Routers A and B.
[RouterA] display rip 1 bfd session all
LocalIp :3.3.3.1 RemoteIp :3.3.3.2 BFDState :Down

BFD Local Dis :8200 Interface :GigabitEthernet2/0/0
Diagnostic Info:No diagnostic information
# Check the routing table of Router A.

------------------------------------------------------------------------------
3.3.3.0/24 Direct 0 0 D 3.3.3.1

3.3.3.1/32 Direct 0 0 D 127.0.0.1
4.0.0.0/8 RIP 100 1 D 3.3.3.2
172.16.0.0/16 RIP 100 2 D 3.3.3.2
The preceding command output shows that the standby link Router A->Router C->Router B is
used after the active link fails, and the next-hop address and outbound interface of the route to
destination 172.16.0.0/16 are 3.3.3.2 and GE 2/0/0 respectively.
----End
Configuration Files
#
sysname RouterA
#
bfd
#
ip address 2.2.2.1 255.255.255.0
#
ip address 3.3.3.1 255.255.255.0
#
rip 1
version 2
network 2.0.0.0
network 3.0.0.0
bfd all-interfaces min-tx 100 min-rx-interval 100 detect-multiplier 10
#
return

#
sysname RouterB

Routers
#
bfd
#
ip address 2.2.2.2 255.255.255.0
#
ip address 4.4.4.1 255.255.255.0
#
interface gigabitethernet3/0/0
ip address 172.16.1.1 255.255.255.0
#
rip 1
version 2
network 2.0.0.0
network 4.0.0.0
network 172.16.0.0
bfd all-interfaces min-tx-interval 100 min-rx-interval 100 detect-multiplier
10
#
return

#
sysname RouterC
#
ip address 4.4.4.2 255.255.255.0
#
ip address 3.3.3.2 255.255.255.0
#
rip 1
version 2
network 3.0.0.0
network 4.0.0.0
#
return

#
sysname RouterD
#
ip address 172.16.1.2 255.255.255.0
#
rip 1
version 2
network 172.16.0.0
#
return

This section describes common faults caused by incorrect RIP configurations and provides the

Routers
3.8.1 Failed to Receive RIP Update Packets from Neighbors
Fault Description
A device cannot receive RIP Update packets from neighbors when the link runs properly.
Procedure
Step 1 Run the display current-configuration configuration rip command to check RIP
configurations.
l Check whether RIP has been enabled on the interface. Only the RIP-enabled interface can
receive RIP packets.
l Check whether the RIP versions on neighbors and local interface are the same. If the RIP
versions are different, the interface cannot receive RIP packets from neighbors.
Step 2 Run the display current-configuration interface interface-type interface-number command to

view the interface configuration.
l Check whether the undo rip input command has been executed on the interface. If the
command has been executed, the interface does not receive RIP packets.
l Check whether the authentication modes on the two ends of the link are the same. If the
authentication modes are different, the interface cannot receive RIP packets from the peer.
----End
3.8.2 Failed to Send RIP Update Packets to Neighbors
Fault Description
A device cannot send RIP Update packets to neighbors when the link runs properly.
Procedure
Step 1 Run the display current-configuration configuration rip command to check RIP
configurations.
l Check whether RIP has been enabled on the interface. Only the RIP-enabled interface can
send RIP packets.
l Check whether the silent-interface command has been executed on the interface. If the
command has been executed, the interface does not send RIP packets.
Step 2 Run the display current-configuration interface interface-type interface-number command to

view the interface configuration.
l Check whether the undo rip output command has been executed on the interface. If the
command has been executed, the interface does not send RIP packets.
l Check whether the authentication modes on the two ends of the link are the same. If the
authentication modes are different, the interface cannot send RIP packets to the peer.
l Check whether split horizon has been enabled on the interface. If split horizon has been
enabled, the interface cannot send the route learned by itself to neighbors.

Routers
NOTE
Split horizon is enabled on all interfaces by default, but the display current-configuration command
output does not show the split horizon option. If the command output for an interface connected to an
NBMA network does not contain the split horizon option, split horizon is disabled on the interface.
----End
3.8.3 Route Flapping Occurs on a RIP Network
Fault Description
Route flapping occurs on a RIP network when the link runs properly. Some routes intermittently
disappear in the routing table.
Procedure
Step 1 Run the display rip command to check the configuration of RIP timers.
The RIP timers on the entire network must be consistent; otherwise, route flapping occurs. The
relationships between the timer values are update < age, update < garbage-collect.
Step 2 Run the timers rip update age garbage-collect command to set the RIP timers.
----End
3.9 References
The following table lists the references that apply in this chapter.
Document Description Remar

ks
RFC 1058 This document describes RIP protocol, describes the -

elements, characteristic, limitation of rip version 1.
RFC 2453 This document specifies an extension of the Routing -

Information Protocol (RIP), as defined in [1], to expand
the amount of useful information carried in RIP
messages and to add a measure of security.
RFC 2080 This document specifies a routing protocol for an IPv6 -

Internet. It is based on protocols and algorithms
currently in wide use in the IPv4 Internet.

Routers
Configuration Guide - IP Routing 4 RIPng Configuration
4 RIPng Configuration
About This Chapter
RIPng is widely used on small-sized networks to discover routes and generate routing
information.
4.1 Introduction to RIPng

Routing Information Protocol next generation (RIPng) is a simple Interior Gateway Protocol
(IGP). It is the extension of RIP on IPv6 networks. RIPng applies to small-scale networks, such
as campus networks and regional networks with simple structure. RIPng is widely used on
networks because of its simple implementation and ease of configuration and maintenance
compared to OSPFv3 and IS-IS for IPv6.
4.2 Principles
This section describes only the differences between RIP and RIPng. For details about the RIP
implementation principles, see 3.2 Principles.

After basic RIPng functions are configured, you can build a Layer 3 network using the RIP
protocol. If other RIPng functions are required, configure them according to reference sections.

This section describes the default configuration of RIPng, which can be changed according to
4.5 Configuring RIPng

RIPng is widely used on small-sized IPv6 networks to discover routes and generate routing
information.
4.6 Maintaining RIPng

RIPng maintenance includes clearing RIPng statistics.

This section provides configuration examples of RIPng, including networking requirements,
4.8 References

Routers
4.1 Introduction to RIPng

Routing Information Protocol next generation (RIPng) is a simple Interior Gateway Protocol
(IGP). It is the extension of RIP on IPv6 networks. RIPng applies to small-scale networks, such
as campus networks and regional networks with simple structure. RIPng is widely used on
networks because of its simple implementation and ease of configuration and maintenance
compared to OSPFv3 and IS-IS for IPv6.
NOTE
The RIPng does not have the security authentication mechanism. To ensure security, configure OSPFv3,
IS-IS(IPv6), or BGP4+.
4.2 Principles
This section describes only the differences between RIP and RIPng. For details about the RIP
implementation principles, see 3.2 Principles.
4.2.1 RIPng
In addition to IPv4 networks, RIP is also applicable to IPv6 networks to provide accurate route
information for IPv6 packets. IETF has defined RIP next generation (RIPng) based on RIP for
IPv6 networks. RIPng is an important protocol for IPv6 networks.
Comparison Between RIPng and RIP

RIPng made the following modifications to RIP:
l RIPng uses UDP port 521 to send and receive routing information.
l RIPng uses the destination addresses with 128-bit prefixes (mask length).
l RIPng uses 128-bit IPv6 addresses as next hop addresses.
l RIPng uses the local link address FE80::/10 as the source address to send RIPng Update
packets.
l RIPng periodically sends routing information in multicast mode and uses FF02::9 as
multicast address.
l A RIPng packet consists of a header and multiple route table entries (RTEs). In a RIPng
packet, the maximum number of RTEs depends on the MTU on the interface.

After basic RIPng functions are configured, you can build a Layer 3 network using the RIP
protocol. If other RIPng functions are required, configure them according to reference sections.
Table 4-1 describes the RIPng configuration tasks.

Routers
Table 4-1 RIPng configuration tasks
Configuring basic RIPng Basic RIPng functions 4.5.1 Configuring Basic

functions include enabling RIPng and RIPng Functions
enabling the RIPng process
on interfaces. The basic
RIPng functions must be
configured before you use the
RIPng features.
Preventing routing loops RIPng is a routing protocol 4.5.2 Avoiding Routing

based on the distance vector Loops
algorithm. RIPng devices
advertise their local IPv6
routing tables to neighbors,
so routing loops may occur.
RIPng uses split horizon and
poison reverse to prevent
routing loops:
l Split horizon: A route
learnt by RIPng from an
interface is not sent to
neighbors from the
interface. This reduces
bandwidth consumption
and prevents routing
loops.
l Poison reverse: RIPng
sets the cost of a route
learnt from an interface to
16 (an unreachable route),
and sends the route to
neighbors through the
interface. In this way,
RIPng can delete useless
routes from the neighbor
routing table and prevent
routing loops.
Controlling RIP routing To use RIPng more flexibly 4.5.3 Controlling RIPng
on the existing network and Routing
meet various user
configure different
parameters to control RIP
routing.

Routers
Controlling the advertising In practical applications, to 4.5.4 Controlling RIPng

and receiving of RIP routes meet network requirements, Route Advertisement
you can configure different 4.5.5 Controlling the
parameters to accurately Receiving of RIPng Routes
control the advertising and
receiving of RIPng routes.
Improving RIPng network In practical applications, you 4.5.6 Improving RIPng

performance can configure special RIPng Network Performance
functions to improve RIPng
l Adjusting the value of the
RIPng timer to change the
RIPng network
convergence rate.
l Adjusting the number and
interval of Update packets
sent by the interface to
reduce device resource
and network bandwidth
consumption.
l Checking the zero fields
in RIPng packets to meet
network requirements for
high security.

This section describes the default configuration of RIPng, which can be changed according to
Table 4-2 describes the default configuration of RIPng.
Table 4-2 Default configuration of RIPng
Maximum number of equal-cost routes On the AR150&200 series, AR1200 series,

AR2201-48FE, AR2202-48FE, and AR2204
is 4, on the AR2220, AR2240, and AR3200
series is 8.
RIPng function Disabled

Routers
4.5 Configuring RIPng

RIPng is widely used on small-sized IPv6 networks to discover routes and generate routing
information.
4.5.1 Configuring Basic RIPng Functions

Basic RIPng functions include creating RIPng processes and enabling RIPng on interfaces. The
basic RIPng functions must be configured before you use RIPng features.
Before configuring basic RIPng functions, complete the following tasks:
l Enabling IPv6 on the router

l Configuring IPv6 addresses for interfaces to ensure that neighboring nodes are reachable
at the network layer
Configuration Flowchart
Creating RIPng processes is the prerequisite for enabling RIPng on interfaces.
4.5.1.1 Enabling RIPng
Context
Enabling RIPng is the prerequisite for all RIPng-related configurations. If you run the RIPng
commands in the interface view before enabling RIPng, the configurations take effect only after
RIPng is enabled.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ripng [ process-id ] [ vpn-instance vpn-instance-name ]
RIPng is enabled and the RIPng view is displayed.
If a VPN instance is specified, the RIPng process belongs to this VPN instance. If no VPN
instance is specified, the RIPng process belongs to a public network instance.

description text
Descriptions for RIPng processes are configured.
----End

Routers
4.5.1.2 Enabling RIPng on Interfaces
Context
After RIPng is enabled on an interface, devices can exchange RIPng routing information through
this interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng process-id enable
RIPng is enabled on the specified interface.
NOTE
If IPv6 is not enabled in the interface, this command cannot be run.

This command is not supported on ATM interfaces.
If RIPng needs to be enabled on multiple interfaces of a router, repeat steps 2 and 3.
----End
Procedure
l Run the display ripng [ process-id ] command to check the configuration of the RIPng
process.
l Run the display ripng process-id route command to check all the RIPng routes that are
learned from other routers.
l Run the display default-parameter ripng command to check the default RIPng
configuration.
l Run the display ripng process-id statistics interface { all | interface-type interface-
number [ neighbor neighbor-ipv6-address | verbose ] } command to check statistics about
RIPng interfaces.
----End
4.5.2 Avoiding Routing Loops

You can configure split horizon and poison reverse to prevent routing loops.

Routers
Before configuring split horizon and poison reverse, complete the following task:
l 4.5.1 Configuring Basic RIPng Functions
4.5.2.1 Configuring Split Horizon
Context
Split horizon can prevent routing loops.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng split-horizon
Split horizon is configured.
NOTE
l By default, split horizon is enabled except on the NBMA network.

l If both split horizon and poison reverse are configured, only poison reverse takes effect.
----End
4.5.2.2 Configuring Poison Reverse
Context
Poison reverse can prevent routing loops.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
Step 3 Run:
ripng poison-reverse
Poison reverse is enabled.
NOTE
If both split horizon and poison reverse are configured, only poison reverse takes effect.
----End
Procedure
l Run the display ripng process-id interface [ interface-type interface-number ]
[ verbose ] command to view information about the RIPng interface.
----End
4.5.3 Controlling RIPng Routing

You can control RIPng routing in a network with a complicated environment.
Before configuring RIPng route attributes, complete the following task:
4.5.3.1 Configuring RIPng Preference
Context
When different routing protocols discover the routes to the same destination, set the RIPng
preference to select the required route.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
The RIPng view is displayed.
Step 3 Run:
The RIPng preference is set.
By default, the RIPng preference is 100.
----End
4.5.3.2 Configuring Additional Metrics of an Interface
Context
Configuring the additional metrics on a RIPng interface can change the route selection sequence.
The additional metric is the metric (hop count) to be added to the original metric of a RIPng
route. You can specify commands to set additional metrics for incoming and outgoing RIPng
routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run the following commands as required:

l Run the ripng metricin value command to set the additional metric for receiving routes. By
default, an interface does not add the metric to a received RIPng route.
l Run the ripng metricout { value | { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-
prefix-name } value1 } command to set the additional metric for advertising routes. By
default, the metric that is added to the RIPng route sent by an interface is 1.
NOTE
l The ripng metricin command is used to add an additional metric to an incoming route. After this route
is added to the routing table, its metric in the routing table changes. Running this command affects
route selection on the local device and other devices on the network.
l The ripng metricout command is used to add an additional metric to an outgoing route. When this
route is advertised, an additional metric is added to this route, but the metric of the route in the routing
table does not change. Running this command does not affect route selection on the local device but
other devices on the network.
----End

Routers
Context
By setting the maximum number of equal-cost RIPng routes, you can change the number of
routes for load balancing.
Procedure
Step 1 Run:
system-view
Step 2 Run:
RIPng is enabled and the RIPng view is displayed.
Step 3 Run:
By default, the AR150&200 series, AR1200 series, AR2201-48FE, AR2202-48FE, and AR2204
support a maximum of four equal-cost routes, and the AR2220, AR2240, and AR3200 series
support a maximum of eight equal-cost routes.
----End
Procedure
l Run the display ripng [ process-id ] command to view the running status and configurations
of RIPng.
l Run the display ripng process-id database [ verbose ] command to view all the active
routes in the RIPng database.
l Run the display ripng process-id route command to view all RIPng routes learned from
other devices.
----End
4.5.4 Controlling RIPng Route Advertisement

On a complex network, RIPng route advertisement must be accurate.
Before controlling RIPng route advertisement, complete the following task:

Routers
4.5.4.1 Configuring RIPng Route Summarization
Context
Route summarization can reduce the routing table size and minimize impact of route flapping
on the network.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng summary-address ipv6-address prefix-length [ avoid-feedback ]
RIPng route summarization is configured.
By default, a RIPng router does not advertise summarized IPv6 addresses.
----End
4.5.4.2 Advertising a Default Route
Context
In an IPv6 routing table, a default route is a route to network ::/0. If the destination address of a
packet does not match any entry in the routing table, the packet is sent through a default route.
There are two methods to advertise RIPng default routes. You can configure a device to advertise
RIPng default routes according to networking requirements.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
Step 3 Run:
ripng default-route { only | originate } [ cost cost ]
The device is configured to advertise RIPng default routes.
By default, there is no default route in the RIPng routing domain.
Configure the device to advertise default routes according to networking requirements:
l only: configures the device to advertise only IPv6 default routes (::/0), suppressing the
advertisement of other routes.If the local device is located on the network edge and the details
of the local network need to be hidden, you can set this parameter to enable the devices on
other networks to access the local network only through the local device.
l originate: configures the device to advertise IPv6 default routes (::/0) without affecting the
advertisement of other routes.If the local device is located on the network edge and some
details of the local network need to be hidden, you can set this parameter to enable the devices
on other networks to use the default route when connecting to certain devices on the local
network.
The device advertises generated RIPng default routes using Update packets through a specified
interface regardless of whether these routes exist in the local IPv6 routing table.
----End
4.5.4.3 Configuring a RIPng Process to Import External Routes
Context
A RIPng process can import the routes learned by other processes or routing protocols to enrich
its routing information.
Procedure
Step 1 Run:
system-view
Step 2 Run:

default-cost cost
The default cost of external routes to be imported is set.
By default, the default cost of RIPng routes is 0.
If no cost is set for external routes to be imported, the default cost is used.
NOTE
When a RIPng process imports IBGP routes, routing loops may occur. Therefore, exercise caution before
you configure this function.

Routers
Step 4 Run:
import-route { { ripng | isis | ospfv3 } [ process-id ] | bgp [ permit-ibgp ] |
unr | direct | static } [ cost cost | route-policy route-policy-name ] *
External routes are imported.

filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name }
export [ protocol [ process-id ] ]
The RIPng process is configured to filter imported routes.

A RIPng process can use ACL6 and IPv6 prefix lists to filter imported routes, allowing only the
routes matching ACL6 and IPv6 prefix lists to be advertised to RIPng neighbors. If protocol is
not specified, the RIPng process filters all the routes to be advertised, including imported routes
and local RIPng routes (similar to direct routes).
----End
Procedure
l Run the display ripng process-id database [ verbose ] command to check all activated
----End
4.5.5 Controlling the Receiving of RIPng Routes

To meet the requirements of complex networks, control the receiving of RIPng routes.
Before controlling the receiving of RIPng routes, complete the following task:
l Configuring Basic RIPng Functions
Procedure
Step 1 Run:
system-view

Step 2 Run:
ripng [ process-id ]

Step 3 Run:
import
The RIPng process is configured to filter received routes.

Routers
You can use ACL6 and IPv6 prefix lists to filter received RIPng routes, allowing only the routes
matching ACL6 and IPv6 prefix lists to be added to RIPng routing tables.
----End

l Run the display ripng process-id database [ verbose ] command to check all the active
l Run the display ripng process-id route command to check all the RIPng routes learned
from other routers.
4.5.6 Improving RIPng Network Performance

You can adjust and optimize the RIPng network performance by configuring RIPng functions
in special network environments, such as configuring RIPng timers, setting the interval for
sending packets, and setting the maximum number of packets to be sent.
Before improving RIPng network performance, complete the following task:
4.5.6.1 Configuring RIPng Timers
Context
RIPng uses 3 timers: Update, Age, and Garbage-collect. Changing the timer values affects the
convergence speed of RIPng routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The RIPng process is enabled and the RIPng view is displayed.
Step 3 Run:
timers ripng update age garbage-collect
RIPng timers are configured.

Routers
NOTE
l RIPng timers take effect immediately after being changed.

l Route flapping occurs if the values of the three times are set improperly. The relationship between the
values is as follows: update must be smaller than age and update must be smaller than garbage-
collect. For example, if the update time is longer than the aging time, and a RIPng route changes within
the update time, the router cannot inform its neighbors of the change on time.
l You must configure RIPng timers based on the network performance and uniformly on all the routers
running RIPng. This avoids unnecessary network traffic or route flapping.
By default, the Update timer is 30s; the Age timer is 180s; the Garbage-collect timer is four
times the Update timer, namely, 120s.
In practice, the Garbage-collect timer is not fixed. If the Update timer is set to 30s, the Garbage-
collect timer may range from 90s to 120s.
Before permanently deleting an unreachable route from the routing table, RIPng advertises this
route (with the metric being set to 16) by periodically sending Update packets four times.
Subsequently, all the neighbors know that this route is unreachable. Because a route may not
always become unreachable at the beginning of an Update period, the Garbage-collect timer is
actually three or four times the Update timer.
----End
4.5.6.2 Setting the Interval for Sending Update Packets and Maximum Number of
Sent Packets
Context
To limit memory resources occupied by RIPng Update packets, set the interval for sending RIPng
Update packets and the maximum number of Update packets to be sent at a time to appropriate
values.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng pkt-transmit { interval interval | number pkt-count }*
The interval for sending RIPng Update packets and the maximum number of Update packets to
be sent at a time are set.
----End

Routers
4.5.6.3 Enabling Zero Field Check for RIPng Packets
Context
In a RIPng packet, some fields must be zero. These fields are called zero fields. When receiving
a packet, a RIPng process checks the zero fields of the packet. If the value of a zero field in the
packet is not 0, the RIPng process discards the packet.
Enabling zero field check on RIPng Update packets can improve network security.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
checkzero
Zero field check is enabled for RIPng packets.
----End
Procedure
l Run the display ripng [ process-id ] command to check the configuration of the RIPng
process.
l Run the display ripng process-id database [ verbose ] command to check all activated
l Run the display ripng process-id interface [ interface-type interface-number ]
[ verbose ] command to check information about the RIPng interface.
l Run the display ripng process-id neighbor [ verbose ] command to check information
about RIPng neighbors.
----End
4.6 Maintaining RIPng

RIPng maintenance includes clearing RIPng statistics.

Routers
4.6.1 Clearing RIPng
Context
NOTICE
RIPng information cannot be restored after it is cleared. Exercise caution when running the
commands.
Procedure
l Run the reset ripng process-id statistics [ interface { interface-type interface-number
[ neighbor neighbor-ip-address ] } ] command in the user view to clear statistics about the
counter that is maintained by a specified RIPng process.
----End

This section provides configuration examples of RIPng, including networking requirements,
4.7.1 Example for Configuring Basic RIPng Functions
As shown in Figure 4-1, three routers (RouterA, RouterB, and RouterC) reside on a small IPv6
network. RouterA, RouterB, and RouterC must communicate with each other.
Figure 4-1 Networking diagram of configuring basic RIPng functions
GE2/0/0
1::1/64 GE1/0/0 GE2/0/0
2::2/64 3::3/64
GE1/0/0 GE1/0/0
RouterA 2::1/64 RouterB 3::2/64 RouterC
1. Assign IP addresses to interfaces to ensure network reachability.

2. Enable RIPng on routers to implement network interconnection.

Routers
Procedure
Step 1 Assign an IPv6 address to each interface.
# Configure RouterA.
[RouterA] ipv6
[RouterA-GigabitEthernet1/0/0] ipv6 address 2::1 64
[RouterA-GigabitEthernet2/0/0] ipv6 address 1::1 64
not mentioned here.
Step 2 Configure basic RIPng functions.
[RouterA] ripng 1
[RouterA-ripng-1] quit
[RouterA-GigabitEthernet2/0/0] ripng 1 enable
[RouterA-GigabitEthernet1/0/0] ripng 1 enable
# Configure RouterB.
[RouterB] ripng 1
[RouterB-ripng-1] quit
[RouterB-GigabitEthernet1/0/0] ripng 1 enable
[RouterB-GigabitEthernet2/0/0] ripng 1 enable
# Configure RouterC.
[RouterC] ripng 1
[RouterC-ripng-1] quit
[RouterC] interface gigabitethernet 1/0/0
[RouterC-GigabitEthernet1/0/0] ripng 1 enable
[RouterC-GigabitEthernet1/0/0] quit
# Check the RIPng routing table of RouterA.

[RouterA] display ripng 1 route
Route Flags: R - RIPng
A - Aging, G - Garbage-
collect
----------------------------------------------------------------
Peer FE80::200:5EFF:FE04:B602 on GigabitEthernet1/0/0
Dest 3::/64,
via FE80::200:5EFF:FE04:B602, cost 1, tag 0, RA, 10 Sec
# Check the RIPng routing table of RouterB.

[RouterB] display ripng 1 route
A - Aging, G - Garbage-
collect
----------------------------------------------------------------

Routers
Peer FE80::A19:A6FF:FECE:7D4C on GigabitEthernet1/0/0

Dest 1::/64,
via FE80::A19:A6FF:FECE:7D4C, cost 1, tag 0, RA, 25 Sec
# Check the RIPng routing table of RouterC.

[RouterC] display ripng 1 route
A - Aging, G - Garbage-collect
----------------------------------------------------------------
Peer FE80::2E0:FCFF:FE01:9 on GigabitEthernet1/0/0
Dest 1::/64,
via FE80::2E0:FCFF:FE01:9, cost 2, tag 0, RA, 4 Sec
Dest 2::/64,
via FE80::2E0:FCFF:FE01:9, cost 1, tag 0, RA, 4 Sec
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
ripng 1 enable
#
ipv6 enable
ripng 1 enable
#
ripng 1
#
return

#
sysname RouterB
#
ipv6
#
ipv6 enable
ripng 1 enable
#
ipv6 enable
ripng 1 enable
#
ripng 1
#
return

#
sysname RouterC
#
ipv6
#

Routers
ipv6 enable
ripng 1 enable
#
ripng 1
#
return
4.8 References
Document Description Remar

ks
RFC 1058 This document describes RIP protocol, describes the -

elements, characteristic, limitation of rip version 1.
RFC 2453 This document specifies an extension of the Routing -

Information Protocol (RIP), as defined in [1], to expand
the amount of useful information carried in RIP
messages and to add a measure of security.
RFC 2080 This document specifies a routing protocol for an IPv6 -

Internet. It is based on protocols and algorithms
currently in wide use in the IPv4 Internet.

Routers
Configuration Guide - IP Routing 5 OSPF Configuration
5 OSPF Configuration
About This Chapter
By building OSPF networks, you can enable OSPF to discover and calculate routes in ASs.
OSPF is applicable to a large-scale network that consists of hundreds of devices.
5.1 Introduction to OSPF

This section describes the definition and purpose of OSPF.
5.2 Principle
This section describes the implementation of OSPF.
5.3 OSPF Applications

This section describes applications of OSPF.

After basic OSPF functions are configured, you can build a basic OSPF network. If other OSPF
functions are required, configure them according to reference sections.

This section describes the default configuration of OSPF, which can be changed according to
5.6 Configuring OSPF

5.7 Maintaining OSPF

Maintaining OSPF involves resetting OSPF, and clearing OSPF statistics.
5.8 Configuring Examples

This section provides several configuration examples of OSPF together with the configuration
flowchart. The configuration examples explain networking requirements, and configuration
roadmap.
5.9 FAQ
5.10 References
This section lists references of OSPF.

Routers
5.1 Introduction to OSPF

This section describes the definition and purpose of OSPF.
Definition
The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force
(IETF), is a link-state Interior Gateway Protocol (IGP).
At present, OSPF Version 2, defined in RFC 2328, is intended for IPv4, and OSPF Version 3,
defined in RFC 2740, is intended for IPv6. Unless otherwise stated, OSPF stated in this document
refers to OSPF Version 2.
Purpose
Before the emergence of OSPF, the Routing Information Protocol (RIP) is widely used on
networks as an IGP.
RIP is a routing protocol based on the distance vector algorithm. Due to its slow convergence,
routing loops, and poor scalability, RIP is gradually replaced by OSPF.
As a link-state protocol, OSPF can solve many problems encountered by RIP. Additionally,
OSPF features the following advantages:
l Receives or sends packets in multicast mode to reduce load on the Router that does not run
OSPF.
l Supports Classless Interdomain Routing (CIDR).
l Supports load balancing among equal-cost routes.
l Supports packet encryption.
With the preceding advantages, OSPF is widely accepted and used as an IGP.
5.2 Principle
This section describes the implementation of OSPF.
5.2.1 Fundamentals of OSPF
OSPF has the following functions:
l Divides an Autonomous System (AS) into one or multiple logical areas.

l Advertises routes by sending Link State Advertisements (LSAs).
l Exchanges OSPF packets between devices in an OSPF area to synchronize routing
information.
l Encapsulates OSPF packets into IP packets and sends the packets in unicast or multicast
mode.

Routers
Packet Type
Table 5-1 packet type
Packet Type Function
Hello packet Sent periodically to discover and maintain OSPF

neighbor relationships.
Database Description (DD) packet Contains brief information about the local link-state
database (LSDB) and synchronizes the LSDBs on two
devices.
Link State Request (LSR) packet Requests the required LSAs from neighbors.
LSR packets are sent only after DD packets are
exchanged successfully.
Link State Update (LSU) packet Sends the required LSAs to neighbors.
Link State Acknowledgement Acknowledges the receipt of an LSA.

(LSAck) packet
LSA Type
Table 5-2 LSA type
LSA Type Function
Router-LSA (Type 1) Describes the link status and link cost of a router. It is
generated by every router and advertised in the area to which
the router belongs.
Network-LSA (Type 2) Describes the link status of all routers on the local network
segment. Network-LSAs are generated by a designated router
(DR) and advertised in the area to which the DR belongs.
Network-summary-LSA Describes routes to a specific network segment in an area.

(Type 3) Network-summary-LSAs are generated by an Area Border
Router (ABR) and advertised in all areas except totally stub
areas and Not-So-Stubby Areas (NSSA Areas).
ASBR-summary-LSA Describes routes to an Autonomous System Boundary Router

(Type 4) (ASBR). ASBR-summary-LSAs are generated by an ABR
and advertised to all related areas except the area to which the
ASBR belongs.
AS-external-LSA (Type 5) Describes routes to a destination outside the AS. AS-external-

LSAs are generated by an ASBR and advertised to all areas
except stub areas and NSSA areas.
NSSA-LSA (Type7) Describes routes to a destination outside the AS. Generated by

an ASBR and advertised in NSSAs only.

Routers
LSA Type Function
Opaque-LSA (Type 9/Type Provides a universal mechanism for OSPF extension.

10/Type 11) l Type 9 LSAs are advertised only on the network segment
where the interface originating Type 9 LSAs resides. Grace
LSAs used to support GR are a type of Type 9 LSAs.
l Type 10 LSAs are advertised inside an OSPF area. LSAs
used to support TE are a type of Type 10 LSAs.
l Type 11 LSAs are advertised within an AS. At present,
there are no applications of Type 11 LSAs.
Router Type
Figure 5-1 lists common Router types used in OSPF.
Figure 5-1 Router type

IS-IS ASBR
Area1 Area4
Internal Router Backbone Router
Area0
Area2 ABR Area3
Table 5-3 Router type
Router Type Description
Internal router All interfaces on an internal router belong to the same OSPF
area.
Area Border Router (ABR) An ABR belongs to two or more than two areas, one of which
must be the backbone area.
An ABR is used to connect the backbone area and non-
backbone areas. It can be physically or logically connected
to the backbone area.

Routers
Backbone router At least one interface on a backbone router belongs to the

backbone area.
Internal routers in Area 0 and all ABRs are backbone routers.
ASBR (AS Boundary Router) An ASBR exchanges routing information with other ASs.
An ASBR does not necessarily reside on the border of an AS.
It can be an internal router or an ABR. An OSPF device that
has imported external routing information will become an
ASBR.
Route Type
Inter-area and intra-area routes in an AS describe the AS's network structure. AS external routes
describe the routes to destinations outside an AS. OSPF classifies the imported AS external
routes into Type 1 and Type 2 external routes.
Table 5-4 lists route types in descending priority order.
Table 5-4 route type
Route Type Description
Intra-area route Indicates routes within an area.
Inter-area route Indicates routes between areas.
Type 1 external route Type 1 external routes have high reliability.

Cost of a Type 1 external route = Cost of the route from a
local router to an ASBR + Cost of the route from the ASBR
to the destination of the Type 1 external route
Type 2 external route Type 2 external routes have low reliability, and therefore
OSPF considers that the cost of the route from an ASBR to
the destination of a Type 2 external route is much greater
than the cost of any internal route to the ASBR.
Cost of a Type 2 external route = Cost of the route from the
ASBR to the destination of the Type 2 external route

Routers
Area Type
Table 5-5 area type
Area Type Function
Common area OSPF areas are common areas by default. Common areas include
standard areas and backbone areas.
l A standard area is the most common area and transmits intra-area
routes, inter-area routes, and external routes.
l A backbone area connects all the other OSPF areas. It is usually
named Area 0.
Stub area A stub area does not advertise AS external routes, but only intra-area
and inter-area routes.
Compared with a non-stub area, the Router in a stub area maintains
fewer routing entries and transmits less routing information.
To ensure the reachability of AS external routes, the ABR in a stub
area advertises Type 3 default routes to the entire stub area. All AS
external routes must be advertised by the ABR.
Totally stub area A totally stub area does not advertise AS external routes or inter-area
routes, but only intra-area routes.
Compared with a non-stub area, the Router in a totally stub area
maintains fewer routing entries and transmits less routing
information.
To ensure the reachability of AS external routes, the ABR in a totally
stub area advertises Type 3 default routes to the entire totally stub
area. All AS external routes must be advertised by the ABR.
NSSA area An NSSA area can import AS external routes. An ASBR uses Type
7 LSAs to advertise the imported AS external routes to the entire
NSSA area. These Type 7 LSAs are translated into Type 5 LSAs on
an ABR, and are then flooded in the entire OSPF AS.
An NSSA area has the characteristics of the stub areas in an AS.
An ABR in an NSSA area advertises Type 3 default routes to the
entire NSSA area. All inter-area routes must be advertised by the
ABR.
Totally NSSA area A totally NSSA area can import AS external routes. An ASBR uses
Type 7 LSAs to advertise the imported AS external routes to the entire
NSSA area. These Type 7 LSAs are translated into Type 5 LSAs on
an ABR, and are then flooded in the entire OSPF AS.
A totally NSSA area has the characteristics of the totally stub areas
in an AS.
An ABR in a totally NSSA area advertises Type 3 default routes to
the entire totally NSSA area. All inter-area routes must be advertised
by the ABR.

Routers
OSPF Network Type

Table 5-6 lists four OSPF network types that are classified based on link layer protocols.
Table 5-6 OSPF network type
Network Type Description
Broadcast A network with the link layer protocol of Ethernet or Fiber

Distributed Data Interface (FDDI) is a broadcast network by
default.
On a broadcast network:
l Hello packets, LSU packets, and LSAck packets are usually
transmitted in multicast mode. 224.0.0.5 is an IP multicast
address reserved for an OSPF device. 224.0.0.6 is an IP
multicast address reserved for an OSPF DR or backup
designated router (BDR).
l DD and LSR packets are transmitted in unicast mode.
Non-Broadcast Multi- A network with the link layer protocol of frame relay (FR), X.25
Access (NBMA) is an NBMA network by default.
On an NBMA network, protocol packets such as Hello packets,
DD packets, LSR packets, LSU packets, and LSAck packets are
sent in unicast mode.
Point-to-Multipoint No network is a P2MP network by default, no matter what type of

(P2MP) link layer protocol is used on the network. A network can be
changed to a P2MP network. The common practice is to change a
non-fully meshed NBMA network to a P2MP network.
On a P2MP network:
l Hello packets are transmitted in multicast mode using the
multicast address 224.0.0.5.
l Other types of protocol packets, such as DD packets, LSR
packets, LSU packets, and LSAck packets are sent in unicast
mode.
Point-to-point (P2P) By default, a network where the link layer protocol is PPP, HDLC,
or LAPB is a P2P network.
On a P2P network, protocol packets such as Hello packets, DD
packets, LSR packets, LSU packets, and LSAck packets are sent
in multicast mode using the multicast address 224.0.0.5.
Stub Area
Stub areas are specific areas where ABRs do not flood the received AS external routes. In stub
areas, Routers maintain fewer routing entries and less routing information.
Configuring a stub area is optional. Not every area can be configured as a stub area. A stub area
is usually a non-backbone area with only one ABR and is located at the AS border.

Routers
To ensure the reachability of the routes to destinations outside an AS, the ABR in the stub area
generates a default route and advertises the route to the non-ABRs in the same stub area.
Note the following points when configuring a stub area:
l The backbone area cannot be configured as a stub area.

l Before configuring an area as a stub area, you must configure stub area attributes on all
Routers in the area.
l There should be no ASBR in a stub area, meaning that AS external routes cannot be
transmitted in the stub area.
l Virtual connections cannot cross a stub area.
NSSA Area
NSSA areas are a special type of OSPF areas. There are many similarities between an NSSA
area and a stub area. Both of them do not advertise the external routes received from the other
OSPF areas. The difference is that a stub area cannot import AS external routes, whereas an
NSSA area can import AS external routes and advertise the imported routes to the entire AS.
After an area is configured as an NSSA area, an ABR in the NSSA area generates a default route
and advertises the route to the other Routers in the NSSA area. This is to ensure the reachability
of the routes to the destinations outside an AS.
Note the following points when configuring an NSSA area:
l The backbone area cannot be configured as an NSSA area.

l Before configuring an area as an NSSA area, you must configure NSSA area attributes on
all Routers in the area.
l Virtual connections cannot cross an NSSA area.
Neighbor State Machine

OSPF has eight state machines: Down, Attempt, Init, 2-way, Exstart, Exchange, Loading, and
Full.
l Down: It is in the initial stage of setting up sessions between neighbors. The state machine
is Down when a router fails to receive Hello packets from its neighbor before the dead
interval expires.
l Attempt: It occurs only on an NBMA network. The state machine is Attempt when a
neighbor does not reply with Hello packets after the dead interval has expired. The local
router, however, keeps sending Hello packets to the neighbor at every poll interval.
l Init: The state machine is Init after a router receives Hello packets.
l 2-way: The state machine is 2-way when the Hello packets received by a router contain its
own router ID. The state machine will remain in the 2-way state if no neighbor relationship
is established, and will become Exstart if a neighbor relationship is established.
l Exstart: The state machine changes from Init to Exstart when the neighbor relationship is
established. The two neighbors then start to negotiate the master/slave status and determine
the sequence numbers of DD packets.
l Exchange: The state machine is Exchange when a router starts to exchange DD packets
with its neighbor after the master/slave status negotiation is completed.

Routers
l Loading: The state machine is Loading after a router has finished exchanging DD packets
with its neighbor.
l Full: The state machine is Full when the LSA retransmission list is empty.
OSPF Packet Authentication

OSPF supports packet authentication. Only the OSPF packets that have been authenticated can
be received. If OSPF packets are not authenticated, a neighbor relationship cannot be established.
The Router supports two authentication methods:
l Area-based authentication
l Interface-based authentication
When both area-based and interface-based authentication methods are configured, interface-
based authentication takes effect.
OSPF Route Summarization

Route summarization means that an ABR in an area summarizes the routes with the same prefix
into one route and advertises the summarized route to the other areas.
Route summarization between areas reduces the amount of routing information to be transmitted,
reducing the size of routing tables and improving device performance.
Route summarization can be carried out by an ABR or an ASBR:
l Route summarization on an ABR:

When an ABR in an area advertises routing information to other areas, it generates Type
3 LSAs by network segment. If this area contains consecutive network segments, you can
run a command to summarize these network segments into one network segment. The ABR
only needs to send one summarized LSA, and will not send the LSAs that belong to the
summarized network segment specified in the command.
l Route summarization on an ASBR:
If the local device is an ASBR and route summarization is configured, the ASBR will
summarize the imported Type 5 LSAs within the aggregated address range. After an NSSA
area is configured, the ASBR needs to summarize the imported Type 7 LSAs within the
aggregated address range.
If the local device is an ASBR and ABR, the device will summarize the Type 5 LSAs that
are translated from Type 7 LSAs.
OSPF Default Route

A default route is a route of which the destination address and mask are all 0s. If a router cannot
find a route in its routing table for forwarding packets, it can forward packets using a default
route. Due to hierarchical management of OSPF routes, the priority of default Type 3 routes is
higher than the priority of default Type 5 or Type 7 routes.
OSPF default routes are usually used in the following cases:
l An ABR advertises default Type 3 Summary LSAs to instruct routers within an area to
forward packets between areas.

Routers
l An ASBR advertises default Type 5 ASE LSAs or default Type 7 NSSA area LSAs to
instruct routers in an AS to forward packets to other ASs.
Principles for advertising OSPF default routes are described below:

l An OSPF router advertises an LSA that describes a default route only when an interface
on the OSPF router is connected to a network outside an area.
l If an OSPF router has advertised an LSA carrying information about a type of default route,
the OSPF router does not learn this type of default routes advertised by other routers. This
means that the OSPF router no longer calculates routes based on the LSAs carrying
information about the same type of the default routes advertised by other routers, but stores
these LSAs in its LSDB.
l The route on which default external route advertisement depends cannot be a route in the
local OSPF AS. This means that the route cannot be the one learned by the local OSPF
process. This is because default external routes are used to guide packet forwarding outside
an AS, whereas the routes within an AS have the next hop pointing to the devices within
the AS.
Table 5-7 lists principles for advertising default routes in different areas.
Table 5-7 Principles for advertising OSPF default routes
Area Type Function
Common area By default, devices in a common OSPF area do not automatically

generate default routes, even if the common OSPF area has default
routes.
When a default route on the network is generated by another routing
process (not OSPF process), the device that generates the default
route must advertise the default route in the entire OSPF AS. (Run a
command on an ASBR to configure the ASBR to generate a default
route. After the configuration, the ASBR generates a default Type 5
ASE LSA and advertises the LSA to the entire OSPF AS.)
STUB area A stub area does not allow AS external routes (Type 5 LSAs) to be
transmitted within the area.
All routers within the stub area must learn AS external routes from
the ABR. The ABR automatically generates a default Summary LSA
(Type 3 LSA) and advertises it to the entire stub area. Then all routes
to destinations outside an AS can be learned from the ABR.
Totally STUB area A totally stub area does not allow AS external routes (Type 5 LSAs)
or inter-area routes (Type 3 LSAs) to be transmitted within the area.
All routers within the totally stub area must learn AS external routes
and other areas' routes from the ABR. The ABR automatically
generates a default Summary LSA (Type 3 LSA) and advertises it to
the entire totally stub area. Then, all routes to destinations outside an
AS and to destinations in other areas can be learned from the ABR.

Routers
Area Type Function
NSSA area An NSSA area allows its ASBRs to import a small number of AS
external routes, but does not advertise ASE LSAs (Type 5 LSAs)
received from other areas within the NSSA area. This means that AS
external routes can be learned only from ASBRs in the NSSA area.
Devices in an NSSA area do not automatically generate default
routes.
Use either of the following methods as required:
l To advertise some external routes using the ASBR in the NSSA
area and advertise other external routes through other areas,
configure a default Type 7 LSA on the ABR and advertise this
LSA in the entire NSSA area.
l To advertise all the external routes using the ASBR in the NSSA
area, configure a default Type 7 LSA on the ASBR and advertise
this LSA in the entire NSSA area.
The difference between these two configurations is described below:
l An ABR will generate a default Type 7 LSA regardless of whether
the routing table contains the default route 0.0.0.0.
l An ASBR will generate a default Type 7 LSA only when the
routing table contains the default route 0.0.0.0.
A default route is flooded only in the local NSSA area and is not
flooded in the entire OSPF AS. If Routers in the local NSSA area
cannot find routes to the outside of the AS, the Routers can forward
packets to the outside of the AS through an ASBR. Packets of other
OSPF areas, however, cannot be sent to the outside of the AS through
this ASBR. Default Type 7 LSAs will not be translated into default
Type 5 LSAs and flooded in the entire OSPF AS.
Totally NSSA area A totally NSSA area does not allow AS external routes (Type 5 LSAs)
or inter-area routes (Type 3 LSAs) to be transmitted within the area.
All Routers within the totally NSSA area must learn AS external
routes from the ABR. The ABR automatically generates a default
Summary LSAs and advertises it to the entire totally NSSA area. Then
all external routes received from other areas and inter-area routes can
be advertised within the totally NSSA area.
OSPF Route Filtering

OSPF supports route filtering using routing policies. By default, OSPF does not filter routes.
Routing policies used by OSPF include the route-policy, access-list, and prefix-list.
OSPF route filtering can be used for:
l Importing routes

Routers
OSPF can import routes learned by other routing protocols. You can configure routing
policies to filter the imported routes to allow OSPF to import only the routes that match
specific conditions.
l Advertising imported routes
OSPF advertises the imported routes to its neighbors.
You can configure filtering rules to filter the routes to be advertised. The filtering rules can
be configured only on ASBRs.
l Learning routes
Filtering rules can be configured to allow OSPF to filter the received intra-area, inter-area,
and AS external routes.
After receiving routes, an OSPF device adds only the routes that match the filtering rules
to the local routing table, but can still advertise all routes from the OSPF routing table.
l Learning inter-area LSAs
You can run a command to configure an ABR to filter the incoming Summary LSAs. This
configuration takes effect only on ABRs because only ABRs can advertise Summary LSAs.
Table 5-8 Differences between inter-area LSA learning and route learning
Inter-area LSA Route Learning

Learning
Directly filters the Filters the routes that are calculated based on LSAs, but does
incoming LSAs. not filter LSAs. This means that all incoming LSAs are learned.
l Advertising inter-area LSAs

You can run a command to configure an ABR to filter the outgoing Summary LSAs. This
configuration takes effect only on ABRs.
OSPF Multi-Process
OSPF supports multi-process. Multiple OSPF processes can run on the same Router, and they
are independent of each other. Route exchanges between different OSPF processes are similar
to route exchanges between different routing protocols.
Each interface on the Router belongs to only one OSPF process.
A typical application of OSPF multi-process is that OSPF runs between PEs and CEs in a VPN,
whereas OSPF is used as an IGP on the backbone of the VPN. Two OSPF processes on the same
PE are independent of each other.
OSPF RFC 1583 Compatibility

RFC 1583 is an earlier version of OSPFv2.
When OSPF calculates external routes, routing loops may occur because RFC 2328 and RFC
1583 define different route selection rules. To prevent routing loops, both communication ends
must use the same route selection rules.

Routers
l After RFC 1583 compatibility is enabled, OSPF use the route selection rules defined in
RFC 1583.
l When RFC 1583 compatibility is disabled, OSPF uses the route selection rules defined in
RFC 2328.
OSPF calculates external routes based on Type 5 LSAs. If the Router enabled with RFC 1583
compatibility receives a Type 5 LSA:
l The Router selects a route to the ASBR that originates the LSA, or to the forwarding address
(FA) described in the LSA.
l The Router selects external routes to the same destination.
By default, OSPF uses the route selection rules defined in RFC 1583.
5.2.2 OSPF TE
OSPF Traffic Engineering (TE) is a new feature developed on the basis of OSPF to support
MPLS TE and establish and maintain the Label Switch Path (LSP) of TE. In the MPLS TE
architecture described in "Principles" in the Configuration Guide - MPLS - MPLS TE
Configuration, OSPF functions as the information advertising component, responsible for
collecting and advertising MPLS TE information.
In addition to the network topology, TE also needs to know network constraints, such as the
bandwidth, TE metric, administrative group, and affinity attribute. Current OSPF functions,
however, cannot meet these requirements. Therefore, OSPF needs to be extended by introducing
a new type of LSAs to advertise network constraints. Based on the network constraints, the
Constraint Shortest Path First (CSPF) algorithm can calculate the path that satisfies certain
constraints.
Figure 5-2 Function of OSPF in the MPLS TE architecture
Destination: Network1 Destination: Network1

cost=2 cost=2
Area 3 RouterE
RouterC ASBR
cost=6 cost=1 cost=8
RouterA RouterB
ASBR cost=1
cost=2
Area 0
Area 2
RouterD

Routers
Function of OSPF in the MPLS TE Architecture

In the MPLS TE architecture, OSPF functions as the information advertising component:
l Collects related information about TE.

l Floods TE information to devices in the same area.
l Uses the collected TE information to form the TE database (TEDB) and provides it for
CSPF to calculate routes.
OSPF does concern with what the specific information is or how MPLS uses the information.
TE-LSA
OSPF uses a new type of LSAs, namely, Type 10 opaque LSAs, to collect and advertise TE
information. This type of LSAs contain the link status information required by TE, including
the maximum link bandwidth, maximum reservable bandwidth, current reserved bandwidth, and
link color. Type 10 opaque LSAs synchronize link status information among devices in an area
through the OSPF flooding mechanism. By so doing, a uniform TEDB is formed for route
calculation.
Interaction Between OSPF TE and CSPF

OSPF collects TE information in an area by using Type 10 LSAs, including the bandwidth,
priority, and link metric. After processing the collected TE information, OSPF provides it for
CSPF to calculate routes.
IGP Shortcut and Forwarding Adjacency

OSPF supports IGP shortcut and forwarding adjacency. The two features allow OSPF to use a
tunnel interface as an outgoing interface to reach a destination.
Differences between IGP shortcut and forwarding adjacency are as follows:
l A device enabled with IGP shortcut uses a tunnel interface as an outgoing interface, but it
does not advertise the link of the tunnel interface to neighbors. Therefore, other devices
cannot use this tunnel.
l A device enabled with forwarding adjacency uses a tunnel interface as an outgoing
interface, and advertises the tunnel interface to neighbors. Therefore, other devices can use
this tunnel.
l IGP shortcut is unidirectional and needs to be configured only on the device that uses IGP
shortcut.
OSPF DS-TE
DiffSer Aware Traffic Engineering (DS-TE) controls and forwards flows differently based on
Class of Service (CoS). DS-TE combines the advantages of MPLS TE and Differentiated
Services (DiffServ) and controls flow paths precisely. By so doing, DS-TE effectively uses
network resources and reserves required resources for different service flows. For details, see
"Principles" in the Configuration Guide - MPLS - MPLS TE Configuration.
To support DS-TE in MPLS, OSPF supports the local overbooking multiplier TLV and
bandwidth constraint (BC) TLV in the TE-LSA, which are used to advertise and collect the

Routers
reservable bandwidths of class types (CTs) with different priorities on the link (A CT refers to
a collection of bandwidths of an LSP or a group of LSPs with the same CoS.)
OSPF SRLG
OSPF supports the applications of the Shared Risk Link Group (SRLG) in MPLS by obtaining
information about the SRLG that floods TE information to devices in an area. For details, see
"Principles" in the Configuration Guide - MPLS - MPLS TE Configuration.
5.2.3 BFD for OSPF
Definition
Bidirectional Forwarding Detection (BFD) is a mechanism to detect communication faults
between forwarding engines.
To be specific, BFD detects connectivity of a data protocol on a path between two systems. The
path can be a physical link, a logical link, or a tunnel.
In BFD for OSPF, a BFD session is associated with OSPF. The BFD session quickly detects a
link fault and then notifies OSPF of the fault. This speeds up OSPF's response to the change of
the network topology.
Purpose
The link fault or the topology change may cause devices to re-calculate routes. Therefore, the
convergence of routing protocols must be as quick as possible to improve the network
performance.
Link faults are unavoidable. Therefore, a feasible solution is required to detect faults faster and
notify the faults to routing protocols immediately. If BFD is associated with OSPF, once a fault
occurs on a link between neighbors, BFD can speed up the OSPF convergence.
Table 5-9 Comparison before and after BFD for OSPF is enabled
Associated Link Fault Detection Mechanism Convergence

with BFD or Speed
Not
Not associated An OSPF Dead timer expires. By default, the At the second level
with BFD timeout period of the timer is 40s.
Associated with A BFD session goes Down. At the millisecond

BFD level

Routers
Principle
Figure 5-3 BFD for OSPF
RouterA RouterB GE3/0/0

172.16.1.1/24
GE2/0/0 GE2/0/0
GE1/0/0 3.3.3.1/24 3.3.3.2/24 GE1/0/0
1.1.1.1/24 2.2.2.2/24
GE1/0/0 GE2/0/0
1.1.1.2/24 2.2.2.1/24
RouterC Area0
The principle of BFD for OSPF is shown in Figure 5-3.
1. OSPF neighbor relationships are established between these three routers.

2. After a neighbor relationship becomes Full, this triggers BFD to establish a BFD session.
3. The outbound interface on RouterA connected to RouterB is GE 2/0/0. If the link fails,
BFD detects the fault and then notifies RouterA of the fault.
4. RouterA processes the event that a neighbor relationship becomes Down and re-calculates
routes. After calculation, the outbound interface is GE1 /0/0 passes through RouterC and
then reaches RouterB.
5.2.4 OSPF GTSM
Definition
GTSM is short for Generalized TTL Security Mechanism, a mechanism that protects the services
over the IP layer by checking whether the TTL value in the IP packet header is within a pre-
defined range.
Purpose
On the network, an attacker may simulate valid OSPF packets and keeps sending them to a
device. After receiving these packets, the device identifies the destination of the packets. The
forwarding plane of the device then directly sends the packets to the control plane for processing
without checking the validity of the packets. As a result, the device is busy processing these
"valid" packets, resulting in high CPU usage.
In applications, the GTSM is mainly used to protect the TCP/IP-based control plane from CPU-
utilization based attacks, for example, attacks that cause CPU overload.

Routers
Principle
Devices enabled with GTSM check the TTL values in all the received packets according to the
configured policies. The packets that fail to pass the policies are discarded or sent to the control
plane. This prevents devices from possible CPU-utilization based attacks. A GTSM policy
involves the following items:
l Source address of the IP packet sent to the device

l VPN instance to which the packet belongs
l Protocol number of the IP packet (89 for OSPF, and 6 for BGP)
l Source interface number and destination interface number of protocols above TCP/UDP
l Valid TTL range
The method of implementing GTSM is as follows:
l For the directly connected OSPF neighbors, the TTL value of the unicast protocol packets
to be sent is set to 255.
l For multi-hop neighbors, a reasonable TTL range is defined.
The applicability of GTSM is as follows:
l GTSM is effective with unicast packets rather than multicast packets. This is because the
TTL file of multicast packets can only be 255, and therefore GTSM is not needed to protect
against multicast packets.
l GTSM does not support tunnel-based neighbors.
5.2.5 OSPF Smart-discover
Definition
Generally, Routers periodically send Hello packets through OSPF interfaces. That is, a Router
sends Hello packets at the Hello interval set by a Hello timer. Because Hello packets are sent at
a fixed interval, the speed at which OSPF neighbor relationship is established is lowered.
Enabling Smart-discover can speed up the establishment of OSPF neighbor relationships in

specific scenarios.
Table 5-10 OSPF Smart-discover
Smart-discover Configured or Processing

Not
Smart-discover is not configured l Hello packets are sent only when the Hello timer
expires.
l The gap between the sending of two Hello packets
is the Hello interval.
l Neighbors keep waiting to receive Hello packets
within the Hello interval.

Routers
Smart-discover Configured or Processing

Not
Smart-discover is configured l Hello packets are sent directly regardless of whether

the Hello timer expires.
l Neighbors can receive packets rapidly and perform
status transition immediately.
Principle
In the following scenarios, the interface enabled with Smart-discover can send Hello packets to
neighbors without having to wait for the Hello timer to expire:
l The neighbor status becomes 2-way for the first time.

l The neighbor status changes from 2-way or a higher state to Init.
5.2.6 OSPF VPN
Definition
As an extension of OSPF, OSPF VPN multi-instance enables Provider Edges (PEs) and
Customer Edges (CEs) in VPNs to run OSPF for interworking and use OSPF to learn and
advertise routes.
Purpose
As a widely used IGP, in most cases, OSPF runs in VPNs. If OSPF runs between PEs and CEs,
and PEs advertise VPN routes to CEs using OSPF, CEs do not need to support other routing
protocols for interworking with PEs. This simplifies management and configuration of CEs.
Running OSPF Between PEs and CEs

In BGP/MPLS VPN, routing information is transmitted between PEs using Multi-Protocol BGP
(MP-BGP), whereas routes are learned and advertised between PEs and CEs using OSPF.
Running OSPF between PEs and CEs has the following benefits:
l OSPF is used in a site to learn routes. Running OSPF between PEs and CEs can reduce the
protocol types that CEs must support, reducing the requirements for CEs.
l Similarly, running OSPF both in a site and between PEs and CEs simplifies the workload
of network administrators. In this manner, network administrators do not have to be familiar
with multiple protocols.
l When a network using OSPF but not VPN on the backbone network begins to use BGP/
MPLS VPN, running OSPF between PEs and CEs facilitates the transition.
As shown in Figure 5-4, CE1, CE3, and CE4 belong to VPN 1, and the numbers following OSPF
refer to the process IDs of multiple OSPF instances running on PEs.

Routers
Figure 5-4 Running OSPF between PEs and CEs
VPN1 VPN1
Site1 Site3
Area1
Area0
CE1 CE3
Area0 Area0
MPLS VPN
OSPF 100 VPN1
OSPF 100 VPN1 Backbone
Area1 PE1 PE2 Area1

OSPF 200 VPN2 OSPF 200 VPN1
CE2 CE4
Area1 Area2
Site2 Site4
VPN2 VPN1
The process of advertising routes of CE1 to CE3 and CE4 is as follows:
1. PE1 imports OSPF routes of CE1 into BGP and forms BGP VPNv4 routes.
2. PE1 advertises BGP VPNv4 routes to PE2 using MP-BGP.
3. PE2 imports BGP VPNv4 routes into OSPF, and then advertises these routes to CE3 and
CE4.
The process of advertising routes of CE4 or CE3 to CE1 is the same as the preceding process.
Configuring OSPF Areas Between PEs and CEs

OSPF areas between PEs and CEs can be either non-backbone areas or backbone areas (Area
0). A PE can only be an area border router (ABR).
In the extended application of OSPF VPN, the MPLS VPN backbone network serves as Area
0. OSPF requires that Area 0 be contiguous. Therefore, Area 0 of all VPN sites must be connected
to the MPLS VPN backbone network. If a VPN site has OSPF Area 0, the PEs that CEs access
must be connected to the backbone area of this VPN site through Area 0. If no physical link is
available to directly connect PEs to the backbone area, a virtual link can be used to implement
logical connection between the PEs and the backbone area, as shown in Figure 5-5.

Routers
Figure 5-5 Configuring OSPF areas between PEs and CEs
VPN
PE1 backbone PE2
Area0 Area0
Area1
Virtual link
CE1 CE2 Area0

Site1 Site2
Area0
A non-backbone area (Area 1) is configured between PE1 and CE1, and a backbone area (Area
0) is configured in Site 1. As a result, the backbone area in Site 1 is separated from the VPN
backbone area. Therefore, a virtual link is configured between PE1 and CE1 to ensure that the
backbone area is contiguous.
OSPF Domain ID
If inter-area routes are advertised between local and remote OSPF areas, these areas are
considered to be in the same OSPF domain.
l Domain IDs identify and differentiate different domains.

l Each OSPF domain has one or more domain IDs, one of which is a primary ID with the
others being secondary IDs.
l If an OSPF instance does not have a specific domain ID, its ID is considered as null.
Before advertising the remote routes sent by BGP to CEs, PEs need to determine the type of
OSPF routes (Type 3, Type 5 or Type 7) to be advertised to CEs according to domain IDs.
l If local domain IDs are the same as or compatible with remote domain IDs in BGP routes,
PEs advertise Type 3 routes.
l Otherwise, PEs advertise Type 5 or Type 7 routes.
Table 5-11 Domain ID
Comparison Between Local and Remote Local and Route Type

Domain IDs Remote
Domain
IDs the
Same Or
Not
Both the local and remote domain IDs are The same Inter-area route
null.

Routers
Comparison Between Local and Remote Local and Route Type

Domain IDs Remote
Domain
IDs the
Same Or
Not
The remote domain ID is the same as the local The same Inter-area route
primary domain ID or one of the local
secondary domain IDs.
The remote domain ID is different from the Not the If the local area is a non-
local primary domain ID or any of the local same NSSA, external routes are
secondary domain IDs. generated.
If the local area is an NSSA,
NSSA routes are generated.
Disabling Routing Loop Prevention
NOTICE
Disabling routing loop prevention may cause routing loops. Exercise caution when performing
this operation.
During BGP or OSPF route exchanges, routing loop prevention prevents OSPF routing loops in
VPN sites.
In the inter-AS VPN Option A scenario, if OSPF is running between ASBRs to transmit VPN
routes, the remote ASBR may be unable to learn the OSPF routes sent by the local ASBR due
to the routing loop prevention mechanism.
As shown in Figure 5-6, inter-AS VPN Option A is deployed. OSPF is running between PE1
and CE1. CE1 sends VPN routes to CE2.

Routers
Figure 5-6 Networking diagram for inter-AS VPN Option A
VPN1
CE1
VPN1
CE3
BGP/MPLS backbone BGP/MPLS backbone
AS: 100 AS: 200
PE1
PE3
ASBR1 ASBR2
MP-IBGP MP-IBGP
OSPF
PE2
PE4
CE4
CE2 VPN2
VPN2
1. PE1 learns routes to CE1 using the OSPF process in a VPN instance, and imports these
routes into MP-BGP, and sends the MP-BGP routes to ASBR1.
2. After having received the MP-BGP routes, ASBR1 imports the routes into the OSPF
process in a VPN instance and generates Type 3, Type 5, or Type 7 LSAs in which the DN
bit is set to 1.
3. ASBR2 learns these LSAs using OSPF and checks the DN bit of each LSA. After learning
that the DN bit in each LSA is set to 1, ASBR2 does not add the routing information carried
in these LSAs to its routing table.
Due to the routing loop prevention mechanism, ASBR2 cannot learn the OSPF routes sent from
ASBR1, causing CE1 to be unable to communicate with CE3.
To address the preceding problem, use either of the following methods:
l A device does not set the DN bit to 1 in the LSAs when importing BGP routes into OSPF.
For example, ASBR1 does not set the DN bit to 1 when importing MP-BGP routes into
OSPF. After ASBR2 receives these routes and checks that the DN bit in the LSAs carrying
these routes is 0, ASBR2 adds the routes to its routing table.
l A device does not check the DN bit after having received LSAs. For example, ASBR1 sets
the DN bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2, however,
does not check the DN bit after having received these LSAs.
The preceding methods can be used more flexibly based on specific types of LSAs. For Type 3
LSAs, you can configure a sender to determine whether to set the DN bit to 1 or configure a
receiver to determine whether to check the DN bit in the Type 3 LSAs based on the router ID
of the device that generates the Type 3 LSAs.
In the inter-AS VPN Option A scenario shown in Figure 5-7, the four ASBRs are fully meshed
and run OSPF. ASBR2 may receive the Type 3, Type 5, or Type 7 LSAs generated on ASBR4.
If ASBR2 is not configured to check the DN bit in the LSAs, ASBR2 will accept the Type 3
LSAs, and routing loops will occur, as described in Figure 5-7. ASBR2 will deny the Type 5

Routers
or Type 7 LSAs, because the VPN route tags carried in the LSAs are the same as the default
VPN route tag of the OSPF process on ASBR2.
To address the routing loop problem caused by Type 3 LSAs, configure ASBR2 not to check
the DN bit in the Type 3 LSAs that are generated by devices with the router ID 1.1.1.1 and the
router ID 3.3.3.3. After the configuration is complete, if ASBR2 receives Type 3 LSAs sent by
ASBR4 with the router ID 4.4.4.4, ASBR2 will check the DN bit and deny these Type 3 LSAs
because the DN bit is set to 1.
Figure 5-7 Networking diagram for full-mesh ASBRs in the inter-AS VPN Option A scenario
OSPF Router ID OSPF Router ID
1.1.1.1 2.2.2.2
ASBR1 ASBR2
OSPF AS: 200

AS: 100
ASBR3 ASBR4
OSPF Router ID OSPF Router ID
3.3.3.3 4.4.4.4
Routing Loop Prevention

Between PEs and CEs, routing loops may occur when OSPF and BGP learn routes from each
other.
Figure 5-8 OSPF VPN routing loops
PE1
VPN
backbone
vpn1 site1 10.1.1.1/32
CE1
PE2
As shown in Figure 5-8, on PE1, OSPF imports a BGP route whose destination address is
10.1.1.1/32, and then generates and advertises a Type 5 or Type 7 LSA to CE1. Then, CE1 learns
an OSPF route with the destination address and next hop being 10.1.1.1/32 and PE1 respectively,
and advertises the route to PE2. In this manner, PE2 learns an OSPF route with the destination
address and next hop being 10.1.1.1/32 and CE1 respectively.

Routers
Similarly, CE1 also learns an OSPF route with the destination address and next hop being
10.1.1.1/32 and PE2 respectively. PE1 learns an OSPF route with the destination address and
next hop being 10.1.1.1/32 and CE1 respectively.
As a result, CE1 has two equal-cost routes with next hops being PE1 and PE2 respectively, and
the next hops of the routes from PE1 and PE2 to 10.1.1.1/32 are CE1. Thus, a routing loop occurs.
In addition, the preference of an OSPF route is higher than that of a BGP route. Therefore, on
PE1 and PE2, BGP routes to 10.1.1.1/32 are replaced by the OSPF route. That is, the OSPF route
with the destination address and next hop being 10.1.1.1/32 and CE1 respectively is active in
the routing tables of PE1 and PE2.
The BGP route then becomes inactive, and thus the LSA generated when this route is imported
by OSPF is deleted. This causes the OSPF route to be withdrawn. As a result, there is no OSPF
route in the routing table, and the BGP route becomes active again. This cycle causes route
flapping.
OSPF VPN provides a solution to this problem, as shown in Table 5-12.
Table 5-12 Routing loop prevention
Feature Definition Function
DN-bit To prevent routing loops, an OSPF When advertising the

multi-instance process uses one bit as a generated Type 3, Type 5, or
flag bit, which is called the DN-bit. Type 7 LSAs to CEs, PEs set
the DN-bit of these LSAs to
1 and the DN-bit of other
LSAs to 0.
When calculating routes, the
OSPF multi-instance process
of a PE ignores the LSAs with
the DN-bit being 1. This
avoids routing loops that
occur when PEs learn the
self-originated LSAs from
CEs.
VPN Route Tag The VPN route tag is carried in Type 5 When a PE detects that the
or Type 7 LSAs generated by PEs VPN route tag in the
according to the received BGP private incoming LSA is the same as
route. that in the local LSA, the PE
Not transmitted in BGP extended ignores this LSA.
community attributes, the VPN route Consequently, routing loops
tag is valid only on the PEs that receive are avoided.
BGP routes and generate OSPF LSAs.

Routers
Feature Definition Function
Default Route A route with the destination address PEs do not calculate default
and mask being all 0s is a default route. routes.
Default routes are used to
forward the traffic from CEs
or the sites where CEs reside
to the VPN backbone
network.
Multi-VPN-Instance CE
OSPF multi-instance generally runs on PEs. The devices that run OSPF multi-instance within
the LANs of users are called Multi-VPN-Instance CEs (MCEs), that is, multi-instance CEs.
Compared with OSPF multi-instance running on PEs, MCEs have the following characteristics:
l MCEs do not need to support OSPF-BGP synchronization.

l MCEs establish different OSPF instances for different services. Different virtual CEs
transmit different services. This solves the security issue of the LAN at a low cost.
l MCEs implement different OSPF multi-instances on a CE. The key to implementing MCEs
is to disable loop detection and calculate routes directly. MCEs also need to use the received
LSAs with the ND-bit for route calculation.
5.2.7 OSPF NSSA
Definition
As defined in OSPF, stub areas cannot import external routes. This prevents a large number of
external routes from consuming bandwidth and storage resources of the Routers in stub areas.
To import external routes and to prevent external routes from consuming resources, NSSAs are
used, because stub areas cannot meet requirements.
NSSAs are a new type of OSPF areas.
There are many similarities between NSSAs and stub areas. The difference between NSSAs and
stub areas is that NSSAs can import AS external routes into the entire OSPF AS and advertise
the imported routes in the OSPF AS, but do not learn external routes from other areas on the
OSPF network.
Figure 5-9 NSSA
RIP RIP
Type5 Type5 NSSA Area
Type5 Type5 Type7

ASBR Area2 Area0 Area1 ASBR
ABR ABR

Routers
N-bit
All Routers in an area must be configured with the same area type. In OSPF, the N-bit is carried
in a Hello packet and is used to identify the area type supported by the Router. OSPF neighbor
relationships cannot be established between Routers configured with different area types.
Some manufacturers do not comply with the standard and set the N-bit in both OSPF Hello and
DD packets. To allow Huawei devices to interwork with these manufacturers' devices, set the
N-bit in OSPF DD packets on Huawei devices.
Type 7 LSA
l Type 7 LSAs are a new type of LSAs that can only be used in NSSAs and describe the
imported external routes.
l Type 7 LSAs are generated by ASBRs in an NSSA and flooded only in the NSSA where
the ASBRs reside.
l When the ABRs in the NSSA receive these Type 7 LSAs, they translate some of the Type
7 LSAs into Type 5 LSAs to advertise AS external routes to the other areas on the OSPF
network.
Translating Type 7 LSAs Into Type 5 LSAs

To advertise the external routes imported by an NSSA to other areas, Type 7 LSAs need to be
translated into Type 5 LSAs so that the external routes can be advertised on the entire OSPF
network.
l The Propagate bit (P-bit) in a Type 7 LSA is used to instruct the Router whether to translate
Type 7 LSAs into Type 5 LSAs.
l By default, the ABR with the largest router ID in an NSSA is responsible for translating
Type 7 LSAs into Type 5 LSAs.
l Only the Type 7 LSAs in which the P-bit is set to 1 and the FA is not 0 can be translated
into Type 5 LSAs. The FA indicates that the packet to a specific destination address will
be forwarded to the address specified by the FA.
l The P-bit in the Type 7 LSAs generated by ABRs is not set to 1.
Preventing Loops Caused by Default Routes

There may be multiple ABRs in an NSSA. To prevent routing loops, these ABRs not to calculate
default routes advertised by each other.
5.2.8 OSPF Fast Convergence

OSPF fast convergence is an extended feature of OSPF to speed up route convergence. The
characteristics of OSPF fast convergence are as follows:
l 5.2.9 Priority-based OSPF Convergence

l When certain routes on the network change, only the changed routes are recalculated. This
is called Partial Route Calculation (PRC).

Routers
l An intelligent timer is used to implement LSA management (the generating and receiving
of LSAs). With the intelligent timer, infrequent changes are responded to quickly, whereas
frequent changes are suppressed as desired.
To avoid excessive consumption of device resources by network connections or due to
frequent route flapping, RFC 2328 maintains that:
After an LSA is generated, it cannot be generated again in five seconds. That is, the
interval for updating LSAs is one second.
The interval for receiving LSAs is one second.
On a stable network where routes need to be fast converged, you can use the intelligent
timer to set the interval for receiving LSAs to 0 seconds. This ensures that topology or route
changes can be advertised to the network or be immediately sensed, thus speeding up route
convergence on the network.
l Route calculation is controlled through the intelligent timer.
When the network topology changes, devices need to recalculate routes according to OSPF.
This means that frequent changes in the network topology affect the performance of
devices. To address issue, RFC 2328 requires the use of a delay timer in route calculation
so that route calculation is performed only after the specified delay. But the delay suggested
by RFC is a fixed value, and cannot ensure both fast response to topology changes and
effective suppression of flapping.
By means of the intelligent timer, the delay in route calculation can be flexibly set as desired.
As a result, infrequent changes are responded to quickly, whereas frequent changes are
suppressed as desired.
l 5.2.5 OSPF Smart-discover
5.2.9 Priority-based OSPF Convergence

Priority-based OSPF convergence ensures that specific routes converge first when a great
number of routes need to converge. Different routes can be set with different convergence
priorities. This allows important routes to converge first and therefore improves network
reliability.
By using priority-based OSPF convergence, you can assign a higher convergence priority to
routes for key services so that those routes can converge fast. By so doing, the impact on key
services is reduced.
5.2.10 OSPF IP FRR

OSPF IP Fast Reroute (FRR) is dynamic IP FRR in which a backup link is pre-computed by an
OSPF based on the LSDBs on the entire network. The backup link is stored in the forwarding
table to protect traffic in the case of failures. In this manner, the failure recovery time can be
reduced to less than 50 ms.
OSPF IP FRR complies with RFC 5286, that is, Basic Specification for IP Fast Reroute Loop-
Free Alternates, which protects traffic when links or nodes become faulty.
Background
With the development of networks, Voice over IP (VoIP) and online video services require high-
quality real-time transmission. Nevertheless, if an OSPF fault occurs, multiple processes,

Routers
including fault detection, LSP update, LSP flooding, route calculation, and FIB entry delivery,
must be performed to switch traffic to a new link. As a result, the fault recovery time is much
greater than 50 ms, the time for users to sense traffic interruption, which cannot meet the
requirement for real-time services.
Implementation Principle
OSPF IP FRR pre-computes a backup link by using the Loop-Free Alternate (LFA) algorithm,
and then adds the backup link and the primary link to the forwarding table. In the case of failures,
OSPF IP FRR can fast switch traffic to the backup link before routes on the control plane
converge. This prevents traffic interruption and thus protects traffic and improves reliability of
an OSPF network. The Router supports IPv4 OSPF IP FRR.
In the LFA algorithm, considering a neighbor that can provide a backup link as the root node,
the neighbor computes the shortest path from itself to the destination of the primary link by using
the SPF algorithm. The neighbor then computes a loop-free backup link with the smallest cost
by using the inequality defined in RFC 5286.
OSPF IP FRR can filter backup routes that need to be added to the IP routing table. Only the
backup routes that are filtered through the filtering policy are added to the IP routing table. In
this manner, users can flexibly manage the addition of OSPF backup routes to the IP routing
table.
Application Environment
OSPF IP FRR is classified into link protection and link-node dual protection. Distance_opt(X,Y)
indicates the shortest path between node X and node Y.
Link protection: indicates that the object to be protected is the traffic passing through an OSPF
IP FRR-enabled link. The link cost must satisfy the inequality Distance_opt(N, D) <
Distance_opt(N, S) + Distance_opt(S, D). S indicates the source node of traffic; N indicates the
node on the backup link; D indicates the destination node of traffic.
As shown in Figure 5-10, traffic is transmitted from RouterS to RouterD. The link cost satisfies
the link protection inequality. When the primary link fails, RouterS switches the traffic to the
backup link RouterS -> RouterN so that the traffic can be further transmitted along downstream
paths. This ensures that traffic interruption is less than 50 ms.
Figure 5-10 OSPF IP FRR link protection

cost = 10 cost = 5
RouterS RouterE RouterD

=5
co
st
st
co
=1
0
RouterN
Link-node dual protection: Figure 5-11 shows link-node dual protection of OSPF IP FRR. Node
protection takes precedence over link protection.

Routers
Link-node dual protection must satisfy the following situations:
The link cost must satisfy the inequality Distance_opt(N, D) < Distance_opt(N, S) +
Distance_opt(S, D).
The interface cost of the router must satisfy the inequality Distance_opt(N, D) < Distance_opt
(N, E) + Distance_opt(E, D).
S indicates the source node of traffic; E indicates the faulty node; N indicates the node on the
backup link; D indicates the destination node of traffic.
Figure 5-11 OSPF IP FRR link-node dual protection
cost = 15 cost = 5
RouterE
RouterS RouterD
co
st= =5
10 st
co
RouterN
5.2.11 OSPF-BGP Association
Definition
When a new device is deployed in the network or a device is restarted, network traffic may be
lost during BGP convergence. This is because IGP convergence is faster than BGP convergence.
This problem can be solved through the synchronization between OSPF and BGP.
Purpose
If a backup link exists, during traffic switchback, BGP traffic is lost because BGP route
convergence is slower than OSPF route convergence.
As shown in Figure 5-12, RouterA, RouterB, RouterC, and RouterD run OSPF and establish
IBGP connections. RouterC functions as the backup of RouterB. When the network is stable,
BGP and OSPF routes converge completely on the device.
Normally, traffic from RouterA to 10.3.1.0/30 passes through RouterB. When RouterB becomes
faulty, traffic is switched to RouterC. After RouterB recovers, traffic is switched back to
RouterB. During this process, packet loss occurs.
This is because when traffic is switched back to RouterB, IGP route convergence is faster than
BGP route convergence. Consequently, convergence of OSPF routes is already complete when
BGP route convergence is still going on. As a result, RouterB does not know the route to
10.3.1.0/30.
Therefore, when packets from RouterA to 10.3.1.0/30 arrive at RouterB, they are discarded
because RouterB does not have the route to 10.3.1.0/30.

Routers
Figure 5-12 OSPF-BGP synchronization
RouterC
RouterF
POS2/0/0 POS1/0/0
10.1.2.2/30 10.1.4.1/30 POS1/0/0
10.3.1.2/30
POS1/0/0 POS2/0/0
POS2/0/0 10.1.4.2/30 10.3.1.1/30
10.1.2.1/30 EBGP
RouterA RouterD RouterE
POS1/0/0 POS3/0/0
10.1.1.1/30 10.2.1.1/30 POS1/0/0
POS2/0/0 10.2.1.2/30
10.1.3.2/30
POS1/0/0 POS2/0/0
10.1.1.2/30 10.1.3.1/30
AS 10 RouterB AS 20
Principle
The device enabled with OSPF-BGP synchronization remains as a stub router within the set
synchronization period. That is, the link metric in the LSA advertised by the device is the
maximum value 65535. Therefore, the device instructs other OSPF devices not to use it for data
forwarding.
As shown in Figure 5-12, OSPF-BGP synchronization is enabled on RouterB. In this situation,
before BGP route convergence is complete, RouterA continues to use the backup link RouterC
rather than forward traffic to RouterB until BGP route convergence on RouterB is complete.
5.2.12 OSPF GR
Routers generally operate with separation of the control plane and forwarding plane. When the
network topology remains stable, a restart of the control plane does not affect the forwarding
plane, and the forwarding plane can still forward data properly. This separation ensures non-
stop service forwarding.
In graceful restart (GR) mode, the forwarding plane continues to direct data forwarding after a
restart occurs. The actions on the control plane, such as re-establishment of neighbor
relationships and route calculation, do not affect the forwarding plane. Network reliability is
improved because service interruption caused by route flapping is prevented.
Basic Concepts of OSPF GR

Graceful Restart (GR) is a technology used to ensure normal traffic forwarding and non-stop
forwarding of key services during the restart of routing protocols.
Unless otherwise stated, GR described in this section refers to the GR technology defined in
RFC 3623.
GR is one of the high availability (HA) technologies, which comprise a set of comprehensive
technologies, such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic
engineering. As a fault-tolerant redundancy technology, GR is widely used to ensure non-stop
forwarding of key services during master/slave switchover and system upgrade.

Routers
The following concepts are involved in GR:
l Grace-LSA
OSPF supports GR by flooding Grace-LSAs. Grace-LSAs are used to inform the neighbor
of the GR time, cause, and interface address when the GR starts and ends.
l Role of a router during GR
Restarter: is the router that restarts. The Restarter can be configured to support totally
GR or partly GR.
Helper: is the router that helps the Restarter. The Helper can be configured to support
planned GR or unplanned GR or to selectively support GR through the configured
policies.
l Conditions that cause GR
Unknown: indicates that GR is triggered for an unknown reason.
Software restart: indicates that GR is triggered by commands.
Software reload/upgrade: indicates that GR is triggered by software restart or upgrade.
Switch to redundant control processor: indicates that GR is triggered by the abnormal
master/slave switchover.
l GR period
The GR period cannot exceed 1800 seconds. OSPF routers can exit from GR regardless of
whether GR succeeds or fails, without waiting for GR to expire.
Classification of OSPF GR
l Totally GR: indicates that when a neighbor of a router does not support GR, the router exits
from GR.
l Partly GR: indicates that when a neighbor does not support GR, only the interface associated
with this neighbor exits from GR, whereas the other interfaces perform GR normally.
l Planned GR: indicates that a router restarts or performs the master/slave switchover using
a command. The Restarter sends a Grace-LSA before restart or master/slave switchover.
l Unplanned GR: indicates that a router restarts or performs the master/slave switchover
because of faults. A router performs the master/slave switchover, without sending a Grace-
LSA, and then enters GR after the slave board goes Up. The process of unplanned GR is
the same as that of planned GR.
GR Process
l A router starts GR.
In planned GR mode, after master/slave switchover is triggered through a command, the
Restarter sends a Grace-LSA to all neighbors to notify them of the start, period, and cause
of GR, and then performs the master/slave switchover.
In unplanned GR, the Restarter does not send the Grace-LSA.
In unplanned GR mode, the Restarter sends a Grace-LSA immediately after the slave board
goes Up, informing neighbors of the start, period, and cause of GR. The Restarter then
sends a Grace-LSA to each neighbor five times consecutively. This ensures that neighbors
receive the Grace-LSA. This operation is proposed by manufacturers but not defined by
the OSPF protocol.

Routers
The Restarter sends a Grace-LSA to notify neighbors that it enters GR. During GR,
neighbors keep neighbor relationships with the Restarter so that other routers cannot detect
the switchover of the Restarter.
l The GR process runs, as shown in Figure 5-13.
Figure 5-13 OSPF GR process
RouterA RouterB
Restarter Helper
Before the active/ Grace-LSA
Enter Helper
standby switchover
Switchover Return LSAck
LSAck
Finish switchover packet for the
received LSA
Grace-LSA Updates the GR
Enter GR period for the
Grace-LSAs received
Grace-LSAs
Send Hello packets, negotiate,
exchange
Full DD packets, and synchronize LSDB
Exit GR Exit the Helper
successfully, Flush Grace-LSA successfully and
calculate routes, and generate Router-
generate LSA LSA
l The router exits from GR.
Table 5-13 Reasons that a router exits GR
Executi Restarter Helper

on of
GR
GR Before GR expires, the Restarter re- After the Helper receives the
succeed establishes neighbor relationships with all Grace-LSA with the Age being
s. neighbors before master/slave 3600s from the Restarter, the
switchover. neighbor relationship between
the Helper and Restarter enters
the Full state.

Routers
Executi Restarter Helper

on of
GR
GR l GR expires, and neighbor l Helper does not receive the

fails. relationships do not recover Grace-LSA from Restarter
completely. before the neighbor
l Router-LSA or Network-LSA sent by relationship expires.
the Helper causes Restarter to fail to l Status of the interface that
perform bidirectional check. functions as the Helper
l Status of the interface that functions as changes.
the Restarter changes. l Helper receives the LSA that
l Restarter receives the one-way Hello is inconsistent with the LSA
packet from the Helper. in the local LSDB from
another router. This situation
l The Restarter receives the Grace-LSA can be excluded after the
that is generated by another router on Helper is configured not to
the same network segment. Only one perform strict LSA check.
router can perform GR on the same
network segment. l Helper receives Grace-LSAs
from two routers on the same
l On the same network segment, network segment at the same
neighbors of the Restarter have time.
different DRs or BDRs because of the
topology changes. l Neighbor relationships
between Helper and other
neighbors change.
Comparison Between GR Mode and Non-GR Mode
Table 5-14 Comparison of master/slave switchover in the GR mode and non-GR mode
Switchover in Non-GR Mode Switchover in GR Mode
l OSPF neighbor relationships are re- l OSPF neighbor relationships are re-
established. established.
l Routes are recalculated. l Routes are recalculated.
l Forwarding table changes. l Forwarding table remains unchanged.
l Entire network detects route changes, l Except for neighbors of the device where
and route flapping occurs for a short master/slave switchover occurs, other
period of time. routers do not detect route changes.
l Packets are lost during forwarding, and l No packets are lost during forwarding, and
services are interrupted. services are not affected.

Routers
5.2.13 OSPF-LDP Association
Definition
In the networking that uses primary and backup links, when the faulty primary link recovers,
traffic is switched from the backup link back to the primary link.
IGP route convergence completes before an LDP session is established. Consequently, the old
LSP is deleted before the new LSP is established and LSP traffic is interrupted.
Purpose
As shown in Figure 5-14, the primary link adopts the path PE1P1P2P3PE2, and the
backup link adopts the path PE1P1P4P3PE2.
When the primary link is faulty, traffic is switched to the backup link. After the primary link
recovers, traffic is switched back to the primary link. During this process, traffic is interrupted
for a long period of time.
Figure 5-14 OSPF-LDP association
P2
PE1 P1 P3 PE2
Primary link
Backup link
P4
Synchronizing Label Distribution Protocol(LDP) and IGP on P1 and P2 can shorten traffic
interruption caused by traffic switchover from the backup link to the primary link.
Table 5-15 OSPF-LDP association
Enabling Status of OSPF-LDP Traffic Interruption Time

Association
Not enabled. Seconds level
Enabled. Milliseconds level

Routers
Principle
The principle of LDP-IGP synchronization is to delay route switchback by suppressing the
establishment of IGP neighbor relationships until LDP convergence is complete. That is, before
an LSP on the primary link is established, the backup link continues to forward traffic. Then the
link is deleted after the LSP is established.
Synchronization of LDP and IGP involves three timers:
l Hold-down
l Hold-max-cost
l Delay
After the primary link recovers, a router responds as follows:
1. Starts the hold-down timer. The IGP interface does not establish IGP neighbors but waits
for establishment of an LDP session. The Hold-down timer specifies the period that the
IGP interface waits.
2. Starts the hold-max-cost timer after the hold-down timer expires. The hold-max-cost timer
specifies the interval for advertising the maximum link metric of the interface in the Link
State Advertisement (LSA) to the primary link.
3. Starts the Delay timer to allow time for establishment of an LSP after an LDP session is
re-established for the faulty link.
4. After the Delay timer expires, LDP notifies IGP that synchronization is complete regardless
of the status of IGP.
5.2.14 OSPF Database Overflow
Definition
OSPF requires that routers in the same area have the same Link-State Database (LSDB).
With the continuous increase in routes on the network, some routers fail to carry the additional
routing information because of limited system resources. This situation is called OSPF database
overflow.
Purpose
You can configure stub areas or NSSAs to solve the problem of the continuous increase in routing
information that causes the exhaustion of system resources of routers. However, configuring
stub areas or NSSAs cannot solve the problem when the unexpected increase in dynamic routes
causes database overflow. Setting the maximum number of external LSAs in the LSDB can
dynamically limit the LSDB capacity, to avoid the problems caused by database overflow.
Principle
To prevent database overflow, you can set the maximum number of non-default external routes
on a router.
All routers on the OSPF network must be set with the same upper limit. If the number of external
routes on a router reaches the upper limit, the router enters the Overflow state and starts an

Routers
overflow timer. The router automatically exits from the overflow state after the timer expires,
By default, it is 5 seconds.
Table 5-16 OSPF database overflow
Overflow Phase OSPF Processing
Entering overflow state A router deletes all non-default external routes that is
generated.
Staying in overflow state l Router does not generate non-default external routes.
l Router discards the newly received, non-default external
routes, and does not reply with an LSAck packet.
l When the overflow timer expires, the router checks
whether the number of external routes still exceeds the
upper limit.
If so, the router restarts the timer.
If not, the router exits from overflow state.
Exiting from the overflow l Router deletes the overflow timer.

state l Router generates non-default routes.
l Router learns the newly received non-default routes, and
replies with an LSAck packet.
l Router prepares to enter Overflow state for the next time
it occurs.
5.2.15 OSPF Mesh-Group
Definition
In the scenario where there are multiple concurrent links, you can deploy OSPF mesh-group to
classify links into a mesh group. Then, OSPF floods LSAs to only a link selected from the mesh
group. Using OSPF mesh-group prevents unnecessary burden on the system caused by repetitive
flooding.
The mesh-group feature is disabled by default.
Purpose
After receiving or generating an LSA, an OSPF process floods the LSA. When there are multiple
concurrent links, OSPF floods the LSA to each link and sends Update messages.
In this scenario, if there are 2000 concurrent links, OSPF floods each LSA 2000 times. Only one
flooding, however, is valid. The other 1999 times are useless repetition.
To prevent burden on the system caused by repetitive flooding, you can enable mesh-group to
classify multiple concurrent links between a router and its neighbor into a group and then select
a primary link to use for flooding.

Routers
Principles
As shown in Figure 5-15, RouterA and RouterB, which are connected through three links,
establish an OSPF neighbor relationship. After receiving a new LSA from interface 4, RouterA
floods the LSA to RouterB through interfaces 1, 2, and 3.
This flooding causes a heavy load on the concurrent links. For the neighbor with concurrent
links, only a primary link is selected to flood the LSA.
Figure 5-15 LSA flooding with OSPF mesh-group disabled

1 LSA
LSA 4 2 LSA
RouterA 3 LSA RouterB
When multiple concurrent links exist between a device enabled with OSPF mesh-group and its
neighbor, the device selects to flood the received LSAs, as shown in Figure 5-16.
Figure 5-16 LSA flooding with OSPF mesh-group enabled

1 LSA
LSA 4 2 LSA
3 LSA
RouterA RouterB
As defined in OSPF, LSAs can be flooded to a link only when the neighbor status is not lower
than Exchange. In this case, when the status of the interface on the primary link is lower than
Exchange, OSPF reselects a primary link from the concurrent links and then floods the LSA.
After receiving the LSA flooded by RouterA from link 1, RouterB no longer floods the LSA to
RouterA through interfaces 2 and 3.
As defined by the mesh-group feature, the Router ID of a neighbor uniquely identifies the mesh
group. Interfaces connected to the same neighbor that have a status greater than Exchange belong
to the same mesh group.
In Figure 5-17, a mesh group of RouterA resides in Area 0, which contains the links of interface
1 and interface 2. More than one neighbor of interface 3 resides on the broadcast link. Therefore,
interface 3 cannot be defined as part of the mesh group.

Routers
Figure 5-17 Interface not added to mesh group
4 2
RouterB
RouterA
3
Area0
NOTE
After a router is enabled with mesh-group, if the Router IDs of the router and its directly connected neighbor
are the same, LSDBs cannot be synchronized and routes cannot be calculated correctly. In this case, you
need to reconfigure the Router ID of the neighbor.
5.3 OSPF Applications

This section describes applications of OSPF.
5.3.1 OSPF GR
In Figure 5-18, RouterA, RouterB, RouterC, and RouterD run OSPF for interworking, and
RouterA and RouterB are enabled with GR. When RouterA restarts, RouterB helps RouterA
perform GR, without notifying other neighbors of RouterA. OSPF GR ensures non-interrupted
network traffic.
Figure 5-18 OSPF GR
es RouterC
B do ter
r ou
ute y R r A
Ro notif oute
t R
Set up neighbor no that tarts
relationship and C re s
RouterA RouterB
negotiate GR
Restarter Helper Rou

noti ter B d RouterD
Restart fy R oes
Rou ou n o
ter A ter D t t
rest hat
arts

Routers
5.3.2 OSPF GTSM

As shown in Figure 5-19, OSPF runs between Routers, and GTSM is enabled on RouterC. The
following are the valid TTL ranges of the packets that are sent from Routers to RouterC:
l RouterA and RouterE are the neighbors of RouterC, and their valid TTL range of packets
is [255 - hops + 1, 255].
l The valid TTL ranges of the packets sent from RouterB, RouterD, and RouterF to RouterC
are respectively [254, 255], [253, 255], and [252, 255].
Figure 5-19 OSPF GTSM
RouterA Area0 RouterB

POS1/0/0 POS1/0/0
192.168.0.1/24 192.168.0.2/24
POS2/0/0 POS2/0/0
192.168.1.1/24 192.168.2.1/24
POS1/0/0 POS1/0/0
192.168.1.2/24 192.168.2.2/24
RouterC RouterD
GE2/0/0 GE2/0/0
172.16.1.1/24 172.17.1.1/24
GE2/0/0 GE2/0/0
172.16.1.2/24 172.17.1.2/24
RouterE RouterF
Area1 PC Area2

After basic OSPF functions are configured, you can build a basic OSPF network. If other OSPF
functions are required, configure them according to reference sections.
Table 5-17 describes the OSPF configuration tasks.

Routers
Table 5-17 Table 1 OSPF configuration tasks
Configuring Basic OSPF The configuration of basic 5.6.1 Configuring Basic

Functions OSPF functions is the OSPF Functions
foundation of the OSPF 5.6.2 Setting Parameters
network construction and the for OSPF Neighbor
precondition for other OSPF Relationship
functions.
5.6.3 Configuring OSPF
Attributes in Different
Types of Networks
Configuring OSPF Areas l In a stub area, the area 5.6.4 Configuring OSPF
border router (ABR) does Stub Areas
not transmit learned 5.6.5 Configuring OSPF
autonomous system (AS) NSSA Areas
external routes. This
implementation reduces
entries in the routing
tables on ABRs in stub
areas and the amount of
routing information to be
transmitted.
l An NSSA is a new type of
OSPF area. Neither the
NSSA nor the stub area
transmits routes learned
from other areas in the AS
where it resides. Different
from the stub area, the
NSSA allows AS external
routes to be imported and
forwarded in the entire
AS.
Adjusting OSPF Route To use OSPF more flexibly 5.6.6 Adjusting OSPF
Selection on the existing network and Route Selection
meet various user
configure different
parameters to control OSPF
routing.
Controlling OSPF Routing In practical applications, to 5.6.7 Controlling OSPF

Information meet network requirements, Routing Information
you can configure different
parameters to accurately
control the advertising and
receiving of OSPF routes.

Routers
Improving the Reliability of l OSPF IP FRR pre- 5.6.8 Configuring OSPF IP

an OSPF Network computes a backup link FRR
by using the Loop-Free 5.6.9 Configuring BFD for
Alternate (LFA) OSPF
algorithm, and then adds
the backup link and the 5.6.11 Configuring OSPF
primary link to the GR Helper
forwarding table. In the
case of failures, OSPF IP
FRR can fast switch
traffic to the backup link
before routes on the
control plane converge.
This prevents traffic
interruption and thus
protects traffic and
improves reliability of an
OSPF network.
l By default, on broadcast
networks, the interval for
OSPF to send Hello
packets is 10 seconds; on
NBMA networks, the
interval for sending Hello
packets is 30 seconds.
The interval for declaring
a neighbor Down, that is,
the dead time after which
the neighbor relationship
becomes invalid, is four
times the interval for
sending Hello packets. If
the router does not receive
a Hello packet from its
neighbor within the dead
time, the router deletes
the neighbor. That is, the
router detects the
neighbor faults in
seconds. This causes a
large number of packets
to be lost on a high-speed
network.
Bidirectional Forwarding
Detection (BFD) is
introduced to solve the
preceding problem in the
existing detection

Routers
mechanism. BFD ensures

the detection interval in
milliseconds. Instead of
replacing the Hello
mechanism of OSPF,
BFD works with OSPF to
fast detect the adjacency
fault. In addition, BFD
instructs OSPF to
recalculate corresponding
routes for correct packet
forwarding.
l When a router restarts or
performs the active/
standby switchover, it
directly ages all routing
entries in the Forward
Information Base (FIB)
table. This results in route
interruption. In addition,
neighboring routers
remove this router from
the neighbor list, and
notify other routers. This
causes the re-calculation
of SPF. If this router
recovers within a few
seconds, the neighbor
relationship becomes
unstable. This results in
route flapping.
After being enabled with
OSPF Graceful Restart
(GR), a router can ensure
continuous packet
forwarding if it restarts
just for abnormities. In
such a case, route
flapping is avoided
during the short restart of
the router.

Routers
Improving the Stability of an In practical applications, you 5.6.12 Improving the

OSPF Network can improve the stability of Stability of an OSPF
the OSPF network to reduce Network
route flapping on the OSPF
network and enable the
device to work in a normal
state for a long time.
Improving the Security of an In a network demanding high 5.6.13 Improving the

OSPF Network security, you can configure Security of an OSPF
OSPF authentication and Network
adopt the GTSM mechanism
to improve the security of the
OSPF network.

This section describes the default configuration of OSPF, which can be changed according to
Table 5-18 describes the default configuration of OSPF.
Table 5-18 Default configuration of OSPF
OSPF Disabled
The interval of sending Hello By default, for the interface of P2P and Broadcast type,
packets the interval for sending Hello packets is 10 seconds; for
the interface of NBMA type, it is 30 seconds.
The dead interval of the OSPF By default, for the interface of P2P and Broadcast, the
neighbor dead interval for the OSPF neighbors is 40 seconds; for
that of NBMA, it is 120 seconds.
The period during which a 500 seconds.

device keeps acting as a stub
router.
The bandwidth reference value 100 Mbit/s

used to calculate the link cost.
5.6 Configuring OSPF


Routers
5.6.1 Configuring Basic OSPF Functions

Before building OSPF networks, you need to configure basic OSPF functions.
When OSPF is configured on multiple routers in the same area, most configuration data, such
as the timer, filter, and aggregation, must be planned uniformly in the area. Incorrect
configurations may cause neighboring routers to fail to send messages to each other or even
causing routing information congestion and self-loops.
The OSPF-relevant commands that are configured in the interface view take effect regardless
of whether OSPF is enabled. After OSPF is disabled, the OSPF-relevant commands also exist
on interfaces.
Before configuring basic OSPF functions, complete the following tasks:
l Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer
Figure 5-20 Flowchart of configuring basic OSPF functions
Create an OSPF process
Create an OSPF area
Enable OSPF
Restricting the Flooding of LSA

Creating OSPF Virtual Links
Update Packets
Mandatory
procedure
Optional
procedure
5.6.1.1 Creating an OSPF Process
Context
To run OSPF, the router needs to have a router ID. A router ID of the router is a 32-bit unsigned
integer, which uniquely identifies the router in an AS. To ensure the stability of OSPF, you need
to manually configure a router ID for each device during network planning.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *
An OSPF process is created, and the OSPF view is displayed.
l The parameter process-id specifies the ID of an OSPF process. The default value is 1.
The router supports OSPF multi-process. You can create different processes for different
types of service. The OSPF process ID is valid in the local area, without affecting packet
exchange with other routers. Therefore, different routers can also exchange packets even
though they have different process IDs.
l The parameter router-id router-id specifies the router ID of the router.
By default, the system automatically selects an IP address of the interface as the router ID.
The largest IP address in loopback addresses is taken as the router ID. If no loopback interface
is configured, the largest IP address configured on the interface is selected as the router ID..
When manually setting a router ID, ensure that the router ID of each device in an AS is
unique. Generally, you can set the router ID to be the same as the IP address of a certain
interface on the device.
NOTE
The router ID of each OSPF process must be unique on the OSPF network; otherwise, the OSPF
neighbor relationship cannot be set up and routing information is incorrect. Configuring a unique router
ID for each OSPF process on each OSPF device is recommended.
l The parameter vpn-instance vpn-instance-name specifies the name of a VPN instance.
If a VPN instance is specified, the OSPF process belongs to the specified VPN instance.
Otherwise, the OSPF process belongs to the public network instances.
----End
5.6.1.2 Creating an OSPF Area
Context
More and more devices are deployed with the increasing expansion of the network scale. As a
result, each device has to maintain a large LSDB, which becomes a heavy burden. OSPF solves
this problem by dividing an AS into areas. An area is regarded as a logical device group. Each
group is identified by an area ID. The borders of an area are devices, rather than links. A network
segment (or a link) belongs to only one area. That is, each OSPF interface must belong to an
area.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
The OSPF process is enabled, and the OSPF view is displayed.
Step 3 Run:
area area-id
The OSPF area view is displayed.
Areas are not equally important. The area with the area ID being 0 is called the backbone area.
The backbone area is responsible for forwarding inter-area routing information. In addition,
routing information between non-backbone areas must be forwarded through the backbone area.
----End
5.6.1.3 Enable OSPF
Context
After creating an OSPF process, you need to configure the network segments included in an
area. A network segment belongs to only one area. That is, you need to specify an area for each
interface that runs OSPF. In this document, the network segment refers to the network segment
to which the IP address of the OSPF interface belongs.
OSPF checks the network mask carried in a received Hello packets. If the network mask carried
in a received Hello packet is different from the network mask of the local device, the Hello
packet is discarded. Then no OSPF neighbor relationship can be established.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run:
area area-id
OSPF can be enabled in an OSPF area or on a specific interface.
l Enable OSPF in an OSPF area.

1. Run:
network ip-address wildcard-mask
Network segments belonging to an area are configured.
OSPF can properly run on an interface only when the following conditions are met:

Routers
l The IP address mask length of the interface is equal to or greater than the mask length
specified in the network command.
l The primary IP address of the interface must be within the network segment specified
by the network command.
By default, OSPF advertises the IP address of the loopback interface as a 32-bit host route,
which is irrelevant to the mask length configured on the loopback interface. To advertise
routes to the network segment of the loopback interface, configure the network type as
NBMA or broadcast in the interface view. For details, see Configuring Network Types
of OSPF Interfaces.
l Enable OSPF on an interface.
1. Run the following command in the system view:

2. Run:
ospf enable [ process-id ] area area-id
OSPF is enabled on the interface.
An area ID can be input in the format of a decimal integer or an IPv4 address, but displayed
in the format of IPv4 address.
----End
5.6.1.4 (Optional) Creating OSPF Virtual Links
Context
After OSPF areas are defined, OSPF route updates between non-backbone areas are transmitted
through a backbone area. Therefore, OSPF requires that all non-backbone areas maintain the
connectivity with the backbone area and the backbone areas in different OSPF areas maintain
the connectivity with each other. In real world situations, this requirement may not be met
because of some restrictions. To resolve this problem, you can configure OSPF virtual links.
Perform the following steps on the router running OSPF.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id

Routers
Step 4 Run:
vlink-peer router-id [ smart-discover | hello hello-interval | retransmit
retransmit-interval | trans-delay trans-delay-interval | dead dead-interval |
[ simple [ plain plain-text | [ cipher ] cipher-text ] | { md5 | hmac-md5 | hmac-
sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ] | authentication-
null | keychain keychain-name ] ] *
A virtual link is created.
This command must also be configured on the neighboring router.
----End
Follow-up Procedure
After virtual links are created, different default MTUs may be used on devices provided by
different vendors. To ensure consistency, the MTU is set to 0 by default when the interface sends
DD packets. For details, see Configuring an Interface to Fill in the DD Packet with the Actual
MTU.
5.6.1.5 (Optional) Restricting the Flooding of LSA Update Packets
Context
When multiple neighboring routers are configured or a large number of LSA update packets are
flooded, the neighboring router may receive a large number of LSA update packets in a short
period. This keeps the neighboring router busy processing a burst of LSA update packets and
causes the neighboring router to unexpectedly discard Hello packets that are used to maintain
the OSPF neighbor relationships. As a result, the neighbor relationships are interrupted. After
the neighbor relationships are reestablished, more packets are to be exchanged. This intensifies
neighbor relationship interruption. To resolve this problem, you can restrict the flooding of LSA
update packets to maintain neighbor relationships.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
flooding-control [ number transmit-number | timer-interval transmit-interval ] *
The flooding of LSA update packets is restricted.
By default, the number of LSA update packets to be flooded each time is 50, and the interval at
which LSA update packets are flooded is 30s.

Routers
After the flooding-control command is run, the flooding of LSA update packets is immediately
restricted.
If the flooding-control command is not run, the function of restricting the flooding of LSA
update packets automatically takes effect when the number of neighboring routers exceeds 256.
----End
Prerequisites
All configurations of basic OSPF functions are complete.
Procedure
l Run the display ospf [ process-id ] peer command in any view to check information about
OSPF neighbors.
l Run the display ospf [ process-id ] interface command in any view to check information
about OSPF interfaces.
l Run the display ospf [ process-id ] routing command in any view to check information
about the OSPF routing table.
l Run the display ospf [ process-id ] lsdb command to check OSPF LSDB information.
----End
5.6.2 Setting Parameters for OSPF Neighbor Relationship

On an OSPF network, all routing information is transmitted and exchanged between neighboring
or adjacent devices. By maintaining neighbor relationships or adjacencies, you can stabilize the
entire network.
Before configuring session parameters for the OSPF neighbor or adjacency relationship,
complete the following tasks:
l Configuring a link layer protocol

the network layer
l 5.6.1 Configuring Basic OSPF Functions
You can choose one or several configuration tasks (excluding "Checking the Configuration") as
required.
5.6.2.1 Setting the OSPF Packet Retransmission Limit

Routers
Context
After an OSPF router sends one of the following packets, if it does not receive the LSAck packet
within a specified time, it retransmits the packet. After the number of packet retransmissions
reaches the set limit, the OSPF router tears down the adjacency relationship with its neighbor.
l DD packets
l LSU packets
l LSR packets
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
The OSPF view is displayed.
Step 3 Run:
retransmission-limit [ max-number ]
The OSPF packet retransmission limit is set.
By default, the OSPF packet retransmission limit is not set. The default maximum number of
packet retransmissions is 30.
----End
5.6.2.2 Configuring an Interface to Fill in the DD Packet with the Actual MTU
Context
After virtual links are created, different default MTUs may be used on devices provided by
different vendors. To ensure consistency, the MTU is set to 0 by default when the interface sends
DD packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The OSPF interface view is displayed.
Step 3 Run:
ospf mtu-enable

Routers
The interface is configured to fill in the DD packet with the actual MTU and check whether the
MTU in the DD packet from the neighbor exceeds the MTU of the local end.
By default, the MTU in the DD packet sent by an interface is 0.
NOTICE
Setting the MTU in a DD packet will lead to the reestablishment of the neighbor relationship.
----End
Prerequisites
All configurations of session parameters of the OSPF neighbor or adjacency relationship are
complete.
Procedure
l Run the display ospf [ process-id ] peer command to check information about OSPF
neighbors.
l Run the display ospf [ process-id ] brief command to check brief information about the
specified OSPF process.
l Run the display ospf [ process-id ] retrans-queue [ interface-type interface-number ]
[ neighbor-id ] [ low-level-of-retrans-times-range min-time ] [ high-level-of-retrans-
times-range max-time ] command to check the OSPF retransmission list.
----End
5.6.3 Configuring OSPF Attributes in Different Types of Networks

By setting network types for OSPF interfaces and adjusting OSPF attributes, you can build OSPF
networks flexibly.
As shown in Table 5-19, OSPF classifies networks into four types based on the types of link
layer protocols.
NOTE
Differentiated OSPF configurations that are applicable to the NBMA network and P2MP network are
provided in this section.The OSPF configurations not provided here are applicable to the four types of
networks.

Routers
Table 5-19 Network types supported by OSPF
Network Type Characteristic Default Configuration
Broadcast On the broadcast network, Hello If the link layer protocol is

packets, LSU packets, and LSAck Ethernet or Fiber Distributed Data
packets are multicasted; DD Interface (FDDI), OSPF regards
packets and LSR packets are the network as a broadcast
unicasted. network by default.
Non-broadcast On an NBMA network, Hello If the link layer protocol is ATM,

multiple access packets, DD packets, LSR OSPF regards the network as an
(NBMA) packets, LSU packets, and LSAck NBMA network by default.
packets are unicasted.
The NBMA network must be fully
meshed. Any two routers on the
NBMA network must be directly
reachable.
Point-to-point On a P2P network, Hello packets, If the link layer protocol is PPP,
(P2P) DD packets, LSR packets, LSU HDLC, or Link Access Procedure
packets, and LSAck packets are Balanced (LAPB), OSPF regards
multicasted. the network as a P2P network by
default.
Point-to- On a P2MP network, Hello OSPF does not regard a network as

multipoint (P2MP) packets are multicasted; DD a P2MP network by default
packets, LSR packets, LSU regardless of any link layer
packets, and LSAck packets are protocol. A P2MP network is
unicasted. forcibly changed from the network
of another type.
As shown in Table 5-19, OSPF sends packets in different manners on networks of different
types. Therefore, the difference between OSPF configurations on the networks lies in the packet
sending configurations.
Before configuring OSPF attributes in different types of networks, complete the following tasks:
the network layer
Configuring network types of OSPF interfaces is the prerequisite for configuring P2MP or
NBMA network attributes

Routers
5.6.3.1 Configuring Network Types of OSPF Interfaces
Context
By default, the physical interface type determines the network type.
l The network type of an Ethernet interface is Broadcast.

l The network type of a serial interface running PPP or HDLC is P2P.
l The network type of an ATM interface or a Frame Relay (FR) interface is NBMA.
NOTE
l A P2MP network is forcibly changed from another other type of network.

l AR150&200 series do not support Frame-relay interface.
The network types of the interfaces on both ends of a link must be the same; otherwise, the OSPF
neighbor relationship cannot be established.
l When the network type of one OSPF interface is broadcast and the network type of the
other OSPF interface is P2P, the two interfaces can still set up the neighbor relationship.
but cannot learn the OSPF routing information each other.
l When the network types of OSPF interfaces on both ends of a link are P2MP and P2P, the
two OSPF interfaces can establish OSPF neighbor relationship but cannot learn routing
information from each other. To enable the interfaces to learn routing information from
each other, configure the same interval for sending Hello packets and same neighbor
holdtime on the two OSPF interfaces.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospf network-type { broadcast | nbma | p2mp | p2p }
The network type of the OSPF interface is configured.
By default, the network type of an interface depends on the physical interface. The network type
of an Ethernet interface is broadcast; the network type of a serial or POS interface (encapsulated
with PPP or HDLC) is P2P; the network type of a ATM and FR interface is NBMA.
When the network type is configured for an interface, the original network type of the interface
is replaced.
The network type can be configured based on the real world situations.
l On an interface with the broadcast network type, if a router that does not support the multicast
address exists, change the network type of the interface to NBMA.

Routers
l On an interface with the NBMA network type, if the network is fully meshed or any two
routers are directly connected, change the network type of the interface to broadcast and do
not configure neighboring router information on the interface.
l On an interface with the NBMA network type, if the network is not fully meshed, change
the network type of the interface to P2MP. After that, two indirectly connected routers can
communicate through one router that can directly reach both the two routers. After the
network type of the interface is changed to P2MP, configuring neighboring router
information on the interface is unnecessary.
l If only two routers run OSPF on the same network segment, changing the network type of
the interface to P2P is recommended.
NOTE
OSPF cannot be configured on a null interface.
----End
5.6.3.2 Configuring P2MP Network Attributes
Procedure
Step 1 Disable OSPF from checking the network mask.
1. Run:
system-view

2. Run:

3. Run:
ospf network-type p2mp
The network type of the OSPF interface is configured.

A P2MP network is forcibly changed from another other type of network. For details, see
Configuring Network Types for OSPF Interfaces.
4. Run:
ospf p2mp-mask-ignore
OSPF is disabled from checking the network mask on the P2MP network.
Step 2 Configure the router to filter the LSA packets to be sent.
When multiple links exist between two routers, you can configure the local router to filter the
LSA packets to be sent. This can reduce unnecessary LSA retransmission attempts and save
bandwidth resources.
1. Run:
quit
Exit from the interface view.

2. Run:
ospf [ process-id ]

Routers

3. Run:
filter-lsa-out peer ip-address { all | { summary [ acl { acl-number | acl-
name } ] | ase [ acl { acl-number | acl-name } ] | nssa [ acl { acl-number |
acl-name } ] } * }
The local router is configured to filter the LSA packets to be sent on the P2MP network.
By default, the LSA packets to be sent are not filtered.
----End
5.6.3.3 Configuring NBMA Network Attributes
Procedure
Step 1 (Optional) Set the network type to NBMA.
The NBMA network must be fully meshed. Any two routers on the NBMA network must be
directly reachable. In most cases, however, this requirement cannot be met. To resolve this
problem, run specific commands to forcibly change the network type to NBMA. For details, see
Configuring Network Types for OSPF Interfaces.
1. Run:
system-view

2. Run:

3. Run:
ospf network-type nbma
The network type of the OSPF interface is set to NBMA.
Step 2 (Optional) Set the interval at which Hello packets for polling are sent on the NBMA network.
On the NBMA network, after the neighbor relationship becomes invalid, the router sends Hello
packets at an interval defined in the polling mechanism.
1. Run:
ospf timer poll interval
The interval at which Hello packets for polling are sent by an NBMA interface is set.
The default value is 120, in seconds.
Step 3 Configure a neighboring router on the NBMA network.
The interface with the network type of NBMA cannot broadcast Hello packets to discover
neighboring routers. Therefore, the IP address of a neighboring router must be configured on
the interface and whether the neighboring router can participate in DR election must be
determined on the interface.
1. Run:

Routers
quit
Exit from the interface view.

2. Run:
ospf [ process-id ]

3. Run:
peer ip-address [ dr-priority priority ]
A neighboring router is configured on the NBMA network.
----End
Prerequisites
The configurations for OSPF attributes on the NBMA network and P2MP network are complete.
Procedure
l Run the either of the following command to check LSDB information.
display ospf [ process-id ] lsdb [ brief ]
display ospf [ process-id ] lsdb [ { router | network | summary | asbr | ase | nssa |
opaque-link | opaque-area | opaque-as } [ link-state-id ] ] [ originate-router
[ advertising-router-id ] | self-originate ] [ age { min-value min-age-value | max-
value max-age-value } * ]
l Run the display ospf [ process-id ] peer [ [ interface-type interface-number ] neighbor-
id | brief | last-nbr-down ] command to view neighbor information.
l Run the display ospf [ process-id ] nexthop command to check next hop information.
l Run the either of the following command to check routing table information.
display ospf [ process-id ] routing [ ip-address [ mask | mask-length ] ] [ interface
interface-type interface-number ] [ nexthop nexthop-address ]
display ospf [ process-id ] routing router-id [ router-id ]
l Run the display ospf [ process-id ] interface [ all | interface-type interface-number ]
[ verbose ] command to check interface information.
----End
5.6.4 Configuring OSPF Stub Areas

By configuring non-backbone areas at the edge of ASs as stub areas, you can reduce the size of
the routing table and reduce the number of LSAs to be transmitted.
The number of LSAs can be reduced by partitioning an AS into different areas. To reduce the
number of entries in the routing table and the number of LSAs to be transmitted in a non-
backbone area, configure the non-backbone area on the border of the AS as a stub area.

Routers
Configuring a stub area is optional.
Note the following points when configuring a stub area:
l The backbone area (Area 0) cannot be configured as a stub area.

l If an area needs to be configured as a stub area, all the routers in this area must be configured
with stub attributes using the stub command.
l An ASBR cannot exist in a stub area. External routes are not transmitted in the stub area.
l Virtual links cannot exist in the stub area.
Before configuring OSPF stub areas, complete the following tasks:
the network layer
Figure 5-21 Flowchart of configuring OSPF stub areas
Configure OSPF stub areas
Configure metrics of default routes

sent to stub areas
Mandatory
procedure
Optional
procedure
5.6.4.1 Defining the Current Area to be a Stub Area
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
stub

Routers
The specified area is configured as a stub area.
NOTE
l All routers in a stub area must be configured with stub attributes using the stub command.
l Configuring or deleting stub attributes will update routing information in the area. Stub attributes can
be deleted or configured again only after the routing update is complete.

stub [ no-summary ]
The ABR is prevented from sending Type 3 LSAs to the stub area.
----End
5.6.4.2 (Optional) Configuring Metrics of Default Routes Sent to Stub Areas
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
stub
The specified area is configured as a stub area.
NOTE
l All routers in a stub area must be configured with stub attributes using the stub command.
l Configuring or deleting stub attributes will update routing information in the area. Stub attributes can
be deleted or configured again only after the routing update is complete.

stub [ no-summary ]
The ABR is prevented from sending Type 3 LSAs to the stub area.
Step 6 Run:
default-cost cost
The cost of the default route to the stub area is set.
The parameter cost specifies the cost of the Type 3 default route to a stub area. The default value
is 1.

Routers
To ensure the reachability of AS external routes, the ABR in the stub area generates a default
route and advertises the route to the non-ABR routers in the stub area.
----End
Procedure
Run either of the following commands to check LSDB information.
l display ospf [ process-id ] lsdb [ brief ]

l display ospf [ process-id ] lsdb [ { router | network | summary | asbr | ase | nssa | opaque-
link | opaque-area | opaque-as } [ link-state-id ] ] [ originate-router [ advertising-router-
id ] | self-originate ] [ age { min-value min-age-value | max-value max-age-value } * ]
Run either of the following commands to check routing table information.
l display ospf [ process-id ] routing [ ip-address [ mask | mask-length ] ] [ interface

l display ospf [ process-id ] routing router-id [ router-id ]
Run the display ospf [ process-id ] abr-asbr [ router-id ] command to check ASBR and ABR
information.
5.6.5 Configuring OSPF NSSA Areas

Configuring a non-backbone area on the border of an autonomous system (AS) as a not-so-
stubby area (NSSA) can reduce entries in the routing table and the amount of routing information
to be transmitted.
An NSSA is configured in the scenario where AS external routes are to be imported but not
forwarded to save system resources.
The NSSA is a special type of OSPF area. Neither the NSSA nor the stub area transmits routes
learned from other areas in the AS it resides. The stub area does not allow AS external routes to
be imported, whereas the NSSA allows AS external routes to be imported and forwarded in the
entire AS.
Type 7 LSAs are used to carry imported AS external routing information in the NSSA. Type 7
LSAs are generated by the ASBRs of NSSAs and flooded only in the NSSAs where ASBRs
reside. The ABR in an NSSA selects certain Type 7 LSAs from the received ones and translates
them into Type 5 LSAs to advertise AS external routing information to the other areas over the
OSPF network.
Before configuring an NSSA, complete the following tasks:

Routers
l Configuring IP addresses for interfaces to ensure that neighboring routers are reachable at
the network layer
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
nssa [ default-route-advertise | flush-waiting-timer interval-value | no-import-
route | no-summary | set-n-bit | suppress-forwarding-address | translator-always |
translator-interval interval-value | zero-address-forwarding ]*
The specified area is configured as an NSSA.
NOTE
l NSSA attributes must be configured on all devices in the NSSA using the nssa command.
l Configuring or deleting NSSA attributes may trigger routing update in the area and disconnection from
neighbors. A second configuration of NSSA attributes can be implemented or canceled only after a
routing update is complete.
The nssa command is applicable to the following scenarios:

l The default-route-advertise parameter is configured to advertise Type 7 LSAs carrying the
default route on the ASBR to the NSSA.
Regardless of whether the default route 0.0.0.0/0 exists in the routing table on the ABR, Type
7 LSAs carrying the default route will be generated. However, Type 7 LSAs carrying the
default route will be generated only when the default route 0.0.0.0/0 exists in the routing
table on the ASBR.
l When the area to which the ASBR belongs is configured as an NSSA, invalid Type 5 LSAs
from other routers in the area where LSAs are flooded will be reserved. These LSAs will be
deleted only when the aging time reaches 3600s. The router performance is affected because
the forwarding of a large number of LSAs consumes the memory resources. To resolve such
a problem, you can set the parameter flush-waiting-timer to the maximum value 3600s for
Type 5 LSAs so that the invalid Type 5 LSAs from other routers can be deleted in time.
NOTE
l When the LS age field value (aging time) in the header of an LSA reaches 3600s, the LSA is deleted.
l If an ASBR also functions as an ABR, flush-waiting-timer does not take effect. This prevents
Type 5 LSAs in the non-NSSAs from being deleted.

Routers
l If an ASBR also functions as an ABR, the no-import-route parameter is configured to

prevent external routes imported using the import-route command from being advertised
to the NSSA.
l The no-summary parameter is configured on an ABR to reduce the number of LSAs that
are transmitted to the NSSA. This implementation prevents the ABR from transmitting Type
3 LSAs to the NSSA.
l After the set-n-bit parameter is configured, the N-bit is set in the database description (DD)
packets during the synchronization between the router and neighboring routers.
l If multiple ABRs are deployed in the NSSA, the system automatically selects an ABR
(generally the router with the largest router ID) as a translator to convert Type 7 LSAs into
Type 5 LSAs. You can configure the translator-always parameter on an ABR to specify the
ABR as an all-the-time translator. To specify two ABRs for load balancing, configure the
translator-always parameter on the chosen ABRs to specify the ABRs as all-the-time
translators. You can use this command to pre-configure a fixed translator to prevent LSA
flooding caused by translator role changes.
l The translator-interval parameter is used to ensure uninterrupted services when translator
roles change. The value of interval-value must be greater than the flooding period.
default-cost cost
The cost of the default route on which Type 3 LSAs are transmitted to the NSSA by the ABR
is set.
To ensure the reachability of AS external routes, the ABR in the NSSA generates a default route
and advertises this route to the other routers in the NSSA. The cost of the default route to an
NSSA is set and the selection of the default route is adjusted.
Type 7 LSAs can be used to carry default route information to guide traffic to other ASs.
Multiple ABRs may be deployed in an NSSA. To prevent routing loops, ABRs do not calculate
the default routes advertised by each other.
By default, the cost of the default route to the NSSA by the ABR is 1.
----End
Run either of the following commands to check LSDB information:

l display ospf [ process-id ] lsdb [ brief ]
l display ospf [ process-id ] lsdb [ { router | network | summary | asbr | ase | nssa | opaque-
link | opaque-area | opaque-as } [ link-state-id ] ] [ originate-router [ advertising-router-
id ] | self-originate ] [ age { min-value min-age-value | max-value max-age-value } * ]
Run either of the following commands to check routing table information:
l display ospf [ process-id ] routing [ ip-address [ mask | mask-length ] ] [ interface
l display ospf [ process-id ] routing router-id [ router-id ]
Run the display ospf [ process-id ] interface [ all | interface-type interface-number ]
[ verbose ] command to check OSPF interface information.

Routers
5.6.6 Adjusting OSPF Route Selection

By adjusting OSPF route selection, you can enable OSPF to meet the requirements of complex
networks.
On complex networks, you can adjust OSPF parameters to flexibly adjust the networking and
optimize load balancing.
Before adjusting OSPF route selection, complete the following tasks:
the network layer
required.
5.6.6.1 Setting the Link Cost for an OSPF Interface
Context
OSPF can automatically calculate the link cost for an interface according to the interface
bandwidth. You can also set the link cost for the interface through commands.
If you do not set the cost of an OSPF interface by using the ospf cost cost command, OSPF
automatically calculates the cost of the interface according to the interface bandwidth. The
calculation formula is as follows: Cost of the interface = Bandwidth reference value/Interface
bandwidth. The integer of the calculated result is the cost of the interface. If the calculated result
is smaller than 1, the cost value is 1. Changing the bandwidth reference value can change the
cost of an interface.
Procedure
l Setting the link cost for an OSPF interface
1. Run:
system-view

2. Run:

3. Run:
ospf cost cost

Routers
The cost of the OSPF interface is set.

l Setting the bandwidth reference value
1. Run:
system-view

2. Run:
ospf [ process-id ]

3. Run:
bandwidth-reference value
The bandwidth reference value is set.
The parameter value specifies the bandwidth reference value used to calculate the link
cost, in Mbit/s.
NOTE
Ensure that the bandwidth reference values of routers in an OSPF process are the same.
----End
5.6.6.2 Configuring Equal-Cost Routes
Context
If the destinations and costs of the multiple routes discovered by one routing protocol are the
same, load balancing can be implemented among the routes.
As shown in Figure 5-22, three routes between router A and router B that run OSPF have the
same costs. The three routes are equal-cost routes for load balancing.
Figure 5-22 Networking diagram of equal-cost routes
cos
t=1
t =5 0
c os
cost=10 cost=5
RouterA
RouterB
c os
t=8 t =7
c os

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
NOTE
By default, the AR150&200 series, AR1200 series, AR2201-48FE, AR2202-48FE, and AR2204 support
a maximum of four equal-cost routes, and the AR2220, AR2240, and AR3200 series support a maximum
of eight equal-cost routes.

nexthop ip-address weight value
The route preferences are configured for load balancing.
When the number of equal-cost routes on the live network is greater than that specified in the
maximum load-balancing command, valid routes are randomly selected for load balancing. To
specify valid routes for load balancing, run the nexthop command to set the route preference.
Ensure that the preferences of valid routes to be used must be high.
The smaller the weight value, the higher the preference of the route. The default weight value
is 255, which indicates that load balancing is implemented regardless of the route preferences.
----End
5.6.6.3 Configuring External Route Selection Rules
Context
RFC 2328 and RFC 1583 define the route selection rule differently. After OSPF is enabled on
the router, specify a route selection rule based on the router configuration. The router complies
with the route selection rule defined in RFC 1583 by default. If the neighboring router complies
with the route selection rule defined in RFC 2328, configure the local router to comply with that
defined in RFC 2328. This allows all routers in the OSPF area to comply with the same route
selection rule.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
undo rfc1583 compatible
The router is configured to comply with the route selection rule defined in RFC 2328, not RFC
1583.
By default, the router complies with route selection rule defined in RFC 1583.
----End
5.6.6.4 Suppressing an Interface from Receiving and Sending OSPF Packets
Context
Suppressing an interface from receiving and sending OSPF packets helps routing information
to bypass a specific router and enables the local router to reject routing information advertised
by another router. This ensures that an optimal route is provided.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
silent-interface { all | interface-typeinterface-number }
An interface is suppressed from receiving and sending OSPF packets.
The same interface in different processes can be suppressed from sending and receiving OSPF
packets, but the silent-interface command is valid only for the OSPF interface in the local
process.
After an OSPF interface is configured to be in the silent state, the interface can still advertise its
direct routes. Hello packets on the interface, however, cannot be forwarded. Therefore, no
neighbor relationship can be established on the interface. This can enhance the networking
adaptability of OSPF and reduce system resource consumption.
----End

Routers
Prerequisites
All configurations of adjusting OSPF route selection are complete.
Procedure
l Run the display ospf [ process-id ] interface command to check information about OSPF
interfaces.
l Run the display ospf [ process-id ] routing command to check information about the OSPF
routing table.
----End
5.6.7 Controlling OSPF Routing Information

This section describes how to control OSPF routing information. Detailed operations include
importing external routes, and filtering the received routes and LSAs.
Before controlling OSPF routing information, complete the following tasks:
the network layer
required.
5.6.7.1 Configuring OSPF to Import External Routes
Context
To access a router running a non-OSPF protocol, an OSPF-capable router needs to import routes
of the non-OSPF protocol into the OSPF network.
OSPF can ensure loop-free intra-area routes and inter-area routes; however, OSPF cannot protect
external routes against loops. Therefore, when configuring OSPF to import external routes, avoid
the loops caused by manual configurations.
Do as follows on the router that functions as the ASBR running OSPF:
Procedure
l Configuring OSPF to import the routes discovered by other protocols
1. Run:
system-view

2. Run:

Routers
ospf [ process-id ]

3. Run:
import-route { limit limit-number | { bgp [ permit-ibgp ] | direct | unr
| rip [ process-id-rip ] | static | isis [ process-id-isis ] | ospf
[ process-id-ospf ] } [ cost cost | type type | tag tag | route-policy
route-policy-name ] * }
The routes discovered by other protocols are imported.

l Setting parameters for OSPF to import routes
1. Run:
system-view

2. Run:
ospf [ process-id ]

3. Run:
default { cost { cost-value | inherit-metric } | limit limit | tag tag |
type type } *
The default values of parameters (the metric of routes, tag, and type) are set for
importing routes.
The default values of parameters (the cost, number of routes, tag, and type) are set for
imported routes.
When OSPF imports external routes, you can set default values for some additional
parameters, such as the cost, number of routes to be imported, route tag, and route
type. The route tag is used to identify the protocol-related information. For example,
it can be used to differentiate AS numbers carried in BGP routes imported by OSPF.
By default, the cost of the external routes imported by OSPF is 1; a maximum of
2147483647 routes can be imported each time; the type of the imported external routes
is Type 2; the default tag value of the imported routes is 1.
NOTE
You can run one of the following commands to set the cost of the imported route. The following
commands are listed in descending order of priorities.
l Run the apply cost command to set the cost of a route.
l Run the import-route command to set the cost of the imported route.
l Run the default command to set the default cost of the imported route.
----End
5.6.7.2 Configuring OSPF to Advertise the Default Route to the OSPF Area
Context
On the area border and AS border of an OSPF network generally reside multiple routers for next-
hop backup or traffic load balancing. A default route can be configured to reduce routing entries
and improve resource usage on the OSPF network.

Routers
The default route is generally applied to the following scenarios:

1. An ABR in an area advertises Type 3 LSAs carrying the default route within the area.
routers in the area use the received default route to forward inter-area packets.
2. An ASBR in an AS advertises Type 5 or Type 7 LSAs carrying the default route within the
AS. routers in the AS use the received default route to forward AS external packets.
When no exactly matched route is discovered, the router can forward packets through the default
route.
The preference of the default route in Type 3 LSAs is higher than that of the route in Type 5 or
Type 7 LSAs.
The advertising mode of the default route is determined by the type of the area to which the
default route is imported, as shown in Table 5-20.
Table 5-20 Default route advertising mode
Area Generated By Advertise LSA Type Floodi

Type d By ng
Area
Commo The default-route-advertise command ASBR Type 5 LSA Comm

n area on area
Stub Automatically ABR Type 3 LSA Stub

area area
NSSA The nssa [ default-route-advertise ] ASBR Type 7 LSA NSSA

command
Totally Automatically ABR Type 3 LSA NSSA

NSSA
Perform the following steps on the ASBR running OSPF.
Procedure
l Configuring OSPF to Advertise the Default Route to the OSPF Area
1. Run:
system-view

2. Run:
ospf [ process-id ]

3. Run the following commands as required:
Run:
default-route-advertise [ [ always | permit-calculate-other ] | cost
cost | type type | route-policy route-policy-name [ match-any ] ] *
OSPF is configured to advertise the default route to the OSPF area.

Routers
always indicates that an LSA describing the default route is generated and then
advertised regardless of whether there are the active default routes of other
OSPF processes in the routing table of the local device.
permit-calculate-other indicates that the local router is still allowed to
calculate the default routes advertised by other routers after adverting its default
route.
route-policy route-policy-name indicates that the local device advertises
default routes according to the parameters of the configured routing policy
when there are matched default routing entries generated by other OSPF
processes.
Run:
default-route-advertise summary cost cost
The default cost of a Type 3 summary LSA is set.

Before selecting the preceding parameters, you need to configure VPN. Otherwise,
this command cannot be run.
NOTE
l An ASE LSA that describes the default route is generated and then advertised only when
there are active default routes of other OSPF processes in the routing table of the local
device.
l Before advertising a default route, OSPF compares the preferences of default routes.
Therefore, if a static default route is configured on an OSPF router, to add the default route
advertised by OSPF to the current routing table, ensure that the preference of the configured
static default route is lower than that of the default route advertised by OSPF.
----End
5.6.7.3 Configuring OSPF Route Aggregation
Context
Route summarization on a large-scale OSPF network efficiently reduces routing entries. This
minimizes system resource consumption and maintains the system performance. In addition, if
a specific link frequently alternates between Up and Down, the links not involved in the route
summarization will not be affected. This prevents route flapping and improves the network
stability.
When an ABR transmits routing information to other areas, it originates Type 3 LSAs per
network segment. If any consecutive segments exist in this area, you can run the abr-
summary command to summarize these segments into one segment. An ABR sends only one
summarized LSA to other areas. Any LSA that belongs to the summarized network segment
specified by the command is not transmitted separately. Therefore, the size of the routing table
is reduced, and router performance is improved.
Procedure
l Configuring ABR Route Aggregation
1. Run:
system-view

Routers

2. Run:
ospf [ process-id ]

3. Run:
area area-id

4. Run:
abr-summary ip-address mask [ [ advertise | not-advertise ] | cost cost ]*
ABR route aggregation of OSPF is configured.

l Configuring ASBR Route Aggregation
1. Run:
system-view

2. Run:
ospf [ process-id ]

3. Run:
asbr-summary ip-address mask [ not-advertise | tag tag | cost cost |
distribute-delay interval ] *
ASBR route aggregation of OSPF is configured.
NOTE
After route summarization is configured, the routing table on the local OSPF router remains
the same. The routing table on another OSPF router, however, contains only one summarized
route, no specific route. This summarized route is not removed until all specific routes are
interrupted.
----End
5.6.7.4 Configuring OSPF to Filter the Received Routes
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-
policy route-policy-name [ secondary ] } import

Routers
OSPF is configured to filter the received routes.
l The parameter acl-number specifies the number of a basic ACL.

l The parameter acl-name acl-name specifies the name of an ACL.
l The parameter ip-prefix ip-prefix-name specifies the name of an IP prefix list.
OSPF is a link-state dynamic routing protocol, with routing information carried in the LSA.
Therefore, the filter-policy import command cannot be used to filter the advertised or received
LSAs.
The filter-policy import command is used to filter the routes calculated by OSPF. Only the
routes that pass the filtering are added to the routing table. Routes that do not pass the filtering
can not added to the OSPF routing table, but can be advertised.
----End
5.6.7.5 Configuring OSPF to Filter the Routes to Be Advertised
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name } export
[ protocol [ process-id ] ]
OSPF is configured to filter the routes imported through the import-route command. Only the
routes that pass the filtering are advertised.
l The parameter acl-number specifies the number of a basic ACL.

l The parameter acl-name acl-name specifies the name of an ACL.
l The parameter ip-prefix ip-prefix-name specifies the name of an IP prefix list.
You can specify the parameter protocol [ process-id ] to filter the routes of a certain routing
protocol or a certain OSPF process. If protocol [ process-id ] is not specified, OSPF filters all
the imported routes.
NOTE
l The import-route command cannot be used to import external default routes.

l OSPF filters the imported routes, and generates Type 5 LSAs to advertise only external routes that
passing the filtering.
----End
5.6.7.6 Configuring the router to Filter LSAs to Be Sent

Routers
Context
When multiple links exist between two routers, you can configure the local router to filter the
LSAs to be sent. This prevents unnecessary LSA transmission and saves bandwidth resources.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ospf filter-lsa-out { all | { summary [ acl { acl-number | acl-name } ] | ase
[ acl { acl-number | acl-name } ] | nssa [ acl { acl-number | acl-name } ] } * }
The LSAs to be sent are filtered.

By default, the LSAs to be sent are not filtered.
----End
5.6.7.7 Configuring OSPF to Filter ABR Type3 LSA
Context
After filtering conditions are set for the incoming or outgoing Type 3 LSAs (Summary LSAs)
in an area, only the Type 3 LSAs that meet the filtering conditions can be received or advertised.
This function is applicable only to the ABR.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
area area-id

Step 4 Depending on type of desired filtering, run one of following commands to configure OSPF to
filter the Type 3 LSAs generated by ABRs.:

Routers
OSPF is configured to filter the Type 3 LSAs generated by ABRs.
l Run:
filter { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-
policy route-policy-name } export
The outgoing summary LSAs in the local area will be filtered.

l Run:
filter { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-
policy route-policy-name } import
The incoming summary LSAs in the local area are to be filtered.
----End
5.6.7.8 (Optional) Enabling the Mesh-Group Function
Context
When concurrent links exist between two routers, you can enable the mesh-group function to
reduce the load on the links.
The neighboring router ID identifies each mesh group. Several concurrent links are added to a
mesh group. Flooding is implemented once in the group. You can add interfaces that meet the
following conditions to the same mesh group.
l The interfaces belong to the same area and OSPF process.

l The interfaces begin to exchange DD packets.
l The interfaces are connected to the same neighboring router.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
mesh-group enable
The mesh-group function is enabled.
By default, the mesh-group function is disabled.
----End
5.6.7.9 Setting the Maximum Number of External LSAs in the LSDB

Routers
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
lsdb-overflow-limit number
The maximum number of external LSAs in the LSDB is set.
----End
Prerequisites
The configurations of controlling OSPF routing information are complete.
Procedure
l Run either of the following commands to check routing table information.
display ospf [ process-id ] routing [ ip-address [ mask | mask-length ] ] [ interface
display ospf [ process-id ] routing router-id [ router-id ]
l Run the display ospf [ process-id ] interface [ all | interface-type interface-number ]
[ verbose ] command to check OSPF interface information.
l Run the display ospf [ process-id ] asbr-summary [ ip-address mask ] command to check
OSPF ASBR summarization information.
----End
5.6.8 Configuring OSPF IP FRR

In the case of a link fault, a device enabled with OSPF IP FRR can fast switch traffic to the
backup link. This protects traffic and greatly improves the reliability of OSPF networks.
Context
With the development of networks, Voice over IP (VoIP) and on-line video services require
high-quality real-time transmission. Nevertheless, if an OSPF fault occurs, traffic can be
switched to a new link only after the following processes: fault detection at the millisecond level,
notifying the fault to the routing control plane at the millisecond level, generating and flooding
new topology information at the tens of milliseconds level, triggering SPF calculation at the tens
of milliseconds level, and notifying and installing a new route at the hundreds-of-milliseconds
level. As a result, it takes much more than 50 ms to recovery the link from the fault, which cannot
meet the requirement for real-time services on the network.

Routers
OSPF IP FRR can work with BFD to implement protection switchover within 50 ms. With OSPF
IP FRR that calculates a backup link in advance, devices can fast switch traffic to the backup
link without interrupting traffic when the primary link becomes faulty. This protects traffic and
thus greatly improves the reliability of OSPF networks.
OSPF IP FRR is applicable to the services that are sensitive to packet delay and packet loss.
NOTE
AR150&200 series do not support OSPF IP FRR.
Before configuring OSPF IP FRR, complete the following tasks:
the network layer
Figure 5-23 Flowchart for configuring OSPF IP FRR
Enable OSPF IP FRR
Bind OSPF IP FRR and

BFD
Block FRR on a specified

OSPF interface
Mandatory
procedure
Optional
procedure
5.6.8.1 Enabling OSPF IP FRR
Context
Enabling OSPF IP FRR to generate a loop-free backup link. When this route becomes faulty,
OSPF can fast switch the traffic to a backup link.
FRR calculation consumes a large number of CPU resources. When there are import features
such as routing protocol, you need to delay FRR calculation.
After FRR calculation is delayed, devices process important services such as route calculation
first.
Do as follows on the router that needs to protect traffic to be forwarded:

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
An OSPF process is started and the OSPF view is displayed.
Step 3 Run:
frr
The OSPF IP FRR view is displayed.
Step 4 Run:
loop-free-alternate
OSPF IP FRR is enabled to generate a loop-free backup link.
NOTE
OSPF can generate a loop-free backup link only when the OSPF IP FRR traffic protection inequality is
met.

frr-policy route route-policy route-policy-name
OSPF IP FRR filtering policies are configured.
After OSPF IP FRR filtering policies are configured, only the OSPF backup routes that match
the filtering conditions can be delivered to the forwarding table. To protect the traffic over a
specific OSPF route, you can configure a filtering policy that matches the OSPF route to ensure
that the route can be added to the forwarding table. When this route becomes faulty, OSPF can
fast switch the traffic to a backup link.
----End
5.6.8.2 Binding IP FRR and BFD
Context
During the configuration of OSPF IP FRR, the lower layer needs to fast respond to the link
change so that traffic can be rapidly switched to the backup link in the case of a link failure.
Bind BFD to the link status so that link faults can be detected rapidly. This ensures that traffic
is rapidly switched to the backup link in the case of link failures.
Binding OSPF IP FRR and BFD can configure in a specified process or on a specified interface.
The priority of BFD configured on an interface is higher than that of BFD configured in an OSPF
process. If BFD is enabled on an interface, a BFD session is established according to the BFD
parameters set on the interface.

Routers
Procedure
l Bind IP FRR and BFD in an OSPF process.
1. Run:
system-view

2. Run:
ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ]
*
The OSPF process is enabled, and the OSPF view is displayed.

3. Run:
bfd all-interfaces frr-binding
IP FRR and BFD are bound in the OSPF process.

l Bind IP FRR and BFD on a specified OSPF interface.
1. Run:
system-view

2. Run:

3. Run:
ospf bfd frr-binding
IP FRR and BFD are bound on the interface.
----End
5.6.8.3 (Optional) Blocking FRR on an OSPF Interface
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of an OSPF interface enabled with FRR is displayed.
Step 3 Run:
ospf frr block
FRR is blocked on the OSPF interface.
----End

Routers
Prerequisites
All OSPF IP FRR configurations are complete.
Procedure
l Run the display ospf [ process-id ] routing command to check the information about the
primary link and backup link of a route after configuring OSPF IP FRR.
----End
5.6.9 Configuring BFD for OSPF

If there are high requirements for data transmission, and OSPF convergence needs to be speeded
up when the link status changes, you can configure BFD on OSPF links. After detecting a link
failure, BFD notifies the routing protocol of the failure, which triggers fast convergence. When
the neighbor relationship is Down, the BFD session is deleted dynamically.
OSPF enables the router to periodically send Hello packets to a neighboring router for fault
detection. Detecting a fault takes more than 1s. As technologies develop, voice, video, and other
VOD services are widely used. These services are quite sensitive to packet loss and delays. When
traffic is transmitted at gigabit rates, long-time fault detection will cause packet loss. This cannot
meet high reliability requirements of the carrier-class network.
BFD for OSPF is introduced to resolve this problem. After BFD for OSPF is configured in a
specified process or on a specified interface, the link status can be rapidly detected and fault
detection can be completed in milliseconds. This speeds up OSPF convergence when the link
status changes.
NOTE
A BFD session currently does not detect route switching. If the change of bound peer IP address causes a
route to switch to another link, the BFD session is negotiated again only when the original link fails.
Before configuring BFD for OSPF, complete the following tasks:
the network layer

Routers
Figure 5-24 Flowchart of configuring BFD for OSPF

Configure global BFD
Configure BFD for OSPF
Prevent an interface from

dynamically setting up a BFD session
Configure BFD on the specified

interface
Mandatory
procedure
Optional
procedure
5.6.9.1 Configuring Global BFD
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
BFD is configured globally, and the global BFD view is displayed.
----End
5.6.9.2 Configuring BFD for OSPF Feature
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
BFD for OSPF is enabled to establish the BFD session.

Routers
If all the interfaces in a certain process are configured with BFD and their neighbor relationships
are in the Full state, OSPF establishes BFD sessions on all the interfaces in the process.
Run the bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-
interval | detect-multiplier multiplier-value | frr-binding } * command to set parameters for
BFD sessions.
l The parameter min-rx-interval receive-interval specifies the expected minimum interval for
receiving BFD packets from the neighbor.
l The parameter min-tx-interval transmit-interval specifies the minimum interval for sending
BFD packets to the neighbor.
l The parameter detect-multiplier multiplier-value specifies the local detection multiplier.
l The parameter frr-binding indicates that the status of the BFD session is bound to OSPF IP
FRR.
NOTE
If only the bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-interval |

detect-multiplier multiplier-value | frr-binding } * command is run to set BFD parameters, and the bfd
all-interfaces enable command is not run, BFD cannot be enabled.
AR150&200 series do not support OSPF IP FRR.
You can skip this step. The default interval at which BFD packets are transmitted and the default
detection multiplier are recommended.
The parameters are configured based on the network status and network reliability requirements.
A short interval at which BFD packets are transmitted can be configured for a link that has a
higher requirement for reliability. A long interval at which BFD packets are transmitted can be
configured for a link that has a lower requirement for reliability.
NOTE
l Actual interval at which BFD packets are transmitted on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local router, configured interval receive-
interval at which BFD packets are received on the peer router }
l Actual interval at which BFD packets are received on the local router = Max { configured interval transmit-
interval at which BFD packets are transmitted on the peer router, configured interval receive-interval at
which BFD packets are received on the local router }
l Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
router x Configured detection multiplier multiplier-value on the peer router
For example:
l On the local router, the configured interval at which BFD packets are transmitted is 200 ms; the configured
interval at which BFD packets are received is 300 ms; the detection multiplier is 4.
l On the peer router, the configured interval at which BFD packets are transmitted is 100 ms; the interval at
which BFD packets are received is 600 ms; the detection multiplier is 5.
Then:
l On the local router, the actual interval at which BFD packets are transmitted is 600 ms calculated by using
the formula max {200 ms, 600 ms}; the interval at which BFD packets are received is 300 ms calculated by
using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by multiplying 300
ms by 5.
l On the peer router, the actual interval at which BFD packets are transmitted is 300 ms calculated by using
the formula max {100 ms, 300 ms}, the actual interval at which BFD packets are received is 600 ms calculated
by using the formula max {200 ms, 600 ms}, and the detection period is 2400 ms calculated by multiplying
600 ms by 4.
----End

Routers
5.6.9.3 (Optional) Preventing an Interface from Dynamically Setting Up a BFD

Session
Context
After the bfd all-interfaces enable command is run in an OSPF process, BFD sessions can be
established on all the OSPF interfaces whose neighbor relationships are Full.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of the interface enabled with BFD for OSPF is displayed.
Step 3 Run:
ospf bfd block
The interface is prevented from dynamically establishing a BFD session.
----End
5.6.9.4 (Optional) Configuring BFD on the Specified Interface
Context
After BFD for OSPF is configured on a specified interface and the interface becomes faulty, the
router rapidly detects the fault and instructs OSPF to recalculate routes. This speeds up OSPF
convergence. When the OSPF neighbor relationship goes Down, the BFD session between OSPF
neighbors is dynamically deleted.
Before configuring BFD for OSPF, enable BFD globally.
Perform the following steps on the router:
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of the interface enabled with BFD for OSPF is displayed.
Step 3 Run:
ospf bfd enable

Routers
BFD is enabled on the interface to establish the BFD session.
If all the interfaces in a certain process are configured with BFD and their neighbor relationships
are in the Full state, OSPF creates BFD sessions with default parameter values on specified
interfaces in the process.
NOTE
The priority of BFD for OSPF configured on an interface is higher than that of BFD for OSPF configured
for a process.
Run the ospf bfd { min-rx-interval receive-interval | min-tx-interval transmit- interval |

detect-multiplier multiplier-value } * command to set parameters for BFD sessions.
You can skip this step. The default interval at which BFD packets are transmitted and the default
detection multiplier are recommended.
The parameters are configured based on the network status and network reliability requirements.
A short interval at which BFD packets are transmitted can be configured for a link that has a
higher requirement for reliability. A long interval at which BFD packets are transmitted can be
configured for a link that has a lower requirement for reliability.
NOTE
l Actual interval at which BFD packets are transmitted on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local router, configured interval receive-
interval at which BFD packets are received on the peer router }
l Actual interval at which BFD packets are received on the local router = Max { configured interval transmit-
interval at which BFD packets are transmitted on the peer router, configured interval receive-interval at
which BFD packets are received on the local router }
l Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
router x Configured detection multiplier multiplier-value on the peer router
For example:
l On the local router, the configured interval at which BFD packets are transmitted is 200 ms; the interval at
which BFD packets are received is set to 300 ms; the detection multiplier is 4.
l On the peer router, the configured interval at which BFD packets are transmitted is 100 ms; the interval at
which BFD packets are received is 600 ms; the detection multiplier is 5.
Then:
l On the local router, the actual interval at which BFD packets are transmitted is 600 ms calculated by using
the formula max {200 ms, 600 ms}; the interval at which BFD packets are received is 300 ms calculated by
using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by multiplying 300
ms by 5.
l On the peer router, the actual interval at which BFD packets are transmitted is 300 ms calculated by using
the formula max {100 ms, 300 ms}, the actual interval at which BFD packets are received is 600 ms calculated
by using the formula max {200 ms, 600 ms}, and the detection period is 2400 ms calculated by multiplying
600 ms by 4.
----End
Prerequisites
All configurations of BFD for OSPF are complete.

Routers
Procedure
l Run one of the following commands to check the BFD session:
display ospf [process-id ] bfd session interface-type interface-number [ router-id ]
display ospf [process-id ] bfd session { router-id | all }
----End
5.6.10 Configuring OSPF Fast Convergence

By adjusting OSPF timers, you can implement OSPF fast network convergence.
Before configuring OSPF fast convergence, complete the following tasks:

the network layer
required.
5.6.10.1 Setting the Convergence Priority of OSPF Routes
Context
With the integration of network services, different services such as data, voice, and video run
on the same network infrastructure, and have different requirements for the network. For Video
on Demand (VoD) services, the route convergence speed of the multicast source server is the
most critical factor that affects multicast services. It is required that the routes to the multicast
source should converge rapidly when network faults occur. On the BGP or MPLS VPN bearer
network where OSPF is used to implement the IP connectivity of the backbone network, end-
to-end routes between PEs need to be converged rapidly.
You can set priorities for specific routes by setting the convergence priority of OSPF routes so
that these routes converge preferentially. This shortens the interruption of key services and
improves the reliability of the entire network.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]

Routers
Step 3 Run:
prefix-priority { critical | high | medium } ip-prefix ip-prefix-name
The convergence priority of OSPF routes is set.
After the convergence priority of OSPF routes is set, OSPF can calculate and flood LSAs, and
synchronize LSDBs according to priorities. This speeds up route convergence. When an LSA
meets multiple priorities, the highest priority takes effect. OSPF calculates LSAs in the sequence
of intra-area routes, inter-area routes, and AS external routes. This command makes OSPF
calculate route priorities. Convergence priorities are critical, high, medium, and low. To speed
up the processing of LSAs with the higher priority, during LSA flooding, the LSAs need to be
placed into the corresponding critical, high, medium, and low queues according to priorities.
NOTE
This command takes effect only on the public network.
----End
5.6.10.2 Setting the Interval for Sending Hello Packets
Context
Hello packets are commonly used packets, which are periodically sent on OSPF interfaces to
establish and maintain neighbor relationships. The intervals set on the interfaces connecting two
OSPF neighbors need to be the same. Otherwise, the OSPF neighbor relationship cannot be
established.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospf timer hello interval
The interval for sending Hello packets is set on the OSPF interface.
By default, the interval for sending Hello packets on a P2P or broadcast interface is 10s; the
interval for sending Hello packets on a P2MP or NBMA interface is 30s; the dead time for the
OSPF neighbors on the same interface is four times the interval for sending Hello packets.
----End
5.6.10.3 Setting the Dead Time of the Neighbor Relationship

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospf timer dead interval
The dead time after which the neighbor relationship between two routers is set.
By default, the dead time of the neighbor relationship on a P2P or broadcast interface is 40s; the
dead time of the neighbor relationship on a P2MP or NBMA interface is 120s; the dead time of
the neighbor relationship on the same interface is four times the interval for sending Hello
packets.
NOTE
Setting the dead interval of an OSPF neighbor to be longer than 20s is recommended. If the dead interval
of an OSPF neighbor is shorter than 20s, the session may be closed.
Both the Hello timer and the Dead timer are restored to the default values after the network type is changed.
----End
5.6.10.4 Configuring Smart-discover
Context
Before Smart-discover is configured, when the neighbor status of the router changes or the DR/
BDR on the multi-access network (broadcast or NBMA network) changes, the router does not
send Hello packets to its neighbor until the Hello timer expires. This slows down the
establishment of neighbor relationships between devices. After Smart-discover is configured,
when the neighbor relationship status of the router changes or the DR/BDR on the multi-access
network (broadcast or NBMA network) changes, the router can send Hello packets to its neighbor
immediately without waiting for the expiration of the Hello timer. This speeds up the
establishment of neighbor relationships and thus implements fast convergence of OSPF
networks.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
Step 3 Run:
ospf smart-discover
Smart-discover is configured on the interface.
----End
5.6.10.5 Setting the Interval for Updating LSAs
Context
In OSPF, the interval for updating LSAs is defined as 1s. This aims to prevent network
connections or frequent route flapping from consuming excessive network bandwidth or device
resources.
On a stable network where routes need to be fast converged, you can cancel the interval for
updating LSAs by setting the interval to 0 seconds. In this manner, the changes of the topology
or the routes can be immediately advertised on the network through LSAs. Route convergence
on the network is thus sped up.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
lsa-originate-interval { 0 | { intelligent-timer max-interval start-interval hold-
interval | other-type interval } * }
The interval for updating LSAs is set.
l The parameter intelligent-timer indicates that the interval for updating router LSAs and
network LSAs is set through an intelligent timer.
l The parameter max-interval specifies the maximum interval for updating LSAs, in
milliseconds.
l The parameter start-interval specifies the initial interval for updating LSAs, in milliseconds.
l The parameter hold-interval specifies the hold interval for updating LSAs, in milliseconds.
l The parameter other-type interval indicates that the interval for updating LSAs excluding
Router LSAs and Network LSAs is set.
By default, no intelligent timer is enabled. After an intelligent timer is enabled, the default
maximum interval for updating LSAs is 5000 ms, the default initial interval is 500 ms, and the
default hold interval is 1000 ms (the interval is expressed in milliseconds). Details about the
interval for updating LSAs are as follows:
1. The initial interval for updating LSAs is specified by start-interval.

Routers
2. The interval for updating LSAs for the nth (n 2) time is equal to hold-interval x 2(n-2).
3. When the interval specified by hold-interval x 2(n-2) reaches the maximum interval specified
by max-interval, OSPF updates LSAs at the maximum interval for three consecutive times.
Then, OSPF goes back to Step 3.1 and updates LSAs at the initial interval specified by
start-interval.
----End
5.6.10.6 Setting the Interval for Receiving LSAs
Context
In OSPF, the interval for receiving LSAs is 1s. This aims to prevent network connections or
frequent route flapping from consuming excessive network bandwidth or device resources.
On a stable network where routes need to be fast converged, you can cancel the interval for
receiving LSAs by setting the interval to 0 seconds. In this manner, the changes of the topology
or the routes can be immediately advertised to the network through LSAs. Route convergence
on the network is thus sped up.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
lsa-arrival-interval { interval | intelligent-timer max-interval start-interval
hold-interval }
The interval for receiving LSAs is set.
l The parameter interval specifies the interval for receiving LSAs, in milliseconds.
l The parameter intelligent-timer indicates that the interval for receiving router LSAs or
network LSAs is set through an intelligent timer.
l The parameter max-interval specifies the maximum interval for receiving LSAs, in
milliseconds.
l The parameter start-interval specifies the initial interval for receiving LSAs, in milliseconds.
l The parameter hold-interval specifies the hold interval for receiving LSAs, in milliseconds.
On a stable network where routes need to be fast converged, you can set the interval for receiving
LSAs to 0 seconds so that the changes of the topology or the routes can be detected immediately.
By default, no intelligent timer is enabled. After an intelligent timer is enabled, the default
maximum interval for receiving LSAs is 1000 ms, the default initial interval is 500 ms, and the
default hold interval is 500 ms. Details about the interval for receiving LSAs are as follows:

Routers
1. The initial interval for receiving LSAs is specified by the parameter start-interval.
2. The interval for receiving LSAs for the nth (n 2) time is equal to hold-interval x 2(n-2).
by max-interval, OSPF receives LSAs at the maximum interval for three consecutive times.
Then, OSPF goes back to Step 3.1 and receives LSAs at the initial interval specified by
start-interval.
----End
5.6.10.7 Setting the Interval for the SPF Calculation
Context
When the OSPF LSDB changes, the shortest path needs to be recalculated. If a network changes
frequently and the shortest path is calculated continually, many system resources are consumed
and thus system performance is degraded. By configuring an intelligent timer and properly
setting the interval for the SPF calculation, you can prevent excessive system memory and
bandwidth resources from being occupied.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
spf-schedule-interval { interval1 | intelligent-timer max-interval start-interval
hold-interval | millisecond interval2 }
The interval for the SPF calculation is set.

l The parameter interval1 specifies the interval for the SPF calculation, in milliseconds.
l The parameter intelligent-timer indicates that the interval for the SPF calculation is set
through an intelligent timer.
l The parameter max-interval specifies the maximum interval for the SPF calculation, in
milliseconds.
l The parameter start-interval specifies the initial interval for the SPF calculation, in
milliseconds.
l The parameter hold-interval specifies the hold interval for the SPF calculation, in
milliseconds.
l The parameter millisecond interval2 specifies the interval for the SPF calculation, in
milliseconds.
By default, an intelligent timer is enabled; the maximum interval for the SPF calculation is 10000
ms, the initial interval is 500 ms, and the hold interval is 1000 ms (the interval is expressed in
milliseconds).

Routers
After an intelligent timer is enabled, the interval for the SPF calculation is as follows:
1. The initial interval for the SPF calculation is specified by the parameter start-interval.
2. The interval for the SPF calculation for the nth (n 2) time is equal to hold-interval x 2
(n-2).
by max-interval, OSPF performs the SPF calculation at the maximum interval for three
consecutive times. Then, OSPF goes back to 3.1 and performs the SPF calculation at the
initial interval specified by start-interval.
----End
Prerequisites
All configurations of OSPF fast convergence are complete.
Procedure
----End
5.6.11 Configuring OSPF GR Helper

To avoid traffic interruption and route flapping caused by the active/standby switchover, you
can enable OSPF GR.
Graceful Restart (GR) is a technology used to ensure normal traffic forwarding and non-stop
forwarding of key services during the restart of routing protocols. GR is one of high availability
(HA) technologies. HA technologies comprise a set of comprehensive techniques, such as fault-
tolerant redundancy, link protection, faulty node recovery, and traffic engineering. As a fault-
tolerant redundancy technology, GR is widely used to ensure non-stop forwarding of key
services during master/slave switchover and system upgrade.
To avoid traffic interruption and route flapping caused by the active/standby switchover, you
can enable OSPF GR.
After the OSPF process is restarted through GR, the Restarter and the Helper reestablish the
neighbor relationship, exchange routing information, synchronize the LSDB, and update the
routing table and forwarding table. These operations ensure the fast convergence of OSPF and
the stability the network topology.
NOTE
In practical applications, you can configure OSPF GR on the dual main control boards to avoid service
forwarding from being affected by the fault occurred on the main control board.
The AR150&200&1200&2200&3200 support only the GR Helper.

Routers
Before configuring OSPF GR, complete the following tasks:
the network layer
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
opaque-capability enable
The opaque-LSA capability is enabled.
The opaque-LSA capability of OSPF needs to be enabled first because OSPF supports GR
through Type 9 LSAs.
Step 4 Run:
graceful-restart helper-role { [ { ip-prefix ip-prefix-name | acl-number acl-
number | acl-name acl-name } | ignore-external-lsa | planned-only ] * | never }
The GR session parameters is set.
l Set ACL parameters, the local router can enter the Helper mode only after neighbors pass
the filtering policies of ip-prefix or acl.
l Set ignore-external-lsa, the Helper does not check the LSAs outside the AS (AS-external
LSA). By default, the Helper checks the LSAs outside the AS.
l Set planned-only, the Helper supports only the planned-GR. By default, the Helper supports
both the planned-GR and unplanned-GR.
l Set never, the router does not support the Helper mode.
----End

Run the display ospf [ process-id ] graceful-restart [ verbose ] command to check the restart
status of OSPF GR.
5.6.12 Improving the Stability of an OSPF Network

A stable OSPF network features less route flapping, normal device performance, and good

Routers
By setting timers, you can reduce the number of unnecessary packets on networks and reduce
the load on the device. Network performance is thus improved.
Before improving the security of an OSPF network, complete the following tasks:

the network layer
required.
5.6.12.1 Setting the Priority of OSPF
Context
The routing protocols may share and select the routing information because the router may run
multiple dynamic routing protocols at the same time. The system sets a priority for each routing
protocol. When multiple routing protocols are used to select routes, the route selected by the
routing protocol with a higher priority takes effect.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
preference [ ase ] { preference | route-policy route-policy-name } *
The priority of OSPF is set.
l If the parameter ase is specified, it indicates that the preference of AS external routes is set.
l The parameter preference specifies the preference of OSPF routes. The smaller the value,
the higher the preference.
l If the parameter route-policy route-policy-name is specified, it indicates that the preference
is set for specified routes according to the routing policy.

Routers
By default, the preference of OSPF routes is 10. When the parameter ase is specified, the default
preference of AS external routes is 150.
----End
5.6.12.2 Configuring the Delay for Transmitting LSAs on the Interface
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospf trans-delay interval
The delay in transmitting LSAs is set on the interface.
By default, the delay in transmitting LSAs is 1 second.
----End
5.6.12.3 Configuring the Interval for Retransmitting LSAs
Context
After sending an LSA packet to the neighboring router, the router waits for a response. If no
response is received within the set interval, the router retransmits the LSA packet to the
neighboring router.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospf timer retransmit interval
The interval for retransmitting LSAs between adjacent routers is set.
By default, the interval for retransmitting LSAs is 5 seconds.

Routers
NOTE
The interval for retransmitting LSAs between adjacent routers cannot be set too small. Otherwise, certain
LSAs are retransmitted unnecessarily. Generally, the interval needs to be greater than the round trip time
of a packet transmitted between two routers.
----End
5.6.12.4 Configuring Stub Routers
Context
After a stub router is configured, the route on the stub router will not be preferentially selected.
After the route cost is set to the maximum value 65535, traffic generally bypasses the router.
This ensures an uninterrupted route on the router during maintenance operations such as upgrade.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
stub-router [ on-startup [ interval ] ]
A stub router is configured.
By default, no router is configured as a stub router.
If a router is configured as a stub router, the router keeps functioning as a stub router for 500s.
NOTE
There is no relation between the stub router configured through this command and the router in a stub area.
----End
5.6.12.5 Suppressing an Interface from Receiving or Sending OSPF Packets
Context
After an OSPF interface is set to be in the silent state, the interface can still advertise its direct
routes. Hello packets on the interface, however, cannot be forwarded. Therefore, no neighbor
relationship can be established on the interface. This can enhance the networking adaptability
of OSPF and reduce the consumption of system resources.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
silent-interface { all | interface-type interface-number }
The interface is suppressed from receiving or sending OSPF packets.
----End
Prerequisites
All configurations of improving the stability of an OSPF network are complete.
Procedure
l Run the display ip routing-table command to check information about the IP routing table.
----End
5.6.13 Improving the Security of an OSPF Network

On a network demanding high security, you can configure OSPF authentication and the
GTSM to improve the security of the OSPF network.
In a network demanding high security, you can configure OSPF authentication and adopt the
GTSM mechanism to improve the security of the OSPF network.
The GTSM mechanism defends against attacks by checking the TTL value. If an attacker keeps
sending packets to a router by simulating real OSPF unicast packets, the router finds itself is the
destination of the packets after the interface board receives these packets. The router directly
sends the packets to the control plane for OSPF processing without checking the validity of the
packets. The router busies itself with processing these "valid" packets. As a result, the system
is busy, and the CPU is highly occupied.
The GTSM mechanism protects a router by checking whether the TTL value in the IP packet
header is in a pre-defined range to enhance the system security.

Routers
NOTE
GTSM supports only unicast addresses; therefore, in OSPF, GTSM takes effect on the virtual link and the
sham link.
Before improving the security of an OSPF network, complete the following tasks:
the network layer
required.
5.6.13.1 Configuring the OSPF GTSM Functions
Context
To apply GTSM functions, enable GTSM on the two ends of the OSPF connection.
The valid TTL range of the detected packets is [255 -hops + 1, 255].
GTSM checks the TTL value of only the packet that matches the GTSM policy. For the packets
that do not match the GTSM policy, you can set them as "pass" or "drop". If the GTSM default
action performed on the packet is set as "drop", you need to configure all the router connections
for GTSM. If the packets sent from a router do not match the GTSM policy, they are dropped.
The connection thus cannot be established. This ensures security but reduces the ease of use.
You can enable the log function to record the information that the packets are dropped. This is
convenient for fault location.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf valid-ttl-hops hops [ vpn-instance vpn-instance-name ]
OSPF GTSM functions are configured.

Routers
NOTE
The ospf valid-ttl-hops command has two functions:

l Enabling OSPF GTSM
l Configuring the TTL value to be detected
The parameter vpn-instance is valid only for the latter function.
Thus, if the private network policy or the public network policy is configured only, it is recommended to
set the default action performed on the packets that do not match the GTSM policy as pass. This prevents
the OSPF packets of other processes from being discarded incorrectly.

gtsm default-action { drop | pass }
The default action performed on the packets that do not match the GTSM policy is set.
By default, the packets that do not match the GTSM policy can pass the filtering.
NOTE
If the default action is configured but the GTSM policy is not configured, GTSM does not take effect.

gtsm log drop-packet all
The log function is enabled on the specified board in the system view. The information that
GTSM drops packets is recorded in the log.
----End
5.6.13.2 Configuring the Area Authentication Mode
Context
In area authentication, all the routers in an area must use the same area authentication mode and
password. For example, the authentication mode of all devices in Area 0 is simple authentication
and the password is abc.
NOTICE
If plain is selected during the configuration of the area authentication mode, the password is
saved in the configuration file in plain text. This brings security risks. It is recommended that
you select cipher to save the password in cipher text.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]

Routers

Step 3 Run:
area area-id

Step 4 Run any of the following command to configure the authentication mode of the OSPF area as
required:
l Run:
authentication-mode simple [ plain plain-text | [ cipher ] cipher-text ]
Simple authentication is configured for the OSPF area.

plain indicates the plain text password.
cipher indicates the cipher text password. For Message Digest 5 (MD5) or Hashed
Message Authentication Code-MD5 (HMAC-MD5) authentication, the authentication
mode is in cipher text by default.
l Run:
authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-
text | [ cipher ] cipher-text } ]
Authentication mode is configured for the OSPF area.

md5 indicates the MD5 cipher text authentication mode.
hmac-md5 indicates the HMAC-MD5 cipher text authentication mode.
hmac-sha256 indicates the HMAC-SHA256 cipher text authentication mode.
key-id specifies the authentication key ID of the cipher authentication.
l Run:
authentication-mode keychain keychain-name
The Keychain authentication is configured for the OSPF area.

NOTE
Before using the Keychain authentication, you need to configure Keychain information in the system
view. To establish the OSPF neighbor relationship, you need to ensure that the key-id, algorithm, and
key-string of the local ActiveSendKey are the same as those of the remote ActiveRecvKey.
----End
5.6.13.3 Configuring the Interface Authentication Mode
Context
The interface authentication mode is used among neighbor routers to set the authentication mode
and password. Its priority is higher than that of the area authentication mode.
NOTICE
If plain is selected during the configuration of the interface authentication mode, the password
is saved in the configuration file in plain text. This brings security risks. It is recommended that

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run any of the following commands to configure the interface authentication mode as required:
l Run:
ospf authentication-mode simple [ plain plain-text | [ cipher ] cipher-text ]
Simple authentication is configured for the OSPF interface.

simple indicates simple authentication.
plain indicates the plain text password. For simple authentication, the authentication
mode is in plain text by default.
cipher indicates the cipher text password. For MD5 or HMAC-MD5 authentication, the
authentication mode is in cipher text by default.
l Run:
ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-
text | [ cipher ] cipher-text } ]
Authentication mode is configured for the OSPF interface.

md5 indicates the MD5 cipher text authentication mode.
hmac-md5 indicates the HMAC-MD5 cipher text authentication mode.
hmac-sha256 indicates the HMAC-SHA256 cipher text authentication mode.
l Run:
ospf authentication-mode null
The OSPF interface is not authenticated.

l Run:
ospf authentication-mode keychain keychain-name
The Keychain authentication is configured for the OSPF area.

NOTE
Before using the Keychain authentication, you need to configure Keychain information in the system
view. To establish the OSPF neighbor relationship, you need to ensure that the key-id, algorithm, and
key-string of the local ActiveSendKey are the same as those of the remote ActiveRecvKey.
----End
Prerequisites
The configurations for Improving Security of an OSPF Network are complete.

Routers
Procedure
l Run the display gtsm statistics { slot-id | all } command to check the GTSM statistics.
l Run the display ospf [ process-id ] request-queue [ interface-type interface-number ]
[ neighbor-id ] command to check the OSPF request queue.
l Run the display ospf [ process-id ] retrans-queue [ interface-type interface-number ]
[ neighbor-id ] command to check the OSPF retransmission queue.
l Run the display ospf [ process-id ] error [ lsa ] command to check the OSPF error
information.
----End
5.6.14 Configuring the Network Management Function of OSPF

OSPF supports the network management function. You can bind the OSPF MIB to a certain
OSPF process, and configure the trap function and log function.
OSPF supports the network management function. You can bind OSPF MIB and a certain OSPF
process. In addition, OSPF also supports the trap function and the log function.
Before configuring the network management function of OSPF, complete the following tasks:
l Configuring IP addresses for interfaces to make neighboring nodes reachable
l Configuring Basic OSPF Functions
required.
5.6.14.1 Configuring OSPF MIB Binding
Context
When multiple OSPF processes are enabled, you can configure OSPF MIB to select the process
to be processed, that is, configure OSPF MIB to select the process to which it is bound.
Do as follows on the OSPF router:
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf mib-binding process-id

Routers
OSPF MIB binding is configured.
----End
5.6.14.2 Configuring OSPF Trap
Procedure
Step 1 Run:
system-view

Step 2 Run:
snmp-agent trap enable feature-name ospf [ trap-name { ospfifauthfailure |
ospfifconfigerror | ospfifrxbadpacket | ospfifstatechange |
ospflsdbapproachingoverflow | ospflsdboverflow | ospfmaxagelsa |
ospfnbrrestarthelperstatuschange | ospfnbrstatechange |
ospfnssatranslatorstatuschange | ospforiginatelsa | ospfrestartstatuschange |
ospftxretransmit | ospfvirtifauthfailure | ospfvirtifconfigerror |
ospfvirtifrxbadpacket | ospfvirtifstatechange | ospfvirtiftxretransmit |
ospfvirtnbrrestarthelperstatuschange | ospfvirtnbrstatechange } ]
The trap function for the OSPF module is enabled.

To enable the traps of one or more events, you can specify type-name.
----End
5.6.14.3 Configuring OSPF Log
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
enable log [ config | error | state | snmp-trap ]
The log function is enabled.
----End
Prerequisites
The configurations for the network management function of OSPF are complete.

Routers
Procedure
l Run the display ospf [ process-id ] brief command to view information about the binding
of OSPF MIBs and OSPF processes.
l Run the display snmp-agent trap feature-name ospf all command to view all trap
messages of the OSPF module.
----End
5.7 Maintaining OSPF

Maintaining OSPF involves resetting OSPF, and clearing OSPF statistics.
5.7.1 Clearing OSPF
Context
NOTICE
OSPF information cannot be restored after you clear it. So, confirm the action before you use
the command.
To clear OSPF information, run the following reset commands in the user view.
Procedure
l Run the reset ospf [ process-id ] counters [ neighbor [ interface-type interface-number ]
[ router-id ] ] command to reset OSPF counters.
counters indicates OSPF counters.
neighbor indicates neighbor information on the specified interface.
l Run the reset ospf [ process-id ] redistribution command in the user view to re-import
routes by OSPF.
l Run the reset gtsm statistics all command in the user view to clear the GTSM statistics
on the board.
----End
5.7.2 Resetting OSPF

Routers
Context
NOTICE
The OSPF adjacency relationship between the routers will be torn down after you run the reset
ospf command to reset OSPF connections. So, confirm the action before you use the command.
To reset OSPF connections, run the following reset commands in the user view.
Procedure
l Run the reset ospf [ process-id ] process [ flush-waiting-timer time | graceful-restart ]
command in the user view to Restart the OSPF process.
----End
5.8 Configuring Examples

This section provides several configuration examples of OSPF together with the configuration
roadmap.
5.8.1 Example for Configuring Basic OSPF Functions
As shown in Figure 5-25, all routers run OSPF, and the entire AS is divided into three areas.
Router A and Router B serve as ABRs to forward routes between areas.
After the configuration, each router should learn the routes from the AS to all network segments.

Routers
Figure 5-25 Networking diagram of configuring basic OSPF functions
Area0
RouterA GE1/0/0 RouterB
192.168.0.1/24 GE1/0/0
192.168.0.2/24
GE2/0/0 GE2/0/0
192.168.1.1/24 192.168.2.1/24
GE1/0/0 GE1/0/0
192.168.1.2/24 192.168.2.2/24
RouterC RouterD
GE2/0/0 GE2/0/0
172.16.1.1/24 172.17.1.1/24
GE2/0/0 GE2/0/0
172.16.1.2/24 172.17.1.2/24
RouterE RouterF
Area1 Area2
1. Enable OSPF on each router.

2. Specify network segments in different areas.
Procedure
<Huawei> system-view
[Huawei] sysname RouterA
The configurations of Router B, Router C, Router D, Router E, and Router F are similar to the
configuration of Router A, and are not mentioned here.
Step 2 Configure basic OSPF functions.
[RouterA] router id 1.1.1.1
[RouterA] ospf
[RouterA-ospf-1] area 0

Routers
[RouterA-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255

[RouterA-ospf-1-area-0.0.0.0] quit
[RouterB] router id 2.2.2.2
[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterC] router id 3.3.3.3
[RouterC] ospf
[RouterC-ospf-1] area 1
[RouterC-ospf-1-area-0.0.0.1] network 192.168.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.1] quit
[RouterD] router id 4.4.4.4
[RouterD] ospf
[RouterD-ospf-1] area 2
[RouterD-ospf-1-area-0.0.0.2] network 192.168.2.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.2] quit
# Configure Router E.
[RouterE] router id 5.5.5.5
[RouterE] ospf
[RouterE-ospf-1] area 1
[RouterE-ospf-1-area-0.0.0.1] network 172.16.1.0 0.0.0.255
[RouterE-ospf-1-area-0.0.0.1] quit
# Configure Router F.
[RouterF] router id 6.6.6.6
[RouterF] ospf
[RouterF-ospf-1] area 2
[RouterF-ospf-1-area-0.0.0.2] network 172.17.1.0 0.0.0.255
[RouterF-ospf-1-area-0.0.0.2] quit
# View OSPF neighbors of Router A.

[RouterA] display ospf peer
OSPF Process 1 with Router ID 1.1.1.1
Neighbors
Area 0.0.0.0 interface 192.168.0.1(GigabitEthernet1/0/0)'s neighbors
Router ID: 2.2.2.2 Address: 192.168.0.2
State: Full Mode:Nbr is Master Priority: 1
DR: 192.168.0.2 BDR: 192.168.0.1 MTU: 0
Dead timer due in 36 sec
Retrans timer interval: 5
Neighbor is up for 00:15:04
Authentication Sequence: [ 0 ]
Neighbors

Routers

DR: 192.168.1.2 BDR: 192.168.1.1 MTU: 0
# View the OSPF routing information of Router A.

[RouterA] display ospf routing
Routing Tables
Routing for Network
Destination Cost Type NextHop AdvRouter Area
172.16.1.0/24 2 Transit 192.168.1.2 3.3.3.3 0.0.0.1
172.17.1.0/24 3 Inter-area 192.168.0.2 2.2.2.2 0.0.0.0
192.168.0.0/24 1 Transit 192.168.0.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
192.168.2.0/24 2 Inter-area 192.168.0.2 2.2.2.2 0.0.0.0
Total Nets: 5
Intra Area: 3 Inter Area: 2 ASE: 0 NSSA: 0
# View the LSDB of Router A.

[RouterA] display ospf lsdb
Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 2.2.2.2 2.2.2.2 317 48 80000003 1
Router 1.1.1.1 1.1.1.1 316 48 80000002 1
Network 192.168.0.2 2.2.2.2 399 32 800000F8 0
Sum-Net 172.16.1.0 1.1.1.1 250 28 80000001 2
Sum-Net 172.17.1.0 2.2.2.2 203 28 80000001 2
Sum-Net 192.168.2.0 2.2.2.2 237 28 80000002 1
Sum-Net 192.168.1.0 1.1.1.1 295 28 80000002 1
Area: 0.0.0.1
Router 5.5.5.5 5.5.5.5 214 36 80000004 1
Router 3.3.3.3 3.3.3.3 217 60 80000008 1
Router 1.1.1.1 1.1.1.1 289 48 80000002 1
Network 192.168.1.1 1.1.1.1 202 28 80000002 0
Network 172.16.1.1 3.3.3.3 670 32 80000001 0
Sum-Net 172.17.1.0 1.1.1.1 202 28 80000001 3
Sum-Net 192.168.2.0 1.1.1.1 242 28 80000001 2
Sum-Net 192.168.0.0 1.1.1.1 300 28 80000001 1
# View the routing table of Router D and test connectivity by using the ping command.
[RouterD] display ospf routing
Routing Tables
Routing for Network
172.16.1.0/24 4 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
172.17.1.0/24 1 Transit 172.17.1.1 4.4.4.4 0.0.0.2
192.168.0.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.1.0/24 3 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.2.0/24 1 Transit 192.168.2.2 4.4.4.4 0.0.0.2
Total Nets: 5
[RouterD] ping 172.16.1.1

Routers

0.00% packet loss
----End
Configuration Files
#
sysname RouterA
#
ip address 192.168.0.1 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
ip address 192.168.0.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#

Routers
return

#
sysname RouterD
#
router id 4.4.4.4
#
ip address 192.168.2.2 255.255.255.0
#
ip address 172.17.1.1 255.255.255.0
#
ospf 1
area 0.0.0.2
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
return
l Configuration file of Router E

#
sysname RouterE
#
router id 5.5.5.5
#
ip address 172.16.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
#
return
l Configuration file of Router F

#
sysname RouterF
#
router id 6.6.6.6
#
ip address 172.17.1.2 255.255.255.0
#
ospf 1
area 0.0.0.2
network 172.17.1.0 0.0.0.255
#
return
5.8.2 Example for Configuring OSPF Virtual Links
As shown in Figure 5-26, Area 2 does not connect to the backbone area directly. Area 1 serves
as a transit area to connect Area 2 and Area 0. A virtual link is configured between Router A
and Router B.

Routers
Figure 5-26 Configuring OSPF virtual links
Area1
RouterA GE1/0/0 GE1/0/0 RouterB
192.168.1.1/24 192.168.1.2/24
GE2/0/0 GE2/0/0
10.1.1.1/8 Virtual Link 172.16.1.1/16
GE2/0/0 GE2/0/0
10.1.1.2/8 172.16.1.2/16
Area0 Area2
RouterC RouterD
1. Configure basic OSPF functions on each router.

2. Configure virtual connections on Router A and Router B to connect the backbone area with
the non-backbone area.
Procedure
[RouterA] ospf 1 router-id 1.1.1.1

Routers
[RouterB] ospf 1 router-id 2.2.2.2

[RouterC] ospf 1 router-id 3.3.3.3
[RouterD] ospf 1 router-id 4.4.4.4
# View the OSPF routing table of Router A.
NOTE
The routing table of Router A does not contain routes in Area 2 because Area 2 is not directly connected
to Area 0.
Routing Tables
Routing for Network
10.0.0.0/8 1 Transit 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 2
Step 3 Configure virtual links.
[RouterA] ospf 1
[RouterA-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[RouterB] ospf 1
[RouterB-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1
# View the OSPF routing table of Router A.

Routing Tables
Routing for Network
172.16.0.0/16 2 Inter-area 192.168.1.2 2.2.2.2 0.0.0.2
10.0.0.0/8 1 Transit 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 3

Routers
----End
Configuration Files
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ip address 10.1.1.1 255.0.0.0
#
ospf 1 router-id 1.1.1.1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 2.2.2.2
#
return

#
sysname RouterB
#
ip address 192.168.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.0.0
#
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 1.1.1.1
area 0.0.0.2
network 172.16.0.0 0.0.255.255
#
return

#
sysname RouterC
#
ip address 10.1.1.2 255.0.0.0
#
area 0.0.0.0
network 10.0.0.0 0.255.255.255
#
return

#
sysname RouterD
#
ip address 172.16.1.2 255.255.0.0
#
area 0.0.0.2

Routers
network 172.16.0.0 0.0.255.255

#
return
5.8.3 Example for Configuring DR Election of OSPF
As shown in Figure 5-27, Router A has the highest priority (100) in the network and is elected
as the DR. Router C has the second highest priority, and is elected as the BDR. The priority of
Router B is 0, and Router B cannot be elected as the DR or BDR. The priority of Router D is
not configured and its default value is 1.
Figure 5-27 Configuring DR election of OSPF
RouterA RouterB
GE1/0/0 GE1/0/0
192.168.1.1/24 192.168.1.2/24
GE1/0/0 GE1/0/0
192.168.1.3/24 192.168.1.4/24
RouterC RouterD
1. Configure the router ID on each router, enable OSPF, and specify the network segment.
2. Check the DR/BDR status of each router with the default priority.
3. Configure the DR priority of the interface and check the DR/BDR status.
Procedure
The configuration details are not mentioned here.
[RouterA] ospf

Routers

[RouterB] ospf
[RouterC] ospf
[RouterD] ospf
# View the DR/BDR status.

[RouterA] display ospf peer
Neighbors
State: 2-Way Mode:Nbr is Master Priority: 1
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
# View the neighbor information of Router A. You can see the priority of DR and the neighbor
status. The Router D is the DR, and Router C is the BDR.
NOTE
When the priority is the same, the router with a higher router ID is elected as the DR. If a new router is
added after the DR/BDR election is complete, the new router cannot become the DR even if it has the
highest priority.
Step 3 Configure DR priorities on interfaces.

[RouterA-GigabitEthernet1/0/0] ospf dr-priority 100

Routers

[RouterB-GigabitEthernet1/0/0] ospf dr-priority 0
[RouterC-GigabitEthernet1/0/0] ospf dr-priority 2
# View the DR/BDR status.

[RouterD] display ospf peer
Neighbors
State: Full Mode:Nbr is Slave Priority: 100
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
Step 4 Restart OSPF processes.
In the user view of each router, run the reset ospf 1 process command to restart the OSPF
process.
Step 5 View the configuration.
# View the status of OSPF neighbors.

[RouterD] display ospf peer
Neighbors
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

Routers
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

# View the status of the OSPF interface.

[RouterA] display ospf interface
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 100 192.168.1.1 192.168.1.3
[RouterB] display ospf interface
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.2 Broadcast DROther 1 0 192.168.1.1 192.168.1.3
If all neighbors are in the Full state, it indicates that Router A establishes the neighbor
relationship with its neighbor. If the neighbor stays "2-Way", it indicates both of them are not
the DR or BDR. They need not exchange LSAs.
If the status of the OSPF interface is DROther, it indicates that it is neither DR nor BDR.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
ip address 192.168.1.1 255.255.255.0
ospf dr-priority 100
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
ip address 192.168.1.2 255.255.255.0
ospf dr-priority 0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#

Routers
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.1.3 255.255.255.0
ospf dr-priority 2
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
ip address 192.168.1.4 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
5.8.4 Example for Configuring OSPF Stub Areas
As shown in Figure 5-28, all routers run OSPF, and the entire AS is divided into three areas.
Router A and Router B serve as ABRs to forward routes between areas. Router D serves as an
ASBR to import external routes (static routes).
It is required to configure Area 1 as a stub area to reduce the LSAs advertised to this area without
affecting the route reachability.

Routers
Figure 5-28 Configuring OSPF stub areas
Area0
RouterA GE1/0/0 RouterB
192.168.0.1/24 GE1/0/0
Area1 192.168.0.2/24
Area2
GE2/0/0 GE2/0/0
192.168.1.1/24 192.168.2.1/24
GE1/0/0 GE1/0/0
192.168.1.2/24 192.168.2.2/24
RouterC RouterD
ASBR
GE2/0/0 GE2/0/0
172.16.1.1/24 Stub 172.17.1.1/24
GE2/0/0 GE2/0/0
172.16.1.2/24 172.17.1.2/24
RouterE RouterF
1. Enable OSPF on each router, and configure basic OSPF functions.

2. Configure static routes on Router D, and import them into OSPF.
3. Configure Area 1 as a stub area, and check the OSPF routing information on Router C.
4. Stop Router A from advertising Type 3 LSAs to the stub area, and check the OSPF routing
information on Router C.
Procedure

Routers
[RouterA] ospf
[RouterB] ospf
[RouterC] ospf
[RouterD] ospf
[RouterE] router id 5.5.5.5
[RouterE] ospf
[RouterE-ospf-1-area-0.0.0.1] network 172.16.1.0 0.0.0.255
[RouterF] router id 6.6.6.6
[RouterF] ospf
[RouterF-ospf-1] area 2
[RouterF-ospf-1-area-0.0.0.2] network 172.17.1.0 0.0.0.255
[RouterF-ospf-1-area-0.0.0.2] quit
Step 3 Configure Router D to import static routes.

[RouterD] ip route-static 200.0.0.0 8 null 0
[RouterD] ospf
[RouterD-ospf-1] import-route static type 1
[RouterD-ospf-1] quit
# View ABR/ASBR information on Router C.

[RouterC] display ospf abr-asbr

Routers

Routing Table to ABR and ASBR
RtType Destination Area Cost Nexthop Type
Intra-area 1.1.1.1 0.0.0.1 1 192.168.1.1 ABR
Inter-area 4.4.4.4 0.0.0.1 3 192.168.1.1 ASBR
# View the OSPF routing table of Router C.
NOTE
When Router C is in a common area, there are AS external routes in the routing table.
[RouterC] display ospf routing
Routing Tables
Routing for Network
172.16.1.0/24 1 Transit 172.16.1.1 3.3.3.3 0.0.0.1
172.17.1.0/24 4 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.1.0/24 1 Transit 192.168.1.2 3.3.3.3 0.0.0.1
192.168.2.0/24 3 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
Routing for ASEs
Destination Cost Type Tag NextHop AdvRouter
200.0.0.0/8 4 Type1 1 192.168.1.1 4.4.4.4
Total Nets: 6
Step 4 Configure Area 1 as a stub area.

[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub
[RouterC] ospf
[RouterC-ospf-1-area-0.0.0.1] stub
[RouterE] ospf
[RouterE-ospf-1-area-0.0.0.1] stub
# View the routing table of Router C.
NOTE
After the area where Router C resides is configured as a stub area, AS external routes are invisible. Instead,
there is a default route.
Routing Tables
Routing for Network
0.0.0.0/0 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
172.16.1.0/24 1 Transit 172.16.1.1 3.3.3.3 0.0.0.1
172.17.1.0/24 4 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.1.0/24 1 Transit 192.168.1.2 3.3.3.3 0.0.0.1
192.168.2.0/24 3 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1

Routers
Total Nets: 6
Step 5 # Stop Router A from advertising Type 3 LSAs to the stub area.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub no-summary

# View the OSPF routing table of Router C.
Routing Tables
Routing for Network
0.0.0.0/0 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
172.16.1.0/24 1 Transit 172.16.1.1 3.3.3.3 0.0.0.1
192.168.1.0/24 1 Transit 192.168.1.2 3.3.3.3 0.0.0.1
Total Nets: 3
NOTE
After the advertisement of summary LSAs to a stub area is disabled, the routing entries of the stub router
are further reduced, and only the default route to a destination outside the AS is reserved.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
ip address 192.168.0.1 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub no-summary
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
ip address 192.168.0.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#

Routers
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
stub
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
ip address 192.168.2.2 255.255.255.0
#
ip address 172.17.1.1 255.255.255.0
#
ospf 1
import-route static type 1
area 0.0.0.2
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
ip route-static 200.0.0.0 255.0.0.0 NULL0
#
return
l Configuration file of Router E

#
sysname RouterE
#
router id 5.5.5.5
#
ip address 172.16.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
stub
#
return

Routers
#
sysname RouterF
#
router id 6.6.6.6
#
ip address 172.17.1.2 255.255.255.0
#
ospf 1
area 0.0.0.2
network 172.17.1.0 0.0.0.255
#
return
5.8.5 Example for Configuring OSPF NSSAs
As shown in Figure 5-29, all routers run OSPF, and the entire AS is divided into two areas.
Router A and Router B serve as ABRs to forward routes between areas. Router D serves as an
ASBR to import external routes (static routes).
It is required to configure Area 1 as an NSSA. Configure Router A and Router B as translators

in the NSSA, configure Router D as an ASBR to import external routes (static routes) and
correctly transmit routing information inside the AS.
Figure 5-29 Configuring an OSPF NSSA
RouterA
GE2/0/0 GE1/0/0
192.168.3.1/24 192.168.0.1/24
GE1/0/0
192.168.3.2/24 GE3/0/0 GE1/0/0
192.168.1.1/24 192.168.0.2/24
RouterD
ASBR RouterC
GE1/0/0
192.168.1.2/24 GE2/0/0
GE2/0/0 192.168.2.2/24
192.168.4.1/24
GE3/0/0 GE2/0/0
Area1 192.168.4.2/24
NSSA 192.168.2.1/24 Area0
RouterB
1. Enable OSPF on each router, and configure basic OSPF functions.

2. Configure Area 1 as an NSSA (run the nssa command on all routers in Area 1), and check
the OSPF routing information and LSDB of Router C.

Routers
3. Configure static routes on Router D, and import them into OSPF.

4. Configure translators in the NSSA.
Procedure
Step 2 Configure basic OSPF functions (see Example for Configuring Basic OSPF Functions).
Step 3 Configure Area 1 as an NSSA.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] nssa
[RouterB] ospf
[RouterB-ospf-1-area-0.0.0.1] nssa
[RouterD] ospf
[RouterD-ospf-1-area-0.0.0.1] nssa
Step 4 Configure Router D to import static routes.

[RouterD] ip route-static 100.0.0.0 8 null 0
[RouterD] ospf
[RouterD-ospf-1] import-route static
[RouterD-ospf-1] quit
# Display the OSPF routing table of Router C.

NOTE
l On Router C, you can view that the router ID of the advertising router that imports AS external routes
in the NSSA, that is, the router ID of Router B is 2.2.2.2.
l OSPF selects the ABR with larger router ID as a translator.

Routing Tables
Routing for Network

192.168.3.0/24 2 Inter-area 192.168.0.1 1.1.1.1 0.0.0.0
192.168.4.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.0
192.168.0.0/24 1 Transit 192.168.0.2 3.3.3.3 0.0.0.0
192.168.1.0/24 2 Inter-area 192.168.0.1 1.1.1.1 0.0.0.0
192.168.1.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.0
192.168.2.0/24 1 Transit 192.168.2.2 3.3.3.3 0.0.0.0
Routing for ASEs

100.0.0.0/8 1 Type2 1 192.168.2.1 2.2.2.2

Routers
Total Nets: 7
# Display the OSPF LSDB of Router C.

[RouterC] display ospf lsdb

Link State Database
Area: 0.0.0.0
Router 3.3.3.3 3.3.3.3 345 72 80000004 1
Router 2.2.2.2 2.2.2.2 346 48 80000005 1
Router 1.1.1.1 1.1.1.1 193 48 80000006 1
Network 192.168.0.2 3.3.3.3 385 32 80000007 0
Network 192.168.2.2 3.3.3.3 387 32 80000008 0
Sum-Net 192.168.4.0 2.2.2.2 393 28 80000001 1
Sum-Net 192.168.4.0 1.1.1.1 189 28 80000001 2
Sum-Net 192.168.3.0 1.1.1.1 189 28 80000002 1
Sum-Net 192.168.3.0 2.2.2.2 192 28 80000002 2
Sum-Net 192.168.1.0 2.2.2.2 393 28 80000001 1
Sum-Net 192.168.1.0 1.1.1.1 189 28 80000002 1
AS External Database
External 100.0.0.0 2.2.2.2 257 36 80000002 1
Step 5 Configure Router A as a translator.

[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] nssa default-route-advertise no-summary translator-
always
[RouterA-ospf-1] quit
# Display the OSPF routing table of Router C.
NOTE
On Router C, an AS external route is imported.


Routing Tables
Routing for Network

192.168.3.0/24 2 Inter-area 192.168.0.1 1.1.1.1 0.0.0.0
192.168.4.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.0
192.168.0.0/24 1 Transit 192.168.0.2 3.3.3.3 0.0.0.0
192.168.1.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.0
192.168.1.0/24 2 Inter-area 192.168.0.1 1.1.1.1 0.0.0.0
192.168.2.0/24 1 Transit 192.168.2.2 3.3.3.3 0.0.0.0
Routing for ASEs

100.0.0.0/8 1 Type2 1 192.168.0.1 1.1.1.1
Total Nets: 7

Routers
NOTE
l On RouterC, the router ID of the advertising router that imports AS external routes to the NSSA changes
to 1.1.1.1. That is, RouterA becomes the translator.
l By default, the new translator, together with the former translator, acts as the translator for 40s. After
40s, only the new translator continues to work as a translator.
# Display the OSPF LSDB of Router C.

[RouterC] display ospf lsdb

Link State Database
Area: 0.0.0.0
Router 3.3.3.3 3.3.3.3 493 72 80000004 1
Router 2.2.2.2 2.2.2.2 494 48 80000005 1
Router 1.1.1.1 1.1.1.1 341 48 80000006 1
Network 192.168.0.2 3.3.3.3 501 32 80000007 0
Network 192.168.2.2 3.3.3.3 503 32 80000008 0
Sum-Net 192.168.4.0 2.2.2.2 541 28 80000001 1
Sum-Net 192.168.4.0 1.1.1.1 337 28 80000001 2
Sum-Net 192.168.3.0 1.1.1.1 337 28 80000002 1
Sum-Net 192.168.3.0 2.2.2.2 340 28 80000002 2
Sum-Net 192.168.1.0 2.2.2.2 541 28 80000001 1
Sum-Net 192.168.1.0 1.1.1.1 337 28 80000002 1
AS External Database
External 100.0.0.0 1.1.1.1 248 36 80000001 1
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
ip address 192.168.0.1 255.255.255.0
#
ip address 192.168.3.1 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
nssa default-route-advertise no-summary translator-always
#
return

#
sysname RouterB

Routers
#
router id 2.2.2.2
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ip address 192.168.4.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
nssa
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.0.2 255.255.255.0
#
ip address 192.168.2.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
ip address 192.168.3.2 255.255.255.0
#
ip address 192.168.4.1 255.255.255.0
#
ospf 1
import-route static
area 0.0.0.1
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
nssa
#
#
return

Routers
5.8.6 Example for Configuring OSPF IP FRR

When a fault occurs on the network, OSPF IP FRR can fast switch traffic to the backup link
without waiting for route convergence. This ensures uninterrupted traffic transmission.
As shown in Figure 5-30:
l OSPF runs on the four routers in the same area.
l If the link between Router A and Router C becomes faulty, the traffic forwarded by
Router A is rapidly switched to the backup link and forwarded through Router B.
Figure 5-30 Networking diagram for configuring OSPF IP FRR

RouterB
Router-id
2.2.2.2
GE1/0/1 GE1/0/2
1.2.1.2/24 2.3.1.2/24
co
st
=
9
5
=
GE1/0/1 GE1/0/3
st
co
1.2.1.1/24 2.3.1.3/24
cost = 4 cost = 55
GE1/0/2 GE1/0/1 GE1/0/2 GE1/0/1
RouterA 1.3.1.1/24 1.3.1.3/24 RouterC 3.4.1.3/24 3.4.1.4/24 RouterD
Router-id Router-id Router-id
1.1.1.1 3.3.3.3 4.4.4.4
1. Configure basic OSPF functions on each router.
2. Set the cost to ensure that the link from Router A to Router C is preferred.
3. Enable OSPF IP FRR on Router A to protect the traffic forwarded by Router A.
Procedure
Step 1 Configure an IP address and the cost for each interface. This example assumes that you know
the configuration method and no details are provided here.
[RouterA] ospf

Routers
[RouterB] ospf
[RouterC] ospf
[RouterD] ospf
Step 3 Enable OSPF IP FRR on Router A.

# Enable OSPF IP FRR on Router A.
[RouterA] ospf
[RouterA-ospf-1] frr
[RouterA-ospf-1-frr] loop-free-alternate

# View information about the route from Router A to Router D. You can find that OSPF generates
a backup route because OSPF IP FRR is enabled.
<RouterA> display ospf routing router-id 4.4.4.4
Destination : 4.4.4.4 Route Type : Intra-area

Area : 0.0.0.1 AdvRouter : 4.4.4.4
Type : Normal Age : 00h31m27s
URT Cost : 59
NextHop : 1.3.1.3 Interface : GigabitEthernet1/0/2
Backup Nexthop : 1.2.1.2 Backup Interface : GigabitEthernet1/0/1
Backup Type : LFA LINK
The preceding display shows that a backup route is generated on Router A.
----End
Configuration Files
#
sysname RouterA
#
router-id 1.1.1.1
#
ip address 1.2.1.1 255.255.255.0
ospf cost 9

Routers
#
ip address 1.3.1.1 255.255.255.0
ospf cost 4
#
ospf 1
frr
loop-free-alternate
area 0.0.0.1
network 1.2.1.0 0.0.0.255
network 1.3.1.0 0.0.0.255
#
return

#
sysname RouterB
#
router-id 2.2.2.2
#
ip address 1.2.1.2 255.255.255.0
ospf cost 9
#
ip address 2.3.1.2 255.255.255.0
ospf cost 5
#
ospf 1
area 0.0.0.1
network 2.3.1.0 0.0.0.255
network 1.2.1.0 0.0.0.255
#
return

#
sysname RouterC
#
router-id 3.3.3.3
#
ip address 1.3.1.3 255.255.255.0
ospf cost 4
#
ip address 3.4.1.3 255.255.255.0
ospf cost 55
#
ip address 2.3.1.3 255.255.255.0
ospf cost 5
#
ospf 1
area 0.0.0.1
network 2.3.1.0 0.0.0.255
network 1.3.1.0 0.0.0.255
network 3.4.1.0 0.0.0.255
#
return

#
sysname RouterD
#
router-id 4.4.4.4
#

Routers
ip address 3.4.1.4 255.255.255.0
ospf cost 55
#
ospf 1
area 0.0.0.1
network 3.4.1.0 0.0.0.255
#
return
5.8.7 Example for Configuring BFD for OSPF
As shown in Figure 5-31, it is required as follows:
l Run OSPF between Router A, Router B, and Router C.

l Enable BFD of the OSPF process on Router A, Router B, and Router C.
l Traffic is transmitted on the active link Router A Router B. The link Router A Router
C Router B acts as the standby link.
l BFD of the interface is configured on the link between Router A and Router B. When a
fault occurs on the link, BFD can quickly detect the fault and notify OSPF of the fault;
therefore, the traffic is transmitted on the standby link.
Figure 5-31 Networking diagram for configuring BFD for OSPF
RouterA RouterB GE3/0/0

172.16.1.1/24
GE2/0/0 GE2/0/0
GE1/0/0 3.3.3.1/24 3.3.3.2/24 GE1/0/0
1.1.1.1/24 2.2.2.2/24
GE1/0/0 GE2/0/0
1.1.1.2/24 2.2.2.1/24
RouterC Area0
1. Enable the basic OSPF functions on each router.

2. Enable global BFD.
3. Enable the detection mechanism on Router A and Router B.

Routers
Procedure
Step 1 Assign an IP address to each router interface.
The detailed configuration is not mentioned here.
Step 2 Configure the basic OSPF functions.
[RouterA] ospf
[RouterB] ospf
[RouterB-ospf-1] quit
[RouterC] ospf
[RouterC-ospf-1] quit
# After the preceding configurations are complete, run the display ospf peer command. You
can view that the neighboring relationship is set up between Router A, Router B, and Router C.
Take the display of Router A as an example:
<RouterA> display ospf peer
Neighbors
DR: 1.1.1.1 BDR: 1.1.1.2 MTU: 0
Neighbors
DR: 3.3.3.1 BDR: 3.3.3.2 MTU: 0

Routers
# Display the information in the OSPF routing table on Router A. You can view the routing
entries to Router B and Router C. The next hop address of the route to 172.16.1.0/24 is 3.3.3.2
and traffic is transmitted on the active link Router A Router B.
<RouterA> display ospf routing
Routing Tables
Routing for Network
172.16.1.0/24 2 Transit 3.3.3.2 2.2.2.2 0.0.0.0
3.3.3.0/24 1 Transit 3.3.3.1 1.1.1.1 0.0.0.0
2.2.2.0/24 2 Transit 3.3.3.2 2.2.2.2 0.0.0.0
2.2.2.0/24 2 Transit 1.1.1.2 2.2.2.2 0.0.0.0
1.1.1.0/24 1 Transit 1.1.1.1 1.1.1.1 0.0.0.0
Total Nets: 5
Step 3 Configure OSPF BFD.

# Enable global BFD on Router A.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] ospf
[RouterA-ospf-1] bfd all-interfaces enable
# Enable global BFD on Router B.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] ospf
[RouterB-ospf-1] bfd all-interfaces enable
# Enable global BFD on Router C.

[RouterC] bfd
[RouterC-bfd] quit
[RouterC] ospf
[RouterC-ospf-1] bfd all-interfaces enable
# After the preceding configurations are complete, run the display ospf bfd session all command
on Router A or Router B. You can view that the status of the BFD session is Up.
Take the display of Router A as an example:
[RouterA] display ospf bfd session all
Area 0.0.0.0 interface 1.1.1.1(GigabitEthernet1/0/0)'s BFD Sessions
NeighborId:3.3.3.3 AreaId:0.0.0.0 Interface:GigabitEthernet1/0/0
BFDState:up rx :1000 tx :1000
Multiplier:3 BFD Local Dis:8195 LocalIpAdd:1.1.1.1
RemoteIpAdd:1.1.1.2 Diagnostic Info:No diagnostic information
NeighborId:2.2.2.2 AreaId:0.0.0.0 Interface:GigabitEthernet2/0/0
Step 4 Configure BFD of the interface.

# Configure BFD on GE 2/0/0 of Router A, set the minimum interval for sending the packets
and the minimum interval for receiving the packets to 500 ms, and set the local detection time
multiple to 4.

Routers

[RouterA-GigabitEthernet2/0/0] ospf bfd enable
[RouterA-GigabitEthernet2/0/0] ospf bfd min-tx-interval 500 min-rx-interval 500
detect-multiplier 4
# Configure BFD on GE 2/0/0 of Router B, set the minimum interval for sending the packets
and the minimum interval for receiving the packets to 500 ms, and set the local detection time
multiple to 4.
[RouterB-GigabitEthernet2/0/0] ospf bfd enable
[RouterB-GigabitEthernet2/0/0] ospf bfd min-tx-interval 500 min-rx-interval 500
detect-multiplier 4
# After the preceding configurations are complete, run the display ospf bfd session all command
on Router A or Router B. You can view that the status of the BFD session is Up.
Take the display of Router B as an example:
[RouterB] display ospf bfd session all

NeighborId:1.1.1.1 AreaId:0.0.0.0 Interface:


# Run the shutdown command on GE 2/0/0 of Router B to simulate the active link failure.
# Display the routing table on Router A. The standby link Router A Router C Router B
takes effect after the active link fails. The next hop address of the route to 172.16.1.0/24 becomes
1.1.1.2.
<RouterA> display ospf routing
Routing Tables
Routing for Network
172.16.1.0/24 3 Transit 1.1.1.2 2.2.2.2 0.0.0.0
3.3.3.0/24 1 Transit 3.3.3.1 1.1.1.1 0.0.0.0
2.2.2.0/24 2 Transit 1.1.1.2 2.2.2.2 0.0.0.0
1.1.1.0/24 1 Transit 1.1.1.1 1.1.1.1 0.0.0.0
Total Nets: 4
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#

Routers
bfd
#
ip address 1.1.1.1 255.255.255.0
#
ip address 3.3.3.1 255.255.255.0
ospf bfd enable
ospf bfd min-tx-interval 500 min-rx-interval 500 detect-multiplier 4
#
ospf 1
area 0.0.0.0
network 3.3.3.0 0.0.0.255
network 1.1.1.0 0.0.0.255
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
bfd
#
ip address 2.2.2.2 255.255.255.0
#
ip address 3.3.3.2 255.255.255.0
ospf bfd enable
ospf bfd min-tx-interval 500 min-rx-interval 500 detect-multiplier 4
#
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 3.3.3.0 0.0.0.255
network 2.2.2.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
bfd
#
ip address 1.1.1.2 255.255.255.0
#
ip address 2.2.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 1.1.1.0 0.0.0.255
network 2.2.2.0 0.0.0.255
#
return

Routers
5.8.8 Example for Configuring OSPF GTSM
As shown on the network shown in Figure 5-32,routers run OSPF and GTSM is enabled on
Router A, Router B, and Router C.
Figure 5-32 Networking diagram of OSPF GTSM
RouterB
Virtual Link
GE1/0/0
192.168.1.2/24
GE1/0/0 GE3/0/0
10.1.1.2/8 10.1.1.1/8 GE1/0/0
192.168.1.1/24
Network
GE2/0/0
192.168.2.1/24
RouterD RouterA
GE2/0/0
Area0
192.168.2.2/24
Virtual Link
RouterC
Area1
1. Configure OSPF.
2. Enable GTSM on each router and specify a valid TTL range for packets.
Procedure
Step 2 Configure basic OSPF functions (see Example for Configuring Basic OSPF Functions).
Step 3 Configure OSPF GTSM.
# On Router A, set the maximum valid TTL range for packets from Router A to other routers is
255 to 255.
[RouterA] ospf valid-ttl-hops 1

Routers
# On Router B, set the maximum valid TTL range for packets from Router B to other routers is
254 to 255.
[RouterB] ospf valid-ttl-hops 2
# On Router C, set the maximum valid TTL range for packets from Router C to other routers is
254 to 255.
[RouterC] ospf valid-ttl-hops 2
# Check whether OSPF neighbor relationships between routers are successfully established.
Take the display on Router C as an example. The neighbor relationship is Full, indicating that
the neighbor relationship is successfully established.
[RouterC] display ospf peer
Neighbors
DR: 192.168.2.2 BDR: 192.168.2.1 MTU: 0
# On Router C, run the display gtsm statistics all command. You can view GTSM statistics on
Router C. The default behavior is pass, no illegal packets exist, and the number of discarded
packets is 0.
<RouterC> display gtsm statistics all
GTSM Statistics Table
----------------------------------------------------------------
SlotId Protocol Total Counters Drop Counters Pass Counters
----------------------------------------------------------------
0 BGP 0 0 0
0 BGPv6 0 0 0
0 OSPF 0 0 0
0 LDP 0 0 0
1 BGP 0 0 0
1 BGPv6 0 0 0
1 OSPF 0 0 0
1 LDP 0 0 0
2 BGP 0 0 0
2 BGPv6 0 0 0
2 OSPF 0 0 0
2 LDP 0 0 0
3 BGP 0 0 0
3 BGPv6 0 0 0
3 OSPF 0 0 0
3 LDP 0 0 0
----------------------------------------------------------------
----End
Configuration files
#
sysname RouterA
#
router id 1.1.1.1

Routers
#
ip address 192.168.1.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ip address 10.1.1.1 255.0.0.0
#
ospf 1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
ospf valid-ttl-hops 1
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
ip address 192.168.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.2.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.2.0 0.0.0.255
#
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
ip address 10.1.1.2 255.0.0.0
#
ospf 1
area 0.0.0.0
network 10.0.0.0 0.255.255.255

Routers
#
return
5.9 FAQ
5.9.1 Which OSPF Interfaces Require Peers?

You must configure peers on interfaces in the open shortest path first (OSPF) view, if the link
type of the network is Non-Broadcast Multi-Access (NBMA).
5.9.2 How Do I Calculate the Cost of an IGP Route?

IGP protocols include RIP, IS-IS, and OSPF.
Calculating the Cost of a RIP Route

RIP measures the distance from the local end to the destination by hop count. The hop count is
also called the metric. RIP defines that the hop count from a router to a directly connected
network is 0, and the hop count from a router to a network that can be reached through another
router is 1. The hop count increases with the number of routers between the local router and the
destination network. To limit the convergence time, RIP defines that the hop count must be an
integer ranging from 0 to 15. A hop count of 16 or greater is defined as infinite. That is, the
destination network or host is unreachable.
An interface does not add the cost to RIP routes to be sent, but increases the cost by 1 for the
received RIP routes. You can run the following commands to change the cost of routes:
l After you run the rip metricin command, the AR150&200&1200&2200&3200 adds an
additional metric to a received route, and then adds the route to the routing table. Then the
metric of the route changes in the routing table. This command affects route selection on
the local device and other devices.
l After you run the rip metricout command, the AR150&200&1200&2200&3200 adds an
additional metric to a route when advertising the route. The metric of the route, however,
does not change in the routing table. This command does not affect route selection on the
local device, but affects route selection on other devices.
NOTE
You can run one of the following commands to set the metric of the imported routes. The following
commands are listed in descending order of priority:
l Run the apply cost command to set the route cost.
l Run the import-route (RIP) command to set the cost for imported routes.
l Run the default-cost (RIP) command to set the cost for default routes.
Calculating the Cost of an IS-IS Route

On an IS-IS network, the default cost of an IS-IS interface is 10. The cost of an IS-IS route is
the sum of costs of all links between the source device and the destination device.
The link cost of an IS-IS interface can be calculated in the following modes in descending order
of priority:

Routers
l Run the isis cost command to set the link cost for a specified IS-IS interface.
l Run the circuit-cost command to set the link cost for all IS-IS interfaces.
l Run the auto-cost enable command to enable automatic calculation of the link cost of an
interface.
Before using the auto-cost enable command, run the bandwidth-reference command to
set the bandwidth reference value. By default, the bandwidth reference value is 100 Mbit/
s. The bandwidth reference value takes effect only when the cost type is wide or wide-
compatible. The cost of each interface is calculated as follows:
Cost of each interface = (Bandwidth reference value/Interface bandwidth) x 10
If the cost type is narrow, narrow-compatible, or compatible, the cost of each interface can
be obtained from Table 5-21.
Table 5-21 Relationship between the IS-IS interface cost and interface bandwidth
Cost Bandwidth Range
60 Interface bandwidth 10 Mbit/s
50 10 Mbit/s < interface bandwidth 100 Mbit/

s
40 100 Mbit/s < interface bandwidth 155Mbit/

s
30 155 Mbit/s < interface bandwidth 622 Mbit/

s
20 622 Mbit/s < Interface bandwidth 2.5 Gbit/

s
10 Interface bandwidth > 2.5 Gbit/s
NOTE
A Level-1 router in the Level-1 area must communicate with a router outside the Level-1 area through the
default route generated on the Level-1-2 router. Therefore, the cost of the route from the Level-1 router to
the router outside the Level-1 area is the cost of the route from the Level-1 router to the closest Level-1-2
router.
IS-IS can be configured to specify the cost for the imported route or retain the original cost of the imported
route.
Calculating the Cost of the OSPF Route

Similar to the cost of an IS-IS route, the cost of an OSPF route is the sum of costs of all links
along the route. By default, the link cost of an OSPF interface is 1.
You can run the ospf cost command to set the cost for a specified OSPF interface. If no interface
cost is configured, the system calculates the interface cost using the following formula:
l Cost of each interface = Bandwidth reference value/Interface bandwidth
The integer portion of the calculation result is taken as the cost of the interface. If the value is
smaller than 1, OSPF takes 1 as the interface cost. By default, the bandwidth reference value is

Routers
100 Mbit/s. You can change the cost of an OSPF interface by running the bandwidth-
reference command to change the bandwidth reference value.
NOTE
Packets between the stub router or total stub router and a router outside the AS are forwarded through the
default route generated on the ABR. Therefore, the cost of the route from the stub router or total stub router
to the router outside the AS is the cost of the route from the outside the stub router or total stub router to
the closest ABR. Similarly, the cost of the route from the NSSA router to a router in another area or AS is
the cost of the route from the NSSA router to the closest ABR or ASBR.
5.9.3 Why Cannot Interfaces of Different Types Generate Equal-

Cost Routes and Establish OSPF Load Balancing?
OSPF can automatically calculate the cost of an interface based on the interface bandwidth. The
calculation formula is: Interface cost = Bandwidth reference value/Interface bandwidth. The
bandwidth reference value is configurable. The default value is 100 Mbit/s. Routes generated
by OSPF have the same priority (10 by default). The interface cost, however, depends on the
interface type. Interfaces of different types have different costs; therefore, the interfaces cannot
generate equal-cost routes, leading to failure in establishing load balancing.
5.9.4 How Can I Set the cost Value When OSPF Imports External
Routes?
When OSPF imports external routes, the cost of original routes is not used. By default, the cost
of the external routes imported by OSPF is 1.
To change the default cost value of external routes imported by OSPF, run the default { cost
{ cost | inherit-metric } command. In the preceding command:
l cost: specifies the cost of the imported external routes. The value is an integer ranging from
0 to 16777214.
l inherit-metric: indicates that the cost of the imported external routes is the cost carried in
the route.
5.9.5 What Are the Rules for Selecting Routes Belonging to

Different OSPF Processes?
OSPF supports multi-processes. Multiple OSPF processes can run on the same router
independently.
Assume that a router is configured with two OSPF processes: process 1 and process 2. They are
independent of each other. Therefore, both of the routes belonging to process 1 and process 2
are advertised to the routing management (RM) module. Route selection between the two
processes complies with the following rules:
1. The RM module checks the protocol preference of process 1 and process 2. The route
belonging to the process with higher protocol preference is selected as the optimal route.
NOTE
To set the preference of an OSPF route in the specified process, run the preference [ ase ]
{ preference | route-policy route-policy-name } * command. The default preference of an OSPF
route is 10. When an ASE is specified, the default value is 150.

Routers
2. When the protocol preferences of the two processes are the same, the RM module compare
the cost of the two routes. The route with smaller cost value is selected as the optimal route.
NOTE
When selecting the optimal route, the RM module first compares the protocol preference. The RM
module compares the cost of routes only when the protocol preferences are the same.
5.9.6 Why the Number of Routes in the OSPF Routing Table of the
OSPF VPN Multi-instance Is Less than the Predicted Number?
In the OSPF VPN multi-instance, loops may occur if PEs and CEs learn BGP and OSPF routes
from each other. You can set the DN in Type3, Type5, or Type7 LSAs advertised by PEs to 1
so that CEs ignore the LSAs with the DN value of 1. These LSAs are not used in route calculation,
which prevents loops.
If the preceding method is used to prevent loops, the number of routes in the OSPF routing table
is less than the predicted number. To use the LSAs with DN 1 in route calculation, run the vpn-
instance-capability simple command on CEs to disable routing loop detection.
5.10 References
This section lists references of OSPF.
Document Description Remarks
RFC 1587 This document describes a new optional type of -

OSPF area, referred to humorously as a "not-so-
stubby" area (or NSSA). NSSAs are similar to the
existing OSPF stub area configuration option, but
have the additional capability to import AS
external routes on a limited basis.
RFC 1765 Proper operation of the OSPF protocol requires This RFC is
that all OSPF routers maintain an identical copy experimental and
of the OSPF link-state database. However, when non-standard.
the size of the link-state database becomes very
large, some routers might be unable to store the
entire database due to resource shortages. This
condition is called "database overflow".
RFC 2328 This memo documents version 2 of the OSPF -

protocol.
RFC 2370 This memo defines enhancements to the OSPF -

protocol to support a new class of link-state
advertisements (LSA) called Opaque LSAs.
Opaque LSAs provide a generalized mechanism
to allow for future extensibility of OSPF.

Routers
RFC 3137 This memo describes a backward-compatible This RFC is

technique that can be used by OSPF (Open informational and
Shortest Path First) implementations to advertise non-standard.
unavailability to forward transit traffic or to lower
the preference level for the paths through such a
router.
RFC 3623 This memo documents an enhancement to the -

OSPF routing protocol, whereby an OSPF device
can stay on the forwarding path even as its OSPF
software is restarted.
RFC 3630 This document describes extensions to the OSPF -

protocol version 2 to support intra-area Traffic
Engineering (TE), using Opaque Link State
Advertisements.
RFC 3682 This document describes the use of a packets Time This RFC is
to Live (TTL) (IPv4) or Hop Limit (IPv6) to experimental and
protect a protocol stack from CPU-utilization non-standard.
based attacks, which has been proposed in many
settings.
RFC 3906 This document describes how conventional hop- -

by-hop link-state routing protocols interact with
new Traffic Engineering capabilities to create
Interior Gateway Protocol (IGP) shortcuts.
RFC 4576 This document specifies the necessary procedure, -

using one of the options bits in the LSA (Link State
Advertisements) to indicate that an LSA has
already been forwarded by a PE and should be
ignored by any other PEs that see it.
RFC 4577 This document extends that specification by -

allowing the routing protocol on the PE/CE
interface to be Open Shortest Path First (OSPF)
protocol.
RFC 4750 This memo defines a portion of the Management -

Information Base (MIB) for use with network
management protocols in TCP/IP-based Internet
networks. In particular, it defines objects to
manage version 2 of the Open Shortest Path First
Routing Protocol. Version 2 of the OSPF protocol
is specific to the IPv4 address family.

Routers
Configuration Guide - IP Routing 6 OSPFv3 Configuration
6 OSPFv3 Configuration
About This Chapter
By building Open Shortest Path First Version 3 (OSPFv3) networks, you can enable OSPFv3
to discover and calculate routes in ASs. OSPFv3 is applicable to a large-scale network that
consists of hundreds of routers.
6.1 Introduction to OSPFv3

This section describes the definition and functions of OSPFv3.
6.2 Principle
This section describes the implementation of OSPFv3.

After basic OSPFv3 functions are configured, you can build a basic OSPFv3 network. If other
OSPFv3 functions are required, configure them according to reference sections.

This section describes the default configuration of OSPFv3, which can be changed according to
6.5 Configuring OSPFv3

This section describes how to configure OSPFv3.
6.6 Maintaining OSPFv3

Maintaining OSPFv3 involve resetting OSPFv3.

This section provides several configuration examples of OSPFv3 together with the configuration
roadmap.
6.8 References
This section lists references of OSPFv3.

Routers
6.1 Introduction to OSPFv3

This section describes the definition and functions of OSPFv3.
Definition
The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force
(IETF), is an interior gateway protocol based on the link status.
At present, OSPF Version 2 is used for IPv4 and OSPF Version 3 is used for IPv6.
l OSPFv3 is short for OSPF Version 3.

l As defined in RFC 2740, OSPFv3 is a routing protocol over IPv6.
l OSPFv3 is an independent routing protocol whose functions are modified on the basis of
OSPFv2.
Purpose
The primary purpose of OSPFv3 is to develop a routing protocol independent of any specific
network layer. The internal routing information of OSPFv3 is redesigned to serve this purpose.
The differences between OSPFv3 and OSPFv2 are as follows:
l OSPFv3 does not insert IP-based data in the header of the packet and Link State
Advertisement (LSA).
l OSPFv3 executes some crucial tasks that originally require the data in the IP packet header
by making use of the information independent of any network protocol. For example,
OSPFv3 can identify the LSA that advertises the routing data.
6.2 Principle
This section describes the implementation of OSPFv3.
6.2.1 Principle of OSPFv3
Running on IPv6, OSPFv3 (defined in RFC 2740) is an independent routing protocol whose
functions are enhanced on the basis of OSPFv2.
l OSPFv3 and OSPFv2 are the same in respect of the working principles of the Hello
message, state machine, link-state database (LSDB), flooding, and route calculation.
l OSPFv3 divides an Autonomous System (AS) into one or more logical areas and advertises
routes through LSAs.
l OSPFv3 achieves unity of routing information by exchanging OSPFv3 packets between
routers within an OSPFv3 area.
l OSPFv3 packets are encapsulated into IPv6 packets, which can be transmitted in unicast
or multicast mode.

Routers
Formats of OSPFv3 Packets

Packet Type Description
Hello packet Hello packets are sent regularly to discover and maintain
OSPFv3 neighbor relationships.
Database Description (DD) A DD packet contains the summary of the local LSDB.
packet It is exchanged between two OSPFv3 routers to update
the LSDBs.
Link State Request (LSR) packet LSR packets are sent to the neighbor to request the
required LSAs.
An OSPFv3 router sends LSR packets to its neighbor
only after they exchange DD packets.
Link State Update (LSU) packet The LSU packet is used to transmit required LSAs to the
neighbor.
Link State Acknowledgment The LSAck packet is used to acknowledge the received
(LSAck) packet LSA packets.
LSA Type
LSA Type Description
Router-LSA (Type1) Generated by a router for each area to which an OSPFv3

interface belongs, the router LSA describes the status and
costs of links of the router and is advertised in the area where
the OSPFv3 interface belongs.
Network-LSA (Type2) Generated by a designated router (DR), the network LSA

describes the link status and is broadcast in the area that the
DR belongs to.
Inter-Area-Prefix-LSA Generated on the area border router (ABR), an inter-area

(Type3) prefix LSA describes the route of a certain network segment
within the local area and is used to inform other areas of the
route.
Inter-Area-Router-LSA Generated on the ABR, an inter-area router LSA describes

(Type4) the route to the autonomous system boundary router (ASBR)
and is advertised to all related areas except the area that the
ASBR belongs to.
AS-external-LSA (Type5) Generated on the ASBR, the AS-external LSA describes the
route to a destination outside the AS and is advertised to all
areas except the stub area and NSSA area.
NSSA-LSA (Type7) Describes routes to a destination outside the AS. It is

generated by an ASBR and advertised in NSSAs only.

Routers
LSA Type Description
Link-LSA (Type8) Each router generates a link LSA for each link. A link LSA
describes the link-local address and IPv6 address prefix
associated with the link and the link option set in the network
LSA. It is transmitted only on the link.
Intra-Area-Prefix-LSA Each router or DR generates one or more intra-area prefix

(Type9) LSAs and transmits it in the local area.
l An LSA generated on a router describes the IPv6 address
prefix associated with the router LSA.
l An LSA generated on a DR describes the IPv6 address
prefix associated with the network LSA.
Router Type
Figure 6-1 Router type
IS-IS ASBR
Area1 Area4
Internal Router Backbone Router
Area0
Area2 ABR Area3
Table 6-1 Router types and descriptions
Internal router All interfaces on an internal router belong to the same

OSPFv3 area.
Area border router (ABR) An ABR can belong to two or more areas, but one of the areas
must be a backbone area.
An ABR is used to connect the backbone area and the non-
backbone areas. It can be physically or logically connected
to the backbone area.

Routers
Backbone router At least one interface on a backbone router belongs to the

backbone area.
All ABRs and internal routers in Area 0, therefore, are
backbone routers.
AS boundary router (ASBR) A router that exchanges routing information with other ASs
is called an ASBR.
An ASBR may not locate on the boundary of an AS. It can
be an internal router or an ABR.
OSPFv3 Route Type

Inter-area routes and intra-area routes describe the network structure of an AS. External routes
describe how to select a route to the destination outside an AS. OSPFv3 classifies the imported
AS external routes into Type 1 routes and Type 2 routes.
Table 6-2 lists route types in a descending order of priority.
Table 6-2 Types of OSPFv3 routes
Route Type Description
Intra-area route Indicates routes within an area.
Inter-area route Indicates routes between areas.
Type1 external routes Because of the high reliability of Type 1 external routes, the
calculated cost of external routes is equal to that of AS
internal routes, and can be compared with the cost of OSPFv3
routes.
That is, the cost of a Type1 external route equals the cost of
the route from the router to the corresponding ASBR plus the
cost of the route from the ASBR to the destination address.
Type2 external routes Because of the low reliability of Type2 external routes, the
cost of the route from the ASBR to a destination outside the
AS is considered far greater than the cost of any internal path
to an ASBR.
Therefore, OSPFv3 only takes the cost of the route from the
ASBR to a destination outside the AS into account when
calculating route costs. That is, the cost of a Type2 external
route equals the cost of the route from the ASBR to the
destination of the route.

Routers
Area Type
Table 6-3 Types of OSPFv3 areas
Area Type Description
Totally stub area A totally stub area allows the Type3 default routes advertised by the
ABR, and disallows the routes outside the AS and inter-area routes.
Stub area A stub area allows inter-area routes, which is different from a totally
stub area.
NSSA Imports routes outside an AS, which is different from a stub area. An
ASBR advertises Type7 LSAs in the local area. These Type 7 LSAs
are translated into Type 5 LSAs on an ABR, and are then flooded in
the entire OSPFv3 AS.
Network Types Supported by OSPFv3

OSPFv3 classifies networks into the following types according to link layer protocols.
Table 6-4 Types of OSPFv3 networks
Broadcast If the link layer protocol is Ethernet or FDDI, OSPFv3 defaults the
network type to broadcast.
In this type of networks, the following situations occur:
l Hello messages, LSU packets, and LSAck packets are
transmitted in multicast mode (FF02::5 is the reserved IPv6
multicast address of the OSPFv3 router; FF02::6 is the reserved
IPv6 multicast address of the OSPFv3 DR or BDR).
l DD packets and LSR packets are transmitted in unicast mode.
Non-broadcast Multiple If the link layer protocol is frame relay, ATM, or X.25, OSPFv3
Access (NBMA) defaults the network type to NBMA.
In this type of networks, protocol packets such as Hello messages,
DD packets, LSR packets, LSU packets, and LSAck packets, are
transmitted in unicast mode.

Routers
Point-to-Multipoint Regardless of the link layer protocol, OSPFv3 does not default the
(P2MP) network type to P2MP. A P2MP network must be forcibly changed
from other network types. The common practice is to change a
non-fully connected NBMA to a P2MP network.
In this type of networks, the following situations occur:
l Hello messages are transmitted in multicast mode with the
multicast address as FF02::5.
l Other protocol packets, including DD packets, LSR packets,
LSU packets, and LSAck packets, are transmitted in unicast
mode.
Point-to-point (P2P) If the link layer protocol is PPP, HDLC, or LAPB, OSPFv3
defaults the network type to P2P.
In this type of network, the protocol packets, including Hello
messages, DD packets, LSR packets, LSU packets, and LSAck
packets, are transmitted to the multicast address FF02::5.
Stub Area
A stub area is a special area where the ABRs do not flood the received external routes. In stub
areas, the size of the routing table of the routers and the routing information in transmission are
reduced.
Configuring a stub area is optional. Not all areas can be configured as stub areas. Usually, a stub
area is a non-backbone area with only one ABR and is located at the AS boundary.
To ensure the reachability of a destination outside the AS, the ABR in the stub area generates a
default route and advertises it to the non-ABR routers in the stub area.
Note the following when configuring a stub area:
l The backbone area cannot be configured as a stub area.
l If an area needs to be configured as a stub area, all the routers in this area must be configured
with the stub command.
l An ASBR cannot exist in a stub area. That is, external routes are not flooded in the stub
area.
l A virtual link cannot pass through the stub area.
OSPFv3 Route Summarization

Routing information can be decreased after route aggregation so that the size of routing tables
is reduced, which improves the performance of routers.
The procedure for OSPFv3 route aggregation is as follows:
l Route summarization on an ABR
An ABR can summarize routes with the same prefix into one route and advertise the
summarized route in other areas.

Routers
When sending routing information to other areas, an ABR generates Type 3 LSAs based
on IPv6 prefixes. If consecutive IPv6 prefixes exist in an area and route summarization is
enabled on the ABR of the area, the IPv6 prefixes can be summarized into one prefix. If
there are multiple LSAs that have the same prefix, the ABR summarizes these LSAs and
advertises only one summarized LSA. The ABR does not advertise any specific LSAs.
l Route summarization on an ASBR
An ASBR can summarize imported routes with the same prefix into one route and then
advertise the summarized route to other areas.
After being enabled with route summarization, an ASBR summarizes imported Type 5
LSAs within the summarized address range. After route summarization, the ASBR does
not generate a separate Type 5 LSA for each specific prefix within the configured range.
Instead, the ASBR generates a Type 5 LSA for only the summarized prefix. In an NSSA,
an ASBR summarizes multiple imported Type 7 LSAs within the summarized address
range into one Type 7 LSA.
OSPFv3 Virtual Link

A virtual link refers to a logical channel established between two ABRs through a non-backbone
area.
l A virtual link must be set up on both ends of the link; otherwise, it does not take effect.
l The transmit area refers to the area that provides an internal route of a non-backbone area
for both the ends of the virtual link.
In actual applications, the physical connectivity between non-backbone areas and the backbone
area cannot be ensured owing to various limitations. To solve this problem, you can configure
OSPFv3 virtual links.
The virtual link is similar to a point-to-point connection between two ABRs. Similar to physical
interfaces, the interfaces on the virtual link can be configured with parameters such as the hello
interval.
Figure 6-2 OSPFv3 virtual link
Area0 Area2
Virtual Link
ABR Area1 ABR
Transit Area
As shown in Figure 6-2, OSPFv3 packets transmitted between two ABRs are only forwarded
by the OSPFv3 devices that reside between the two ABRs. The OSPFv3 devices detect that they
are not the destinations of the packets, so they forward the packets as common IP packets.

Routers
OSPFv3 Multi-process
OSPFv3 supports multi-process. More than one OSPFv3 process can run on the same router
because processes are independent of each other. Route interaction between different OSPFv3
processes is similar to the route interaction between different routing protocols.
An interface of a router belongs to only a certain OSPFv3 process.
6.2.2 OSPFv3 GR
Graceful restart (GR) is a technology used to ensure normal traffic forwarding when a routing
protocol restarts and guarantee that key services are not affected in the process.
GR is one of the high availability (HA) technologies, which comprise a series of comprehensive
technologies such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic
engineering. As a redundancy technology, GR is widely used to ensure uninterrupted forwarding
of key data in active/standby switchover and system upgrade.
If GR is not enabled, the active/standby switchover occurring owing to various causes leads to
transient interruption of data forwarding, and as a result, route flapping occurs on the whole
network. Such route flapping and service interruption are unacceptable on a large-scale network,
especially on a carrier network.
In GR mode, the forwarding plane continues to direct data forwarding once a restart occurs, and
the actions on the control plane, such as reestablishment of neighbor relationships and route
calculation, do not affect the forwarding plane. In this manner, service interruption caused by
route flapping is prevented so that the network reliability is improved.
Basic Concepts
l Grace-LSA
OSPFv3 supports GR by flooding Grace-LSAs on the link.
Grace-LSAs are used to inform the neighbor of the GR time, cause, and interface
instance ID when GR starts and ends.
l Router function
A router can function as a GR restarter.
A router can function as a GR helper.
l GR implementation
Planned-GR: This refers to the smooth restart of OSPFv3 through the reset ospfv3
graceful-restart command. In this mode, a Grace-LSA is sent to the neighbor before
the restart.
Unplanned-GR: This refers to the active/standby switchover triggered by router faults
like power down, dead loop, exception or reset in master.
Unlike planned-GR, no Grace-LSA is sent before the active/standby switchover in
unplanned GR mode. Instead, the switchover is directly performed. When the standby
board becomes Up, a Grace-LSA is sent and the GR process starts. The following
procedure is the same as that of planned GR.

Routers
GR Process
Figure 6-3 OSPFv3 planned-GR process (reset ospfv3 graceful-restart)

RouterA RouterB
Restarter Helper
Restart the OSPFv3 Grace-LSA

process in GR mode Enter the Helper
and enter the GR state LSAck state
Send Hello packets, negotiate with

neighbors by exchanging DD packets,
and synchronize LSDBs
Synchronize LSDBs with
Full the Restarter
Exit from the GR state, Flush Grace-LSA
recalculate routes, and Exit from the Helper state
generate LSAs and generate Router-LSAs
Figure 6-4 OSPFv3 unplanned-GR process (active/standby switchover)

RouterA RouterB
Restarter Helper
Master/slave Grace-LSA
Enter the Helper state
switchover is complete
LSAck
Responds to LSAs
with LSAcks
Send Hello packets, negotiate with
neighbors by exchanging DD packets,
and synchronize LSDBs
Synchronize LSDBs
Full
with the Restarter
Exit from the GR state,
recalculate routes, and Flush Grace-LSA
Exit from the Helper
generate LSAs state and generate
Router-LSAs
l On the GR restarter:
1. In planned-GR mode, the GR restarter sends a Grace-LSA to all neighbors to inform them
of the start of a GR process and the period and cause of this process.

Routers
In unplanned GR mode, a Grace-LSA is sent to each neighbor immediately after the standby
board is Up to inform the neighbors of the start of a GR process and the period and cause
of the process.
2. The GR restarter performs negotiation with neighbors again to set up new neighbor
relationships.
3. When all the neighbor relationships between the GR restarter and the original neighbors
enter the Full state:
l The GR restarter exits from the GR process and OSPFv3 recalculates routes.
l The GR restarter updates the routing table on the main control board and the FIBs on
interface boards and deletes invalid routing entries.
l The GR restarter sends a Grace-LSA whose aging time is 3600 seconds to instruct the
GR helper to exit from the GR process.
Now, the GR process is complete.
4. If errors occur during a GR process, the GR timer expires, or the neighbor relationship fails
to enter the Full state during a GR process, the GR restarter exits from the process and
OSPFv3 is restarted in non-GR mode. In this case, packets are lost.
l On the GR helper:
1. If a router is configured to support the GR process on its neighbor, the router enters the
helper mode after receiving a Grace-LSA.
2. The GR helper maintains its neighbor relationship with the GR restarter, and the status of
the neighbor relationship does not change.
3. If the GR helper continues to receive Grace-LSAs whose GR period is different from that
on the GR helper, the GR helper updates its GR period.
4. Being informed of the successful GR process through a Grace-LSA whose aging time is
3600 seconds from the GR restarter, the GR helper exits from the GR process.
5. If errors occur during a GR process, the GR helper exits from the helper state and deletes
invalid routes after route calculation.
Comparison between the GR Mode and the Non-GR Mode
Table 6-5 Comparison between the OSPFv3 GR mode and the OSPFv3 non-GR mode
Active/Standby Switchover in Non- Active/Standby Switchover in GR Mode

GR Mode
l OSPFv3 neighbor relationships are l OSPFv3 neighbor relationships are

reestablished. reestablished.
l Routes are recalculated. l Routes are recalculated.
l The forwarding table changes. l The forwarding table remains the same.
l Route changes are sensed on the l Except the neighbor of the device where the
network and route flapping occurs over active/standby switchover occurs, other
a short period of time. routers do not sense the route changes.
l Packets are lost during forwarding, and l No packets are lost during forwarding, and
services are interrupted. services are not affected.

Routers
6.2.3 Association between OSPFv3 and BGP

When a new router is deployed in the network or a router is restarted, the network traffic may
be lost during BGP convergence. This is because IGP convergence is quicker than BGP
convergence. This problem can be solved through the association between OSPFv3 and BGP.
If a router on a BGP network recovers from a fault, BGP convergence is performed again and
certain packets may be lost during the convergence.
As shown in Figure 6-5, traffic from RouteA to RouterD passes through RouterC, and traverses
a BGP network.
Figure 6-5 Traffic traversing a BGP network

RouterB
Router Nexthop
BGP 1::1 RouterD
OSPFv3 RouterD RouterC
RouterD
BGP Routes
RouterA 1::1/128
OSPFv3
RouterC
If a fault occurs on RouterC, traffic is redirected to RouterB after rerouting. Packets are lost
when RouterC is restored to the normal status.
Because OSPFv3 convergence is quicker than BGP convergence, OSPFv3 convergence is

complete when RouterC recovers. The next hop of the route from RouterA to RouterD is
RouterC, which, however, does not know the route to RouterD since BGP convergence on
RouterC is not complete.
Thus, when the packets destined for RouterD are transmitted from RouterA to RouterC, they
are discarded by RouterC because RouterC has no route to RouterD, as shown in Figure 6-6.

Routers
Figure 6-6 Packet loss during the restart of the device not enabled with association between
OSPFv3 and BGP
RouterB
Router Nexthop
BGP 1::1 RouterD
OSPFv3 RouterD RouterC
BGP Routes
RouterA 1::1/128
OSPFv3 RouterD
RouterC
Process of Association between OSPFv3 and BGP

When a router enabled with association between OSPFv3 and BGP restarts, the router advertises
a message in the local OSPFv3 area to instruct other routers not to use it as a transit router.
At the same time, the router sets the largest weight value of 65535 in its LSAs to ensure that it
is not used by other routers as the transit router. The BGP route, however, can still reach the
router.
6.2.4 Comparison between OSPFv3 and OSPFv2

OSPFv3 and OSPFv2 are the same in the following aspects:
l Network type and interface type

l Interface state machine and neighbor state machine
l LSDB
l Flooding mechanism
l Five types of packets, including Hello, DD, LSR, LSU, and LSAck packets
l Route calculation
OSPFv3 and OSPFv2 are different in the following aspects:
l OSPFv3 is based on links rather than network segments.

OSPFv3 runs on IPv6, which is based on links rather than network segments.
Therefore, you need not to configure OSPFv3 on the interfaces in the same network
segment. It is only required that the interfaces enabled with OSPFv3 are on the same link.
In addition, the interfaces can set up OSPFv3 sessions without IPv6 global addresses.
l OSPFv3 does not depend on IP addresses.
This is to separate topology calculation from IP addresses. That is, OSPFv3 can calculate
the OSPFv3 topology without knowing the IPv6 global address, which only applies to
virtual link interfaces for packet forwarding.

Routers
l OSPFv3 packets and LSA format change.

OSPFv3 packets do not contain IP addresses.
OSPFv3 router LSAs and network LSAs do not contain IP addresses, which are
advertised by Link LSAs and Intra Area Prefix LSAs.
In OSPFv3, Router IDs, area IDs, and LSA link state IDs no longer indicate IP addresses,
but the IPv4 address format is still reserved.
Neighbors are identified by Router IDs instead of IP addresses in broadcast, NBMA,
or P2MP networks.
l Information about the flooding scope is added in LSAs of OSPFv3.
Information about the flooding scope is added in the LSA Type field of LSAs of OSPFv3.
Thus, OSPFv3 routers can process LSAs of unidentified types, which makes the processing
more flexible.
OSPFv3 can store or flood unidentified packets, whereas OSPFv2 just discards
unidentified packets.
OSPFv3 floods packets in an OSPF area or on a link. It sets the U flag bit of packets
(the flooding area is based on the link local) so that unidentified packets are stored or
forwarded to the stub area.
For example, RouterA and RouterB can identify LSAs of a certain type. They are connected
through RouterC, which, however, cannot identify this type of LSAs. When RouterA floods
an LSA of this type, RouterC can still flood the received LSA to RouterB although it does
not identify this LSA. RouterB then processes the LSA.
If OSPFv2 is run, RouterC discards the unidentified LSA so that the LSA cannot reach
RouterB.
l OSPFv3 supports multi-process on a link.
Only one OSPFv2 process can be configured on a physical interface.
In OSPFv3, one physical interface can be configured with multiple processes that are
identified by different instance IDs. That is, multiple OSPFv3 instances can run on one
physical link. They establish neighbor relationships with the other end of the link and
transmit packets to the other end without interfering with each other.
Thus, the resources of a link can be shared among OSPFv3 instances that simulate multiple
OSPFv3 routers, which improves the utilization of limited router resources.
l OSPFv3 uses IPv6 link-local addresses.
IPv6 implements neighbor discovery and automatic configuration based on link-local
addresses. Routers running IPv6 do not forward IPv6 packets whose destination address is
a link-local address. Those packets can only be exchanged on the same link. The unicast
link-local address starts from FE80/10.
As a routing protocol running on IPv6, OSPFv3 also uses link-local addresses to maintain
neighbor relationships and update LSDBs. Except Vlink interfaces, all OSPFv3 interfaces
use link-local addresses as the source address and that of the next hop to transmit OSPFv3
packets.
The advantages are as follows:
The OSPFv3 can calculate the topology without knowing the global IPv6 addresses so
that topology calculation is not based on IP addresses.
The packets flooded on a link are not transmitted to other links, which prevents
unnecessary flooding and saves bandwidth.

Routers
l OSPFv3 packets do not contain authentication fields.

OSPFv3 directly adopts IPv6 authentication and security measures. Thus, OSPFv3 does
not need to perform authentication. It only focuses on the processing of packets.
l OSPFv3 supports two new LSAs.
Link LSA: A router floods a link LSA on the link where it resides to advertise its link-
local address and the configured global IPv6 address.
Intra Area Prefix LSA: A router advertises an intra-area prefix LSA in the local OSPF
area to inform the other routers in the area or the network, which can be a broadcast
network or a NBMA network, of its IPv6 global address.
l OSPFv3 identifies neighbors based on router IDs only.
On broadcast, NBMA, and P2MP networks, OSPFv2 identifies neighbors based on IPv4
addresses of interfaces.
OSPFv3 identifies neighbors based on router IDs only. Thus, even if global IPv6 addresses
are not configured or they are configured in different network segments, OSPFv3 can still
establish and maintain neighbor relationships so that topology calculation is not based on
IP addresses.

After basic OSPFv3 functions are configured, you can build a basic OSPFv3 network. If other
OSPFv3 functions are required, configure them according to reference sections.
Table 6-6 describes the OSPFv3 configuration tasks.

Routers
Table 6-6 OSPFv3 configuration tasks
Constructing a basic OSPFv3 Before configuring OSPFv3, l 6.5.1 Configuring Basic

network you must enable the OSPFv3 OSPFv3 Functions
process and specify the router l 6.5.2 Establishing or
ID. Other OSPFv3 functions Maintaining OSPFv3
then can be configured or Neighbor Relationship
take effect.
In practical applications,
establishing or maintaining
OSPFv3 neighbor
relationships is an important
precondition for the
construction of OSPFv3
networks. By implementing
the configuration tasks in this
section, you can:
l Change the OSPFv3
packet timer to adjust the
OSPFv3 network
convergence rate and
network load brought by
protocol packets.
l Configure the limit for
OSPFv3 retransmission
times. When
retransmitting packets,
OSPFv3 disconnects
from its neighbor if the
retransmission times
exceed the limit. This
prevents neighbors from
dead loops caused by
consecutive
retransmission when the
neighbor does not receive
the packet.
l Increase the OSPFv3
network convergence rate
by adjusting the LSA
updating and receiving
intervals.

Routers
Configuring OSPFv3 special After the basic OSPFv3 l 6.5.3 Configuring

area attributes network is constructed, OSPFv3 Areas
OSPFv3 special area l 6.5.4 Configuring
attributes can be flexibly OSPFv3 NSSA Areas
used to deploy the OSPFv3
network according to actual
needs.
l OSPF stub area: A stub
area is a special area
where ABRs do not
advertise the received
external routes. In a stub
area, the device routing
table size and routing
information in
transmission are greatly
reduced. To ensure the
reachability of a
destination outside the
AS, the ABR in the stub
area generates a default
route and advertises it to
the non-ABR routers in
the stub area.
l OSPF NSSA area: An
NSSA is also a special
area that resembles a stub
area in many ways. The
difference between the
two areas is that the
NSSA area can introduce
and advertise routes
outside the AS to the
entire OSPF AS, without
learning external routes
sent from other areas on
the OSPF network.
l OSPF virtual link: All the
non-backbone areas need
to be connected to the
backbone area in the
OSPF deployment.
Otherwise, some areas
will be unreachable.
However, in actual
applications, physical
connectivity between the
non-backbone area and

Routers
backbone area cannot be

ensured because of
various limitations. In this
case, OSPF virtual links
can be configured
between the ABRs in the
new non-backbone area
and those in the backbone
area.
Configuring OSPFv3 route In practical applications, to 6.5.5 Configuring OSPFv3

attributes meet the requirements of Route Attributes
complex network
environment, configure the
OSPFv3 route attributes to
change the OSPFv3 route
selection policies.
Controlling OSPFv3 routing In practical applications, to 6.5.6 Controlling OSPFv3

information meet the network Routing Information
requirements, configure
filtering of received and
advertised routes and route
aggregation, and control the
number of external routes
from the LSDB to implement
accurate control of OSPFv3
routing information.
Adjusting and optimizing Change the OSPFv3 packet 6.5.7 Optimizing an

OSPFv3 networks timer to adjust the OSPFv3 OSPFv3 Network
network convergence rate
and network load brought by
protocol packets. On some
low-rate links, the delay of
LSA transmission by
interfaces must be
considered. Adjust the SPF
calculation interval to restrict
resource consumption caused
by frequent network changes.

Routers
Configuring OSPFv3 GR To prevent route flapping and 6.5.8 Configuration

interruption of traffic OSPFv3 GR
forwarding caused by
OSPFv3 restart, enable the
OSPFv3 GR features.
After OSPFv3 is restarted,
the GR Restarter and the GR
Helper re-establish the
neighbor relationship,
exchange routing
information, synchronize the
database, and update the
routing table and forwarding
table. This implements
OSPFv3 fast convergence.
Configuring the OSPFv3 OSPFv3 supports the 6.5.9 Configuring the

network management network management Network Management
function function. You can bind Function of OSPFv3
OSPFv3 MIB to a process. In
addition, OSPFv3 also
supports fault and log
functions.

This section describes the default configuration of OSPFv3, which can be changed according to
Table 6-7 describes the default configuration of OSPFv3.
Table 6-7 Default configuration of OSPFv3
OSPFv3 Disabled
The interval of sending Hello For the interface of the P2P and broadcast type, the
packets interval for sending Hello packets is 10 seconds. For the
interface of the P2MP and NBMA type, the interval for
sending Hello packets is 30 seconds.
The dead interval of the OSPFv3 The dead interval of OSPFv3 neighbor is 40 seconds for
neighbor the interface of P2P or broadcast type. The dead interval
of OSPFv3 neighbor is 120 seconds for the interface of
P2MP or NBMA type.

Routers
The period during which a 500 seconds

router keeps acting as a stub
router.
The bandwidth reference value 100 Mbit/s

used to calculate the link cost.
6.5 Configuring OSPFv3

This section describes how to configure OSPFv3.
6.5.1 Configuring Basic OSPFv3 Functions

Before building OSPFv3 networks, you need to configure basic OSPFv3 functions.
You must enable OSPFv3 and specify the interface ,area ID and router ID before configuring
other functions.
Before configuring basic OSPFv3 functions, complete the following tasks:
l Enabling IPv6 capabilities

l Making the network layers of the adjacent nodes accessible
6.5.1.1 Enabling OSPFv3
Context
OSPFv3 supports multiple processes. Multiple OSPFv3 processes running on one router are
differentiated by process IDs. OSPFv3 process ID is set when OSPFv3 is enabled and is only
locally valid. It does not affect the packet exchange with other routers.
In the format of an IPv4 address, a router ID is a 32-bit unsigned integer that uniquely identifies
a router within an AS. The router ID of OSPFv3 must be manually set. If no router ID is set,
OSPFv3 fails to run normally.
When manually setting the router ID, ensure that the router IDs of any two routers in an AS are
different. When multiple processes are enabled on a router, it is necessary to specify a unique
route ID for each process.
To ensure the stable running of OSPFv3, you need to allocate router IDs and set them in network
planning.
Do as follows on the router that runs OSPFv3.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 [ process-id ] [ vpn-instance vpn-instance-name ]
OSPFv3 is enabled and the OSPFv3 view is displayed.
Step 3 Run:
router-id router-id
A Router ID is set.
----End
6.5.1.2 Enabling OSPFv3 on an Interface
Context
After enabling OSPFv3 in the system view, you need to enable OSPFv3 on the interface.
Because an interface has multiple instances, you need to specify which instance of the interface
is enabled in the OSPFv3 process when OSPFv3 is enabled on the interface. If no instance ID
is specified, the value defaults to 0. The same instance must be enabled on the interfaces between
which the neighbor relationship is set up.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 process-id area area-id [ instance instance-id ]
OSPFv3 is enabled on the interface.
The area ID can be a decimal integer or in the IPv4 address format, but it is displayed in the IPv4
address format.
Step 4 (Optional) Run the ospfv3 network-type { broadcast | nbma | p2mp [ non-broadcast ] |
p2p } [ instance instance-id ] command to configure the network type of an interface.

Routers
NOTE
When an interface supports multi-instances, you must specify the value of instance-id when enabling OSPFv3
on the interface. If the value of instance-id is not specified, the default value 0 is adopted. In this case, the
configured network type of an interface mismatches the actual network type of the interface. This step is
mandatory in such a case.
----End
6.5.1.3 Entering the OSPFv3 Area View
Context
You must configure the routers in the same area based on the area. Otherwise, the neighbor
routers cannot exchange information with each other. The congestion of routing information or
routing loop is thus caused.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 [ process-id ]
The OSPFv3 view is displayed.
Step 3 Run:
area area-id
The OSPFv3 area view is displayed.
The area ID can be a decimal integer or in the IPv4 address format, but it is displayed in the IPv4
address format.
An OSPFv3 area cannot be deleted directly. Only after all the configurations in the area view
are removed, this area is automatically removed.
----End
Prerequisites
The configurations for the Basic OSPFv3 Functions are complete.
Procedure
l Run the display ospfv3 [ process-id ] command to check the summary information about
the OSPFv3 process.

Routers
l Run the display ospfv3 [ process-id ] interface [ area area-id ] [ interface-type interface-
number ] command to check the OSPFv3 interface information.
l Run the commands as follow to check the LSDB information about OSPFv3:
display ospfv3 [ process-id ] lsdb [ area area-id ] [ originate-router advertising-
router-id | self-originate ] [ { router | network | inter-router [ asbr-router asbr-
router-id ] | { inter-prefix | nssa } [ ipv6-address prefix-length ] | link | intra-prefix |
grace } [ link-state-id ] ]
display ospfv3 [ process-id ] lsdb [ originate-router advertising-router-id | self-
originate ] external [ ipv6-address prefix-length ] [ link-state-id ]
l Run the display ospfv3 [ process-id ] [ area area-id ] peer [ interface-type interface-
number ] [ verbose ] command or display ospfv3 [ process-id ] [ area area-id ] peer
neighbor-id [ verbose ] command to check the information about the OSPFv3 neighbor.
l Run the display ospfv3 [ process-id ] routing [ abr-routes | asbr-routes | statistics | ipv6-
address prefix-length | intra-routes | inter-routes | ase-routes | nssa-routes ] command
as follow to check the OSPFv3 routing table:
l Run the display ospfv3 [ process-id ] path command to check the paths to a destination
address.
l Run the display default-parameter ospfv3 command to check the default OSPFv3
configuration.
----End
6.5.2 Establishing or Maintaining OSPFv3 Neighbor Relationship

By establishing and maintaining OSPFv3 neighbor relationships or adjacencies, you can build
OSPFv3 networks.
In applications, establishing or maintaining the OSPFv3 neighbor relationship is a premise for
the construction of an OSPFv3 network. After the configuration in this section, you can:
l Adjust the convergence speed of the OSPFv3 network and network load posed by protocol
packets by modifying OSPFv3 timers.
l Enable OSPFv3 to be disconnected from its neighbor when the number of OSPFv3 packet
retransmissions exceeds the threshold by configuring Retransmission Limitation for
OSPFv3. This prevents non-stop packet retransmissions if the neighbor does not receive
packets.
l Speed up the convergence of an OSPFv3 network by adjusting the intervals for updating
and receiving LSAs.
Before establishing or maintaining the OSPFv3 neighbor relationship, complete the following
tasks:
l 6.5.1 Configuring Basic OSPFv3 Functions
6.5.2.1 Configuring the Interval for Sending Hello Packets

Routers
Context
Hello packets are periodically sent to the neighbor router to detect and maintain the neighbor
relationship and to elect the DR and the BDR. RFC 2328 requires that the Hello timer values of
neighbors be consistent. The value of the Hello timer is inversely proportional to the route
convergence speed and network load.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ospfv3 timer hello interval [ instance instance-id ]
The interval for sending Hello packets is set on the interface.
----End
6.5.2.2 Configuring Dead Time of Neighbor Relationship
Context
If a router does not receive any Hello packet from its neighbor during a specified period, the
neighbor router is considered invalid. The specified period is called the dead time of the neighbor
relationship. The dead time must be at least four times the Hello interval on an interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ospfv3 timer dead interval [ instance instance-id ]
The dead time of the neighbor relationship is specified.
----End

Routers
6.5.2.3 Configuring the Interval for Retransmitting LSAs to Neighboring routers
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 timer retransmit interval [ instance instance-id ]
The interval for retransmitting LSAs to the adjacent routers is set.
The value of seconds must be greater than a round trip of one packet transmitted between two
routers.
NOTE
Do not set a value which is too small, for the interval between LSA retransmissions. Otherwise, unnecessary
retransmissions may occur.
----End
6.5.2.4 Configuring the Delay for Transmitting LSAs on the Interface
Context
The LSA ages out in the LSDB of a local router instead of in the transmission process. You need
to set the delay for an LSA before sending it. For a low-speed network, this configuration is
necessary.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
Step 3 Run:
ospfv3 trans-delay interval [ instance instance-id ]
The delay in transmitting LSAs on the interface is set.
----End
Prerequisites
The configurations for the Establishing or Maintaining OSPFv3 Neighbor Relationship are
complete.
Procedure
----End
6.5.3 Configuring OSPFv3 Areas

OSPFv3 supports stub areas and virtual links, the principle and applicable environment of which
are similar to those in OSPFv2.
To reduce the number of LSAs in the network and enhance OSPFv3 extensibility, define OSPFv3
areas. For some non-backbone areas at the edge of ASs, you can define them as stub areas for
further reducing the size of the routing table and the number of LSAs.
Before configuring OSPFv3 area attributes, complete the following tasks:
6.5.3.1 Configuring OSPFv3 Stub Areas
Context
Do as follows on each router that runs OSPFv3 in the stub area:
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
Step 3 Run:
area area-id
Step 4 Run:
stub [ no-summary ]
The area is configured as a stub area.

default-cost cost
The cost of the default route sent to the stub area is set.
By default, the cost of the default route sent to the stub area is 1.
This command is configured on the ABR of the stub area only to set the cost of the default route
to be sent to the stub area. This command does not need to be configured on other routers in the
stub area.
The parameter no-summary takes effect only when the stub command is configured on the
ABR. If this parameter is configured, the ABR only sends the summary-LSA of a default route
to the stub area without originating other summary-LSAs. The stub area without AS-external-
LSAs or Summary-LSAs is called a totally stub area.
----End
6.5.3.2 Configuring OSPFv3 Virtual Links
Context
After OSPFv3 areas are defined, OSPFv3 route update between non-backbone areas is
implemented through a backbone area. Then, OSPFv3 requires that all non-backbone areas
should maintain the connectivity with the backbone area and the backbone area should maintain
its own connectivity. In actual applications, this requirement may not be met because of some
restrictions. To solve this problem, you can configure OSPFv3 virtual links.
A virtual link must be configured at both ends of the link; otherwise, it does not take effect.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
Step 3 Run:
area area-id
Step 4 Run:
vlink-peer router-id [ hello hello-interval | retransmit retransmit-interval |
trans-delay trans-delay-interval | dead dead-interval | instance instance-id ] *
A virtual link is created and configured.
----End
Prerequisites
The configurations for the OSPFv3 Areas are complete.
Procedure
l Run the commands as follow to check the OSPFv3 routing table:
display ospfv3 [ process-id ] routing
display ospfv3 [ process-id ] routing [ abr-routes | asbr-routes | statistics
[ uninstalled ] | ipv6-address prefix-length | intra-routes | inter-routes | ase-routes |
nssa-routes ]
l Run the display ospfv3 [ process-id ] vlink command to check the information about
OSPFv3 virtual links.
----End
6.5.4 Configuring OSPFv3 NSSA Areas

Configuring a non-backbone area on the border of an autonomous system (AS) as a not-so-
stubby area (NSSA) can reduce entries in the routing table and the amount of routing information
to be transmitted. This section describes how to set the cost of the default route to an NSSA and
adjust the selection of the default route.
An NSSA allows the transmission of Type 7 LSAs, which are generated by ASBRs in an NSSA.
The Type 7 LSAs converting into Type 5 LSAs in the NSSA and advertised to other areas.

Routers
Before configuring an OSPFv3 NSSA, complete the following tasks:
6.5.4.1 Defining the Current Area to Be an NSSA Area
Context
Do as follows on the OSPFv3 router:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The OSPFv3 process view is displayed.
Step 3 Run:
area area-id
Step 4 Run:
nssa [ default-route-advertise [ cost cost | type type | tag tag ] * | no-import-
route | no-summary | translator-always | translator-interval translator-interval |
set-n-bit ] *
An area is configured as an NSSA.
----End
Follow-up Procedure
If an area is configured to the NSSA area, all routers of the area must be configured with the
NSSA attribute.
The area may be updated after NSSA attributes are configured or deleted. Thus, the NSSA
attributes can be re-configured or deleted only after the last update of NSSA attributes is
complete.
Prerequisites
The configurations for OSPFv3 NSSAs are complete.

Routers
Procedure
l Run the display ospfv3 [ process-id ] area [ area-id ] command to check information about
OSPFv3 areas.
l Run the commands as follow to check the OSPFv3 routing table.
display ospfv3 [ process-id ] routing [ abr-routes | asbr-routes | statistics | ipv6-
address prefix-length | intra-routes | inter-routes | ase-routes | nssa-routes ]
----End
6.5.5 Configuring OSPFv3 Route Attributes

By setting OSPFv3 route attributes, you can change OSPFv3 routing policies to meet the
requirements of complex networks.
In actual applications, to meet the requirements of a complicated networking environment, you
can change OSPFv3 routing policies by configuring OSPFv3 route attributes. Through the
following procedures, you can:
l Set the cost on the OSPFv3 interface.

l Configure load balancing among equal-cost routes.
Before configuring OSPFv3 route attributes, complete the following tasks:
6.5.5.1 Setting the Cost of the OSPFv3 Interface
Context
You can control route calculation by setting the link cost of OSPFv3 on different interfaces.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ospfv3 cost cost [ instance instance-id ]

Routers
The cost is set on the OSPFv3 interface.
By default, the link cost on an OSPFv3 interface is 1.
----End
Context
Do as follows on the router that runs OSPFv3:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
----End
Prerequisites
The configurations for the OSPFv3 Route Attributes are complete.
Procedure

Routers

----End
6.5.6 Controlling OSPFv3 Routing Information

This section describes how to control OSPFv3 routing information. Detailed operations include
configuring route aggregation, filtering the received routes, and importing external routes.
Through the configuration in this section, you can control the advertising and receiving of
OSPFv3 routing information and configure OSPFv3 to import external routes.
Before controlling OSPFv3 routing information, complete the following tasks:
6.5.6.1 Configuring OSPFv3 Route Aggregation
Context
If multiple continuous network segments exist in this area, use the abr-summary command to
summarize them into one network segment. In this way, the ABR only sends an LSA after
summarization. No LSA that belongs to the summarization network segment is separately
transmitted, thus reducing the LSDB size of other areas.
When a large number of routes are imported, use the asbr-summary command to summarize
the imported routes and set the delay for advertising the summarized route. In this manner, the
summarized route advertised each time contains more valid routing information, and network
flapping caused by incorrect routing information is avoided.
Procedure
l Configure route summarization on an ABR.
Do as follows on the ABR that runs OSPFv3:
1. Run:
system-view

2. Run:

3. Run:
area area-id

Routers
4. Run:
abr-summary ipv6-address prefix-length [ cost cost | not-advertise ] *
Route summarization is configured in the OSPFv3 area.
cost cost set the cost of a summarized route. By default, the cost of a summarized
route is the maximum cost among those of routes that are summarized. The value
ranges from 1 to 16777214.
If not-advertise is set, no routing information of the network segment is advertised.

l Configure route summarization on an ASBR.
Do as follows on the ASBR that runs OSPFv3:
1. Run:
system-view

2. Run:

3. Run:
asbr-summary ipv6-address summary-prefix-length [ cost summary-cost | tag
summary-tag | distribute-delay dist-delay-interval | not-advertise ] *
Route summarization is configured on the ASBR.
cost cost specifies the cost of a summarized route. By default, the cost of a summarized
route is the maximum cost among those of routes that are summarized. The value
ranges from 1 to 16777214.
tag tag specifies the tag used to control route advertisement. The value of this
parameter ranges from 0 to 4294967295.
If not-advertise is specified in the command, the summarized IPv6 route that matches
a specified IPv6 prefix or prefix length is not advertised.
distribute-delay interval specifies the delay for advertising a summarized route.
----End
6.5.6.2 Configuring OSPFv3 to Filter the Received Routes
Context
After receiving LSAs, OSPFv3 determines whether to add the calculated routes to the local
routing table according to the filtering policy.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
Step 3 Run:
import
OSPFv3 is configured to filter the imported routes.
Using the filter-policy command, you can only filter the routes calculated by OSPFv3. Routes
that do not pass the filtering are neither added to the OSPFv3 routing table nor advertised.
----End
6.5.6.3 Configuring OSPFv3 to Import External Routes
Context
Because OSPFv3 is a link state-based routing protocol and cannot directly filter the advertised
LSAs, OSPFv3 must filter the routes when importing them. Then, only the routes that pass the
filtering can be advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
default { cost cost | tag tag | type type }*
The default parameters of the imported route is set.
Step 4 Run:
import-route { bgp [ permit-ibgp ] | unr | direct | ripng help-process-id | static
| isis help-process-id | ospfv3 help-process-id } [ cost cost | inherit-cost } |
type type | tag tag | route-policy route-policy-name ]*
External routes are imported.
NOTE
Importing IBGP routes in OSPFv3 process can lead to routing loops.

After you run the import-route command on an OSPFv3 router to import external routes, the router
becomes an ASBR.

Routers

default-route-advertise [ always | cost cost | type type | tag tag | route-policy
route-policy-name ]*
Default routes are advertised to the OSPFv3 route area.

export [ protocol [ process-id ] ]
The imported external routes are filtered.
You can configure OSPFv3 to filter a certain type of routing information by specifying the
protocol. If protocol is not specified, OSPFv3 filters all the imported routes.
NOTE
The filter-policy command takes effect only on the routes imported through the import-route command
by the ASBR, that is, filters the imported routes. The routes that are filtered out do not generate LSAs and
cannot be advertised by OSPFv3. If the import-route command is not configured to import other external
routes (including OSPFv3 routes in different processes), the filter-policy command does not takes effect.
----End
6.5.6.4 (Optional) Configuring OSPFv3 to Filter LSAs in an Area
Context
After filtering conditions are set for the incoming or outgoing Type 3 LSAs (Inter-Area-Prefix
LSAs) in an area, only the Type 3 LSAs that meet the filtering conditions can be received or
advertised. This filters unnecessary LSAs, reduces the LSDB size, and increases network
convergence.
This function is applicable only to the ABR.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
area area-id
Step 4 Filter incoming or outgoing Type 3 LSAs in the area.

l Filter incoming Type 3 LSAs in the area.
Run the filter { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-
policy route-policy-name } import command to filter incoming Type 3 LSAs in the area.

Routers
l Filter outgoing Type 3 LSAs in the area.

Run the filter { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-
policy route-policy-name } export command to filter outgoing Type 3 LSAs in the area.
----End
Prerequisites
The configurations for Controlling OSPFv3 Routing Information are complete.
Procedure
l Run the commands as follow to check the OSPFv3 route aggregation:
display ospfv3 [ process-id ] abr-summary-list [ ipv6-address prefix-length ]
display ospfv3 [ process-id ] asbr-summary [ ipv6-address prefix-length ]
[ verbose ]
----End
6.5.7 Optimizing an OSPFv3 Network

By configuring OSPFv3 functions in special network environments, you can adjust and optimize
the OSPFv3 network performance.
By adjusting the OSPFv3 timer, you can change the convergence speed of an OSPFv3 network
and the network overload caused by protocol packets. On low-speed links, you need to consider
the delay in transmitting LSAs on the interface. By adjusting the SPF calculation interval, you
can mitigate resource consumption due to frequent network changes.
You can specify the DR priority of an interface to affect the DR/BDR election in a broadcast
network.
Before optimizing an OSPFv3 network, complete the configuration tasks:

Routers
6.5.7.1 Configuring the SPF Timer
Context
When the OSPFv3 link state database (LSDB) changes, SPF calculation needs to be performed
again. A shorter SPF calculation interval can increase the network convergence speed, but also
occupies more resources. If the network changes frequently, the bandwidth may be used up. A
longer SPF calculation interval occupies less resources, which prevents the bandwidth from
being used up due to frequent network changes. However, the network convergence speed
becomes slower in this scenario. Set the interval based on the actual network.
Procedure
l Configure an SPF normal timer.
1. Run:
system-view

2. Run:

3. Run:
spf timers delay-interval hold-interval
An SPF normal timer is configured.

l Configure an SPF intelligent timer.
1. Run:
system-view

2. Run:

3. Run:
spf-schedule-interval { delay-interval hold-interval | intelligent-timer
max-interval start-interval hold-interval-1 }
An SPF intelligent timer is configured.
NOTE
An SPF normal timer and an SPF intelligent timer are mutually exclusive.
----End
6.5.7.2 Setting the Interval for Receiving LSAs

Routers
Context
When a network is instable, control the minimum interval for receiving the same LSA update.
To prevent unnecessary LSA updates caused by network changes, by default, set the interval for
receiving the same LSA update to 1000ms.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
lsa-arrival-interval arrival-interval
The interval for receiving LSAs is set.

arrival-interval is an integer ranging from 1 to 10000, in milliseconds. By default, the interval
for receiving LSAs is 1000ms.
----End
6.5.7.3 Configuring an Intelligent Timer for Generating LSAs
Context
Setting the millisecond-level interval for generating the same LSA speeds up network
convergence. When a network becomes instable, reduce the interval for generating the same
LSA by using an intelligent timer.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
lsa-originate-interval intelligent-timer max-interval start-interval hold-interval
The interval interval for updating OSPFv3 LSAs by using an SPF intelligent timer is set.

Routers
l max-interval specifies the maximum interval for updating LSAs. The value ranges from 1 to
10000, in milliseconds.
l start-interval specifies the initial interval for updating LSAs. The value ranges from 0 to
1000, in milliseconds.
l hold-interval specifies the hold interval for updating LSAs. The value ranges from 1 to 5000,
in milliseconds.
By default, the maximum interval for updating LSAs is 5000ms, the initial interval for updating
LSAs is 500ms, the hold interval for updating LSAs is 1000ms.
----End
6.5.7.4 Suppressing an Interface from Sending and Receiving OSPFv3 Packets
Context
To prevent a router from advertising routes to the router on a certain network and from importing
the routes of other routers, you can suppress the interface on which OSPFv3 is enabled from
receiving and sending OSPFv3 packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
silent-interface interface-type interface-number
The interface is suppressed from sending and receiving OSPFv3 packets.
----End
Follow-up Procedure
Different processes can suppress the same interface from sending and receiving OSPFv3 packets,
but the silent-interface command is valid only for the OSPFv3 interface on which the specified
process is enabled, and does not take effect on the interface of other processes.
After an OSPFv3 interface is set to be silent, the interface can still advertise its direct routes
through the Intra-Area-Prefix-LSA of the same router. No OSPFv3 neighbor relationship can
be set up on the interface. Therefore, the OSPFv3 adaptability is enhanced.

Routers
6.5.7.5 Configuring DR Priority of an Interface
Context
The DR priority on a router interface qualifies the interface for the DR election. If the DR priority
is 0, the router cannot be elected as a DR or BDR.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 dr-priority priority [ instance instance-id ]
The DR priority of the interface is set.
----End
Follow-up Procedure
After the DR priority is changed, you can re-elect a DR or BDR through the following methods,
which, however, will result in the interruption of the OSPFv3 neighbor relationship between
routers and therefore are used only when necessary.
l Restarting all routers.

l Running the shutdown and undo shutdown commands on the interface on which the
OSPFv3 neighbor relationship is set up.
6.5.7.6 Configuring Stub Routers
Context
A stub router is used to control traffic. It notifies OSPFv3 routers not to forward data by the stub
router, but they can have a route to the stub router.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
Step 3 Run:
stub-router [ on-startup [ interval ] ]
The stub router is configured.
NOTE
There is no correlation between the stub router configured through this command and the router in the stub
area.
----End
6.5.7.7 Ignoring MTU Check on DD Packets
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 mtu-ignore [ instance instance-id ]
The MTU check on DD packets is ignored.
After the command is used, the interface does not check the MTU field of a received DD packet.
----End
Prerequisites
The configurations for Optimizing an OSPFv3 Network are complete.
Procedure
l Run the display ospfv3[ process-id ] interface [ area area-id ] [ interface-type interface-

Routers

----End
6.5.8 Configuration OSPFv3 GR

By configuring OSPFv3 GR, you can avoid route flapping and packet loss after an OSPFv3
router restarts.
To prevent route flapping and service interruption due to the restart of OSPFv3, you can enable
OSPFv3 GR.
After OSPFv3 restarts, the GR restarter and the GR helper keep the neighbor relationship,
exchange routing information, synchronize the database, and update the routing table and the
forwarding table. OSPFv3 fast convergence is thus realized.
NOTE
The AR150&200&1200&2200&3200 can function as only the Helper router, but cannot function as the
Restarter router.
Before configuring OSPFv3 GR, complete the following task:
6.5.8.1 Enabling OSPFv3 GR
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
Step 3 Run:
graceful-restart [ period period | ack-time time | retransmit-interval interval |
lsa-checking-ignore | planned-only ] *
OSPFv3 GR is enabled.
By default, OSPFv3 GR is disabled.
ack-time is optional. After ack-time is specified, the restarter can discover more neighbors in
the ack-time period.
----End
6.5.8.2 Enabling the Helper of OSPFv3 GR
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
helper-role [ { ip-prefix ip-prefix-name | acl-number acl-number | acl-name acl-
name } | max-grace-period period | planned-only | lsa-checking-ignore ] *
The helper of OSPFv3 GR is enabled.
By default, the helper of OSPFv3 GR is disabled.
----End
6.5.8.3 Check the Configuration
Prerequisites
The configurations for OSPFv3 GR are complete.

Routers
Procedure
l Run the display ospfv3 [ process-id ] graceful-restart-information command to check
the status of OSPFv3 GR.
----End
6.5.9 Configuring the Network Management Function of OSPFv3

OSPFv3 supports the network management function. You can bind the OSPFv3 MIB to a certain
OSPFv3 process.
OSPFv3 supports the network management function. You can bind OSPFv3 MIB and a certain
OSPFv3 process. In addition, OSPFv3 also supports the trap function and the log function.
Before configuring the network management function of OSPFv3, complete the following tasks:
6.5.9.1 Configuring OSPFv3 MIB Binding
Context
When multiple OSPFv3 processes are enabled, you can configure OSPFv3 MIB to select the
process to be processed, that is, that is, configure OSPFv3 MIB to select the process to which it
is bound.
Do as follows on the OSPFv3 router.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 mib-binding process-id
OSPFv3 MIB binding OSPFv3 process is configured.
----End
6.5.9.2 Configuring OSPFv3 Trap
Context
Do as follows on the OSPFv3 router.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent trap enable feature-name ospfv3 [ trap-name { ifconfigerror |
ifrxbadpacket | ifstatechange | nbrrestarthelperstatuschange | nbrstatechange |
nssatranslatorstatuschange | restartstatuschange | virtifconfigerror |
virtifrxbadpacket | virtifstatechange | virtnbrrestarthelperstatuschange |
virtnbrstatechange } ]
The trap function for the OSPFv3 module is enabled.
----End
6.5.9.3 Check the Configuration
Prerequisites
The configurations of the Network Management Function of OSPFv3 are complete.
Procedure
l Run the display current-configuration command to check the configuration currently
validated on the router.
----End
6.6 Maintaining OSPFv3

Maintaining OSPFv3 involve resetting OSPFv3.
6.6.1 Resetting OSPFv3
Context
NOTICE
The OSPFv3 adjacency is removed when you reset the OSPFv3 connection by using the reset
ospfv3 command. Exercise caution when running this command.
After modifying the OSPFv3 routing policy or protocol, reset the OSPFv3 connection to validate
the modification. To reset OSPFv3 connections, run the following reset ospfv3 command in the
user view.

Routers
Procedure
l To validate the new configuration, run the following commands:
reset ospfv3 { process-id | all } [ graceful-restart [ extend-period period ] ]
reset ospfv3 { process-id | all } counters [ neighbor [ interface-type interface-
number ] [ router-id ] ]
----End

This section provides several configuration examples of OSPFv3 together with the configuration
roadmap.
6.7.1 Example for Configuring OSPFv3 Areas
As shown in Figure 6-7, all routers run OSPFv3. The entire autonomous system is divided into
three areas. RouterB and RouterC serve as ABRs to forward the inter-area routes.
It is required that Area 2 be configured to decrease the LSAs advertised to this area, without
affecting route reachability.
Figure 6-7 Networking diagram of configuring OSPFv3 areas
RouterB Area0 RouterC
GE1/0/0 GE1/0/0
1000::1/64 1000::2/64 GE2/0/0
GE2/0/0 1002::1/64
1001::1/64
GE2/0/0 GE1/0/0
1001::2/64 1002::2/64
RouterA RouterD
GE1/0/0
2000::1/64
Area1 Area2
1. Enable basic OSPFv3 function on each router.

Routers
2. Configure Area 2 as a stub area to decrease the LSAs advertised to this area, without
affecting route reachability.
Procedure
Step 1 Assign an IPv6 address for each interface.
The details are not mentioned here.
Step 2 Configure basic OSPFv3 functions.
[RouterA] ipv6
[RouterA] ospfv3
[RouterA-ospfv3-1] router-id 1.1.1.1
[RouterA-ospfv3-1] quit
[RouterA-GigabitEthernet1/0/0] ospfv3 1 area 1
[RouterB] ipv6
[RouterB] ospfv3
[RouterB-ospfv3-1] router-id 2.2.2.2
[RouterB-ospfv3-1] quit
[RouterB-GigabitEthernet1/0/0] ospfv3 1 area 0
[RouterC] ipv6
[RouterC] ospfv3
[RouterC-ospfv3-1] router-id 3.3.3.3
[RouterC-ospfv3-1] quit
[RouterC-GigabitEthernet1/0/0] ospfv3 1 area 0
# Configure RouterD.
[RouterD] ipv6
[RouterD] ospfv3
[RouterD-ospfv3-1] router-id 4.4.4.4
[RouterD-ospfv3-1] quit
[RouterD] interface gigabitethernet 1/0/0
[RouterD-GigabitEthernet1/0/0] ospfv3 1 area 2
[RouterD-GigabitEthernet1/0/0] quit
# Display the OSPFv3 neighbors of RouterB.

[RouterB] display ospfv3 peer
OSPFv3 Process (1)
OSPFv3 Area (0.0.0.1)
Neighbor ID Pri State Dead Time Interface Instance ID

Routers
1.1.1.1 1 Full/ - 00:00:34 GE2/0/0 0

3.3.3.3 1 Full/ - 00:00:32 GE1/0/0 0
# Display OSPFv3 neighbors of RouterC.

[RouterC] display ospfv3 peer
OSPFv3 Process (1)
2.2.2.2 1 Full/ - 00:00:37 GE1/0/0 0
4.4.4.4 1 Full/ - 00:00:33 GE2/0/0 0
# Display the OSPFv3 routing table of RouterD.

[RouterD] display ospfv3 routing
Codes : E2 - Type 2 External, E1 - Type 1 External, IA - Inter-Area,
N - NSSA, U - Uninstalled
OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA 1000::/64 2
via FE80::1572:0:5EF4:1, GigabitEthernet1/0/0
IA 1001::/64 3
1002::/64 1
directly-connected, GigabitEthernet1/0/0
IA 2000::/64 4
Step 3 Configure stub areas.

# Configure the stub area of RouterD.
[RouterD] ospfv3
[RouterD-ospfv3-1] area 2
[RouterD-ospfv3-1-area-0.0.0.2] stub
[RouterD-ospfv3-1-area-0.0.0.2] quit
# Configure the stub area of RouterC, and set the cost of the default route advertised to the stub
area to 10.
[RouterC] ospfv3
[RouterC-ospfv3-1] area 2
[RouterC-ospfv3-1-area-0.0.0.2] stub
[RouterC-ospfv3-1-area-0.0.0.2] default-cost 10
[RouterC-ospfv3-1-area-0.0.0.2] quit
# Display the OSPFv3 routing table of RouterD, and you can view a new default route in the
routing table. Its cost is the sum of the cost of the directly connected routes and the configured
cost.
OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA ::/0 11
IA 1000::/64 2

Routers
IA 1001::/64 3
1002::/64 1
IA 2000::/64 4
Step 4 Configure totally stub areas.
# Configure RouterC and configure Area 2 as a totally stub area.

[RouterC] ospfv3
[RouterC-ospfv3-1] area 2
[RouterC-ospfv3-1-area-0.0.0.2] stub no-summary
[RouterC-ospfv3-1-area-0.0.0.2] quit
# Display the OSPFv3 routing table of RouterD, and you can view that the entries in the routing
table decrease; other non-directly connected routes are suppressed; only the default route is
reserved.
OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA ::/0 11
1002::/64 1
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
ospfv3 1 area 0.0.0.1
#
ipv6 enable
#
ospfv3 1
router-id 1.1.1.1
#
return

#
sysname RouterB
#
ipv6
#

Routers
ipv6 enable
#
ipv6 enable
#
ospfv3 1
router-id 2.2.2.2
#
return

#
sysname RouterC
#
ipv6
#
ipv6 enable
#
ipv6 enable
#
ospfv3 1
router-id 3.3.3.3
area 0.0.0.2
stub no-summary
default-cost 10
#
return
l Configuration file of RouterD

#
sysname RouterD
#
ipv6
#
ipv6 enable
#
ospfv3 1
router-id 4.4.4.4
area 0.0.0.2
stub
#
return
6.7.2 Example for Configuring OSPFv3 DR Election

In Figure 6-8, RouterA has a DR priority of 100, which is the highest in the network, so it is
elected as the DR. RouterC has the second highest priority, so it is elected as the BDR. The
priority of RouterB is 0 so that it cannot be elected as the DR and BDR. RouterD does not have
a priority and the priority is 1 by default.

Routers
Figure 6-8 Networking diagram of configuring OSPFv3 DR election
RouterA RouterB
GE1/0/0 GE1/0/0
1001::1/64 1001::2/64
GE1/0/0 GE1/0/0
1001::3/64 1001::4/64
RouterC RouterD
1. Configure the router ID on each router, enable OSPFv3, and specify the network segment.
2. Check the DR/BDR status with the default priority.
3. Configure the DR priority on the interface and check the DR/BDR status.
Procedure
Step 2 Configure basic OSPFv3 functions.
# Configure RouterA, enable OSPFv3, and set its router ID to 1.1.1.1.

[RouterA] ipv6
[RouterA] ospfv3
[RouterA-ospfv3-1] router-id 1.1.1.1
[RouterA-ospfv3-1] quit
# Configure RouterB, enable OSPFv3, and set its Router ID to 2.2.2.2.

[RouterB] ipv6
[RouterB] ospfv3
[RouterB-ospfv3-1] router-id 2.2.2.2
[RouterB-ospfv3-1] quit
# Configure RouterC, enable OSPFv3, and set its Router ID to 3.3.3.3.

[RouterC] ipv6
[RouterC] ospfv3

Routers
[RouterC-ospfv3-1] router-id 3.3.3.3

[RouterC-ospfv3-1] quit
# Configure RouterD, enable OSPFv3, and set its Router ID to 4.4.4.4.

[RouterD] ipv6
[RouterD] ospfv3
[RouterD-ospfv3-1] router-id 4.4.4.4
[RouterD-ospfv3-1] quit
[RouterD-GigabitEthernet1/0/0] ospfv3 1 area 0
# Display the neighbors of RouterA. You can view the DR priority (its default value is 1) and
the neighbor status. RouterD is the DR and RouterC is the BDR.
NOTE
The router with the greater router ID is the DR when routers have the same priority. If a certain Ethernet
interface of a router becomes a DR, the other broadcast interfaces of the router have the highest priority in
DR election. That is, the DR router is elected as the DR.
[RouterA] display ospfv3 peer
OSPFv3 Process (1)
2.2.2.2 1 2-Way/DROther 00:00:32 GE1/0/0 0
3.3.3.3 1 Full/Backup 00:00:36 GE1/0/0 0
4.4.4.4 1 Full/DR 00:00:38 GE1/0/0 0
# Display the neighbors of RouterD, and you can view that all neighbors of RouterD are in the
Full state.
[RouterD] display ospfv3 peer
OSPFv3 Process (1)
1.1.1.1 1 Full/DROther 00:00:32 GE1/0/0 0
2.2.2.2 1 Full/DROther 00:00:35 GE1/0/0 0
3.3.3.3 1 Full/Backup 00:00:30 GE1/0/0 0
Step 3 Set the DR priority of the interface.

# Set the DR priority of RouterA to 100.
[RouterA-GigabitEthernet1/0/0] ospfv3 dr-priority 100
# Set the DR priority of RouterB to 0.

[RouterB-GigabitEthernet1/0/0] ospfv3 dr-priority 0
# Set the DR priority of RouterC to 2.

[RouterC-GigabitEthernet1/0/0] ospfv3 dr-priority 2
# Display the neighbors of RouterA, and you can view that the DR priority is updated and the
DR and BDR remain unchanged.

Routers
OSPFv3 Process (1)

2.2.2.2 0 2-Way/DROther 00:00:34 GE1/0/0 0
3.3.3.3 2 Full/Backup 00:00:38 GE1/0/0 0
4.4.4.4 1 Full/DR 00:00:31 GE1/0/0 0
# Display the neighbors of RouterD, and you can view that RouterD remains as the DR.
OSPFv3 Process (1)
1.1.1.1 100 Full/DROther 00:00:36 GE1/0/0 0
2.2.2.2 0 Full/DROther 00:00:30 GE1/0/0 0
3.3.3.3 2 Full/Backup 00:00:36 GE1/0/0 0
Step 4 Re-elect the DR/BDR.
# Restart all routers (or run the shutdown and undo shutdown commands on the interface that
establishes the OSPFv3 neighbor relationship), and make OSPFv3 re-elect the DR/BDR.
# Display the neighbors of RouterA, and you can view that RouterC is the BDR.
OSPFv3 Process (1)
2.2.2.2 0 Full/DROther 00:00:31 GE1/0/0 0
3.3.3.3 2 Full/Backup 00:00:36 GE1/0/0 0
4.4.4.4 1 Full/DROther 00:00:39 GE1/0/0 0
# Display the neighbors of RouterD, and you can view that RouterA is the DR.
OSPFv3 Process (1)
1.1.1.1 100 Full/DR 00:00:39 GE1/0/0 0
2.2.2.2 0 2-Way/DROther 00:00:35 GE1/0/0 0
3.3.3.3 2 Full/Backup 00:00:39 GE1/0/0 0
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
ospfv3 dr-priority 100
#
ospfv3 1
router-id 1.1.1.1
#
return

Routers

#
sysname RouterB
#
ipv6
#
ipv6 enable
#
ospfv3 1
router-id 2.2.2.2
#
return

#
sysname RouterC
#
ipv6
#
ipv6 enable
#
ospfv3 1
router-id 3.3.3.3
#
return

#
sysname RouterD
#
ipv6
#
ipv6 enable
#
ospfv3 1
router-id 4.4.4.4
#
return
6.8 References
This section lists references of OSPFv3.
The following table lists the references of this document.
Document Description Rema

rks
RFC 2740 This document describes the modifications to OSPF to -

support version 6 of the Internet Protocol (IPv6).

Routers
Document Description Rema

rks
draft-ietf-ospf- This document describes the OSPFv3 graceful restart. The -

ospfv3-graceful- OSPFv3 graceful restart is identical to OSPFv2 except for the
restart differences described in this document. These differences
include the format of the grace Link State Advertisements
(LSA) and other considerations.
draft-ietf-ospf- This memo defines a portion of the Management Information -

ospfv3-mib-11 Base (MIB) for use with network management protocols in
IPv6-based internets. In particular, it defines objects for
managing the Open Shortest Path First Routing Protocol for
IPv6.

Routers
Configuration Guide - IP Routing 7 IPv4 IS-IS Configuration
7 IPv4 IS-IS Configuration
About This Chapter
You can build an IPv4 IS-IS network to allow IS-IS to discover and calculate routes in an
autonomous system (AS).
7.1 Introduction to IS-IS

This section describes the definition and functions of IS-IS.
7.2 Principles
This section describes the implementation of IS-IS.
After basic IS-IS functions are configured, you can build a Layer 3 network using the IS-IS
protocol. If other IS-IS functions are required, configure them according to reference sections.
This section describes the default configuration of IPv4 IS-IS, which can be changed according
7.5 Configuring IS-IS (IPv4)
By building IS-IS IPv4 networks, you can discover and calculate routes in ASs.
7.6 Maintaining IS-IS
Maintaining IS-IS includes resetting IS-IS, configuring IS-IS host name mapping and
configuring the Output of IS-IS Adjacency Status
This section describes IS-IS configuration examples, including networking requirements,
configuration roadmap, and configuration procedure.
This section describes common faults caused by incorrect IS-IS configurations and provides the
7.9 FAQ
7.10 References

Routers
This section lists references of IS-IS.

Routers

Definition
Intermediate System-to-Intermediate System (IS-IS) is an Interior Gateway Protocol (IGP) that
runs within an autonomous system (AS). IS-IS is also a link-state routing protocol, using the
shortest path first (SPF) algorithm to calculate routes.
Purpose
IS-IS is a dynamic routing protocol initially designed by the International Organization for
Standardization (ISO) for its Connectionless Network Protocol (CLNP).
To support IP routing, the Internet Engineering Task Force (IETF) extended and modified IS-
IS in RFC 1195. This modification enables IS-IS to apply to TCP/IP and OSI environments.
This type of IS-IS is called Integrated IS-IS or Dual IS-IS.
NOTE
IS-IS stated in this document refers to Integrated IS-IS, unless otherwise stated.
In addition to IPv4 networks, IS-IS also applies to IPv6 networks to provide accurate routing
information for IPv6 packets. IS-IS has good scalability, supports IPv6 network layer protocols,
and is capable of discovering, generating, and forwarding IPv6 routes.
7.2 Principles
This section describes the implementation of IS-IS.
7.2.1 IS-IS Basic Concepts
IS-IS Topology Structure

Overall IS-IS Topology
IS-IS uses a two-level hierarchy (backbone area and non-backbone area) to support large-scale
routing networks. Generally, Level-1 routers are deployed in non-backbone areas, whereas
Level-2 and Level-1-2 routers are deployed in backbone areas. Each non-backbone area connects
to the backbone area through a Level-1-2 router.
Figure 7-1 shows a network that runs IS-IS. The network is similar to an OSPF network typology
with multiple areas. The backbone area contains all the routers in Area 1 and Level-1-2 routers
in other areas.

Routers
Figure 7-1 IS-IS topology I
Area2
Area3
L1
L1/2
L2 L1/2
L2
backbone Area1
L2 L2
L1
L1/2 L1/2
L1 L1
L1
L1
Area4 Area5
Figure 7-2 shows another type of IS-IS topology. In this topology, Level-2 routers belong to
different areas. All the physically contiguous Level-1-2 and Level-2 routers form the backbone
area of IS-IS.
Figure 7-2 IS-IS topology II
Area1
L1
L2
L1
L1/2
Area2 L1/2 L1
Area4
L2
L2 Area3
The two types of topologies show the differences between IS-IS and OSPF:
l In IS-IS, each router belongs to only one area. In OSPF, different interfaces of a router may
belong to different areas.
l In IS-IS, no area is defined as the backbone area. In OSPF, Area 0 is defined as the backbone
area.

Routers
l In IS-IS, Level-1 and Level-2 routes are calculated using the SPF algorithm to generate the
shortest path tree (SPT). In OSPF, the SPF algorithm is used only in the same area, and
inter-area routes are forwarded by the backbone area.
IS-IS Router Types

l Level-1 router
A Level-1 router manages intra-area routing. It establishes neighbor relationships with only
the Level-1 and Level-1-2 routers in the same area and maintains a Level-1 link state
database (LSDB). The LSDB contains intra-area routing information. A packet to a
destination outside this area is forwarded to the nearest Level-1-2 router.
l Level-2 router
A Level-2 router manages inter-area routing. It can establish neighbor relationships with
Level-2 or Level-1-2 routers in different areas and maintains a Level-2 LSDB. The LSDB
contains inter-area routing information.
All Level-2 routers form the backbone network of the routing domain. They establish
Level-2 neighbor relationships and are responsible for inter-area communication. Level-2
routers in the routing domain must be physically contiguous to ensure the continuity of the
backbone network. Only Level-2 routers can exchange data packets or routing information
with routers outside the routing domain.
l Level-1-2 router
A router that belongs to both a Level-1 area and a Level-2 area is called a Level-1-2 router.
It can establish Level-1 neighbor relationships with Level-1 and Level-1-2 routers in the
same area. It can also establish Level-2 neighbor relationships with Level-2 and Level-1-2
routers in different areas. A Level-1 router must be connected to other areas through a
Level-1-2 router.
A Level-1-2 router maintains two LSDBs: a Level-1 LSDB and a Level-2 LSDB. The
Level-1 LSDB saves for intra-area routing and the Level-2 LSDB saves for inter-area
routing.
IS-IS Network Types
IS-IS supports only two types of networks. In terms of physical links, IS-IS networks can be
classified into the following link types:
l Broadcast: such as Ethernet and Token-Ring

l Point-to-point: such as PPP and HDLC
NOTE
For a Non-Broadcast Multi-Access (NBMA) network such as the ATM, you should configure its sub-
interfaces as P2P interfaces.
IS-IS cannot run on Point to MultiPoint (P2MP) networks.
DIS and Pseudonode
In a broadcast network, IS-IS needs to elect a Designated Intermediate System (DIS) from all
the routers. DISs are used to create and update pseudonodes and generate link state protocol data
units (LSPs) of pseudonodes to describe available network devices.
The pseudonode is used to simulate the virtual node in the broadcast network and is not an actual
router. In IS-IS, a pseudonode is identified by the system ID of the DIS and the 1-byte Circuit
ID (its value is not 0).

Routers
Figure 7-3 Pseudonode
L1 L1 L1 L1
Pseudonode
L1 DIS L1 L1 DIS L1
Physical
connection
Virtual
connection
As shown in Figure 7-3, the use of pseudonodes simplifies the network topology and shortens
LSPs. When the network changes, the number of generated LSPs is reduced, and the SPF
consumes fewer resources.
Level-1 and Level-2 DISs are elected separately. You can configure different priorities for DISs
of different levels. The router with the highest priority is elected as the DIS. If there are multiple
routers with the same highest priority on a broadcast network, the one with the highest MAC
address is chosen. The DISs of different levels can be the same router or different routers.
DIS election in IS-IS differs from designated router (DR) election in OSPF:
l On an IS-IS broadcast network, the router with priority 0 also takes part in DIS election.
In OSPF, the router with priority 0 does not take part in DR election.
l In IS-IS, when a new router that meets the requirements of being a DIS connects to a
broadcast network, the router is elected as the new DIS, and the previous pseudonode is
deleted. This causes a new flooding of LSPs. In OSPF, when a new router connects to a
network, it is not immediately elected as the DR even if it has the highest DR priority.
l On an IS-IS broadcast network, routers (including non-DIS routers) of the same level on a
network segment set up adjacencies. In OSPF, routers set up adjacencies with only the DR
and backup designated router (BDR).
NOTE
On an IS-IS broadcast network, although all the routers set up adjacencies with each other, the LSDBs are
synchronized by the DISs.
IS-IS Address Structure

The network service access point (NSAP) is an address defined by the OSI to locate resources.
Figure 7-4 shows the NSAP address structure. The NSAP is composed of the initial domain
part (IDP) and the domain specific part (DSP). The lengths of the IDP and the DSP are variable.
The maximum length of the NSAP is 20 bytes and its minimum length is 8 bytes.
l The IDP is similar to the network ID in an IP address. It is defined by the ISO and consists
of the authority and format identifier (AFI) and the initial domain identifier (IDI). The AFI

Routers
indicates the address allocation authority and address format, and the IDI identifies a
domain.
l The DSP is similar to the subnet ID and host address in an IP address. The DSP consists
of the High Order DSP (HODSP), system ID, and NSAP Selector (SEL). The HODSP is
used to divide areas, the system ID identifies a host, and the SEL indicates the service type.
Figure 7-4 IS-IS address structure
IDP DSP
AFI IDI High Order DSP System ID SEL(1 octet)
Area Address
l Area Address
The IDP and the HODSP of the DSP identify a routing domain and the areas in a routing
domain. Therefore, the combination of the IDP and HODSP is called an area address, which
is similar to an area number in OSPF. The area addresses of routers in the same Level-1
area must be the same, while the area addresses of routers in the Level-2 area can be
different.
In general, a router can be configured with only one area address. The area address of all
nodes in an area must be the same. In the implementation of a device, an IS-IS process can
be configured with a maximum of three area addresses to support seamless combination,
division, and transformation of areas.
l System ID
A system ID uniquely identifies a host or a router in an area. In the device, the fixed length
of the system ID is 48 bits (6 bytes).
In actual applications, a router ID corresponds to a system ID. If a router takes the IP address
168.10.1.1 of Loopback 0 as its router ID, its system ID used in IS-IS can be obtained in
the following way:
Extend each part of IP address 168.10.1.1 to 3 bits and add 0 to the front of any part
that is shorter than 3 bits. Then the IP address is extended as 168.010.001.001.
Divide the extended address 168.010.001.001 into three parts, each of which consists
of four decimal digits. Then system ID 1680.1000.1001 is obtained.
You can specify a system ID in many ways. You need to ensure that the system ID uniquely
identifies a host or a router.
l SEL
The role of an SEL is similar to that of the "protocol identifier" of IP. A transport protocol
matches an SEL. The SEL is always "00" in IP.
A network entity title (NET) indicates network layer information about an IS. A NET can be
regarded as a special NSAP. The NET length is the same as the NSAP length. Its maximum
length is 20 bytes and minimum length is 8 bytes. When configuring IS-IS on a router, you only
need to configure a NET but not an NSAP.

Routers
Assume that there is a NET: ab.cdef.1234.5678.9abc.00. In the NET, the area address is ab.cdef,
the system ID is 1234.5678.9abc, and the SEL is 00.
IS-IS PDU Types

IS-IS PDUs include Hello PDUs, link state PDUs (LSPs), and sequence number PDUs (SNPs).
l Hello PDU
Hello packets, also called IS-IS Hello PDUs (IIH), are used to set up and maintain neighbor
relationships. Among them, Level-1 LAN IIHs apply to the Level-1 routers on broadcast
LANs; Level-2 LAN IIHs apply to the Level-2 routers on broadcast LANs; and P2P IIHs
apply to non-broadcast networks. Hello packets on different networks have different
formats. Compared to a LAN IIH, a P2P IIH does not have the Priority and LAN ID fields,
but has a Local Circuit ID field. The Priority field indicates the DIS priority on a broadcast
network, the LAN ID field indicates the system ID of the DIS and pseudonode, and the
Local Circuit ID indicates the local link ID.
l LSP
LSPs are used to exchange link-state information. There are two types of LSPs: Level-1
and Level-2. Level-1 IS-IS transmits Level-1 LSPs; Level-2 IS-IS transmits Level-2 LSPs;
and Level-1-2 IS-IS can transmit both Level-1 and Level-2 LSPs.
The meanings of major fields in an LSP are as follows:
ATT field: When a Level-1-2 IS-IS transmits Level-1 LSPs in a Level-1 area, Level-1
IS-IS in the area can communicate with devices in other areas through the Level-1-2
IS-IS if the ATT bit is set in the Level-1 LSPs.
OL field: indicates the LSDB overload.
LSPs with the overload bit are still flooded on the network, but these LSPs are ignored
during the calculation of the routes that pass through a router in overload state. After
the overload bit is set on a router, other routers ignore the router when performing SPF
calculation and consider only the direct routes of the router. For details, see "IS-IS
Overload" in Principles.
IS Type field: indicates the type of IS-IS that generates the LSP. The value 01 indicates
Level-1, and the value 11 indicates Level-2.
l SNP
SNPs describe the LSPs in all or some databases to help synchronize and maintain all
LSDBs.
SNPs include complete SNPs (CSNPs) and partial SNPs (PSNPs). They are further
classified into Level-1 CSNPs, Level-2 CSNPs, Level-1 PSNPs, and Level-2 PSNPs.
A CSNP contains the summary of all LSPs in an LSDB. This maintains LSDB
synchronization between neighboring routers. On a broadcast network, the DIS periodically
sends CSNPs. The default interval for sending CSNPs is 10 seconds. On a point-to-point
link, CSNPs are sent only when the neighbor relationship is established for the first time.
A PSNP lists only the sequence number of recently received LSPs. A PSNP can
acknowledge multiple LSPs at one time. If an LSDB is not updated, the PSNP is also used
to request a neighbor to send a new LSP.
The variable length fields in an IS-IS PDU are multiple type-length-values (TLVs). Figure
7-5 shows the TLV format. A TLV is also called a code-length-value (CLV).

Routers
Figure 7-5 TLV format

No. of Octets
Type 1
Length 1
Value Length
TLVs vary according to PDU types, as shown in Table 7-1.
Table 7-1 PDU types and TLV names
TLV Type Name Applied PDU Type
1 Area Addresses IIH, LSP
2 IS Neighbors (LSP) LSP
4 Partition Designated Level2 IS L2 LSP
6 IS Neighbors (MAC Address) LAN IIH
7 IS Neighbors (SNPA Address) LAN IIH
8 Padding IIH
9 LSP Entries SNP
10 Authentication Information IIH, LSP, SNP
128 IP Internal Reachability Information LSP
129 Protocols Supported IIH, LSP
130 IP External Reachability Information L2 LSP
131 Inter-Domain Routing Protocol Information L2 LSP
132 IP Interface Address IIH, LSP
TLVs with the type value ranging from 1 to 10 are defined in ISO 10589, and the other TLVs
are defined in RFC 1195.
7.2.2 IS-IS Basic Principles

IS-IS is a link-state routing protocol. Each router generates an LSP that contains link state
information about all the IS-IS interfaces on the router. The router can establish IS-IS neighbor
relationships with neighboring devices and update its LSDB to synchronize the local LSDB with
the LSDBs of all the other devices on the IS-IS network. Based on the local LSDB, the router
uses the SPF algorithm to calculate IS-IS routes. If the router finds that an IS-IS route is the
optimal route to a destination, the router adds the route to the local IP routing table to guide
packet forwarding.

Routers
Establishment of IS-IS Neighbor Relationship

Two IS-IS routers need to establish a neighbor relationship before exchanging packets to
implement routing. On different networks, the modes for establishing IS-IS neighbors are
different.
l Establishment of a neighbor relationship on a broadcast link

Figure 7-6 uses Level-2 routers as an example to describe the process of establishing a
neighbor relationship on a broadcast link. The process of establishing a neighbor
relationship between Level-1 routers is the same as the process of establishing a neighbor
relationship between Level-2 routers.
Figure 7-6 Process of establishing a neighbor relationship on a broadcast link
RouterA RouterB
SYS id:1111.1111.1111 SYS id:2222.2222.2222

L2 LAN IIH
( sys id:1111.1111.1111 neighbor:null ) neighbor RouterA
L2 LAN IIH initialized
neighbor RouterB ( sys id:2222.2222.2222 neighbor:Router A )
established L2 LAN IIH
( sys id:1111.1111.1111 neighbor:Router B )
neighbor RouterA
L2 LAN IIH established
L2 LAN IIH
1. RouterA broadcasts a Level-2 LAN IS-IS Hello PDU (IIH) with no neighbor ID
specified.
2. RouterB receives this packet and sets the status of the neighbor relationship with
RouterA to Initial. RouterB then responds to RouterA with a Level-2 LAN IIH,
indicating that RouterA is a neighbor of RouterB.
3. RouterA receives this packet and sets the status of the neighbor relationship with
RouterB to Up. RouterA then sends RouterB a Level-2 LAN IIH indicating that
RouterB is a neighbor of RouterA.
4. RouterB receives this packet and sets the status of the neighbor relationship with
RouterA to Up. RouterA and RouterB establish a neighbor relationship successfully.
The network is a broadcast network, so a DIS needs to be elected. After the neighbor
relationship is established, routers wait for two intervals before sending Hello packets to
elect the DIS. The IIH packets exchanged by the routers contain the Priority field. The
router with the highest priority is elected as the DIS. If the routers have the same priority,
the router with the largest interface MAC address is elected as the DIS.
l Establishment of a neighbor relationship on a P2P link

Routers
Unlike the establishment of a neighbor relationship on a broadcast link, the establishment

of a neighbor relationship on a P2P link is classified into two modes: two-way mode and
three-way mode.
Two-way mode
Upon receiving a P2P IIH from a neighbor, a router considers the neighbor Up and
establishes a neighbor relationship with the neighbor.
Three-way mode
A neighbor relationship is established after P2P IIHs are sent for three times. The
establishment of a neighbor relationship on a P2P link is similar to that on a broadcast
link.
Two-way mode has distinct disadvantages. For example, when two or more links exist
between two routers, the two routers can still establish a neighbor relationship if one link
is Down and the other is Up in the same direction. The parameters of the link in Up state
are used in SPF calculation. As a result, the router that does not detect the fault of the link
in Down state still tries to forward packets over this link. Three-way mode addresses such
problems on unreliable P2P links. In three-way mode, a router considers the neighbor Up
only after confirming that the neighbor receives the packet sent by itself, and then
establishes a neighbor relationship with the neighbor.
Basic rules for establishing an IS-IS neighbor relationship are as follows:

l Only neighboring routers of the same level can set up the neighbor relationship with each
other.
l For Level-1 routers, their area IDs must be the same
l Network types of IS-IS interfaces on both ends of a link must be consistent.
NOTE
Ethernet interfaces can be simulated as P2P interfaces to establish a neighbor relationship on a P2P
link.
l IP addresses of IS-IS interfaces on both ends of a link must be on the same network segment.
IS-IS runs on the data-link layer and was initially designed for CLNP. Therefore, the
establishment of an IS-IS neighbor relationship is not related to IP addresses. In the
implementation of a device, IS-IS runs only over IP. Therefore, IS-IS needs to check the
IP address of its neighbor. If secondary IP addresses are assigned to the interfaces, the
routers can still set up the IS-IS neighbor relationship, but only when either the primary IP
addresses or secondary IP addresses are on the same network segment.
NOTE
When IP addresses of IS-IS interfaces on both ends of a link are on different network segments, a
neighbor relationship can still be established on the two interfaces if the interfaces are configured
not to check the IP addresses in received Hello packets. You can configure P2P interfaces not to
check the IP addresses in received Hello packets. Before configuring Ethernet interfaces not to check
the IP addresses, simulate Ethernet interfaces as P2P interfaces.
Process of Exchanging IS-IS LSPs

Causes of LSP generation
All routers in the IS-IS routing domain can generate LSPs. The following events trigger the
generation of a new LSP:
l Neighbor is Up or Down.

Routers
l Related interface goes Up or Down.

l Imported IP routes change.
l Inter-area IP routes change.
l Interface is assigned a new metric value.
l Periodic updates occur.
Processing of a new LSP received from a neighbor
1. The router installs the LSP to its LSDB and marks it for flooding.
2. The router sends the LSP to all interfaces except the interface that initially received the
LSP.
3. The neighbors flood the LSP to their neighbors.
LSP flooding
In LSP flooding, a router sends an LSP to its neighbors and then the neighbors send the received
LSP to their respective neighbors except the router that first sends the LSP. In this manner, the
LSP is flooded among the routers of the same level. LSP flooding allows each router of the same
level to have the same LSP information and synchronize its LSDB with each other.
Each LSP has a 4-byte sequence number. When a router is started, the sequence number of the
first LSP sent by the router is 1. When a new LSP is generated, the sequence number of the LSP
is equal to the sequence number of the previous LSP plus 1. The greater the sequence number,
the newer the LSP.
Process of synchronizing LSDBs between a newly added router and DIS on a broadcast
link
Figure 7-7 Process of updating LSDBs on a broadcast link
RouterA
RouterC
RouterB( DIS)
1 LSP
Router C.00-
CSNP 00
Router A.00-00 2
Router B.00-00
Router B.01-00 PSNP
Router C.00-00 3 Router A.00-00
Router B.00-00
Router B.01-00
LSP 4
Router A.00-00
Router B.00-00
Router B.01-00

Routers
1. As shown in Figure 7-7, a new router (RouterC) sends a Hello packet to establish neighbor
relationships with the other routers in the broadcast domain.
2. RouterC establishes neighbor relationships with RouterA and RouterB, waits for the
timeout of the LSP refresh timer, and then sends its LSP to a multicast address (01-80-
C2-00-00-14 in a Level-1 area and 01-80-C2-00-00-15 in a Level-2 area). All neighbors
on the network can receive the LSP.
3. The DIS on the network segment adds the received LSP to its LSDB. After the CSNP timer
expires, the DIS sends CSNPs to synchronize the LSDBs on the network.
4. RouterC receives the CSNPs from the DIS, checks its LSDB, and sends a PSNP to request
the LSPs it does not have.
5. The DIS receives the PSNP and sends RouterC the required LSPs for LSDB
synchronization.
The process of updating the LSDB of the DIS is as follows:

1. When the DIS receives an LSP, it searches the LSDB to check whether the same LSP exists.
If the DIS does not find the same LSP in its LSDB, the DIS adds the LSP to its LSDB and
broadcasts the content of the new LSDB.
2. If the sequence number of the received LSP is greater than that of the corresponding LSP
in the LSDB, the DIS replaces the existing LSP with the received LSP and broadcasts the
contents of the new LSDB. If the sequence number of the received LSP is smaller than that
of the corresponding LSP in the LSDB, the DIS sends its LSP in the LSDB through the
inbound interface of the received LSP.
3. If the sequence number of the received LSP is the same as that of the corresponding LSP
in the LSDB, the DIS compares the remaining lifetime of the two LSPs. If the remaining
lifetime of the received LSP is smaller than that of the corresponding LSP in the LSDB,
the DIS replaces the existing LSP with the received LSP and broadcasts the contents of the
new LSDB. If the remaining lifetime of the received LSP is greater than that of the
corresponding LSP, the DIS sends its LSP in the LSDB through the inbound interface of
the received LSP.
4. If the sequence number and remaining lifetime of the received LSP are the same as those
of the corresponding LSP in the LSDB, the DIS compares the checksum of the two LSPs.
If the checksum of the received LSP is greater than that of the corresponding LSP in the
LSDB, the DIS replaces the existing LSP with the received LSP and broadcasts the content
of the new LSDB. If the checksum of the received LSP is smaller than that of the
corresponding LSP, the DIS sends its LSP in the LSDB through the inbound interface of
the received LSP.
5. If the sequence number, remaining lifetime, and checksum of the received LSP are the same
as those of the corresponding LSP in the LSDB, the DIS does not forward the received
LSP.
Process of synchronizing the LSDB on a P2P link

Routers
Figure 7-8 Process of updating LSDBs on a P2P link
RouterA RouterB
PPP
LSP
Router A.00-00
PSNP
Router A.00-00
Retransmission
times out
LSP Resend
Router A.00-00 response packet
PSNP
Router A.00-00
1. RouterA establishes a neighbor relationship with RouterB.

2. RouterA and RouterB send a CSNP to each other. If the LSDB of the neighbor and the
received CSNP are not synchronized, the neighbor sends a PSNP to request the required
LSP.
3. Figure 7-8 assumes that RouterB requests the required LSP from RouterA. RouterA sends
the required LSP to RouterB, starts the LSP retransmission timer, and waits for a PSNP
from RouterB as an acknowledgement for the received LSP.
4. If RouterA does not receive a PSNP from RouterB after the LSP retransmission timer
expires, RouterA resends the LSP until it receives a PSNP from RouterB.
NOTE
A PSNP on a P2P link is used as follows:

l An ACK packet to acknowledge the received LSP.
l A request packet to acquire LSPs.
The process of updating LSDBs on a P2P link is as follows:

1. If the sequence number of the received LSP is smaller than that of the corresponding LSP
in the LSDB, the router directly sends its LSP to the neighbor and waits for a PSNP from
the neighbor. If the sequence number of the received LSP is greater than that of the
corresponding LSP in the LSDB, the router adds the received LSP to its LSDB, sends a
PSNP to acknowledge the received LSP, and then sends the received LSP to all its neighbors
except the neighbor that sends the LSP.
2. If the sequence number of the received LSP is the same as that of the corresponding LSP
in the LSDB, the router compares the remaining lifetime of the two LSPs. If the received
LSP has a smaller remaining lifetime than that of the corresponding LSP in the LSDB, the
router adds the received LSP to its LSDB, sends a PSNP to acknowledge the received LSP,
and then sends the received LSP to all its neighbors except the neighbor that sends the LSP.
If the received LSP has a greater remaining lifetime than that of the corresponding LSP in
the LSDB, the router directly sends its LSP to the neighbor and waits for a PSNP from the
neighbor.

Routers
3. If the sequence number and remaining lifetime of the received LSP are the same as those
of the corresponding LSP in the LSDB, the router compares the checksum of the two LSPs.
If the received LSP has a greater checksum than that of the corresponding LSP in the LSDB,
the router adds the received LSP to its LSDB, sends a PSNP to acknowledge the received
LSP, and then sends the received LSP to all its neighbors except the neighbor that sends
the LSP. If the received LSP has a smaller checksum than that of the corresponding LSP
in the LSDB, the router directly sends its LSP to the neighbor and waits for a PSNP from
the neighbor.
4. If the sequence number, remaining lifetime, and checksum of the received LSP and the
corresponding LSP in the LSDB are the same, the router does not forward the received
LSP.
7.2.3 IS-IS Authentication

To ensure network security, IS-IS authentication encrypts IS-IS packets by adding the
authentication field to packets. When a local router receives IS-IS packets from a remote router,
the local router discards the packets if the authentication passwords do not match. This protects
the local router.
Authentication Types
Based on the types of packets, the authentication is classified as follows:
l Interface authentication: authenticates Level-1 and Level-2 Hello packets sent and received
on IS-IS interfaces using the specified authentication mode and password.
NOTE
You can configure a router to perform interface authentication in the following ways:
l A router sends authentication packets carrying the authentication TLV and verifies the
authentication information about the received packets.
l A router sends authentication packets carrying the authentication TLV but does not verify the
authentication information about the received packets.
l Area authentication: authenticates Level-1 LSPs and Level-1 SNPs transmitted in an IS-IS
area using the specified authentication mode and password.
l Routing domain authentication: authenticates Level-2 LSPs and Level-2 SNPs transmitted
in an IS-IS routing domain using the specified authentication mode and password.
NOTE
In area authentication and routing domain authentication, you can configure a router to authenticate
LSPs and SNPs separately in the following ways:
l A router sends LSPs and SNPs carrying the authentication TLV and verifies the authentication
information about the received LSPs and SNPs.
l A router sends LSPs carrying the authentication TLV and verifies the authentication information
about the received LSPs. The router sends SNPs carrying the authentication TLV but does not
verify the authentication information about the received SNPs.
l A router sends LSPs carrying the authentication TLV and verifies the authentication information
about the received LSPs. The router sends SNPs without the authentication TLV and does not
verify the authentication information about the received SNPs.
l A router sends LSPs and SNPs carrying the authentication TLV but does not verify the
authentication information about the received LSPs and SNPs.
Based on the authentication modes of packets, authentication is classified into the following
types:

Routers
l Plain text authentication: is a simple authentication mode in which passwords are directly
added to packets. This authentication is insecure.
l MD5 authentication: uses the MD5 algorithm to encrypt passwords before they are added
to packets, which improves password security.
l Keychain authentication: further improves network security with configurable key chain
that changes with time.
Mode in Which Authentication Information Is Carried

IS-IS provides a TLV to carry authentication information, with the type of the TLV specified as
10.
l Type: is defined by the ISO as 10, with a length of 1 byte.

l Length: indicates the length of the authentication TLV, which is 1 byte.
l Value: indicates the authentication contents of 1 to 254 bytes, including the authentication
type and password.
The authentication type is 1 byte:
Type 0 is reserved.
Type 1 indicates plain text authentication.
Type 54 indicates MD5 authentication.
Type 255 indicates routing domain private authentication methods.
7.2.4 IS-IS Route Leaking

Normally, Level-1 routers manage routes in Level-1 areas. All Level-2 and Level-1-2 routers
form a contiguous backbone area. Level-1 areas can only connect to the backbone area, but
cannot connect to each other.
A Level-1-2 router encapsulates learned Level-1 routing information into a Level-2 LSP and
floods the Level-2 LSP to other Level-2 and Level-1-2 routers. Then Level-1-2 and Level-2
routers know routing information about the entire IS-IS routing domain. To reduce the size of
routing tables, a Level-1-2 router, by default, does not advertise the learned routing information
of other Level-1 areas and the backbone area to its Level-1 area. In this case, Level-1 routers
cannot know routing information outside the local area. As a result, Level-1 routers cannot select
the optimal route to the destination outside the local area.
IS-IS route leaking can solve this problem. You can configure access control lists (ACLs) and
routing policies and mark routes with tags on Level-1-2 routers to select eligible routes. Then a
Level-1-2 router can advertise routing information of other Level-1 areas and backbone area to
its Level-1 area.

Routers
Figure 7-9 IS-IS route leaking
RouterA RouterC
L1 L1/2
cost 50
cost 10
cost 10 cost 10
RouterE RouterF
L2 L2
cost 10 Area20
cost 10
RouterB RouterD
L1 L1/2
Area10
In Figure 7-9, RouterA sends a packet to RouterF. The selected optimal route should be
RouterA->RouterB->RouterD->RouterE->RouterF. This is because the cost of this route is 40,
which is smaller than the cost (70) of the other route (RouterA->RouterC->RouterE->RouterF).
However, when you check the route on RouterA to view the path of the packets sent to RouterF,
the selected route is RouterA->RouterC->RouterE->RouterF but not the optimal route from
RouterA to RouterF.
RouterA (Level-1 router) does not know routes outside its area, so it sends packets outside its
area through the default route generated by the nearest Level-1-2 router. Therefore, the optimal
route is not used to forward the packets.
If route leaking is enabled on Level-1-2 routers (RouterC and RouterD), Level-1 routers in Area
10 can know routes outside Area 10 and passing through the two Level-1-2 routers. After route
calculation, the forwarding path becomes RouterA->RouterB->RouterD->RouterE->RouterF,
which is the optimal route from RouterA to RouterF.
7.2.5 IS-IS Overload

IS-IS Overload allows a device to use the IS-IS overload bit to identify the overload state. The
IS-IS overload bit is the OL field in an IS-IS LSP. After the overload bit is set on a device, other
devices ignore this device when performing SPF calculation and consider only the direct routes
of the device.

Routers
Figure 7-10 IS-IS Overload
RouterD RouterE
1.1.1.0/24
Overload
RouterA RouterC
RouterB
As shown in Figure 7-10, RouterB forwards the packets sent from RouterA to network segment
1.1.1.0/24. If the overload bit in the LSP sent from RouterB is set to 1, RouterA considers the
LSDB of RouterB incomplete and sends packets to 1.1.1.0/24 through RouterD and RouterE.
This process does not affect the packets sent to the directly connected network segment of
RouterB.
If a device cannot store new LSPs and fails to synchronize the LSDB, the routes calculated by
this device are incorrect. In this situation, the device enters the overload state and does not
calculate the routes passing through this device; however, the direct routes of the device are still
valid.
A device may enter the overload state because of device abnormalities or is manually configured
to enter the overload state. When an IS-IS device on the network needs to be upgraded or
maintained, isolate this device from the network temporarily and set the overload bit on the
device to prevent other devices from using this device to forward traffic.
NOTE
l If the system enters the overload state because of an abnormality, the system deletes all the imported
or leaked routes.
l If the system is configured to enter the overload state, the system determines whether to delete all the
imported or leaked routes based on the configuration.
7.2.6 IS-IS Network Convergence

Fast convergence and priority-based convergence can improve IS-IS network convergence. Fast
convergence speeds up network convergence by fast calculating routes, while priority-based
convergence sets different convergence priorities for routes to improve network convergence.
Fast Convergence
IS-IS fast convergence is an extended feature of IS-IS that is implemented to speed up the
convergence of routes. Fast convergence includes the following:
l Incremental SPF (I-SPF): recalculates only the routes of the changed nodes rather than all
the nodes when the network topology changes. This speeds up the calculation of routes.
In ISO 10589, the SPF algorithm is used to calculate routes. When a node changes on the
network, this algorithm is used to recalculate all routes. The calculation takes a long time
and consumes too many CPU resources, which affects the convergence speed.

Routers
I-SPF improves this algorithm. Except for the first time, only changed nodes instead of all
nodes are involved in calculation. The shortest path tree (SPT) generated is the same as
that generated by the previous algorithm. This decreases CPU usage and speeds up network
convergence.
l Partial Route Calculation (PRC): calculates only the changed routes when the routes on the
network change.
Similar to I-SPF, PRC calculates only the changed routes, but it does not calculate the
shortest path. It updates routes based on the SPT calculated by I-SPF.
In route calculation, a leaf represents a route, and a node represents a router. If the SPT
changes after I-SPF calculation, PRC processes all the leaves only on the changed node. If
the SPT remains unchanged, PRC processes only the changed leaves. For example, if IS-
IS is enabled on an interface of a node, the SPT calculated by I-SPF remains unchanged.
PRC updates only the routes of this interface, consuming less CPU resources.
PRC working with I-SPF further improves the convergence performance of the network.
It is an improvement of the original SPF algorithm.
l Intelligent timer: applies to LSP generation and SPF calculation. The first timeout period
of the intelligent timer is fixed. Before the intelligent timer expires, if an event that triggers
the timer occurs, the next timeout period of the intelligent timer increases.
Although the route calculation algorithm is improved, the long interval for triggering route
calculation affects the convergence speed. Frequent network changes also consume too
many CPU resources. The SPF intelligent timer addresses both of these problems. In
general, an IS-IS network is stable under normal conditions. The probability of the
occurrence of many network changes is very minimal, and IS-IS does not calculate routes
frequently. The period for triggering the route calculation is very short (milliseconds). If
the topology of the network changes very often, the intelligent timer increases the interval
for the calculation times to avoid too much CPU consumption. The original mechanism
uses a timer with uniform intervals, which makes fast convergence and low CPU
consumption impossible to achieve.
The LSP generation intelligent timer is similar to the SPF intelligent timer. When the LSP
generation intelligent timer expires, the system generates a new LSP based on the current
topology. The LSP generation timer is designed as an intelligent timer to respond to
emergencies (such as the interface is Up or Down) quickly and speed up the network
convergence.
l LSP fast flooding: speeds up the flooding of LSPs.
In most cases, when an IS-IS router receives new LSPs from other routers, it updates the
LSPs in its LSDB and periodically floods the updated LSPs according to a timer.
LSP fast flooding speeds up LSDB synchronization because it allows a device to flood
fewer LSPs than the specified number before route calculation when the device receives
one or more new LSPs. This mechanism also speeds up network convergence.
Priority-based Convergence
Priority-based IS-IS convergence ensures that specific routes are converged first when a great
number of routes need to be converged. You can assign a high convergence priority to routes
for key services so that these routes are converged quickly. This reduces the impact of route
convergence on key services. Different routes can be set with different convergence priorities
so that important routes can be converged first. This improves network reliability.

Routers
7.2.7 IS-IS Administrative Tag

Administrative tags control the advertisement of IP prefixes in an IS-IS routing domain to
simplify route management. You can use administrative tags to control the import of routes of
different levels and different areas and control IS-IS multi-instances running on the same router.
Figure 7-11 IS-IS networking
RouterD L1
Area2 RouterC
Area3
L1 L1/2 L1/2
L2
L2
Area1
L2 L2
Area5
RouterA L1
L1/2 L1/2
L1 L1
L1
L1
Area4 RouterB
In Figure 7-11, RouterA in Area 4 needs to communicate with RouterB in Area 5, RouterC in
Area 3, and RouterD in Area 2. To ensure information security, it is required that other routers
in Level-1 areas (Areas 2, 3, and 5) should not receive the packets sent from RouterA. To meet
this requirement, configure the same administrative tag for IS-IS interfaces on RouterB,
RouterC, and RouterD and configure the Level-1-2 router in Area 4 to leak only the routes
matching the configured administrative tag from Level-2 to Level-1 areas. This allows RouterA
to communicate with only RouterB, RouterC, and RouterD. Figure 7-12 shows the topology
formed on RouterA.

Routers
Figure 7-12 IS-IS administrative tag application
RouterD L1
Area2 RouterC
Area3
L1/2 L1/2
L2
L2
Area1
L2 L2
Area5
RouterA
L1/2 L1/2
L1
L1
L1
Area4 RouterB
The value of an administrative tag is associated with certain attributes. If the cost-style is wide,
wide-compatible or compatible, when IS-IS advertises an IP address prefix with these attributes,
IS-IS adds the administrative tag to the TLV in the prefix. The tag is flooded along with the
prefix throughout the routing domain.
7.2.8 IS-IS Wide Metric

In ISO 10589, the maximum IS-IS interface metric value can only be 63 and the IS-IS cost style
is narrow. A small range of metrics cannot meet the requirements on large-scale networks.
Therefore, in RFC 3784, the maximum IS-IS interface metric value can reach 16777215, and
the maximum IS-IS route metric value can reach 4261412864; in this case, the IS-IS cost style
is wide.
l The following lists the TLVs used in narrow mode:
TLV 128 (IP Internal Reachability TLV): carries IS-IS routes in a routing domain.
TLV 130 (IP External Reachability TLV): carries IS-IS routes outside a routing domain.
TLV 2 (IS Neighbors TLV): carries neighbor information.
l The following lists the TLVs used in wide mode:
TLV 135 (Extended IP Reachability TLV): replaces the earlier IP reachability TLV and
carries IS-IS routing information. This TLV expands the route metric and carries sub-
TLVs.
TLV 22 (IS Extended Neighbors TLV): carries neighbor information.
Table 7-2 lists the cost styles of received and sent IS-IS routing information. The cost styles of
received and sent IS-IS routing information vary according to the cost style configured on a
device.

Routers
Table 7-2 Cost styles of received and sent IS-IS routing information
Cost Style Configured Cost Style for Received Cost Style for Sent IS-IS
on a Device IS-IS Routing Routing Information
Information
narrow narrow narrow
narrow-compatible narrow&wide narrow
compatible narrow&wide narrow&wide
wide-compatible narrow&wide wide
wide wide wide
NOTE
When the cost-style is set to compatible, IS-IS sends the information in narrow mode and then in wide
mode.
IS-IS in wide mode and IS-IS in narrow mode cannot communicate. If IS-IS in wide mode and IS-IS in
narrow mode need to communicate, you must change the mode to enable all routers on the network to
receive packets sent by other routers.
7.2.9 IS-IS LSP Fragment Extension

When an IS-IS router needs to advertise the LSPs that contain much information, the IS-IS router
generates multiple LSP fragments to carry more IS-IS information.
IS-IS LSP fragments are identified by the LSP Number field in their LSP IDs. This field is of 1
byte. An IS-IS process can generate a maximum of 256 LSP fragments; therefore, only a limited
number of routes can be carried.
As defined in RFC 3786, virtual system IDs can be configured and virtual LSPs that carry routing
information can be generated for IS-IS.
Concepts
l Originating system: is a router that runs the IS-IS protocol. A single IS-IS process can
function as multiple virtual routers to advertise LSPs, and the originating system refers to
the IS-IS process.
l Normal System-ID: is the system ID of the originating system.
l Virtual System: is the system identified by the additional system ID to generate extended
LSP fragments. These fragments carry additional system IDs in their LSP IDs.
l Additional System-ID: is assigned by network administrators to identify a virtual system.
A maximum of 256 extended LSP fragments can be generated for each additional system
ID.
NOTE
Like a normal system ID, an additional system ID must be unique in a routing domain.
l TLV 24 (IS Alias ID TLV): describes the relationship between the originating system and
virtual system.

Routers
Principles
In IS-IS, each system ID identifies a system, which can generate a maximum of 256 LSP
fragments. With more additional system IDs (up to 50 virtual systems can be configured), an
IS-IS process can generate a maximum of 13,056 LSP fragments.
After LSP fragment extension is configured, the system prompts you to restart the IS-IS process
if information is lost because LSPs overflow. After being restarted, the originating system loads
as much routing information to LSPs, adds the overloaded information to the LSPs of the virtual
system for transmission, and uses TLV 24 to notify other routers of its relationship with the
virtual system.
Operating Modes
An IS-IS router can run the LSP fragment extension feature in two modes.
Figure 7-13 IS-IS LSP fragment extension
RouterA1
RouterB RouterA
RouterA2

Routers
O Usag Principles Example Precautions

pe e
rat Scena
in rio
g
M
od
e
M Some Virtual systems In Figure 7-13, The LSP sent by a

od router participate in SPF RouterB does not virtual system contains
e-1 s on calculation. The support LSP fragment the same area address
the originating system extension, and RouterA and overload bit as
netwo advertises LSPs is configured to support those in a common LSP.
rk do containing information LSP fragment extension If the LSPs sent by a
not about links to each in mode-1. RouterA1 virtual system contain
suppor virtual system. and RouterA2 are TLVs specified in other
t LSP Similarly, each virtual virtual systems of features, these TLVs
fragm system advertises LSPs RouterA and send LSPs must be the same as
ent containing information carrying some routing those in common LSPs.
extens about links to the information of RouterA. The virtual system
ion. originating system. After receiving LSPs carries neighbor
Virtual systems look from RouterA, information indicating
like the physical routersRouterA1, and that the neighbor is the
that connect to the RouterA2, RouterB originating system, with
originating system. considers that there are the metric equal to the
Mode-1 is a transitional three individual routers maximum value minus
mode for the earlier at the remote end and 1. The originating
versions that do not calculates routes. system carries neighbor
support LSP fragment Because the cost of the information indicating
extension. In earlier route from RouterA to that the neighbor is the
versions, IS-IS cannot RouterA1 and the cost virtual system, with the
identify the IS Alias ID of the route from metric 0. This ensures
TLV and processes the RouterA to RouterA2 that the virtual system is
received LSP that is are both 0, the cost of the the downstream node of
advertised by a virtual route from RouterB to the originating system
system as an LSP RouterA is the same as when other routers
advertised by an IS-IS the cost of the route calculate routes.
process. from RouterB to
RouterA1.

Routers
O Usag Principles Example Precautions

pe e
rat Scena
in rio
g
M
od
e
M All the Virtual systems do not In Figure 7-13, -

od router participate in SPF RouterB supports LSP
e-2 s on calculation. All the fragment extension, and
the routers on the network RouterA is configured
netwo know that the LSPs to support LSP fragment
rk generated by virtual extension in mode-2.
suppor systems actually belong RouterA1 and
t LSP to the originating RouterA2 are virtual
fragm system. systems of RouterA and
ent An IS-IS router send LSPs carrying
extens working in mode-2 can some routing
ion. identify the IS Alias ID information of RouterA.
TLV, which is used as a When receiving LSPs
reference for from RouterA1 and
calculating the SPT and RouterA2, RouterB
routes. obtains the IS Alias ID
TLV and knows that the
originating system of
RouterA1 and
RouterA2 is RouterA.
RouterB then considers
that information
advertised by RouterA1
and RouterA2 belongs
to RouterA.
NOTE
When the originating system and virtual system send the LSPs with fragment number 0, the LSPs must
carry the IS Alias ID TLV to indicate the originating system regardless of the operation mode (mode-1 or
mode-2).
7.2.10 IS-IS Host Name Mapping

The IS-IS host name mapping mechanism maps host names to system IDs for IS-IS devices,
including dynamic host name mapping and static host name mapping. Dynamic host name
mapping takes precedence over static host name mapping. When both a dynamic host name and
a static host name are configured, the dynamic host name takes effect.
On an IS-IS router where host name exchange is disabled, information about IS-IS neighbors
and LSDBs shows that each device in an IS-IS routing domain is identified by a system ID with
12-digit hexadecimal number, for example, aaaa.eeee.1234. This device identification method

Routers
is complex and not easy to use. The host name exchange mechanism facilitates IS-IS network
management and maintenance.
The system ID is replaced by a host name in the following situations:

l When an IS-IS neighbor is displayed, the system ID of the IS-IS neighbor is replaced by
its host name. When the neighbor is the DIS, the system ID of the DIS is also replaced by
its host name.
l When an LSP in the IS-IS LSDB is displayed, the system ID in the LSP ID is replaced by
the host name of the IS-IS device that advertises the LSP.
l When details about the IS-IS LSDB are displayed, the Host Name field is added to the LSP
generated by the device where dynamic host name exchange is enabled, and the system ID
in the Host Name field is replaced by the dynamic host name of the device that generates
the LSP.
Dynamic Host Name Mapping

On a device where dynamic host name mapping is enabled, dynamic host name information is
advertised as TLV 137 (Dynamic Hostname TLV) in LSPs. When you run IS-IS commands on
other devices to view IS-IS information, the system ID of the local device is replaced by the
configured host name. The host name is easier to identify and memorize than the system ID.
The Dynamic Hostname TLV is optional and can be inserted anywhere in an LSP. The value of
this TLV cannot be empty. A device can determine whether to send LSPs carrying TLV 137,
while the device that receives LSPs can determine whether to ignore TLV 137 or whether to
obtain TLV 137 for its mapping table.
Static Host Name Mapping

Static host name mapping allows you to configure the mapping between host names and system
IDs of other IS-IS devices on a device. Static host name mapping takes effect only on the local
device and is not advertised using LSPs.
7.2.11 IS-IS GR
IS-IS graceful restart (GR) is a high availability technology that implements non-stop data
forwarding.
After the master/slave switchover, no neighbor information is stored on the restarted router. The
first Hello packets sent by the router after restart do not contain the neighbor list. After receiving
the Hello packets, the neighbor checks the two-way neighbor relationship and detects that it is
not in the neighbor list of the Hello packets sent by the router. The neighbor relationship is
interrupted. The neighbor then generates new LSPs and floods the topology changes to all other
routers in the area. Routers in the area calculate routes based on the new LSDBs, which leads
to route interruption or routing loops.
The IETF defined the GR standard, RFC 3847, for IS-IS. The restart of the protocol is processed
for both the reserved FIB tables and unreserved FIB tables. Therefore, the route flapping and
interruption of the traffic forwarding caused by the restart can be avoided.
Concepts
IS-IS GR involves two roles, namely, GR restarter and GR helper.

Routers
l GR restarter: is a device that has the GR capability and restarts in GR mode.

l GR helper: is a device that has the GR capability and helps the GR restarter complete the
GR process. The GR restarter must have the GR helper capability.
To implement GR, IS-IS uses TLV 211 (restart TLV) and three timers, T1, T2, and T3.
Restart TLV
The restart TLV is an extended part of an IS-to-IS Hello (IIH) PDU. All IIH packets of the router
that supports IS-IS GR contain the restart TLV. The restart TLV carries the parameters for the
protocol restart. Figure 7-14 shows the format of the restart TLV.
Figure 7-14 Restart TLV
0 1 2 3 4 5 6 7
Type(211)
Length(1 to 9)
Reserved SA RA RR
Remaining Time
Table 7-3 describes the fields of the restart TLV.
Table 7-3 Restart TLV fields
Field Length Description
Type 1 byte TLV type. Type value 211 indicates the restart TLV.
Length 1 byte Length of value in the TLV.
RR 1 bit Restart request bit. A router sends an RR packet to notify the

neighbors of its restarting or starting and to require the
neighbors to retain the current IS-IS adjacency and return
CSNPs.
RA 1 bit Restart acknowledgement bit. A router sends an RA packet to

respond to the RR packet.
SA 1 bit Suppress adjacency advertisement bit. The starting router uses

an SA packet to require its neighbors to suppress the broadcast
of their neighbor relationships to prevent routing loops.
Remaining 2 bytes Time during which the neighbor does not reset the adjacency.
Time The length of the field is 2 bytes. The time is measured in
seconds. When RA is reset, the value is mandatory.

Routers
Timers
Three timers are introduced to enhance IS-IS GR: T1, T2, and T3.
l T1: If the GR restarter has already sent an IIH packet with RR being set but does not receive
any IIH packet that carries the restart TLV and the RA set from the GR helper even after
the T1 timer expires, the GR restarter resets the T1 timer and continues to send the restart
TLV. If the ACK packet is received or the T1 timer expires three times, the T1 timer is
deleted. The default value of a T1 timer is 3 seconds.
Any interface enabled with IS-IS GR maintains a T1 timer. On a Level-1-2 router, broadcast
interfaces maintain a T1 timer for Level-1 and Level-2 neighbor relationships.
l T2: is the time from when the GR restarter restarts until the LSDBs of all devices of the
same level are synchronized. T2 is the maximum time that the system waits for
synchronization of all LSDBs. T2 is generally 60 seconds.
Level-1 and Level-2 LSDBs maintain their respective T2 timers.
l T3: is the maximum time during which the GR restarter performs GR. The T3 initial value
is 65535 seconds. After the IIH packets that carry the RA are received from neighbors, the
T3 value becomes the smallest value among the Remaining Time fields of the IIH packets.
If the T3 timer expires, GR fails.
The entire system maintains a T3 timer.
Session Mechanism
For differentiation, GR triggered by the master/slave switchover or the restart of an IS-IS process
is referred to as restarting. In restarting, the FIB table remains unchanged. GR triggered by router
restart is referred to as starting. In starting, the FIB table is updated.
The following describes the process of IS-IS GR in restarting and starting modes:
l Figure 7-15 shows the process of IS-IS restarting.

Routers
Figure 7-15 IS-IS restarting
GR Restarter GR Helper
Active/standby
switchover
Start T1, T2, IIH (Restart TLV, RR=1, RA=0, SA=0)

and T3 timers
IIH (Restart TLV, RR=0, RA=1, SA=0)

Reset T3 timer
CSNP
Delete T1 timer
LSPs
Delete T2 timer
Flood LSPs Update

Delete T3 timer and
the
Update the FIB table
FIB table
1. After performing the protocol restart, the GR restarter performs the following actions:
Starts T1, T2, and T3 timers.
Sends IIH packets that contain the restart TLV from all interfaces. In such a packet,
RR is set to 1, and RA and SA are set to 0.
2. After receiving an IIH packet, the GR helper performs the following actions:
Maintains the neighbor relationship and refreshes the current Holdtime.
Replies with an IIH packet containing the restart TLV. In the packet, RR is set to
0; RA is set to 1, and the value of the Remaining Time field indicates the period
from the current moment to the timeout of the Holdtime.
Sends CSNPs and all LSPs to the GR restarter.
NOTE
On a P2P link, a neighbor must send CSNPs.

On a LAN link, only the neighbor of the DIS sends CSNPs. If the DIS is restarted, a temporary
DIS is elected from the other routers on the LAN.
If the neighbor does not have the GR helper capability, it ignores the restart TLV and
resets the adjacency with the GR restarter according to normal IS-IS processing.
3. After the GR restarter receives the IIH response packet, in which RR is set to 0 and
RA is set to 1, from the neighbor, it performs the following actions:
Compares the current value of the T3 timer with the value of the Remaining Time
field in the packet. The smaller value is taken as the value of the T3 timer.

Routers
Deletes the T1 timer maintained by the interface that receives the ACK packet and
CSNPs.
If the interface does not receive the ACK packet or CSNPs, the GR restarter
constantly resets the T1 timer and resends the IIH packet that contains the restart
TLV. If the number of timeouts of the T1 timer exceeds the threshold value, the
GR restarter forcibly deletes the T1 timer and turns to the normal IS-IS processing
to complete LSDB synchronization.
4. After the GR restarter deletes the T1 timers on all interfaces, the synchronization with
all neighbors is complete when the CSNP list is cleared and all LSPs are collected.
The T2 timer is then deleted.
5. After the T2 timer is deleted, the LSDB of the level is synchronized.
In the case of a Level-1 or Level-2 router, SPF calculation is triggered.
In the case of a Level-1-2 router, determine whether the T2 timer on the router of
the other level is also deleted. If both T2 timers are deleted, SPF calculation is
triggered. Otherwise, the router waits for the T2 timer of the other level to expire.
6. After all T2 timers are deleted, the GR restarter deletes the T3 timer and updates the
FIB table. The GR restarter re-generates the LSPs of each level and floods them.
During LSDB synchronization, the GR restarter deletes the LSPs generated before
restarting.
7. At this point, the IS-IS restarting of the GR restarter is complete.
l The starting device does not retain the FIB table. The starting device depends on the
neighbors, whose adjacency with itself is Up before it starts, to reset their adjacency and
suppress the neighbors from advertising their adjacency. The IS-IS starting process is
different from the IS-IS restarting process, as shown in Figure 7-16.

Routers
Figure 7-16 IS-IS starting

GR Restarter GR Helper
Starting
Start T2 timer for IIH (Restart TLV, RR=0, RA=0, SA=1)

various LSPDBs
Reestablish the adjacency relationship
Start T1 timer
CSNP
Delete T1 timer
LSPs
Delete T2 timer
Update the Flood LSPs Update the

FIB table FIB table
1. After the GR restarter is started, it performs the following actions:

Starts the T2 timer for the synchronization of LSDBs of each level.
Sends IIH packets that contain the restart TLV from all interfaces.
If RR in the packet is set to 0, a router is started.
If SA in the packet is set to 1, the router requests its neighbor to suppress the
advertisement of their adjacency before the neighbor receives the IIH packet in
which SA is set to 0.
2. After the neighbor receives the IIH packet that carries the restart TLV, it performs the
following actions depending on whether GR is supported:
GR is supported.
Re-initiates the adjacency.
Deletes the description of the adjacency with the GR restarter from the sent LSP.
The neighbor also ignores the link connected to the GR restarter when performing
SPF calculation until it receives an IIH packet in which SA is set to 0.
GR is not supported.
Ignores the restart TLV and resets the adjacency with the GR restarter.
Replies with an IIH packet that does not contain the restart TLV. The neighbor
then returns to normal IS-IS processing. In this case, the neighbor does not suppress

Routers
the advertisement of the adjacency with the GR restarter. On a P2P link, the
neighbor also sends a CSNP.
3. After the adjacency is re-initiated, the GR restarter re-establishes the adjacency with
the neighbors on each interface. When an adjacency set on an interface is in the Up
state, the GR restarter starts the T1 timer for the interface.
4. After the T1 timer expires, the GR restarter sends an IIH packet in which both RR and
SA are set to 1.
5. After the neighbor receives the IIH packet, it replies with an IIH packet, in which RR
is set to 0 and RA is set to 1, and sends a CSNP.
6. After the GR restarter receives the IIH ACK packet and CSNP from the neighbor, it
deletes the T1 timer.
If the GR restarter does not receive the IIH packet or CSNP, it constantly resets the
T1 timer and resends the IIH packet in which RR and SA are set to 1. If the number
of the timeouts of the T1 timer exceeds the threshold value, the GR restarter forcibly
deletes the T1 timer and turns to the normal IS-IS processing to complete LSDB
synchronization.
7. After receiving the CSNP from the helper, the GR restarter synchronizes the LSDB.
8. After the LSDB of this level is synchronized, the T2 timer is deleted.
9. After all T2 timers are deleted, the SPF calculation is started and LSPs are regenerated
and flooded.
10. At this point, the IS-IS starting of the GR restarter is complete.
7.2.12 BFD for IS-IS

In IS-IS, the interval for sending Hello packets is 10s, and the holddown time for keeping the
neighbor relationship is three times the interval for sending Hello packets. If a router does not
receive a Hello packet from its neighbor within the holddown time, the router deletes the
corresponding neighbor relationship. This indicates that the router detects neighbor faults in
seconds. Second-level fault detection, however, may result in heavy packet loss on high-speed
networks.
Bidirectional forwarding detection (BFD) provides light-load and millisecond-level link fault
detection to prevent heavy packet loss. BFD is not used to substitute the Hello mechanism of
IS-IS but helps IS-IS rapidly detect the faults on neighbors or links and instructs IS-IS to
recalculate routes for packet forwarding.
In Figure 7-17, basic IS-IS functions are configured on every router, and BFD for IS-IS is
enabled on RouterA and RouterB.
Figure 7-17 BFD for IS-IS

Router A Router D Router B
Primary Path
Backup Path
Probed Path
Router C

Routers
When a fault occurs on the primary link, BFD fast detects the fault and reports it to IS-IS. IS-IS
sets the neighbors of the interface on the faulty link to Down, which triggers topology calculation,
and updates LSPs so that neighbors such as RouterC can receive the updated LSPs from RouterB.
This process implements fast network convergence.
Classification of BFD for IS-IS

BFD for IS-IS includes static BFD for IS-IS and dynamic BFD for IS-IS.
Table 7-4 Two implementation modes for BFD for IS-IS
Impleme Principles Differences

ntation
Mode
Static BFD BFD session parameters, including l Static BFD can be manually
for IS-IS local and remote discriminators, controlled and is easy to deploy. To
are manually configured using save memory and ensure reliability of
commands, and the requests for key links, deploy BFD on specified
establishing BFD sessions are links.
manually delivered. l Establishing and deleting BFD
sessions need to be manually triggered
and lack flexibility. Configuration
errors may occur. For example, if an
incorrect local or remote
discriminator is configured, a BFD
session cannot work properly.
Dynamic BFD sessions are dynamically Dynamic BFD is more flexible than static
BFD for created but not manually BFD. In dynamic BFD, routing protocols
IS-IS configured. When detecting faults, trigger the setup of BFD sessions,
BFD informs IS-IS of the faults preventing the configuration errors
through the routing management caused by manual configuration.
(RM) module. IS-IS then turns the Dynamic BFD is easy to configure and
neighbors Down, rapidly applies to the scenarios where BFD needs
advertises the changed LSPs, and to be configured on the entire network.
performs incremental SPF. This
implements fast route
convergence.
NOTE
BFD uses local and remote discriminators to differentiate multiple BFD sessions between the same pair of
systems.
Because IS-IS establishes only single-hop neighbors, BFD for IS-IS detects only single-hop links between
IS-IS neighbors.

Routers
Establishment and Deletion of BFD Sessions

The RM module provides related services for association with the BFD module for IS-IS.
Through RM, IS-IS prompts BFD to set up or tear down BFD sessions by sending notification
messages. In addition, BFD events are transmitted to IS-IS through RM.
Conditions for setting up a BFD session

l Basic IS-IS functions are configured on each router and IS-IS is enabled on the interfaces
of the routers.
l BFD is globally enabled on each router, and BFD is enabled on a specified interface or
process.
l BFD is enabled on interfaces or processes, and the neighbors are Up. A DIS needs to be
elected on a broadcast network.
Process of setting up a BFD session
l P2P network
After the conditions for setting up a BFD session are satisfied, IS-IS instructs BFD through
RM to directly set up a BFD session between neighbors.
l Broadcast network
After the conditions for establishing BFD sessions are met, and the DIS is elected, IS-IS
instructs BFD through RM to establish a BFD session between the DIS and each router.
No BFD session is established between non-DISs.
NOTE
On a broadcast network, routers (including non-DIS routers) of the same level on a network segment
can establish neighbor relationships. In the implementation of BFD for IS-IS, however, BFD sessions
are established only between a DIS and a non-DIS. On a P2P network, BFD sessions are directly
established between neighbors.
If a Level-1-2 neighbor relationship is set up between two routers on a link, IS-IS sets up two BFD
sessions for the Level-1 and Level-2 neighbors on a broadcast network, but sets up only one BFD
session on a P2P network.
Conditions for tearing down a BFD session
l P2P network
When a neighbor relationship that was set up on P2P interfaces by IS-IS is down (that is,
the neighbor relationship is not in the Up state) or when the IP protocol type of a neighbor
is deleted, IS-IS tears down the BFD session.
l Broadcast network
When a neighbor relationship that was set up on P2P interfaces by IS-IS is torn down (that
is, the neighbor relationship is not in the Up state), when the IP protocol type of a neighbor
is deleted, or when the DIS is re-elected, IS-IS tears down the BFD session.
NOTE
After dynamic BFD is globally disabled in an IS-IS process, the BFD sessions on all the interfaces in this
IS-IS process are deleted.
IS-IS Responding to BFD Session Down Event

When detecting a link failure, BFD generates a Down event, and then notifies RM of the event.
RM then instructs IS-IS to deletes the neighbor relationship. IS-IS recalculates routes to speed
up route convergence on the entire network.

Routers
When both the local router and its neighbor are Level-1-2 routers, they establish two neighbors
of different levels. Then IS-IS establishes two BFD sessions for the Level-1 neighbor and Level-2
neighbor respectively. When BFD detects a link failure, it generates a Down event and informs
the RM module of the event. The RM module then instructs IS-IS to delete the neighbor
relationship of a specific level.
7.2.13 IS-IS Auto FRR

With the development of networks, the services such as Voice over IP (VoIP) and online video
services require high-quality real-time transmission. Nevertheless, if an IS-IS link fault occurs,
traffic can be switched to a new link only after the processes, including fault detection, LSP
update, LSP flooding, route calculation, and FIB entry delivery, are complete. As a result, it
takes much more than 50 ms to rectify the fault, which cannot meet the requirement for real-
time transmission services on the network.
Complying with RFC 5286 (Basic Specification for IP Fast Reroute Loop-Free Alternates), IS-
IS Auto FRR protects traffic when links or nodes become faulty. IS-IS Auto FRR allows the
forwarding system to rapidly detect such faults and take measures to restore services as soon as
possible.
In most cases, you can bind BFD to IS-IS Auto FRR to ensure that the fault recovery time is
within 50 ms. When BFD detects a link fault on an interface, the BFD session goes Down,
triggering FRR on the interface. Subsequently, traffic is switched from the faulty link to the
backup link, which protects services.
Principles
IS-IS Auto FRR pre-computes a backup link by using the Loop-Free Alternate (LFA) algorithm,
and then adds the backup link and the primary link to the forwarding table. In the case of an IS-
IS network failure, IS-IS Auto FRR can fast switch traffic to the backup link before routes on
the control plane converge. This ensures normal transmission of traffic and improves the
reliability of the IS-IS network.
The backup link is calculated through the LFA algorithm. With the neighbor that can provide
the backup link being the root, the shortest path to the destination node is calculated by a device
through the SPF algorithm. Then, the loop-free backup link is calculated according to the
inequality defined in RFC 5286.
IS-IS Auto FRR can filter backup routes that need to be added to the IP routing table. Only the
backup routes matching the filtering policy are added to the IP routing table. In this manner,
users can flexibly control the addition of IS-IS backup routes to the IP routing table.
Applications
IS-IS Auto FRR support traffic engineering (TE) links, including the following types:
l IP protecting TE
As shown in Figure 7-18, the TE tunnel has the smallest IS-IS cost among the paths from
RouterS to RouterD. Therefore, RouterS selects the TE tunnel as the primary path to
RouterD. The path RouterS->RouterN->RouterD has the second smallest cost. According
to the LFA algorithm, RouterS selects the path RouterS->RouterN->RouterD as the backup
path. The outbound interface of the backup path is the interface that connects RouterS to
RouterN.

Routers
NOTE
If the outbound interface of the backup link is the actual outbound interface of the TE tunnel, IP
protecting TE fails.
Figure 7-18 IP protecting TE

RouterS TE Tunnel: IS-IS cost = 1 RouterD
IS-IS cost = 13
IS
-IS
co
1
t=
st
s
=
co
10
-IS
IS
RouterN
Traffic in normal
Traffic in case of failure
l TE protecting IP
As shown in Figure 7-19, the physical path RouterS-->RouterN-->RouterD has the
smallest IS-IS metric among the paths from RouterS to RouterD. Therefore, RouterS prefers
the path RouterS-->RouterN-->RouterD as the primary path from RouterS to RouterD. The
IS-IS cost of the TE tunnel is 12, and the explicit path of the TE tunnel is the direct link
from RouterS to RouterD. The IS-IS metric of the direct link from RouterS to RouterD is
13, which is greater than the IS-IS metric of the TE tunnel. Therefore, IS-IS selects the TE
tunnel as the backup path. TE protecting IP is implemented.
Figure 7-19 TE protecting IP

RouterS TE Tunnel: IS-IS cost = 12 RouterD
IS-IS cost = 13
IS
1
-IS
=
st
co
co
st
-IS
=
IS
10
RouterN
Traffic in normal

Routers
IS-IS Auto FRR traffic protection is classified into link protection and link-node dual protection.
Figure 7-20 IS-IS Auto FRR link protection
cost = 10
RouterS co RouterD
st
10
=
=
10
st
co
RouterN
Figure 7-21 IS-IS Auto FRR link-node dual protection

RouterE
co
st
5
=
=
st
10
co
RouterS co RouterD
st
10
=
=
10
st
co
RouterN

Routers
Table 7-5 IS-IS Auto FRR traffic protection

Tra Object Condition Application Example
ffic Protecte
Pro d
tec
tio
n
Ty
pe
Lin Traffic The link cost must satisfy the following In Figure 7-20, traffic is
k passing inequality: transmitted from RouterS to
pro through a Distance_opt(N,D) < Distance_opt(N,S) RouterD. The link cost
tect specific + Distance_opt(S,D) satisfies the link protection
ion link inequality. When the primary
link fails, RouterS switches
the traffic to the backup link
RouterS->RouterN so that the
traffic can be further
transmitted along
downstream paths. This
ensures that the traffic
interruption time is within 50
ms.
Lin Next-hop Link-node dual protection must satisfy the In Figure 7-21, traffic is
k- node or following conditions: transmitted along the path
nod link from l The link cost must satisfy the RouterS->RouterE-
e the local following inequality: >RouterD. The link cost
dua node to satisfies the link protection
l the next- Distance_opt(N,D) < Distance_opt inequality. When RouterE or
pro hop node. (N,S) + Distance_opt(S,D) the link between RouterS and
tect Node l The interface cost of the router must RouterE fails, RouterS
ion protectio satisfy the following inequality: switches the traffic to the
n takes Distance_opt(N,D) < Distance_opt backup link RouterS-
preceden (N,E) + Distance_opt(E,D) >RouterN so that the traffic
ce over can be further transmitted
link along downstream paths. This
protectio ensures that the traffic
n. interruption time is within 50
ms.
NOTE
In Table 7-5, Distance_opt(X,Y) indicates the cost of the optimal path between node X and node Y. S
indicates the source node of traffic; E indicates the faulty node; N indicates the node on the backup link;
D indicates the destination node of traffic.
7.2.14 IS-IS TE
Traditional routers select the shortest path as the master route regardless of other factors, such
as bandwidth. In this manner, the traffic is not switched to other paths even if a path is congested.

Routers
MPLS traffic engineering (TE) has advantages in solving the problem of network congestion.
With MPLS TE, you can precisely control the traffic path and prevent traffic from passing
through congested nodes. Meanwhile, MPLS TE can reserve resources to ensure the quality of
services during the establishment of LSPs.
To ensure the continuity of services, MPLS TE introduces the LSP backup and fast reroute (FRR)
mechanisms. When faults occur on the link, the traffic can be switched immediately. Through
MPLS TE, service providers (SPs) can fully utilize the current network resources to provide
diversified services, optimize network resources, and scientifically manage the network.
To achieve the preceding purpose, MPLS needs to learn TE information of all routers in this
network. MPLS TE lacks such a mechanism through which each router floods its TE information
in the entire network to implement the synchronization of TE information. This mechanism is
provided by the IS-IS protocol. Therefore, MPLS TE can advertise and synchronize TE
information with the help of the IS-IS protocol.
IS-IS TE is an extension of IS-IS to support MPLS TE and complies with RFC 5305 and RFC
4205. IS-IS TE defines new TLVs in IS-IS LSPs to carry TE information and floods LSPs to
flood and synchronize TE information. It extracts TE information from all LSPs and then
transmits the TE information to the Constraint Shortest Path First (CSPF) module of MPLS for
tunnel path calculation. IS-IS TE plays the role of a porter in MPLS TE. Figure 7-22 shows the
relationships between IS-IS TE, MPLS TE, and CSPF.
Figure 7-22 Relationships between MPLS TE, CSPF, and IS-IS TE
MPLS TE
TE management
feedback advertising
and adjust
CSPF IS-IS TE
calculating TE Flooding TE
collecting
New TLVs in IS-IS TE

To carry TE information in LSPs, IS-IS TE defines the following TLVs in RFC 5305:
l Extended IS reachability TLV

This TLV takes the place of IS reachability TLV and extends the TLV formats with sub-
TLVs. Sub-TLVs are implemented in TLVs in the same manner as TLVs are implemented
in LSPs. Sub-TLVs are used to carry TE information configured on physical interfaces.
NOTE
Currently, all sub-TLVs defined in RFC 5305 and sub-TLV type 22 defined in RFC 4124 are
supported.

Routers
Table 7-6 Sub-TLVs defined in Extended IS reachability TLV
Name Typ Length (Byte) Value

e
Administrative Group 3 4 Indicates the administrative

group.
IPv4 Interface Address 6 4 Indicates the IPv4 address of

a local interface.
IPv4 Neighbour Address 8 4 Indicates the IPv4 address of

a neighbor interface.
Maximum Link Bandwidth 9 4 Indicates the maximum

bandwidth of a link.
Maximum Reserved Link 10 4 Indicates the maximum

Bandwidth reserved bandwidth of a link.
Unreserved Bandwidth 11 32 Indicates the unreserved

bandwidth.
Traffic Engineering Default 18 3 Indicates the default metric

Metric of TE.
Bandwidth Constraints sub- 22 36 Indicates the TLV of the

TLV bandwidth constraint.
l Traffic Engineering router ID TLV

It is of TLV type 134, with a 4-byte Router ID. It is used as the MPLS LSR ID. In MPLS
TE, a Router ID uniquely identifies a router. Each router has a Router ID.
l Extended IP reachability TLV
This TLV takes the place of IP reachability TLV and carries routing information. It extends
the length of the route cost field and carries sub-TLVs.
l Shared Risk Link Group TLV
It is of TLV type 138 and used to carry information about the shared risk link group. This
TLV can carry information about multiple shared links, each of which is a 4-byte positive
integer.
IS-IS TE Implementation
IS-IS TE is implemented in two processes.
l Process of responding to MPLS TE configurations.

IS-IS TE functions only after MPLS TE is enabled.
IS-IS TE updates the TE information in IS-IS LSPs based on MPLS TE configurations.
IS-IS TE transmits MPLS TE configurations to the CSPF module.
l Process of handling TE information in LSPs.

Routers
IS-IS TE extracts TE information from IS-IS LSPs and transmits the TE information to the
CSPF module.
In typical applications, IS-IS TE helps MPLS TE set up TE tunnels. As shown in Figure 7-23,
a TE tunnel is set up between RouterA and RouterD.
Figure 7-23 IS-IS TE networking

RouterB
RouterA RouterC
Tunnel
RouterD
The networking configuration is as follows:
l Enable MPLS TE on RouterA, RouterB, RouterC, and RouterD and enable MPLS TE CSPF
on RouterA to calculate the tunnel path.
l Run IS-IS and enable IS-IS TE on RouterA, RouterB, RouterC, and RouterD to implement
communication between the four routers.
After the preceding configuration is complete, IS-IS on RouterA, RouterB, RouterC, and
RouterD sends LSPs carrying TE information configured on each router. RouterA then obtains
the TE information of RouterB, RouterC, and RouterD from the received LSPs. The CSPF
module can calculate the path required by the TE tunnel based on the TE information on the
entire network.
Route Calculation on TE Tunnel Interfaces

IS-IS Shortcut (AA) and IS-IS Advertise (FA) calculate routes through TE tunnel interfaces. For
the traffic transmitted through a specific route, MPLS guarantees the forwarding comparing with
IP, which is unreliable. When IS-IS Shortcut (AA) and IS-IS Advertise (FA) are configured,
MPLS forwarding is achieved with TE tunnel interfaces involving in route calculation and being
the outbound interfaces of specific routes.

Routers
Figure 7-24 Principle of IS-IS Shortcut (AA) and Advertise (FA)

TE tunnel FA 10
10 10 10 10
RouterE RouterA RouterB RouterC RouterD

5
RouterT
IS-IS Shortcut (AA) and IS-IS Advertise (FA) have the following differences:
l IS-IS Advertise (FA) advertises TE tunnel information to other ISs, whereas IS-IS Shortcut
(AA) does not.
As shown in Figure 7-24, if the TE tunnel is enabled with IS-IS Advertise (FA), RouterA
advertises information indicating that RouterC is its neighbor. The neighbor information
is carried in TLV type 22 with no sub-TLVs. That is, no TE information is carried. If the
TE tunnel is enabled with IS-IS Shortcut (AA), RouterA does not advertise such
information.
l IS-IS Advertise (FA) affects the SPF tree of other routers, whereas IS-IS Shortcut (AA)
does not.
IS-IS Shortcut (AA) does not affect the original structure of the IS-IS SPF tree, irrespective
of whether a TE tunnel exists or not. Apart from the link from RouterA to RouterB, and
that from RouterB to RouterC, a link marked with an Shortcut from RouterA to RouterC
is added. The link marked with an Shortcut participates in route calculation.
If the TE tunnel is enabled with IS-IS Advertise (FA), RouterA advertises the message that
"RouterC is a neighbor of RouterA" to other routers on the network. Other routers then
consider RouterC a neighbor of RouterA and add RouterC to the SPF tree without marking
it with an Shortcut.
l IS-IS Advertise (FA) does not support a relative metric, whereas IS-IS Shortcut (AA)
supports.
IS-IS Shortcut (AA) supports an absolute metric and a relative metric.
If you use an absolute metric, the metric value of TE tunnels in IS-IS is fixed. If you use a
relative metric, the metric value of TE tunnels in IS-IS is the sum of the physical link cost
and relative metric. As shown in Figure 7-24, if the relative metric is set to 1, the cost of
the path from SwitchA to SwitchC through the TE tunnel is 21 (10+10+1). If the relative
metric is set to 0, the TE tunnel and physical link are of equal-cost on the outbound interface.
If the relative metric is less than 0, the TE tunnel interface is preferred as the outbound
interface.
l IS-IS Advertise (FA) requires bidirectional TE tunnels, whereas IS-IS Shortcut (AA)
requires only unidirectional tunnels.

Routers
7.2.15 IS-IS Multi-Instance and Multi-Process

On a VPN-supporting device, you can associate multiple VPN instances with multiple IS-IS
processes to implement IS-IS multi-instance. IS-IS multi-process allows you to create multiple
IS-IS processes in the same VPN (or on the public network). These IS-IS processes are
independent of each other. Route exchange between IS-IS processes is similar to route exchange
between routing protocols.
Each IS-IS process can be bound to a specified VPN instance. A typical application is as follows:
In a VPN, IS-IS runs between PEs and CEs and also runs on the VPN backbone network. On
the PEs, the two IS-IS processes are independent of each other.
IS-IS multi-instance and multi-process have the following characteristics:

l IS-IS multi-processes share an RM routing table. IS-IS multi-instances use the RM routing
tables in VPNs, and each VPN has its own RM routing table.
l IS-IS multi-process allows a set of interfaces to be associated with a specified IS-IS process.
This ensures that the specified IS-IS process performs all the protocol operations only on
this set of interfaces. In this manner, multiple IS-IS processes can work on a single router
and each process is responsible for managing a unique set of interfaces.
l When creating an IS-IS process, you can bind it to a VPN instance to associate the IS-IS
process with the VPN instance. The IS-IS process accepts and processes only the events
related to the VPN instance. When the bound VPN instance is deleted, the IS-IS process is
also deleted.

Table 7-7 describes the IS-IS configuration tasks.
Table 7-7 IS-IS configuration tasks
Configuring basic IS-IS To deploy the IS-IS protocol 7.5.1 Configure Basic IS-IS
functions on IPv4 networks, configure Functions
basic IS-IS functions to
enable communication
between different nodes on
the network. Other IS-IS
features can only be
configured after the basic
functions are configured.

Routers
Configuring IS-IS network On IS-IS networks, 7.5.2 Improving IS-IS

security unauthorized users can attack Network Security
the IS-IS network by
modifying data packets or
forging authorized users. To
ensure security of services
carried on IS-IS networks,
configure the area or domain
authentication and interface
authentication.
Configuring IS-IS route If multiple redundant links 7.5.3 Controlling IS-IS

selection are available in the network Route Selection
using the IS-IS protocol, the
route in the IS-IS routing
table may not be the expected
optimal route. This does not
meet the network planning
and traffic management
requirements. To optimize
the IS-IS network and
facilitate traffic
management, more accurate
control of the routes on the
network is required.
Configuring IS-IS routing In practical applications, to 7.5.4 Controlling IS-IS

information exchange meet network requirements, Route Exchange
configure route policies to
accurately control
advertising and receiving of
IS-IS routing information.

Routers
Configuring IS-IS route Route aggregation allows 7.5.5 Configuring IS-IS

aggregation multiple routes with the same Route Summarization
IP prefix to be aggregated
into one route.
Route aggregation on a large
IS-IS network can effectively
reduce entries in the routing
table. This minimizes system
resource consumption and
facilitates management. In
addition, if a link in the
aggregated IP address
segment frequently alternates
between Up and Down,
devices outside this segment
will not be affected by the
change. This prevents route
flapping and improves
network stability.
Configuring IS-IS route To enable IS-IS to rapidly 7.5.6 Controlling IS-IS

convergence detect the network changes, Route Convergence
speed up the IS-IS network
convergence. To minimize
the effect on networks from
route flapping and reduce
load on the device, slow
down the IS-IS network
convergence.
Configuring LSP fragment When information contained 7.5.7 Configuring LSP

extension in the LSP data packet Fragment Extension
Protocol Data Unit (PDU) to
be advertised by IS-IS
increases greatly, the IS-IS
device will generate multiple
LSP fragments to carry and
advertise more information.

Routers
Configuring mesh groups On the NBMA network, 7.5.8 Configuring a Mesh

when an interface of the Group on an NBMA
router receives a new LSP, Network
the LSP is flooded to other
interfaces of the router. On
highly-connected networks
that have multiple P2P links,
this processing method
results in repeated LSP
flooding and wastes
To solve this problem, create
a mesh group and add some
interfaces to the group. The
router never floods the LSPs
received at interfaces in the
mesh group to other
interfaces from the same
group, and only floods the
LSPs to interfaces from other
groups or interfaces that are
not configured to any mesh
groups.
IS-IS Reliability To ensure rapid recovery 7.5.9 Configuring IS-IS

from failures on networks Reliability
using the IS-IS protocol,
adopt the solution of fast fault
detection and standby link
switchover. However, the IS-
IS fault detection mechanism
and link switchover require a
long period of time, which
fails to meet the requirements
of services that are highly
sensitive to packet loss and
packet delay.
To meet requirements of
these services, use BFD for
IS-IS to implement fast fault
detection and use IS-IS Auto
FRR and IS-IS GR helper to
implement fast switchover.
This improves IS-IS
reliability.

Routers
Configuring IS-IS overload If the system cannot store 7.5.10 Configuring the
new LSPs or synchronize the Overload Bit for an IS-IS
LSDB normally, the Device
calculated routing
information will be incorrect.
In this case, the system can
enter the overload state.
Routes reached through the
device will not be calculated,
but routes directly connected
to the device will not be
ignored.
When an IS-IS device on the
network requires upgrade or
maintenance, the device
needs to be temporarily
isolated from the network. To
prevent other devices from
forwarding traffic through
this node, set the overload bit
for the device in question.

Table 7-8 describes the default configuration of IPv4 IS-IS.
Table 7-8 Default configuration of IPv4 IS-IS
Parameter Default Configuration
IS-IS Disabled
DIS priority 64
Device level Level-1-2
Interval for sending Hello packets 10s
Minimum interval for sending LSPs 50 ms
Maximum number of LSPs to be sent 10
Interval for updating LSPs 900s
Maximum lifetime of LSPs 1200s

Routers
Bandwidth reference value 100 Mbit/s

7.5.1 Configure Basic IS-IS Functions

An IS-IS network can be set up only after basic IS-IS functions are configured.
Before configuring basic IS-IS functions, complete the following task:
the network layer
Creating an IS-IS process is the prerequisite for configuring a network entity title (NET),
configuring the device level, and establishing an IS-IS neighbor relationship.
7.5.1.1 Creating IS-IS Processes
Context
Creating IS-IS processes is the prerequisite for performing IS-IS configurations.
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ] [ vpn-instance vpn-instance-name ]
An IS-IS process is created, and the IS-IS process view is displayed.

The process-id parameter specifies the ID of an IS-IS process. If the process-id is not specified,
by default, The value of process-id is 1. To associate the IS-IS process with a VPN instance,
specify the VPN instance name.
description
Description for the IS-IS process is configured.
----End

Routers
7.5.1.2 Configuring a NET
Context
NET is the special form of the network service access point (NSAP). After the IS-IS view is
displayed, IS-IS can start only when a NET is configured for an IS-IS process.
Generally, you only need to configure one NET for an IS-IS process. When an area needs to be
redefined, for example, the area needs to be merged with other areas or divided into sub-areas,
configure multiple NETs to ensure route correctness. A maximum of three area addresses can
be configured for an IS-IS process. Therefore, a maximum of three NETs can be configured for
an IS-IS process. When configuring multiple NETs, ensure that their system IDs are the same.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
The IS-IS process view is displayed.
Step 3 Run:
network-entity net
A NET is configured.
NOTE
Configuring loopback interface addresses based on NETs is recommended to ensures that a NET is unique
on the network. If NETs are not unique, route flapping will easily occur.
An area ID uniquely identifies an area in the same IS-IS domain. All routers in the same Level-1 area must
share the same area ID, while routers in the same Level-2 area can have different area IDs.
----End
7.5.1.3 Configuring the Device Level
Context
Configure the device level according to network planning requirements:
l When the level of a device is Level-1, the device establishes neighbor relationships with
only Level-1 and Level-1-2 routers in the same area and maintains only Level-1 LSDBs.
l When the level of a device is Level-2, the device can establish neighbor relationship with
Level-2 routers in the same area or different areas and with Level-1-2 routers in different
areas and maintain only Level-2 LSDB.
l When the level of a device is Level-1-2, the device can establish neighbor relationships
with Level-1 and Level-2 routers and maintain Level-1 and Level-2 LSDBs.

Routers
NOTICE
If the levels of IS-IS devices are changed during network operation, the IS-IS process will be
restarted and IS-IS neighbor relationships will be disconnected. Setting the levels of devices
when configuring IS-IS is recommended.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
is-level { level-1 | level-1-2 | level-2 }
The level of the router is configured.
By default, the level of the router is Level-1-2.
----End
7.5.1.4 Establishing IS-IS Neighbor Relationships
Context
The methods to establish IS-IS neighbor relationships on a broadcast network and a P2P network
are different. Therefore, you need to set different IS-IS attributes for interfaces of different types:
l On a broadcast network, IS-IS needs to select the designated intermediate system (DIS).
You can set the DIS priority for IS-IS interfaces to enable the device with the highest DIS
priority to be elected as the DIS.
l On a P2P network, IS-IS does not need to select the DIS. Therefore, the DIS priority does
not need to be configured for interfaces. To ensure P2P link reliability, configure IS-IS to
establish a neighbor relationship on two P2P interfaces in 3-way mode for unidirectional
link fault detection.
Generally, IS-IS checks the IP addresses of received Hello packets. A neighbor relationship
can be established only when the source IP address carried in a received Hello packet and
the address of the interface that receives the Hello packet are on the same network segment.
If the IP addresses of the two P2P interfaces are on different network segments, and the
isis peer-ip-ignore command is run on the two interfaces, IS-IS does not check the peer
IP address. The neighbor relationship can be correctly established on the two P2P interfaces.
Procedure
l Establish an IS-IS neighbor relationship on a broadcast link.
1. Run:

Routers
system-view

2. Run:

3. Run:
isis enable [ process-id ]
IS-IS is enabled on the interface.
After this command is run, IS-IS establishes neighbor relationships and floods LSPs
through this interface.
NOTE
Loopback interfaces are not used to establish neighbor relationships. If IS-IS is enabled on a
loopback interface, IS-IS advertises the routes of the network segment where the interface
resides through other IS-IS interfaces.
4. Run:
isis circuit-level [ level-1 | level-1-2 | level-2 ]
The level of the interface is configured.
By default, the level of an interface is level-1-2.
When two Level-1-2 devices establish IS-IS neighbor relationship, they establish both
Level-1 and Level-2 neighbor relationships. To allow the two Level-1-2 devices to
establish only Level-1 or Level-2 neighbor relationship, change the level of interfaces.
NOTE
Changing the level of an IS-IS interface is valid only when the level of the IS-IS device is
Level-1-2. If the level of the device is not Level-1-2, the level of the device determines the
level of the established neighbor relationship.
5. (Optional) Run:
isis dis-priority priority [ level-1 | level-2 ]
The DIS priority is set for the interface. A larger value indicates a higher priority.
By default, the DIS priority of Level-1 and Level-2 broadcast interfaces is 64.
6. (Optional) Run:
isis silent [ advertise-zero-cost ]
The interface is suppressed.
By default, an IS-IS interface is not suppressed.
When an IS-IS interface is suppressed, the interface no longer sends or receives IS-
IS packets. The routes of the network segment where the interface resides, however,
can still be advertised to other IS-IS devices within the same AS.
l Establish an IS-IS neighbor relationship on a P2P link.
1. Run:
system-view

Routers
2. Run:

3. Run:
isis enable [ process-id ]
IS-IS is enabled on the interface.

4. Run:
By default, the level of an interface is level-1-2.

5. Run:
isis circuit-type p2p
The network type of the interface is set to P2P.
By default, the network type of an interface is determined by the physical type of the
interface.
When the network type of an IS-IS interface changes, the interface configuration
changes accordingly:
After a broadcast interface is simulated as a P2P interface using the isis circuit-
type p2p command, the interval for sending Hello packets, number of Hello
packets that IS-IS does not receive from a neighbor before the neighbor is declared
Down, interval for retransmitting LSPs on a P2P link, and various IS-IS
authentication modes are restored to the default settings; other configurations such
as the DIS priority, DIS name, and interval for sending CSNPs on a broadcast
network become invalid.
After the undo isis circuit-type command is run to restore the default network
type of an IS-IS interface, the interval for sending Hello packets, number of Hello
Down, interval for retransmitting LSPs on a P2P link, various IS-IS authentication
modes, DIS priority, and interval for sending CSNPs on a broadcast network are
restored to the default settings.
6. Run:
isis ppp-negotiation { 2-way | 3-way [ only ] }
The negotiation mode is specified for the interface.
By default, the negotiation mode is 3-way.

7. Run:
isis peer-ip-ignore
IS-IS is configured not to check the IP addresses of received Hello packets.
By default, IS-IS checks the IP addresses of received Hello packets.

8. Run:
isis ppp-osicp-check
OSICP negotiation status check is configured on the interface.

Routers
By default, the OSICP negotiation status of a PPP interface does not affect the status
of an IS-IS interface.
NOTE
This command applies only to PPP interfaces and is invalid for other P2P interfaces.
After this command is run, the OSICP negotiation status of a PPP interface affects the status
of an IS-IS interface. When PPP detects that the OSI network fails, the link status of the IS-IS
interface goes Down and the routes of the network segment where the interface resides are not
advertised through LSPs.
----End
Procedure
l Run the display isis peer [ verbose ] [ process-id | vpn-instance vpn-instance-name ]
command to check information about IS-IS neighbors.
l Run the display isis interface [ verbose ] [ process-id | vpn-instance vpn-instance-
name ] command to check information about IS-IS interfaces.
l Run the display isis route [ process-id | vpn-instance vpn-instance-name ] [ ipv4 ]
[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * command to check
information about IS-IS routes.
----End
7.5.2 Improving IS-IS Network Security

On an IS-IS network that requires high security, configure IS-IS authentication to improve IS-
IS network security.
Before improving IS-IS network security, complete the following task:
l 7.5.1 Configure Basic IS-IS Functions
7.5.2.1 Configuring Interface Authentication
Context
Generally, the IS-IS packets to be sent are not encapsulated with authentication information, and
the received packets are not authenticated. If a user sends malicious packets to attack a network,
information on the entire network may be stolen. Therefore, you can configure IS-IS
authentication to improve the network security.
After the IS-IS interface authentication is configured, authentication information can be
encapsulated into the Hello packet to confirm the validity and correctness of neighbor.

Routers
NOTICE
If plain is selected during the configuration of the authentication mode for the IS-IS interface,
the password is saved in the configuration file in plain text. This brings security risks. It is
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run any of the following command to configure the authentication mode of the IS-IS interface
as required:
l Run:
isis authentication-mode simple { plain plain-text | [ cipher ] plain-cipher-
text } [ level-1 | level-2 ] [ ip | osi ] [ send-only ]
Simple authentication is configured for the IS-IS interface.

l Run:
isis authentication-mode md5 { plain plain-text | [ cipher ] plain-cipher-text }
[ level-1 | level-2 ] [ ip | osi ] [ send-only ]
MD5 authentication is configured for the IS-IS interface.

l Run:
isis authentication-mode hmac-sha256 key-id key-id { plain plain-text |
[ cipher ] plain-cipher-text } [ level-1 | level-2 ] [ send-only ]
HMAC-SHA256 authentication is configured for the IS-IS interface.

l Run:
isis authentication-mode keychain keychain-name [ level-1 | level-2 ] [ send-
only ]
The Keychain authentication is configured for the IS-IS interface.
By default, an IS-IS interface does not authenticate received Hello packets and no authentication
password is configured on the interface.

Routers
NOTE
Use the send-only parameter according to network requirements:

l If the send-only parameter is specified, the device only encapsulates the Hello packets to be sent with
authentication information rather than checks whether the received Hello packets pass the
authentication. When the Hello packets do not need to be authenticated on the local device and pass
the authentication on the remote device, the two devices can establish the neighbor relationship.
l If the send-only parameter is not specified, ensure that passwords of all interfaces with the same level
on the same network are the same.
Parameters level-1 and level-2 apply only to the WAN-side Ethernet interfaces and LAN-side VLANIF
interfaces on which IS-IS is enabled using the isis enable command.
----End
7.5.2.2 Configuring Area or Domain Authentication
Context
The area authentication password is encapsulated into Level-1 IS-IS packets. Only the packets
that pass the area authentication can be accepted. Therefore, you must configure IS-IS area
authentication on all the IS-IS devices in the specified Level-1 area to authenticate the Level-1
area.
The domain authentication password is encapsulated into Level-2 IS-IS packets. Only the
packets that pass the domain authentication can be accepted. Therefore, you must configure IS-
IS domain authentication on all the IS-IS devices in the Level-2 area to authenticate Level-2
area.
NOTICE
If plain is selected during the configuration of the area authentication mode or domain
authentication mode, the password is saved in the configuration file in plain text. This brings
security risks. It is recommended that you select cipher to save the password in cipher text.
NOTE
When configuring IS-IS authentication, the area or domain authentication modes and passwords of the
routers in the same area must be consistent so that IS-IS packets can be flooded normally.
Whether IS-IS packets can pass area or domain authentication does not affect the establishment of Level-1
or Level-2 neighbor relationships.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
isis [ process-id ]
Step 3 Perform the following operations at any sequence as required.

l Run:
area-authentication-mode { { simple | md5 } { plain plain-text | [ cipher ]
plain-cipher-text } [ ip | osi ] | keychain keychain-name | hmac-sha256 key-id
key-id } [ snp-packet { authentication-avoid | send-only } | all-send-only ]
The area authentication mode is configured.

By default, the system neither encapsulates generated Level-1 packets with authentication
information nor authenticates received Level-1 packets.
l Run:
domain-authentication-mode { { simple | md5 } { plain plain-text | [ cipher ]
The domain authentication mode is configured.

NOTE
The authentication involves the following situations:

l The device encapsulates the authentication mode into LSPs and SNPs to be sent and checks whether
the received packets pass authentication. Then, the device discards the packets that do not pass the
authentication. In this case, the parameter snp-packet or all-send-only is not specified.
l The device encapsulates authentication information into LSPs to be sent and checks whether the
received LSPs pass the authentication; the device neither encapsulates the SNPs to be sent with
authentication information nor checks whether the received SNPs pass the authentication. In this case,
the parameter snp-packet authentication-avoid needs to be specified.
l The device encapsulates the LSPs and SNPs to be sent with authentication information; the device,
however, checks the authentication mode of only the received LSPs rather than the received SNPs. In
this case, the parameter snp-packet send-only needs to be specified.
l The device encapsulates the LSPs and SNPs to be sent with authentication information, but does not
check whether the received LSPs or SNPs pass the authentication. In this case, the parameter all-send-
only needs to be specified.
----End
7.5.2.3 Configuring the Optional Checksum
Context
When a network is running, Intermediate System to Intermediate System (IS-IS) routers may be
attacked or IS-IS packets may be modified. As a result, important network information may be
intercepted, causing serious loss to the network. The optional checksum encapsulates optional
checksum TLVs into the Complete Sequence Numbers Protocol Data Units (CSNPs), Partial
Sequence Number Protocol Data Units (PSNPs), and Hello packets sent by IS-IS routers. When
the peer device receives the encapsulated packets, it checks whether TLVs carried in the packets
are correct. If TLVs are not correct, the peer device discards the packets for network security.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis
An IS-IS process is created and the IS-IS view is displayed.
Step 3 Run:
optional-checksum enable
IS-IS optional checksum is enabled.
NOTE
If MD5 authentication or Keychain authentication with valid MD5 authentication is configured on an IS-
IS interface or area, IS-IS routers send Hello packets and SNP packets carrying no checksum TLVs and
verify the checksum of the received packets.
----End
Procedure
l Run the display isis lsdb verbose command to check the detailed information in the IS-IS
LSDB.
----End
7.5.3 Controlling IS-IS Route Selection

You can adjust IS-IS route selection to precisely control route selection.
Before configuring IS-IS route selection, complete the following task:
7.5.3.1 Configuring a Preference Value for IS-IS
Context
If multiple routes to the same destination are discovered by different routing protocols running
on the same device, the route discovered by the protocol with the highest preference is selected.

Routers
To prefer a route discovered by IS-IS, configure a higher preference value for IS-IS. In addition,
a routing policy can be configured to increase the preferences of specified IS-IS routes, without
affecting route selection.
Procedure
Step 1 Run:
system-view

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

Step 3 Run:
The IS-IS preference value is configured.

The default IS-IS preference value is 15. A smaller preference value indicates a higher
preference.
----End
7.5.3.2 Configuring the Cost of an IS-IS Interface
Context
The costs of IS-IS interfaces can be determined in the following modes in descending order by
priority:
l Interface cost: is configured for a specified interface.
l Global cost: is configured for all interfaces.
l Automatically calculated cost: is automatically calculated based on the interface
bandwidth.
If no cost is configured for an IS-IS interface, the IS-IS interface uses the default cost 10 and
cost style narrow.
NOTICE
If you want to change the cost style of IS-IS devices, running the command while configuring
basic IS-IS functions is recommended. If the cost style of IS-IS devices is changed during
network operation, the IS-IS process is restarted and neighbors are disconnected.
Procedure
Step 1 Configure the IS-IS cost style.
1. Run:
system-view

Routers

2. Run:
isis [ process-id ]

3. Run:
cost-style { narrow | wide | wide-compatible | { { narrow-compatible |
compatible } [ relax-spf-limit ] } }
The IS-IS cost style is configured.
By default, the cost style of routes received and sent by an IS-IS device is narrow.
The cost range of an interface and a route received by the interface vary with the cost type.
l If the cost style is narrow, the cost of an interface ranges from 1 to 63. The maximum cost
of a route received by the interface is 1023.
l If the cost style is narrow-compatible or compatible, the cost of an interface ranges from 1
to 63. The cost of a received route is related to relax-spf-limit.
l If the cost style is wide-compatible or wide, the cost of the interface ranges from 1 to
16777215. When the cost is 16777215, the neighbor TLV generated on the link cannot be
used for route calculation but for the transmission of TE information. The maximum cost of
a received route is 0xFFFFFFFF.
Step 2 Configure the cost of an IS-IS interface.
Perform any of the following operations to configure the cost of an IS-IS interface.
Configure the cost of a specified IS-IS interface.

1. Run:
system-view

2. Run:

3. Run:
isis cost { cost | maximum } [ level-1 | level-2 ]
The cost of the IS-IS interface is configured.
By default, the link cost of an IS-IS interface is 10.
NOTE
You can configure the parameter maximum only when the IS-IS cost style is wide or wide-
compatible.
To change the cost of a loopback interface, run the isis cost command only in the loopback interface
view.
Configure the global IS-IS cost.
1. Run:
system-view

Routers
2. Run:
isis [ process-id ]

3. Run:
circuit-cost { cost | maximum } [ level-1 | level-2 ]
The global IS-IS cost is configured.

By default, no global cost is configured.
Enable IS-IS to automatically calculate the interface cost.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
bandwidth-reference value
The reference value of the bandwidth is configured. By default, the bandwidth reference
value is 100 Mbit/s.
4. Run:
auto-cost enable
The interface is configured to automatically calculate its cost.

The bandwidth reference value set using the bandwidth-reference command takes effect only
when the cost style is wide or wide-compatible. In this case, the interface cost is calculated using
the following formula:
Cost of each interface = (Bandwidth-reference/Interface bandwidth) 10
If the cost-style is narrow, narrow-compatible, or compatible, the cost of each interface is based
on costs listed in Table 7-9.
Table 7-9 Mapping between IS-IS interface costs and interface bandwidth
50 10 Mbit/s < interface bandwidth 100 Mbit/s
20 622 Mbit/s < Interface bandwidth 2.5 Gbit/s
10 2.5 Gbit/s < Interface bandwidth
----End

Routers
7.5.3.3 Configuring Principles for Using Equal-Cost IS-IS Routes
Context
If there are redundant IS-IS links, multiple routes may have an equal cost. Choose either of the
following methods to use these equal-cost IS-IS routes:
l Configure load balancing for equal-cost IS-IS routes so that traffic will be evenly balanced
among these links.
This mechanism increases the link bandwidth usage and prevents network congestion
caused by link overload. However, this mechanism may make traffic management more
difficult because traffic will be randomly forwarded.
l Configure preference values for equal-cost IS-IS routes so that only the route with the
highest preference will be used and the others function as backups.
This configuration facilitates traffic management and improves the network reliability,
without the need to change original configurations.
Procedure
l Configure equal-cost IS-IS routes to work in load-balancing mode.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
The maximum number of load-balancing equal-cost IS-IS routes is set.
By default, the AR150&200 series, AR1200 series, AR2201-48FE, AR2202-48FE,

and AR2204 support a maximum of four equal-cost routes, and the AR2220, AR2240,
and AR3200 series support a maximum of eight equal-cost routes.
NOTE
When the number of equal-cost routes is greater than number specified in the maximum load-
balancing command, valid routes are selected for load balancing based on the following
criteria:
1. Route preference: Routes with higher preferences are selected for load balancing.
2. Interface index: If routes have the same priorities, routes with higher interface index values
are selected for load balancing.
3. Next hop IP address: If routes have the same priorities and interface index values, routes
with larger IP address are selected for load balancing.
l Configure preference values for equal-cost IS-IS routes.
1. Run:
system-view

Routers
2. Run:
isis [ process-id ]

3. Run:
nexthop ip-address weight value
A preference value is configured for an equal-cost IS-IS route.
By default, no preference is set for equal-cost IS-IS routes. A smaller value indicates
a higher priority.
----End
7.5.3.4 Configuring IS-IS Route Leaking
Context
If multiple Level-1-2 devices in a Level-1 area are connected to devices in the Level-2 area, a
Level-1 LSP sent by each Level-1-2 device carries an ATT flag bit of 1. This Level-1 area will
have multiple routes to the Level-2 area and to other Level-1 areas.
By default, routes in a Level-1 area can be leaked into the Level-2 area so that Level-1-2 and
Level-2 devices can learn about the topology of the entire network. Devices in a Level-1 area
are unaware of the entire network topology because they only maintain LSDBs in the local
Level-1 area. Therefore, a device in a Level-1 area can forward traffic to a Level-2 device only
through the nearest Level-1-2 device. The route used may not be the optimal route to the
destination.
To enable a device in a Level-1 area to select the optimal route, configure IPv4 IS-IS route
leaking so that specified routes in the Level-2 area can be leaked into the local Level-1 area.
Routes of services deployed only in the local Level-1 area do not need to be leaked into the
Level-2 area. A policy can be configured to leak only desired routes into the Level-2 area.
Procedure
l Specify routes in the Level-2 area and other Level-1 areas that can be leaked into the local
Level-1 area.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
import-route isis level-2 into level-1 [ tag tag | filter-policy { acl-
number | acl-name acl-name | ip-prefix ip-prefix-name | route-policy route-
policy-name } ] *
Routes that meet the specified conditions in the Level-2 areas are leaked into the local
Level-1 area.

Routers
By default, routes in the Level-2 area are not leaked into Level-1 areas.
NOTE
The command is run on the Level-1-2 device that is connected to an external area.
l Configure routes in Level-1 areas to leak into the Level-2 area.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
import-route isis level-1 into level-2 [ tag tag | filter-policy { acl-
number | acl-name acl-name | ip-prefix ip-prefix-name | route-policy route-
policy-name } ] *
Routes that meet the specifies conditions in Level-1 areas are leaked into the Level-2
area.
By default, all routes in a Level-1 area are leaked into the Level-2 area.
NOTE
----End
7.5.3.5 Controlling Whether a Level-1 Device Generates a IPv4 Default Route
Context
As defined in the IS-IS protocol, if a Level-1-2 device reaches more areas through a Level-2
area than through a Level-1 area based on the link state database (LSDB), the Level-1-2 device
sets the ATT bit to 1 in the LSPs and sends the LSPs with the ATT bit 1 to the Level-1 device.
Upon receipt, the Level-1 device generates a default route destined for the Level-1-2 device.
The preceding rules are employed by default. You can set the ATT bit as required on a live
network.
Perform the following steps:
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

Routers
Step 3 Run the following command as required:

l To set the ATT bit in the LSPs sent by the Level-1-2 device, run the attached-bit
advertise { always | never } command.
If the always parameter is specified, the ATT bit is set to 1. After receiving the LSPs
carrying the ATT bit 1, the Level-1 device generates a default route.
If the never parameter is specified, the ATT bit is set to 0. After receiving the LSPs
carrying the ATT bit 0, the Level-1 device does not generate a default route, which reduces
the size of a routing table.
l To disable the Level-1 device from generating default routes even though it receives the LSPs
carrying the ATT bit 1, run the attached-bit avoid-learning command.
----End
Procedure
[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * command to check IS-
IS routing information.
l Run the display isis lsdb [ { level-1 | level-2 } | verbose | { local | lsp-id | is-name symbolic-
name } ] * [ process-id | vpn-instance vpn-instance-name ] command to check information
in the IS-IS LSDB.
----End
7.5.4 Controlling IS-IS Route Exchange

If other routing protocols are configured on an IS-IS network, you need to configure IS-IS to
interact with these protocols to ensure successful communication between them.
Before controlling IS-IS route exchange, complete the following task:
7.5.4.1 Configuring IS-IS to Advertise a Default Route
Context
If IS-IS is configured to advertise a default route on a border device that has external routes, the
device advertises a default route 0.0.0.0/0 in the IS-IS routing domain. All traffic destined for
other routing domains is first forwarded to the border device.

Routers
NOTE
Configuring a static default route can also allow all the traffic to be first forwarded to a border device,
which then forwards the traffic outside an IS-IS routing domain. However, this method leads to heavy
workload in configuration and management when a large number of devices are deployed on the network.
In addition, advertising default routes using IS-IS is flexible. If multiple border devices are deployed, a
routing policy can be configured to allow only the border device that meets the specified conditions to
advertise a default route, preventing routing blackholes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
default-route-advertise [ always | match default | route-policy route-policy-name ]
[ cost cost | tag tag | [ level-1 | level-1-2 | level-2 ] ] * [ avoid-learning ]
IS-IS is configured to advertise a default route.
By default, IS-IS does not advertise a default route.
----End
7.5.4.2 Configuring IS-IS to Import External Routes
Context
After IS-IS is configured to advertise a default route on a border device in an IS-IS routing
domain, all the traffic destined outside the IS-IS routing domain is forwarded through the border
device. This burdens the border device because other devices in the IS-IS routing domain do not
have the routes destined outside the domain. If multiple border devices are deployed in the IS-
IS routing domain, optimal routes to other routing domains need to be selected.
To ensure optimal routes are selected, all the other devices in the IS-IS routing domain must
learn all or some external routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

Routers
Step 3 Configure IS-IS to import external routes.

l When you need to set the cost of imported routes, run the import-route { { rip | isis |
ospf } [ process-id ] | static | direct | unr | bgp [ permit-ibgp ] } [ cost-type { external |
internal } | cost cost | tag tag | route-policy route-policy-name | [ level-1 | level-2 |
level-1-2 ] ] * command to configure IS-IS to import external routes.
l When you need to retain the original cost of imported routes, run the import-route { { rip
| isis | ospf } [ process-id ] | direct | unr | bgp } inherit-cost [ tag tag | route-policy route-
policy-name | [ level-1 | level-2 | level-1-2 ] ] * command to configure IS-IS to import external
routes. In this case, the source routing protocol of imported routes cannot be static.
NOTE
IS-IS will advertise all imported external routes to the IS-IS routing domain by default.
----End
7.5.4.3 Configuring IS-IS to Advertise Specified External Routes to an IS-IS Routing

Domain
Context
When the local IS-IS device advertises imported external routes to other IS-IS devices, routing
policies can be configured to advertise only the external routes that meet specified conditions if
these devices do not require all the imported external routes.
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ]

Step 3 Run:
policy route-policy-name } export [ protocol [ process-id ] ]
IS-IS is configured to advertise the external routes that meet specified conditions to the IS-IS
routing domain.
----End
7.5.4.4 Adding Specified IS-IS Routes to the IP Routing Table
Context
Only routes in an IP routing table can be used to forward IP packets. An IS-IS route can take
effect only after this IS-IS route has been successfully added to an IP routing table.
If an IS-IS route does not need to be added to a routing table, specify conditions, such as a basic
ACL, IP prefix, and routing policy, to filter routes so that only IS-IS routes that meet the specified

Routers
conditions can added to an IP routing table. IS-IS routes that do not meet the specified conditions
cannot be added to the IP routing table and cannot be selected to forward IP packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
policy route-policy-name } import
Conditions for filtering IS-IS routes are configured.
----End
Procedure
name } ] * [ process-id | vpn-instance vpn-instance-name ] command to check IS-IS LSDB
information.
[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * command to check IS-
IS routing information.
l Run the display ip routing-table [ verbose ] command to check the IP routing table.
----End
7.5.5 Configuring IS-IS Route Summarization

A large IS-IS network has a large number of routing entries. This will slow down routing table
lookup and increase management complexity. You can configure route summarization to reduce
the size of routing tables.
Before configuring IS-IS route summarization, complete the following task:
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
isis [ process-id ]
Step 3 Run:
summary ip-address mask [ avoid-feedback | generate_null0_route | tag tag |
[ level-1 | level-1-2 | level-2 ] ] *
The specified IS-IS routes are summarized into one IS-IS route.
NOTE
After route summarization is configured on a device, the local routing table still contains all specific routes
before the summarization. The routing tables on other devices contain only the summary route, and the
summary route is deleted only after all its specific routes are deleted.
----End

l Run the display isis route command to check summary routes in the IS-IS routing table.
l Run the display ip routing-table [ verbose ] command to check summary routes in the IP
routing table.
7.5.6 Controlling IS-IS Route Convergence

Accelerating IS-IS route convergence can improve the fault location efficiency and improve
network reliability.
Before configuring IS-IS route convergence, complete the following task:
7.5.6.1 Configuring Attributes for Hello Packets
Context
IS-IS maintains neighbor relationships between neighbors by sending and receiving Hello
packets. If the local device does not receive Hello packets from its neighbor within a specified
period, the device considers the neighbor Down.
In IS-IS, you can set the interval for sending Hello packets and the holding multiplier of
neighboring devices to control the holdtime of neighbor relationships between the local device
and neighbors.

Routers
l If the interval for sending Hello packets is too short, more system resources are consumed
to send Hello packets, causing a heavy CPU load.
l If the holdtime of neighboring devices is too long, the local device needs to spend much
time detecting the failure of neighbors, slowing down IS-IS route convergence. If the
holdtime of neighboring devices is too short, some Hello packets may be lost or become
incorrect because of network transmission delay and errors. This will cause neighbor
relationships to frequently alternate between Up and Down and lead to route flapping on
the IS-IS network.
NOTE
You are advised to set the same interval for sending Hello packets and same holding multiplier of
neighboring devices on all the devices on the IS-IS network. This method prevents IS-IS route
convergence from being slowed down when some devices detect link failures at a lower speed than
other devices.
Procedure
l Configure the interval for sending Hello packets.
1. Run:
system-view

2. Run:

3. Run:
isis timer hello hello-interval [ level-1 | level-2 ]
The interval for sending Hello packets is set on an interface.
By default, the interval for sending Hello packets 10 seconds.
NOTE
Parameters level-1 and level-2 are configured only on a broadcast interface.

On a broadcast link, there are Level-1 and Level-2 Hello packets. For different types of packets,
you can set different intervals. If no level is specified, both the Level-1 timer and Level-2 timer
are configured. On a P2P link, there are only one type of Hello packets. Therefore, neither
level-1 nor level-2 is required.
l Set the holding multiplier for neighboring devices.
1. Run:
system-view

2. Run:

3. Run:
isis timer holding-multiplier number [ level-1 | level-2 ]
The holding multiplier of neighboring devices is set.

Routers
The default holding multiplier is 3. The holdtime of neighbor relationships is three

times the interval for sending Hello packets.
NOTE
----End
7.5.6.2 Configuring Attributes for LSPs
Context
LSPs are used to exchange link state information. You can configure attributes for LSPs to
control the length and maximum lifetime of LSPs. To accelerate network convergence, you can
enable LSP fast flooding or reduce the minimum interval for sending LSPs and the interval for
updating LSPs to speed up LSP flooding. However, CPU resources will be consumed too much
if the network topology changes frequently. In this situation, configure the intelligent timer for
generating LSPs. This timer can fast respond to emergencies, speed up network convergence,
and improve CPU resource efficiency because its interval becomes longer when the network
changes frequently.
Configured Function Usage Scenario

Parameters
Set the Set the size When the volume of link status information increases, the
maximum for LSPs to length of LSPs to be generated can be increased to carry
length for LSPs be more information in each LSP.
generated
and LSPs to
be received.
Set the Set the When a router generates the system LSP, it fills in the
maximum maximum maximum lifetime for this LSP. After this LSP is received
lifetime for lifetime for by other routers, the lifetime of the LSP is reduced gradually.
LSPs LSPs to If the router does not receive any more update LSPs and the
ensure the lifetime of the LSP is reduced to 0, the LSP will be deleted
validity of from the LSDB 60s later if no more updated LSPs are
an LSP received.
before its
updated
LSP is
received.
Set the refresh Set the On an IS-IS network, LSDB synchronization is

interval for refresh implemented through LSP flooding. During LSP flooding,
LSPs interval for a router sends an LSP to its neighbors and then the neighbors
LSPs to send the received LSP to their respective neighbors except
synchronize the router that first sends the LSP. In this manner, the LSP
LSDBs. is flooded among the routers of the same level. LSP flooding
allows each router of the same level to have the same LSP
information and synchronize its LSDB with each other.

Routers

Parameters
Set the Set the Reducing the minimum interval for sending LSPs speeds up
minimum interval for LSP flooding.
interval at sending an
which LSPs are LSP during
sent LSP update.
Configure the Control the On an IS-IS network, if the local routing information
intelligent interval for changes, a router needs to generate a new LSP to notify this
timer used to generating change. If the local routing information changes frequently,
generate LSPs LSPs a large number of new LSPs are generated, which occupies
intelligently a lot of system resources and decreases system performance.
to speed up To speed up network convergence and prevent system
route performance from being affected, configure an intelligent
convergenc timer for generating LSPs. This timer can adjust the delay
e and reduce in generating LSPs based on the routing information change
system frequency.
load.
Enable LSP Control the When an IS-IS router receives new LSPs from other
fast flooding number of routers, it router updates the LSPs in the local LSDB and
LSPs periodically floods out the updated LSPs according to a
flooded timer . LSP fast flooding updates the preceding method.
each time When a device configured with LSP fast flooding receives
on an one or more new LSPs. it floods out the LSPs with a number
interface to smaller than the specified number before calculating routes.
speed up IS- This speeds up LSDB synchronization.
IS network
convergenc
e.
Set an interval Control the On a point-to-point network, devices at both ends of a link
at which LSPs interval for synchronize LSDBs with each other by flooding LSPs. The
are retransmitti device at one end of the link sends an LSP. If the device at
retransmitted ng LSPs to the other end receives this LSP, it replies with a PSNP. If the
over a P2P link ensure device that has sent an LSP does not receive a PSNP from
LSDB the other end in a period of time, the device will retransmit
synchroniza the LSP.
tion on a
P2P
network.
Procedure
l Set the maximum length for LSPs.
1. Run:
system-view

Routers

2. Run:
isis [ process-id ]

3. Set the maximum length for LSPs.
Run:
lsp-length originate max-size
The maximum length is set for each generated LSP.

Run:
lsp-length receive max-size
The maximum length is set for each received LSP.
By default, the IS-IS system generates and receives 1497-byte LSPs.
NOTE
Ensure that the value of max-size for LSPs to be generated must be smaller than or equal to the
value of max-size for LSPs to be received.
The value of max-size set through the lsp-length command must meet the following
requirements; otherwise, the MTU status on the interface is considered Down.
l The MTU of an Ethernet interface must be greater than or equal to the sum of the value of
max-size and 3.
l The MTU of a P2P interface must be greater than or equal to the value of max-size.
l Set the maximum lifetime for LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-max-age age-time
The maximum lifetime is set for LSPs.
By default, the maximum lifetime of LSPs is 1200 seconds.

l Set the refresh interval for LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-refresh refresh-time
A refresh interval is set for LSPs.

Routers
y default, the LSP refresh interval is 900s.
NOTE
Ensure that the LSP refresh interval is more than 300s shorter than the maximum LSP lifetime.
This allows new LSPs to reach all devices in an area before existing LSPs expire.
The larger a network, the greater the deviation between the LSP refresh interval and the
maximum LSP lifetime.
l Set the minimum interval at which LSPs are sent.
1. Run:
system-view

2. Run:

3. Run:
isis timer lsp-throttle throttle-interval [ count count ]
The minimum interval for sending LSPs on an IS-IS interface and the maximum
number of LSPs sent within the interval are set.
By default, the minimum interval for sending LSPs is 50 ms, and the maximum number
of LSPs sent each time is 10.
l Configure the intelligent timer used to generate LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-generation max-interval [ init-interval [ incr-interval ] ]
[ level-1 | level-2 ]
The intelligent timer used to generate LSPs is set.
If no level is configured, both Level-1 and Level-2 are configured.
The initial delay for generating the same LSPs (or LSP fragments) is init-interval. The
delay for generating the same LSPs (or LSP fragments) secondly is incr-interval.
When the routes change each time, the delay for generating the same LSPs (or LSP
fragments) is twice as the previous value until the delay is up to max-interval. After
the delay reaches max-interval for three times or reset the IS-IS process, the interval
is reduced to init-interval.
When incr-interval is not used and generating the same LSPs (or LSP fragments) for
the first time, init-interval is used as the initial delay. Then, the delay for generating
the same LSPs (or LSP fragments) is max-interval. After the delay reaches max-
interval for three times or the IS-IS process is reset, the interval is reduced to init-
interval.

Routers
When only max-interval is used, the intelligent timer changes into a normal one-short
timer.
l Enable LSP fast flooding.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
flash-flood [ lsp-count | max-timer-interval interval | [ level-1 |
level-2 ] ]*
The LSP fast flooding is enabled.
The lsp-count parameter specifies the number of LSPs flooded each time, which is
applicable to all interfaces. If the number of LSPs to be sent is greater than the value
of lsp-count, lsp-count takes effect. If the number of LSPs to be sent is smaller than
the value of lsp-count, LSPs of the actual number are sent. If a timer is configured and
the configured timer does not expire before the route calculation, the LSPs are flooded
immediately when being received; otherwise, the LSPs are sent when the timer
expires.
When LSP fast flooding is enabled, Level-1 LSPs and Level-2 LSPs are fast flooded
by default if no level is specified.
l Set an interval at which LSPs are retransmitted over a P2P link.
1. Run:
system-view

2. Run:

3. (Optional) Run:
A broadcast interface is simulated as a P2P interface.
NOTE
If the interface type is P2P, this step is not required.

4. Run:
isis timer lsp-retransmit retransmit-interval
The interval at which LSPs are retransmitted over a P2P link is set.
By default, the interval for retransmitting LSPs over a P2P link is 5 seconds.
----End

Routers
7.5.6.3 Configuring Attributes for CSNPs
Context
Complete sequence number PDUs (CSNPs) contains the summary of all the LSPs in an LSDB
to ensure LSDB synchronization between neighbors. CSNPs are processed differently on
broadcast and P2P links.
l On a broadcast link, CSNPs are periodically sent by a DIS device. If a device detects that
its LSDB is not synchronized with that on its neighboring device, the device will send
PSNPs to apply for missing LSPs.
l On a P2P link, CSNPs are sent only during initial establishment of neighboring
relationships.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
isis timer csnp csnp-interval [ level-1 | level-2 ]
The interval at which CSNPs are sent is set on the specified interface.
By default, the interval at which CSNPs are sent on a broadcast network is 10 seconds.
NOTE
Configure Level-1 and Level-2 only when a broadcast interface is specified.
----End
7.5.6.4 Setting the SPF Calculation Interval
Context
A network change always triggers IS-IS to perform SPF calculation. Frequent SPF calculation
will consume excessive CPU resources, affecting services.
To solve this problem, configure an intelligent timer to control the interval for SPF calculation.
For example, to speed up IS-IS route convergence, set the interval for SPF calculation to a small
value and set the interval to a large value after the IS-IS network becomes stable.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
isis [ process-id ]
Step 3 Run:
timer spf max-interval [ init-interval [ incr-interval ] ]
The SPF intelligent timer is configured.
By default, no SPF intelligent timer is configured and the maximum delay in SPF calculation is
5 seconds.
The intelligent timer changes as follows:

l The delay in the first SPF calculation is determined by init-interval; the delay in the second
SPF calculation is determined by incr-interval. From the third time on, the delay in SPF
calculation increases twice every time until the delay reaches the value specified by max-
interval. After the delay remains at the value specified by max-interval for three times or the
IS-IS process is restarted, the delay decreases to the value specified by init-interval.
l If incr-interval is not specified, the delay in SPF calculation for the first time is determined
by init-interval. From the second time on, the delay in SPF calculation is determined by max-
l When only max-interval is specified, the intelligent timer functions as an ordinary one-time
triggering timer.

spf-slice-size duration-time
The maximum duration for SPF calculation is configured.
By default, IS-IS route calculation lasts for a maximum of 2 ms at a time.
----End
7.5.6.5 Configuring Convergence Priorities for IS-IS Routes
Context
Devices allow you to configure the highest convergence priority for specific IS-IS routes so that
these IS-IS routes will be converged first when a network topology changes.
The application rules of the convergence priorities for IS-IS routes are as follows:
l Existing IS-IS routes are converged based on the priorities configured in the prefix-
priority command.
l New IS-IS routes are converged based on the priorities configured in the prefix-priority
command.
l If an IS-IS route conforms to the matching rules of multiple convergence priorities, the
highest convergence priority is used.
l The convergence priority of a Level-1 IS-IS route is higher than that of a Level-2 IS-IS
route.

Routers
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ]

Step 3 Run:
prefix-priority [ level-1 | level-2 ] { critical | high | medium } { ip-prefix
prefix-name | tag tag-value }
Convergence priorities are set for IS-IS routes.

By default, the convergence priority of 32-bit host routes is medium, and the convergence
priority of the other IS-IS routes is low.
NOTE
The prefix-priority command is only applicable to the public network.

After the prefix-priority command is run, the convergence priority of 32-bit host routes is low, and the
convergence priorities of the other routes are determined as specified in the prefix-priority command.

quit

ip route prefix-priority-scheduler critical-weight high-weight medium-weight low-
weight
The preference-based scheduling ratio of IPv4 routes is configured.

By default, the preference-based scheduling ratio of IPv4 routes is 8:4:2:1.
----End
Procedure
name ] command to check IS-IS packet information.
[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * [ | count ] command
to check the informations of IS-IS routes.
----End
7.5.7 Configuring LSP Fragment Extension

LSP fragment extension allows an IS-IS device to generate more LSP fragments to transmit
more IS-IS information.

Routers
Before configuring LSP fragment extension, complete the following task:
l 7.5.1.1 Creating IS-IS Processes

NOTE
When a new device connects to an IS-IS network, you are advertised to configure LSP fragment extension
and virtual systems before establishing IS-IS neighbors or importing routes. If you establish IS-IS neighbors
or import routes, which causes IS-IS to carry much information that cannot be loaded through 256
fragments, you must configure LSP fragment extension and virtual systems. The configurations, however,
take effect only after you restart the IS-IS process.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
lsp-fragments-extend [ [ level-1 | level-2 | level-1-2 ] | [ mode-1 | mode-2 ] ] *
LSP fragment extension is enabled in an IS-IS process.
By default, LSP fragment extension is disabled in an IS-IS process.
If the mode or level is not specified during the configuration of LSP fragment extension, mode-1
and level-1-2 are used by default.
NOTE
If there are devices of other manufacturers on the network, LSP fragment extension must be set to mode-1.
Otherwise, devices of other manufacturers cannot identify LSPs.
Step 4 Run:
virtual-system virtual-system-id
A virtual system is configured.
By default, no virtual system is configured.
To configure a router to generate extended LSP fragments, you must configure at least one virtual
system. The ID of the virtual system must be unique in the domain.
An IS-IS process can be configured with up to 50 virtual system IDs.
----End

Run the following commands to check IS-IS process statistics.

Routers
l display isis statistics [ updated-lsp [ history ] ] [ level-1 | level-2 | level-1-2 ] [ process-

id | vpn-instance vpn-instance-name ]
l display isis process-id statistics [ [ [ updated-lsp [ history ] ] [ level-1 | level-2 |
level-1-2 ] ] | [ packet ] ]
7.5.8 Configuring a Mesh Group on an NBMA Network

You can configure a mesh group on an NBMA network to prevent repeated LSP flooding from
causing bandwidth waste.
Before configuring a mesh group, complete the following task:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
isis mesh-group { mesh-group-number | mesh-blocked }
The interface is added to a mesh group.

When mesh-blocked is configured on an interface, the interface is blocked and cannot flood
LSPs outside. All the interfaces added to a mesh group implement global LSDB synchronization
through CSNP and PSNP mechanisms.
----End

level-1-2 ] ] | [ packet ] ]
7.5.9 Configuring IS-IS Reliability

You can configure IS-IS Auto FRR, BFD for IS-IS, and IS-IS GR to improve IS-IS reliability.
Before configuring IS-IS reliability, complete the following task:

Routers
7.5.9.1 Enabling IS-IS Auto FRR
Context
At present, the VoIP and on-line video services require high-quality real-time transmission.
Nevertheless, if an IS-IS fault occurs, multiple processes, including fault detection, LSP update,
LSP flooding, route calculation, and FIB entry delivery, must be performed to switch the traffic
to a new link. As a result, it takes much more than 50 ms to recover the link from the fault, which
cannot meet the requirement for real-time services on the network.
After the BFD session status is bound to IS-IS Auto FRR, traffic can be fast switched from the
faulty link to the backup link. This ensures that the traffic interruption time is within 50 ms,
which protects traffic and improves IS-IS network reliability.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
The IS-IS process is enabled and the IS-IS view is displayed.
Step 3 Run:
frr
The IS-IS FRR view is displayed.

frr-policy route route-policy route-policy-name
Backup routes are filtered using a filtering policy. Only backup routes that have passed the
filtering policy are added to the routing table.
Step 5 Run:
loop-free-alternate [ level-1 | level-2 | level-1-2 ]
IS-IS Auto FRR is enabled and the loop-free backup route is created.
By default, IS-IS Auto FRR is disabled from calculating loop-free backup routes using the loop-
free alternate (LFA) algorithm.
If the IS-IS level is not specified, IS-IS Auto FRR is enabled on Level-1 and Level-2 to create
the backup route.
Step 6 (Optional) Run the following command in the interface view:

Routers
undo isis lfa-backup [ level-1 | level-2 | level-1-2 ]
The interface is disabled from participating in LFA calculation.
By default, an IS-IS interface can participate in LFA calculation.
During network deployment, to facilitate traffic management and fast determine the traffic
forwarding path when the primary link fails, disable some interfaces from participating in LFA
calculation.
----End

[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * command to check
information about the primary link and backup link generated by IS-IS Auto FRR.
l Run the display isis spf-tree verbose command to check the traffic protection type of IS-
IS Auto FRR.
7.5.9.2 Configuring Static BFD for IS-IS
Context
On an IS-IS network, a device periodically sends Hello packets to detect the neighbor status
change. By default, the device considers a neighbor Down when it does not receive a Hello
packet from the neighbor after sending three Hello packets (30 seconds). This IS-IS fault
detection mechanism, however, cannot provide high reliability for the network that requires fast
network convergence and no packet loss. BFD for IS-IS can solve this problem. BFD is a
millisecond-level fault detection mechanism. It can detect faults on the link between IS-IS
neighbors within 50 ms. Therefore, BFD can speed up IS-IS route convergence, ensures fast link
switchover, and reduces traffic loss.
Compared to dynamic BFD, static BFD has the following characteristics:

l Static BFD can be manually controlled and is easy to deploy. To save memory and ensure
reliability of key links, BFD can be deployed on specified links.
l Establishing and deleting BFD sessions need to be manually triggered and lack flexibility.
Configuration errors may occur. For example, if an incorrect local or remote discriminator
is configured, a BFD session cannot work properly.
NOTE
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd

Routers
Step 3 Run:
quit
Step 4 Run:
bfd cfg-name bind peer-ip ip-address [ interface interface-type interface-number ]
BFD is enabled between the specified interface and peer router.
If a peer IP address and a local interface are specified in the bfd command, BFD monitors only
a single-hop link with the interface specified in the bfd command as the outbound interface and
with the peer IP address specified in the peer-ip command as the next-hop address.
Step 5 Set discriminators.

l Run:
A local discriminator is set.

l Run:
discriminator remote discr-value
A remote discriminator is set.
The local discriminator of a device must be the remote discriminator of the device on the other
end; otherwise, a BFD session cannot be established. In addition, the local and remote
discriminators cannot be modified after being configured.
NOTE
The local discriminator of the local device must be the same as the remote discriminator of the remote
device, and the remote discriminator of the local device must be the same as the local discriminator of the
remote device.
Step 6 Run:
commit
Configurations are committed.
Step 7 Run:
quit
Step 8 Run:
Step 9 Run:
isis bfd static
Static IPv4 BFD is enabled on the specified interface.
----End

Routers

You can check information about a BFD session only after parameters of the BFD session are
configured and the BFD session is established.
l Run the display isis [ process-id | vpn-instance vpn-instance-name ] bfd session { peer
ip-address | all } command to check information about the BFD session.
l Run the display isis interface verbose command. The command output shows that the
status of static BFD for IS-IS process is Yes.
7.5.9.3 Configuring Dynamic BFD for IS-IS
Context
On an IS-IS network, a device periodically sends Hello packets to detect the neighbor status
change. By default, the device considers a neighbor Down when it does not receive a Hello
packet from the neighbor after sending three Hello packets (30 seconds). This IS-IS fault
detection mechanism, however, cannot provide high reliability for the network that requires fast
network convergence and no packet loss. BFD for IS-IS can solve this problem. BFD is a
millisecond-level fault detection mechanism. It can detect faults on the link between IS-IS
neighbors within 50 ms. Therefore, BFD can speed up IS-IS route convergence, ensures fast link
switchover, and reduces traffic loss.
Dynamic BFD for IS-IS implements dynamic setup of BFD sessions. When a new IS-IS neighbor
relationship is set up, BFD is notified of the neighbor parameters and the detection parameters
(including source and destination IP addresses). Then a BFD session will be established based
on the received neighbor parameters.
Dynamic BFD is more flexible than static BFD. In dynamic BFD, routing protocols trigger the
setup of BFD sessions, preventing the configuration errors caused by manual configuration.
Dynamic BFD is easy to configure and applies to the scenarios where BFD needs to be configured
on the entire network. Dynamic BFD for IS-IS can fast detect neighbor status changes and
implement fast network convergence.
NOTE
The priority of BFD configured on an interface is higher than that of BFD configured for a process. If BFD
session parameters are configured for both a process and an interface, the parameters on the interface will
be used to establish a dynamic BFD session.
Procedure
l Configure dynamic BFD for IS-IS in a specified IS-IS process.
1. Run:
system-view

2. Run:
bfd

Routers
3. Run:
quit

4. Run:
isis process-id

5. Run:
BFD for IS-IS is enabled to establish a BFD session.
This command enables an IS-IS process to use default BFD parameters to create BFD
sessions on all the interfaces in the IS-IS process.
6. (Optional) Run:
bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval
transmit-interval | detect-multiplier multiplier-value | frr-binding } *
The parameters for establishing BFD sessions are set for all interfaces.
The command execution result is applicable to BFD session parameters on all IS-IS
interfaces.
NOTE
The AR150&200 series does not support the frr-binding parameter.

7. (Optional) Run the following command in the interface view:
isis bfd block
The interface is prohibited from dynamically establishing a BFD session.
By default, an interface can dynamically establish BFD sessions.

l Configure dynamic BFD for IS-IS on a specified interface.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

4. Run:

5. Run:
isis bfd enable
BFD is enabled on the interface to establish a BFD session.

Routers
After BFD is configured globally and the neighbor status is Up (on a broadcast
network, DIS is in the Up state), default BFD parameters will be used to establish
BFD sessions on the specified interface.
6. (Optional) Run:
isis bfd { min-rx-interval receive-interval | min-tx-interval transmit-
interval | detect-multiplier multiplier-value | frr-binding } *
Run this command when BFD session parameters need to be configured for a specified
interface.
NOTE
The AR150&200 series does not support the frr-binding parameter.

7. (Optional) Run:
isis bfd block
The interface is prohibited from dynamically establishing a BFD session.
----End

After BFD is enabled on both ends of a link, run the display isis [ process-id | vpn-instance
vpn-instance-name ] bfd session { all | peer ip-address | interface interface-type interface-
number } command. The command output shows that BFD status is up.
7.5.9.4 Enabling IS-IS GR
Context
The restart of an IS-IS router causes the temporary interruption of the network, because the
adjacency relationship between the router and its neighbor is torn down. The LSPs of the
router are deleted, which makes route calculation inaccurate. Packets are thus lost.
You can configure IS-IS GR to solve this problem. After IS-IS GR is enabled, the router notifies
the neighbor of the restart status, and reestablishes the adjacency relationship with its neighbor
without interrupting the forwarding.
The GR interval is set as the Holdtime in an IS-IS Hello PDU. Therefore, the adjacency
relationship is not torn down when the router restarts.
NOTE
The AR150&200&1200&2200&3200 can function as only the Helper router, but cannot function as the
Restarter router.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

Routers
Step 3 Run:
graceful-restart
IS-IS GR is enabled.
By default, IS-IS GR is disabled.
Step 4 Run:
graceful-restart no-impact-holdtime
The holdtime of an IS-IS neighbor is configured to remain unchanged in IS-IS GR mode.

graceful-restart interval interval-value
A value is configured for the T3 timer during the IS-IS GR.
The value of the T3 timer indicates the longest time that a GR lasts. A router disables the T3
timer after the LSDB synchronization ends in all areas. If LSDBs are not synchronized yet when
the T3 timer expires, the GR fails.
By default, the value of the T3 timer is 300 seconds. Keeping the default value is recommended.
During a GR, an IS-IS neighbor of the restarter sets the value of the T3 timer to the holdtime of
the neighbor relationship between them, which prevents routes from being recalculated on the
whole network due to a neighbor disconnection during the GR.

graceful-restart suppress-sa
The GR restarter is configured to suppress the Suppress-Advertisement (SA) bit of the restart
TLV.
By default, the SA bit is not suppressed.
----End

Run display isis graceful-restart status [ level-1 | level-2 ] [ process-id | vpn-instance vpn-
instance-name ] command to check the status of IS-IS GR.
7.5.10 Configuring the Overload Bit for an IS-IS Device

If an IS-IS device needs to be temporarily isolated, configure the IS-IS device to enter the
overload state to prevent other devices from forwarding traffic to this IS-IS device and prevent
routing black hole.
Before configuring the overload bit for an IS-IS device, complete the following task:

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
set-overload [ on-startup [ timeout1 | start-from-nbr system-id [ timeout1
[ timeout2 ] ] | wait-for-bgp [ timeout1 ] ] ][ allow { interlevel | external }* ]
The overload bit for non-pseudonode LSPs is configured.
----End

l Run the display isis lsdb [ [ level-1 | level-2 ] | verbose | [ local | lsp-id | is-name symbolic-
name ] ] * [ process-id | vpn-instance vpn-instance-name ] command to check information
in the IS-IS LSDB.

7.6.1 Resetting IS-IS
Context
To reset IS-IS, reset IS-IS data structure, neighbor relationship and packets
NOTICE
The IS-IS data structure cannot be restored after you reset it. All the previous structure
information and the neighbor relationship are reset. Exercise caution when running this
command.
The specified IS-IS neighbor relationship is deleted after you reset a specified IS-IS neighbor.
Exercise caution when running this command.
Procedure
l Reset IS-IS data structure.

Routers
Run the reset isis all [ [ process-id | vpn-instance vpn-instance-name ] | graceful-

restart ] * command to reset IS-IS data structure.
l Reset IS-IS neighbor relationship.
Run the reset isis peer system-id [ process-id | vpn-instance vpn-instance-name ] command
to reset a specific IS-IS neighbor.
After the IS-IS routing policy or the protocol changes, you can reset a specific IS-IS
neighbor to validate the new configuration.
----End
7.6.2 Improving the Maintainability of IS-IS
Context
The administrator can improve the maintainability of IS-IS using either of the following
methods:
l Configuring IS-IS host name mapping: Through this function, the administrator can use a
simple name to replace the system ID. After IS-IS host name mapping is configured, the
dynamic name is displayed in the IS-IS information to replace the system ID when the
display command is executed. This improves the maintainability of IS-IS networks.
l Configuring IS-IS to add the POI TLV to a PURGE packet: When the value of the
Remaining Lifetime field in an LSP packets is 0, this packet is invalid and called a PURGE
packet. PURGE packets do not record information about the devices generating these
packets. Therefore, when a network is faulty, the packet source cannot be located. To solve
this problem, IS-IS can be configured to add the POI TLV to a PURGE packet so that the
PURGE packet contains information about its generating device. If the dynamic host name
function is configured locally, the host name TLV is also added to the PURGE packet to
facilitate fault location.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Configure IS-IS host name mapping.

l Run:
is-name symbolic-name
IS-IS dynamic host name mapping is configured and a host name is configured for the local
device.
This configuration is dynamic configuration. Therefore, the configured host name symbolic-
name is advertised through an LSP to other IS-IS devices in the same area. When you use
IS-IS display commands to view IS-IS information on other IS-IS devices, the system ID of
the local device is replaced by the configured host name.

Routers
l Run:
is-name map system-id symbolic-name
IS-IS static host name mapping is configured and a host name is configured for the remote
device.
This configuration is static configuration and takes effect only on the local device. Therefore,
the configured host name symbolic-name is not advertised through an LSP.
----End
7.6.3 Configuring the Output of IS-IS Adjacency Status
Context
On an IS-IS network, neighbor flapping will result in network instability and frequent network
convergence. This will consume lots of memory and may even cause user traffic loss. Therefore,
neighbor flapping needs to be rapidly located and solved.
To rapidly locate problems in the case of neighbor flapping, enable the output of IS-IS adjacency
changes to log these changes.
If the local terminal monitor is enabled and the output of the IS-IS adjacency status is enabled,
IS-IS adjacency changes will be output to the router until the output of the adjacency status is
disabled.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
log-peer-change [ topology ]
The output of the adjacency status is enabled.
By default, the output of IS-IS adjacency changes is disabled.
----End

This section describes IS-IS configuration examples, including networking requirements,
configuration roadmap, and configuration procedure.

Routers
7.7.1 Example for Configuring Basic IS-IS Functions

As shown in Figure 7-25, there are four routers (RouterA, RouterB, RouterC, and RouterD) on
the network. The four routers need to communicate with each other. RouterA and RouterB can
only process a small amount of data because they have lower performance than the other two
routers.
Figure 7-25 Networking diagram of configuring basic IS-IS functions
IS-IS
Area10 RouterD
L2
GE1/0/0 GE1/0/0 GE3/0/0 GE2/0/0
10.1.1.2/24 10.1.1.1/24 192.168.0.1/24 172.16.1.1/16
GE1/0/0
RouterA GE2/0/0 RouterC
192.168.0.2/24
L1 10.1.2.1/24 L1/2
GE1/0/0 IS-IS
10.1.2.2/24 Area20
RouterB
L1
1. Enable IS-IS on each router so that the routers can be interconnected. Configure RouterA
and RouterB as Level-1 routers to enable them to maintain less data.
Procedure
Step 1 Configure IP addresses for interfaces on each router.
The configurations of RouterB, RouterC and RouterD are similar to the configuration of
RouterA, and are not mentioned here.
Step 2 Configure basic IS-IS functions.
[RouterA] isis 1

Routers
[RouterA-isis-1] is-level level-1

[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA-GigabitEthernet1/0/0] isis enable 1
[RouterB] isis 1
[RouterB-isis-1] is-level level-1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB-GigabitEthernet1/0/0] isis enable 1
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC-GigabitEthernet1/0/0] isis enable 1
[RouterD] isis 1
[RouterD-isis-1] is-level level-2
[RouterD-isis-1] network-entity 20.0000.0000.0004.00
[RouterD-isis-1] quit
[RouterD-GigabitEthernet2/0/0] isis enable 1
# View the IS-IS LSDB of each Router to check whether the IS-IS LSDBs of the Routers are
synchronized.
[RouterA] display isis lsdb
Database information for ISIS(1)

--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL

-------------------------------------------------------------------------
0000.0000.0001.00-00* 0x00000006 0xbf7d 649 68 0/0/0
0000.0000.0001.01-00* 0x00000002 0xcfbb 1157 55 0/0/0
0000.0000.0002.00-00 0x00000003 0xef4d 545 68 0/0/0
0000.0000.0003.00-00 0x00000008 0x3340 582 111 1/0/0
Total LSP(s): 4
*(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended),
ATT-Attached, P-Partition, OL-Overload
[RouterB] display isis lsdb

Routers

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

-------------------------------------------------------------------------
0000.0000.0001.00-00 0x00000006 0xbf7d 642 68 0/0/0
0000.0000.0002.00-00* 0x00000003 0xef4d 538 68 0/0/0
0000.0000.0002.01-00* 0x00000003 0xef4b 538 68 0/0/0
0000.0000.0003.00-00 0x00000008 0x3340 574 111 1/0/0
Total LSP(s): 4
[RouterC] display isis lsdb

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

-------------------------------------------------------------------------
0000.0000.0001.00-00 0x00000006 0xbf7d 638 68 0/0/0
0000.0000.0001.01-00 0x00000002 0xcfbb 871 55 0/0/0
0000.0000.0002.00-00 0x00000003 0xef4d 533 68 0/0/0
0000.0000.0003.00-00* 0x00000008 0x3340 569 111 1/0/0
Total LSP(s): 4


-------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000008 0x55bb 650 100 0/0/0
0000.0000.0004.00-00 0x00000005 0x6510 629 84 0/0/0
0000.0000.0004.01-00 0x00000001 0xee95 803 55 0/0/0
Total LSP(s): 3
[RouterD] display isis lsdb

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

-------------------------------------------------------------------------
0000.0000.0003.00-00 0x00000008 0x55bb 644 100 0/0/0
0000.0000.0004.00-00* 0x00000005 0x6510 624 84 0/0/0
0000.0000.0004.01-00* 0x00000001 0xee95 700 55 0/0/0
Total LSP(s): 3
# View the IS-IS routing information of each Router. The routing table of a Level-1 router
contains a default route with the next hop as a Level-1-2 router. The routing table of a Level-2
router contains all Level-1 and Level-2 routes.
[RouterA] display isis route
Route information for ISIS(1)

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

Routers
ISIS(1) Level-1 Forwarding Table

--------------------------------
IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags

-------------------------------------------------------------------------
10.1.1.0/24 10 NULL GE1/0/0 Direct D/-/L/-
10.1.2.0/24 20 NULL GE1/0/0 10.1.1.1 A/-/-/-
192.168.0.0/24 20 NULL GE1/0/0 10.1.1.1 A/-/-/-
0.0.0.0/0 10 NULL GE1/0/0 10.1.1.1 A/-/-/-
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,

U-Up/Down Bit Set
[RouterB] display isis route

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

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

-------------------------------------------------------------------------
10.1.2.0/24 10 NULL GE1/0/0 Direct D/-/L/-
10.1.1.0/24 20 NULL GE1/0/0 10.1.2.1 A/-/-/-
192.168.0.0/24 20 NULL GE1/0/0 10.1.2.1 A/-/-/-
0.0.0.0/0 10 NULL GE1/0/0 10.1.2.1 A/-/-/-

U-Up/Down Bit Set
[RouterC] display isis route

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

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

-------------------------------------------------------------------------
10.1.1.0/24 10 NULL GE1/0/0 Direct D/-/L/-
10.1.2.0/24 10 NULL GE2/0/0 Direct D/-/L/-
192.168.0.0/24 10 NULL GE3/0/0 Direct D/-/L/-

U-Up/Down Bit Set

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

-------------------------------------------------------------------------
10.1.1.0/24 10 NULL GE1/0/0 Direct D/-/L/-
10.1.2.0/24 10 NULL GE2/0/0 Direct D/-/L/-
192.168.0.0/24 10 NULL GE3/0/0 Direct D/-/L/-
172.16.0.0/16 20 NULL GE3/0/0 192.168.0.2 A/-/-/-

U-Up/Down Bit Set
[RouterD] display isis route

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

Routers

--------------------------------
--------------------------------------------------------------------------
192.168.0.0/24 10 NULL GE3/0/0 Direct D/-/L/-
10.1.1.0/24 20 NULL GE3/0/0 192.168.0.1 A/-/-/-
10.1.2.0/24 20 NULL GE3/0/0 192.168.0.1 A/-/-/-
172.16.0.0/16 10 NULL GE2/0/0 Direct D/-/L/-

U-Up/Down Bit Set
----End
Configuration Files
#
sysname RouterA
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
return

#
sysname RouterB
#
isis 1
is-level level-1
network-entity 10.0000.0000.0002.00
#
ip address 10.1.2.2 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1
network-entity 10.0000.0000.0003.00
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
ip address 192.168.0.1 255.255.255.0
isis enable 1
#
return

Routers

#
sysname RouterD
#
isis 1
is-level level-2
network-entity 20.0000.0000.0004.00
#
ip address 192.168.0.2 255.255.255.0
isis enable 1
#
ip address 172.16.1.1 255.255.0.0
isis enable 1
#
return
7.7.2 Example for Configuring IS-IS Route Summarization
As shown in Figure 7-26, three routers run IS-IS to communicate with each other. RouterA is
a Level-2 router, RouterB is a Level-1-2 router, and RouterC is a Level-1 router. RouterA is
heavily loaded because there are too many routing entries on the IS-IS network. Therefore,
system resource consumption of RouterA needs to be reduced.
Figure 7-26 Networking diagram of configuring IS-IS route summarization
Network1
GE2/0/0
172.1.1.0/24
172.1.1.1/24
RouterC RouterB RouterA

L1
GE3/0/0 GE1/0/0 L1/L2 GE2/0/0 L2
172.1.2.1/24 172.1.4.2/24 172.2.1.1/24
Network2
172.1.2.0/24 GE1/0/0 GE2/0/0
172.1.4.1/24 172.2.1.2/24
Area20
Area10
GE4/0/0
Network3 172.1.3.1/24
172.1.3.0/24
1. Configure IP addresses for interfaces and enable IS-IS on each router so that the routers
can be interconnected.

Routers
2. Configure route summarization on RouterB to reduce the routing table size of RouterA
without affecting data forwarding so that the system resource consumption of RouterA can
be reduced.
Procedure
not mentioned here.
[RouterA] isis 1
[RouterB] isis 1
[RouterC] isis 1
[RouterC-isis-1] is-level level-1
The configurations of GigabitEthernet2/0/0, GigabitEthernet3/0/0, and GigabitEthernet4/0/0 are

similar to the configuration of GigabitEthernet1/0/0, and are not mentioned here.
Step 3 Check the IS-IS routing table of RouterA.

-----------------------------
--------------------------------
----------------------------------------------------------------------------
172.1.1.0/24 30 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.1.2.0/24 30 NULL GE2/0/0 172.2.1.2 A/-/L/-

Routers
172.1.3.0/24 30 NULL GE2/0/0 172.2.1.2 A/-/L/-

172.1.4.0/24 20 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.2.1.0/24 10 NULL GE2/0/0 Direct D/-/L/-
U-Up/Down Bit Set
Step 4 Configure route summarization on RouterB.
# Summarize 172.1.1.0/24, 172.1.2.0/24, 172.1.3.0/24, and 172.1.4.0/24 into 172.1.0.0/16 on

RouterB.
[RouterB] isis 1
[RouterB-isis-1] summary 172.1.0.0 255.255.0.0 level-1-2
# Check the routing table of RouterA, you can see that routes 172.1.1.0/24, 172.1.2.0/24,
172.1.3.0/24 and 172.1.4.0/24 are summarized into one route 172.1.0.0/16.
-----------------------------
--------------------------------
----------------------------------------------------------------------------
172.1.0.0/16 20 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.2.1.0/24 10 NULL GE2/0/0 Direct D/-/L/-
U-Up/Down Bit Set
----End
Configuration Files
#
sysname RouterA
#
isis 1
is-level level-2
network-entity 20.0000.0000.0001.00
#
ip address 172.2.1.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
summary 172.1.0.0 255.255.0.0 level-1-2
#
ip address 172.1.4.2 255.255.255.0
isis enable 1
#
ip address 172.2.1.2 255.255.255.0
isis enable 1

Routers
#
return

#
sysname RouterC
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
ip address 172.1.4.1 255.255.255.0
isis enable 1
#
ip address 172.1.1.1 255.255.255.0
isis enable 1
#
ip address 172.1.2.1 255.255.255.0
isis enable 1
#
ip address 172.1.3.1 255.255.255.0
isis enable 1
#
return
7.7.3 Example for Configuring IS-IS DIS Election
As shown in Figure 7-27, four routers on the broadcast network communicate using IS-IS.
RouterA and RouterB are Level-1-2 routers, RouterC is a Level-1 router, and RouterD is a
Level-2 router. RouterA with high performance needs to be configured as a Level-2 DIS.
Figure 7-27 Networking diagram of configuring IS-IS DIS election
RouterA RouterB
L1/L2 L1/L2
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24
GE1/0/0 GE1/0/0
10.1.1.3/24 10.1.1.4/24
RouterC RouterD
L1 L2

Routers
1. Configure IS-IS to enable network interconnectivity.

2. Configure the DIS priority of RouterA to 100 so that RouterA can be elected as a Level-2
DIS.
Procedure
The configurations of RouterB, RouterC, and RouterD are similar to the configuration of
Step 2 View the MAC address of the GE interface on each router.
# View the MAC address of GigabitEthernet1/0/0 on RouterA.

[RouterA] display arp interface gigabitethernet 1/0/0
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-INSTANCE
VLAN/CEVLAN PVC
-------------------------------------------------------------------------
10.1.1.1 00e0-fc10-afec I - GE1/0/0
-------------------------------------------------------------------------
Total:1 Dynamic:0 Static:0 Interface:1
# View the MAC address of GigabitEthernet1/0/0 on RouterB.

[RouterB] display arp interface gigabitethernet 1/0/0
VLAN/CEVLAN PVC
-------------------------------------------------------------------------
10.1.1.2 00e0-fccd-acdf I - GE1/0/0
-------------------------------------------------------------------------
# View the MAC address of GigabitEthernet1/0/0 on RouterC.

[RouterC] display arp interface gigabitethernet 1/0/0
VLAN/CEVLAN PVC
-------------------------------------------------------------------------
10.1.1.3 00e0-fc50-25fe I - GE1/0/0
-------------------------------------------------------------------------
# View the MAC address of GigabitEthernet1/0/0 on RouterD.

[RouterD] display arp interface gigabitethernet 1/0/0
VLAN/CEVLAN PVC
-------------------------------------------------------------------------
10.1.1.4 00e0-fcfd-305c I - GE1/0/0
-------------------------------------------------------------------------
Step 3 Enable IS-IS

Routers
[RouterA] isis 1
[RouterB] isis 1
[RouterC] isis 1
[RouterD] isis 1
# View IS-IS neighbor information on RouterA.

[RouterA] display isis peer
Peer information for ISIS(1)
----------------------------
System Id Interface Circuit Id State HoldTime Type PRI
-----------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 9s L1(L1L2) 64
0000.0000.0003 GE1/0/0 0000.0000.0002.01 Up 27s L1 64
0000.0000.0002 GE1/0/0 0000.0000.0004.01 Up 28s L2(L1L2) 64
0000.0000.0004 GE1/0/0 0000.0000.0004.01 Up 8s L2 64
Total Peer(s): 4
# View IS-IS interface information on RouterA.

[RouterA] display isis interface
Interface information for ISIS(1)
---------------------------------
Interface Id IPV4.State IPV6.State MTU Type DIS
GE1/0/0 001 Up Down 1497 L1/L2 No/No
# View IS-IS interface information on RouterB.

[RouterB] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 Yes/No

Routers
# View IS-IS interface information on RouterD.

[RouterD] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 No/Yes
NOTE
As shown in the preceding interface information, when the default DIS priority is used, the IS-IS interface
on RouterB has the largest MAC address among all the interfaces on the Level-1 routers. Therefore,
RouterB is elected as the Level-1 DIS. The IS-IS interface on RouterD has the largest MAC address among
all the interfaces on Level-2 routers. Therefore, RouterD is elected as the Level-2 DIS. Level-1 and Level-2
pseudonodes are 0000.0000.0002.01 and 0000.0000.0004.01 respectively.
Step 4 Set the DIS priority of RouterA.

[RouterA-GigabitEthernet1/0/0] isis dis-priority 100
# View IS-IS neighbor information on RouterA.

----------------------------
-----------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0001.01 Up 21s L1(L1L2) 64
0000.0000.0003 GE1/0/0 0000.0000.0001.01 Up 27s L1 64
0000.0000.0002 GE1/0/0 0000.0000.0001.01 Up 28s L2(L1L2) 64
0000.0000.0004 GE1/0/0 0000.0000.0001.01 Up 30s L2 64
Total Peer(s): 4
# View IS-IS interface information on RouterA.

[RouterA] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 Yes/Yes
NOTE
As shown in the preceding information, after the DIS priority of the IS-IS interface is changed, RouterA
becomes a Level-1-2 DIS (DR) immediately and its pseudonode is 0000.0000.0001.01.
# View IS-IS neighbor and interface information on RouterB.

[RouterB] display isis peer
----------------------------
-----------------------------------------------------------------------------
0000.0000.0001 GE1/0/0 0000.0000.0001.01 Up 7s L1(L1L2) 100
0000.0000.0003 GE1/0/0 0000.0000.0001.01 Up 25s L1 64
0000.0000.0001 GE1/0/0 0000.0000.0001.01 Up 7s L2(L1L2) 100
0000.0000.0004 GE1/0/0 0000.0000.0001.01 Up 25s L2 64
Total Peer(s): 4
[RouterB] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 No/No

Routers
# View IS-IS neighbor and interface information on RouterD.

[RouterD] display isis peer
----------------------------
-----------------------------------------------------------------------------
0000.0000.0001 GE1/0/0 0000.0000.0001.01 Up 9s L2 100
0000.0000.0002 GE1/0/0 0000.0000.0001.01 Up 28s L2 64
Total Peer(s): 2
[RouterD] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 No/No
----End
Configuration Files
#
sysname RouterA
#
isis 1
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis dis-priority 100
#
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
ip address 10.1.1.3 255.255.255.0
isis enable 1
#
return

#
sysname RouterD
#

Routers
isis 1
is-level level-2
network-entity 10.0000.0000.0004.00
#
ip address 10.1.1.4 255.255.255.0
isis enable 1
#
return
7.7.4 Example for Configuring IS-IS to Interact with BGP
As shown in Figure 7-28, RouterA and RouterB belong to the same AS, and the IS-IS neighbor
relationship is established between RouterA and RouterB. An EBGP connection is established
between RouterB and RouterC. RouterA, RouterB, and RouterC need to communicate with each
other. Besides, the metric of routes need to be changed when AS 65009 sends the routes to AS
65008.
Figure 7-28 Networking diagram of configuring IS-IS to interact with BGP
Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32
GE1/0/0 GE2/0/0 GE1/0/0
10.1.1.1/24 10.2.1.1/24 10.2.1.2/24
GE1/0/0
RouterA 10.1.1.2/24 RouterB RouterC
AS65009
AS65008
1. Configure IP addresses for interfaces, and enable IS-IS and BGP to ensure that there are
reachable routes inside each AS.
2. Configure IS-IS and BGP to import routes from each other on RouterB to ensure that there
are routes on each network segment. Configure a route-policy to change the metric of
imported routes when IS-IS imports BGP routes.
Procedure

Routers
not mentioned here.
Step 2 Configure IS-IS.
[RouterA] isis 1
[RouterB] isis 1
Step 3 Configure BGP.
[RouterB] bgp 65008
[RouterB-bgp] router-id 1.1.1.1
[RouterB-bgp] peer 10.2.1.2 as-number 65009
[RouterB-bgp] ipv4-family unicast
[RouterB-bgp-af-ipv4] network 10.2.1.0 255.255.255.0
[RouterC] bgp 65009
[RouterC-bgp] router-id 2.2.2.2
[RouterC-bgp] peer 10.2.1.1 as-number 65008
[RouterC-bgp] ipv4-family unicast
[RouterC-bgp-af-ipv4] network 10.2.1.0 255.255.255.0
Step 4 Configure IS-IS to import BGP routes.
# Configure a static route on RouterC.

[RouterC] ip route-static 200.1.1.1 32 NULL 0
# On RouterC, configure BGP to import the static route.

[RouterC] bgp 65009
[RouterC-bgp] import-route static
# On RouterB, configure IS-IS to import the BGP route.

[RouterB] isis 1
[RouterB-isis-1] import-route bgp
# View the routing table of RouterA, and you can see that IS-IS successfully imports BGP route
200.1.1.1/32.
------------------------------------------------------------------------------

Routers

200.1.1.1/32 ISIS-L2 15 74 D 10.1.1.2 GigabitEthernet1/0/0
# On RouterB, configure the AS_Path filter, and apply the filter in route-policy RTC.
[RouterB] ip as-path-filter 1 permit 65009
[RouterB] route-policy RTC permit node 0
[RouterB-route-policy] if-match as-path-filter 1
[RouterB-route-policy] apply cost 20
[RouterB-route-policy] quit
# On RouterB, configure IS-IS to import the BGP route.

[RouterB] isis 1
[RouterB-isis-1] import-route bgp route-policy RTC
# View the routing table of RouterA, and you can see that the AS_Path filter is successfully
applied and the cost of imported route 200.1.1.1/32 changes from 74 to 94.
------------------------------------------------------------------------------
Step 5 Configure BGP to import IS-IS routes.

[RouterB] bgp 65008
[RouterB-bgp] import-route isis 1
[RouterB-bgp] quit
# View the routing table of RouterC, and you can see that BGP successfully imports IS-IS route
10.1.1.0/24.
[RouterC] display ip routing-table
------------------------------------------------------------------------------

10.1.1.0/24 EBGP 255 0 D 10.2.1.1 GigabitEthernet1/0/0
200.1.1.1/32 Static 60 0 D 0.0.0.0 NULL0
----End
Configuration Files

Routers
#
sysname RouterA
#
isis 1
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
import-route bgp route-policy RTC
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 65008
router-id 1.1.1.1
peer 10.2.1.2 as-number 65009
#
ipv4-family unicast
undo synchronization
network 10.2.1.0 255.255.255.0
import-route isis 1
peer 10.2.1.2 enable
#
route-policy RTC permit node 0
if-match as-path-filter 1
apply cost 20
#
ip as-path-filter 1 permit 65009
#
return

#
sysname RouterC
#
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
network 10.2.1.0 255.255.255.0
import-route static

Routers
#
#
return
7.7.5 Example for Configuring IS-IS Fast Convergence

As shown in Figure 7-29, two Routers are connected through a Layer 2 switch. The two routers
communicate with each other through the IS-IS protocol. The convergence speed of the two
routers need to be improved.
Figure 7-29 Networking diagram for configuring IS-IS fast convergence

GE1/0/0
100.1.1.2/24
GE1/0/0
RouterA 100.1.1.1/24 RouterB
1. Configure the IP addresses of interfaces and the IS-IS route-policy on each router so that
routes on the two routers are reachable.
2. Configure BFD sessions on RouterA and RouterB to improve the link fault detection speed
of the routers.
3. Set the time parameters of fast convergence on RouterA and RouterB to implement IS-IS
fast convergence.
Procedure
The configuration of RouterB is similar to the configuration of RouterA, and is not mentioned
here.
[RouterA] isis 1

Routers
[RouterB] isis 1
Step 3 Configure BFD.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd atob bind peer-ip 100.1.1.2 interface gigabitethernet 1/0/0
[RouterA-bfd-session-atob] discriminator local 1
[RouterA-bfd-session-atob] discriminator remote 2
[RouterA-bfd-session-atob] commit
[RouterA-bfd-session-atob] quit
[RouterA-GigabitEthernet1/0/0] isis bfd static
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd btoa bind peer-ip 100.1.1.1 interface gigabitethernet 1/0/0
[RouterB-bfd-session-btoa] discriminator local 2
[RouterB-bfd-session-btoa] discriminator remote 1
[RouterB-bfd-session-btoa] commit
[RouterB-bfd-session-btoa] quit
[RouterB-GigabitEthernet1/0/0] isis bfd static
Step 4 Set the time parameters of fast convergence.
[RouterA] isis 1
[RouterA-isis-1] flash-flood
[RouterA-isis-1] timer spf 1 20 100
[RouterA-isis-1] timer lsp-generation 1 1 120
[RouterB] isis 1
[RouterB-isis-1] timer spf 1 20 100
[RouterB-isis-1] timer lsp-generation 1 1 120

Routers
NOTE
l In IS-IS, if the LSDB changes, routes are calculated and a new LSP is generated to report this change.
Frequent route calculations consume a lot of system resources and decrease the system performance.
Delaying SPF calculation and LSP generation and speeding up LSP flooding can improve the efficiency
in route calculation and reduce the consumption of system resources.
l The flash-flood command enables LSP fast flooding to speed up IS-IS network convergence.
l The timer spf command sets the interval for SPF calculation. The default interval is 5 seconds.
l The timer lsp-generation command sets the delay in generating an LSP. The default interval is 2
seconds.
# Run the shutdown command on GE1/0/0 of RouterB to shut down the link.
# View the information about neighbors of RouterA.

<RouterA> display isis peer
INformation about neighbors of RouterA does not exist.
When BFD detects that the link goes Down, it notifies the routing management (RM) module
immediately. IS-IS then deletes the neighbor relationship immediately and triggers route
calculation. This implements fast convergence of the network.
----End
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
timer lsp-generation 1 1 120 level-1
flash-flood level-1
flash-flood level-2
network-entity 10.0000.0000.0001.00
timer spf 1 20 100
#
ip address 100.1.1.1 255.255.255.0
isis enable 1
isis bfd static
#
bfd atob bind peer-ip 100.1.1.2 interface GigabitEthernet1/0/0
commit
#
return

#
sysname RouterB
#

Routers
bfd
#
isis 1
is-level level-2
flash-flood level-1
flash-flood level-2
network-entity 10.0000.0000.0002.00
timer spf 1 20 100
#
ip address 100.1.1.2 255.255.255.0
isis enable 1
isis bfd static
#
bfd btoa bind peer-ip 100.1.1.1 interface GigabitEthernet1/0/0
commit
#
return
7.7.6 Example for Configuring IS-IS Auto FRR (IP Protecting IP)
As shown in Figure 7-30, four routers (RouterA, RouterB, RouterC, and RouterD) communicate
using IS-IS. Reliability of data forwarding from RouterA to RouterD needs to be improved so
that uninterrupted traffic transmission is ensured when a fault occurs on the network.
Figure 7-30 Networking diagram of configuring IS-IS Auto FRR

RouterC
L1/2
GE1/0/0 GE2/0/0
1.0.0.2/24 4.0.0.1/24
co
st RouterD
GE1/0/0 =
10
1.0.0.1/24 Link T 10 L1/2

=
GE3/0/0
st
GE1/0/0
co
RouterA 4.0.0.2/24 100.1.1.1/24

L1/2 cost = 10
co
GE2/0/0 st =
10
GE2/0/0
=
2.0.0.1/24 30
st
3.0.0.2/24
co
GE1/0/0 GE2/0/0
2.0.0.2/24 3.0.0.1/24
RouterB
L1/2

Routers
1. Configure IP addresses for interfaces and enable IS-IS on each router to ensure reachable
routes between the routers.
2. Set a larger link cost (in compliance with the traffic protection inequality of IS-IS Auto
FRR) on GigabitEthernet2/0/0 of RouterA to ensure that Link T functions as the primary
link to forward data from RouterA to RouterD.
3. Configure IS-IS Auto FRR on RouterA to allow traffic to be fast switched to the backup
link without waiting for route convergence when a fault occurs on Link T. This ensures
uninterrupted traffic transmission.
Procedure
The configurations of RouterB, RouterC, and RouterD are similar to the configuration of
[RouterA] isis 1
[RouterA-isis-1] is-level level-1-2
[RouterB] isis 1
[RouterB-isis-1] is-level level-1-2
[RouterC] isis 1
[RouterC-isis-1] is-level level-1-2

Routers

[RouterD] isis 1
[RouterD-isis-1] is-level level-1-2
Step 3 Set the cost of GigabitEthernet2/0/0 on RouterA to 30, and check routing information.
# Set the cost of GigabitEthernet2/0/0 on RouterA to 30.

[RouterA-GigabitEthernet2/0/0] isis cost 30
# Check information about the link from RouterA to RouterD. Link T has a lower cost, and so
IS-IS selects Link T to send traffic forwarded by RouterA.
<RouterA> display isis route 100.1.1.1 verbose

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

--------------------------------
IPV4 Dest : 100.1.1.0/24 Int. Cost : 30 Ext. Cost : NULL

Admin Tag : - Src Count : 1 Flags : A/-/L/-
Priority : Low
NextHop : Interface : ExitIndex :
1.0.0.2 GE1/0/0 0x00000003

U-Up/Down Bit Set

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

Admin Tag : - Src Count : 3 Flags : -/-/-/-
Priority : Low

U-Up/Down Bit Set
# Run the display fib 100.1.1.1 verbose command on RouterA to check the forwarding entry
of traffic from RouterA to RouterD.
<RouterA> display fib 100.1.1.1 verbose
Route Entry Count: 1

Destination: 100.1.1.0 Mask : 255.255.255.0
Nexthop : 1.0.0.2 OutIf : GigabitEthernet1/0/0
LocalAddr : 1.0.0.1 LocalMask: 0.0.0.0
Flags : DGU Age : 26sec
ATIndex : 0 Slot : 0

Routers
LspFwdFlag : 0 LspToken : 0x0

InLabel : NULL OriginAs : 0
BGPNextHop : 0.0.0.0 PeerAs : 0
QosInfo : 0x0 OriginQos: 0x0
NexthopBak : 0.0.0.0 OutIfBak : [No Intf]
LspTokenBak: 0x0 InLabelBak : NULL
LspToken_ForInLabelBak : 0x0
EntryRefCount : 0
VlanId : 0x0
LspType : 0 Label_ForLspTokenBak : 0
MplsMtu : 0 Gateway_ForLspTokenBak : 0
NextToken : 0 IfIndex_ForLspTokenBak : 0
Label_NextToken : 0 Label : 0
LspBfdState : 0
As shown in the command output, traffic from RouterA to RouterD is only forwarded through
Link T.
Step 4 Enable IS-IS Auto FRR on RouterA, and check routing information.
# Enable IS-IS Auto FRR on RouterA.

[RouterA] isis
[RouterA-isis-1] frr
[RouterA-isis-1-frr]loop-free-alternate
# Check information about the routes from RouterA to RouterD. The information shows that IS-
IS generates a backup link after IS-IS Auto FRR is enabled.
<RouterA> display isis route 100.1.1.1 verbose

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

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

Admin Tag : - Src Count : 1 Flags : A/-/L/-
Priority : Low
NextHop : Interface : ExitIndex :
1.0.0.2 GE1/0/0 0x00000003
(B)2.0.0.2 GE2/0/0 0x00000004

U-Up/Down Bit Set

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

Admin Tag : - Src Count : 3 Flags : -/-/-/-
Priority : Low

U-Up/Down Bit Set
# Check the protection type for the traffic forwarded from RouterA to RouterD.
<RouterA> display isis spf-tree systemid 0000.0000.0004 verbose
Shortest Path Tree for ISIS(1)

------------------------------
ISIS(1) Level-1 Shortest Path Tree

Routers
----------------------------------
0000.0000.0004.00
Distance : 20
Distance-URT : 20
Flags : SPT/V6_Islt
IPv4 Nexthops-URT : 1
(1) 1.0.0.2 IF:GE1/0/0 NBR:0000.0000.0003.00
(B) 2.0.0.2 IF:GE2/0/0 NBR:0000.0000.0002.00
TYPE:LOOP-FREE PROTECT:LINK-NODE
IPv6 Nexthops : 0
Neighbors: 2 (Children:1 Parents:1 Others:0)
(1) 0000.0000.0003.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.03
Cost : 10
Flags : Child
ISIS(1) Level-2 Shortest Path Tree

----------------------------------
0000.0000.0004.00
Distance :20
Distance-URT :20
Flags :SPT/V6_Islt
IPv4 Nexthops-URT :1
(1) 1.0.0.2 IF:GE1/0/0 NBR:0000.0000.0003.00
(B) 2.0.0.2 IF:GE2/0/0 NBR:0000.0000.0002.00
TYPE:LOOP-FREE PROTECT:LINK-NODE
IPv6 Nexthops : 0
Neighbors: 2 (Children:1 Parents:1 Others:0)
(1) 0000.0000.0003.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.03
Cost : 10
Flags : Child
As shown in the preceding command output, link-node dual protection is performed on the traffic
from RouterA to RouterD.
# Run the display fib 100.1.1.1 verbose command on RouterA to check the forwarding entry
of traffic from RouterA to RouterD.
NexthopBak : 2.0.0.2 OutIfBak : GigabitEthernet2/0/0
EntryRefCount : 0
VlanId : 0x0

Routers
LspBfdState : 0
As shown in the command output, the primary link from RouterA to RouterD is Link T, the
backup link follows the route with outbound interface GigabitEthernet2/0/0 and next hop 2.0.0.2.
# Run the shutdown command on GigabitEthernet2/0/0 of RouterC to shut down the link.
[RouterC-GigabitEthernet2/0/0] shutdown
# Run the display fib 100.1.1.1 verbose command on RouterA to check information about the
route from RouterA to RouterD.
EntryRefCount : 0
VlanId : 0x0
LspBfdState : 0
As shown in the command output, the traffic forwarded by the RouterA is switched to the backup
link with outbound interface GigabitEthernet2/0/0 and next hop 2.0.0.2.
----End
Configuration Files
#
sysname RouterA
#
isis 1
frr
loop-free-alternate level-1
network-entity 10.0000.0000.0001.00
#
interface GigabitEthernet 1/0/0
ip address 1.0.0.1 255.255.255.0
isis enable 1
#
ip address 2.0.0.1 255.255.255.0
isis enable 1
isis cost 30
#

Routers
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 2.0.0.2 255.255.255.0
isis enable 1
#
ip address 3.0.0.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1
network-entity 10.0000.0000.0003.00
#
ip address 1.0.0.2 255.255.255.0
isis enable 1
#
shutdown
ip address 4.0.0.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterD
#
isis 1
network-entity 10.0000.0000.0004.00
#
ip address 4.0.0.2 255.255.255.0
isis enable 1
#
ip address 3.0.0.2 255.255.255.0
isis enable 1
#
ip address 100.1.1.1 255.255.255.0
isis enable 1
#
return
7.7.7 Example for Configuring IS-IS Auto FRR (TE Protecting IP)
Figure 7-31 shows the simplified networking diagram of MPLS VPN dual plane, and PEs are
dual-homed to the two planes. Routes run IS-IS to implement route reachability. The reliability

Routers
of data forwarding between PEs needs to be improved so that uninterrupted traffic transmission
is ensured when a fault occurs on the network.
Figure 7-31 Networking diagram of configuring IS-IS Auto FRR

PE1 P1 P3 PE3
P5
Plane A
P2 P4
P6
Plane B Traffic in normal
GE4/0/0 P1 GE2/0/0
10.1.10.2/30 10.1.2.1/30 GE1/0/0
10 G 10.1.1.2/30
.1 E
GE1/0/0 .1 4
G 1. /0 GE2/0/0
10.1.1.1/30 2/ /0
10 E3 30 10.1.4.1/30
.1 /0/ P2
.3 0
.1
/3 G
0
10 E3
.1 /0/
.5 0
.1
/3
0
GE2/0/0 P3 GE4/0/0
30
10.1.2.2/30 10.1.12.2/30
.1 0
2/
.1 /0/
3.
GE1/0/0
10 E4
G
GE1/0/0 10.1.6.2/30
.1 /0
.7 /0
0
10.1.6.1/30
.1 E3
/3
P4
10 G
GE2/0/0
10.1.4.2/30
.1 /0
.8 /0
0
.1 E3
/3
10 G

Routers
10 G
GE1/0/0
0
.1 E2
.7 0
P5
/3
.1 /0/
.3 /0
.2
10.1.9.2/30
10 E3
.2 /0
/3
G
0 10 G
0
.1 E2
.8 0
/3
.1 /0/
.5 /0
.2
GE1/0/0
10 E3
.2 /0
/3
G
10.1.9.1/30 0
P6
PE1 GE1/0/0 GE1/0/0 PE3

10.1.10.1/30 10.1.12.1/30
G
10 E2
1/ /0
.1 /0/
3. /0
30
.1 2
.1 0
.1 E
1.
10 G
1/
30
1. Configure IP addresses for interfaces of each node, configure the IP addresses of loopback
interfaces that are used as LSR IDs, and configure IS-IS to implement IP connectivity.
2. Configure an MPLS TE tunnel between P nodes as the loop-free alternate (LFA) backup
path.
3. Enable IS-IS Auto FRR on P nodes so that traffic can be rapidly switched in the case of a
link fault. Disable the interfaces that connect P nodes to PE nodes from becoming LFA
backup interfaces and prevent traffic between P nodes from going back to PE nodes.
NOTE
This example uses two PEs (PE1 and PE3), three P nodes on each plane at the core layer, and one MPLS
TE tunnel between P1 and P3 as an example. In practice, there are far more PE nodes, P nodes, and MPLS
TE tunnels.
Procedure
Step 1 Assign IP addresses to interfaces.
# Configure PE1.
[PE1] interface gigabitethernet 1/0/0
[PE1-GigabitEthernet1/0/0] ip address 10.1.10.1 255.255.255.252
[PE1-GigabitEthernet1/0/0] quit
The IP address configurations of other nodes are similar to the IP address configuration of PE1,
and are not mentioned here.

Routers
Configure IS-IS on all the PE and P nodes. Configure IS-IS on P1 and PE1. The configurations
of other nodes are similar to the configurations of P1 and PE1, and are not mentioned here.
# Configure P1.
[P1] router id 1.1.1.1
[P1] isis 64
[P1-isis-64] network-entity 86.0010.0010.0100.1001.00
[P1-isis-64] is-level level-2
[P1-isis-64] cost-style wide
[P1-isis-64] is-name P1
[P1-isis-64] quit
[P1] interface loopback 0
[P1-LoopBack0] isis enable 64
[P1-LoopBack0] quit
[P1] interface gigabitethernet 1/0/0
[P1-GigabitEthernet1/0/0] isis enable 64
[P1-GigabitEthernet1/0/0] isis cost 5
[P1-GigabitEthernet1/0/0] quit
# Configure PE1.
[PE1] router id 7.7.7.7
[PE1] isis 64
[PE1-isis-64] network-entity 86.0010.0070.0700.7007.00
[PE1-isis-64] is-level level-2
[PE1-isis-64] cost-style wide
[PE1-isis-64] is-name PE1
[PE1-isis-64] quit
[PE1] interface loopback 0
[PE1-LoopBack0] isis enable 64
[PE1-LoopBack0] quit
[PE1-GigabitEthernet1/0/0] isis enable 64
[PE1-GigabitEthernet1/0/0] isis cost 5
[PE1-GigabitEthernet2/0/0] isis enable 64
[PE1-GigabitEthernet2/0/0] isis cost 5
After the preceding configurations, run the display ip routing-table command on each node,
and you can see that the nodes learn routes from each other. For example, when checking whether
there are routes to the IP address of Loopback 0 on PE1, you can see the following information:
[PE1] display ip routing-table 1.1.1.1 32
------------------------------------------------------------------------------
Summary Count : 1

Routers
Step 3 Configure an MPLS TE tunnel.

Enable MPLS, MPLS TE, and RSVP-TE on the interfaces of P1, P2, P3, and P4, and enable
CSPF on the ingress of the tunnel.
Configure P1 and P2. The configuration of P3 is similar to that of P1, and the configuration of
P4 is similar to that of P2.
# Configure P1.
[P1] mpls lsr-id 1.1.1.1
[P1] mpls
[P1-mpls] mpls te
[P1-mpls] mpls rsvp-te
[P1-mpls] mpls te cspf
[P1-mpls] quit
[P1-GigabitEthernet1/0/0] mpls
[P1-GigabitEthernet1/0/0] mpls te
[P1-GigabitEthernet1/0/0] mpls rsvp-te
# Configure P2.
[P2] mpls
[P2-mpls] mpls te
[P2-mpls] mpls rsvp-te
[P2-mpls] quit
# Configure an explicit path for the TE tunnel on P1. The configuration of P3 is similar to the
configuration of P1, and is not mentioned here.
[P1] explicit-path to_P3
[P1-explicit-path-to_p3] next hop 10.1.1.2
[P1-explicit-path-to_p3] quit
# Configure a tunnel interface on P1. The configuration of P3 is similar to the configuration of

P1, and is not mentioned here.
[P1] interface Tunnel1/0/0
[P1-Tunnel1/0/0] to_P3
[P1-Tunnel1/0/0] ip address unnumbered interface loopback0
[P1-Tunnel1/0/0] tunnel-protocol mpls te
[P1-Tunnel1/0/0] destination 3.3.3.3
[P1-Tunnel1/0/0] mpls te tunnel-id 100
[P1-Tunnel1/0/0] mpls te path explicit-path to_P3
[P1-Tunnel1/0/0] mpls te commit
After the preceding configurations, run the display interface tunnel 1/0/0 command on P1 and
P3, you can see that the status of the tunnel interface is Up.

Routers
[P1] display interface tunnel 1/0/0

Tunnel1/0/0 current state : UP
Line protocol current state : UP
Last up time: 2009-09-29, 16:35:10
Description : to_P3
Step 4 Configuring LDP over TE.
Enable MPLS LDP. Configure PE1, P1, P3, and P5. The configurations of other nodes are similar
to the configurations of PE1, P1, P3, and P5, and are not mentioned here.
# Configure PE1.
[PE1] mpls lsr-id 7.7.7.7
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1-GigabitEthernet1/0/0] mpls
[PE1-GigabitEthernet1/0/0] mpls ldp
# Configure P1.
[P1] mpls ldp
[P1-GigabitEthernet2/0/0] mpls ldp
[P1] mpls ldp remote-peer to_P3
[P1-mpls-ldp-remote-to_P3] remote-ip 3.3.3.3
[P1-mpls-ldp-remote-to_P3] quit
# Configure P3.
[P3] mpls ldp
[P3] mpls ldp remote-peer to_P1
[P3-mpls-ldp-remote-to_P1] remote-ip 1.1.1.1
[P3-mpls-ldp-remote-to_P1] quit
# Configure P5.
[P5] mpls
[P5-mpls] quit
[P5] mpls ldp
[P5-mpls-ldp] quit

Routers
# On the tunnel interface, enable forwarding adjacency and an IS-IS process, and adjust the
metric of the tunnel interface so that the tunnel interface can become the outbound interface of
the second best IS-IS route. The following uses the configuration of P1 as an example. The
configuration of P3 is similar to the configuration of P1, and is not mentioned here.
[P1] interface tunnel 1/0/0
[P1-Tunnel1/0/0] mpls te igp advertise
[P1-Tunnel1/0/0] mpls te igp metric absolute 6
[P1-Tunnel1/0/0] mpls te commit
[P1-Tunnel1/0/0] isis enable 1
After the preceding configuration, run the display mpls ldp lsp command on PE1, you can see
that an LDP LSP is established. Take the display on PE1 as an example.
[PE1] display mpls ldp lsp 8.8.8.8 32
LDP LSP Information

-------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop OutInterface
-------------------------------------------------------------------------------
8.8.8.8/32 NULL/3 - 10.1.10.2 GE1/0/0
8.8.8.8/32 1024/3 1.1.1.1 10.1.10.2 GE1/0/0
-------------------------------------------------------------------------------
TOTAL: 2 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 in GR state
A '*' before a NextHop means the LSP is FRR LSP
Step 5 Configure IS-IS Auto FRR.
Enable IS-IS Auto FRR on P1 and P3, and disable the interfaces that connect P nodes to PE
nodes from becoming IS-IS LFA backup interfaces.
# Configure P1.
[P1] isis 64
[P1-isis-64] frr
[P1-isis-64-frr] loop-free-alternate level-2
[P1-isis-64-frr] quit
[P1-isis-64] quit
[P1] interface gigabitethernet4/0/0
[P1-GigabitEthernet4/0/0] undo isis lfa-backup
# Configure P3.
[P3] isis 64
[P3-isis-64] frr
[P3-isis-64-frr] loop-free-alternate level-2
[P3-isis-64-frr] quit
[P3-isis-64] quit
[P3] interface gigabitethernet4/0/0
[P3-GigabitEthernet4/0/0] undo isis lfa-backup
# Run the display fib 3.3.3.3 32 verbose command on P1 to view the FIB entry to P3.

Routers
[P1] display fib 3.3.3.3 32 verbose

Nexthop : 10.1.2.2 OutIf : GE2/0/0
NexthopBak : 10.1.1.2 OutIfBak : Tunnel1/0/0
EntryRefCount : 0
VlanId : 0x0
LspBfdState : 0
# Run the shutdown command on GE2/0/0 of P1 or P3 to simulate a link fault. Take the
configuration of P1 as an example.
[P1-GigabitEthernet2/0/0] shutdown
# Run the display fib 3.3.3.3 32 verbose command on P1 to view the FIB entry to P3.
[P1] display fib 3.3.3.3 32 verbose
Nexthop : 10.1.1.2 OutIf : Tunnel1/0/0
EntryRefCount : 0
VlanId : 0x0
LspBfdState : 0
As shown in the command output, traffic from P1 to P3 has been switched to the backup link
with the outbound interface being Tunnel1/0/0.
----End
Configuration Files
l Configuration file of P1
#
sysname P1
#
router id 1.1.1.1

Routers
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path to_p3
next hop 10.1.1.2
next hop 10.1.4.2
next hop 10.1.6.1
next hop 3.3.3.3
#
mpls ldp
#
mpls ldp remote-peer to_p3
remote-ip 3.3.3.3
undo remote-ip pwe3
#
isis 64
frr
is-level level-2
cost-style wide
network-entity 86.0010.0010.0100.1001.00
is-name P1
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 64
#
interface Tunnel1/0/0
description toP3
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 3.3.3.3
mpls te tunnel-id 100
mpls te path explicit-path to_p3
mpls te igp advertise
mpls te igp metric absolute 6
mpls te commit
isis enable 64
#
ip address 10.1.1.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.2.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.3.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.10.2 255.255.255.252

Routers
isis enable 64
isis cost 5
undo isis lfa-backup
mpls
mpls ldp
#
return
#
sysname P2
#
router id 2.2.2.2
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0020.0200.2002.00
is-name P2
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 64
#
ip address 10.1.1.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.4.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls ldp
#
ip address 10.1.5.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.11.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
#
sysname P3
#

Routers
router id 3.3.3.3
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path to_p3
next hop 10.1.6.2
next hop 10.1.4.1
next hop 10.1.1.1
next hop 1.1.1.1
#
mpls ldp
#
mpls ldp remote-peer to_p1
remote-ip 1.1.1.1
undo remote-ip pwe3
#
isis 64
frr
is-level level-2
cost-style wide
network-entity 86.0010.0030.0300.3003.00
is-name P3
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 64
#
interface Tunnel1/0/0
description toP1
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 1.1.1.1
mpls te tunnel-id 100
mpls te path explicit-path to_p1
mpls te igp advertise
mpls te igp metric absolute 6
mpls te commit
isis enable 64
#
ip address 10.1.6.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.2.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.7.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#

Routers
ip address 10.1.12.2 255.255.255.252

isis enable 64
isis cost 5
undo isis lfa-backup
mpls
mpls ldp
#
return
#
sysname P4
#
router id 4.4.4.4
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0040.0400.4004.00
is-name P4
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
isis enable 64
#
ip address 10.1.6.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.4.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls ldp
#
ip address 10.1.8.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.13.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
#
sysname P5

Routers
#
router id 5.5.5.5
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0050.0500.5005.00
is-name P5
#
interface LoopBack0
ip address 5.5.5.5 255.255.255.255
isis enable 64
#
ip address 10.1.9.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.3.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.7.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
#
sysname P6
#
router id 6.6.6.6
#
mpls lsr-id 6.6.6.6
mpls
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0060.0600.6006.00
is-name P6
#
interface LoopBack0
ip address 6.6.6.6 255.255.255.255
isis enable 64
#
ip address 10.1.9.2 255.255.255.252
isis enable 64
isis cost 5
mpls

Routers
mpls ldp
#
ip address 10.1.5.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.8.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
l Configuration file of PE1

#
sysname PE1
#
router id 7.7.7.7
#
mpls lsr-id 7.7.7.7
mpls
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0070.0700.7007.00
is-name PE1
#
interface LoopBack0
ip address 7.7.7.7 255.255.255.255
isis enable 64
#
ip address 10.1.10.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.11.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return

#
sysname PE3
#
router id 8.8.8.8
#
mpls lsr-id 8.8.8.8
mpls
#
mpls ldp
#
isis 64

Routers
is-level level-2
cost-style wide
network-entity 86.0010.0080.0800.8008.00
is-name PE3
#
interface LoopBack0
ip address 8.8.8.8 255.255.255.255
isis enable 64
#
ip address 10.1.12.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
ip address 10.1.13.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
7.7.8 Example for Configuring Static BFD for IS-IS
As shown in Figure 7-32, three routers are interconnected using IS-IS, and RouterA and RouterB
communicate with each other through a Layer 2 switch. When the link between RouterA and
RouterB is faulty, the two routers need to rapidly respond to the fault and reestablish a neighbor
relationship.
Figure 7-32 Networking diagram of configuring static BFD for IS-IS
GE1/0/0 GE1/0/0 GE2/0/0

100.1.1.1/24 100.1.1.2/24 100.2.1.1/24
GE1/0/0
RouterA RouterB 100.2.1.2/24 RouterC
NOTE
BFD for IS-IS cannot be used to detect the multi-hop link between RouterA and RouterC, because the IS-
IS neighbor relationship cannot be established between RouterA and RouterC.
2. Enable static BFD for IS-IS on RouterA and RouterB so that routers can rapidly detect link
faults.

Routers
Procedure
not mentioned here.
[RouterA] isis 1
[RouterA-isis-1] network-entity aa.1111.1111.1111.00
[RouterB] isis 1
[RouterB-isis-1] network-entity aa.2222.2222.2222.00
[RouterC] isis 1
[RouterC-isis-1] network-entity aa.3333.3333.3333.00
# After the preceding configurations, you can see that the neighbor relationship is established
between RouterA and RouterB.
----------------------------
System Id Interface Circuit Id State HoldTime Type
PRI
2222.2222.2222 GE1/0/0 2222.2222.2222.00 Up 23s
L2 64
The IS-IS routing table of RouterA contains the routes to RouterB and RouterC.
-----------------------------
--------------------------------

Routers

-------------------------------------------------------------------------
100.1.1.0/24 10 NULL GE1/0/0 Direct D/-/L/-
100.2.1.0/24 20 NULL GE1/0/0 100.1.1.2 A/-/L/-
U-Up/Down Bit Set
Step 3 Configure BFD.
# Enable BFD on RouterA and configure a BFD session.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd atob bind peer-ip 100.1.1.2 interface gigabitethernet 1/0/0
[RouterA-bfd-session-atob] discriminator local 1
[RouterA-bfd-session-atob] discriminator remote 2
[RouterA-bfd-session-atob] commit
[RouterA-bfd-session-atob] quit
# Enable BFD on RouterB and configure a BFD session.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd btoa bind peer-ip 100.1.1.1 interface gigabitethernet 1/0/0
[RouterB-bfd-session-btoa] discriminator local 2
[RouterB-bfd-session-btoa] discriminator remote 1
[RouterB-bfd-session-btoa] commit
[RouterB-bfd-session-btoa] quit
After the preceding configurations, run the display bfd session command on RouterA or
RouterB, and you can see that the status of the BFD session is Up.
The following uses the display on RouterA as an an example.

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 2 100.1.1.2 Up S_IP_IF GE1/0/0
--------------------------------------------------------------------------------
Step 4 Enable IS-IS fast detect.
[RouterA-GigabitEthernet1/0/0] isis bfd static
[RouterB-GigabitEthernet1/0/0] isis bfd static
# Enable log information display on RouterA.

<RouterA> terminal logging
<RouterA> terminal monitor
# Run the shutdown command on GigabitEthernet1/0/0 on RouterB to simulate a link fault.


Routers
# On RouterA, you can view the following log and debugging information, which indicates that
IS-IS deletes the neighbor relationship with RouterB after being notified by BFD of the fault.
ISIS/4/PEER_DOWN_BFDDOWN/1880166931 UL/R "ISIS 1 neighbor
2222.2222.2222 was Down on interface GE1/0/0
because the BFD node was down. The Hello packet was received at 11:32:10 last
time; the maximum interval for sending Hello packets was 9247;the local router sent
426 Hello
packets and received 61 packets;the type of the Hello packet was Lan Level-2."
Run the display isis route command or the display isis peer command on RouterA, and you
can see that no information is displayed. This indicates that the IS-IS neighbor relationship
between RouterA and RouterB is deleted.
----End
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
network-entity aa.1111.1111.1111.00
#
ip address 100.1.1.1 255.255.255.0
isis enable 1
isis bfd static
#
bfd atob bind peer-ip 100.1.1.2 interface GigabitEthernet1/0/0
commit
#
return

#
sysname RouterB
#
bfd
#
isis 1
is-level level-2
#
ip address 100.1.1.2 255.255.255.0
isis enable 1
isis bfd static
#
ip address 100.2.1.1 255.255.255.0
isis enable 1
#
bfd btoa bind peer-ip 100.1.1.1 interface GigabitEthernet1/0/0
commit
#

Routers
return

#
sysname RouterC
#
isis 1
is-level level-2
#
ip address 100.2.1.2 255.255.255.0
isis enable 1
#
return
7.7.9 Example for Configuring Dynamic BFD for IS-IS
As shown in Figure 7-33, three routers are interconnected using IS-IS, and RouterA and RouterB
communicate with each other through a Layer 2 switch. When the link that passes through the
switch between RouterA and RouterB fails, the two routers need to rapidly respond to the fault,
and traffic can be switched to the link that passes through RouterC for forwarding.
Figure 7-33 Networking diagram of configuring dynamic BFD for IS-IS
RouterA GE2/0/0 GE2/0/0 RouterB GE3/0/0

3.3.3.1/24 3.3.3.2/24 172.16.1.1/24
GE1/0/0 GE1/0/0
1.1.1.1/24 2.2.2.2/24
GE1/0/0 GE1/0/0
1.1.1.2/24 2.2.2.1/24
RouterC
2. Set the IS-IS interface cost to control route selection of the routers to make the link that
passes through the switch from RouterA to RouterB as the primary link and the link that
passes through RouterC as the backup link.
3. Configure dynamic BFD for IS-IS on RouterA, RouterB, and RouterC so that link faults
can be detected rapidly and traffic can be switched to the backup link for forwarding.

Routers
Procedure
not mentioned here.
[RouterA] isis
[RouterB] isis
[RouterC] isis
[RouterC] interface gigabitEthernet 1/0/0
# After the preceding configurations, run the display isis peer command. You can see that the
neighbor relationships are established between RouterA and RouterB, and between RouterA and
RouterC. The following uses the configuration of RouterA as an example.

Routers
----------------------------
0000.0000.0002 GE2/0/0 0000.0000.0002.01 Up 9s L2 64
0000.0000.0003 GE1/0/0 0000.0000.0001.02 Up 21s L2 64
Total Peer(s): 2
# Routers have learned routes from each other. The following uses the routing table of
RouterA as an example.
------------------------------------------------------------------------------
As shown in the routing table, the next-hop address of the route to 172.16.1.0/24 is 3.3.3.2, and
traffic is transmitted on the primary link RouterARouterB.
Step 3 Set the interface cost.
[RouterA-GigabitEthernet1/0/0] isis cost 5
[RouterB-GigabitEthernet1/0/0] isis cost 5
Step 4 Configure BFD for IS-IS processes.
# Enable BFD for IS-IS on RouterA.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] isis
[RouterA-isis-1] bfd all-interfaces enable
# Enable BFD for IS-IS on RouterB.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] isis
[RouterB-isis-1] bfd all-interfaces enable
# Enable BFD for IS-IS on RouterC.

[RouterC] bfd
[RouterC-bfd] quit
[RouterC] isis
[RouterC-isis-1] bfd all-interfaces enable

Routers
# After the preceding configurations, run the display isis bfd session all command on RouterA,
RouterB, and RouterC. You can see that the BFD session status is Up.
The following uses the display on RouterA as an example.

[RouterA] display isis bfd session all
BFD session information for ISIS(1)
-----------------------------------
Peer System ID : 0000.0000.0002 Interface : GE2/0/0
RX : 1000 LocDis : 8193 Local IP Address: 3.3.3.1
Multiplier : 3 RemDis : 8192 Type : L2
Diag : No diagnostic information
Total BFD session(s): 2
As shown in the preceding display, the status of the BFD session between RouterA and
RouterB and that between RouterA and RouterC is Up.
Step 5 Configure BFD for IS-IS interfaces.
# Configure BFD on GE2/0/0 of RouterA, set the minimum interval for sending packets to 100
ms, the minimum interval for receiving packets to 100 ms, and the local detection multiplier to
4.
[RouterA-GigabitEthernet2/0/0] isis bfd enable
[RouterA-GigabitEthernet2/0/0] isis bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
# Configure BFD on GE2/0/0 of RouterB, set the minimum interval for sending packets to 100
ms, the minimum interval for receiving packets to 100 ms, and the local detection multiplier to
4.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB-GigabitEthernet2/0/0] isis bfd enable
[RouterB-GigabitEthernet2/0/0] isis bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
# After the preceding configurations, run the display isis bfd session all command on RouterA
or RouterB. You can see that the BFD parameters have taken effect. The following uses the
display on RouterB as an example.
[RouterB] display isis bfd session all
-----------------------------------
TX : 100 BFD State : up Peer IP Address : 3.3.3.1

Routers
# Run the shutdown command on GigabitEthernet2/0/0 of RouterB to simulate a primary link

failure.
Step 7 # View the routing table of RouterA.

------------------------------------------------------------------------------
As shown in the routing table, the backup link RouterARouterCRouterB takes effect after
the primary link fails, and the next-hop address of the route to 172.16.1.0/24 becomes 1.1.1.2.
# Run the display isis bfd session all command on RouterA. You can see that the status of the
BFD session between RouterA and RouterC is Up.
[RouterA] display isis bfd session all
-----------------------------------
----End
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
#
ip address 1.1.1.1 255.255.255.0
isis enable 1
#
ip address 3.3.3.1 255.255.255.0
isis enable 1

Routers
isis cost 5
isis bfd enable
isis bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
#
return

#
sysname RouterB
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#
ip address 2.2.2.2 255.255.255.0
isis enable 1
#
ip address 3.3.3.2 255.255.255.0
isis enable 1
isis cost 5
isis bfd enable
isis bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
#
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0003.00
#
ip address 1.1.1.2 255.255.255.0
isis enable 1
#
ip address 2.2.2.1 255.255.255.0
isis enable 1
#
return

This section describes common faults caused by incorrect IS-IS configurations and provides the

Routers
7.8.1 Failed to Establish IS-IS Neighbor Relationships
Fault Symptom
IS-IS neighbor relationship fails to be established when the link is working properly.
Procedure
Step 1 Check whether devices on both ends of the link have the matching IS-IS levels.
l Run the display current-configuration configuration isis | include is-level command to
check the level configurations of IS-IS processes on both ends.
l Run the display current-configuration interface interface-type interface-number | include
isis circuit-level command to check the IS-IS level configuration of the specified interface.
IS-IS neighbor relationship can be established when IS-IS interfaces on both ends of the link
have the matching IS-IS levels.
NOTE
If you cannot view the IS-IS level of an interface using the display current-configuration interface
interface-type interface-number | include isis circuit-level command, the interface uses the default IS-IS
level. To view the default IS-IS level, run the display default-parameter isis command to check the
Circuit-Level field.
Requirements on the IS-IS levels of interfaces on both ends of a link are as follows:
l If the IS-IS level of the local interface is Level-1, the IS-IS level of the remote interface must be
Level-1 or Level-1-2.
l If the IS-IS level of the local interface is Level-2, the IS-IS level of the remote interface must be
Level-2 or Level-1-2.
l If the IS-IS level of the local interface is Level-1-2, the IS-IS level of the remote interface can be
Level-1, Level-2, or Level-1-2.
If the IS-IS levels of interfaces on both ends of a link do not match, perform either of the following
operations to change the IS-IS level:
l Run the is-level command in the IS-IS view to change the global IS-IS level.
l Run the isis circuit-level command in the interface view to change the interface IS-IS level.
Step 2 Check whether devices on both ends of the link have the matching area addresses.
Run the display current-configuration configuration isis command to check area address
information.
NOTE
If IS-IS Level-1 neighbor relationship needs to be established between devices on both ends, ensure that
the two devices reside in the same area.
A maximum of three area addresses can be configured for an IS-IS process. Devices on both ends can
establish IS-IS Level-1 neighbor relationship when the two devices have a same area address.
When IS-IS Level-2 neighbor relationship needs to established between the two devices, the two devices
can have the same or different area addresses.
If the area addresses of the two devices are different, run the network-entity command in the
IS-IS view to set the same area address for the two devices.
Step 3 Check whether devices on both ends of the link have the authentication mode.

Routers
Run the display current-configuration interface interface-type interface-number | include isis

authentication-mode command to check the IS-IS authentication modes of the interfaces on
both ends of the link.
If the two interfaces use different authentication modes, run the isis authentication-mode
command in the view of one interface to ensure that this interface has the same authentication
mode and password as the other interface.
----End
7.8.2 A Device Cannot Learn IS-IS Routes from Its Neighbor
Fault Symptom
A device cannot learn IS-IS routes from its neighbor when its link is working properly.
Procedure
Step 1 Check whether IS-IS neighbor relationship has been established between the device and its
neighbor.
Run the display isis peer command on each device on the link to check whether IS-IS neighbor
relationship has been established.
If IS-IS neighbor relationship is not established, rectify the fault according to 7.8.1 Failed to
Establish IS-IS Neighbor Relationships.
Step 2 Check whether the IS-IS routing table of the device is correct.
Run the display isis route command on the device to check the IS-IS routing table.
1. If the IS-IS routing table contains specified routes, run the display ip routing-table ip-
address [ mask | mask-length ] verbose command to check whether the IP routing table
contains routes with higher protocol preference than IS-IS routes.
NOTE
If the State field of a route displays Active Adv, the route is active. If there are routes that have the
same prefix but are discovered by different routing protocols, routes with higher protocol preference
are preferred as active routes.
2. If the IP routing table contains routes with higher protocol preference than IS-IS routes,
modify the configuration based on network planning.
Step 3 Check whether the device and its neighbor have the matching IS-IS cost style.
Run the display current-configuration configuration isis command on the device and its
neighbor to check the IS-IS cost style.

Routers
NOTE
The device can learn IS-IS routes from its neighbor when it has the same IS-IS cost style as its neighbor.
The IS-IS cost style of a device can be set as follows:
l narrow: indicates that the device can receive and send packets with cost style narrow.
l narrow-compatible: indicates that the device can receive packets with cost style narrow or wide but
sends only packets with cost style narrow.
l compatible: indicates that the device can receive and send packets with cost style narrow or wide.
l wide-compatible: indicates that the device can receive packets with cost style narrow or wide but sends
only packets with cost style wide.
l wide: indicates that the device can receive and send packets with cost style wide.
If the IS-IS cost styles of both ends are set to narrow and wide (or wide-compatible) respectively, the two
ends cannot communicate.
If the IS-IS cost styles of both ends are set to narrow-compatible and wide respectively, the two ends cannot
communicate either.
If the device and its neighbor have mismatching IS-IS cost styles, run the cost-style command
on the device to modify the configuration.
----End
7.9 FAQ
7.9.1 Why Does the IS-IS Neighbor Relationship Fail to Be

Established on the DSLAM?
Figure 7-34 shows the actual networking.
Figure 7-34 Networking
RouterA DSLAM RouterB

GE1/0/0 PON1/0/0
IS-IS transmits BPDU packets whose MAC address is in 0180-C2##-####-#### format. BPDU
packets are reserved multicast packets at the link layer and need to carry VLAN tags when
transparently transmitted by the DSLAM. IS-IS Hello packets do not carry VLAN tags when
being transmitted through Layer 3 GE interfaces; therefore, the DSLAM fails to transparently
transmit IS-IS Hello packets. The PON interface receives no IS-IS Hello packet from the peer
end, so the PON interface fails to establish the neighbor relationship.
To address this problem, configure the GE interface as a subinterface which allows packets to
carry VLAN tags so that the DSLAM can transparently transmit these packets.
NOTE
The DSLAM adds VLAN tags to packets sent by a PON interface.

Routers
7.9.2 When Configured with a Link State Protocol, Why Can the
Local Device Not Establish Neighbor Relationship with the Peer
Device?
When the local device is configured with a link state protocol, first check the type of the interface
on the peer device.
l To set the network type for an OSPF interface, run the ospf network-type command.
l To set the network type of an IS-IS interface to P2P, run the isis circuit-type p2p command.
The network types of the interfaces on both ends of a link must be the same; otherwise, the
neighbor relationship cannot be established.
7.10 References
This section lists references of IS-IS.
Table 7-10 The following table lists the references of this document.
ISO 10589 ISO IS-IS Routing Protocol -
ISO 8348/Ad2 Network Services Access Points -
RFC 1195 Use of OSI IS-IS for Routing in TCP/IP Multiple

and Dual Environments authentication
passwords are not
supported.
RFC 2763 Dynamic Hostname Exchange -

Mechanism for IS-IS
RFC 2966 Domain-wide Prefix Distribution with -

Two-Level IS-IS
RFC 2973 IS-IS Mesh Groups -
RFC 3277 IS-IS Transient Blackhole Avoidance -
RFC 3373 Three-Way Handshake for IS-IS Point- -

to-Point Adjacencies
RFC 3567 Intermediate System to Intermediate -

System (IS-IS) Cryptographic
Authentication
RFC 3719 Recommendations for Interoperable -

Networks using IS-IS
RFC 3784 IS-IS extensions for Traffic -

Engineering

Routers
RFC 3786 Extending the Number of IS-IS LSP -

Fragments Beyond the 256 Limit
RFC 3787 Recommendations for Interoperable IP -

RFC 3847 Restart signaling for IS-IS -
RFC 3906 Calculating Interior Gateway Protocol -

(IGP) Routes Over Traffic Engineering
Tunnels
RFC 4444 Management Information Base for IS- -

IS
RFC 5120 Multi Topology (MT) Routing in IS-IS -
draft-ietf-IS-IS-ipv6-05 Routing IPv6 with IS-IS -
draft-ietf-IS-IS-wg-multi- M-IS-IS: Multi Topology (MT) -

topology-11 Routing in IS-IS
draft-ietf-isis-admin- Admin Tag -

tags-02(Admin Tag)

Routers
8 IPv6 IS-IS Configuration
About This Chapter
You can build an IPv6 IS-IS network to allow IS-IS to discover and calculate routes in an
autonomous system (AS). IS-IS applies to large and medium networks.

8.2 Principles
This section describes only the differences between IS-IS for IPv6 and IS-IS. For details about
the IS-IS implementation principles, see 7.2 Principles.





This section describes IS-IS for IPv6 configuration examples, including networking
requirements, configuration roadmap, and configuration procedure.
8.8 References
This section lists references of IS-IS(IPv6).

Routers

Definition
Intermediate System-to-Intermediate System (IS-IS) is an Interior Gateway Protocol (IGP) that
runs within an autonomous system (AS). IS-IS is also a link-state routing protocol, using the
shortest path first (SPF) algorithm to calculate routes.
Purpose
IS-IS is a dynamic routing protocol initially designed by the International Organization for
Standardization (ISO) for its Connectionless Network Protocol (CLNP).
To support IP routing, the Internet Engineering Task Force (IETF) extended and modified IS-
IS in RFC 1195. This modification enables IS-IS to apply to TCP/IP and OSI environments.
This type of IS-IS is called Integrated IS-IS or Dual IS-IS.
NOTE
IS-IS stated in this document refers to Integrated IS-IS, unless otherwise stated.
In addition to IPv4 networks, IS-IS also applies to IPv6 networks to provide accurate routing
information for IPv6 packets. IS-IS has good scalability, supports IPv6 network layer protocols,
and is capable of discovering, generating, and forwarding IPv6 routes.
8.2 Principles
This section describes only the differences between IS-IS for IPv6 and IS-IS. For details about
the IS-IS implementation principles, see 7.2 Principles.
8.2.1 IS-IS IPv6

IS-IS is a link-state dynamic routing protocol initially designed by the OSI. To support IPv4
routing, IS-IS is applied to IPv4 networks and called as Integrated IS-IS.
As IPv6 networks are built, IS-IS also needs to provide accurate routing information for IPv6
packet forwarding. IS-IS has good scalability, supports IPv6 network layer protocols, and is
capable of discovering, generating, and forwarding IPv6 routes.
Extended IS-IS for IPv6 is defined in the draft-ietf-isis-ipv6-05 of the IETF. To process and
calculate IPv6 routes, IS-IS uses two new TLVs and one network layer protocol identifier
(NLPID).
The two TLVs are as follows:
l TLV 236 (IPv6 Reachability): describes network reachability by defining the route prefix
and metric.
l TLV 232 (IPv6 Interface Address): is similar to the IP Interface Address TLV of IPv4,
except that it changes a 32-bit IPv4 address to a 128-bit IPv6 address.

Routers
The NLPID is an 8-bit field that identifies the protocol packets of the network layer. The NLPID
of IPv6 is 142 (0x8E). If IS-IS supports IPv6, it advertises routing information through the
NLPID value.
8.2.2 IS-IS MT
During the transition from IPv4 networks to IPv6 networks, IPv4 topologies and IPv6 topologies
must coexist for a long time. The IPv4/IPv6 dual stack is a widely used technology that is
applicable to IPv4 networks and IPv6 networks. The function is that a router that supports only
IPv4 or IPv6 can communicate with a router that supports both IPv4 and IPv6.
Background
IS-IS implements IPv6 by extending TLV and complies with the rules for establishing and
maintaining neighbor databases and topology databases as defined in ISO 10589 and RFC 1195.
As a result, IPv4 networks and IPv6 networks have the same topology. The mixed topology of
IPv4 and IPv6 is considered as an integrated topology, which utilizes the SPT to perform the
SPF calculation. This requires that IPv6 and IPv4 topology information should be consistent.
In actual applications, the deployment of IPv4 and IPv6 may be different on the network;
therefore, information about IPv4 topologies may be different from information about IPv6
topologies. Some routers and links in a mixed topology do not support IPv6. However, routers
that support the IPv4/IPv6 dual stack in the mixed topology cannot sense the routers or links,
and still forward IPv6 packets to them. As a result, the IPv6 packets are discarded. Similarly,
when routers and links that do not support IPv4 exist in the topology, IPv4 packets cannot be
forwarded.
IS-IS multi-topology (MT) can be used to solve the preceding problems. IS-IS MT is an extension
of IS-IS to support multiple topologies, complying with draft-ietf-IS-IS-wg-multi-topology. IS-
IS MT defines new TLVs in IS-IS packets, transmits MT information, and performs separate
SPF calculation in different topologies.
Principles
IS-IS MT refers to multiple separate IP topologies that are run in an IS-IS AS, such as IPv4
topology and IPv6 topology. The separate IP topologies are not considered as an integrated and
single topology. This is helpful for calculating IS-IS routes of separate IPv4 networks and IPv6
networks. Based on the IP protocols supported by links, separate SPF calculation is performed
in different topologies to shield networks from each other.
Figure 8-1 shows the IS-IS MT. Values in Figure 8-1 indicate link costs. RouterA, RouterC,
and RouterD support the IPv4/IPv6 dual stack. RouterB supports only IPv4 and cannot forward
IPv6 packets.
If RouterA does not support IS-IS MT, only the single topology is considered during SPF
calculation. The shortest path from RouterA to RouterC is RouterA->RouterB->RouterC.
However, RouterB does not support IPv6. IPv6 packets sent from RouterA cannot be forwarded
by RouterB to RouterC.
If IS-IS MT is enabled on RouterA, RouterA performs SPF calculation in different topologies.

When RouterA needs to send IPv6 packets to RouterC, RouterA chooses only IPv6 links to
forward IPv6 packets. The shortest path from RouterA to RouterC changes to RouterA-
>RouterD->RouterC. IPv6 packets are then forwarded.

Routers
Figure 8-1 IS-IS MT networking

RouterA RouterB
4
IPv4/IPv6 IPv4
6 3
5
IPv4/IPv6 IPv4/IPv6
RouterD RouterC
IS-IS MT is implemented as follows:
1. Setting up topologies: Neighbors are set up by exchanging various packets for setting up
MTs.
2. Performing the SPF calculation: The SPF calculation is performed for different MTs.

Table 8-1 describes the IS-IS configuration tasks.
Table 8-1 IS-IS configuration tasks
Configuring basic IS-IS To deploy the IS-IS protocol 8.5.1 Configuring Basic
functions on IPv6 networks, configure IPv6 IS-IS Functions
basic IS-IS functions to
enable communication
between different nodes on
the network. Other IS-IS
features can only be
configured after the basic
functions are configured.

Routers
Configuring IS-IS network On IS-IS networks, 8.5.2 Improving IPv6 IS-IS

security unauthorized users can attack Network Security
the IS-IS network by
carried on IS-IS networks,
configure the area or domain
authentication and interface
authentication.
Configuring IS-IS route If multiple redundant links 8.5.3 Controlling IPv6 IS-
selection are available in the network IS Route Selection
using the IS-IS protocol, the
route in the IS-IS routing
table may not be the expected
optimal route. This does not
meet the network planning
and traffic management
requirements. To optimize
the IS-IS network and
facilitate traffic
management, more accurate
control of the routes on the
network is required.
Configuring IS-IS routing In practical applications, to 8.5.4 Controlling IPv6 IS-

information exchange meet network requirements, IS Route Exchange
configure route policies to
accurately control
advertising and receiving of
IS-IS routing information.

Routers
Configuring IS-IS route Route aggregation allows 8.5.5 Configuring IPv6 IS-
aggregation multiple routes with the same IS Route Summarization
IP prefix to be aggregated
into one route.
Route aggregation on a large
IS-IS network can effectively
reduce entries in the routing
table. This minimizes system
resource consumption and
facilitates management. In
addition, if a link in the
aggregated IP address
segment frequently alternates
between Up and Down,
devices outside this segment
will not be affected by the
change. This prevents route
flapping and improves
network stability.
Configuring IS-IS route To enable IS-IS to rapidly 8.5.6 Controlling IPv6 IS-
convergence detect the network changes, IS Route Convergence
speed up the IS-IS network
down the IS-IS network
convergence.
Configuring LSP fragment When information contained 8.5.7 Configuring LSP

extension in the LSP data packet Fragment Extension
Protocol Data Unit (PDU) to
be advertised by IS-IS
increases greatly, the IS-IS
device will generate multiple
LSP fragments to carry and
advertise more information.

Routers
Configuring mesh groups On the NBMA network, 8.5.8 Configuring a Mesh

when an interface of the Group on an NBMA
router receives a new LSP, Network
the LSP is flooded to other
interfaces of the router. On
highly-connected networks
that have multiple P2P links,
this processing method
results in repeated LSP
flooding and wastes
To solve this problem, create
a mesh group and add some
interfaces to the group. The
router never floods the LSPs
received at interfaces in the
mesh group to other
interfaces from the same
group, and only floods the
LSPs to interfaces from other
groups or interfaces that are
not configured to any mesh
groups.
Configuring IS-IS overload If the system cannot store 8.5.9 Configuring the
new LSPs or synchronize the Overload Bit for an IS-IS
LSDB normally, the Device
calculated routing
information will be incorrect.
In this case, the system can
enter the overload state.
Routes reached through the
device will not be calculated,
but routes directly connected
to the device will not be
ignored.
When an IS-IS device on the
network requires upgrade or
maintenance, the device
needs to be temporarily
isolated from the network. To
prevent other devices from
forwarding traffic through
this node, set the overload bit
for the device in question.

Routers

Table 8-2 describes the default configuration of IPv6 IS-IS.
Table 8-2 Default configuration of IPv6 IS-IS
IS-IS Disabled
DIS priority 64
Device level Level-1-2
Interval for sending Hello packets 10s
Minimum interval for sending LSPs 50ms
Maximum number of LSPs to be sent 10
Interval for updating LSPs 900s
Maximum lifetime of LSPs 1200s
Bandwidth reference value 100Mbit/s

8.5.1 Configuring Basic IPv6 IS-IS Functions

An IS-IS network can be set up only after basic IS-IS functions are configured.
Before configuring basic IPv6 IS-IS functions, complete the following tasks:
l Enabling the IPv6 forwarding capability on the device

l Configuring IPv6 addresses for interfaces to ensure that neighboring nodes are reachable
at the network layer
Creating an IS-IS process is the prerequisite for configuring a network entity title (NET),
configuring the device level, and establishing an IS-IS neighbor relationship.

Routers
8.5.1.1 Creating IS-IS Processes
Context
Creating IS-IS processes is the prerequisite for performing the IS-IS configuration.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
An IS-IS process is created, and the IS-IS process view is displayed.
The process-id parameter specifies the ID of an IS-IS process. The default value of process-id
is 1.

description text
Description for the IS-IS process is configured.
----End
8.5.1.2 Configuring a NET and Enabling IPv6 IS-IS
Context
NET is the special form of the network service access point (NSAP). After the IS-IS view is
displayed, IS-IS can start only when a NET is configured for an IS-IS process.
Generally, you only need to configure one NET for an IS-IS process. When an area needs to be
redefined, for example, the area needs to be merged with other areas or divided into sub-areas,
configure multiple NETs to ensure route correctness. A maximum of three area addresses can
be configured for an IS-IS process. Therefore, a maximum of three NETs can be configured for
an IS-IS process. When configuring multiple NETs, ensure that their system IDs are the same.
IS-IS can run on an IPv6 topology only when IPv6 is enabled on an IS-IS process.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

Routers
Step 3 Run:
network-entity net
A NET is configured.
NOTE
Configuring loopback interface addresses based on NETs is recommended to ensures that a NET is unique
on the network. If NETs are not unique, route flapping will easily occur.
An area ID is used to uniquely identify an area in the same IS-IS domain. All routers in the same Level-1
area must share the same area ID, while routers in the same Level-2 area can have different area IDs.
Step 4 Run:
ipv6 enable
IPv6 is enabled for the IS-IS process.
----End
8.5.1.3 Configuring the Device Level
Context
Configure the device level according to network planning requirements:
l When the level of a device is Level-1, the device establishes neighbor relationships with
only Level-1 and Level-1-2 routers in the same area and maintains only Level-1 LSDBs.
l When the level of a device is Level-2, the device can establish neighbor relationship with
Level-2 routers in the same area or different areas and with Level-1-2 routers in different
areas and maintain only Level-2 LSDB.
l When the level of a device is Level-1-2, the device can establish neighbor relationships
with Level-1 and Level-2 routers and maintain Level-1 and Level-2 LSDBs.
NOTICE
If the levels of IS-IS devices are changed during network operation, the IS-IS process will be
restarted and IS-IS neighbor relationships will be disconnected. Setting the levels of devices
when configuring IS-IS is recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ]

Step 3 Run:
is-level { level-1 | level-1-2 | level-2 }

Routers
The level of the router is configured.
By default, the level of the router is Level-1-2.
----End
8.5.1.4 Establishing IS-IS Neighbor Relationships
Context
The methods to establish IS-IS neighbor relationships on a broadcast network and a P2P network
are different. Therefore, you need to set different IS-IS attributes for interfaces of different types:
l On a broadcast network, IS-IS needs to select the designated intermediate system (DIS).
You can set the DIS priority for IS-IS interfaces to enable the device with the highest DIS
priority to be elected as the DIS.
l On a P2P network, IS-IS does not need to select the DIS. Therefore, the DIS priority does
not need to be configured for interfaces. To ensure P2P link reliability, configure IS-IS to
establish neighbor relationships on P2P interfaces in 3-way mode for unidirectional link
fault detection.
Generally, IS-IS checks the IP addresses of received Hello packets. Neighbor relationships
can be established only when the IP address carried in a received Hello packet and the
address of the interface that receives the Hello packet are on the same network segment. If
the IP addresses of the two P2P interfaces are on different network segments, and the isis
peer-ip-ignore command is run on the two interfaces, IS-IS does not check the peer IP
address. The neighbor relationship can be correctly established on the two P2P interfaces.
Procedure
l Establish an IS-IS neighbor relationship on a broadcast link.
1. Run:
system-view

2. Run:

3. Run:
ipv6 enable
IPv6 is enabled on the interface.

4. Run:
isis ipv6 enable [ process-id ]
After this command is run, IS-IS establishes neighbor relationships and floods LSPs
through this interface.

Routers
NOTE
Loopback interfaces are not used to establish neighbor relationships. If IS-IS is enabled on a
loopback interface, IS-IS advertises the routes of the network segment where the interface
resides through other IS-IS interfaces.
5. Run:

By default, the level of an interface is Level-1-2.
When two Level-1-2 devices establish IS-IS neighbor relationship, they establish both
Level-1 and Level-2 neighbor relationships. To allow the two Level-1-2 devices to
establish only Level-1 or Level-2 neighbor relationship, change the level of interfaces.
NOTE
Changing the level of an IS-IS interface is valid only when the level of the IS-IS device is
Level-1-2. If the level of the device is not Level-1-2, the level of the device determines the
level of the established neighbor relationship.
6. (Optional) Run:
isis dis-priority priority [ level-1 | level-2 ]
The DIS priority is set for the interface. A larger value indicates a higher priority.
By default, the DIS priority of Level-1 and Level-2 broadcast interfaces is 64.
7. (Optional) Run:
isis silent [ advertise-zero-cost ]
The interface is suppressed.

By default, an IS-IS interface is not suppressed.
When an IS-IS interface is suppressed, the interface no longer sends or receives IS-
IS packets. The routes of the network segment where the interface resides, however,
can still be advertised to other IS-IS devices within the same AS.
l Establish an IS-IS neighbor relationship on a P2P link.
1. Run:
system-view

2. Run:

3. Run:
ipv6 enable

4. Run:
isis ipv6 enable [ process-id ]
IS-IS IPv6 is enabled on the interface.

5. Run:

Routers
By default, the level of an interface is Level-1-2.

6. Run:
The network type of the interface is set to P2P.
By default, the network type of an interface is determined by the physical type of the
interface.
When the network type of an IS-IS interface changes, the interface configuration
changes accordingly:
After a broadcast interface is simulated as a P2P interface using the isis circuit-
type p2p command, the interval for sending Hello packets, number of Hello
Down, interval for retransmitting LSPs on a P2P link, and various IS-IS
authentication modes are restored to the default settings; other configurations such
as the DIS priority, DIS name, and interval for sending CSNPs on a broadcast
network become invalid.
After the undo isis circuit-type command is run to restore the default network
type of an IS-IS interface, the interval for sending Hello packets, number of Hello
Down, interval for retransmitting LSPs on a P2P link, various IS-IS authentication
modes, DIS priority, and interval for sending CSNPs on a broadcast network are
restored to the default settings.
7. Run:
isis ppp-negotiation { 2-way | 3-way [ only ] }
The negotiation mode is specified for the interface.
By default, the negotiation mode is 3-way.

8. Run:
isis peer-ip-ignore
IS-IS is configured not to check the IP addresses of received Hello packets.
By default, IS-IS checks the IP addresses of received Hello packets.

9. Run:
isis ppp-osicp-check
OSICP negotiation status check is configured on the interface.
By default, the OSICP negotiation status of a PPP interface does not affect the status
of an IS-IS interface.
NOTE
This command applies only to PPP interfaces and is invalid for other P2P interfaces.
After this command is run, the OSICP negotiation status of a PPP interface affects the status
of an IS-IS interface. When PPP detects that the OSI network fails, the link status of the IS-IS
interface goes Down and the routes of the network segment where the interface resides are not
advertised through LSPs.
----End

Routers
Procedure
l Run the display isis peer [ verbose ] [ process-id | vpn-instance vpn-instance-name ]
command to check information about IS-IS neighbors.
name ] command to check information about IS-IS interfaces.
l Run the display isis route [ process-id | vpn-instance vpn-instance-name ] ipv6
[ verbose | [ level-1 | level-2 ] | ipv6-address [ prefix-length ] ] * command to check
information about IS-IS routes.
----End
8.5.2 Improving IPv6 IS-IS Network Security

On an IS-IS network that requires high security, configure IS-IS authentication to improve IS-
IS network security.
Before improving IS-IS network security, complete the following task:
l 8.5.1 Configuring Basic IPv6 IS-IS Functions
8.5.2.1 Configuring Interface Authentication
Context
After the IS-IS interface authentication is configured, authentication information can be

encapsulated into the Hello packet to confirm the validity and correctness of neighbor
relationships.
NOTICE
If plain is selected during the configuration of the authentication mode for the IS-IS interface,
the password is saved in the configuration file in plain text. This brings security risks. It is

Routers
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run any of the following command to configure the authentication mode of the IS-IS interface
as required:
l Run:
isis authentication-mode simple { plain plain-text | [ cipher ] plain-cipher-
text } [ level-1 | level-2 ] [ ip | osi ] [ send-only ]
Simple authentication is configured for the IS-IS interface.

l Run:
isis authentication-mode md5 { plain plain-text | [ cipher ] plain-cipher-text }
[ level-1 | level-2 ] [ ip | osi ] [ send-only ]
MD5 authentication is configured for the IS-IS interface.

l Run:
isis authentication-mode hmac-sha256 key-id key-id { plain plain-text |
[ cipher ] plain-cipher-text } [ level-1 | level-2 ] [ send-only ]
HMAC-SHA256 authentication is configured for the IS-IS interface.

l Run:
isis authentication-mode keychain keychain-name [ level-1 | level-2 ] [ send-
only ]
The Keychain authentication is configured for the IS-IS interface.

By default, an IS-IS interface does not authenticate received Hello packets and no authentication
password is configured on the interface.
NOTE
Use the send-only parameter according to network requirements:

l If the send-only parameter is specified, the device only encapsulates the Hello packets to be sent with
authentication information rather than checks whether the received Hello packets pass the
authentication. When the Hello packets do not need to be authenticated on the local device and pass
the authentication on the remote device, the two devices can establish the neighbor relationship.
l If the send-only parameter is not specified, ensure that passwords of all interfaces with the same level
on the same network are the same.
Parameters level-1 and level-2 apply only to the WAN-side Ethernet interfaces and LAN-side VLANIF
interfaces on which IS-IS is enabled using the isis ipv6 enable command.
----End
8.5.2.2 Configuring Area or Domain Authentication
Context

Routers
The area authentication password is encapsulated into Level-1 IS-IS packets. Only the packets
that pass the area authentication can be accepted. Therefore, you must configure IS-IS area
authentication on all the IS-IS devices in the specified Level-1 area to authenticate the Level-1
area.
The domain authentication password is encapsulated into Level-2 IS-IS packets. Only the
packets that pass the domain authentication can be accepted. Therefore, you must configure IS-
IS domain authentication on all the IS-IS devices in the Level-2 area to authenticate Level-2
area.
NOTICE
If plain is selected during the configuration of the area authentication mode or domain
authentication mode, the password is saved in the configuration file in plain text. This brings
security risks. It is recommended that you select cipher to save the password in cipher text.
NOTE
When configuring IS-IS authentication, the area or domain authentication modes and passwords of the
routers in the same area must be consistent so that IS-IS packets can be flooded normally.
Whether IS-IS packets can pass area or domain authentication does not affect the establishment of Level-1
or Level-2 neighbor relationships.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Perform the following operations at any sequence as required.

l Run:
area-authentication-mode { { simple | md5 } { plain plain-text | [ cipher ]
The area authentication mode is configured.

l Run:
domain-authentication-mode { { simple | md5 } { plain plain-text | [ cipher ]
The domain authentication mode is configured.

Routers
NOTE
The authentication involves the following situations:

l The device encapsulates the authentication mode into LSPs and SNPs to be sent and checks whether
the received packets pass authentication. Then, the device discards the packets that do not pass the
authentication. In this case, the parameter snp-packet or all-send-only is not specified.
l The device encapsulates authentication information into LSPs to be sent and checks whether the
received LSPs pass the authentication; the device neither encapsulates the SNPs to be sent with
authentication information nor checks whether the received SNPs pass the authentication. In this case,
the parameter snp-packet authentication-avoid needs to be specified.
l The device encapsulates the LSPs and SNPs to be sent with authentication information; the device,
however, checks the authentication mode of only the received LSPs rather than the received SNPs. In
this case, the parameter snp-packet send-only needs to be specified.
l The device encapsulates the LSPs and SNPs to be sent with authentication information, but does not
check whether the received LSPs or SNPs pass the authentication. In this case, the parameter all-send-
only needs to be specified.
----End
8.5.2.3 Configuring the Optional Checksum
Context
When a network is running, Intermediate System to Intermediate System (IS-IS) routers may be
attacked or IS-IS packets may be modified. As a result, important network information may be
intercepted, causing serious loss to the network. The optional checksum encapsulates optional
checksum TLVs into the Complete Sequence Numbers Protocol Data Units (CSNPs), Partial
Sequence Number Protocol Data Units (PSNPs), and Hello packets sent by IS-IS routers. When
the peer device receives the encapsulated packets, it checks whether TLVs carried in the packets
are correct. If TLVs are not correct, the peer device discards the packets for network security.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis
An IS-IS process is created and the IS-IS view is displayed.
Step 3 Run:
optional-checksum enable
IS-IS optional checksum is enabled.

Routers
NOTE
If MD5 authentication or Keychain authentication with valid MD5 authentication is configured on an IS-
IS interface or area, IS-IS routers send Hello packets and SNP packets carrying no checksum TLVs and
verify the checksum of the received packets.
----End
Procedure
l Run the display isis lsdb verbose command to check the detailed information in the IS-IS
LSDB.
----End
8.5.3 Controlling IPv6 IS-IS Route Selection

You can adjust IS-IS route selection to precisely control route selection.
Before configuring IS-IS route selection, complete the following task:
8.5.3.1 Configuring a Preference Value for IPv6 IS-IS
Context
If multiple routes to the same destination are discovered by different routing protocols running
on the same device, the route discovered by the protocol with the highest preference is selected.
To prefer a IPv6 route discovered by IS-IS, configure a higher preference value for IS-IS IPv6
route. In addition, a routing policy can be configured to increase the preferences of specified IS-
IS IPv6 routes, without affecting route selection.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

Routers
Step 3 Run:
ipv6 preference { route-policy route-policy-name | preference }*
The IS-IS IPv6 route preference value is configured.
The default IS-IS IPv6 route preference value is 15. A smaller preference value indicates a higher
preference.
----End
8.5.3.2 Configuring the Cost of an IS-IS Interface on IPv6 network
Context
The costs of IS-IS interfaces can be determined in the following modes in descending order by
priority:
l Interface cost: is configured for a specified interface.
l Global cost: is configured for all interfaces.
l Automatically calculated cost: is automatically calculated based on the interface
bandwidth.
If no cost is configured for an IS-IS interface, the IS-IS interface uses the default cost 10 and
cost style narrow.
NOTICE
If you want to change the cost style of IS-IS devices, running the command while configuring
basic IS-IS functions is recommended. If the cost style of IS-IS devices is changed during
network operation, the IS-IS process is restarted and neighbors are disconnected.
Procedure
Step 1 Configure the IS-IS cost style.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
cost-style { narrow | wide | wide-compatible | { { narrow-compatible |
compatible } [ relax-spf-limit ] } }
The IS-IS cost style is configured.
By default, the cost style of routes received and sent by an IS-IS device is narrow.
The cost range of an interface and a route received by the interface vary with the cost type.

Routers
l If the cost style is narrow, the cost of an interface ranges from 1 to 63. The maximum cost
of a route received by the interface is 1023.
l If the cost style is narrow-compatible or compatible, the cost of an interface ranges from 1
to 63. The cost of a received route is related to relax-spf-limit.
l If the cost style is wide-compatible or wide, the cost of the interface ranges from 1 to
16777215. When the cost is 16777215, the neighbor TLV generated on the link cannot be
used for route calculation but for the transmission of TE information. The maximum cost of
a received route is 0xFFFFFFFF.
Step 2 Configure the cost of an IS-IS interface on IPv6 network.
Perform any of the following operations to configure the cost of an IS-IS interface on IPv6
network.
Configure the cost of a specified IS-IS interface on IPv6 network.

1. Run:
system-view

2. Run:

3. Run:
isis ipv6 cost { cost | maximum } [ level-1 | level-2 ]
The cost of the IS-IS interface on IPv6 network is configured.
By default, the cost of an IS-IS interface on IPv6 network is 10.

Configure the global IS-IS interface cost on IPv6 network.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
ipv6 circuit-cost { cost | maximum } [ level-1 | level-2 ]
The global IS-IS interface cost on IPv6 network is configured.
By default, no global cost is configured.
NOTE
You can configure the parameter maximum only when the IS-IS cost style is wide or wide-compatible.
Enable IS-IS interface to automatically calculate the interface cost on IPv6 network.
1. Run:
system-view

Routers
2. Run:
isis [ process-id ]

3. Run:
ipv6 bandwidth-reference value
The reference value of the bandwidth is configured. By default, the bandwidth reference
value is 100 Mbit/s.
4. Run:
ipv6 auto-cost enable
The interface is configured to automatically calculate its cost on IPv6 network.
The bandwidth reference value set using the ipv6 bandwidth-reference command takes effect
only when the cost style is wide or wide-compatible. In this case, the interface cost is calculated
using the following formula:
Cost of each interface = (Bandwidth-reference/Interface bandwidth) 10
If the cost-style is narrow, narrow-compatible, or compatible, the cost of each interface is based
on costs listed in Table 8-3.
Table 8-3 Mapping between IS-IS interface costs and interface bandwidth
20 622 Mbit/s < Interface bandwidth 2.5 Gbit/s
10 2.5 Gbit/s < Interface bandwidth
----End
8.5.3.3 Configuring Principles for Using Equal-Cost IPv6 IS-IS Routes
Context
If there are redundant IS-IS links, multiple routes may have an equal cost.
Configure load balancing for equal-cost IS-IS routes so that traffic will be evenly balanced
among these links. This mechanism increases the link bandwidth usage and prevents network
congestion caused by link overload. However, this mechanism may make traffic management
more difficult because traffic will be randomly forwarded.

Routers
Procedure
l Configure equal-cost IS-IS routes to work in load-balancing mode.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
ipv6 maximum load-balancing number
The maximum number of load-balancing equal-cost IPv6 IS-IS routes is set.
By default, the AR150&200 series, AR1200 series, AR2201-48FE, AR2202-48FE,

and AR2204 support a maximum of four equal-cost routes, and the AR2220, AR2240,
and AR3200 series support a maximum of eight equal-cost routes.
NOTE
When the number of equal-cost routes is greater than number specified in the ipv6 maximum
load-balancing command, valid routes are selected for load balancing based on the following
criteria:
1. Route preference: Routes with higher preferences are selected for load balancing.
2. Interface index: If routes have the same priorities, routes with higher interface index values
are selected for load balancing.
3. Next hop IP address: If routes have the same priorities and interface index values, routes
with larger IP address are selected for load balancing.
----End
8.5.3.4 Configuring IS-IS IPv6 Route Leaking
Context
If multiple Level-1-2 devices in a Level-1 area are connected to devices in the Level-2 area, a
Level-1 LSP sent by each Level-1-2 device carries an ATT flag bit of 1. This Level-1 area will
have multiple routes to the Level-2 area and to other Level-1 areas.
By default, routes in a Level-1 area can be leaked into the Level-2 area so that Level-1-2 and
Level-2 devices can learn about the topology of the entire network. Devices in a Level-1 area
are unaware of the entire network topology because they only maintain LSDBs in the local
Level-1 area. Therefore, a device in a Level-1 area can forward traffic to a Level-2 device only
through the nearest Level-1-2 device. The route used may not be the optimal route to the
destination.
To enable a device in a Level-1 area to select the optimal route, configure IS-IS IPv6 route
leaking so that specified routes in the Level-2 area can be leaked into the local Level-1 area.
Routes of services deployed only in the local Level-1 area do not need to be leaked into the
Level-2 area. A policy can be configured to leak only desired routes into the Level-2 area.

Routers
Procedure
l Specify IS-IS IPv6 routes in the Level-2 area and other Level-1 areas that can be leaked
into the local Level-1 area.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
ipv6 import-route isis level-2 into level-1 [ tag tag | filter-policy
{ acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-
policy route-policy-name } ] *
IS-IS IPv6 routes in the Level-2 area and other Level-1 areas that meet the specified
conditions are leaked into the local Level-1 area.
By default, IS-IS IPv6 routes in the Level-2 area are not leaked into Level-1 areas.
NOTE
l Configure IS-IS IPv6 routes in Level-1 areas to leak into the Level-2 area.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
ipv6 import-route isis level-1 into level-2 [ tag tag | filter-policy
{ acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-
policy route-policy-name } ] *
IS-IS IPv6 routes that meet the specifies conditions in Level-1 areas are leaked into
the Level-2 area.
By default, all Level-1 IS-IS IPv6 routing information, excluding information about
default routes, is leaked to Level-2 areas.
NOTE
----End
8.5.3.5 Controlling Whether a Level-1 Device Generates a IPv6 Default Route
Context
As defined in the IS-IS protocol, if a Level-1-2 device reaches more areas through a Level-2
area than through a Level-1 area based on the link state database (LSDB), the Level-1-2 device

Routers
sets the ATT bit to 1 in the LSPs and sends the LSPs with the ATT bit 1 to the Level-1 device.
Upon receipt, the Level-1 device generates a default route destined for the Level-1-2 device.
The preceding rules are employed by default. You can set the ATT bit as required on a live
network.
Perform the following steps:
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run the following command as required:

l To set the ATT bit in the LSPs sent by the Level-1-2 device, run the attached-bit
advertise { always | never } command.
If the always parameter is specified, the ATT bit is set to 1. After receiving the LSPs
carrying the ATT bit 1, the Level-1 device generates a default route.
If the never parameter is specified, the ATT bit is set to 0. After receiving the LSPs
carrying the ATT bit 0, the Level-1 device does not generate a default route, which reduces
the size of a routing table.
l To disable the Level-1 device from generating default routes even though it receives the LSPs
carrying the ATT bit 1, run the attached-bit avoid-learning command.
----End
Procedure
[ verbose | [ level-1 | level-2 ] | ipv6-address [ prefix-length ] ] * command to check IS-IS
name } ] * [ process-id | vpn-instance vpn-instance-name ] command to check information
in the IS-IS LSDB.
----End
8.5.4 Controlling IPv6 IS-IS Route Exchange

If other routing protocols are configured on an IS-IS network, you need to configure IS-IS to
interact with these protocols to ensure successful communication between them.

Routers
Before controlling IS-IS route exchange, complete the following task:
8.5.4.1 Configuring IS-IS to Advertise a Default Route
Context
If IS-IS is configured to advertise a default route on a border device that has external routes, the
device advertises a default route ::/0 in the IS-IS routing domain. All traffic destined for other
routing domains is first forwarded to the border device.
NOTE
Configuring a static default route can also allow all the traffic to be first forwarded to a border device,
which then forwards the traffic outside an IS-IS routing domain. However, this method leads to heavy
workload in configuration and management when a large number of devices are deployed on the network.
In addition, advertising default routes using IS-IS is flexible. If multiple border devices are deployed, a
routing policy can be configured to allow only the border device that meets the specified conditions to
advertise a default route, preventing routing blackholes.
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ]

Step 3 Run:
ipv6 default-route-advertise [ always | match default | route-policy route-policy-
name ] [ cost cost | tag tag | [ level-1 | level-1-2 | level-2 ] ] * [ avoid-
learning ]
IS-IS is configured to advertise a default IPv6 route.

By default, IS-IS does not advertise a default route.
----End
8.5.4.2 Configuring IS-IS to Import External Routes
Context
After IS-IS is configured to advertise a default route on a border device in an IS-IS routing
domain, all the traffic destined outside the IS-IS routing domain is forwarded through the border

Routers
device. This burdens the border device because other devices in the IS-IS routing domain do not
have the routes destined outside the domain. If multiple border devices are deployed in the IS-
IS routing domain, optimal routes to other routing domains need to be selected.
To ensure optimal routes are selected, all the other devices in the IS-IS routing domain must
learn all or some external routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Configure IS-IS to import external routes.

l When you need to set the cost of imported routes, run the ipv6 import-route { static |
direct | unr | { ospfv3 | ripng | isis } [ process-id ] | bgp [ permit-ibgp ] } [ cost cost | tag
tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ] * command to configure
IS-IS to import external IPv6 routes.
l When you need to retain the original cost of imported routes, run the ipv6 import-route
{ direct | unr | { ospfv3 | ripng | isis } [ process-id ] | bgp [ permit-ibgp ] } inherit-cost
[ tag tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ] * command to
configure IS-IS to import external IPv6 routes. In this case, the source routing protocol of
imported routes cannot be static.
NOTE
IS-IS will advertise all imported external routes to the IS-IS routing domain by default.
----End
8.5.4.3 Configuring IS-IS to Advertise Specified External Routes to an IS-IS Routing

Domain
Context
When the local IS-IS device advertises imported external routes to other IS-IS devices, routing
policies can be configured to advertise only the external routes that meet specified conditions if
these devices do not require all the imported external routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

Routers
Step 3 Run:
ipv6 filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-
name | route-policy route-policy-name } export [ protocol [ process-id ] ]
IS-IS is configured to advertise the external IPv6 routes that meet specified conditions to the IS-
IS routing domain.
----End
8.5.4.4 Adding Specified IS-IS Routes to the IPv6 Routing Table
Context
Only routes in an IPv6 routing table can be used to forward IPv6 packets. An IS-IS route can
take effect only after this IS-IS route has been successfully added to an IPv6 routing table.
If an IS-IS route does not need to be added to a routing table, specify conditions, such as IPv6
prefix, and routing policy, to filter routes so that only IS-IS routes that meet the specified
conditions can added to an IPv6 routing table. IS-IS routes that do not meet the specified
conditions cannot be added to the IPv6 routing table and cannot be selected to forward IPv6
packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
ipv6 filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-
name | route-policy route-policy-name } import
Conditions for filtering IS-IS routes are configured.
----End
Procedure
name } ] * [ process-id | vpn-instance vpn-instance-name ] command to check IS-IS LSDB
information.
[ verbose | [ level-1 | level-2 ] | ipv6-address [ prefix-length ] ] * command to check IS-IS

Routers
l Run the display ipv6 routing-table command to check the IPv6 routing table.
----End
8.5.5 Configuring IPv6 IS-IS Route Summarization

A large IS-IS network has a large number of routing entries. This will slow down routing table
lookup and increase management complexity. You can configure route summarization to reduce
the size of routing tables.
Before configuring IS-IS route summarization, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
ipv6 summary ipv6-address prefix-length [ avoid-feedback | generate_null0_route |
tag tag | [ level-1 | level-1-2 | level-2 ] ] *
The specified IPv6 IS-IS routes are summarized into one IS-IS route.
NOTE
After route summarization is configured on a device, the local routing table still contains all specific routes
before the summarization. The routing tables on other devices contain only the summary route, and the
summary route is deleted only after all its specific routes are deleted.
----End

l Run the display isis route command to check summary routes in the IS-IS routing table.
l Run the display ipv6 routing-table [ verbose ] command to check summary routes in the
IPv6 routing table.
8.5.6 Controlling IPv6 IS-IS Route Convergence

Accelerating IS-IS route convergence can improve the fault location efficiency and improve
network reliability.
Before configuring IS-IS route convergence, complete the following task:

Routers
8.5.6.1 Configuring Attributes for Hello Packets
Context
IS-IS maintains neighbor relationships between neighbors by sending and receiving Hello
packets. If the local device does not receive Hello packets from its neighbor within a specified
period, the device considers the neighbor Down.
In IS-IS, you can set the interval for sending Hello packets and the holding multiplier of
neighboring devices to control the holdtime of neighbor relationships between the local device
and neighbors.
l If the interval for sending Hello packets is too short, more system resources are consumed
to send Hello packets, causing a heavy CPU load.
l If the holdtime of neighboring devices is too long, the local device needs to spend much
time detecting the failure of neighbors, slowing down IS-IS route convergence. If the
holdtime of neighboring devices is too short, some Hello packets may be lost or become
incorrect because of network transmission delay and errors. This will cause neighbor
relationships to frequently alternate between Up and Down and lead to route flapping on
the IS-IS network.
NOTE
You are advised to set the same interval for sending Hello packets and same holding multiplier of
neighboring devices on all the devices on the IS-IS network. This method prevents IS-IS route
convergence from being slowed down when some devices detect link failures at a lower speed than
other devices.
Procedure
l Configure the interval for sending Hello packets.
1. Run:
system-view

2. Run:

3. Run:
isis timer hello hello-interval [ level-1 | level-2 ]
The interval for sending Hello packets is set on an interface.
By default, the interval for sending Hello packets 10 seconds.

Routers
NOTE

On a broadcast link, there are Level-1 and Level-2 Hello packets. For different types of packets,
you can set different intervals. If no level is specified, both the Level-1 timer and Level-2 timer
are configured. On a P2P link, there are only one type of Hello packets. Therefore, neither
level-1 nor level-2 is required.
l Set the holding multiplier for neighboring devices.
1. Run:
system-view

2. Run:

3. Run:
isis timer holding-multiplier number [ level-1 | level-2 ]
The holding multiplier of neighboring devices is set.
The default holding multiplier is 3. The holdtime of neighbor relationships is three

times the interval for sending Hello packets.
NOTE
----End
8.5.6.2 Configuring Attributes for LSPs
Context
LSPs are used to exchange link state information. You can configure attributes for LSPs to
control the length and maximum lifetime of LSPs. To accelerate network convergence, you can
enable LSP fast flooding or reduce the minimum interval for sending LSPs and the interval for
updating LSPs to speed up LSP flooding. However, CPU resources will be consumed too much
if the network topology changes frequently. In this situation, configure the intelligent timer for
generating LSPs. This timer can fast respond to emergencies, speed up network convergence,
and improve CPU resource efficiency because its interval becomes longer when the network
changes frequently.

Parameters
Set the Set the size When the volume of link status information increases, the
maximum for LSPs to length of LSPs to be generated can be increased to carry
length for LSPs be more information in each LSP.
generated
and LSPs to
be received.

Routers

Parameters
Set the Set the When a router generates the system LSP, it fills in the
maximum maximum maximum lifetime for this LSP. After this LSP is received
lifetime for lifetime for by other routers, the lifetime of the LSP is reduced gradually.
LSPs LSPs to If the router does not receive any more update LSPs and the
ensure the lifetime of the LSP is reduced to 0, the LSP will be deleted
validity of from the LSDB 60s later if no more updated LSPs are
an LSP received.
before its
updated
LSP is
received.
Set the refresh Set the On an IS-IS network, LSDB synchronization is

interval for refresh implemented through LSP flooding. During LSP flooding,
LSPs interval for a router sends an LSP to its neighbors and then the neighbors
LSPs to send the received LSP to their respective neighbors except
synchronize the router that first sends the LSP. In this manner, the LSP
LSDBs. is flooded among the routers of the same level. LSP flooding
allows each router of the same level to have the same LSP
information and synchronize its LSDB with each other.
Set the Set the Reducing the minimum interval for sending LSPs speeds up
minimum interval for LSP flooding.
interval at sending an
which LSPs are LSP during
sent LSP update.
Configure the Control the On an IS-IS network, if the local routing information
intelligent interval for changes, a router needs to generate a new LSP to notify this
timer used to generating change. If the local routing information changes frequently,
generate LSPs LSPs a large number of new LSPs are generated, which occupies
intelligently a lot of system resources and decreases system performance.
to speed up To speed up network convergence and prevent system
route performance from being affected, configure an intelligent
convergenc timer for generating LSPs. This timer can adjust the delay
e and reduce in generating LSPs based on the routing information change
system frequency.
load.

Routers

Parameters
Enable LSP Control the When an IS-IS router receives new LSPs from other
fast flooding number of routers, it router updates the LSPs in the local LSDB and
LSPs periodically floods out the updated LSPs according to a
flooded timer . LSP fast flooding updates the preceding method.
each time When a device configured with LSP fast flooding receives
on an one or more new LSPs. it floods out the LSPs with a number
interface to smaller than the specified number before calculating routes.
speed up IS- This speeds up LSDB synchronization.
IS network
convergenc
e.
Set an interval Control the On a point-to-point network, devices at both ends of a link
at which LSPs interval for synchronize LSDBs with each other by flooding LSPs. The
are retransmitti device at one end of the link sends an LSP. If the device at
retransmitted ng LSPs to the other end receives this LSP, it replies with a PSNP. If the
over a P2P link ensure device that has sent an LSP does not receive a PSNP from
LSDB the other end in a period of time, the device will retransmit
synchroniza the LSP.
tion on a
P2P
network.
Procedure
l Set the maximum length for LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Set the maximum length for LSPs.
Run:
lsp-length originate max-size
The maximum length is set for each generated LSP.

Run:
lsp-length receive max-size
The maximum length is set for each received LSP.
By default, the IS-IS system generates and receives 1497-byte LSPs.

Routers
NOTE
Ensure that the value of max-size for LSPs to be generated must be smaller than or equal to the
value of max-size for LSPs to be received.
The value of max-size set through the lsp-length command must meet the following
requirements; otherwise, the MTU status on the interface is considered Down.
l The MTU of an Ethernet interface must be greater than or equal to the sum of the value of
max-size and 3.
l The MTU of a P2P interface must be greater than or equal to the value of max-size.
l Set the maximum lifetime for LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-max-age age-time
The maximum lifetime is set for LSPs.
By default, the maximum lifetime of LSPs is 1200 seconds.

l Set the refresh interval for LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-refresh refresh-time
A refresh interval is set for LSPs.
y default, the LSP refresh interval is 900s.
NOTE
Ensure that the LSP refresh interval is more than 300s shorter than the maximum LSP lifetime.
This allows new LSPs to reach all devices in an area before existing LSPs expire.
The larger a network, the greater the deviation between the LSP refresh interval and the
maximum LSP lifetime.
l Set the minimum interval at which LSPs are sent.
1. Run:
system-view

2. Run:

Routers

3. Run:
isis timer lsp-throttle throttle-interval [ count count ]
The minimum interval for sending LSPs on an IS-IS interface and the maximum
number of LSPs sent within the interval is set.
By default, the minimum interval for sending LSPs is 50 ms, and the maximum number
of LSPs sent each time is 10.
l Configure the intelligent timer used to generate LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-generation max-interval [ init-interval [ incr-interval ] ]
[ level-1 | level-2 ]
The intelligent timer used to generate LSPs is set.
If no level is configured, both Level-1 and Level-2 are configured.
The initial delay for generating the same LSPs (or LSP fragments) is init-interval. The
delay for generating the same LSPs (or LSP fragments) secondly is incr-interval.
When the routes change each time, the delay for generating the same LSPs (or LSP
fragments) is twice as the previous value until the delay is up to max-interval. After
the delay reaches max-interval for three times or reset the IS-IS process, the interval
is reduced to init-interval.
When incr-interval is not used and generating the same LSPs (or LSP fragments) for
the first time, init-interval is used as the initial delay. Then, the delay for generating
the same LSPs (or LSP fragments) is max-interval. After the delay reaches max-
interval for three times or the IS-IS process is reset, the interval is reduced to init-
interval.
When only max-interval is used, the intelligent timer changes into a normal one-short
timer.
l Enable LSP fast flooding.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
flash-flood [ lsp-count | max-timer-interval interval | [ level-1 |
level-2 ] ] *

Routers
The LSP fast flooding is enabled.
The lsp-count parameter specifies the number of LSPs flooded each time, which is
applicable to all interfaces. If the number of LSPs to be sent is greater than the value
of lsp-count, lsp-count takes effect. If the number of LSPs to be sent is smaller than
the value of lsp-count, LSPs of the actual number are sent. If a timer is configured and
the configured timer does not expire before the route calculation, the LSPs are flooded
immediately when being received; otherwise, the LSPs are sent when the timer
expires.
When LSP fast flooding is enabled, Level-1 LSPs and Level-2 LSPs are fast flooded
by default if no level is specified.
l Set an interval at which LSPs are retransmitted over a P2P link.
1. Run:
system-view

2. Run:

3. (Optional) Run:
A broadcast interface is simulated as a P2P interface.
NOTE
If the interface type is P2P, the step is not required.

4. Run:
isis timer lsp-retransmit retransmit-interval
The interval at which LSPs are retransmitted over a P2P link is set.
By default, the interval for retransmitting LSPs over a P2P link is 5 seconds.
----End
8.5.6.3 Configuring Attributes for CSNPs
Context
Complete sequence number PDUs (CSNPs) contains the summary of all the LSPs in an LSDB
to ensure LSDB synchronization between neighbors. CSNPs are processed differently on
broadcast and P2P links.
l On a broadcast link, CSNPs are periodically sent by a DIS device. If a device detects that
its LSDB is not synchronized with that on its neighboring, the device will send PSNPs to
apply for missing LSPs.
l On a P2P link, CSNPs are sent only during initial establishment of neighboring
relationships.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
isis timer csnp csnp-interval [ level-1 | level-2 ]
The interval at which CSNPs are sent is set on the specified interface.
By default, the interval at which CSNPs are sent is 10 seconds.
NOTE
Configure Level-1 and Level-2 only when a broadcast interface is specified.
----End
8.5.6.4 Setting the SPF Calculation Interval
Context
A network change always triggers IS-IS to perform SPF calculation. Frequent SPF calculation
will consume excessive CPU resources, affecting services.
To solve this problem, configure an intelligent timer to control the interval for SPF calculation.
For example, to speed up IS-IS route convergence, set the interval for SPF calculation to a small
value and set the interval to a large value after the IS-IS network becomes stable.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
timer spf max-interval [ init-interval [ incr-interval ] ]
The SPF intelligent timer is configured.
By default, no SPF intelligent timer is configured and the maximum delay in SPF calculation is
5 seconds.
The intelligent timer changes as follows:

Routers
l The delay in the first SPF calculation is determined by init-interval; the delay in the second
SPF calculation is determined by incr-interval. From the third time on, the delay in SPF
calculation increases twice every time until the delay reaches the value specified by max-
l If incr-interval is not specified, the delay in SPF calculation for the first time is determined
by init-interval. From the second time on, the delay in SPF calculation is determined by max-
l When only max-interval is specified, the intelligent timer functions as an ordinary one-time
triggering timer.
spf-slice-size duration-time
The maximum duration for SPF calculation is configured.

By default, IS-IS route calculation lasts for a maximum of 2 ms at a time.
----End
8.5.6.5 Configuring Convergence Priorities for IS-IS Routes
Context
Devices allow you to configure the highest convergence priority for specific IS-IS routes so that
these IS-IS routes will be converged first when a network topology changes.
The application rules of the convergence priorities for IS-IS routes are as follows:
l Existing IS-IS routes are converged based on the priorities configured in the ipv6 prefix-
priority command.
l New IS-IS routes are converged based on the priorities configured in the ipv6 prefix-
priority command.
l If an IS-IS route conforms to the matching rules of multiple convergence priorities, the
highest convergence priority is used.
l The convergence priority of a Level-1 IS-IS route is higher than that of a Level-2 IS-IS
route.
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ]

Step 3 Run:
ipv6 prefix-priority [ level-1 | level-2 ] { critical | high | medium } { ipv6-
prefix prefix-name | tag tag-value }

Routers
Convergence priorities are set for IS-IS routes.
By default, the convergence priority of 32-bit host routes is medium, and the convergence
priority of the other IS-IS routes is low.
NOTE
The ipv6 prefix-priority command is only applicable to the public network.

After the ipv6 prefix-priority command is run, the convergence priority of 32-bit host routes is low, and
the convergence priorities of the other routes are determined as specified in the ipv6 prefix-priority
command.

quit

ipv6 route prefix-priority-scheduler critical-weight high-weight medium-weight low-
weight
The preference-based scheduling ratio of IPv6 routes is configured.
By default, the preference-based scheduling ratio of IPv6 routes is 8:4:2:1.
----End
Procedure
name ] command to check IS-IS packet information.
[ verbose | [ level-1 | level-2 ] | ipv6-address [ prefix-length ] ] * command to check the
information of IS-IS routes.
----End
8.5.7 Configuring LSP Fragment Extension

LSP fragment extension allows an IS-IS device to generate more LSP fragments to transmit
more IS-IS information.
Before configuring LSP fragment extension, complete the following task:
l 8.5.1.1 Creating IS-IS Processes

NOTE
When a new device connects to an IS-IS network, you are advertised to configure LSP fragment extension
and virtual systems before establishing IS-IS neighbors or importing routes. If you establish IS-IS neighbors
or import routes, which causes IS-IS to carry much information that cannot be loaded through 256
fragments, you must configure LSP fragment extension and virtual systems. The configurations, however,
take effect only after you restart the IS-IS process.

Routers
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ]
Step 3 Run:
lsp-fragments-extend [ [ level-1 | level-2 | level-1-2 ] | [ mode-1 | mode-2 ] ] *
LSP fragment extension is enabled in an IS-IS process.

By default, LSP fragment extension is disabled in an IS-IS process.
If the mode or level is not specified during the configuration of LSP fragment extension, mode-1
and level-1-2 are used by default.
NOTE
If there are devices of other manufacturers on the network, LSP fragment extension must be set to mode-1.
Otherwise, devices of other manufacturers cannot identify LSPs.
Step 4 Run:
virtual-system virtual-system-id
A virtual system is configured.

By default, no virtual system is configured.
To configure a router to generate extended LSP fragments, you must configure at least one virtual
system. The ID of the virtual system must be unique in the domain.
An IS-IS process can be configured with up to 50 virtual system IDs.
----End

level-1-2 ] ] | [ packet ] ]
8.5.8 Configuring a Mesh Group on an NBMA Network

You can configure a mesh group on an NBMA network to prevent repeated LSP flooding from
causing bandwidth waste.
Before configuring a mesh group, complete the following task:

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
isis mesh-group { mesh-group-number | mesh-blocked }
The interface is added to a mesh group.
When mesh-blocked is configured on an interface, the interface is blocked and cannot flood
LSPs outside. All the interfaces added to a mesh group implement global LSDB synchronization
through CSNP and PSNP mechanisms.
----End


level-1-2 ] ] | packet ]
8.5.9 Configuring the Overload Bit for an IS-IS Device

If an IS-IS device needs to be temporarily isolated, configure the IS-IS device to enter the
overload state to prevent other devices from forwarding traffic to this IS-IS device and prevent
blackhole routes.
Before configuring the overload bit for an IS-IS device, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

Routers

Step 3 Run:
set-overload [ on-startup [ timeout1 | start-from-nbr system-id [ timeout1
[ timeout2 ] ] | wait-for-bgp [ timeout1 ] ] ][ allow { interlevel | external }* ]
The overload bit for non-pseudonode LSPs is configured.
----End

l Run the display isis lsdb [ [ level-1 | level-2 ] | verbose | [ local | lsp-id | is-name symbolic-
name ] ] * [ process-id | vpn-instance vpn-instance-name ] command to check information
in the IS-IS LSDB.

8.6.1 Resetting IS-IS

Context
To reset IS-IS, reset IS-IS data structure, neighbor relationship and packets
NOTICE
The IS-IS data structure cannot be restored after you reset it. All the previous structure
information and the neighbor relationship are reset. Exercise caution when running this
command.
The specified IS-IS neighbor relationship is deleted after you reset a specified IS-IS neighbor.
Exercise caution when running this command.
Procedure
l Reset IS-IS data structure.
Run the reset isis all [ [ process-id | vpn-instance vpn-instance-name ] | graceful-
restart ] * command to reset IS-IS data structure.
l Reset IS-IS neighbor relationship.
Run the reset isis peer system-id [ process-id | vpn-instance vpn-instance-name ] command
to reset a specific IS-IS neighbor.
After the IS-IS routing policy or the protocol changes, you can reset a specific IS-IS
neighbor to validate the new configuration.
----End

Routers
8.6.2 Improving the Maintainability of IS-IS
Context
The administrator can improve the maintainability of IS-IS using either of the following
methods:
l Configuring IS-IS host name mapping: Through this function, the administrator can use a
simple name to replace the system ID. After IS-IS host name mapping is configured, the
dynamic name is displayed in the IS-IS information to replace the system ID when the
display command is executed. This improves the maintainability of IS-IS networks.
l Configuring IS-IS to add the POI TLV to a PURGE packet: When the value of the
Remaining Lifetime field in an LSP packets is 0, this packet is invalid and called a PURGE
packet. PURGE packets do not record information about the devices generating these
packets. Therefore, when a network is faulty, the packet source cannot be located. To solve
this problem, IS-IS can be configured to add the POI TLV to a PURGE packet so that the
PURGE packet contains information about its generating device. If the dynamic host name
function is configured locally, the host name TLV is also added to the PURGE packet to
facilitate fault location.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Configure IS-IS host name mapping.

l Run:
is-name symbolic-name
IS-IS dynamic host name mapping is configured and a host name is configured for the local
device.
This configuration is dynamic configuration. Therefore, the configured host name symbolic-
name is advertised through an LSP to other IS-IS devices in the same area. When you use
IS-IS display commands to view IS-IS information on other IS-IS devices, the system ID of
the local device is replaced by the configured host name.
l Run:
is-name map system-id symbolic-name
IS-IS static host name mapping is configured and a host name is configured for the remote
device.
This configuration is static configuration and takes effect only on the local device. Therefore,
the configured host name symbolic-name is not advertised through an LSP.
----End

Routers
8.6.3 Configuring the Output of IS-IS Adjacency Status
Context
On an IS-IS network, neighbor flapping will result in network instability and frequent network
convergence. This will consume lots of memory and may even cause user traffic loss. Therefore,
neighbor flapping needs to be rapidly located and solved.
To rapidly locate problems in the case of neighbor flapping, enable the output of IS-IS adjacency
changes to log these changes.
If the local terminal monitor is enabled and the output of the IS-IS adjacency status is enabled,
IS-IS adjacency changes will be output to the router until the output of the adjacency status is
disabled.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
log-peer-change [ topology ]
The output of the adjacency status is enabled.
By default, the output of IS-IS adjacency changes is disabled.
----End

This section describes IS-IS for IPv6 configuration examples, including networking
requirements, configuration roadmap, and configuration procedure.
8.7.1 Example for Configuring Basic IPv6 IS-IS Functions
As shown in Figure 8-2, there are four routers on the IPv6 topology network. The four routers
need to communicate with each other. In addition, RouterA and Router B can only process less
data.

Routers
Figure 8-2 Networking diagram of configuring basic IS-IS functions
GE1/0/0
10:1::2/64
RouterA
L1 GE2/0/0
GE1/0/0 GE3/0/0 20::1/64
10:1::1/64 30::1/64
GE2/0/0 GE1/0/0
10:2::1/64 RouterC 30::2/64 RouterD
IS-IS L1/L2 L2
Area10 IS-IS
GE1/0/0
Area20
10:2::2/64
RouterB
L1
1. Configure IPv6 addresses on interfaces of each router so that the routers can be
interconnected.
2. Enable IS-IS on each router so that the routers can be interconnected. Configure RouterA
and RouterB as Level-1 routers to enable them to maintain less data.
Procedure
Step 1 Enable the IPv6 forwarding capability, and configure an IPv6 address for each interface. The
following uses the display on RouterA as an example. The configurations of the other three
routers are the same as that of RouterA, and are not mentioned here.
[RouterA] ipv6
[RouterA-GigabitEthernet1/0/0] ipv6 address 10:1::2/64
[RouterA] isis 1
[RouterA-isis-1] ipv6 enable
[RouterA-GigabitEthernet1/0/0] isis ipv6 enable 1

Routers
[RouterB] isis 1
[RouterB-isis-1] ipv6 enable
[RouterB-GigabitEthernet1/0/0] isis ipv6 enable 1
[RouterC] isis 1
[RouterC-isis-1] ipv6 enable
[RouterC-GigabitEthernet1/0/0] isis ipv6 enable 1
[RouterC-GigabitEthernet3/0/0] isis circuit-level level-2
[RouterD] isis 1
[RouterD-isis-1] ipv6 enable
[RouterD] interface GigabitEthernet 1/0/0
[RouterD-GigabitEthernet1/0/0] isis ipv6 enable 1
[RouterD] interface GigabitEthernet 2/0/0
[RouterD-GigabitEthernet2/0/0] isis ipv6 enable 1
# View the IS-IS routing table of RouterA.

-----------------------------
--------------------------------
IPV6 Dest. ExitInterface NextHop Cost Flags
----------------------------------------------------------------------------
10:1::/64 GigabitEthernet1/0/0 Direct 10
D/L/-
10:2::/64 GigabitEthernet1/0/0 FE80::A83E:0:3ED2:1 20
A/-/-
U-Up/Down Bit Set
# View the IS-IS neighbor information on RouterC.

[RouterC] display isis peer verbose
System Id Interface Circuit Id State HoldTime Type
PRI
-------------------------------------------------------------------------------

Routers
0000.0000.0001 GE1/0/0 0000000001 Up 24s L1

--
MT IDs supported : 0(UP)
Local MT IDs : 0
Area Address(es) : 10
Peer IPv6 Address(es): FE80::996B:0:9419:1
Uptime : 00:44:43
Adj Protocol : IPV6
Restart Capable : YES
Suppressed Adj : NO
Peer System Id : 0000.0000.0001
0000.0000.0002 GE2/0/0 0000000001 Up 28s L1
--
Local MT IDs : 0
Peer IPv6 Address(es): FE80::DC40:0:47A9:1
Uptime : 00:46:13
Adj Protocol : IPV6
Suppressed Adj : NO
Peer System Id : 0000.0000.0002
0000.0000.0004 GE3/0/0 0000000001 Up 24s L2
--
Local MT IDs : 0
Peer IPv6 Address(es): FE80::F81D:0:1E24:2
Uptime : 00:53:18
Adj Protocol : IPV6
Suppressed Adj : NO
Peer System Id : 0000.0000.0004
Total Peer(s): 3
# View the IS-IS LSDB information on RouterC.

[RouterC] display isis lsdb verbose
--------------------------------
-------------------------------------------------------------------------------
0000.0000.0001.00-00 0x0000000c 0x4e06 1117 113 3/0/0
SOURCE 0000.0000.0001.00
NLPID IPV6
AREA ADDR 10
INTF ADDR V6 10:1::2
Topology Standard
NBR ID 0000.0000.0003.00 COST: 10
IPV6 10:1::/64 COST: 10
0000.0000.0002.00-00 0x00000009 0x738c 1022 83 3/0/0
SOURCE 0000.0000.0002.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 0000.0000.0003.00 COST: 10
IPV6 10:2::/64 COST: 10
0000.0000.0003.00-00* 0x00000020 0x6b10 771 140 1/0/0
SOURCE 0000.0000.0003.00
NLPID IPV6
AREA ADDR 10
INTF ADDR V6 30::1
Topology Standard
NBR ID 0000.0000.0002.00 COST: 10

Routers
NBR ID 0000.0000.0001.00 COST: 10

IPV6 10:2::/64 COST: 10
IPV6 10:1::/64 COST: 10
Total LSP(s): 3
-------------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000017 0x61b4 771 157 3/0/0
SOURCE 0000.0000.0003.00
NLPID IPV6
AREA ADDR 10
INTF ADDR V6 30::1
Topology Standard
NBR ID 0000.0000.0004.00 COST: 10
IPV6 30::/64 COST: 10
IPV6 10:2::/64 COST: 10
IPV6 10:1::/64 COST: 10
0000.0000.0004.00-00 0x0000000b 0x6dfa 1024 124 3/0/0
SOURCE 0000.0000.0004.00
NLPID IPV6
AREA ADDR 20
INTF ADDR V6 30::2
INTF ADDR V6 20::1
Topology Standard
NBR ID 0000.0000.0003.00 COST: 10
NBR ID 0000.0000.0005.00 COST: 10
IPV6 30::/64 COST: 10
IPV6 20::/64 COST: 10
Total LSP(s): 2
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#
ipv6 enable topology standard
#
ipv6 enable
ipv6 address 10:1::2/64
isis ipv6 enable 1
#
return

#
sysname RouterB
#
ipv6
#
isis 1

Routers
is-level level-1
network-entity 10.0000.0000.0002.00
#
#
ipv6 enable
isis ipv6 enable 1
#
return

#
sysname RouterC
#
ipv6
#
isis 1
network-entity 10.0000.0000.0003.00
#
#
ipv6 enable
isis ipv6 enable 1
#
ipv6 enable
isis ipv6 enable 1
#
ipv6 enable
isis ipv6 enable 1
isis circuit-level level-2
#
return

#
sysname RouterD
#
ipv6
#
isis 1
is-level level-2
network-entity 20.0000.0000.0004.00
#
#
ipv6 enable
isis ipv6 enable 1
#
ipv6 enable
isis ipv6 enable 1
#
return

Routers
8.8 References
This section lists references of IS-IS(IPv6).
Table 8-4 The following table lists the references of this document.
ISO 10589 ISO IS-IS Routing Protocol -
ISO 8348/Ad2 Network Services Access Points -
RFC 1195 Use of OSI IS-IS for Routing in TCP/IP Multiple

and Dual Environments authentication
passwords are not
supported.
RFC 2763 Dynamic Hostname Exchange -

Mechanism for IS-IS
RFC 2966 Domain-wide Prefix Distribution with -

Two-Level IS-IS
RFC 2973 IS-IS Mesh Groups -
RFC 3277 IS-IS Transient Blackhole Avoidance -
RFC 3373 Three-Way Handshake for IS-IS Point- -

to-Point Adjacencies
RFC 3567 Intermediate System to Intermediate -

System (IS-IS) Cryptographic
Authentication
RFC 3719 Recommendations for Interoperable -

RFC 3784 IS-IS extensions for Traffic -

Engineering
RFC 3786 Extending the Number of IS-IS LSP -

Fragments Beyond the 256 Limit
RFC 3787 Recommendations for Interoperable IP -

RFC 3847 Restart signaling for IS-IS -
RFC 3906 Calculating Interior Gateway Protocol -

(IGP) Routes Over Traffic Engineering
Tunnels
RFC 4444 Management Information Base for IS- -

IS

Routers
RFC 5120 Multi Topology (MT) Routing in IS-IS -
draft-ietf-IS-IS-ipv6-05 Routing IPv6 with IS-IS -
draft-ietf-IS-IS-wg-multi- M-IS-IS: Multi Topology (MT) -

topology-11 Routing in IS-IS
draft-ietf-isis-admin- Admin Tag -

tags-02(Admin Tag)

Routers
Configuration Guide - IP Routing 9 BGP Configuration
9 BGP Configuration
About This Chapter
The Border Gateway Protocol (BGP) is used between Autonomous Systems (ASs) to transmit
routing information. BGP applies to large and complex networks.
9.1 Introduction to BGP

This section defines BGP and describes its purpose and benefits.
9.2 Principles
This section describes BGP implementation.

After basic BGP functions are configured, you can enable basic communication functions on
BGP networks. If other BGP functions are required, configure them according to reference
sections.

This section describes the default configuration of BGP, which can be changed according to
9.5 Configuring BGP

This section describes how to configure BGP.
9.6 Maintaining BGP

Maintaining BGP includes resetting BGP connections and clearing BGP statistics.

The section provides BGP configuration examples, including networking requirements,
networking diagram, configuration roadmap, and configuration procedure.
9.8 FAQ
9.9 References
This section lists RFC documents related to BGP.

Routers
9.1 Introduction to BGP

This section defines BGP and describes its purpose and benefits.
Definition
The Border Gateway Protocol (BGP) is a path vector protocol that allows devices between
Autonomous Systems (ASs) to communicate and selects optimal routes. BGP-1 (defined in RFC
1105), BGP-2 (defined in RFC 1163), and BGP-3 (defined in RFC 1267) are three earlier
versions of BGP. BGP-4 (defined in RFC 1771) has been used since 1994. Since 2006, unicast
IPv4 networks have been using BGP-4 defined in RFC 4271, and other networks (such as IPv6
networks) have been using MP-BGP defined in RFC 4760.
MP-BGP is an extension of BGP-4 and applies to different networks; however, the original
message exchange and routing mechanisms of BGP-4 are not changed. MP-BGP applications
on IPv6 unicast and IPv4 multicast networks are called BGP4+ and Multicast BGP (MBGP)
respectively.
Purpose
A network is divided into different ASs to facilitate the management over the network. In 1982,
the Exterior Gateway Protocol (EGP) was used to dynamically exchange routing information
between ASs. EGP advertises only reachable routes but not select optimal routes or prevent
routing loops. Therefore, EGP cannot meet network management requirements.
BGP was designed to replace EGP. Different from EGP, BGP can select optimal routes, prevent
routing loops, transmit routing information efficiently, and maintain a large number of routes.
Although BGP is used to transmit routing information between ASs, BGP is not the best choice
in some scenarios. For example, on the egress connecting a data center to the Internet, static
routes instead of BGP are used to prevent a huge number of Internet routes from affecting the
data center internal network.
Benefits
BGP ensures high network security, flexibility, stability, reliability, and efficiency:
l BGP uses authentication and Generalized TTL Security Mechanism (GTSM) to ensure
network security.
l BGP provides routing policies to allow for flexible route selection and routing policy-
based route advertisement.
l BGP provides 9.2.8 Route Summarization and 9.2.9 Route Dampening to prevent route
flapping and improve network stability.
l BGP uses the Transport Control Protocol (TCP) with port number 179 as the transport layer
protocol and supports 9.2.10 BFD for BGP, 9.2.11 BGP Tracking, and 9.2.12 BGP GR
to improve network reliability.
l BGP uses the 9.2.14 Dynamic Update Peer-Groups technology to send packets in groups
when a large number of peers and routes exist and most peers share the same outbound
policies, improving BGP forwarding performance.

Routers
9.2 Principles
This section describes BGP implementation.
9.2.1 BGP Concepts

This section describes BGP concepts to help you better understand BGP functions.
Autonomous System
An Autonomous System (AS) is a group of Internet Protocol (IP) networks that are controlled
by one entity, typically an Internet service provider (ISP), and that have the same routing policy.
Each AS is assigned a unique AS number, which identifies an AS on a BGP network. Two types
of AS numbers are available: 2-byte AS numbers and 4-byte AS numbers. A 2-byte AS number
ranges from 1 to 65535, and a 4-byte AS number ranges from 1 to 4294967295. Devices
supporting 4-byte AS numbers are compatible with devices supporting 2-byte AS numbers.
BGP Classification
As shown in Figure 9-1, BGP is classified into two types according to where it runs: Internal
BGP (IBGP) and External BGP (EBGP).
Figure 9-1 BGP operating mode
AS200
IBGP
EBGP EBGP
AS100 AS300
Internet
l EBGP: runs between ASs. To prevent routing loops between ASs, a BGP device discards
the routes with the local AS number when receiving the routes from EBGP peers.

Routers
l IBGP: runs within an AS. To prevent routing loops within an AS, a BGP device does not
advertise the routes learned from an IBGP peer to the other IBGP peers and establishes
full-mesh connections with all the IBGP peers. To address the problem of too many IBGP
connections between IBGP peers, BGP uses 9.2.6 Route Reflector and 9.2.7 BGP
Confederation.
NOTE
If a BGP device needs to advertise the route received from an EBGP peer outside an AS through
another BGP device, IBGP is recommended.
Device Roles in BGP Message Exchange

There are two device roles in BGP message exchange:
l Speaker: The device that sends BGP messages is called a BGP speaker. The speaker
receives and generates new routes, and advertises the routes to other BGP speakers.
l Peer: The speakers that exchange messages with each other are called BGP peers. A group
of peers sharing the same policies can form a peer group.
BGP Router ID
The BGP router ID is a 32-bit value that is often represented by an IPv4 address to identify a
BGP device. It is carried in the Open message sent during the establishment of a BGP session.
When two BGP peers need to establish a BGP session, they each require a unique router ID.
Otherwise, the two peers cannot establish a BGP session.
The BGP router ID of a device must be unique on a BGP network. It can be manually configured
or selected from IPv4 addresses on the device. By default, an IPv4 address of a loopback interface
on a device is used as the BGP router ID. If no loopback interface is configured on the device,
the system selects the largest IPv4 address from all IPv4 addresses of interfaces as the BGP
router ID. Once the BGP router ID is selected, the system retains this router ID even if a larger
IPv4 address is configured on the device later. The system changes the BGP router ID only when
the corresponding IPv4 address is deleted.
9.2.2 BGP Working Principles

BGP peer establishment, update, and deletion involve five types of messages, six state machine
states, and five route exchange rules.
BGP Messages
BGP peers exchange the following messages, among which Keepalive messages are periodically
sent and other messages are triggered by events.
l Open message: is used to establish BGP peer relationships.

l Update message: is used to exchange routes between BGP peers.
l Notification message: is used to terminate BGP connections.
l Keepalive message: is used to maintain BGP connections.
l Route-refresh message: is used to request the peer to resend routes if routing policies are
changed. Only the BGP devices supporting route-refresh can send and respond to Route-
refresh messages.

Routers
BGP State Machine

As shown in Figure 9-2, a BGP device uses a finite state machine (FSM) to determine its
operations with peers. The FSM has six states: Idle, Connect, Active, OpenSent, OpenConfirm,
and Established. Three common states are involved in BGP peer establishment: Idle, Active,
and Established.
Figure 9-2 BGP state machine
Idle
Connect Retry Start

Timeout
Error
Connect
TCP Failed
TCP
Active Establieshed
Error
OpenSent
TCP
Establieshed Receive
Correct Open
Error
OpenConfirm
Receive Correct
Keepalive
Error
Establieshed
1. The Idle state is the initial BGP state. In Idle state, the BGP device refuses all connection
requests from neighbors. The BGP device initiates a TCP connection with its BGP peer
and changes its state to Connect only after receiving a Start event from the system.
NOTE
l The Start event occurs when an operator configures a BGP process or resets an existing BGP
process or when the router software resets a BGP process.
l If an error occurs at any state of the FSM, for example, the BGP device receives a Notification
packet or TCP connection termination notification, the BGP device returns to the Idle state.
2. In Connect state, the BGP device starts the Connect Retry timer and waits to establish a
TCP connection.
l If the TCP connection is established, the BGP device sends an Open message to the
peer and changes to the OpenSent state.
l If the TCP connection fails to be established, the BGP device moves to the Active state.

Routers
l If the BGP device does not receive a response from the peer before the Connect Retry
timer expires, the BGP device attempts to establish a TCP connection with another peer
and stays in Connect state.
3. In Active state, the BGP device keeps trying to establish a TCP connection with the peer.
l If the TCP connection is established, the BGP device sends an Open message to the
peer, closes the Connect Retry timer, and changes to the OpenSent state.
l If the TCP connection fails to be established, the BGP device stays in the Active state.
l If the BGP device does not receive a response from the peer before the Connect Retry
timer expires, the BGP device returns to the Connect state.
4. In OpenSent state, the BGP device waits an Open message from the peer and then checks
the validity of the received Open message, including the AS number, version, and
authentication password.
l If the received Open message is valid, the BGP device sends a Keepalive message and
changes to the OpenConfirm state.
l If the received Open message is invalid, the BGP device sends a Notification message
to the peer and returns to the Idle state.
5. In OpenConfirm state, the BGP device waits for a Keepalive or Notification message from
the peer. If the BGP device receives a Keepalive message, it transitions to the Established
state. If it receives a Notification message, it returns to the Idle state.
6. In Established state, the BGP device exchanges Update, Keepalive, Route-refresh, and
Notification messages with the peer.
l If the BGP device receives a valid Update or Keepalive message, it considers that the
peer is working properly and maintains the BGP connection with the peer.
l If the BGP device receives a valid Update or Keepalive message, it sends a Notification
message to the peer and returns to the Idle state.
l If the BGP device receives a Route-refresh message, it does not change its status.
l If the BGP device receives a Notification message, it returns to the Idle state.
l If the BGP device receives a TCP connection termination notification, it terminates the
TCP connection with the peer and returns to the Idle state.
Route Exchange Rules

A BGP device adds optimal routes to the BGP routing table to generate BGP routes. After
establishing a BGP peer relationship with a neighbor, the BGP device follows the following
rules to exchange routes with the peer:
l Advertises the BGP routes received from IBGP peers only to its EBGP peers.
l Advertises the BGP routes received from EBGP peers to its EBGP peers and IBGP peers.
l Advertises the optimal route to its peers when there are multiple valid routes to the same
destination.
l Sends only updated BGP routes when BGP routes change.
l Accepts all the routes sent from its peers.
9.2.3 Interaction Between BGP and an IGP

Routers
BGP and IGPs use different routing tables. To enable different ASs to communicate, you need
to configure interaction between BGP and IGPs so that BGP routes can be imported into IGP
routing tables and IGP routes can also be imported to BGP routing tables.
Importing IGP Routes to BGP Routing Tables

BGP does not discover routes and so needs to import the routes discovered by IGPs to BGP
routing tables so that different ASs can communicate. When an AS needs to advertise routes to
another AS, an Autonomous System Boundary Router (ASBR) imports IGP routes to its BGP
routing table. To better plan the network, you can use routing policies to filter routes and set
route attributes when BGP imports IGP routes. Alternatively, you can set the multi-exit
discriminator (MED) to help EBGP peers select the best path for traffic entering an AS.
BGP imports routes in either import or network mode:
l In import mode, BGP imports IGP routes, including RIP, OSPF, and IS-IS routes, into BGP
routing tables based on protocol type. To ensure the validity of imported IGP routes, BGP
can also import static routes and direct routes in import mode.
l In network mode, BGP imports the routes in the IP routing table one by one to BGP routing
tables. The network mode is more accurate than the import mode.
Importing BGP Routes to IGP Routing Tables

When an AS needs to import routes from another AS, an ASBR imports BGP routes to its IGP
routing table. To prevent a large number of BGP routes from affecting devices within the AS,
IGPs can use routing policies to filter routes and set route attributes when importing BGP routes.
Applications
As shown in Figure 9-3, an OSPF network is deployed in AS 100 where the Overseas Market
Department of a company resides, and an IS-IS network is deployed in AS 200 where the
Domestic R&D Department of the company resides. AS 100 and AS 200 communicate using
BGP. The company requires that the Overseas Market Department can send files to the Domestic
R&D Department but the Domestic R&D Department cannot send files to the Overseas Market
Department.
Figure 9-3 IGPs importing BGP routes
AS100 BGP AS200
RouterB RouterC
OSPF ISIS
RouterA RouterD
According to the preceding requirement of the company, devices in AS 100 must know routes
of AS 200, but devices in AS 200 do not know routes of AS 100. To meet this requirement,

Routers
configure BGP to import IS-IS routes on RouterC. Then RouterC has routes of AS 200 in the
BGP routing table and advertises these routes to RouterB. In addition, configure OSPF to import
BGP routes on RouterB. Devices in AS 100 can know routes of AS 200, but devices in AS 200
do not know routes of AS 100.
9.2.4 BGP Security
BGP uses authentication and Generalized TTL Security Mechanism (GTSM) to ensure exchange
security between BGP peers.
BGP Authentication
BGP authentication includes Message Digest 5 (MD5) authentication and keychain
authentication, which improves communication security between BGP peers. In MD5
authentication, you can only set the authentication password for a TCP connection. In keychain
authentication, you can set the authentication password for a TCP connection and authenticate
BGP messages.
BGP GTSM
BGP GTSM checks whether the time to live (TTL) value in the IP packet header is within a
predefined range and permits or discards the packets of which the TTL values are out of the
predefined range to protect services above the IP layer. BGP GTSM enhances system security.
Assume that the TTL value range of packets from BGP peers is set to 254-255. When an attacker
forges valid BGP packets and keeps sending these packets to attack a device, the TTL values of
these packets are smaller than 254. If BGP GTSM is not enabled on the device, the device finds
that these packets are destined for itself and sends the packets to the control plane for processing.
Then the control layer needs to process a large number of such attack packets, causing high CPU
usage. If BGP GTSM is enabled on the device, the system checks the TTL values in all BGP
packets and discards the attack packets of which the TTL values are smaller than 254. This
prevents network attack packets from consuming CPU resources.
9.2.5 BGP Route Selection Rules and Load Balancing
There may be multiple routes to the same destination in a BGP routing table. BGP will select
one route as the optimal route and advertise it to peers. To select the optimal route among these
routes, BGP compares the BGP attributes of the routes in sequence based on route selection
rules.
BGP Attributes
Route attributes describe routes. BGP route attributes are classified into the following types.
Table 9-1 lists common BGP attributes.
l Well-known mandatory attribute

All BGP devices can identify this type of attributes, which must be carried in Update
messages. Without this type of attributes, errors occur in routing information.
l Well-known discretionary attribute

Routers
All BGP devices can identify this type of attributes, which are optional in Update messages.
Without this type of attributes, errors do not occur in routing information.
l Optional transitive attribute
BGP devices may not identify this type of attributes but still accepts them and advertises
them to peers.
l Optional non-transitive attribute
BGP devices may not identify this type of attributes. If a BGP device does not identify this
type of attributes, it ignores them and does not advertise them to peers.
Table 9-1 Common BGP attributes
Attribute Type
Origin Well-known mandatory
AS_Path Well-known mandatory
Next_Hop Well-known mandatory
Local_Pref Well-known discretionary
Community Optional transitive
MED Optional non-transitive
Originator_ID Optional non-transitive
Cluster_List Optional non-transitive
The following describes common BGP route attributes:

l Origin
The Origin attribute defines the origin of a route and marks the path of a BGP route. The
Origin attribute is classified into three types:
IGP
A route with IGP as the Origin attribute is of the highest priority. The Origin attribute
of the routes imported into a BGP routing table using the network command is IGP.
EGP
A route with EGP as the Origin attribute is of the secondary highest priority. The Origin
attribute of the routes obtained through EGP is EGP.
Incomplete
A route with Incomplete as the Origin attribute is of the lowest priority. The Origin
attribute of the routes learned by other means is Incomplete. For example, the Origin
attribute of the routes imported by BGP using the import-route command is
Incomplete.
l AS_Path
The AS_Path attribute records all the ASs that a route passes through from the source to
the destination in the vector order. To prevent inter-AS routing loops, a BGP device does
not receive the routes of which the AS_Path list contains the local AS number.

Routers
When a BGP speaker advertises an imported route:

If the route is advertised to EBGP peers, the BGP speaker creates an AS_Path list
containing the local AS number in an Update message.
If the route is advertised to IBGP peers, the BGP speaker creates an empty AS_Path list
in an Update message.
When a BGP speaker advertises a route learned in the Update message sent by another BGP
speaker:
If the route is advertised to EBGP peers, the BGP speaker adds the local AS number to
the leftmost of the AS_Path list. According to the AS_Path list, the BGP speaker that
receives the route can learn about the ASs through which the route passes to reach the
destination. The number of the AS that is nearest to the local AS is placed on the top of
the AS_Path list. The other AS numbers are listed according to the sequence in which
the route passes through ASs.
If the route is advertised to IBGP peers, the BGP speaker does not change the AS_Path
attribute of the route.
l Next_Hop
The Next_Hop attribute records the next hop that a route passes through. The Next_Hop
attribute of BGP is different from that of an IGP because it may not be the neighbor IP
address. A BGP speaker processes the Next_Hop attribute based on the following rules:
When advertising a route to an EBGP peer, a BGP speaker sets the Next_Hop attribute
of the route to the address of the local interface through which the BGP peer relationship
is established with the peer.
When advertising a locally originated route to an IBGP peer, the BGP speaker sets the
Next_Hop attribute of the route to the address of the local interface through which the
BGP peer relationship is established with the peer.
When advertising a route learned from an EBGP peer to an IBGP peer, the BGP speaker
does not change the Next_Hop attribute of the route.
l Local_Pref
The Local_Pref attribute indicates the BGP preference of a device and helps determine the
optimal route when traffic leaves an AS. When a BGP device obtains multiple routes to the
same destination address but with different next hops from different IBGP peers, the BGP
device prefers the route with the highest Local_Pref. The Local_Pref attribute is exchanged
only between IBGP peers and is not advertised to other ASs. The Local_Pref attribute can
be manually configured. If no Local_Pref attribute is configured for a route, the Local_Pref
attribute of the route uses the default value 100.
l MED
The multi-exit discriminator (MED) attribute helps determine the optimal route when traffic
enters an AS. When a BGP device obtains multiple routes to the same destination address
but with different next hops from EBGP peers, the BGP device selects the route with the
smallest MED value as the optimal route.
The MED attribute is exchanged only between two neighboring ASs. The AS that receives
the MED attribute does not advertise it to any other ASs. The MED attribute can be
manually configured. If no MED attribute is configured for a route, the MED attribute of
the route uses the default value 0.
l Community
The Community attribute identifies the BGP routes with the same characteristics, simplifies
the applications of routing policies, and facilitates route maintenance and management.

Routers
The Community attribute includes self-defined community attributes and well-known

community attributes. Table 9-2 lists well-known community attributes.
Table 9-2 Well-known community attributes

Community Value Description
Attribute
Internet 0 (0x00000000) A BGP device can advertise the received

route with the Internet attribute to all peers.
No_Advertise 4294967042 A BGP device does not advertise the received

(0xFFFFFF02) route with the No_Advertise attribute to any
peer.
No_Export 4294967041 A BGP device does not advertise the received

(0xFFFFFF01) route with the No_Export attribute to devices
outside the local AS.
No_Export_Sub- 4294967043 A BGP device does not advertise the received

confed (0xFFFFFF03) route with the No_Export_Subconfed
attribute to devices outside the local AS or to
devices outside the local sub-AS.
l Originator_ID and Cluster_List

The Originator_ID attribute and Cluster_List attribute help eliminate loops in route
reflector scenarios. For details, see 9.2.6 Route Reflector.
BGP Route Selection Policies

When there are multiple routes to the same destination, BGP compares the following attributes
in sequence to select the optimal route:
1. Prefers the route with the largest PrefVal value.
The PrefVal attribute is a Huawei proprietary attribute and is valid only on the device where
it is configured.
2. Prefers the route with the highest Local_Pref.
If a route does not have the Local_Pref attribute, the Local_Pref attribute of the route uses
the default value 100.
3. Prefers the manually summarized route, automatically summarized route, route imported
using the network command, route imported using the import-route command, and route
learned from peers. These routes are in descending order of priority.
4. Prefers the route with the shortest AS_Path.
5. Prefers the route with the lowest origin type. IGP is lower than EGP, and EGP is lower than
Incomplete.
6. Prefers the route with the lowest MED if routes are received from the same AS.
7. Prefers EBGP routes, IBGP routes, LocalCross routes, and RemoteCross routes, which are
listed in descending order of priority.
LocalCross allows a PE to add the VPNv4 route of a VPN instance to the routing table of
the VPN instance if the export RT of the VPNv4 route matches the import RT of another

Routers
VPN instance on the PE. RemoteCross allows a local PE to add the VPNv4 route learned
from a remote PE to the routing table of a VPN instance on this local PE if the export RT
of the VPNv4 route matches the import RT of the VPN instance.
8. Prefers the route with the lowest IGP metric to the BGP next hop.
NOTE
If there are multiple routes to the same destination, an IGP calculates the route metric using its routing
algorithm.
9. Prefers the route with the shortest Cluster_List.
10. Prefers the route advertised by the device with the smallest router ID.
NOTE
If a route carries the Originator_ID attribute, BGP prefers the route with the smallest Originator_ID
without comparing the router ID.
11. Prefers the route learned from the peer with the lowest IP address.
BGP Load Balancing

When there are multiple equal-cost routes to the same destination, you can perform load
balancing among these routes to load balance traffic. Equal-cost BGP routes can be generated
for traffic load balancing only when the first eight route attributes described in "BGP Route
Selection Policies" are the same.
9.2.6 Route Reflector
To ensure connectivity between IBGP peers, you need to establish full-mesh connections
between IBGP peers. If there are n devices in an AS, n(n-1)/2 IBGP connections need to be
established. When there are a large number of devices, many network resources and CPU
resources are consumed. A route reflector (RR) can be used between IBGP peers to solve this
problem.
Roles in RR
As shown in Figure 9-4, the following roles are involved in RR scenarios in an AS.
Figure 9-4 Networking diagram of the RR
Route Reflector Non-Client

IBGP IBGP
Client1
Cluster1 IBGP
IBGP
AS65000
Client2 Client3

Routers
l Route reflector (RR): a BGP device that can reflect the routes learned from an IBGP peer
to other IBGP peers. An RR is similar to a designated router (DR) on an OSPF network.
l Client: an IBGP device of which routes are reflected by the RR to other IBGP devices. In
an AS, clients only need to directly connect to the RR.
l Non-client: an IBGP device that is neither an RR nor a client. In an AS, a non-client must
establish full-mesh connections with the RR and all the other non-clients.
l Originator: is a device that originates routes in an AS. The Originator_ID attribute helps
eliminate routing loops in a cluster.
l Cluster: is a set of the RR and clients. The Cluster_List attribute helps eliminate routing
loops between clusters.
RR Principles
Clients in a cluster only need to exchange routing information with the RR in the same cluster.
Therefore, clients only need to establish IBGP connections with the RR. This reduces the number
of IBGP connections in the cluster. As shown in Figure 9-4, in AS 65000, Cluster1 is comprised
of an RR and three clients. The number of IBGP connections in AS 65000 is then reduced from
10 to 4, which simplifies the device configuration and reduces the loads on the network and
CPU.
The RR allows a BGP device to advertise the BGP routes learned from an IBGP peer to other
IBGP peers, and uses the Cluster_List and Originator_ID attributes to eliminate routing loops.
The RR advertises routes to IBGP peers based on the following rules:
l The RR advertises the routes learned from a non-client to all the clients.
l The RR advertises the routes learned from a client to all the other clients and all the non-
clients.
l The RR advertises the routes learned from an EBGP peer to all the clients and non-clients.
Cluster_List Attribute
An RR and its clients form a cluster, which is identified by a unique cluster ID in an AS. To
prevent routing loops between clusters, an RR uses the Cluster_List attribute to record the cluster
IDs of all the clusters that a route passes through.
l When a route is reflected by an RR for the first time, the RR adds the local cluster ID to
the top of the cluster list. If there is no cluster list, the RR creates a Cluster_List attribute.
l When receiving an updated route, the RR checks the cluster list of the route. If the cluster
list contains the local cluster ID, the RR discards the route. If the cluster list does not contain
the local cluster ID, the RR adds the local cluster ID to the cluster list and then reflects the
route.
Originator_ID Attribute
The originator ID identifies the originator of a route and is generated by an RR to prevent routing
loops in a cluster. Its value is the same as the router ID.

Routers
l When a route is reflected by an RR for the first time, the RR adds the Originator_ID attribute
to this route. The Originator_ID attribute identifies the originator of the route. If the route
contains the Originator_ID attribute, the RR retains this Originator_ID attribute.
l When a device receives a route, the device compares the originator ID of the route with the
local router ID. If they are the same, the device discards the route.
Backup RR
To ensure network reliability and prevent single points of failures, redundant RRs are required
in a cluster. An RR allows a BGP device to advertise the routes received from an IBGP peer to
other IBGP peers. Therefore, routing loops may occur between RRs in the same cluster. To solve
this problem, all the RRs in the cluster must use the same cluster ID.
Figure 9-5 Backup RR
RR1 RR2
IBGP
Cluster
IBGP IBGP IBGP
Client1 Client2 Client3

AS65000
As shown in Figure 9-5, RR1 and RR2 reside in the same cluster and have the same cluster ID
configured.
l When Client1 receives an updated route from an EBGP peer, Client1 advertises this route
to RR1 and RR2 using IBGP.
l After RR1 and RR2 receive this route, they add the local cluster ID to the top of the cluster
list of the route and then reflect the route to other clients (Client2 and Client3) and to each
other.
l After RR1 and RR2 receive the reflected route from each other, they check the cluster list
of the route, finding that the cluster list contains their local cluster IDs. RR1 and RR2 discard
this route to prevent routing loops.
RRs of Multiple Clusters in an AS

There may be multiple clusters in an AS. RRs of the clusters establish IBGP peer relationships.
When RRs reside at different network layers, an RR at the lower network layer can be configured
as a client to implement hierarchical RR. When RRs reside at the same network layer, RRs of
different clusters can establish full-mesh connections to implement flat RR.
Hierarchical RR

Routers
Figure 9-6 Hierarchical RR
ISP
EBGP EBGP
RR-1 RR-1
Cluster1 Client/RR-2
Client
Cluster2
AS100
Client Client
In practice, hierarchical RR is often used. As shown in Figure 9-6, the ISP provides Internet
routes to AS 100. AS 100 is divided into two clusters, Cluster1 and Cluster2. Four devices in
Cluster1 are core routers and use a backup RR to ensure reliability.
Flat RR
Figure 9-7 Flat RR
Cluster 4
Cluster 3
Client Client Client
Client
Client
Client RR
RR
RR RR Client
Client
Client Client Client
AS100 Cluster 1 Cluster 2

Routers
As shown in Figure 9-7, the backbone network is divided into multiple clusters. RRs of the
clusters are non-clients and establish full-mesh connections with each other. Although each
client only establishes an IBGP connection with its RR, all the RRs and clients can receive all
9.2.7 BGP Confederation

In addition to a route reflector, the confederation is another method that reduces the number of
IBGP connections in an AS. A confederation divides an AS into sub-ASs. Full-mesh IBGP
connections are established in each sub-AS. EBGP connections are established between sub-
ASs. ASs outside a confederation still consider the confederation as an AS. After a confederation
divides an AS into sub-ASs, it assigns a confederation ID (the AS number) to each router within
the AS. This brings two benefits. First, original IBGP attributes are retained, including the
Local_Pref attribute, MED attribute, and Next_Hop attribute. Secondly, confederation-related
attributes are automatically deleted when being advertised outside a confederation. Therefore,
the administrator does not need to configure the rules for filtering information such as sub-AS
numbers at the egress of a confederation.
Figure 9-8 Networking diagram of a confederation
EBGP EBGP
IBGP IBGP AS65003
AS65001 AS65002 AS100
As shown in Figure 9-8, AS 100 is divided into three sub-ASs after a confederation is configured:
AS65001, AS65002, and AS65003. The AS number AS 100 is used as the confederation ID.
The number of IBGP connections in AS 100 is then reduced from 10 to 4, which simplifies the
device configuration and reduces the loads on the network and CPU. In addition, BGP devices
outside AS 100 only know the existence of AS 100 but not the confederation within AS 100.
Therefore, the confederation does not increase the CPU load.
Comparisons Between a Route Reflector and a Confederation

Table 9-3 compares a route reflector and a confederation in terms of the configuration, device
connection, and applications.

Routers
Table 9-3 Comparisons between a route reflector and a confederation
Route Reflector Confederation
Retains the existing network topology and Requires the logical topology to be changed.
ensures compatibility.
Requires only a route reflector to be Requires all devices to be reconfigured.

configured because clients do not need to
know that they are clients of a route reflector.
Requires full-mesh connections between Does not require full-mesh connections

clusters. between sub-ASs of a confederation because
the sub-ASs are special EBGP peers.
Applies to medium and large networks. Applies to large networks.
9.2.8 Route Summarization

The BGP routing table of each device on a large network is large. This burdens devices, increases
the route flapping probability, and affects network stability.
Route summarization is a mechanism that combines multiple routes into one route. This
mechanism allows a BGP device to advertise only the summarized route but not all the specific
routes to peers, therefore reducing the size of the BGP routing table. If the summarized route
flaps, the network is not affected, so network stability is improved.
BGP supports automatic summarization and manual summarization on IPv4 networks, and
supports only manual summarization on IPv6 networks.
l Automatic summarization: summarizes the routes imported by BGP. After automatic
summarization is configured, BGP summarizes routes based on the natural network
segment and advertises only the summarized route to peers. For example, BGP summarizes
10.1.1.1/24 and 10.2.1.1/24 (two Class A addresses with non-natural mask) into 10.0.0.0/8
(Class A address with natural mask).
l Manual summarization: summarizes routes in the local BGP routing table. Manual
summarization can help control the attributes of the summarized route and determine
whether to advertise specific routes.
To prevent routing loops caused by route summarization, BGP uses the AS_Set attribute. The
AS_Set attribute is an unordered set of all ASs that a route passes through. When the summarized
route enters an AS in the AS_Set attribute again, BGP finds that the local AS number has been
recorded in the AS_Set attribute of the route and discards this route to prevent a routing loop.
9.2.9 Route Dampening

When BGP is used on complex networks, route flapping occurs frequently. To prevent frequent
route flapping, BGP uses route dampening to suppress unstable routes.
Route flapping is a process of adding a route to an IP routing table and then withdrawing this
route. When route flapping occurs, a BGP device sends an Update message to its neighbors. The
devices that receive the Update message need to recalculate routes and modify routing tables.

Routers
Frequent route flapping consumes lots of bandwidths and CPU resources and even affects normal
network operation.
Figure 9-9 Diagram of BGP route dampening
Penalty value
suppress value
reuse value
suppress time
time
half-life
Route dampening measures the stability of a route using a penalty value. A larger penalty value
indicates a less stable route. As shown in Figure 9-9, each time route flapping occurs, BGP
increases the penalty of this route by a value of 1000. When the penalty value of a route exceeds
the suppression threshold, BGP suppresses this route, and does not add it to the IP routing table
or advertise any Update message to peers. After a route is suppressed for a period of time (half
life), the penalty value is reduced by half. When the penalty value of a route decreases to the
suppression threshold, the route is reusable and is added to the routing table. At the same time,
BGP advertises an Update message to peers. The suppression time is the period from when a
route is suppressed to when the route is reusable.
Route dampening applies only to EBGP routes but not IBGP routes. IBGP routes may include
the routes of the local AS, and an IGP network requires that the routing tables of devices within
an AS be the same. If IBGP routes were dampened, routing tables on devices are inconsistent
when these devices have different dampening parameters. Therefore, route dampening does not
apply to IBGP routes.
9.2.10 BFD for BGP

BGP periodically sends messages to peers to detect the status of the peers. It takes more than 1
second for this detection mechanism to detect a fault. When data is transmitted at gigabit rates,
long-time fault detection will cause packet loss. This cannot meet high reliability requirements
of networks. Bidirectional Forwarding Detection (BFD) provides the millisecond-level fault
detection for BGP to improve network reliability.

Routers
Figure 9-10 Networking diagram of BFD for BGP
EBGP
AS100 AS200
RouterA RouterB
As shown in Figure 9-10, RouterA belongs to AS 100 and RouterB belongs to AS 200. RouterA
and RouterB are directly connected and establish the EBGP peer relationship. Association
between BGP and BFD is configured on RouterA and RouterB. When a fault occurs on the link
between RouterA and RouterB, BFD can rapidly detect that the BFD session changes from Up
to Down and notify this fault to RouterA and RouterB. RouterA and RouterB process the
neighbor Down event and select routes again using BGP.
9.2.11 BGP Tracking
BGP tracking provides fast link fault detection to speed up network convergence. When a fault
occurs on the link between BGP peers that have BGP tracking configured, BGP tracking can
quickly detect peer unreachability and instruct the routing management module to notify BGP
of the fault, implementing rapid network convergence.
Compared to BFD, BGP tracking is easy to configure because it needs to be configured only on
the local device. BGP tracking is a fault detection mechanism at the routing layer, whereas BFD
is a fault detection mechanism at the link layer. BGP route convergence on a network where
BGP tracking is configured is slower than that on a network where BFD is configured. Therefore,
BGP tracking cannot meet the requirements of voice services that require fast convergence.
Applications
As shown in Figure 9-11, RouterA and RouterB, and RouterB and RouterC establish IGP
connections. RouterA and RouterC establish an IBGP peer relationship. BGP tracking is
configured on RouterA. When a fault occurs on the link between RouterA and RouterB, IGP
performs fast convergence. Subsequently, BGP tracking detects the unreachability of the route
to RouterC and notifies the fault to BGP on RouterA, which then interrupts the BGP connection
with RouterC.
Figure 9-11 Networking diagram of BGP tracking
RouterA RouterB RouterC

Routers
NOTE
If establishing an IBGP peer relationship requires IGP routes, the interval between peer unreachability
discovery and connection interruption needs to be configured, and this interval must be longer than the
IGP route convergence time. Otherwise, the BGP peer relationship may have been interrupted before IGP
route flapping caused by transient interruption is suppressed, causing unnecessary BGP convergence.
9.2.12 BGP GR
BGP graceful restart (GR) is high availability solutions that minimize the impact of device
failures on user services.
BGP GR ensures that the forwarding plane continues to guide data forwarding during a device
restart or active/standby switchover. The operations on the control plane, such as reestablishing
peer relationships and performing route calculation, do not affect the forwarding plane. This
mechanism prevents service interruptions caused by route flapping and improves network
reliability.
GR concepts are as follows:
l GR restarter: is the device that is restarted by the administrator or triggered by failures to
perform GR.
l GR helper: is the neighbor that helps the GR restarter to perform GR.
l GR time: is the time during which the GR helper retains forwarding information after
detecting the restart or active/standby switchover of the GR restarter.
BGP GR process is as follows:
1. Using the BGP capability negotiation mechanism, the GR restarter and helper know each
other's GR capability and establish a GR session.
2. When detecting the restart or active/standby switchover of the GR restarter, the GR helper
does not delete the routing information and forwarding entries of the GR restarter or notify
other neighbors of the restart or switchover, but waits to reestablish a BGP connection with
the GR restarter.
3. The GR restarter reestablishes neighbor relationships with all GR helpers before the GR
time expires.
9.2.13 BGP ORF

RFC 5291 and RFC 5292 define the prefix-based BGP outbound route filtering (ORF) capability
to advertise required BGP routes. BGP ORF allows a device to send prefix-based import policies
in a Route-refresh message to BGP peers. BGP peers construct export policies based on these
import policies to filter routes before sending these routes, which has the following advantages:
l Prevents the local device from receiving a large number of unnecessary routes.
l Reduces CPU usage of the local device.
l Simplifies the configuration of BGP peers.
l Improves link bandwidth efficiency.
Applications
BGP ORF applies to the scenario when a device wants BGP peers to send only required routes,
and BGP peers do not want to maintain different export policies for different devices.

Routers
Figure 9-12 Inter-AS EBGP peers
AS 100 AS 200
RouterA RouterB
As shown in Figure 9-12, after negotiating the prefix-based ORF capability with RouterB,
RouterA adds the local prefix-based import policies to a Route-refresh message and sends the
message to RouterB. RouterB constructs export policies based on the received Route-refresh
message and sends required routes to RouterA using a Route-refresh message. RouterA receives
only required routes, and RouterB does not need to maintain routing policies. This reduces the
configuration workload.
Figure 9-13 Intra-AS route reflector
AS 100
RR
RouterA RouterB
As shown in Figure 9-13, there is a route reflector (RR) in AS 100. RouterA and RouterB are
the clients of the RR. RouterA, RouterB, and the RR negotiate the prefix-based ORF capability.
RouterA and RouterB then add the local prefix-based import policies to Route-refresh messages
and send the messages to the RR. The RR constructs export policies based on the received import
policies and reflects required routes in Route-refresh messages to RouterA and RouterB.
RouterA and RouterB receive only required routes, and the RR does not need to maintain routing
policies. This reduces the configuration workload.
9.2.14 Dynamic Update Peer-Groups

Currently, the rapid growth in the size of the routing table and the complexity of the network
topology require BGP to support more peers. Especially in the case of a large number of peers
and routes, high-performance grouping and forwarding are required when a router needs to send
routes to a large number of BGP peers, most of which share the same outbound policies.
The dynamic update peer-groups feature treats all the BGP peers with the same outbound policies
as an update-group. In this case, routes are grouped uniformly and then sent separately. That is,
each route to be sent is grouped once and then sent to all peers in the update-group, improving

Routers
grouping efficiency exponentially. For example, a route reflector (RR) has 100 clients and needs
to reflect 100,000 routes to these clients. If the RR sends the routes grouped per peer to 100
clients, the total number of times that all routes are grouped is 10,000,000 (100,000 x 100). After
the dynamic update peer-groups feature is used, the total number of grouping times changes to
100,000 (100,000 x 1), improving grouping performance by a factor of 100.
Applications
BGP uses the dynamic update peer-groups technology when a large number of peers and routes
exist and most peers share the same outbound policies, improving BGP route grouping and
forwarding performance. The dynamic update peer-groups feature applies to the following
scenarios:
l International gateway
As shown in Figure 9-14, the Internet gateway (IGW) router sends routes to all neighboring
ASs. If the IGW router supports the dynamic update peer-groups feature, its BGP route
forwarding performance will be greatly improved.
Figure 9-14 Networking diagram of the international gateway
AS1000
AS200
AS65001
AS30
Internet Route
IGW
Router
AS100
AS65002
AS120
l RR
As shown in Figure 9-15, RRs send routes to all clients. If the RRs support the dynamic
update peer-groups feature, their BGP route forwarding performance will be greatly
improved.

Routers
Figure 9-15 Networking diagram of RRs
AS100
RR1 RR2
IBGP IBGP
Client Client Client Client Client Client
l ASBR
As shown in Figure 9-16, RouterB, as an Autonomous System Boundary Router (ASBR),
sends all the routes received from an EBGP neighbor RouterA to all IBGP neighbors. If
RouterB supports the dynamic update peer-groups feature, its BGP route forwarding
performance will be greatly improved.
Figure 9-16 Networking diagram of a PE connecting to multiple IBGP neighbors
AS200
RouterC
IBGP
AS100 RouterD
RouterA EBGP
RouterB RouterE
IBGP
RouterF
9.2.15 MP-BGP
Traditional BGP-4 manages only IPv4 routing information. Inter-AS transmission of other
network layer protocol packets (such as IPv6 and multicast packets) is limited. To support
multiple network layer protocols, Multiprotocol BGP (MP-BGP) is designed in RFC 4760 as an
extension to BGP-4. MP-BGP uses extended attributes and address families to support IPv6,
multicast, and VPN, without changing the existing BGP packet forwarding and routing
mechanism.

Routers
MP-BGP is called BGP4+ on IPv6 unicast networks or called multicast BGP (MBGP) on IPv4
multicast networks. MP-BGP establishes separate topologies for IPv6 unicast networks and IPv4
multicast networks, and stores IPv6 unicast and IPv4 multicast routing information in different
routing tables. This ensures that routing information of IPv6 unicast networks and IPv4 multicast
networks is separated from each other, and allows routes of different networks to be maintained
using different routing policies.
Extended Attributes
In BGP, an Update message carries three IPv4-related attributes: NLRI, Next_Hop, and
Aggregator.
To support multiple network layer protocols, BGP requires NLRI and Next_Hop attributes to
carry information about network layer protocols. Therefore, MP-BGP uses the following new
optional non-transitive attributes:
l MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to advertise

reachable routes and next hop information.
l MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to
withdraw unreachable routes.
Address Families
MP-BGP uses address families to differentiate network layer protocols. Currently, devices
support the following address family views:
l BGP-IPv4 unicast address family view
l BGP-IPv4 multicast address family view
l BGP-VPN instance IPv4 address family view
l BGP-VPNv4 address family view
l BGP-IPv6 unicast address family view
l BGP-VPN instance IPv6 address family view

After basic BGP functions are configured, you can enable basic communication functions on
BGP networks. If other BGP functions are required, configure them according to reference
sections.
Table 9-4 describes the BGP configuration tasks.
NOTE
If BGP is configured on an IPv6 network, all the peer addresses specified in the Peer command must be
IPv6 addresses.

Routers
Table 9-4 BGP configuration tasks
Configuring basic BGP The configuration of basic 9.5.1 Configuring Basic

functions BGP functions is the BGP Functions
foundation of the BGP
network construction and the
precondition for other BGP
functions.
Configuring BGP security On BGP networks, 9.5.2 Configuring BGP

unauthorized users can attack Security
the BGP network by
carried on BGP networks,
configure BGP MD5
authentication, BGP
Keychain authentication, or
Generalized TTL Security
Mechanism (GTSM)
function.
Simplifying IBGP network Because routes received from 9.5.3 Simplifying IBGP
connection the IBGP neighbors will not Network Connections
be sent to other IBGP
neighbors, fully-meshed
connections must be
established on the IBGP
network. However, when the
number of devices is large,
peer configuration is very
complex on the fully-meshed
IBGP network, and the
consumption of network
resources and device CPU
resources will increase. To
reduce the number of IBGP
network connections and
better plan the network,
configure the route reflector
and confederation .

Routers
Configuring BGP route In a BGP routing table, 9.5.4 Configuring BGP

selection and load balancing multiple routes to the same Route Selection and Load
destination may exist. To Balancing
guide route selection, BGP
defines next-hop policies and
route selection rules. The
priority of next-hop policies
is higher than that of BGP
route selection rules. After
the next-hop policies are
performed, BGP selects
routes according to the route
selection rules.
Usually there are multiple
valid routes to the same
destination on the network. If
BGP only advertises the
optimal route to its peer,
unbalanced traffic on
different routes will occur.
The BGP load-balancing
configuration can balance
load on different routes and
reduce network congestion.
Controlling advertising and With the expansion of the 9.5.5 Controlling the
receiving of BGP routes network scale, the sharp Receiving and
increase of routing tables Advertisement of BGP
leads to greater load on Routes
networks and increasing
network security problems.
To solve this problem, filter
routes according to the
routing policies and only
send and receive required
BGP routes. In addition,
multiple routes to the same
destination may exist. If these
routes need to pass through
different ASs, direct service
traffic to specific ASs or filter
the routes to be advertised.

Routers
Configuring and adjusting To enable BGP to rapidly 9.5.6 Adjusting the BGP
the BGP network detect network changes, Network Convergence
convergence rate speed up the BGP network Speed
down the BGP network
convergence.
Configuring BGP reliability To avoid long service 9.5.7 Configuring BGP

interruption when faults Reliability
occur on BGP networks,
adopt the solution of standby
link. However, the BGP
mechanism requires more
than one second to detect the
faults and perform active/
standby switchover. To
ensure that users of delay-
sensitive services such as the
voice service do not detect
the service interruption,
associate BGP tracking,
BGP, and BFD to implement
fast fault detection, and
meanwhile use BGP GR to
perform fast switchover after
the fault detection.

Routers
Configuring BGP route The BGP routing table on a 9.5.8 Configuring BGP
aggregation medium or large BGP Route Summarization
network contains a large
number of routing entries.
Storing the routing table
consumes a large number of
memory resources, and
transmitting and processing
the routing information
network resources. Route
aggregation can reduce the
size of a routing table,
prevent specific routes from
being advertised, and
minimize the impact of route
flapping on networks.
Although BGP automatic
route aggregation is easy to
configure, it only aggregates
routes according to the
natural network segment.
BGP manual route
aggregation can be used with
flexible routing policies to
enable BGP to effectively
transmit and control routes.

Routers
Configuring BGP neighbors BGP Outbound Route Filters 9.5.9 Configuring On-
to advertise routes on (ORF) is used to enable BGP demand Route
demand neighbors to advertise routes Advertisement
on demand.
If neighbors of the local BGP
device have different route
requirements, different
export policies must be
configured on the local BGP
device. In this case, the
configuration workload and
maintenance costs of the
local BGP device will
increase. To solve this
problem, configure BGP
ORF on BGP neighbor
devices, allowing BGP
neighbor devices to maintain
route policies on demand and
send them to the local BGP
device as export policies.
This reduces the
configuration workload and
maintenance costs of the
local BGP device.

Routers
Configuring a local BGP The BGP routing table on a 9.5.10 Configuring BGP to
device to send a default route medium or large BGP Advertise Default Routes to
to its peer network contains a large Peers
number of routing entries.
Storing the routing table
memory resources, and
transmitting and processing
the routing information
network resources. If
multiple routes in a peer BGP
routing table are sent only
from a local device,
configure the local device to
send a default route to its
peer. In this case, the local
device will send a default
route with the next hop
address as the local address to
its peer, regardless of
whether there is a default
route in the local routing
table. After the local device is
configured to send only the
default route to its peer using
the routing policies, the
number of network routes is
greatly reduced and the peer
memory resources and
network resources are largely
saved.
Configuring path MTU auto BGP path MTU auto 9.5.11 Configuring Path
discovery discovery allows the MTU Auto Discovery
discovery of the minimum
MTU value (path MTU) on
the network path from the
source to the destination,
which enables TCP to
transmit the BGP messages
according to the path MTU.
This increases the BGP
message transmission
efficiency and improves the
BGP performance.

Routers
Configuring MP-BGP Traditional BGP-4 only 9.5.12 Configuring MP-

manages IPv4 unicast routing BGP
information and does not
support route transmission
between ASs of other
networks such as IPv6 and
multicast networks. To
support multiple network
layer protocols, the Internet
Engineering Task Force
(IETF) extends BGP-4 to
Multiprotocol Extensions for
BGP-4 (MP-BGP). RFC
4760 defines the current MP-
BPG standard. Features
supported by MP-BGP on
IPv6 networks are called
BGP4+ and multicast
networks are called Multicast
BGP (MBGP).

This section describes the default configuration of BGP, which can be changed according to
Table 9-5 describes the default configuration of BGP.
Table 9-5 Default configuration of BGP
BGP Disabled
Keepalive message interval 60s
Hold time 180s
9.5 Configuring BGP

This section describes how to configure BGP.
9.5.1 Configuring Basic BGP Functions

Before building a BGP network, you need to configure basic BGP functions.

Routers
Before configuring basic BGP functions, complete the following task:
l Configuring IP addresses for interfaces to ensure network-layer communication between

neighbor nodes
Perform the following operations in sequence and as required.
9.5.1.1 Starting a BGP Process
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp { as-number-plain | as-number-dot }
BGP is started, the local AS number is specified, and the BGP view is displayed.
NOTICE
After BGP peers are configured, changing the router ID of a BGP peer resets BGP peer
relationships.
Step 3 Run:
router-id ipv4-address
A router ID of a BGP device is set.
By default, BGP prefers the router ID configured in the system view, highest loopback interface
address, highest interface address, and then IP address 0.0.0.0.
NOTE
To improve network stability, configure the IP address of a loopback interface as the router ID is
recommended.
----End
9.5.1.2 Configuring BGP Peers
Context
During the configuration of BGP peers, if the AS number of the specified peer is the same as
the local AS number, an IBGP peer is configured. If the AS number of the specified peer is

Routers
different from the local AS number, an EBGP peer is configured. To enhance the stability of
BGP connections, you are advised to use the reachable loopback interface addresses to establish
BGP connections.
When loopback interface addresses are used to establish a BGP connection, run the peer
connect-interface command on the both ends of the BGP connection to ensure the correctness
of interfaces and addresses on the TCP connection. If the command is run on only one end, the
BGP connection may fail to be established.
When loopback interface addresses are used to establish an EBGP connection, the peer ebgp-
max-hop command with hop-count greater than or equal to 2 must be run. Otherwise, the EBGP
connection cannot be established.
To perform the same configuration on a large number of peers, configure a BGP peer group
according to 9.5.1.3 (Optional) Configuring a BGP Peer Group to reduce the configuration
workload.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The BGP view is displayed.
Step 3 Run:
peer { ipv4-address | ipv6-address } as-number { as-number-plain | as-number-dot }
The BGP peer is created.
By default, BGP does not create BGP peers.

peer ipv4-address connect-interface interface-type interface-number [ ipv4-source-
address ]
or run:
peer ipv6-address connect-interface interface-type interface-number [ ipv6-source-
address ]
A source interface and a source IP address are specified for the peer to establish a TCP
connection.
By default, BGP uses the interface that is directly connected to the peer to establish a TCP
connection.

peer { ipv4-address | ipv6-address } ebgp-max-hop [ hop-count ]
The maximum number of hops allowed for the establishment of an EBGP connection is set.
By default, the maximum number of hops allowed for an EBGP connection is 1. That is, an
EBGP connection must be established on a directly connected physical link.

Routers

peer { ipv4-address | ipv6-address } description description-text
The description of the peer is configured.
NOTE
If a BGP peer group is configured on an IPv4 unicast network, steps 7 and 8 are not required. If a BGP
peer group is configured on an IPv4 unicast network and an IPv6 unicast network, steps 7 and 8 are required.
Step 7 (Optional) Run the following commands as required.

l Run:
ipv4-family multicast
The BGP-IPv4 multicast address family view is displayed.

l Run:
ipv6-family [ unicast ]
The BGP-IPv6 unicast address family view is displayed.

peer { ipv4-address | ipv6-address } enable
MP-BGP is enabled on the BGP peers to configure them as MP-BGP peers.
----End
9.5.1.3 (Optional) Configuring a BGP Peer Group
Context
A large BGP network has a large number of peers. It is difficult to configure and maintain these
peers. You can add the BGP peers with the same configurations to a BGP peer group and then
configure the BGP peers in batches. This simplifies peer management and improves route
advertisement efficiency.
NOTE
l If a function is configured on a peer and its peer group, the function configured on the peer takes precedence
over that configured on the peer group.
l When loopback interface or sub-interface addresses are used to establish a BGP connection, you are
advertised to perform step 6 on the both ends of the BGP connection simultaneously to ensure the correct
establishment of the connection. If step 6 is performed on only one end, the BGP connection may fail to be
established.
l When loopback interface are used to establish an EBGP connection, step 7 is required and hop-count in the
peer ebgp-max-hop command must be greater than or equal to 2. Otherwise, the EBGP connection cannot
be established.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers
Step 3 Run:
group group-name [ external | internal ]
A BGP peer group is created.
NOTE
The AS number of an IBGP peer group is the local AS number. Therefore, step 4 is not required.
Step 4 Run:
peer group-name as-number { as-number-plain | as-number-dot }
An AS number is configured for the EBGP peer group.
NOTE
To add an EBGP peer to a peer group, configure the EBGP peer according to 9.5.1.2 Configuring BGP
Peers and then perform step 5.
To add an IBGP peer to a peer group, perform step 5. The system creates an IBGP peer in the BGP view
and sets its AS number as the AS number of the peer group.
Step 5 Run:
peer { ipv4-address | ipv6-address } group group-name
A peer is added to the peer group.
NOTE
You can repeat step 5 to add multiple peers to a peer group.

peer group-name connect-interface interface-type interface-number [ ipv4-source-
address ]
or run:
peer group-name connect-interface interface-type interface-number [ ipv6-source-
address ]
A source interface and a source IP address are specified for the peer to establish a TCP
connection.
By default, BGP uses the interface that is directly connected to the peer to establish a TCP
connection.
NOTE
The configurations of GTSM and EBGP-MAX-HOP affect the TTL values of BGP packets, which may
cause a conflict between TTL values. Therefore, you can configure only one of the two functions for a peer
or peer group.

peer group-name ebgp-max-hop [ hop-count ]
The maximum number of hops allowed for the establishment of an EBGP connection is set.
By default, the maximum number of hops allowed for an EBGP connection is 1. That is, an
EBGP connection must be established on a directly connected physical link.

peer group-name description description-text

Routers
The description is configured for the peer group.
NOTE
If a BGP peer group is configured on an IPv4 unicast network, steps 9 and 10 are not required. If a BGP
peer group is configured on an IPv4 unicast network and an IPv6 unicast network, steps 9 and 10 are
required.
Step 9 (Optional) Run the following commands as required.

l Run:

l Run:
Step 10 Run:
peer group-name enable
MP-BGP is enabled on the BGP peers to configure them as MP-BGP peers.
----End
9.5.1.4 Configuring BGP to Import Routes
Context
BGP cannot discover routes and needs to import routes such as IGP routes into BGP routing
tables so that the imported routes can be transmitted within an AS or between ASs. BGP imports
routes in either import or network mode:
l In import mode, BGP imports IGP routes, including RIP, OSPF, and IS-IS routes, into BGP
routing tables based on protocol type. To ensure the validity of imported IGP routes, BGP
can also import static routes and direct routes in import mode.
l In network mode, BGP imports the routes in the IP routing table one by one to BGP routing
tables. The network mode is more accurate than the import mode.
Procedure
l In import mode
1. Run:
system-view

2. Run:

3. Enter the corresponding address family view based on network type to configure BGP
devices on networks.
Run:
ipv4-family { unicast | multicast }

Routers
The IPv4 address family view is displayed.

Run:

4. Run:
import-route protocol [ process-id ] [ med med | route-policy route-policy-
name ] *
BGP is configured to import routes of other routing protocols.

5. (Optional) Run:
default-route imported
BGP is allowed to import default routes from the local IP routing table.
By default, BGP does not add default routes to BGP routing tables.
l In network mode
1. Run:
system-view

2. Run:

Run:

Run:

4. Run:
network ipv4-address [ mask | mask-length ] [ route-policy route-policy-
name ]
Or run:
network ipv6-address prefix-length [ route-policy route-policy-name ]
BGP is configured to import routes from the IPv4 or IPv6 routing table one by one.
----End
Procedure
l Run the display bgp peer [ verbose ] command to check information about all BGP peers.

Routers
l Run the display bgp peer ipv4-address { log-info | verbose } command to check
information about the specified BGP peer.
l Run the display bgp routing-table [ ipv4-address [ mask | mask-length ] ] command to
check BGP routing information.
l Run the display bgp group [ group-name ] command to check information about the
specified BGP peer group.
l Run the display bgp multicast peer [ [ peer-address ] verbose ] command to check
information about the specified MBGP peer.
l Run the display bgp multicast group [ group-name ] command to displays the information
about an MBGP peer group.
l Run the display bgp multicast network command to check the routing information that
MBGP advertises.
l Run the display bgp multicast routing-table [ ip-address [ mask-length [ longer-
prefixes ] | mask [ longer-prefixes ] ] ] command to check the MBGP routing table.
----End
9.5.2 Configuring BGP Security

Configuring connection authentication and BGP GTSM for BGP peers can improve BGP
network security.
Before configuring BGP security, complete the following task:
l Configuring Basic BGP Functions
You can perform the following configuration tasks as required. The following configuration
tasks (excluding the task of checking the configuration) can be performed at any sequence.
9.5.2.1 Configuring MD5 Authentication
Context
BGP uses TCP as the transmission protocol, and considers a packet valid as long as the source
address, destination address, source port, destination port, and TCP sequence number of the
packet are correct. However, most parameters in a packet may be easily obtained by attackers.
To protect BGP from attacks, MD5 authentication or keychain authentication can be used
between BGP peers to reduce the possibility of attacks. The MD5 algorithm is easy to configure,
generates a single password that needs to be manually changed.
NOTICE
If simple is selected during the configuration of the MD5 authentication password, the password
is saved in the configuration file in plain text. This brings security risks. It is recommended that

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { ipv4-address | group-name | ipv6-address } password { cipher cipher-
password | simple simple-password }
The MD5 authentication password is set.
NOTE
l To prevent the MD5 password set on BGP peers from being decrypted, update the MD5 password
periodically.
l BGP MD5 authentication and BGP keychain authentication are mutually exclusive, and only one of
them can be configured for a BGP peer.
----End
9.5.2.2 Configuring Keychain Authentication
Context
BGP uses TCP as the transmission protocol, and considers a packet valid as long as the source
address, destination address, source port, destination port, and TCP sequence number of the
packet are correct. However, most parameters in a packet may be easily obtained by attackers.
To protect BGP from attacks, use MD5 authentication or keychain authentication between BGP
peers to reduce the possibility of attacks. The keychain algorithm is complex to configure and
generates a set of passwords. Keychain authentication allows automatically changing a password
based on the configuration. Therefore, keychain authentication applies to networks requiring
high security.
NOTE
Before configuring BGP keychain authentication, configure a keychain corresponding to keychain-name.

Otherwise, the TCP connection cannot be established. For details about configuring a keychain, see
"Keychain Configuration" in the Huawei AR150&200&1200&2200&3200 Series Configuration Guide -
Security.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers

Step 3 Run:
peer { ipv4-address | group-name | ipv6-address } keychain keychain-name
Keychain authentication is configured,
NOTE
l You must configure keychain authentication on both BGP peers. Encryption algorithms and passwords
configured on both peers must be the same; otherwise, the TCP connection cannot be established
between BGP peers and BGP messages cannot be transmitted.
l BGP MD5 authentication and BGP keychain authentication are mutually exclusive, and only one of
them can be configured for a BGP peer.
----End
9.5.2.3 Configuring BGP GTSM
Context
To protect a device against the attacks of forged BGP packets, you can configure GTSM to check
whether the TTL value in the IP packet header is within the specified range.GTSM allows or
discards packets of which TTL values are not within the specified range according to networking
requirements. When the default action to be taken on packets is set to drop in GTSM, set a proper
TTL range according to the network topology. Then packets of which TTL values are not within
the specified range are discarded. This prevents attackers from sending forged BGP packets to
consume CPU resources.
Procedure
Step 1 Run:
system-view

Step 2 Run:
NOTE
The configurations of GTSM and peer ebgp-max-hop affect the TTL values of BGP packets, which may
cause a conflict between TTL values. Therefore, you can configure only one of the two functions for a peer
or peer group.
Step 3 Run:
peer { group-name | ipv4-address | ipv6-address } valid-ttl-hops [ hops ]
BGP GTSM is configured.

By default, GTSM is not configured on any BGP peer or peer group.
Step 4 (Optional) Run the follow command in the system view:
gtsm default-action { drop | pass }
The default action to be taken on the packets that do not match a GTSM policy is set.

Routers
By default, the action to be taken on the packets that do not match the GTSM policy is pass.
Step 5 (Optional) Run the follow command in the system view:

gtsm log drop-packet all
The log function is enabled on boards.
The log records information that GTSM drops packets, which helps locate faults.
----End
Procedure
l Run the display bgp peer verbose command to check authentication detailed information
about the specified BGP peer.
----End
9.5.3 Simplifying IBGP Network Connections

Configuring a route reflector and a confederation on an IBGP network can simplify IBGP
network connections.
Before simplifying IBGP network connections, complete the following configuration task:
Perform the following configuration tasks as required.
9.5.3.1 Configuring a BGP Route Reflector
Context
To ensure the connectivity between IBGP peers within an AS, you need to establish full-mesh
connections between the IBGP peers. When there are many IBGP peers, it is costly to establish
a fully-meshed network. A route reflector (RR) can solve this problem.
A cluster ID can help prevent routing loops between multiple RRs within a cluster and between
clusters. When a cluster has multiple RRs, the same cluster ID must be configured for all the
RRs within the cluster.
If full-mesh IBGP connections are established between clients of multiple RRs, route reflection
between clients is not required and wastes bandwidth resources. In this case, prohibit route
reflection between clients to reduce the network burden.

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Enter the corresponding address family view based on network type to configure BGP devices
on networks.
l Run:
ipv4-family unicast

l Run:
Step 4 Run:
peer { ipv4-address | group-name | ipv6-address } reflect-client
An RR and its client are configured.

reflector cluster-id cluster-id
A cluster ID is configured for the RR.
By default, each RR uses its router ID as the cluster ID.

undo reflect between-clients
Route reflection is prohibited between clients.
By default, route reflection is allowed between clients.

bgp-rib-only [ route-policy route-policy-name ]
BGP is prohibited from adding preferred routes to IP routing tables.
By default, BGP adds preferred routes to IP routing tables.
----End

l Run the display bgp routing-table [ network [ { mask | mask-length } [ longer-
prefixes ] ] ] command to check routing information in a BGP routing table.

Routers

9.5.3.2 Configuring a BGP Confederation
Context
A confederation divides an AS into sub-ASs. Within each sub-AS, IBGP peers establish full-
mesh connections or have an RR configured. Sub-ASs establish EBGP connections. On a large
BGP network, configuring a confederation can reduce the number of IBGP connections, simplify
routing policy management, and improve route advertisement efficiency.
Other devices may implement the confederation not in accordance with RFC 3065. You can
configure confederation compatibility to make standard devices compatible with nonstandard
devices.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
confederation id { as-number-plain | as-number-dot }
A confederation ID is configured.
NOTICE
An old speaker that has a 2-byte AS number cannot be in the same confederation with a new
speaker that has a 4-byte AS number. Otherwise, a routing loop may occur. This is because the
AS4_Path attribute does not support confederations.
Step 4 Run:
confederation peer-as { as-number-plain | as-number-dot } &<1-32>
A sub-AS number is configured for a confederation.

confederation nonstandard
Confederation compatibility is configured.
By default, confederations comply with RFC 3065.
----End

Routers

l Run the display bgp peer [ ipv4-address ] verbose command to check detailed information
about BGP peers.
9.5.4 Configuring BGP Route Selection and Load Balancing

BGP has many route attributes. You can configure these attributes to change the route selection
result.
Before configuring BGP route attributes, complete the following task:
tasks (excluding the task of checking the configuration) can be performed at any sequence. For
detailed route selection rules, see 9.2.5 BGP Route Selection Rules and Load Balancing.
9.5.4.1 Configuring the BGP Priority
Context
The routing protocols may share and select routing information because routers may run multiple
dynamic routing protocols at the same time. The system sets a default priority for each routing
protocol. When multiple routing protocols are used to select routes, the route selected by the
routing protocol with a higher priority takes effect.
Procedure
Step 1 Run:
system-view
Step 2 Run:
on networks.
l Run:

l Run:

Routers

Step 4 Run:
preference { external internal local | route-policy route-policy-name }
The BGP priority is set.

The default BGP priority is 255.
NOTE
You cannot use the peer route-policy command on BGP peers to apply routing policies to set the BGP
priority.
----End
9.5.4.2 Configuring the Next_Hop Attribute
Context
When an Autonomous System Boundary Router (ASBR) forwards the route learned from an
EBGP peer to an IBGP peer, the ASBR does not change the next hop of the route by default.
When the IBGP peer receives this route, it finds the next hop unreachable, sets the route to
inactive, and does not use this route to guide traffic forwarding. To enable the IBGP peer to use
this route to guide traffic forwarding, configure the ASBR to set its IP address as the next hop
of the route when the ASBR forwards this route to the IBGP peer. After the IBGP peer receives
the route from the ASBR, it finds the next hop of the route reachable, sets the route to active,
and uses this route to guide traffic forwarding.
When a BGP route changes, BGP needs to iterate the indirect next hop of the route again. If no
restriction is imposed on the iterated route, BGP may iterate the next hop to an incorrect
forwarding path, causing traffic loss. To prevent traffic loss, configure routing policy-based
route iteration to prevent traffic loss.
Procedure
Step 1 Run:
system-view

Step 2 Run:

on networks.
l Run:

l Run:

Routers
Step 4 Perform either of the following operations as required:

l Run:
peer { ipv4-address | group-name | ipv6-address } next-hop-local
A BGP device is configured to set its IP address as the next hop when the device advertises
routes to an IBGP peer or an IBGP peer group.
By default, a BGP device does not modify the next-hop address when advertising routes
to its IBGP peers.
l Run:
nexthop recursive-lookup route-policy route-policy-name
Routing-policy-based next hop iteration is configured.

By default, routing-policy-based next hop iteration is not configured.
l Run the following command in the IPv4 unicast address family view:
peer { ipv4-address | group-name } next-hop-invariable
The device is prevented from changing the next-hop address of a route imported from an
IGP before advertising the route to an IBGP peer.
By default, a device changes the next-hop address of a route imported from an IGP to the
address of the interface connecting the device to its peer when advertising the route to an
IBGP peer.
NOTE
The nexthop recursive-lookup route-policy route-policy-name command does not take effect for the
routes received from direct connected EBGP peers.
----End
9.5.4.3 Configuring the PrefVal Attribute
Context
The PrefVal attribute is a Huawei proprietary attribute and is valid only on the device where it
is configured. When a BGP routing table contains multiple routes to the same destination, BGP
prefers the route with the highest PrefVal.
Procedure
Step 1 Run:
system-view
Step 2 Run:
on networks.

Routers
l Run:

l Run:
Step 4 Run:
peer { group-name | ipv4-address | ipv6-address } preferred-value value
The PrefVal attribute is configured for all the routes learned from a specified peer.
By default, the PrefVal of a route learned from a peer is 0.
----End
9.5.4.4 Configuring the Default Local_Pref Attribute
Context
The Local_Pref attribute is used to determine the optimal route for outgoing traffic of an AS.
When a BGP device obtains multiple routes to the same destination address but with different
next hops from different IBGP peers, the BGP device prefers the route with the highest
Local_Pref.
Procedure
Step 1 Run:
system-view
Step 2 Run:
on networks.
l Run:

l Run:
Step 4 Run:
default local-preference local-preference
The default Local_Pref attribute is configured.

Routers
By default, the Local_Pref attribute is 100.
----End
9.5.4.5 Configuring the AS_Path Attribute
Context
The AS_Path attribute records all the ASs that a route passes through from the source to the
destination in the vector order. You can configure the AS_Path attribute to implement flexible
route selection.
l Generally, BGP compares the AS_Path lists of routes and prefers the route with the shortest
AS_Path list. When the AS_Path attribute is not required in route selection, configure BGP
not to compare the AS_Path lists of routes during route selection.
l In most cases, BGP detects routing loops based on AS number. However, to ensure correct
route transmission on a hub-and-spoke network, you need to configure all the BGP peers
that VPN routes advertised from a hub CE to a spoke CE pass through to accept the routes
with a repeated AS number.
l Public AS numbers can be used on the Internet, but private AS numbers cannot because
they may cause routing loops. To prevent routing loops, configure the AS_Path attribute
to carry only public AS numbers in EBGP Update messages.
l When the AS_Path attribute is reconstructed or summarized routes are generated, you can
set the maximum number of AS numbers in the AS_Path attribute. Then a BGP device
checks whether the number of AS numbers in the AS_Path attribute of a route exceeds the
maximum value. If so, the BGP device discards the route.
l A device usually supports only one BGP process. This indicates that a device supports only
one AS number. In some cases, for example, when network migration changes an AS
number, you can set a fake AS number to ensure successful network migration.
l BGP checks the first AS number in the AS_Path list that is carried in the Update message
sent by an EBGP peer. If the first AS number specifies the AS where the EBGP peer resides,
BGP accepts the Update message. Otherwise, BGP rejects the Update message and
interrupts the EBGP connection. If you do not want BGP to check the first AS number,
disable BGP from checking the first AS number.
Procedure
Step 1 Run:
system-view
Step 2 Run:
route-policy route-policy-name { deny | permit } node node
A node is configured for a route-policy, and the view of the route-policy is displayed.
Step 3 (Optional) Configure matching rules for the route-policy to change only the community
attributes of the routes meet matching rules.

Routers
By default, all routes meet matching rules. For details, see 10.5.2.2 (Optional) Configuring an
if-match Clause.
Step 4 Run:
apply as-path { as-number-plain | as-number-dot } &<1-10> { additive | overwrite }
The AS_Path attribute is set for BGP routes.

Step 5 Run:
quit

Step 6 Run:

on networks.
l Run:

l Run:

Step 8 Add the AS_Path attribute to routes.
l Run:
peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-
name export
The AS_Path attribute is added to the routes advertised to BGP peers or peer groups.
l Run:
name import
The AS_Path attribute is added to the routes received from BGP peers or peer groups.
l Run:
import-route protocol [ process-id ] route-policy route-policy-name
The AS_Path attribute is added to the routes imported by BGP in import mode.
l Run:
network { ipv4-address [ mask | mask-length ] | ipv6-address prefix-length }
route-policy route-policy-name
The AS_Path attribute is added to the routes imported by BGP in network mode.
Step 9 (Optional) Run one of the following commands to configure the AS_Path attribute as required.
l Run:
bestroute as-path-ignore
BGP is configured not to compare the AS_Path attributes of routes during route selection.
By default, BGP compares the AS_Path attributes of routes during route selection.
l Run:
peer { ipv4-address | group-name | ipv6-address } allow-as-loop [ number ]
Repeated local AS numbers are allowed in routes.

Routers
By default, repeated local AS number is not allowed.

l Run:
peer { ipv4-address | group-name | ipv6-address } public-as-only
BGP is configured to carry only public AS numbers in the AS_Path attribute in an EBGP
Update message.
By default, the AS_Path attribute can carry both public and private AS numbers in an EBGP
Update message.
l Return to the BGP view to configure the AS_Path attribute.
1. Run:
quit
Return to the BGP view.

2. (Optional) Run one of the following commands to configure the AS_Path attribute as
required.
Run:
as-path-limit as-path-limit-num
The maximum number of AS numbers in the AS_Path attribute is set.

By default, the maximum number of AS numbers in the AS_Path attribute is 255.
Run:
peer { ipv4-address | group-name | ipv6-address } fake-as { as-number-
plain | as-number-dot }
A fake AS number is configured for an EBGP peer group.

By default, EBGP peers establish a connection using a real AS number.
NOTICE
Running the undo check-first-as command increases the probability of routing
loops. Therefore, exercise caution when using this command.
Run:
undo check-first-as
BGP is configured not to check the first AS number in the AS_Path list that is carried
in the Update message sent by an EBGP peer.
By default, BGP checks the first AS number in the AS_Path list that is carried in the
Update message sent by an EBGP peer.
NOTE
When BGP is disabled from checking the first AS number, run the refresh bgp command in
the user view if you want BGP to check the first AS number of received routes.
----End
9.5.4.6 Configuring the MED Attribute
Context
The multi-exit discriminator (MED) helps determine the optimal route for incoming traffic of
an AS. It is similar to the metric used in IGP. When a BGP device obtains multiple routes to the

Routers
same destination address but with different next hops from EBGP peers, the BGP device selects
the route with the smallest MED value as the optimal route.
Procedure
Step 1 Run:
system-view
Step 2 Run:
on networks.
l Run:

l Run:
Step 4 Perform one of the following operations as required:

l Run:
default med med
The default MED value is set.

By default, the MED is 0.
l Run:
bestroute med-none-as-maximum
BGP defines the MED value as the maximum value is a route does not have the MED
attribute.
By default, BGP uses the default MED value when a route does not have the MED attribute.
l Run:
compare-different-as-med
BGP is allowed to compare the MED values of routes received from EBGP peers in any
AS.
By default, BGP compares only the MEDs of the routes received from EBGP peers within
the same AS.
l Run:
deterministic-med
The deterministic-MED function is enabled.

By default, the BGP deterministic-MED function is disabled.
l Run:
bestroute med-confederation
The MED values of routes in a confederation are compared.

Routers
By default, BGP compares only the MEDs of the routes from the same AS.
----End
9.5.4.7 Configuring the BGP Community Attribute
Context
The Community attribute is a private BGP route attribute. It is transmitted between BGP peers
and is not restricted within an AS. The Community attribute allows a group of BGP devices in
multiple ASs to share the same routing policies, which simplifies routing policy applications
and facilitates routing policy management and maintenance. A BGP device can add or change
the community attributes of routes to be advertised.
Procedure
Step 1 Run:
system-view

Step 2 Run:
route-policy route-policy-name { deny | permit } node node
A node is configured for a route-policy, and the view of the route-policy is displayed.
Step 3 (Optional) Configure matching rules for the route-policy to change only the community
attributes of the routes meet matching rules.
By default, all routes meet matching rules. For details, see 10.5.2.2 (Optional) Configuring an
if-match Clause.
Step 4 Run either of the following commands to configure the Community attribute.
l Run:
apply community { community-number | aa:nn | internet | no-advertise | no-
export | no-export-subconfed } &<1-32> [ additive ]
Common community attributes are configured for BGP routes.

NOTE
This command allows you to configure a maximum of 32 community attributes.
l Run:
apply extcommunity { rt { as-number:nn | ipv4-address:nn } } &<1-16>
[ additive ]
An extended community attribute (route-target) is configured.

Extended community attributes are extensions to community attributes in services. Currently,
only the route-target attribute is supported in VPN.
Step 5 Run:
quit

Step 6 Run:

Routers
on networks.
l Run:

l Run:
Step 8 Add the Community attribute to routes.

l Run:
name export
The Community attribute is added to the routes advertised to BGP peers or peer groups.
l Run:
name import
The Community attribute is added to the routes received from BGP peers or peer groups.
l Run:
import-route protocol [ process-id ] route-policy route-policy-name
The Community attribute is added to the routes imported by BGP in import mode.
l Run:
network { ipv4-address [ mask | mask-length ] | ipv6-address prefix-length }
route-policy route-policy-name
The Community attribute is added to the routes imported by BGP in network mode.
NOTE
Step 9 is required only when the Community attribute needs to be added to the routes advertised to BGP
peers or peer groups.
Step 9 (Optional) Allow BGP to advertise community attributes when BGP adds community attributes
to the routes advertised to BGP peers or peer groups.
l Run:
peer { ipv4-address | group-name | ipv6-address } advertise-community
BGP is allowed to advertise community attributes to BGP peers or peer groups.

By default, BGP does not advertise community attributes to any peer or peer group.
l Run:
peer { ipv4-address | group-name | ipv6-address } advertise-ext-community
BGP is allowed to advertise extended community attributes to BGP peers or peer groups.
By default, BGP does not advertise extended community attributes to any peer or peer group.
----End
9.5.4.8 Configuring BGP Load Balancing

Routers
Context
On large networks, there may be multiple valid routes to the same destination. BGP, however,
advertises only the optimal route to its peers. This may result in unbalanced traffic on different
routes. Configuring BGP load balancing better utilizes network resources and reduces network
congestion.
Equal-cost BGP routes can be generated for traffic load balancing only when the first eight route
attributes described in "BGP Route Selection Policies" are the same, and the AS_Path attributes
are also the same. You can change load balancing rules by performing some configurations, for
example, ignoring the comparison of the AS_Path attribute. When performing these
configurations, ensure that these configurations do not result in routing loops.
NOTE
If BGP load balancing is configured, the local device changes the next-hop address of routes to its address
when advertising routes to IBGP peer groups, regardless of whether the peer next-hop-local command is
used.
Procedure
Step 1 Run:
system-view
Step 2 Run:
on networks.
l Run:

l Run:
Step 4 Run:
maximum load-balancing [ ebgp | ibgp ] number
The maximum number of BGP routes to be used for load balancing is set.
By default, the maximum number of BGP routes to be used for load balancing is 1, indicating
that load balancing is not performed.

Routers
NOTE
l On a public network, if the routes to the same destination implement load balancing, the system will
determine the type of the optimal route. If the optimal routes are IBGP routes, only IBGP routes carry
out load balancing. If the optimal routes are EBGP routes, only EBGP routes carry out load balancing.
This means that load balancing cannot be implemented among IBGP and EBGP routes with the same
destination address.
l On an IPv4 multicast network, BGP compares the AS_Path attributes of the routes to be used for load
balancing. In this case, step 5 is not supported.
NOTICE
Configuring BGP not to compare the AS_Path attributes of the routes to be used for load
balancing may cause routing loops.

load-balancing as-path-ignore
BGP is configured not to compare the AS_Path attributes of the routes to be used for load
balancing.
By default, BGP compares the AS_Path attributes of the routes to be used for load balancing.
----End
Procedure
l Run the display bgp paths [ as-regular-expression ] command to check information about
BGP AS_Path.
l Run the display bgp routing-table different-origin-as command to check the routes with
the same destination address but different origin ASs.
l Run the display bgp routing-table regular-expression as-regular-expression command
to check information about routes that match the AS regular expression.
l Run the display bgp routing-table community [ community-number | aa:nn ] &<1-29>
[ internet | no-advertise | no-export | no-export-subconfed ] * [ whole-match ] command
to check routing information with the specified BGP community.
l Run the display bgp routing-table community-filter { { community-filter-name | basic-
community-filter-number } [ whole-match ] | advanced-community-filter-number }
command to check information about routes matching a specified BGP community filter.
l Run the display bgp multicast routing-table statistics command to check statistics about
the MBGP routing table.
----End

Routers
9.5.5 Controlling the Receiving and Advertisement of BGP Routes

Controlling the receiving and advertisement of BGP routes can reduce the routing table size and
improve network security.
Before controlling the receiving and advertisement of BGP routes, complete the following task:
Figure 9-17 Flowchart of controlling the receiving and advertisement of BGP routes
Configuring a Routing
Policy
Controlling the
Controlling the Receiving
Advertisement of BGP
of BGP Routes
Routes
Configuring BGP Soft

Reset
Required steps
9.5.5.1 Configuring a Routing Policy
Context
Before controlling the receiving and advertisement of BGP routes, configure routing policies or
filters of routing policies for route selection. For details, see "Routing Policy Configuration" in
the Huawei AR150&200&1200&2200&3200 Series Enterprise Routers Configuration Guide
- IP Routing.
9.5.5.2 Controlling the Advertisement of BGP Routes
Context
There are usually a large number of routes in a BGP routing table. Transmitting a great deal of
routing information brings a heavy load to devices. Routes to be advertised need to be controlled
to address this problem. You can configure devices to advertise only routes that these devices
want to advertise or routes that their peers require. Multiple routes to the same destination may
exist and traverse different ASs. Routes to be advertised need to be filtered in order to direct
routes to specific ASs.

Routers
Procedure
l Configure a BGP device to advertise routes to all peers or peer groups.
You can configure a BGP device to filter routes to be advertised.
1. Run:
system-view

2. Run:

Run:

Run:

4. Perform either of the following operations to configure the BGP device to advertise
routes to all peers or peer groups:
To filter routes based on an ACL, run the filter-policy { acl-number | acl-name
acl-name } export [ protocol [ process-id ] ] or the filter-policy { acl6-number |
acl6-name acl6-name } export [ protocol [ process-id ] ] command.
To filter routes based on an IP prefix list, run the filter-policy ip-prefix ip-prefix-
name export [ protocol [ process-id ] ] or the filter-policy ipv6-prefix ipv6-prefix-
name export [ protocol [ process-id ] ] command.
NOTE
If an ACL has been referenced in the filter-policy command but no VPN instance is specified
in the ACL rule, BGP will filter routes including public and private network routes in all address
families. If a VPN instance is specified in the ACL rule, only the data traffic from the VPN
instance will be filtered, and no route of this VPN instance will be filtered.
l Configure a BGP device to advertise routes to a specific peer or peer group.
1. Run:
system-view

2. Run:

Run:

Routers
Run:

4. Perform any of the following operations to configure the BGP device to advertise
routes to a specific peer or peer group:
To filter routes based on an ACL, run the peer { group-name | ipv4-address | ipv6-
address } filter-policy { acl-number | acl-name acl-name | acl6-number | acl6-
name acl6-name } export command.
To filter routes based on an IP prefix list, run the peer { ipv4-address | group-
name } ip-prefix ip-prefix-name export or the peer { group-name | ipv6-
address } ipv6-prefix ipv6-prefix-name export command.
To filter routes based on an AS_Path filter, run the peer { ipv4-address | group-
name | ipv6-address } as-path-filter { as-path-filter-number | as-path-filter-
name } export command.
To filter routes based on a route-policy, run the peer { ipv4-address | group-
name | ipv6-address } route-policy route-policy-name export command.
NOTE
The routing policy applied in the peer route-policy export command does not support a
specific interface as one matching rule. That is, the routing policy does not support the if-match
interface command.
----End
9.5.5.3 Controlling the Receiving of BGP Routes
Context
When a BGP device is attacked or network configuration errors occur, the BGP device will
receive a large number of routes from its neighbor. As a result, many device resources are
consumed. Therefore, the administrator must limit the resources used by the device based on
network planning and device capacity. BGP provides peer-based route control to limit the
number of routes to be sent by a neighbor. This addresses the preceding problem.
Procedure
l Configure a BGP device to receive routes from all its peers or peer groups.
1. Run:
system-view

2. Run:

Run:

Routers

Run:

4. Perform either of the following operations to configure the BGP device to filter the
routes received from all its peers or peer groups:
To filter routes based on an ACL, run the filter-policy { acl-number | acl-name
acl-name } import or the filter-policy { acl6-number | acl6-name acl6-name }
import command.
To filter routes based on an IP prefix list, run the filter-policy ip-prefix ip-prefix-
name import or the filter-policy ipv6-prefix ipv6-prefix-name import command.
NOTE
If an ACL has been referenced in the filter-policy command but no VPN instance is specified
in the ACL rule, BGP will filter routes including public and private network routes in all address
families. If a VPN instance is specified in the ACL rule, only the data traffic from the VPN
instance will be filtered, and no route of this VPN instance will be filtered.
l Configure a BGP device to receive routes from a specific peer or peer group.
1. Run:
system-view

2. Run:

Run:

Run:

4. Perform any of the following operations to configure the BGP device to filter the
routes received from a specific peer or peer group:
To filter routes based on an ACL, run the peer { group-name | ipv4-address | ipv6-
address } filter-policy { acl-number | acl-name acl-name | acl6-number | acl6-
name acl6-name } import command.
To filter routes based on an IP prefix list, run the peer { ipv4-address | group-
name } ip-prefix ip-prefix-name import or the peer { group-name | ipv6-
address } ipv6-prefix ipv6-prefix-name import command.
To filter routes based on an AS_Path filter, run the peer { ipv4-address | group-
name | ipv6-address } as-path-filter { as-path-filter-number | as-path-filter-
name } import command.
To filter routes based on a route-policy, run the peer { ipv4-address | group-
name | ipv6-address } route-policy route-policy-name import command.

Routers
NOTE
The routing policy applied in the peer route-policy import command does not support a
specific interface as one matching rule. That is, the routing policy does not support the if-match
interface command.
NOTICE
If the number of routes received by the local device exceeds the upper limit and the
peer route-limit command is used for the first time, the local device and its peer
reestablish the peer relationship, regardless of whether alert-only is set.
5. (Optional) Run:
peer { group-name | ipv4-address } route-limit limit [ percentage ]
[ alert-only | idle-forever | idle-timeout times ]
The maximum number of routes that can be received from the peer or peer group is
set.
----End
9.5.5.4 Configuring BGP Soft Reset
Context
After changing a BGP import policy, you must reset BGP connections for the new import policy
to take effect. This, however, interrupts these BGP connections temporarily. BGP route-refresh
allows the system to softly reset BGP connections to refresh a BGP routing table without tearing
down any BGP connection. If a device's peer does not support route-refresh, configure the device
to remain all routing updates received from the peer so that the device can refresh its routing
table without tearing down the BGP connection with the peer.
Procedure
l If a device's peer supports route-refresh, configure the device to softly reset the BGP
connection with the peer and update the BGP routing table.
1. Run:
system-view

2. Run:

3. (Optional) Run:
peer { ipv4-address | group-name } capability-advertise route-refresh
or run:
peer ipv6-address capability-advertise { 4-byte-as | route-refresh }
Route-refresh is enabled.
By default, route-refresh is enabled.
4. Run:

Routers
quit

5. Run:
quit
Return to the user view.

6. Run:
refresh bgp [ vpn-instance vpn-instance-name ipv4-family | vpnv4 ] { all
| ipv4-address | group group-name | external | internal } { export |
import }
or run :
refresh bgp ipv6 { all | group group-name | ipv6-address | external |
internal } { export | import }
BGP soft reset is configured.

l If a device's peer does not support route-refresh, configure the device to remain all routing
updates received from the peer so that the device can refresh its routing table without tearing
down the BGP connection with the peer.
1. Run:
system-view

2. Run:

Run:

Run:
NOTICE
If the peer keep-all-routes command is used on the device for the first time, the
sessions between the device and its peers are reestablished.
The refresh bgp command takes effect when the peer keep-all-routes command is
used on the device supporting route-refresh.
4. Run:
peer { ipv4-address | group-name | ipv6-address } keep-all-routes
The device is configured to store all the routing updates received from its peers or
peer groups.
By default, the device stores only the routing updates that are received from peers or
peer groups and match a configured import policy.
----End

Routers
Procedure
l Run the display ip as-path-filter [ as-path-filter-number | as-path-filter-name ] command
to check information about a configured AS_Path filter.
l Run the display ip community-filter [ basic-comm-filter-num | adv-comm-filter-num |
comm-filter-name ] command to check information about a configured community filter.
l Run the display ip extcommunity-filter [ extcomm-filter-number | extcomm-filter-name ]
command to check information about a configured extcommunity filter.
l Run the display bgp routing-table as-path-filter as-path-filter { as-path-filter-number |
as-path-filter-name } command to check information about routes matching a specified
AS_Path filter.
l Run the display bgp routing-table community-filter { { community-filter-name | basic-
community-filter-number } [ whole-match ] | advanced-community-filter-number }
command to check information about routes matching a specified BGP community filter.
l Run the display bgp routing-table peer ipv4-address received-routes [ active ]
[ statistics ] command to check information about routes received by a BGP device from
its peers.
l Run the display bgp multicast routing-table different-origin-as command to check
information about MBGP routes with different origin ASs.
l Run the display bgp multicast routing-table regular-expression as-regular-expression
to check information about MBGP routes matching the AS regular expression.
l Run the display bgp multicast paths [ as-regular-expression ] command to check
information about AS paths.
l Run the display bgp multicast routing-table as-path-filter { as-path-filter-number | as-
path-filter-name } command to check information about MBGP routes matching the
AS_Path filter.
l Run the display bgp multicast routing-table community-filter { { community-filter-
name | basic-community-filter-number } [ whole-match ] | advanced-community-filter-
number } command to check information about routes matching a specified MBGP
community filter.
l Run the display bgp multicast routing-table peer peer-address { advertised-routes
[ network [ { mask | mask-length } [ longer-prefixes ] ] ] | received-routes [ active ] |
accepted-routes } command to check information about routes that are sent by and received
from the specified MBGP peer.
l Run the display bgp multicast network command to check the routing information that
MBGP advertises.
----End
9.5.6 Adjusting the BGP Network Convergence Speed

You can configure BGP timers, disable rapid EBGP connection reset, and configure BGP route
dampening to speed up BGP network convergence and improve BGP security.

Routers
Before configuring adjusting the BGP network convergence speed, complete the following task:
tasks (excluding the task of checking the configuration) can be performed at any sequence.
9.5.6.1 Configuring a BGP ConnectRetry Timer
Context
After BGP initiates a TCP connection, the ConnectRetry timer will be stopped if the TCP
connection is established successfully. If the first attempt to establish a TCP connection fails,
BGP tries again to establish the TCP connection after the ConnectRetry timer expires.
l Setting a short ConnectRetry interval reduces the period BGP waits between attempts to
establish a TCP connection. This speeds up the establishment of the TCP connection.
l Setting a long connectRetry interval suppresses routing flapping caused by peer relationship
flapping.
A ConnectRetry timer can be configured either for all peers or peer groups, or for a specific peer
or peer group. A ConnectRetry timer configured for a specific peer takes precedence over that
configured for the peer group of this peer. In addition, a ConnectRetry timer configured for a
specific peer or peer group takes precedence over that configured for all peers or peer groups.
Procedure
l Configure a BGP ConnectRetry timer for all peers or peer groups.
1. Run:
system-view

2. Run:

3. Run:
timer connect-retry connect-retry-time
A BGP ConnectRetry timer is configured for all peers or peer groups.

By default, the ConnectRetry timer value is 32s.
l Configure a ConnectRetry timer for a specific peer or peer group.
1. Run:
system-view

2. Run:

Routers

3. Run:
peer { group-name | ipv4-address | ipv6-address } timer connect-retry
connect-retry-time
A ConnectRetry timer is configured for a specific peer or peer group.
By default, the ConnectRetry timer value is 32s.
----End
9.5.6.2 Configuring BGP Keepalive and Hold Timers
Context
Keepalive messages are used by BGP to maintain peer relationships.
l If short Keepalive time and holdtime are set, BGP can detect a link fault quickly. This
speeds up BGP network convergence, but increases the number of Keepalive messages on
the network and loads of devices, and consumes more network bandwidth resources.
l If long Keepalive time and holdtime are set, the number of Keepalive messages on the
network is reduced, loads of devices are reduced, and fewer network bandwidth are
consumed. If the Keepalive time is too long, BGP is unable to detect link status changes in
a timely manner. This is unhelpful for implementing rapid BGP network convergence and
may cause many packets to be lost.
Keepalive and hold timers can be configured either for all peers or peer groups, or for a specific
peer or peer group. Keepalive and hold timers configured for a specific peer take precedence
over those configured for the peer group of this peer. In addition, Keepalive and hold timers
configured for a specific peer or peer group take precedence over those configured for all peers
or peer groups.
NOTICE
Changing timer values using the timer command or the peer timer command interrupts BGP
peer relationships between routers.
Setting the Keepalive time to 20s is recommended. If the Keepalive time is smaller than 20s,
sessions between peers may be closed.
Procedure
l Configure BGP timers for all peers or peer groups.
1. Run:
system-view

2. Run:

Routers

3. Run:
timer keepalive keepalive-time hold hold-time
BGP timers are configured.

The proper maximum interval at which Keepalive messages are sent is one third the
holdtime. By default, the Keepalive time is 60s and the holdtime is 180s.
l Configure BGP timers for a specific peer or peer group.
1. Run:
system-view

2. Run:

3. Run:
peer { ipv4-address | group-name | ipv6-address } timer keepalive
keepalive-time hold hold-time
The Keepalive and hold timers are configured for a specific peer or peer group.
The proper maximum interval at which Keepalive messages are sent is one third the
holdtime. By default, the Keepalive time is 60s and the holdtime is 180s.
----End
9.5.6.3 Configuring a Update Message Timer
Context
BGP does not periodically update a routing table. When BGP routes change, BGP updates the
changed BGP routes in the BGP routing table by sending Update messages.
l If a short Update message interval is set, BGP can fast detect route changes. This speeds
up BGP network convergence, but increases the number of Update messages on the network
and loads of devices, and consumes more network bandwidth resources.
l If a long Update message interval is set, the number of Update messages on the network is
reduced, loads of devices are reduced, and fewer network bandwidth are consumed. This
avoids network flapping. If the Update message interval is too long, BGP is unable to detect
route changes in a timely manner. This is unhelpful for implementing rapid BGP network
convergence and may cause many packets to be lost.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Routers
on networks.
l Run:

l Run:
Step 4 Run:
peer { ipv4-address | group-name | ipv6-address } route-update-interval interval
An Update message timer is configured.
By default, the interval at which Update messages are sent to IBGP peers is 15s, and the interval
at which Update messages are sent to EBGP peers is 30s.
----End
9.5.6.4 Disabling Rapid EBGP Connection Reset
Context
Rapid EBGP connection reset is enabled by default. This allows BGP to immediately respond
to a fault on an interface and delete the direct EBGP sessions on the interface without waiting
for the hold timer to expire and implements rapid BGP network convergence.
If the status of an interface used to establish an EBGP connection changes frequently, the EBGP
session will be deleted and reestablished repeatedly, causing network flapping. Rapid EBGP
connection reset can be disabled in such a situation. BGP will delete direct EBGP sessions on
the interface until the hold timer expires. This suppresses BGP network flapping, helps
implement rapid BGP network convergence, and reduces network bandwidth consumption.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
undo ebgp-interface-sensitive
Rapid EBGP connection reset is disabled.
By default, rapid EBGP connection reset is enabled.

Routers
NOTE
Rapid EBGP connection reset enables BGP to quickly respond to interface faults but does not enable BGP
to quickly respond to interface recovery. After the interface recovers, BGP uses its state machine to restore
relevant sessions.
Rapid EBGP connection reset is disabled in a situation where the status of an interface used to establish
an EBGP connection changes frequently. If the status of the interface becomes stable, run the ebgp-
interface-sensitive command to enable rapid EBGP connection reset to implement rapid BGP network
convergence.
----End
9.5.6.5 Configuring the BGP Next Hop Delayed Response
Context
Configuring the BGP next hop delayed response can speed up BGP route convergence and
minimize traffic loss.
As shown in Figure 9-18, PE1, PE2, and PE3 are the clients of the RR. CE2 is dual-homed to
PE1 and PE2. PE1 and PE2 advertise their routes to CE2 to the RR. The RR advertises the route
from PE1 to PE3. PE3 has a route to CE2 only and advertises this route to CE1. After the route
exchange, CE1 and CE2 can communicate. If PE1 fails, PE3 detects that the next hop is
unreachable and instructs CE1 to delete the route to CE2. Traffic is interrupted. After BGP route
convergence is complete, the RR selects the route advertised by PE2 and sends a route update
message to PE3. PE3 then advertises this route to CE1, and traffic forwarding is restored to the
normal state. A high volume of traffic will be lost during traffic interruption because BGP route
convergence is rather slow.
If the BGP next hop delayed response is enabled on PE3, PE3 does not reselect a route or instruct
CE1 to delete the route to CE2 immediately after detecting that the route to PE1 is unreachable.
After BGP convergence is complete, the RR selects the route advertised by PE2 and sends the
route to PE3. PE3 then reselects a route and sends a route update message to CE1. Traffic
forwarding is restored to the normal state. After the BGP next hop delayed response is enabled
on PE3, PE3 does not need to delete the route or instruct CE1 to delete the route. This delayed
response speeds up BGP route convergence and minimizes traffic loss.
Figure 9-18 Networking diagram for configuring the BGP next hop delayed response
CE1 PE3 P PE1
CE2
RR PE2

Routers
The BGP next hop delayed response applies to a scenario where the next hop has multiple links
to reach the same destination. If there is only one link between the next hop and the destination,
configuring the BGP next hop delayed response may cause heavier traffic loss when the link
fails because link switching is impossible.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
nexthop recursive-lookup delay [ delay-time ]
A delay in responding to a next hop change is set.
By default, the delay in responding to changes of the next hop is not configured.
NOTE
BGP route convergence depends on IGP route convergence. If IGP route convergence is quick, the default
delay time does not need to be changed. If IGP route convergence is slow, setting a delay time longer than
IGP route convergence time is recommended.
----End
9.5.6.6 Configuring BGP Route Dampening
Context
A route is considered to be flapping when it repeatedly appears and then disappears in the routing
table. BGP generally applies to complex networks where routes change frequently. Frequent
route flapping consumes lots of bandwidths and CPU resources and even affects normal network
operation. BGP route dampening prevents frequent route flapping.
BGP can differentiate routes based on policies and use different route dampening parameters to
suppress different routes. For example, on a network, you can set a long suppression time for
routes with a long mask and set a short suppression time for routes with a short mask (such as
8-bit mask).
Procedure
Step 1 Run:
system-view
Step 2 Run:

Routers

on networks.
l Run:

l Run:

Step 4 Run:
dampening [ half-life-reach reuse suppress ceiling | route-policy route-policy-
name ] *
BGP route dampening parameters are configured.
----End
Procedure
l Run the display bgp peer [ verbose ] command to check information about all BGP peers.
l Run the display bgp routing-table dampened command to check dampened BGP routes.
l Run the display bgp routing-table dampening parameter command to check configured
BGP route dampening parameters.
l Run the display bgp routing-table flap-info [ regular-expression as-regular-
expression | as-path-filter as-path-filter-number | network-address [ { mask | mask-
length } [ longer-match ] ] ] command to check route flapping statistics.
l Run the display bgp multicast routing-table dampened command to check dampened
MBGP routes.
l Run the display bgp multicast routing-table dampening parameter command to check
MBGP route dampening parameters.
l Run the following commands to check statistics about flapping MBGP routes.
display bgp multicast routing-table flap-info [ ip-address [ mask [ longer-match ] |
mask-length [ longer-match ] ] | as-path-filter as-path-filter-number | regular-
expression as-regular-expression ]
display bgp multicast routing-table flap-info as-regular-expression
----End
9.5.7 Configuring BGP Reliability

You can configure BGP Tracking, association between BGP and BFD, and BGP GR to speed
up BGP network convergence and improve BGP reliability.

Routers
Before configuring BGP reliability, complete the following task:
tasks can be performed at any sequence.
9.5.7.1 Enabling BGP Tracking
Context
BGP can be configured to detect peer relationship status changes in order to implement rapid
BGP convergence. BFD, however, needs to be configured on the entire network, and has poor
extensibility. If BFD cannot be deployed on a device to detect BGP peer relationship status,
BGP peer tracking can be enabled on the device to quickly detect link or peer unreachability,
implementing rapid network convergence.
BGP tracking can be used to adjust the interval between peer unreachability discovery and
connection interruption. This suppresses BGP peer relationship flapping caused by route
flapping and improves BGP network stability.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { group-name | ipv4-address | ipv6-address } tracking [ delay delay-time ]
BGP peer tracking is enabled on the device to detect the status of a specified peer.
By default, BGP peer tracking is disabled.
----End
9.5.7.2 Configuring BFD for BGP
Context
BGP periodically sends Keepalive messages to its peers to detect the status of its peers. It takes
more than 1 second for this detection mechanism to detect a fault. When data is transmitted at
gigabit rates, long-time fault detection will cause packet loss. This cannot meet high reliability
requirements of carrier-class networks. Association between BGP and BFD can solve this

Routers
problem. BFD is a millisecond-level fault detection mechanism. It can detect faults on the link
between BGP peers within 50 ms. Therefore, BFD can speed up BGP route convergence, ensures
fast link switching, and reduces traffic loss.
When a peer joins a peer group on which BFD is enabled, BFD also takes effect on the peer and
a BFD session is created on the peer. To prevent BFD from taking effect on the peer, run the
peer bfd block command.
By default, Huawei devices establish multi-hop IBGP sessions with each other. When a Huawei
device communicates with a non-Huawei device that establishes a single-hop IBGP session by
default, you are advised to configure only association between IGP and BFD or association
between IBGP and BFD.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Global BFD is enabled on the local device.
Step 3 Run:
quit
Step 4 Run:
Step 5 Run:
peer { group-name | ipv4-address } bfd enable
BFD is configured for the peer or peer group, and default BFD parameters are used to establish
BFD sessions.
If BFD is configured for a peer group, BFD sessions are created for the peers on which the peer
bfd block command is not used.
Step 6 Run:
peer { group-name | ipv4-address } bfd { min-tx-interval min-tx-interval | min-rx-
interval min-rx-interval | detect-multiplier multiplier | wtr wtr-value } *
BFD session parameters are configured.

peer ipv4-address bfd block
The peer is disabled from inheriting the BFD function of the peer group to which the peer belongs.

Routers
NOTE
l BFD sessions are established when they are in Established state.

l If BFD parameters are configured on a peer, BFD sessions are established using these parameters.
l The peer ipv4-address bfd block and peer ipv4-address bfd enable commands are mutually exclusive.
----End

l Run the display bgp bfd session { [ vpnv4 vpn-instance vpn-instance-name ] peer ipv4-
address | all } command to check information about the BFD sessions established between
BGP peers.
l Run the display bgp [ vpnv4 vpn-instance vpn-instance-name ] peer [ [ ipv4-address ]
verbose ] command to check information about BGP peers.
l Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } group [ group-
name ] command to check information about the BGP VPNv4 peer group.
9.5.7.3 Configuring the BGP GR Function
Context
BGP restart causes peer relationships reestablishment and traffic interruption. Graceful restart
(GR) ensures uninterrupted traffic interruption in the case of BGP restart.
NOTE
Currently, devices support only the GR helper function.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
graceful-restart
BGP GR is enabled.
By default, BGP GR is disabled.
graceful-restart timer wait-for-rib timer
The time during which the restarting speaker and receiving speaker wait for End-of-RIB
messages is set.

Routers
By default, the time for waiting for End-of-RIB messages is 600 seconds.
----End

l Run the display bgp peer verbose command to check detailed information about BGP
peers.
9.5.8 Configuring BGP Route Summarization

On IPv4 networks, BGP supports automatic route summarization and manual route
summarization. Manual route summarization takes precedence over automatic route
summarization. On IPv6 networks, BGP supports only manual route summarization.
Before configuring BGP route summarization, complete the following task:
Procedure
l Configure automatic route summarization.
1. Run:
system-view

2. Run:

Run:

4. Run:
summary automatic
BGP summarizes subnet routes based on natural mask.
NOTE
The command summarizes the routes imported by BGP. These routes can be direct routes, static
routes, RIP routes, OSPF routes, or IS-IS routes. The command, however, is invalid for the routes
imported using the network command.
l Configure manual route summarization.
1. Run:
system-view

Routers
2. Run:

Run:

Run:

4. Perform any of the following operations to configure manual route summarization.
To advertise the summarized routes and specific routes, run the aggregate ipv4-
address { mask | mask-length } or the aggregate ipv6-address prefix-length
command.
To advertise only the summarized routes, run the aggregate ipv4-address
{ mask | mask-length } detail-suppressed or the aggregate ipv6-address prefix-
length detail-suppressed command.
To advertise the summarized routes and specific routes that meet the specified
route-policy, run the aggregate ipv4-address { mask | mask-length } suppress-
policy route-policy-name or the aggregate ipv6-address prefix-length suppress-
policy route-policy-name command.
To advertise the summarized routes of which the AS_Set attribute helps detect
routing loops, run the aggregate ipv4-address { mask | mask-length } as-set or the
aggregate ipv6-address prefix-length as-set command.
To set attributes for the summarized routes, run the aggregate ipv4-address
{ mask | mask-length } attribute-policy route-policy-name or the aggregate ipv6-
address prefix-length attribute-policy route-policy-name command.
To summarize the specific routes that meet the specified route-policy, run the
aggregate ipv4-address { mask | mask-length } origin-policy route-policy-name
or the aggregate ipv6-address prefix-length origin-policy route-policy-name
command.
NOTE
Manual route summarization is valid for the routes in the local BGP routing table. For example, if
the local BGP routing table does not contain routes with mask longer than 16 bits, such as 10.1.1.1/24,
BGP will not generate an aggregated route for it even if the aggregate 10.1.1.1 16 command is used.
----End

prefixes ] ] ] command to check information about summarized routes.

Routers
9.5.9 Configuring On-demand Route Advertisement

If a BGP device only wants to received required routes but its peer cannot maintain different
export policies for connected devices, you can configure prefix-based BGP outbound route
filtering (ORF) to meet this requirement.
Before configuring prefix-based BGP ORF, complete the following tasks:

l Configuring an IP Prefix List
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 { group-name | ipv4-address } ip-prefix ip-prefix-name import
A prefix-based import policy is configured for a peer or peer group.

Step 5 Run:
peer { group-name | ipv4-address } capability-advertise orf [ cisco-compatible ] ip-
prefix { both | receive | send }
Prefix-based ORF is enabled for a peer or peer group.

By default, prefix-based ORF is disabled for a peer or peer group.
----End

l Run the display bgp peer [ ipv4-address ] verbose command to check detailed information
about BGP peers.
l Run the display bgp peer ipv4-address orf ip-prefix command to check prefix-based BGP
ORF information received from a specified peer.
9.5.10 Configuring BGP to Advertise Default Routes to Peers

If a BGP device needs to send multiple routes to its peer, the BGP device can be configured to
send only a default route with the local address as the next-hop address to its peer, regardless of

Routers
whether there are default routes in the local routing table. This function reduces the number of
network routes and saves memory and network resources.
Before configuring BGP to send default routes to peers, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
on networks.
l Run:

l Run:
Step 4 Run:
peer { group-name | ipv4-address | ipv6-address } default-route-advertise [ route-
policy route-policy-name ] [ conditional-route-match-all { ipv4-address1 { mask1 |
mask-length1 } } &<1-4> | conditional-route-match-any { ipv4-address2 { mask2 |
mask-length2 } } &<1-4> ]
A BGP device is configured to send default routes to a peer or peer group.
NOTE
The conditional-route-match-all and conditional-route-match-any keywords are not supported in the IPv4
multicast address family view and the IPv6 address family view.
----End

l Run the display bgp routing-table [ ipv4-address [ mask | mask-length [ longer-
prefixes ] ] ] command to check received BGP default routes.
prefixes ] | mask [ longer-prefixes ] ] ] command to check received MBGP default routes.

Routers
9.5.11 Configuring Path MTU Auto Discovery

BGP path maximum transmission unit (MTU) auto discovery can discover the minimum MTU
(path MTU) on the network path from the source to the destination so that TCP can transmit
BGP messages based on the path MTU.
Before configuring path MTU auto discovery, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { group-name | ipv4-address } path-mtu auto-discovery
Path MTU auto discovery is enabled.
By default, path MTU auto discovery is disabled.
NOTE
The transmit and receive paths between two BGP peers may be different. Therefore, you are advised to
run this command on both ends so that the two BGP peers can exchange messages based on the path MTU.
----End

l Run the display bgp peer [ ipv4-address ] verbose command to check whether path MTU
auto discovery has been successfully configured.
9.5.12 Configuring MP-BGP

Multiprotocol BGP (MP-BGP) enables BGP to support IPv4 unicast networks, IPv4 multicast
networks, and IPv6 unicast networks.
Before configuring MP-BGP, complete the following task:
l 9.5.1.1 Starting a BGP Process

Routers
Procedure
Step 1 Run:
system-view
Step 2 Run:
BGP is started, the local AS number is specified, and the BGP view is displayed.
on networks.
l Run:
ipv4-family unicast

l Run:
ipv4-family vpnv4
The BGP-VPNv4 address family view is displayed.

l Run:
ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed.

l Run:

l Run:
ipv6-family unicast

NOTE
l Different extended BGP functions must be configured in their respective address family views, while
common BGP functions are configured in the BGP view.
l The Router supports the following MBGP features: basic BGP functions, BGP security (MD5
authentication and keychain authentication), simplifying IBGP network connections (route reflector
and confederation), BGP route selection and load balancing, controlling the receiving and
advertisement of BGP routes, adjusting the BGP network convergence speed, BGP reliability, BGP
route summarization, path MTU auto discovery, and advertising default routs to peers.
l Some BGP4+ functions can be configured in the BGP view, and some BGP4+ functions need to be
configured in the IPv6 unicast address family view. For example, the following BGP4+ functions need
to be configured in the IPv6 unicast address family view: load balancing, manual route summarization,
route dampening, community, and route reflector.
----End
9.6 Maintaining BGP

Maintaining BGP includes resetting BGP connections and clearing BGP statistics.
9.6.1 Resetting BGP Connections

Routers
Context
NOTICE
Running the reset bgp command to reset BGP connections will interrupt BGP peer relationships
between BGP devices. Exercise caution when you use this command.
When the BGP routing policy changes, for example, the router does not support the route-refresh
capability, reset BGP connections to make the modification take effect.
Procedure
l To reset all BGP connections, run the reset bgp all command in the user view.
l To reset the BGP connection with a specified AS, run the reset bgp { as-number-plain |
as-number-dot } command in the user view.
l To reset the BGP connection with a specified peer, run the reset bgp ipv4-address
command in the user view.
l To reset all EBGP connections, run the reset bgp external command in the user view.
l To reset the BGP connection with a specified peer group, run the reset bgp group group-
name command in the user view.
l To reset all IBGP connections, run the reset bgp internal command in the user view.
l To reset the MBGP connection with a specified peer, run the reset bgp multicast peer-
address command in the user view.
l To reset all MBGP connections, run the reset bgp multicast all command in the user view.
l To reset the MBGP connection with all the peers in a specified peer group, run the reset
bgp multicast group group-name command in the user view.
l To reset all external connections, run the reset bgp multicast external command in the
user view.
l To reset all internal connections, run the reset bgp multicast internal command in the
user view.
----End
9.6.2 Clearing BGP Statistics
Context
NOTICE
BGP statistics cannot be restored after being cleared. Exercise caution when you reset BGP
statistics.

Routers
Procedure
l To clear route flapping statistics, run the reset bgp flap-info [ regexp as-path-regexp | as-
path-filter as-path-filter-number | ipv4-address [ mask | mask-length ] ] command in the
user view.
l To clear route flapping statistics on a specified peer, run the reset bgp ipv4-address flap-
info command in the user view.
l To clear route dampening statistics and release suppressed routes, run the reset bgp
dampening [ ipv4-address [ mask | mask-length ] ] command in the user view.
l To clear MBGP route dampening statistics, run the reset bgp multicast dampening [ ip-
address [ mask | mask-length ] ] command in the user view.
l To clear MBGP route flapping statistics, run the reset bgp multicast flap-info [ ip-
address [ mask | mask-length ] | as-path-filter { as-path-list-number | as-path-list-
name } | regrexp regrexp ] command in the user view.
----End

The section provides BGP configuration examples, including networking requirements,
networking diagram, configuration roadmap, and configuration procedure.
9.7.1 Example for Configuring Basic BGP Functions

As shown in Figure 9-19, BGP runs between Routers; an EBGP connection is established
between Router A and Router B; IBGP full-mesh connections are established between Router
B, Router C, and Router D.
Figure 9-19 Networking diagram of configuring basic BGP functions

RouterC
AS 65008 AS 65009
GE3/0/0 GE2/0/0
9.1.3.2/24 9.1.2.1/24
RouterA
GE2/0/0
200.1.1.2/24
GE3/0/0 GE2/0/0
GE1/0/0 9.1.3.1/24 9.1.2.2/24
GE1/0/0
8.1.1.1/8 9.1.1.1/24
GE2/0/0
GE1/0/0
200.1.1.1/24
RouterB 9.1.1.2/24 RouterD

Routers
1. Configure IBGP connections between Router B, Router C, and Router D.

2. Configure an EBGP connection between Router A and Router B.
Procedure
<RouterA> system-view
The configurations of Router B, Router C, and Router D are similar to the configuration of
Step 2 Configure IBGP connections.
[RouterB] bgp 65009
[RouterC] bgp 65009
[RouterC-bgp] quit
[RouterD] bgp 65009
[RouterD-bgp] router-id 4.4.4.4
[RouterD-bgp] peer 9.1.1.1 as-number 65009
[RouterD-bgp] quit
Step 3 Configure an EBGP connection.
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 200.1.1.1 as-number 65009
# View the status of BGP peers.

[RouterB-bgp] display bgp peer
BGP local router ID : 2.2.2.2
Local AS number : 65009
Total number of peers : 3 Peers in established state : 3
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
9.1.1.2 4 65009 49 62 0 00:44:58 Established 0
9.1.3.2 4 65009 56 56 0 00:40:54 Established 0
200.1.1.2 4 65008 49 65 0 00:44:03 Established 1

Routers
The preceding command output shows that BGP connections have been established between
Router B and other Routers.
Step 4 Configure Router A to advertise route 8.0.0.0/8.
# Configure Router A to advertise a route.

[RouterA-bgp] ipv4-family unicast
[RouterA-bgp-af-ipv4] network 8.0.0.0 255.0.0.0
[RouterA-bgp-af-ipv4] quit
# View the routing table of Router A.

[RouterA-bgp] display bgp routing-table
BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 1

Network NextHop MED LocPrf PrefVal Path/Ogn
*> 8.0.0.0 0.0.0.0 0 0 i
# View the routing table of Router B.

[RouterB-bgp] display bgp routing-table


*> 8.0.0.0 200.1.1.2 0 0 65008i

[RouterC] display bgp routing-table


i 8.0.0.0 200.1.1.2 0 100 0 65008i
NOTE
The preceding command output shows that Router C has learned the route to destination 8.0.0.0 in AS
65008. The route, however, is invalid because the next hop 200.1.1.2 of this route is unreachable.
Step 5 Configure BGP to import direct routes.
[RouterB-bgp-af-ipv4] import-route direct

Routers
# View the BGP routing table of Router A.

[RouterA-bgp] display bgp routing-table


*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009?
*> 9.1.3.0/24 200.1.1.1 0 0 65009?
200.1.1.0 200.1.1.1 0 0 65009?
# View the BGP routing table of Router C.



*>i 8.0.0.0 200.1.1.2 0 100 0 65008i

*>i 9.1.1.0/24 9.1.3.1 0 100 0 ?
i 9.1.3.0/24 9.1.3.1 0 100 0 ?
*>i 200.1.1.0 9.1.3.1 0 100 0 ?
The preceding command output shows that the route to destination 8.0.0.0 becomes valid
because the next-hop address of this route is the address of Router A.
# Run the ping command on Router C.
[RouterC] ping 8.1.1.1
0.00% packet loss
----End
Configuration Files
#
sysname RouterA
#
ip address 8.1.1.1 255.0.0.0
#

Routers
ip address 200.1.1.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
network 8.0.0.0
#
return

#
sysname RouterB
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.1.1 255.255.255.0
#
ip address 9.1.3.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
import-route direct
peer 9.1.1.2 enable
peer 9.1.3.2 enable
#
return

#
sysname RouterC
#
ip address 9.1.2.1 255.255.255.0
#
ip address 9.1.3.2 255.255.255.0
#
bgp 65009
router-id 3.3.3.3
#
ipv4-family unicast
peer 9.1.2.2 enable
peer 9.1.3.1 enable
#
return

#
sysname RouterD

Routers
#
ip address 9.1.1.2 255.255.255.0
#
ip address 9.1.2.2 255.255.255.0
#
bgp 65009
router-id 4.4.4.4
#
ipv4-family unicast
peer 9.1.1.1 enable
peer 9.1.2.1 enable
#
return
9.7.2 Example for Configuring Basic BGP4+ Functions
Networking Requirement
As shown in Figure 9-20, there are two ASs: 65008 and 65009. Router A belongs to AS 65008;
Router B, and Router C belong to AS65009. Routing Protocol is required to exchange the routing
information between the two ASs.
Figure 9-20 Figure 1 Networking diagram of configuring basic BGP4+ functions

AS 65008 AS 65009
GE1/0/0
8::1/64 GE1/0/0
9:1::1/64
GE2/0/0 GE2/0/0 GE1/0/0
RouterA 10::2/64 10::1/64 RouterB 9:1::2/64 RouterC
1. Configure the IBGP connection between Router B and Router C.

2. Configure the EBGP connection between Router A and Router B.
Procedure
Step 2 Configure the IBGP.
[RouterB] ipv6
[RouterB] bgp 65009

Routers

[RouterB-bgp] peer 9:1::2 as-number 65009
[RouterB-bgp-af-ipv6] peer 9:1::2 enable
[RouterB-bgp-af-ipv6] network 9:1:: 64
[RouterC] ipv6
[RouterC] bgp 65009
[RouterC-bgp] peer 9:1::1 as-number 65009
[RouterC-bgp-af-ipv6] peer 9:1::1 enable
[RouterC-bgp-af-ipv6] network 9:1:: 64
Step 3 Configure the EBGP.

[RouterA] ipv6
[RouterA] bgp 65008
[RouterA-bgp] peer 10::1 as-number 65009
[RouterA-bgp-af-ipv6] peer 10::1 enable
[RouterA-bgp-af-ipv6] network 10:: 64
[RouterB] bgp 65009
[RouterB-bgp] peer 10::2 as-number 65008
[RouterB-bgp-af-ipv6] peer 10::2 enable
[RouterB-bgp-af-ipv6] network 10:: 64
# Check the connection status of BGP4+ peers.

[RouterB] display bgp ipv6 peer

Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
9:1::2 4 65009 10 14 0 00:07:10 Established

1
10::2 4 65008 6 6 0 00:02:17 Established
2
The routing table shows that Router B has set up BGP4+ connections with other routers.
# Display the routing table of Router A.
[RouterA] display bgp ipv6 routing-table


*> Network : 8:: PrefixLen : 64
NextHop : :: LocPrf :

Routers
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
*> Network : 9:1:: PrefixLen : 64
NextHop : 10::1 LocPrf :
MED : 0 PrefVal : 0
Label :
Path/Ogn : 65009 i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i

MED : 0 PrefVal : 0
Label :
Path/Ogn : 65009 i
The routing table shows that Router A has learned the route from AS 65009. AS 65008 and AS
65009 can exchange their routing information.
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
#
ipv6 enable
#
bgp 65008
router-id 1.1.1.1
peer 10::1 as-number 65009
#
ipv4-family unicast
#
ipv6-family unicast
network 8:: 64
network 10:: 64
peer 10::1 enable
#
return

#
sysname RouterB
#
ipv6
#
ipv6 enable
#

Routers
ipv6 enable
#
bgp 65009
router-id 2.2.2.2
peer 9:1::2 as-number 65009
#
ipv4-family unicast
#
ipv6-family unicast
network 9:1:: 64
network 10:: 64
peer 9:1::2 enable
peer 10::2 enable
#
return

#
sysname RouterC
#
ipv6
#
ipv6 enable
#
bgp 65009
router-id 3.3.3.3
peer 9:1::1 as-number 65009
#
ipv4-family unicast
#
ipv6-family unicast
network 9:1:: 64
peer 9:1::1 enable
#
return
9.7.3 Example for Configuring Basic MBGP Functions
As shown in Figure 9-21, the receiver receives VoD information in multicast mode. The receiver
and the source reside in different ASs. Multicast routing information needs to be transmitted
between ASs.

Routers
Figure 9-21 Networking diagram of configuring MBGP
AS100 AS200
RouterD
Loopback0
GE2/0/0
GE1/0/0
Source RouterA GE2/0/0

RouterB
GE2/0/0 GE1/0/0
GE1/0/0 GE3/0/0
Loopback0 Loopback0
GE3/0/0 GE1/0/0
RouterC Loopback0
GE2/0/0
Receiver
MBGP peers
Device Interface IP Address Device Interface IP Address
Router A GE1/0/0 10.1.1.1/24 Router C GE1/0/0 10.4.1.1/24
GE2/0/0 10.10.10.1/24 GE2/0/0 10.168.1.1/24
Loopback0 1.1.1.1/32 GE3/0/0 10.2.1.1/24
Router B GE1/0/0 10.1.1.2/24 Loopback0 3.3.3.3/32
GE2/0/0 10.3.1.2/24 Router D GE1/0/0 10.4.1.2/24
GE3/0/0 10.2.1.2/24 GE2/0/0 10.3.1.1/24
Loopback0 2.2.2.2/32 Loopback0 4.4.4.4/32
1. Configure MBGP peers for inter-AS multicast transmission.

2. Configure the routes advertised by MBGP.
3. Enable the multicast function on each router.
4. Configure basic PIM-SM functions on each router in ASs and enable IGMP on receiver-
side interfaces.
5. Configure a BSR boundary on the interfaces that connect to two ASs.
6. Configure MSDP peers to transmit inter-domain multicast source information.

Routers
Procedure
Step 1 Assign IP addresses to the interfaces on each router and configure OSPF in ASs.
# Configure IP addresses and masks for the interfaces on each router according to Figure
9-21 and configure OSPF on the routers in ASs. Ensure that Router B, Router C, Router D can
communicate with the receiver at the network layer, learn routes to the loopback interfaces of
each other, and dynamically update routes using a unicast routing protocol. Configure OSPF
process 1. The configuration procedure is not mentioned here.
Step 2 Configure BGP, enable the MBGP protocol, and configure MBGP peers.
# Configure BGP and the MBGP peer on Router A.
[RouterA] bgp 100
[RouterA-bgp] ipv4-family multicast
[RouterA-bgp-af-multicast] peer 10.1.1.2 enable
[RouterA-bgp-af-multicast] quit
[RouterA-bgp] quit
# Configure BGP and the MBGP peer on Router B.

[RouterB] bgp 200
[RouterB-bgp] ipv4-family multicast
[RouterB-bgp-af-multicast] peer 10.1.1.1 enable
[RouterB-bgp-af-multicast] quit
[RouterB-bgp] quit
# Configure BGP and the MBGP peer on Router C.

[RouterC] bgp 200
[RouterC-bgp] ipv4-family multicast
[RouterC-bgp-af-multicast] peer 10.2.1.2 enable
[RouterC-bgp-af-multicast] peer 10.4.1.2 enable
[RouterC-bgp-af-multicast] quit
[RouterC-bgp] quit
# Configure BGP and the MBGP peer on Router D.

[RouterD] bgp 200
[RouterD-bgp] ipv4-family multicast
[RouterD-bgp-af-multicast] peer 10.3.1.2 enable
[RouterD-bgp-af-multicast] peer 10.4.1.1 enable
[RouterD-bgp-af-multicast] quit
[RouterD-bgp] quit
Step 3 Configure the routes to be advertised.

# Configure the routes to be advertised on Router A.
[RouterA] bgp 100
[RouterA-bgp] import-route direct
[RouterA-bgp] ipv4-family multicast
[RouterA-bgp-af-multicast] import-route direct
[RouterA-bgp-af-multicast] quit
[RouterA-bgp] quit

Routers
# Configure the routes to be advertised on Router B.

[RouterB] bgp 200
[RouterB-bgp] import-route direct
[RouterB-bgp] import-route ospf 1
[RouterB-bgp] ipv4-family multicast
[RouterB-bgp-af-multicast] import-route direct
[RouterB-bgp-af-multicast] import-route ospf 1
[RouterB-bgp-af-multicast] quit
[RouterB-bgp] quit
# Configure the routes to be advertised on Router C. The configuration of Router D is similar

to the configuration of Router C, and is not mentioned here.
[RouterC] bgp 200
[RouterC-bgp] import-route direct
[RouterC-bgp] ipv4-family multicast
[RouterC-bgp-af-multicast] import-route direct
[RouterC-bgp-af-multicast] import-route ospf 1
[RouterC-bgp-af-multicast] quit
[RouterC-bgp] quit
Step 4 Enable the multicast function on each Router and interfaces on the Routers.
[RouterA] multicast routing-enable
[RouterA-GigabitEthernet1/0/0] pim sm
[RouterA-GigabitEthernet2/0/0] pim sm
[RouterB] multicast routing-enable
[RouterB-GigabitEthernet1/0/0] pim sm
[RouterC] multicast routing-enable
[RouterC-GigabitEthernet1/0/0] pim sm
[RouterC-GigabitEthernet2/0/0] igmp enable
[RouterD] multicast routing-enable
[RouterD-GigabitEthernet1/0/0] pim sm

Routers

[RouterD-GigabitEthernet2/0/0] pim sm
Step 5 Configure the BSR and RP within each AS.
[RouterA] interface loopback 0
[RouterA-LoopBack0] ip address 1.1.1.1 255.255.255.255
[RouterA-LoopBack0] pim sm
[RouterA-LoopBack0] quit
[RouterA] pim
[RouterA-pim] c-bsr loopback 0
[RouterA-pim] c-rp loopback 0
[RouterA-pim] quit
[RouterB] interface loopback 0
[RouterB-LoopBack0] ip address 2.2.2.2 255.255.255.255
[RouterB-LoopBack0] pim sm
[RouterB-LoopBack0] quit
[RouterB] pim
[RouterB-pim] c-bsr loopback 0
[RouterB-pim] c-rp loopback 0
[RouterB-pim] quit
Step 6 Configure a BSR boundary on the interfaces that connect to two ASs.
[RouterA-GigabitEthernet1/0/0] pim bsr-boundary
[RouterB-GigabitEthernet1/0/0] pim bsr-boundary
Step 7 Configure MSDP peers.
[RouterA] msdp
[RouterA-msdp] peer 10.1.1.2 connect-interface gigabitethernet 1/0/0
[RouterA-msdp] quit
[RouterB] msdp
[RouterB-msdp] peer 10.1.1.1 connect-interface gigabitethernet 1/0/0
[RouterB-msdp] quit
# Run the display bgp multicast peer command to view the MBGP peer relationship between
Routers. For example, information about the MBGP peer relationship on Router A is as follows:
[RouterA] display bgp multicast peer
10.1.1.2 4 200 82 75 0 00:30:29 Established 17

Routers
# Run the display msdp brief command to view information about the MSDP peer relationship
between Routers. For example, brief information about the MSDP peer relationship on Router
B is as follows:
[RouterB] display msdp brief
MSDP Peer Brief Information of VPN-Instance: public net
Configured Up Listen Connect Shutdown Down
1 1 0 0 0 0
Peer's Address State Up/Down time AS SA Count Reset Count
10.1.1.1 Up 00:07:17 100 1 0
----End
Configuration Files
#
sysname RouterA
#
multicast routing-enable
#
ip address 10.1.1.1 255.255.255.0
pim bsr-boundary
pim sm
#
ip address 10.10.10.1 255.255.255.0
pim sm
#
interface Loopback0
ip address 1.1.1.1 255.255.255.255
pim sm
#
pim
c-bsr Loopback0
c-rp Loopback0
#
bgp 100
#
ipv4-family unicast
import-route direct
#
import-route direct
#
msdp
peer 10.1.1.2 connect-interface GigabitEthernet1/0/0
#
return

#
sysname RouterB
#
#
ip address 10.1.1.2 255.255.255.0
pim bsr-boundary

Routers
pim sm
#
ip address 10.3.1.2 255.255.255.0
pim sm
#
ip address 10.2.1.2 255.255.255.0
pim sm
#
interface Loopback0
ip address 2.2.2.2 255.255.255.255
pim sm
#
pim
c-bsr Loopback0
c-rp Loopback0
#
ospf 1
area 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
bgp 200
#
ipv4-family unicast
import-route direct
import-route ospf 1
#
import-route direct
import-route ospf 1
#
msdp
peer 10.1.1.1 connect-interface GigabitEthernet1/0/0
#
return

#
sysname RouterC
#
#
ip address 10.4.1.1 255.255.255.0
pim sm
#
ip address 10.168.1.1 255.255.255.0
pim sm
igmp enable
#
ip address 10.2.1.1 255.255.255.0

Routers
pim sm
#
interface Loopback0
ip address 3.3.3.3 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
network 10.168.1.0 0.0.0.255
network 3.3.3.3 0.0.0.0
#
bgp 200
#
ipv4-family unicast
import-route direct
#
import-route direct
import-route ospf 1
#
return

#
sysname RouterD
#
#
ip address 10.4.1.2 255.255.255.0
pim sm
#
ip address 10.3.1.1 255.255.255.0
pim sm
#
interface Loopback0
ip address 4.4.4.4 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.3.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
network 4.4.4.4 0.0.0.0
#
bgp 200
#
ipv4-family unicast
import-route direct
#

Routers
import-route direct
import-route ospf 1
#
return
9.7.4 Example for Configuring BGP to Interact with an IGP
The network shown in Figure 9-22 is divided into AS 65008 and AS 65009. In AS 65009, an
IGP is used to calculate routes. In this example, OSPF is used as an IGP. The two ASs need to
communicate with each other.
Figure 9-22 Networking diagram for configuring BGP to interact with an IGP
GE1/0/0 GE2/0/0
GE2/0/0 GE1/0/0
8.1.1.1/24 9.1.2.1/24
3.1.1.2/24 9.1.1.1/24
GE1/0/0
GE2/0/0
RouterA RouterB 9.1.1.2/24 RouterC
3.1.1.1/24
AS 65008
AS 65009
1. Configure OSPF on Routers B and C so that these devices can access each other.
2. Establish an EBGP connection between Routers A and B so that these devices can exchange
3. Configure BGP and OSPF to import routes from each other on Router B so that the two
ASs can communicate with each other.
4. (Optional) Configure BGP route summarization on Router B to simplify the BGP routing
table.
Procedure
Configure an IP address to each interface as shown in Figure 9-22. For details about the
configuration, see the following configuration files.
Step 2 Configuring OSPF
[RouterB] ospf 1

Routers
[RouterC] ospf 1
Step 3 Establish an EBGP connection.

[RouterA] bgp 65008
[RouterB] bgp 65009
Step 4 Configure BGP to interact with an IGP

# On Router B, configure BGP to import OSPF routes.
[RouterB-bgp-af-ipv4] import-route ospf 1
[RouterB-bgp-af-ipv4] quit
[RouterB-bgp] quit

[RouterA] display bgp routing-table
*> 8.1.1.0/24 0.0.0.0 0 0 i
*> 9.1.1.0/24 3.1.1.1 0 0 65009?
*> 9.1.2.0/24 3.1.1.1 2 0 65009?
# On Router B, configure OSPF to import BGP routes.

[RouterB] ospf
[RouterB-ospf-1] import-route bgp

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

Routers
8.1.1.0/24 O_ASE 150 1 D 9.1.1.1

9.1.1.0/24 Direct 0 0 D 9.1.1.2
9.1.1.2/32 Direct 0 0 D 127.0.0.1
9.1.2.0/24 Direct 0 0 D 9.1.2.1
9.1.2.1/32 Direct 0 0 D 127.0.0.1
Step 5 (Optional) Configure automatic route summarization.

BGP is used to transmit routing information on large-scale networks. BGP route summarization
can be configured to simplify routing tables of devices on these networks.
[RouterB] bgp 65009
[RouterB-bgp-af-ipv4] summary automatic

[RouterA] display bgp routing-table
*> 8.1.1.0/24 0.0.0.0 0 0 i
*> 9.0.0.0 3.1.1.1 0 65009?
# Run the ping -a 8.1.1.1 9.1.2.1 command on Router A.

[RouterA] ping -a 8.1.1.1 9.1.2.1
0.00% packet loss
----End
Configuration Files
#
sysname Router A
#
ip address 8.1.1.1 255.255.255.0
#
ip address 3.1.1.2 255.255.255.0
#
bgp 65008

Routers
router-id 1.1.1.1
#
ipv4-family unicast
network 8.1.1.0 255.255.255.0
peer 3.1.1.1 enable
#
return

#
sysname Router B
#
ip address 9.1.1.1 255.255.255.0
#
ip address 3.1.1.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
summary automatic
import-route ospf 1
peer 3.1.1.2 enable
#
ospf 1
import-route bgp
area 0.0.0.0
network 9.1.1.0 0.0.0.255
#
return

#
sysname Router C
#
ip address 9.1.1.2 255.255.255.0
#
ip address 9.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 9.1.1.0 0.0.0.255
network 9.1.2.0 0.0.0.255
#
return
9.7.5 Example for Configuring AS_Path Filters
On the network shown in Figure 9-23, Router B establish EBGP connections with Routers A
and C. The user wants to disable the devices in AS 10 from communicating with devices in AS
30,

Routers
Figure 9-23 Networking diagram for configuring AS_Path filters
GE1/0/0
AS 10 9.1.1.1/24
GE2/0/0
200.1.2.1/24
RouterA
EBGP
GE2/0/0 GE2/0/0
200.1.2.2/24 EBGP 200.1.3.2/24
GE1/0/0
GE1/0/0 10.1.1.1/24
200.1.3.1/24 RouterC
RouterB
AS 20 AS 30
1. Establish EBGP connections between Routers A and B and between Routers B and C and
configure these devices to import direct routes so that the ASs can communicate with each
other through these EBGP connections.
2. Configure AS_Path filters on Router B and use filtering rules to prevent AS 20 from
advertising routes of AS 30 to AS 10 or routes of AS 10 to AS 30.
Procedure
Step 1 Configure an IP address for each interface. The configuration details are not provided here.
Step 2 Establish EBGP connections.

[RouterA] bgp 10
[RouterA-bgp] import-route direct
[RouterB] bgp 20
[RouterB-bgp] import-route direct
[RouterB-bgp] quit
[RouterC] bgp 30
[RouterC-bgp] import-route direct

Routers
[RouterC-bgp] quit
# View routes advertised by Router B. Routes advertised by Router B to Router C are used as
an example. You can see that Router B advertises the direct route imported by AS 10.
<RouterB> display bgp routing-table peer 200.1.3.2 advertised-routes


*> 9.1.1.0/24 200.1.3.1 0 20 10?

*> 10.1.1.0/24 200.1.3.1 0 20 30?
*> 200.1.2.0 200.1.3.1 0 0 20?
*> 200.1.2.1/32 200.1.3.1 0 0 20?
*> 200.1.3.0/24 200.1.3.1 0 0 20?
View the routing table of Router C. You can see that Router C has learned the direct route from
Router B.
<RouterC> display bgp routing-table


*> 9.1.1.0/24 200.1.3.1 0 20 10?

*> 10.1.1.0/24 0.0.0.0 0 0 ?
*> 10.1.1.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
*> 200.1.2.0 200.1.3.1 0 0 20?
*> 200.1.3.0/24 0.0.0.0 0 0 ?
* 200.1.3.1 0 0 20?
*> 200.1.3.2/32 0.0.0.0 0 0 ?
Step 3 Configure AS_Path filters on Router B and apply the AS_Path filters to routes to be advertised
by Router B.
# Create AS_Path filter 1 to deny the routes carrying AS number 30. The regular expression
"_30_" indicates any AS list that contains AS 30 and "*" matches any character.
[RouterB] ip as-path-filter path-filter1 deny _30_
[RouterB] ip as-path-filter path-filter1 permit .*
# Create AS_Path filter 2 to deny the routes carrying AS 10.

[RouterB] ip as-path-filter path-filter2 deny _10_
[RouterB] ip as-path-filter path-filter2 permit .*
# Apply the AS_Path filters to routes to be advertised by Router B.

[RouterB] bgp 20
[RouterB-bgp] peer 200.1.2.1 as-path-filter path-filter1 export
[RouterB-bgp] peer 200.1.3.2 as-path-filter path-filter2 export

Routers
[RouterB-bgp] quit
Step 4 # View routes advertised by Router B.
# View routes advertised by Router B to AS 30. You can see that Router B does not advertise
the direct route imported by AS 10.


*> 200.1.2.0 200.1.3.1 0 0 20?

*> 200.1.3.0/24 200.1.3.1 0 0 20?
The route does not exist in the BGP routing table of Router C.
<RouterC> display bgp routing-table


*> 10.1.1.0/24 0.0.0.0 0 0 ?

*> 10.1.1.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
*> 200.1.2.0 200.1.3.1 0 0 20?
*> 200.1.3.0/24 0.0.0.0 0 0 ?
* 200.1.3.1 0 0 20?
*> 200.1.3.2/32 0.0.0.0 0 0 ?
# View routes advertised by Router B to AS 10. You can see that Router B does not advertise
the direct route imported by AS 30.


*> 200.1.2.0 200.1.2.2 0 0 20?

*> 200.1.3.0/24 200.1.2.2 0 0 20?
The route does not exist in the BGP routing table of Router A.
<RouterA> display bgp routing-table


Routers


*> 9.1.1.0/24 0.0.0.0 0 0 ?

*> 9.1.1.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
*> 200.1.2.0 0.0.0.0 0 0 ?
* 200.1.2.2 0 0 20?
*> 200.1.2.1/32 0.0.0.0 0 0 ?
*> 200.1.3.0/24 200.1.2.2 0 0 20?
----End
Configuration Files
#
sysname RouterA
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.2.1 255.255.255.0
#
bgp 10
router-id 1.1.1.1
#
ipv4-family unicast
import-route direct
#
return

#
sysname RouterB
#
ip address 200.1.3.1 255.255.255.0
#
ip address 200.1.2.2 255.255.255.0
#
bgp 20
router-id 2.2.2.2
#
ipv4-family unicast
import-route direct
peer 200.1.2.1 as-path-filter path-filter1 export
peer 200.1.3.2 as-path-filter path-filter2 export
#
ip as-path-filter path-filter1 deny _30_
ip as-path-filter path-filter1 permit .*
ip as-path-filter path-filter2 deny _10_

Routers
ip as-path-filter path-filter2 permit .*

#
return

#
sysname RouterC
#
ip address 10.1.1.1 255.255.255.0
#
ip address 200.1.3.2 255.255.255.0
#
bgp 30
router-id 3.3.3.3
#
ipv4-family unicast
import-route direct
#
return
9.7.6 Example for Configuring MED Attributes to Control BGP

Route Selection
As shown in Figure 9-24, BGP is configured on all routeres; Router A resides in AS 65008;
Router B and Router C reside in AS 65009. EBGP connections are established between
Router A and Router B, and between Router A and Router C. An IBGP connection is established
between Router B and Router C. After a period, traffic from AS 65008 to AS 65009 needs to
first pass through RouterC.
Figure 9-24 Networking diagram for configuring MED attributes of routes to control route
selection
GE2/0/0 RouterB
200.1.1.1/24
GE1/0/0 GE1/0/0
AS 65008 200.1.1.2/24 9.1.1.1/24
EBGP
IBGP
RouterA
AS 65009
GE2/0/0
200.1.2.2/24 EBGP GE1/0/0
9.1.1.2/24
GE2/0/0
200.1.2.1/24 RouterC

Routers
1. Establish EBGP connections between Router A and Router B and between Router A and
Router C, and establish an IBGP connection between Router B and Router C.
2. Apply a routing policy to increase the MED value of the route sent by Router B to Router
A so that Router A will send traffic to AS 65009 through Router C.
Procedure
Step 2 Establish BGP connections.
[RouterA] bgp 65008
[RouterA-bgp] quit
[RouterB] bgp 65009
[RouterB-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterB-bgp] quit
[RouterC] bgp 65009
[RouterC-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterC-bgp-af-ipv4] quit
[RouterC-bgp] quit

[RouterA] display bgp routing-table 9.1.1.0 24

Paths: 2 available, 1 best, 1 select
BGP routing table entry information of 9.1.1.0/24:
From: 200.1.1.1 (2.2.2.2)
Route Duration: 00h00m56s
Direct Out-interface: GigabitEthernet1/0/0
Original nexthop: 200.1.1.1
Qos information : 0x0
AS-path 65009, origin igp, MED 0, pref-val 0, valid, external, best, select, pre
255
Advertised to such 2 peers:
200.1.1.1
200.1.2.1

Routers

From: 200.1.2.1 (3.3.3.3)
AS-path 65009, origin igp, MED 0, pref-val 0, valid, external, pre 255, not
preferred for router ID
Not advertised to any peer yet
The preceding command output shows that there are two valid routes to destination 9.1.1.0/24.
The route with the next-hop address of 200.1.1.1 is the optimal route because the router ID of
Router is smaller.
Step 3 Set MED attributes for routes.
# Apply a routing policy to set an MED value for the route advertised by Router B to Router A
(the default MED value of a route is 0).
[RouterB] route-policy policy10 permit node 10
[RouterB] bgp 65009
[RouterB-bgp] peer 200.1.1.2 route-policy policy10 export


From: 200.1.2.1 (3.3.3.3)
AS-path 65009, origin igp, MED 0, pref-val 0, valid, external, best, select, pre
255
200.1.1.1
200.1.2.1

From: 200.1.1.1 (2.2.2.2)
AS-path 65009, origin igp, MED 100, pref-val 0, valid, external, pre 255, not
preferred for MED
The preceding command output shows that the MED value of the route with the next-hop address
of 200.1.1.1 (Router B) is 100 and the MED value of the route with the next-hop address of
200.1.2.1 is 0. The route with the smaller MED value is selected.
----End
Configuration Files
#

Routers
sysname Router A
#
ip address 200.1.1.2 255.255.255.0
#
ip address 200.1.2.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
#
return

#
sysname Router B
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.1.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 9.1.1.2 enable
peer 200.1.1.2 route-policy policy10 export
#
route-policy policy10 permit node 10
apply cost 100
#
return

#
sysname Router C
#
ip address 9.1.1.2 255.255.255.0
#
ip address 200.1.2.1 255.255.255.0
#
bgp 65009
router-id 3.3.3.3
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 9.1.1.1 enable

Routers
#
return
9.7.7 Example for Configuring a BGP Route Reflector

As shown in Figure 9-25, eight Routers need to form an IBGP network. Full-mesh BGP
connections have been established between Router B, Router D, and Router E. Users require
that the IBGP network be formed without interrupting full-mesh BGP connections between
Router B, Router D, and Router E and require simplified device configuration and management.
Figure 9-25 Networking diagram of configuring a BGP RR
GE3/0/0
9.1.1.1/24
AS 65010
GE1/0/0 GE2/0/0
RouterA
GE1/0/0 GE2/0/0
RouerB GE4/0/0 GE1/0/0 RouterC
0 GE GE4/0/0
2 /0/ 3 /0
GE3/0/0
/0
GE
Cluster1 Cluster2
GE3/0/0 GE1/0/0
GE1/0/0
GE2/0/0 GE1/0/0
GE2/0/0
RouterD RouterE RouterF RouterG
Device Interface IP address Device Interface IP address
RouterA GE 1/0/0 10.1.1.2/24 RouterC GE 4/0/0 10.1.8.1/24
GE 2/0/0 10.1.3.2/24 RouterD GE 1/0/0 10.1.4.2/24
GE 3/0/0 9.1.1.1/24 GE 2/0/0 10.1.6.1/24
RouterB GE 1/0/0 10.1.1.1/24 RouterE GE 2/0/0 10.1.6.2/24
GE 2/0/0 10.1.4.1/24 GE 3/0/0 10.1.5.2/24
GE 3/0/0 10.1.5.1/24 RouterF GE 1/0/0 10.1.7.2/24
GE 4/0/0 10.1.2.1/24 RouterG GE 1/0/0 10.1.8.2/24
RouterC GE 1/0/0 10.1.2.2/24
GE 2/0/0 10.1.3.1/24
GE 3/0/0 10.1.7.1/24

Routers
1. Configure RouterB as the route reflector of Cluster1 and RouterD and RouterE as the clients
of RouterB. Prohibit communication between the clients to form an IBGP network without
interrupting full-mesh BGP connections between RouterB, RouterD, and RouterE.
2. Configure RouterC as the route reflector of Cluster2 and RouterF, RouterG, and RouterH
as the clients of RouterC to simplify device configuration and management.
Procedure
Step 1 Configure an IP address for each interface. The configuration details are not mentioned here.
Step 2 Configure the IBGP connections between the clients and the RR and between the non-clients
and the RR. The configuration details are not mentioned here.
Step 3 Configure the RR.
[RouterB] bgp 65010
[RouterB-bgp] group in_rr internal
[RouterB-bgp] peer 10.1.4.2 group in_rr
[RouterB-bgp] peer 10.1.5.2 group in_rr
[RouterB-bgp-af-ipv4] peer in_rr reflect-client
[RouterB-bgp-af-ipv4] undo reflect between-clients
[RouterB-bgp-af-ipv4] reflector cluster-id 1
[RouterC] bgp 65010
[RouterC-bgp] group in_rr internal
[RouterC-bgp] peer 10.1.7.2 group in_rr
[RouterC-bgp] peer 10.1.8.2 group in_rr
[RouterC-bgp-af-ipv4] peer in_rr reflect-client
[RouterC-bgp-af-ipv4] reflector cluster-id 2
[RouterC-bgp-af-ipv4] quit
# Display the routing table of Router D.

[RouterD] display bgp routing-table 9.1.1.0
From: 10.1.4.1 (2.2.2.2)
Relay IP Nexthop: 0.0.0.0
Relay IP Out-Interface:
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, internal, pre 255
Originator: 1.1.1.1
Cluster list: 0.0.0.1
You can view that Router D has learned the route advertised by Router A from Router B. For
details, see the Originator and Cluster_ID attributes of the route.
----End

Routers
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.1.3.2 255.255.255.0
#
ip address 9.1.1.1 255.255.255.0
#
bgp 65010
router-id 1.1.1.1
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
return

#
sysname RouterB
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.1.4.1 255.255.255.0
#
ip address 10.1.5.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
bgp 65010
router-id 2.2.2.2
group in_rr internal
peer 10.1.4.2 group in_rr
#
ipv4-family unicast
undo reflect between-clients
reflector cluster-id 1
peer in_rr enable
peer in_rr reflect-client
#

Routers
return

#
sysname RouterC
#
ip address 10.1.2.2 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0
#
ip address 10.1.7.1 255.255.255.0
#
ip address 10.1.8.1 255.255.255.0
#
bgp 65010
router-id 3.3.3.3
group in_rr internal
#
ipv4-family unicast
reflector cluster-id 2
peer in_rr enable
peer in_rr reflect-client
#
return

#
sysname RouterD
#
ip address 10.1.4.2 255.255.255.0
#
ip address 10.1.6.1 255.255.255.0
#
bgp 65010
router-id 4.4.4.4
#
ipv4-family unicast
#
return
NOTE
The configuration file of other routers is similar to that of Router D and is omitted here.

Routers
9.7.8 Example for Configuring a BGP4+ Route Reflection

As shown in Figure 9-26, four devices belong to two ASs. You are required to perform simplified
configuration to ensure that the two ASs communicate with each other.
Figure 9-26 Networking diagram of configuring BGP4+ route reflection
RouterC AS200
GE2/0/0 GE1/0/0
101::1/96 102::1/96
AS100
GE1/0/0
GE2/0/0 GE1/0/0
101::2/96
100::1/96 102::2/96
GE1/0/0
1::1/64 GE2/0/0
RouterA 100::2/96 RouterB RouterD
1. Configure basic BGP4+ functions to allow BGP neighbors to communicate.

2. Configure RouterC as a route reflector so that no IBGP connection needs to be established
between RouterB and RouterD. This simplifies the configuration.
Procedure
Step 2 Configure basic BGP4+ functions.
[RouterA] ipv6
[RouterA] bgp 100
[RouterA-bgp] peer 100::2 as-number 200
[RouterA-bgp-af-ipv6] peer 100::2 enable
[RouterA-bgp] quit
[RouterB] ipv6
[RouterB] bgp 200

Routers

[RouterB-bgp] quit
[RouterC] ipv6
[RouterC] bgp 200
[RouterC-bgp] peer 101::2 as-number 200
[RouterC-bgp] peer 102::2 as-number 200
[RouterC-bgp-af-ipv6] peer 101::2 enable
[RouterC-bgp-af-ipv6] peer 102::2 enable
[RouterC-bgp-af-ipv6] network 101:: 96
[RouterC-bgp-af-ipv6] network 102:: 96
[RouterD] ipv6
[RouterD] bgp 200
[RouterD-bgp] peer 102::1 as-number 200
[RouterD-bgp] ipv6-family unicast
[RouterD-bgp-af-ipv6] peer 102::1 enable
[RouterD-bgp-af-ipv6] network 102:: 96
[RouterD-bgp-af-ipv6] quit
[RouterD-bgp] quit
Step 3 Configure the route reflector.

# Configure RouterC as a route reflector, and RouterB and RouterD serve as its clients.
[RouterC-bgp-af-ipv6] peer 101::2 reflect-client
[RouterC-bgp-af-ipv6] peer 102::2 reflect-client
# Check the routing table of RouterB.

[RouterB] display bgp ipv6 routing-table


MED : 0 PrefVal : 0
Label :
Path/Ogn : 100 i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i

MED : 0 PrefVal : 0
Label :
Path/Ogn : 100 i

Routers
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
i
NextHop : 101::1 LocPrf : 100
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
*>i Network : 102:: PrefixLen : 96
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
# Check the routing table of RouterD.

[RouterD] display bgp ipv6 routing-table


MED : 0 PrefVal : 0
Label :
Path/Ogn : 100 i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
The routing table shows that RouterD and RouterB learn the routing information advertised by
RouterA from RouterC.
----End
Configuration Files
#
sysname RouterA
#
ipv6
#

Routers
ipv6 enable
#
ipv6 enable
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
network 1:: 64
network 100:: 96
peer 100::2 enable
#
return

#
sysname RouterB
#
ipv6
#
ipv6 enable
#
ipv6 enable
#
bgp 200
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
network 100:: 96
network 101:: 96
peer 100::1 enable
peer 101::1 enable
#
return

#
sysname RouterC
#
ipv6
#
ipv6 enable
#
ipv6 enable
#

Routers
bgp 200
router-id 3.3.3.3
#
ipv4-family unicast
#
ipv6-family unicast
network 101:: 96
network 102:: 96
peer 101::2 enable
peer 101::2 reflect-client
peer 102::2 enable
peer 102::2 reflect-client
#
return

#
sysname RouterD
#
ipv6
#
ipv6 enable
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
#
ipv6-family unicast
network 102:: 96
peer 102::1 enable
#
return
9.7.9 Example for Configuring a BGP Confederation
As shown in Figure 9-27, there are multiple BGP routers in AS 200. It is required that the number
of IBGP connections be reduced.

Routers
Figure 9-27 Networking diagram of configuring the confederation
RouterB RouterC
GE1/0/0
AS 65002 10.1.2.2/24
GE1/0/0 AS 65003
10.1.1.2/24
10.1.1.1/24
GE3/0/0
GE2/0/0
10.1.2.1/24
GE2/0/0 AS 65001
9.1.1.1/24 RouterD
GE4/0/0 GE1/0/0
10.1.3.1/24 10.1.3.2/24
G
GE1/0/0 10 E0
RouterF .1 /0/
200.1.1.1/24 RouterA .4.1 1
.1 /0
.5 /0
/2
4
GE1/0/0
.1 E2
/2
4
10 G
200.1.1.2/24 10 G
AS 100 .1 E1
.4 /0
.2 /0
/2
4
GE2/0/0
AS 200 10.1.5.2/24
RouterE
1. Configure a BGP confederation on each router in AS 200 to divide AS 200 into three sub-
ASs: AS 65001, AS 65002, and AS 65003. Three routers in AS 65001 establish full-mesh
IBGP connections to reduce the number of IBGP connections.
Procedure
Step 1 Configure an IP address to each interface. The configuration details are not mentioned here.
Step 2 Configure the BGP confederation.
[RouterA] bgp 65001
[RouterA-bgp] confederation id 200
[RouterA-bgp] confederation peer-as 65002 65003
[RouterA-bgp-af-ipv4] peer 10.1.1.2 next-hop-local
[RouterB] bgp 65002
[RouterB-bgp] confederation id 200

Routers
[RouterB-bgp] confederation peer-as 65001

[RouterB-bgp] quit
[RouterC] bgp 65003
[RouterC-bgp] confederation id 200
[RouterC-bgp] confederation peer-as 65001
[RouterC-bgp] quit
Step 3 Configure IBGP connections inside AS 65001.

[RouterA] bgp 65001
[RouterD] bgp 65001
[RouterD-bgp] confederation id 200
[RouterD-bgp] quit
[RouterE] bgp 65001
[RouterE-bgp] router-id 5.5.5.5
[RouterE-bgp] confederation id 200
[RouterE-bgp] peer 10.1.4.1 as-number 65001
[RouterE-bgp] peer 10.1.5.1 as-number 65001
[RouterE-bgp] quit
Step 4 Configure the EBGP connection between AS 100 and AS 200.

[RouterA] bgp 65001
[RouterA-bgp] quit
[RouterF] bgp 100
[RouterF-bgp] router-id 6.6.6.6
[RouterF-bgp] peer 200.1.1.1 as-number 200
[RouterF-bgp] ipv4-family unicast
[RouterF-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterF-bgp-af-ipv4] quit

# Check the routing table of Router B.
[RouterB] display bgp routing-table

Routers

*>i 9.1.1.0/24 10.1.1.1 0 100 0 (65001) 100i
[RouterB] display bgp routing-table 9.1.1.0
From: 10.1.1.1 (1.1.1.1)
Relay IP Out-Interface: GigabitEthernet1/0/0
AS-path (65001) 100, origin igp, MED 0, localpref 100, pref-val 0, valid, external-
confed, best, select, active, pre 255
# Check the BGP routing table of Router D.

[RouterD] display bgp routing-table
*>i 9.1.1.0/24 10.1.3.1 0 100 0 100i
[RouterD] display bgp routing-table 9.1.1.0
From: 10.1.3.1 (1.1.1.1)
Relay IP Out-Interface: GigabitEthernet1/0/0
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal-
confed, best, select, pre 255
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.4.1 255.255.255.0
#
ip address 200.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0

Routers
#
bgp 65001
router-id 1.1.1.1
confederation id 200
confederation peer-as 65002 65003
#
ipv4-family unicast
peer 10.1.1.2 next-hop-local
#
return

#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
bgp 65002
router-id 2.2.2.2
confederation peer-as 65001
#
ipv4-family unicast
#
return
NOTE
The configuration file of Router C is similar to that of Router B, and is not mentioned here.
#
sysname RouterD
#
ip address 10.1.3.2 255.255.255.0
#
ip address 10.1.5.1 255.255.255.0
#
bgp 65001
router-id 4.4.4.4
#
ipv4-family unicast

Routers
#
return
NOTE
The configuration file of Router E is similar to that of Router D, and is not mentioned here.
#
sysname RouterF
#
ip address 200.1.1.2 255.255.255.0
#
ip address 9.1.1.1 255.255.255.0
#
bgp 100
router-id 6.6.6.6
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
return
9.7.10 Example for Configuring the BGP Community Attribute

As shown in Figure 9-28, EBGP connections are established between Router B and Router A,
and between Router B and Router C. It is required that AS 20 not advertise the routes advertised
by AS 10 to AS 30.
Figure 9-28 Networking diagram of configuring the BGP community

GE1/0/0
AS 10 9.1.1.1/24
GE2/0/0
200.1.2.1/24
RouterA
EBGP
GE2/0/0 GE1/0/0
200.1.2.2/24 EBGP 200.1.3.2/24
GE1/0/0
200.1.3.1/24 RouterC
RouterB
AS 20 AS 30

Routers
1. Configure a route-policy on RouterA to advertise the No_Export attribute so that AS 20

does not advertise the routes advertised by AS 10 to AS 30.
Procedure
Step 2 Establish EBGP connections.
[RouterA] bgp 10
[RouterA-bgp] quit
[RouterB] bgp 20
[RouterB-bgp] quit
[RouterC] bgp 30
[RouterC-bgp] quit
# On Router B, view detailed information about route 9.1.1.0/24.


From: 200.1.2.1 (1.1.1.1)
AS-path 10, origin igp, MED 0, pref-val 0, valid, external, best, select, active,
pre 255
200.1.2.1
200.1.3.2
The preceding command output shows that Router B advertises the received BGP route to Router
C in AS 30.
# View the BGP routing table of Router C.



Routers

*> 9.1.1.0/24 200.1.3.1 0 20 10i
The preceding command output shows that Router C has learned route 9.1.1.0/24 from Router
B.
Step 3 Configure a BGP community attribute.
# Configure a routing policy on Router A to prevent BGP routes to be advertised by Router A

to Router B from being advertised to any other AS.
[RouterA] route-policy comm_policy permit node 10
[RouterA-route-policy] apply community no-export
[RouterA-route-policy] quit
# Apply the routing policy.

[RouterA] bgp 10
[RouterA-bgp-af-ipv4] peer 200.1.2.2 route-policy comm_policy export
[RouterA-bgp-af-ipv4] peer 200.1.2.2 advertise-community
# On Router B, view detailed information about route 9.1.1.0/24.


From: 200.1.2.1 (1.1.1.1)
Community:no-export
AS-path 10, origin igp, MED 0, pref-val 0, valid, external, best, select, active,
pre 255
The preceding command output shows that route 9.1.1.0/24 carries the configured community
attribute and Router B does not advertise this route to any other AS.
----End
Configuration Files
#
sysname RouterA
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.2.1 255.255.255.0
#
bgp 10
router-id 1.1.1.1
#
ipv4-family unicast

Routers
network 9.1.1.0 255.255.255.0
peer 200.1.2.2 route-policy comm_policy export
peer 200.1.2.2 advertise-community
#
route-policy comm_policy permit node 10
apply community no-export
#
return

#
sysname RouterB
#
ip address 200.1.3.1 255.255.255.0
#
ip address 200.1.2.2 255.255.255.0
#
bgp 20
router-id 2.2.2.2
#
ipv4-family unicast
#
return

#
sysname RouterC
#
ip address 200.1.3.2 255.255.255.0
#
bgp 30
router-id 3.3.3.3
#
ipv4-family unicast
#
return
9.7.11 Example for Configuring Prefix-based BGP ORF
As shown in Figure 9-29, PE1 and PE2 belong to AS 100. PE2 needs to advertise only the routes
that match the import policy of PE1 without having to maintain export policies.

Routers
Figure 9-29 Networking diagram of configuring prefix-based BGP ORF
AS100
PE1 GE1/0/0
111.1.1.1/24
GE1/0/0
111.1.1.2/24 PE2
1. Configure prefix-based BGP ORF so that PE2 can advertise only the routes that match the
import policy of PE1 without having to maintain export policies.
Procedure
Step 1 Establish an IPv4 unicast peer relationship between PE1 and PE2.
# Configure PE1.
[Huawei] sysname PE1
[PE1] bgp 100
[PE1-bgp] peer 111.1.1.2 as-number 100
[PE1-bgp] quit
# Configure PE2.
[Huawei] sysname PE2
[PE2] bgp 100
[PE2-bgp] peer 111.1.1.1 as-number 100
[PE2-bgp] quit
Step 2 Apply the prefix-based inbound policy on PE1.

# Configure PE1.
[PE1] ip ip-prefix 1 permit 4.4.4.0 24 greater-equal 32
[PE1] bgp 100
[PE1-bgp] peer 111.1.1.2 ip-prefix 1 import
[PE1-bgp] quit
# Configure PE2.
[PE2] ip route-static 3.3.3.3 255.255.255.255 NULL0

Routers

[PE2] bgp 100
[PE2-bgp] import static
[PE1-bgp] quit
# Check the routes sent by PE2 to PE1.

[PE2] display bgp routing peer 111.1.1.1 advertised-routes


*> 3.3.3.3/32 111.1.1.2 0 100 0 ?

*> 4.4.4.4/32 111.1.1.2 0 100 0 ?
*> 5.5.5.5/32 111.1.1.2 0 100 0 ?
# Check the routes received by PE1 from PE2.

[PE1] display bgp routing-table peer 111.1.1.2 received-routes


*>i 4.4.4.4/32 111.1.1.2 0 100 0 ?
When prefix-based BGP ORF is not enabled, PE2 sends routes 3.3.3.3, 4.4.4.4, and 5.5.5.5 to
PE1. Because the prefix-based inbound policy is applied on PE1, PE1 receives only route 4.4.4.4.
Step 3 Enable prefix-based BGP ORF.
# Enable prefix-based BGP ORF on PE1.

[PE1] bgp 100
[PE1-bgp] peer 111.1.1.2 capability-advertise orf ip-prefix both
[PE1-bgp] quit
# Enable prefix-based BGP ORF on PE2.

[PE2] bgp 100
[PE2-bgp] peer 111.1.1.1 capability-advertise orf ip-prefix both
[PE2-bgp] quit
# Check the negotiation of prefix-based BGP ORF.

[PE1] display bgp peer 111.1.1.2 verbose
BGP Peer is 111.1.1.2, remote AS 100

Type: IBGP link
BGP version 4, Remote router ID 111.1.1.2
Update-group ID: 2
BGP current state: Established, Up for 00h01m22s
BGP current event: KATimerExpired
BGP last state: OpenConfirm

Routers
BGP Peer Up count: 8

Received total routes: 1
Received active routes total: 1
Advertised total routes: 0
Port: Local - 54845 Remote - 179
Configured: Connect-retry Time: 32 sec
Configured: Active Hold Time: 180 sec Keepalive Time:60 sec
Received : Active Hold Time: 180 sec
Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec
Peer optional capabilities:
Peer supports bgp multi-protocol extension
Peer supports bgp route refresh capability
Peer supports bgp outbound route filter capability
Support Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
Peer supports bgp 4-byte-as capability
Address family IPv4 Unicast: advertised and received
Received: Total 5 messages
Update messages 1
Open messages 1
KeepAlive messages 2
Notification messages 0
Refresh messages 1
Sent: Total 4 messages
Update messages 0
Open messages 1
Refresh messages 1
Authentication type configured: None
Last keepalive received: 2011/09/25 18:48:15
Last keepalive sent : 2011/09/25 18:48:19
Last update received: 2011/09/25 16:11:28
Minimum route advertisement interval is 15 seconds
Optional capabilities:
Route refresh capability has been enabled
Outbound route filter capability has been enabled
Enable Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
4-byte-as capability has been enabled
Peer Preferred Value: 0
Routing policy configured:
No import update filter list
No export update filter list
Import prefix list is: 1
No export prefix list
No import route policy
No export route policy
No import distribute policy
No export distribute policy
# Check the routes sent by PE2 to PE1.

[PE2] display bgp routing peer 111.1.1.1 advertised-routes


*> 4.4.4.4/32 111.1.1.2 0 100 0 ?
# Check the routes received by PE1 from PE2.

[PE1] display bgp routing-table peer 111.1.1.2 received-routes

Routers


*>i 4.4.4.4/32 111.1.1.2 0 100 0 ?
After being enabled with prefix-based BGP ORF, PE2 sends only route 4.4.4.4 matching the
inbound policy of PE1.
----End
Configuration Files
#
sysname PE1
#
ip address 111.1.1.1 255.255.255.0
#
bgp 100
#
ipv4-family unicast
peer 111.1.1.2 ip-prefix 1 import
peer 111.1.1.2 capability-advertise orf ip-prefix both
#
ip ip-prefix 1 index 10 permit 4.4.4.0 24 greater-equal 32 less-equal 32
#
return

#
sysname PE2
#
ip address 111.1.1.2 255.255.255.0
#
bgp 100
#
ipv4-family unicast
import-route static
peer 111.1.1.1 capability-advertise orf ip-prefix both
#
#
return

Routers
9.7.12 Example for Configuring BGP Load Balancing
On the network shown in Figure 9-30, BGP is configured on all routers. RouterA is in AS 100.
RouterB and RouterC are in AS 300. RouterD is in AS 200. Network congestion from RouterA
to destination address 8.1.1.0/24 needs to be relieved and network resources need to be fully
utilized.
Figure 9-30 Networking diagram of configuring BGP load balancing
RouterA AS100
GE1/0/0 GE2/0/0
200.1.1.1/24 200.1.2.1/24
GE1/0/0 GE2/0/0
200.1.1.2/24 200.1.2.2/24
RouterB RouterC
GE2/0/0 AS300 GE1/0/0

200.1.3.2/24 200.1.4.2/24
GE2/0/0 GE1/0/0
200.1.3.1/24 200.1.4.1/24
GE3/0/0
AS200 8.1.1.1/24
RouterD
1. Establish EBGP connections between RouterA and RouterB and between RouterA and
RouterC, between RouterD and RouterB and between RouterD and RouterC to enable ASs
to communicate with each other using BGP.
2. Configuring load balancing on RouterA so that RouterA can send traffic to RouterD through
either RouterB or RouterC.

Routers
Procedure
Step 2 Establish BGP connections.
[RouterA] bgp 100
[RouterA-bgp] quit
[RouterB] bgp 300
[RouterB-bgp] quit
[RouterC] bgp 300
[RouterC-bgp] quit
[RouterD] bgp 200
[RouterD-bgp] ipv4-family unicast
[RouterD-bgp-af-ipv4] network 8.1.1.0 255.255.255.0
[RouterD-bgp-af-ipv4] quit
[RouterD-bgp] quit
# View the routing table of RouterA.


Paths : 2 available, 1 best, 1 select
From: 200.1.1.2 (2.2.2.2)
AS-path 300 200, origin igp, pref-val 0, valid, external, best, select, active,
pre 255
200.1.1.2
200.1.2.2

From: 200.1.2.2 (3.3.3.3)
AS-path 300 200, origin igp, pref-val 0, valid, external, pre 255, not preferred

Routers
for router ID
The preceding command output shows that there are two valid routes from RouterA to
destination 8.1.1.0/24. The route with the next-hop address of 200.1.1.2 is the optimal route
because the router ID of RouterB is smaller.
Step 3 Configure BGP load balancing.
# Configure load balancing on RouterA.
[RouterA] bgp 100
[RouterA-bgp-af-ipv4] maximum load-balancing 2
[RouterA-bgp] quit

# View the routing table of RouterA.

Paths : 2 available, 1 best, 2 select
From: 200.1.1.2 (2.2.2.2)
AS-path 300 200, origin igp, pref-val 0, valid, external, best, select, active,
pre 255
Advertised to such 2 peers
200.1.1.2
200.1.2.2

From: 200.1.2.2 (3.3.3.3)
AS-path 300 200, origin igp, pref-val 0, valid, external, select, active, pre 255,
not preferred for router ID
The preceding command output shows that BGP route 8.1.1.0/24 has two next hops: 200.1.1.2
and 200.1.2.2. Both of them are optimal routes.
----End
Configuration Files
#
sysname RouterA
#
ip address 200.1.1.1 255.255.255.0
#
ip address 200.1.2.1 255.255.255.0
#

Routers
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
maximum load-balancing 2
#
return

#
sysname RouterB
#
ip address 200.1.1.2 255.255.255.0
#
ip address 200.1.3.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 300
router-id 2.2.2.2
#
ipv4-family unicast
#
return

#
sysname RouterC
#
ip address 200.1.4.2 255.255.255.0
#
ip address 200.1.2.2 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 300
router-id 3.3.3.3
#
ipv4-family unicast
#
return

Routers
#
sysname RouterD
#
ip address 200.1.4.1 255.255.255.0
#
ip address 200.1.3.1 255.255.255.0
#
ip address 8.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
network 8.1.1.0 255.255.255.0
#
return
9.7.13 Example for Associating BGP with BFD
As shown in Figure 9-31, RouterA belongs to AS 100, RouterB and RouterC belong to AS 200.
EBGP connections are established between RouterA and RouterB, and between RouterA and
RouterC.
Service traffic is transmitted along the primary link RouterARouterB. The link RouterA
RouterCRouterB functions as the backup link. Fast fault detection is required to allow traffic
to be fast switched from the primary link to the backup link.
Figure 9-31 Networking diagram of configuring BFD for BGP
GE3/0/0
172.16.1.1/24
GE2/0/0
200.1.1.2/24
GE1/0/0 EBGP GE1/0/0

AS 100 RouterB
200.1.1.1/24 9.1.1.1/24
RouterA IBGP
AS 200
GE2/0/0
200.1.2.1/24 EBGP GE1/0/0
9.1.1.2/24
GE2/0/0
200.1.2.2/24 RouterC

Routers
1. Configure basic BGP functions on each router.
2. Configure the MED attribute to control route selection.
3. Enable BFD on RouterA and RouterB.
NOTE
If two routers establish an EBGP peer relationship over a direct link, BFD for BGP does not need to be
configured. This is because the ebgp-interface-sensitive command is enabled by default for directly-
connected EBGP peers.
Procedure
Configure an IP address to each interface as shown in Figure 9-31. For details about the
configuration, see the following configuration files.
Step 2 Configure basic BGP functions. Establish EBGP peer relationships between RouterA and
RouterB, and between RouterA and RouterC and an IBGP peer relationship between RouterB
and RouterC.
[RouterA] bgp 100
[RouterA-bgp] peer 200.1.1.2 ebgp-max-hop
[RouterA-bgp] peer 200.1.2.2 ebgp-max-hop
[RouterA-bgp] quit
[RouterB] bgp 200
[RouterB-bgp] peer 200.1.1.1 ebgp-max-hop
[RouterB-bgp] network 172.16.1.0 255.255.255.0
[RouterB-bgp] quit
[RouterC] bgp 200
[RouterC-bgp] peer 200.1.2.1 ebgp-max-hop
[RouterC-bgp] quit
# Check the status of BGP peer relationships on RouterA. The command output shows that the
BGP peer relationships are in the Established state.
<RouterA> display bgp peer

Routers

200.1.1.2 4 200 2 5 0 00:01:25 Established 0

200.1.2.2 4 200 2 4 0 00:00:55 Established 0
Step 3 Configure the MED attribute.
Set the MED value for the route sent from RouterC or RouterB to RouterA by using a routing
policy.
[RouterB] route-policy 10 permit node 10
[RouterB] bgp 200
[RouterB-bgp] peer 200.1.1.1 route-policy 10 export
[RouterC] route-policy 10 permit node 10
[RouterC-route-policy] apply cost 150
[RouterC-route-policy] quit
[RouterC] bgp 200
[RouterC-bgp] peer 200.1.2.1 route-policy 10 export
# Check BGP routing information on RouterA.



*> 9.1.1.0/24 200.1.2.2 150 0 200?
*> 172.16.1.0/24 200.1.1.2 100 0 200i
* 200.1.2.2 150 0 200i
*> 200.1.2.0 200.1.1.2 100 0 200?
200.1.2.2 150 0 200?
As shown in the BGP routing table, the next-hop address of the route to 172.16.1.0/24 is
200.1.1.2, and service traffic is transmitted on the primary link between RouterA and RouterB.
Step 4 Configure BFD, and set the interval for transmitting BFD packets, the interval for receiving BFD
packets, and the local detection multiplier.
# Enable BFD on RouterA. Set the minimum intervals for transmitting and receiving BFD
packets to 100 ms and the local detection multiplier to 4.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bgp 100
[RouterA-bgp] peer 200.1.1.2 bfd enable
[RouterA-bgp] peer 200.1.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
# Enable BFD on RouterB. Set the minimum intervals for transmitting and receiving BFD
packets to 100 ms and the local detection multiplier to 4.

Routers
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bgp 200
[RouterB-bgp] peer 200.1.1.1 bfd enable
[RouterB-bgp] peer 200.1.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
# Display all BFD sessions on RouterA.

<RouterA> display bgp bfd session all
Local_Address Peer_Address LD/RD Interface
200.1.1.1 200.1.1.2 8201/8201 GigibitEthernet1/0/0
Tx-interval(ms) Rx-interval(ms) Multiplier Session-State
100 100 4 Up
Wtr-interval(m)
0
# Run the shutdown command on GE 2/0/0 of RouterB to simulate a fault on the primary link.
[RouterB-Gigabitethernet2/0/0] shutdown
# Check the BGP routing table on RouterA.



*> 9.1.1.0/24 200.1.2.2 150 0 200?

*> 172.16.1.0/24 200.1.2.2 150 0 200i
200.1.2.0 200.1.2.2 150 0 200?
As shown in the BGP routing table, the backup link of RouterA -> RouterC -> RouterB takes
effect after the primary link fails, and the next-hop address of the route to 172.16.1.0/24 is
200.1.2.2.
----End
Configuration Files
#
sysname RouterA
#
bfd
#
interface Gigabitethernet1/0/0
ip address 200.1.2.1 255.255.255.0
#
ip address 200.1.1.1 255.255.255.0
#
bgp 100
router-id 1.1.1.1
peer 200.1.1.2 ebgp-max-hop 255

Routers
peer 200.1.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier

4
peer 200.1.1.2 bfd enable
#
ipv4-family unicast
#
return

#
sysname RouterB
#
bfd
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
bgp 200
router-id 2.2.2.2
peer 200.1.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier
4
peer 200.1.1.1 bfd enable
#
ipv4-family unicast
network 172.16.1.0 255.255.255.0
peer 9.1.1.2 enable
peer 200.1.1.1 route-policy 10 export
#
route-policy 10 permit node 10
apply cost 100
#
return

#
sysname RouterC
#
bfd
#
ip address 200.1.2.2 255.255.255.0
#
ip address 9.1.1.2 255.255.255.0
#
bgp 200
router-id 3.3.3.3
#

Routers
ipv4-family unicast
import-route direct
peer 9.1.1.1 enable
peer 200.1.2.1 route-policy 10 export
#
route-policy 10 permit node 10
apply cost 150
#
return
9.7.14 Example for Configuring BGP GTSM
As shown in Figure 9-32, Router A belongs to AS 10, and Router B, Router C, and Router D
belong to AS 20. BGP is run in the network and it is required to protect Router B against CPU-
utilization attacks.
Figure 9-32 Figure 1 Networking diagram of configuring BGP GTSM

IBGP
GE1/0/0 RouterB RouterC
GE2/0/0 GE1/0/0
EBGP 10.1.1.2/24 20.1.1.1/24 20.1.1.2/24
RouterA Lo GE2/0/0
Loopback0 3. op 20.1.2.1/24
GE1/0/0 3. ba IBGP
2.2.2.9/32 3. c
10.1.1.1/24 IB 9/ k0
GP 32 GE1/0/0
AS10
20.1.2.2/24
PC RouterD
AS20
Loopback0
4.4.4.9/32
1. Configure OSPF on Router B, Router C, and Router D to implement interworking in AS

20.
2. Set up an EBGP connection between Router A and Router B, and set up IBGP connections
between Router B, Router C, and Router D through loopback interfaces.
3. Configure GTSM on Router A, Router B, Router C, and Router D so that it can protect
Router B against CPU-utilization attacks.
Procedure
Step 1 Configure an IP address to each interface. The configuration details are not mentioned here.

Routers
Step 2 Configure OSPF. The configuration details are not mentioned here.
Step 3 Configure an IBGP connection.
[RouterB] bgp 20
[RouterB-bgp] peer 3.3.3.9 connect-interface LoopBack0
[RouterB-bgp] peer 3.3.3.9 next-hop-local
[RouterB-bgp] peer 4.4.4.9 connect-interface LoopBack0
[RouterB-bgp] peer 4.4.4.9 next-hop-local
[RouterC] bgp 20
[RouterC-bgp] peer 2.2.2.9 connect-interface LoopBack0
[RouterC-bgp] peer 4.4.4.9 connect-interface LoopBack0
[RouterD] bgp 20
[RouterD-bgp] peer 2.2.2.9 connect-interface LoopBack0
[RouterD-bgp] peer 3.3.3.9 connect-interface LoopBack0
Step 4 Configure an EBGP connection.

[RouterA] bgp 10
# Display the connection status of the BGP peers.

[RouterB-bgp] display bgp peer
3.3.3.9 4 20 8 7 0 00:05:06 Established 0

4.4.4.9 4 20 8 10 0 00:05:33 Established 0
10.1.1.1 4 10 7 7 0 00:04:09 Established 0
You can view that Router B has set up BGP connections with other routers.
Step 5 Configure GTSM on Router A and Router B. Router A and Router B are directly connected, so
the range of the TTL value between the two routers is [255, 255]. The value of valid-ttl-hops
is 1.
# Configure GTSM on Router A.
[RouterA-bgp] peer 10.1.1.2 valid-ttl-hops 1

Routers
# Configure GTSM of the EBGP connection on Router B.

[RouterB-bgp] peer 10.1.1.1 valid-ttl-hops 1
# Check the GTSM configuration.

[RouterB-bgp] display bgp peer 10.1.1.1 verbose
Type: EBGP link
Update-group ID : 2
BGP current event: RecvKeepalive
Update messages 0
Open messages 2
Refresh messages 0
Update messages 5
Open messages 2
Refresh messages 0
Last update sent : 2011/09/25 16:11:32
GTSM has been enabled, valid-ttl-hops: 1
No routing policy is configured
You can view that GTSM is enabled, the valid hop count is 1, and the BGP connection is in the
Established state.
Step 6 Configure GTSM on Router B and Router C. Router B and Router C are directly connected, so
is 1.
# Configure GTSM on Router B.
# Configure GTSM of the IBGP connection on Router C.

Routers
[RouterC-bgp] peer 2.2.2.9 valid-ttl-hops 1
# View the GTSM configuration.

Type: IBGP link
Update-group ID : 0
Update messages 0
Open messages 1
Refresh messages 0
Update messages 10
Open messages 1
Refresh messages 0
Last update sent : 2011/09/25 16:11:32
Nexthop self has been configured
Connect-interface has been configured
Established state.
Step 7 Configure GTSM on Router C and Router D. Router C and Router D are directly connected, so
is 1.
# Configure GTSM of the IBGP connection on Router C.
[RouterC-bgp] peer 4.4.4.9 valid-ttl-hops 1
# Configure GTSM of the IBGP connection on Router D.

Routers
[RouterD-bgp] peer 3.3.3.9 valid-ttl-hops 1

[RouterC-bgp] display bgp peer 4.4.4.9 verbose
Type: IBGP link
Update-group ID : 1
Update messages 0
Open messages 1
Refresh messages 0
Update messages 0
Open messages 2
Refresh messages 0
Last update sent : 2011/09/25 16:11:32
Established state.
Step 8 Configure GTSM on Router B and Router D. Router B and Router D are connected by Router
C, so the range of the TTL value between the two routers is [254, 255]. The value of valid-ttl-
hops is 2.
# Configure GTSM of the IBGP connection on Router B.

# Configure GTSM on Router D.

Routers
[RouterD-bgp] peer 2.2.2.9 valid-ttl-hops 2

Type: IBGP link
Update-group ID : 0
BGP current event: RecvKeepalive
Update messages 0
Open messages 1
Refresh messages 0
Update messages 10
Open messages 1
Refresh messages 0
Last update sent : 2011/09/25 16:11:32
Nexthop self has been configured
You can view that GTSM is configured, the valid hop count is 2, and the BGP connection is in
the Established state.
NOTE
l In this example, if the value of valid-ttl-hops of either Router B or Router D is smaller than 2, the
IBGP connection cannot be set up.
l GTSM must be configured on the two ends of the BGP connection.

Routers
# Run the display gtsm statistics all command on Router B to check the GTSM statistics of
Router B. By default, Router B does not discard any packet when all packets match the GTSM
policy.
[RouterB-bgp] display gtsm statistics all
GTSM Statistics Table
----------------------------------------------------------------
SlotId Protocol Total Counters Drop Counters Pass Counters
----------------------------------------------------------------
0 BGP 17 0 17
0 BGPv6 0 0 0
0 OSPF 0 0 0
0 LDP 0 0 0
1 BGP 0 0 0
1 BGPv6 0 0 0
1 OSPF 0 0 0
1 LDP 0 0 0
2 BGP 0 0 0
2 BGPv6 0 0 0
2 OSPF 0 0 0
2 LDP 0 0 0
3 BGP 0 0 0
3 BGPv6 0 0 0
3 OSPF 0 0 0
3 LDP 0 0 0
4 BGP 32 0 32
4 BGPv6 0 0 0
4 OSPF 0 0 0
4 LDP 0 0 0
5 BGP 0 0 0
5 BGPv6 0 0 0
5 OSPF 0 0 0
5 LDP 0 0 0
7 BGP 0 0 0
7 BGPv6 0 0 0
7 OSPF 0 0 0
7 LDP 0 0 0
----------------------------------------------------------------
If the host simulates the BGP packets of Router A to attack Router B, the packets are discarded
because their TTL value is not 255 when reaching Router B. In the GTSM statistics of Router
B, the number of dropped packets increases accordingly.
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
bgp 10
router-id 1.1.1.9
peer 10.1.1.2 valid-ttl-hops 1
#
ipv4-family unicast
#
return

Routers

#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
ip address 20.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
#
bgp 20
router-id 2.2.2.9
peer 3.3.3.9 connect-interface LoopBack0
#
ipv4-family unicast
peer 3.3.3.9 enable
peer 4.4.4.9 enable
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return

#
sysname RouterC
#
ip address 20.1.1.2 255.255.255.0
#
ip address 20.1.2.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
#
bgp 20
router-id 3.3.3.9
#
ipv4-family unicast
peer 2.2.2.9 enable
peer 4.4.4.9 enable
#
ospf 1

Routers
area 0.0.0.0
network 20.1.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return

#
sysname RouterD
#
ip address 20.1.2.2 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
#
bgp 20
router-id 4.4.4.9
#
ipv4-family unicast
peer 2.2.2.9 enable
peer 3.3.3.9 enable
#
ospf 1
area 0.0.0.0
network 20.1.2.0 0.0.0.255
network 4.4.4.9 0.0.0.0
#
return
9.8 FAQ
9.8.1 Why Are Loopback Addresses Used to Establish BGP Peer

Relationships?
Loopback interfaces are logical interfaces. Compared with physical interfaces, loopback
interfaces are not affected by links and can reduce the Border Gateway Protocol (BGP) flapping.
9.8.2 Why Is the BGP Connection Not Interrupted Immediately

After the Interfaces Connecting Two Peers Are Shut Down?
When External Border Gateway Protocol (EBGP) peers are directly connected and the ebgp-
interface-sensitive command is run in the Border Gateway Protocol (BGP) view, the BGP peer
relationship is interrupted immediately after the interfaces connecting the two peers are shut
down. By default, the ebgp-interface-sensitive command is run in the BGP view. In other cases,
the BGP peer relationship is not interrupted until the Hold timer times out.

Routers
9.8.3 Why Are All the Next Hop Addresses in the BGP Routing
Table Displayed as 0.0.0.0 After BGP Imports Routes from Other
Protocols?
Only routes that exist in the Border Gateway Protocol (BGP) routing table can be imported by
the BGP. When importing such routes, BGP does not add new routes, but increases the reference
count based on the routing table.
9.9 References
This section lists RFC documents related to BGP.
Table 9-6 lists the references of this feature.
Table 9-6 References
RFC 827 Exterior Gateway Protocol (EGP) -
RFC 1997 BGP Communities Attribute -
RFC 2439 BGP Route Flap Damping -
RFC 2918 Route Refresh Capability for BGP-4 -
RFC 3065 Autonomous System Confederations for BGP -
RFC 3232 Assigned Numbers: RFC 1700 is Replaced by an On-line -

Database
RFC 3392 Capabilities Advertisement with BGP-4 -
RFC 3682 The Generalized TTL Security Mechanism (GTSM) -
RFC 4271 A Border Gateway Protocol 4 (BGP-4) -
RFC 4456 BGP Route Reflection -
RFC 4486 Subcodes for BGP Cease Notification Message -
RFC 4724 Graceful Restart Mechanism for BGP -
RFC 4760 Multiprotocol Extensions for BGP-4 -
RFC 4893 BGP Support for Four-octet AS Number Space -
draft-rijsman- BFD Down Subcode for BGP Cease Notification Message -

bfd-down-
subcode-00

Routers
Configuration Guide - IP Routing 10 Routing Policy Configuration
10 Routing Policy Configuration
About This Chapter
Routing policies are applied to routing information to change the path through which network
traffic passes.
10.1 Introduction to Routing Policy

This section defines routing policies and describes their purpose and functions.
10.2 Principle
This section describes implementation of routing policies.
10.3 Usage Scenario

This section describes usage scenarios of routing policies.

After routing policies are configured, apply them only when using routing protocols to advertise,
receive, or import routes to implement the route filtering and attribute configuration functions.
10.5 Configuring Routing Policies

This section describes how to configure routing policies.
10.6 Maintaining the Routing Policy

Maintaining routing policies involves clearing the statistics of the IP prefix list.

The configuration examples in this section explain the networking requirements, networking
diagram, configuration notes, configuration roadmap, and configuration procedure for different
types of routing policies.
10.8 References
This section lists RFC documents related to routing policies.

Routers
10.1 Introduction to Routing Policy

This section defines routing policies and describes their purpose and functions.
Definition
Routing policies are used to filter routes and set attributes for routes. By changing route attributes
(including reachability), a route policy changes the path that network traffic passes through.
Purpose
When advertising, receiving, and importing routes, routing protocols implement certain policies
based on actual networking requirements to filter routes and change the attributes of the routes.
Routing policies serve the following purposes:
l To control route receiving and advertising

Only the required and valid routes are received or advertised. This reduces the size of the
routing table and improves network security.
l To control route importing
A routing protocol may import routes discovered by other routing protocols. Only routes
that satisfy certain conditions are imported to meet the requirements of the protocol.
l To modify attributes of specified routes
Attributes of the routes that are filtered by a routing policy are modified to meet the
requirements of the local device.
Benefits
This feature brings the following benefits:
l Controls the size of the routing table, saving system resources.
l Controls route receiving, advertising and importing, improving network security.
l Modifies attributes of routes for proper traffic planning, improving network performance.
10.2 Principle
This section describes implementation of routing policies.
A routing policy uses different matching rules and modes to select routes and change route
attributes. Six filters in the routing policy can be used independently to filter routes in special
scenarios. If the device supports the BGP to IGP function, the private attributes of BGP can
serve as matching rules when the IGP imports BGP routes.

Routers
Routing Policy Principle
Figure 10-1 Working mechanism of the routing policy
Routing
policy
Succeed in
If match matching all Apply
clauses. Matching Permit Passing the
Node 1 If match Apply
mode routing policy

Fail to match Deny
a clause. Denied

Succeed in
matching all
If match Matching Permit Apply
clauses. Passing the
Node N If match mode Apply
routing policy

Fail to match
Deny
a clause. Denied
Denied
As shown in Figure 10-1, a routing policy consists of N nodes (N 1). The system checks
routes in the nodes of a routing policy with the node ID in ascending order. The If-match clauses
define matching rules related to route attributes and six filters.
When a route matches all If-match clauses in a node, the route enters the matching mode without
being checked in other nodes. The following two matching modes are supported:
l permit: A route is permitted, and actions defined by the Apply clauses are performed on
the route to set its attributes.
l deny: A route is denied.
If a route does not match one If-match clause in a node, the route enters to the next node. If a
route does not match any one of the nodes, the route is filtered out.
Filters
The six filters specified in If-match clauses in a routing policy are access control list (ACL), IP
prefix list, AS_Path filter, community filter, extended community filter, and RD filter. The six
filters have their own matching rules and modes. Therefore, they can be used independently to
filter routes in some special situations.
ACL
ACLs check inbound interface, source or destination IP address, source or destination port
number, and protocol of packets to filter routes. ACLs can be used independently when routing
protocols advertise and receive routes. The If-match clauses in a routing policy support only
basic ACLs.

Routers
ACLs can be used in not only a routing policy but other scenarios. For details, see "Principles"
in the Configuration Guide - Security - ACL Configuration.
IP prefix list
IP prefix lists check IP prefixes of the source IP address, destination IP address, and next hop
address to filter routes. They can be used independently when routing protocols advertise and
receive routes.
Each IP prefix list consists of multiple indexes, and each index matches a node. An IP prefix list
checks routes in all nodes with the indexes in ascending order. If a route matches one node, the
route is no longer checked by other nodes. If a route does not match any one of the nodes, the
route is filtered out.
The IP prefix list supports exact matching or matching within a specified mask length.
NOTE
When the IP address is 0.0.0.0, a wildcard address, all routes in the mask length range are permitted or
denied.
AS_Path filter
The AS_Path filter uses the AS_Path attribute of BGP to filter routes. It can be used
independently when BGP advertises and receives routes.
The AS_Path attribute records all ASs that a route passes through. For details about the AS_Path
attribute, see "Principles - BGP Concepts" in the Configuration Guide - IP Routing - BGP
Configuration.
Community filter
The community filter uses the community attribute of BGP to filter routes. It can be used
independently when BGP advertises and receives routes.
The community attribute identifies a group of routes with the same properties. For details about
the community attribute, see "Principles - BGP Concepts" in the Configuration Guide - IP
Routing - BGP Configuration.
Extcommunity Filter
The extended community filter uses the extended community attribute of BGP to filter routes.
It can be used independently when VPN targets are used to identify routes in a VPN.
Currently, the extended community filter applies only to the VPN target attribute in a VPN. On
a BGP/MPLS IP VPN, VPN targets are used to control the advertising and receiving of VPN
routing information between sites. For details about the VPN target attribute, see "Principles -
Concepts" in the Configuration Guide - VPN - BGP MPLS IP VPN Configuration.
Route Distinguisher (RD) filter
The RD filter uses the RD attribute in a VPN to filter routes. It can be used independently when
the RD attribute is used to identify routes in a VPN.
A VPN instance uses RDs to separate address spaces and distinguish the IP prefixes with the
same address space. For details about the RD attribute, see "Principles - Concepts" in the
Configuration Guide - VPN - BGP MPLS IP VPN Configuration.

Routers
BGP to IGP function

The BGP to IGP function enables IGP to identify private attributes of BGP such as the
community, extended community, and AS-Path attributes.
Routing policies can be used when an IGP imports BGP routes. BGP private attributes can be
used as matching rules in routing policies only when the device supports the BGP to IGP
function. When the device does not support the BGP to IGP function, the IGP cannot identify
private attributes of BGP routes. Therefore, the matching rule does not take effect.
10.3 Usage Scenario

This section describes usage scenarios of routing policies.
Specific Routes Filtering

On the OSPF-enabled network shown in Figure 10-2, RouterA receives routes from the Internet
and advertises some of the routes to RouterB.
l RouterA advertises only routes 172.1.17.0/24, 172.1.18.0/24, and 172.1.19.0/24 to

RouterB.
l RouterC accepts only the route 172.1.18.0/24.
l RouterD accepts all the routes advertised by RouterB.
Figure 10-2 Networking diagram for filtering received and advertised routes
RouterC
Internet
OSPF
172.1.16.0/24
172.1.17.0/24
172.1.18.0/24
172.1.19.0/24
RouterB RouterA 172.1.20.0/24
RouterD
There are multiple approaches to meet the preceding requirements, and the following two
approaches are used in this example:
l Use IP prefix lists
Configure an IP prefix list on RouterA and configure the IP prefix list as an export policy
of RouterA to be used by OSPF.
Configure another IP prefix list on RouterC and configure the IP prefix list as an import
policy of RouterC to be used by OSPF.
l Use route-policies

Routers
Configure a Route-Policy (the matching rules can be the IP prefix list, cost, or route
tag) on RouterA and configure the Route-Policy as an export policy of RouterA to be
used by OSPF.
Configure another Route-Policy on RouterC and configure the Route-Policy as an
import policy of RouterC to be used by OSPF.
Compared with an IP prefix list, a Route-Policy allows route attributes to be modified and
can be used to control routes more flexibly, but it is more complex to configure.
Transparent Transmission of Routes of Other Protocols Through an OSPF AS

On the network shown in Figure 10-3, an AS runs OSPF and functions as a transit AS for other
areas. Routes from the IS-IS area connected to RouterA need to be transparently transmitted
through the OSPF AS to the IS-IS area connected to RouterD.
Figure 10-3 Networking diagram for transparently transmitting routes of other protocols through
an OSPF AS
RouterA RouterB
RIP-2
IS-IS
OSPF
RIP-2
IS-IS
RouterC RouterD
To meet the preceding requirements, configure a Route-Policy on RouterA to set a tag for the
imported IS-IS routes. RouterD identifies the IS-IS routes from OSPF routes based on the tag.
Routing Policy Application in Inter-AS VPN Option C

On the network shown in Figure 10-4, CE1 and CE2 communicate with each other through
inter-AS VPN Option C.

Routers
Figure 10-4 Networking diagram for implementing route-policies in the inter-AS VPN Option
C scenario
VPN Backbone VPN Backbone

AS 65001 AS 65002
EBGP
MP-IBGP MP-IBGP
PE1 ASBR1 ASBR2 PE2
Multi-hop MP-EBGP
LSP
CE1 CE2
To establish an inter-AS LSP between PE1 and PE2, route-policies need to be configured on
ASBRs.
l When an ASBR advertises the routes received from a PE in the same AS to the peer ASBR,
the ASBR allocates MPLS labels to the routes using a Route-Policy.
l When an ASBR advertises labeled IPv4 routes to a PE in the same AS, the ASBR reallocates
MPLS labels to the routes using another Route-Policy.
In addition, to control route transmission between different VPN instances on a PE, configure
a Route-Policy on the PE and configure the Route-Policy as an import or export policy on the
VPN instances.

After routing policies are configured, apply them only when using routing protocols to advertise,
receive, or import routes to implement the route filtering and attribute configuration functions.
Table 10-1 describes the routing policy configuration tasks.

Routers
Table 10-1 Routing policy configuration tasks
Configuring the filter Routing policy filters 10.5.1 Filter Configuration

include: ACLs, IP prefix
lists, AS path filters,
community filters, extended
community filters, and RD
filters. The routing policy
filters not only can apply to
the if-match clause of a
routing policy, but also can
be used separately in specific
situations.
Configure routing policies To reduce network burden 10.5.2 Configuring a

and ensure network security, Routing Policy
apply the routing policies
with if-match clauses in the
following situations:
l Importing routes
l Advertising and receiving
routes
l Filtering using the RT and
RD attributes in the VPN

Routers
Configuring the validity time In practical applications, 10.5.3 Controlling the Valid
of a routing policy when multiple cooperative Time of the Routing policy
configurations of a routing
policy change, the Routing
Management (RM) module
immediately informs the
protocols to re-apply the
routing policy after a
configuration is complete. In
this case, incomplete routing
policies will cause route
flapping, resulting in
network instability.
The processing rules for
routing policy changes are as
follows:
l By default, if a routing
policy changes, the RM
module immediately
informs the protocols to
apply a new routing
policy.
l If the validity time of a
routing policy is
configured, the RM
module does not
immediately inform the
protocols to process the
changes when the related
command configurations
of the routing policy
change. Instead, routing
protocols wait for a
specified period and then
apply a new routing
policy.
l If the configuration of the
routing policy changes
again during the waiting
time, the RM module
resets the timer.
You can run the route-
policy-change notify-delay
command to set the delay
time based on the site
requirements.

Routers
10.5 Configuring Routing Policies

This section describes how to configure routing policies.
10.5.1 Filter Configuration

Filters in a routing policy include ACL, IP prefix list, AS_Path filter, community filter, extended
community filter, and RD filter. This section describes the configuration of IP prefix list,
AS_Path filter, community filter, extended community filter, and RD filter. For details about
ACL configuration, see "ACL Configuration" in the Huawei AR150&200&1200&2200&3200
Series Enterprise Routers -Configuration Guide - Security.
Before configuring filters, complete the following task:
l Configuring routing protocols
Configure the filters in any sequence based on the network requirements.
10.5.1.1 Configuring an IP Prefix List
Context
To control the advertising and receiving of routes based on the destination address, configure
an IP prefix list.
NOTICE
If an IP prefix list is not used together with the if-match clauses in a routing policy, you must
set at least one node to the permit mode in the IP prefix list. If no node is set to the permit
mode, all routes are filtered out.
Procedure
Step 1 Configure an IPv4 prefix list.
1. Run:
system-view

2. Run:
ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ip-
address mask-length [ greater-equal greater-equal-value ] [ less-equal less-
equal-value ]

Routers
An IPv4 prefix list is configured.
Step 2 Configure an IPv6 prefix list.

1. Run:
system-view

2. Run:
ip ipv6-prefix ipv6-prefix-name [ index index-number ] { permit | deny } ipv6-
address prefix-length [ greater-equal greater-equal-value ] [ less-equal less-
equal-value ]
An IPv6 prefix list is configured.
----End

l Run the display ip ip-prefix [ ip-prefix-name ] command to check information about the
IPv4 prefix list.
l Run the display ip ipv6-prefix [ ipv6-prefix-name ] command to check information about
the IPv6 prefix list.
10.5.1.2 Configuring an AS_Path Filter
Context
An AS_Path filter is used to filter routes based on the AS_Path attributes of BGP routes. If you
do not want to receive routes of a specified AS number, configure an AS_Path filter based on
the AS number. On a complex network, multiple ACLs or IP prefix lists must be configured to
filter BGP routes, which is complicated. Configuring an AS_Path filter simplifies the
configuration.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip as-path-filter { as-path-filter-number | as-path-filter-name } { permit | deny }
regular-expression
An AS_Path filter is configured.
In the preceding command, regular-expression the regular expression that the AS_Path filter
uses to define a matching rule. For details about a regular expression, see "CLI Overview" in
the Huawei AR150&200&1200&2200&3200 Seriesrouter - Configuration Guide - Basic
Configuration.
----End

Routers

l Run the display ip as-path-filter [ as-path-filter-number | as-path-filter-name ] command
to check information about a configured AS_Path filter.
10.5.1.3 Configuring a Community Filter
Context
The community attribute identifies routes with the same characteristics without considering a
few IP prefixes and numerous AS numbers. Configuring community filters and community
attributes simplifies route management when it is inconvenient to use IP prefix list or AS_Path
filter. For example, a company branch needs to receive only routes from its headquarters and
branches in adjacent countries. In this case, you can configure different community attributes
for the branches. Routes in this branch can then be managed based on community attributes,
without considering a few IP prefixes and numerous AS numbers of routes in different countries.
Community filters are classified into basic and advanced community filters. Compared with a
basic community filter, an advanced community filter supports regular expressions and is more
flexible.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip community-filter
A community filter is configured.
l To configure a basic community filter, run the ip community-filter { basic comm-filter-

name | basic-comm-filter-num } { permit | deny } [ community-number | aa:nn | internet |
no-export-subconfed | no-advertise | no-export ] &<1-20> command.
l To configure an advanced community filter, run the ip community-filter { advanced comm-
filter-name | adv-comm-filter-num } { permit | deny } regular-expression command.
In the preceding command, regular-expression indicates that the AS_Path filter uses a regular
expression to define matching rules. For details about a regular expression, see "CLI Overview"
in the Huawei AR150&200&1200&2200&3200 Seriesrouter - Configuration Guide - Basic
Configuration.
----End

l Run the display ip community-filter [ basic-comm-filter-num | adv-comm-filter-num |
comm-filter-name ] command to check information about a configured community filter.

Routers
10.5.1.4 Configuring an Extended Community Filter
Context
You can use an extended community filter when using the route target (RT) attribute to filter
routes in a VPN scenario.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip extcommunity-filter { basic-extcomm-filter-num | basic basic-extcomm-filter-
name } { deny | permit } { rt { as-number:nn | 4as-number:nn | ipv4-address:nn } }
&<1-16>
or
ip extcommunity-filter { advanced-extcomm-filter-num | advanced advanced-extcomm-
filter-name } { deny | permit } regular-expression
An extended community filter is configured.
----End

Run the display ip extcommunity-filter [ extcomm-filter-number | extcomm-filter-name ]
command to check information about a configured extended community filter.
10.5.1.5 Configuring an RD Filter
Context
You can use an RD filter when using the RD attribute to filter routes in a VPN.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip rd-filter rd-filter-number { deny | permit } route-distinguisher &<1-10>
An RD filter is configured.
----End

Routers

l Run the display ip rd-filter [ rd-filter-number ] command to check information about a
configured RD filter.
10.5.2 Configuring a Routing Policy

Each node of a routing policy can comprise a set of if-match and apply clauses.
Before configuring a routing policy, complete the following task:
l Configuring routing protocols
Before configuring the if-match and apply clauses, you must configure a routing policy. You
can configure the if-match and apply clauses in any sequence based on the network requirements.
10.5.2.1 Creating a Routing Policy
Context
A routing policy can consist of multiple matching rules and actions.
NOTICE
You must set at least one node to the permit mode in a routing policy; otherwise, all routes are
filtered out.
Procedure
Step 1 Run:
system-view

Step 2 Run:
route-policy route-policy-name { permit | deny } node node
A routing policy is created, and the routing policy view is displayed.

A routing policy starts route selection from the lowest node ID. If a route matches a node in the
routing policy, the system does not match it with other nodes. If a route fails to match all the
nodes in the routing policy, the route is filtered out.
description text
The description of the routing policy is configured.
----End

Routers
10.5.2.2 (Optional) Configuring an if-match Clause
Context
An if-match clause defines matching rules related to route filters and attributes in a routing
policy.
If no if-match clause is configured for a node in a routing policy, all routes match in this node.
If one or more if-match clauses are configured in a node, the relationship between the clauses
is "AND". This means that routes match this node only when they match all the if-match clauses
in this node. When multiple if-match as-path-filter, if-match community-filter, if-match
extcommunity-filter, if-match interface, or if-match route-type clauses are configured, the
relationship between the clauses is "OR". The relationship of the five clauses is "AND", and the
relationship between the five clauses and other clauses is also "AND". If multiple if-match as-
path-filter clauses are configured in a node, the relationship of these clauses is "OR", and the
relationship between these clauses and other if-match clauses is "AND".
NOTE
If an if-match clause defines a filter that is not configured, all routes match this if-match clause by default.
The if-match acl and if-match ip-prefix commands cannot be used together in the same node. When both
the commands are used in a node, the later configured one overrides the previous one.
NOTICE
When modifying the configurations of cooperative routing policies with multiple if-match
clauses, it is recommended that you perform the configuration task of 10.5.3 Controlling the
Valid Time of the Routing policy. Otherwise, an incomplete routing policy will cause route
flapping.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The routing policy view is displayed.
Step 3 Configure if-match clauses in any sequence for a routing policy based on the network
requirements.
l Run:
if-match acl { acl-number | acl-name }
An if-match clause is configured to match the basic ACL.

l Run:
if-match as-path-filter { as-path-filter-number &<1-16> | as-path-filter-name }

Routers
An if-match clause is configured to match AS_Path filters.

l Run either of the following commands as required to configure an if-match clause based on
community filters:
if-match community-filter { basic-comm-filter-num [ whole-match ] | adv-comm-filter-
num } &<1-16>
if-match community-filter comm-filter-name [ whole-match ]
l Run:
if-match extcommunity-filter { { basic-extcomm-filter-num | adv-extcomm-filter-
num } &<1-16> | extcomm-filter-name }
An if-match clause is configured to match extended community filters.

l Run:
if-match cost cost
An if-match clause is configured to match the route cost of routes.

l Run:
if-match interface { interface-type interface-number } &<1-16>
An if-match clause is configured to match the outbound interface of routes.

l Run:
if-match ip { next-hop | route-source | group-address } { acl { acl-number | acl-
name } | ip-prefix ip-prefix-name }
An if-match clause is configured to match the next hop or source address of IPv4 routes.
l Run:
if-match ipv6 { address | next-hop | route-source } prefix-list ipv6-prefix-name
An if-match clause is configured to match the destination address, next hop, or source address
of IPv6 routes.
l Run:
if-match ip-prefix ip-prefix-name
An if-match clause is configured to match the IP prefix list.

l Run:
if-match mpls-label
An if-match clause is configured to match the MPLS label of routes.

l Run:
if-match rd-filter rd-filter-number
An if-match clause is configured to match the RD filter.

l Run any of the following command as required to match the type of route:
Run:
if-match route-type { external-type1 | external-type1or2 | external-type2 |
internal | nssa-external-type1 | nssa-external-type1or2 | nssa-external-
type2 }
An if-match clause is configured to match a specified type of OSPF routes.

Run:
if-match route-type { is-is-level-1 | is-is-level-2 }
An if-match clause is configured to match a specified type of IS-IS routes.

l Run:
if-match tag tag

Routers
An if-match clause is configured to match the tag of routes.
----End
10.5.2.3 (Optional) Configuring an apply Clause
Context
An apply clause specifies the action of setting attributes for routes matching a routing policy
node. If a node is not configured with an apply clause, the node only filters routs. If one or more
apply clauses are configured in a node, all the apply clauses are applied to routes that match
the node.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The route-policy view is displayed.
Step 3 Run any of the following commands as required to configure apply clauses, the commands are
not listed in sequence. A node can have multiple or no apply clauses.
l Run:
apply as-path { { as-number-plain | as-number-dot } &<1-10> { additive |
overwrite } | none overwrite }
An apply clause is configured to change the AS_Path attribute of BGP routes.

l Run:
apply backup-interface interface-type interface-number
An apply clause is configured to change the backup outbound interface of routes.

l Run:
apply backup-nexthop { ip-address | auto }
An apply clause is configured to change the backup next hop of routes.

l Run:
apply comm-filter { basic-comm-filter-number | adv-comm-filter-number | comm-
filter-name } delete
An apply clause is configured to delete the specified community attribute of BGP routes.
NOTE
To delete the community attributes, you can run the ip community-filter command several times to
configure community attributes one by one, and apply the routing policy containing the apply comm-
filter delete command to delete these community attributes. If multiple community attributes are
specified in one community filter, none of them can be deleted.
l Run:
apply community none
An apply clause is configured to delete all community attributes of BGP routes.

Routers
l Run:
apply community { community-number | aa:nn | internet | no-advertise | no-
export | no-export-subconfed } &<1-32> [ additive ]
An apply clause is configured to set the community attributes of BGP routes.

l Run:
apply cost [ + | - ] cost
The route cost is set.

l Run the following command as required to set the cost type of a route:
Run:
apply cost-type { external | internal }
The IS-IS cost type is set.

Run:
apply cost-type { type-1 | type-2 }
The OSPF cost type is set.

l Run:
apply dampening half-life-reach reuse suppress ceiling
The dampening parameters of EBGP routes are set.

l Run:
apply extcommunity { rt { as-number:nn | 4as-number:nn | ipv4-address:nn } }
&<1-16> [ additive ]
An extended community attribute (route-target) of BGP is set.

l Run:
apply ip-address next-hop { ipv4-address | peer-address }
The next-hop address of the IPv4 route is set.

l Run:
apply ipv6 next-hop { peer-address | ipv6-address }
The next-hop address of the IPv6 route is set.

l Run:
apply isis { level-1 | level-1-2 | level-2 }
The level of the IS-IS route is set.

l Run:
apply local-preference preference
The local preference for BGP routes is set.

l Run:
apply mpls-lablel
The MPLS label is set.

l Run:
apply origin { egp { as-number-plain | as-number-dot } | igp | incomplete }
The Origin attribute of BGP routes is set.

l Run:
apply ospf { backbone | stub-area }
An OSPF area into which routes are imported is set.

Routers
l Run:
apply preference preference
The preference of the routing protocol is set.

l Run:
apply preferred-value preferred-value
A preferred value is set for BGP routes.

l Run:
apply tag tag
The route tag is set.
----End
Procedure
l Run the display route-policy [ route-policy-name ] command to check information about
the Route-Policy.
----End
10.5.3 Controlling the Valid Time of the Routing policy

To ensure network stability, you need to configure the delay for applying a routing policy when
modifying the routing policy.
None
Procedure
Step 1 Run:
system-view
Step 2 Run:
route-policy-change notify-delay delay-time
The delay for applying the routing policy is set.
The delay ranges from 1 to 180, in seconds.
By default, the RM immediately notifies the protocol of applying the new policy when the routing
policy changes.
Step 3 Run:
quit
Back to the user view.

Routers
refresh bgp all { export | import }
BGP is configured to apply the new routing policy.

After the command is used, policy filtering is immediately effective. You can run the command
to configure BGP to immediately apply new policies.
The polices affected by the timer are ACLs, IP prefix lists, AS-Path filters, community filters,
extended community filters, RD filters, and Route-Policies.
----End

l Run the display current-configuration | include notify-delay command to check the
delay for applying the routing policy.
10.6 Maintaining the Routing Policy

Maintaining routing policies involves clearing the statistics of the IP prefix list.
Context
NOTICE
The statistics of IP prefix lists cannot be restored after being cleared. Exercise caution when
running this command.
Procedure
l Run reset ip ip-prefix [ ip-prefix-name ] command in the user view to clear the IPv4 prefix
list statistics.
l Run reset ip ipv6-prefix [ ipv6-prefix-name ] command in the user view to clear the IPv6
prefix list statistics.
----End

The configuration examples in this section explain the networking requirements, networking
diagram, configuration notes, configuration roadmap, and configuration procedure for different
types of routing policies.
10.7.1 Example for Filtering Received and Advertised Routes

As shown in Figure 10-5, on the network where OSPF runs, Router A receives routes from the
Internet, and provides these routes for the OSPF network. Users want devices on the OSPF

Routers
network to access only the network segments 172.1.17.0/24, 172.1.18.0/24, and 172.1.19.0/24,
and Router C to access only the network segment 172.1.18.0/24.
Figure 10-5 Networking diagram for filtering received and advertised routes
RouterC
GE3/0/0
192.168.2.1/24 172.1.16.0/24
GE1/0/0 172.1.17.0/24
192.168.2.2/24 GE1/0/0
192.168.1.2/24 172.1.18.0/24
GE1/0/0 172.1.19.0/24
GE1/0/0
192.168.3.2/24 RouterB 172.1.20.0/24
192.168.1.1/24
GE2/0/0 RouterA
192.168.3.1/24
RouterD OSPF
1. Configure a routing policy on Router A and apply the routing policy during route
advertisement. When routes are advertised, the routing policy allows Router A to provide
routes from network segments 172.1.17.0/24, 172.1.18.0/24, and 172.1.19.0/24 for
Router B, and allows devices on the OSPF network to access these three network segments.
2. Configure a routing policy on Router C and apply the routing policy during route importing.
When routes are imported, the routing policy allows Router C to receive only the routes
from the network segment 172.1.18.0/24 and access this network segment.
Procedure
Step 1 Assign an IP address to each interface.
[RouterA] ospf
[RouterB] ospf

Routers
[RouterC] ospf
[RouterD] ospf
Step 3 Configure five static routes on Router A and import these routes to OSPF.
[RouterA] ip route-static 172.1.16.0 24 NULL 0
[RouterA] ospf
[RouterA-ospf-1] import-route static
# Check the IP routing table on Router B. You can view that the five static routes are imported
to OSPF.
[RouterB] display ip routing-table
------------------------------------------------------------------------------
172.1.16.0/24 O_ASE 150 1 D 192.168.1.1 GigabitEthernet1/0/0
Step 4 Configure the policy for advertising routes.

# Configure the IP prefix list named a2b on Router A.
[RouterA] ip ip-prefix a2b index 10 permit 172.1.17.0 24
# Configure the policy for advertising routes on Router A and use the IP prefix list named a2b
to filter routes.
[RouterA] ospf
[RouterA-ospf-1] filter-policy ip-prefix a2b export static
# Check IP routing table on Router B, and you can view the three routes received by Router B
from a2b.

Routers
[RouterB] display ip routing-table

------------------------------------------------------------------------------
Step 5 Configure the policy for receiving routes.

# Configure the IP prefix list named in on Router C.
[RouterC] ip ip-prefix in index 10 permit 172.1.18.0 24
# Configure the policy for receiving routes on Router C, and use IP prefix list named in to filter
routes.
[RouterC] ospf
[RouterC-ospf-1] filter-policy ip-prefix in import
# Check the IP routing table on Router C, and you can find that Router C in the local core routing
table receives only one route from the IP prefix list named in.
------------------------------------------------------------------------------
# Check the IP routing table on Router D, and you can find that Router D in the local core routing
table receives all the routes advertised by Router B.
[RouterD] display ip routing-table
------------------------------------------------------------------------------

172.1.17.0/24 O_ASE 150 1 D 192.168.3.1
172.1.18.0/24 O_ASE 150 1 D 192.168.3.1
172.1.19.0/24 O_ASE 150 1 D 192.168.3.1

Routers
192.168.1.0/24 OSPF 10 1 D 192.168.3.1
192.168.2.0/24 OSPF 10 1 D 192.168.3.1
192.168.3.0/24 Direct 0 0 D 192.168.3.2
192.168.3.1/32 Direct 0 0 D 192.168.3.1
# Check the OSPF routing table of Router C. You can find that three routes defined by the IP
prefix list named a2b are in the OSPF routing table. In the link state protocol, you can run the
filter-policy import command to filter the routes that join the local core routing table from the
protocol routing table.

Routing Tables
Routing for Network

192.168.2.0/24 1 Stub 192.168.2.2 192.168.2.2 0.0.0.0
192.168.1.0/24 2 Stub 192.168.2.1 192.168.2.1 0.0.0.0
192.168.3.0/24 2 Stub 192.168.2.1 192.168.2.1 0.0.0.0
Routing for ASEs

172.1.17.0/24 1 Type2 1 192.168.2.1 192.168.1.1
172.1.18.0/24 1 Type2 1 192.168.2.1 192.168.1.1
172.1.19.0/24 1 Type2 1 192.168.2.1 192.168.1.1
Total Nets: 6
----End
Configuration Files
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
filter-policy ip-prefix a2b export static
import-route static
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
ip ip-prefix a2b index 10 permit 172.1.17.0 24
#
#
return

Routers

#
sysname RouterB
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.3.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return

#
sysname RouterC
#
ip address 192.168.2.2 255.255.255.0
#
ospf 1
filter-policy ip-prefix in import
area 0.0.0.0
network 192.168.2.0 0.0.0.255
#
ip ip-prefix in index 10 permit 172.1.18.0 24
#
return

#
sysname RouterD
#
ip address 192.168.3.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.3.0 0.0.0.255
#
return
10.7.2 Example for Applying a Routing Policy for Importing Routes
As shown in Figure 10-6, Router B exchanges routing information with Router A through OSPF
and with Router C through IS-IS. Users want Router B to import IS-IS routes into the OSPF
network. Users also want that the route to 172.17.1.0/24 on the OSPF network has a low
preference and the route to 172.17.2.0/24 has a tag, which makes it easy to reference by a routing
policy.

Routers
Figure 10-6 Networking diagram for applying a routing policy for importing routes
RouterB IS-IS
OSPF
GE1/0/0 GE2/0/0 GE1/0/0
192.168.1.2/24 192.168.2.2/24 172.17.1.1/24
GE2/0/0
RouterA
GE1/0/0 172.17.2.1/24
GE4/0/0
192.168.1.1/2 GE3/0/0
192.168.2.1/24
4 172.17.3.1/24
RouterC
1. Configure a routing policy on Router B, set the cost of the route to 172.17.1.0/24 to 100,
and apply the routing policy when OSPF imports IS-IS routes. The routing policy allows
the route to 172.17.1.0/24 have a low preference.
2. Configure a routing policy on Router B, set the tag of the route to 172.17.2.0/24 is 20, and
apply the routing policy when OSPF imports IS-IS routes. In this way, the tag of the route
to 172.17.2.0/24 can take effect, which makes it easy to reference by a routing policy.
Procedure
Step 1 Assign an IP address to each interface.
[RouterC] isis
[RouterC-GigabitEthernet4/0/0] isis enable
[RouterB] isis

Routers

[RouterB-GigabitEthernet2/0/0] isis enable
Step 3 Configure OSPF and import routes.
# Configure Router A and enable OSPF.

[RouterA] ospf
# Configure Router B. Enable OSPF and import IS-IS routes.

[RouterB] ospf
[RouterB-ospf-1] import-route isis 1
# Check the OSPF routing table of Router A. You can view the imported routes.
Routing Tables
Routing for Network
192.168.1.0/24 1 Stub 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs
172.17.1.0/24 1 Type2 1 192.168.1.2 192.168.1.2
172.17.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.1.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
Total Nets: 5
Step 4 Configure the filtering list.
# Configure ACL 2002 to match 172.17.2.0/24.

[RouterB] acl number 2002
[RouterB-acl-basic-2002] rule permit source 172.17.2.0 0.0.0.255
[RouterB-acl-basic-2002] quit
# Configure the IP prefix list named prefix-a to match 172.17.1.0/24.

[RouterB] ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
Step 5 Configure the Route-Policy.

[RouterB] route-policy isis2ospf permit node 10
[RouterB-route-policy] if-match ip-prefix prefix-a
[RouterB-route-policy] if-match acl 2002
[RouterB-route-policy] apply tag 20
Step 6 Apply the Route-Policy when the route is imported.
# Configure Router B and apply the Route-Policy as the route is imported.

Routers
[RouterB] ospf
[RouterB-ospf-1] import-route isis 1 route-policy isis2ospf
# Check the OSPF routing table of Router A. You can view the cost of the route with the
destination address as 172.17.1.0/24 is 100. The tag of the route with the destination address as
172.17.2.0/24 is 20. Other routing attributes do not change.
Routing Tables
Routing for Network
192.168.1.0/24 1 Stub 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs
172.17.1.0/24 100 Type2 1 192.168.1.2 192.168.1.2
172.17.2.0/24 1 Type2 20 192.168.1.2 192.168.1.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.1.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
Total Nets: 5
----End
Configuration Files
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname RouterB
#
acl number 2002
rule 5 permit source 172.17.2.0 0.0.0.255
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.2.2 255.255.255.0
isis enable 1
#
ospf 1
import-route isis 1 route-policy isis2ospf
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
route-policy isis2ospf permit node 10
if-match ip-prefix prefix-a

Routers
apply cost 100

#
if-match acl 2002
apply tag 20
#
#
ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
#
return

#
sysname RouterC
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
#
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
ip address 172.17.2.1 255.255.255.0
isis enable 1
#
ip address 172.17.3.1 255.255.255.0
isis enable 1
#
ip address 192.168.2.1 255.255.255.0
isis enable 1
#
return
10.8 References
This section lists RFC documents related to routing policies.
None.

Routers
Configuration Guide - IP Routing 11 Managing IP Routing Tables
11 Managing IP Routing Tables
About This Chapter
This section describes how to manage IP routing tables. Through this section, you can understand
the traffic forwarding paths.
11.1 Managing IP Routing Tables

This section describes how to manage IP routing tables.

This section provides examples for configuring IP routing, including networking requirements
and configuration roadmap.

Routers
11.1 Managing IP Routing Tables

This section describes how to manage IP routing tables.
11.1.1 Displaying and Maintaining a Routing Table

You can view routing tables to learn about the network topology and locate routing faults.
Context
You can view routing table information to locate routing faults. The following describes the
commands used to display and maintain routing table information.
The display commands can be used in all views. The reset commands are used in the user view.
If the router imports a large number of routes, system performance may be affected when services
are being processed because the routes consume a lot of system resources. To improve system
security and reliability, configure a limit on the number of public route prefixes. When the
number of public route prefixes exceeds the limit, an alarm is generated, prompting you to check
whether unnecessary public route prefixes exist.
Procedure
l Run the display ip routing-table command to check brief information about the active
routes in the IPv4 routing table.
l Run the display ip routing-table verbose command to check detailed information about
l Run the display ip routing-table ip-address [ mask | mask-length ] [ longer-match ]
[ verbose ] command to check detailed information about the routes with the specified
destination address in the IPv4 routing table.
l Run the display ip routing-table ip-address1 { mask1 | mask-length1 } ip-address2
{ mask2 | mask-length2 } [ verbose ] command to check detailed information about the
routes within the specified destination address range in the IPv4 routing table.
l Run the display ip routing-table acl { acl-number | acl-name } [ verbose ] command to
check detailed information about the routes that match the specified basic ACL in the IPv4
routing table.
l Run the display ip routing-table ip-prefix ip-prefix-name [ verbose ] command to check
detailed information about the routes that match the specified IP prefix list in the IPv4
routing table.
l Run the display ip routing-table protocol protocol [ inactive | verbose ] command to
check detailed information about the routes discovered by the specified routing protocol in
l Run the display ip routing-table statistics command to check route statistics in the IPv4
routing table.
l Run the display ipv6 routing-table command to check brief information about the active
routes in the IPv6 routing table.

Routers
l Run the display ipv6 routing-table verbose command to check detailed information about
l Run the display ipv6 routing-table protocol [ inactive | verbose ] command to check
detailed information about the routes discovered by the specified routing protocol in the
IPv6 routing table.
l Run the display ipv6 routing-table statistics command to check route statistics in the IPv6
routing table.
l Run the reset ip routing-table statistics protocol [ vpn-instance vpn-instance-name ]
{ all | protocol } command to clear route statistics in the IPv4 routing table.
l Run the reset ipv6 routing-table statistics protocol { all | protocol } command to clear
route statistics in the IPv6 routing table.
----End
11.1.2 Displaying the Routing Management Module

You can view information about the routing management module to locate routing faults.
Procedure
l Run the display rm interface [ interface-type interface-number ] command to check IPv4
routing management (RM) information on the specified interface.
l Run the display rm interface vpn-instance vpn-instance-name command to check IPv4
RM information on the interface in the specified VPN instance.
l Run the display rm ipv6 interface [ interface-type interface-number ] command to check
IPv6 RM information on the specified interface.
----End
11.1.3 FIB Query and Maintenance

You can check the forwarding information base (FIB) to locate forwarding faults.
Context
NOTE
Unless otherwise stated, the FIB in this document refers to unicast FIB.
A device selects routes according to the routing table and forwards packets according to the FIB.
If the FIB is overloaded, new active routes cannot be delivered to the FIB, affecting packet
forwarding.
Procedure
l Check FIB entries.
Run the display fib [ slot-id ] [ vpn-instance vpn-instance-name ] [ verbose ] command
to check IPv4 FIB entries.
Run the display fib [ vpn-instance vpn-instance-name ] acl acl-number [ verbose ]
command to check IPv4 FIB entries that match a specified ACL rule.

Routers
Run the display fib [ vpn-instance vpn-instance-name ] ip-prefix prefix-name

[ verbose ] command to check IPv4 FIB entries that match a specified IP prefix list.
Run the display fib [ slot-id ] [ vpn-instance vpn-instance-name ] destination-
address1 [ verbose ] command to check IPv4 FIB entries that match a specified
destination IP address.
address1 destination-mask1 [ verbose ] command to check IPv4 FIB entries that exactly
match a specified destination IP address and mask.
address1 longer [ verbose ] command to check all IPv4 FIB entries that match
destination IP addresses in the natural mask range.
address1 destination-mask1 longer [ verbose ] command to check all IPv4 FIB entries
that match destination IP addresses in a specified mask range.
address1 destination-mask1 destination-address2 destination-mask2 [ verbose ]
command to check IPv4 FIB entries that match destination IP addresses in the range of
destination-address1 destination-mask1 and destination-address2 destination-mask2.
Run the display fib [ vpn-instance vpn-instance-name ] next-hop ip-address command
to check IPv4 FIB entries that match a specified next-hop IP address.
Run the display fib [ slot-id ] [ vpn-instance vpn-instance-name ] statistics command
to check the total number of IPv4 FIB entries.
Run the display fib statistics all command to check IPv4 FIB entry statistics.
Run the display ipv6 fib [ slot-id ] [ vpn-instance vpn-instance-name ] [ verbose ]
command to check IPv6 FIB entries.
Run the display ipv6 fib [ slot-id ] [ vpn-instance vpn-instance-name ] ipv6address
[ verbose ] command to check IPv6 FIB entries that match a specified destination IPv6
address.
Run the display ipv6 fib [ slot-id ] [ vpn-instance vpn-instance-name ] ipv6address
prefix-length [ verbose ] command to check IPv6 FIB entries that exactly match a
specified destination IPv6 address and mask.
Run the display ipv6 fib [ slot-id ] [ vpn-instance vpn-instance-name ] statistics
command to check the total number of IPv6 FIB entries.
Run the display ipv6 fib [ slot-id ] statistics all command to check IPv6 FIB entry
statistics.
l Maintain the FIB.
Configure periodic refresh of FIB entries.
1. Run:
system-view

2. Run:
undo fib regularly-refresh disable
Periodic refresh of FIB entries is enabled.

By default, periodic refresh of FIB entries is enabled.

Routers
3. You can run either of the following commands according to the actual
requirements.
Run:
fib regularly-refresh { interval interval [ entry-number entry-
number ] | entry-number entry-number }
The interval for refreshing FIB entries and the number of FIB entries refreshed
at an interval are configured.
By default, the interval for refreshing FIB entries is 1 second and the number
of FIB entries refreshed at an interval is 100.
Run:
fib regularly-refresh start-time start-time
The time at which FIB entries are refreshed is configured.

By default, FIB entries are refreshed at 01:00 a.m.
----End
11.1.4 Setting the Route Delivery Mode of an LPU

To ensure that packets match correct routes and are forwarded correctly, configure the device
to deliver all the routes to a LAN-side LPU.
Context
In most cases, packets received by a LAN-side LPU need to be sent to a WAN-side LPU for
forwarding. The packets may match incorrect routes in certain scenarios. As a result, the packets
cannot be forwarded. To solve the problem, configure the device to deliver all the routes
including WAN-side routes and LAN-side routes to a LAN-side LPU.
NOTE
Only AR2200 series and AR3200 series support this function.
Procedure
Step 1 Run:
system-view
Step 2 Run:
fib download all slot slot-id
The device is configured to deliver all the routes to a LAN-side LPU.
By default, only LAN-side routes are delivered to a LAN-side LPU.
----End

Run the display fib [ slot-id ] command to view the FIB table of the LPU.

Routers
11.1.5 Configuring IP FRR on the Public Network

IP FRR on the public network applies to the services that are very sensitive to delay and packet
loss on the public network.
Usage Scenario
On a traditional IP network, when a lower-layer failure occurs on the forwarding link of a device,
the physical interface of the device becomes Down. After the device detects the failure, it
instructs the upper-layer routing system to recalculate routes and update routing information. It
often takes the routing system several seconds to reselect an available route.
Second-level convergence is intolerable to the services that are quite sensitive to delay and packet
loss because it may lead to service interruption. For example, Voice over Internet Protocol
(VoIP) services are only tolerant of millisecond-level interruption. IP FRR ensures that the
forwarding system rapidly responds to link failures and uses backup routes to forward data,
minimizing service traffic interruption.
Before configuring IP FRR on the public network, complete the following tasks:
l Configuring static routes or an IGP to ensure that there are reachable IP routes between
devices
l Configuring different costs for routes to generate two non-equal-cost routes
Configure a route-policy and then enable IP FRR on the public network for the route-policy.
Procedure
Step 1 Configure a route-policy.
1. Run:
system-view

2. Run:
A route-policy is created and the route-policy view is displayed.

3. (Optional) Run:
if-match
Matching conditions are set to filter the routes to be backed up.
Select the if-match command according to 10.5.2.2 (Optional) Configuring an if-match

Clause.
If no matching condition is specified, backup outbound interfaces and backup next hops
will be specified for all routes of the device. This, however, causes backup information to

Routers
be specified for some routes that do not need to be backed up. To correctly configure backup
between routes, you are advised to specify matching conditions.
4. Run:
apply backup-interface interface-type interface-number
The backup outbound interface is set.

5. Run:
apply backup-nexthop ip-address
The backup next hop is set.
NOTE
l If a backup outbound interface is specified on a P2P link, no backup next hop needs to be specified.
l If a backup outbound interface is specified on a non-P2P link, a backup next hop needs to be
specified.
6. Run:
quit
Step 2 Enable IP FRR on the public network.

1. Run:
ip frr route-policy route-policy-name
IP FRR on the public network is enabled.
When using IP FRR, use this command to enable IP FRR so that the route-policy can take
effect.
NOTE
Only one route-policy can be configured every time you use the command. If you run the command
multiple times, only the latest configuration takes effect.
----End

Run the display ip routing-table [ verbose ] command to check information about the IPv4
routing table.

This section provides examples for configuring IP routing, including networking requirements
and configuration roadmap.
11.2.1 Example for Configuring IP FRR on the Public Network
As shown in Figure 11-1, four routers exist on the network and run OSPF. Link A (RouterT
RouterARouterC) functions as the primary link to forward services, and link B (RouterT

Routers
RouterBRouterC) functions as the backup link. When the primary link fails, services must be
rapidly switched from the primary link to the backup link to ensure that services are forwarded
correctly from RouterT to RouterC.
Figure 11-1 Networking diagram of configuring IPv4 FRR on the public network
GE1/0/0 GE2/0/0
192.168.10.2/24 192.168.11.2/24
GE2/0/0 GE2/0/0
RouterA
192.168.10.1/24 192.168.11.1/24
GE1/0/0 Link A GE1/0/0
172.16.1.1/24 172.17.1.1/24
RouterT RouterC
GE3/0/0 Link B GE3/0/0
192.168.20.1/24 192.168.21.1/24
GE1/0/0 GE2/0/0
192.168.20.2/24 192.168.21.2/24
RouterB
1. Configure the OSPF cost on GE3/0/0 of RouterT and RouterC to enable OSPF to select
link A (RouterTRouterARouterC) as the primary link.
2. Configure a route-policy on RouterT and apply this route-policy for IP FRR on the public
network to configure link B (RouterTRouterBRouterC) as the backup link of link A.
Procedure
# Configure an IP address for each interface on RouterT.
[Huawei] sysname RouterT
[RouterT] interface gigabitethernet 1/0/0
[RouterT-GigabitEthernet1/0/0] ip address 172.16.1.1 24
[RouterT-GigabitEthernet1/0/0] quit
The configurations of RouterA, RouterB, and RouterC are similar to the configuration of
RouterT, and are not mentioned here.
Step 2 Configure OSPF on RouterT, RouterA, RouterB, and RouterC.
# Configure RouterT.
[RouterT] ospf
[RouterT-ospf-1] area 0
[RouterT-ospf-1-area-0.0.0.0] network 172.16.1.0 0.0.0.255

Routers

[RouterT-ospf-1-area-0.0.0.0] quit
[RouterA] ospf
[RouterB] ospf
[RouterC] ospf
Step 3 Set the cost for OSPF interfaces.
# Set the cost for GE3/0/0 on RouterT to 100 so that OSPF prefers link A as the primary link.
[RouterT-GigabitEthernet3/0/0] ospf cost 100
# Set the cost for GE3/0/0 on RouterC to 100 so that OSPF prefers link A as the primary link.
[RouterC-GigabitEthernet3/0/0] ospf cost 100
Step 4 Configure a route-policy.
# Configure a route-policy on RouterT, specify the backup outbound interface and backup next
hop, and configure an if-match clause to limit the application scope.
[RouterT] ip ip-prefix frr1 permit 172.17.1.1 24
[RouterT] route-policy ip_frr_rp permit node 10
[RouterT-route-policy] if-match ip-prefix frr1
[RouterT-route-policy] apply backup-nexthop 192.168.20.2
[RouterT-route-policy] apply backup-interface gigabitethernet 3/0/0
[RouterT-route-policy] quit
Step 5 Enable IP FRR on the public network on RouterT.

[RouterT] ip frr route-policy ip_frr_rp
# Check information about the backup outbound interface and backup next hop on RouterT.
<RouterT> display ip routing-table 172.17.1.0 verbose
------------------------------------------------------------------------------
Summary Count : 1

Routers
Destination: 172.17.1.0/24
Protocol: OSPF Process ID: 1
Preference: 10 Cost: 3
NextHop: 192.168.10.2 Neighbour: 0.0.0.0
State: Active Adv Age: 00h06m49s
Tag: 0 Priority: low
Label: NULL QoSInfo: 0x0
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: GigabitEthernet2/0/0
TunnelID: 0x0 Flags: D
BkNextHop: 192.168.20.2 BkInterface: GigabitEthernet3/0/0
BkLabel: NULL SecTunnelID: 0x0
BkPETunnelID: 0x0 BkPESecTunnelID: 0x0
BkIndirectID: 0x0
Step 7 When IP FRR is not required, run the undo ip frr command to disable IP FRR.
[RouterT] undo ip frr
# After IP FRR is disabled, check information about the backup outbound interface and backup
next hop.
<RouterT> display ip routing-table 172.17.1.0 verbose
------------------------------------------------------------------------------
Summary Count : 1
Destination: 172.17.1.0/24
Protocol: OSPF Process ID: 1
Preference: 10 Cost: 3
NextHop: 192.168.10.2 Neighbour: 0.0.0.0
State: Active Adv Age: 00h00m01s
Tag: 0 Priority: low
Label: NULL QoSInfo: 0x0
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: GigabitEthernet2/0/0
TunnelID: 0x0 Flags: D
----End
Configuration Files
l Configuration file of RouterT
#
sysname RouterT
#
ip frr route-policy ip_frr_rp
#
ip address 172.16.1.1 255.255.255.0
#
ip address 192.168.10.1 255.255.255.0
#
ip address 192.168.20.1 255.255.255.0
ospf cost 100
#
ospf 1
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.10.0 0.0.0.255

Routers
network 192.168.20.0 0.0.0.255

#
ip ip-prefix frr1 index 10 permit 172.17.1.0 24
#
route-policy ip_frr_rp permit node 10
if-match ip-prefix frrl
apply backup-nexthop 192.168.20.2
apply backup-interface GigabitEthernet3/0/0
#
return

#
sysname RouterA
#
ip address 192.168.10.2 255.255.255.0
#
ip address 192.168.11.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.10.0 0.0.0.255
network 192.168.11.0 0.0.0.255
#
return

#
sysname RouterB
#
ip address 192.168.20.2 255.255.255.0
#
ip address 192.168.21.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.20.0 0.0.0.255
network 192.168.21.0 0.0.0.255
#
return

#
sysname RouterC
#
ip address 172.17.1.1 255.255.255.0
#
ip address 192.168.11.1 255.255.255.0
#
ip address 192.168.21.1 255.255.255.0
ospf cost 100
#
ospf 1
area 0.0.0.0
network 172.17.1.0 0.0.0.255
network 192.168.11.0 0.0.0.255
network 192.168.21.0 0.0.0.255
#
return

Routers
Configuration Guide - IP Routing 12 PBR Configuration
12 PBR Configuration
About This Chapter
Configuring PBR improves the security of the network and implements load balancing.
12.1 Introduction to Policy-based Routing

This section describes the definition and functions of Policy-based Routing.
12.2 Principles
This section describes the implementation of Policy-based Routing.
12.3 Applications
This section describes the applicable scenario of Policy-based Routing.
12.4 Configuration Tasks

The device supports local PBR and interface PBR based on information such as source addresses
and packet lengths and supports SPR based on the link quality.
12.5 Configuration Notes

The SPR function is used with a license.
12.6 Configuring PBR

This section describes how to configure Policy-based Routing.

The section provides several configuration examples of IP unicast PBR, including networking
requirements, and configuration roadmap.
12.8 References
This section lists references of Policy-based Routing.

Routers
12.1 Introduction to Policy-based Routing

This section describes the definition and functions of Policy-based Routing.
Definition
Policy-based routing (PBR) is a mechanism that makes routing decisions based on user-defined
policies. PBR includes local PBR, interface PBR, and smart policy routing (SPR).
NOTE
l The differences between PBR and routing policy are as follows:

l PBR implements routing based on packets. It routes data packets based on user-defined policies
instead of following the routes in the existing routing table.
l Routing policies implement routing based on routing information. Routing policies are used to
filter routes and set route attributes. You can change route attributes (including reachability) to
change a route over which network traffic is transmitted.
For details on routing policies, see 10 Routing Policy Configuration.
Purpose
Traditionally, devices searches routing tables for routes of packets based on their destination
addresses and then forward the packets. Currently, more users require that devices route packets
based on user-defined policies. PBR allows network administrators to make user-defined
policies to change packet routes based on source addresses, packet size, and link quality in
addition to destination addresses.
Benefits
PBR has the following advantages:
l Allows network administrators to make user-defined policies for routing packets, which
improves flexibility of route selection.
l Allows different data flows to be forwarded on different links, which increases link usage.
l Uses cost-effective links to transmit service data without affecting service quality, which
reduces the cost of enterprise data services.
12.2 Principles
This section describes the implementation of Policy-based Routing.
12.2.1 Local PBR

Local PBR applies only to locally generated packets, such as ping packets.
Local PBR on a device can have multiple local PBR nodes. Each local PBR node has a priority.
The device attempts to match locally generated packets with rules bound with local PBR nodes
in descending order of priority.

Routers
Implementation
When sending locally generated packets, a device attempts to match the packets with rules bound
with local PBR nodes in descending order of priority. Local PBR supports rules based on access
control list (ACL) and packet length.
l If the device finds a matching local PBR node, it performs the following steps:
1. Checks whether the priority of the packets has been set.
If so, the device applies the configured priority to the packets and performs the
next step.
If not, the device performs the next step.
2. Checks whether an outbound interface has been configured for local PBR.
If so, the device sends the packets through the outbound interface.
If not, the device performs the next step.
3. Checks whether next hops have been configured for local PBR.
NOTE
Two next hops can be configured for load balancing.

If a next hop is configured for packet forwarding in PBR and the next hop is
reachable, the device checks whether association between next hop and route is
configured.
If association between next hop and route is configured, the device detects
whether the configured IP address of the route associated with the next hop in
PBR is reachable.
If the IP address is reachable, the configured next hop takes effect, and the
device forwards packets to the next hop.
If the IP address is unreachable, the configured next hop does not take effect,
and the device checks whether a backup next hop has been configured. If a
backup next hop has been configured and is reachable, the device forwards
packets to the backup next hop. If no backup next hop is configured or the
configured backup next hop is unreachable, the device searches the routing
table for a route according to the destination of packets. If no route is
available, the device performs the next step.
If association between next hop and route is not configured, the device sends
packets to the next hop.
If a next hop is configured in PBR but the next hop is unreachable, the device
checks whether a backup next hop has been configured. If a backup next hop has
been configured and is reachable, the device forwards packets to the backup next
hop. If no backup next hop is configured or the configured backup next hop is
unreachable, the device searches the routing table for a route according to the
destination of packets. If no route is available, the device performs the next hop.
If the next hop is not configured, the device searches the routing table for a route
based on the destination addresses of the packets. If no route is available, the device
performs the next hop.
4. Checks whether default next hops have been configured for local PBR.
If so, the device sends the packets to the default next hops.

Routers
If not, the device performs the next hop.

5. Discards the packets and generates ICMP_UNREACH messages.
l If the device does not find a matching local PBR node, it searches the routing table for a
route based on the destination addresses of the packets and then sends the packets.
12.2.2 Interface PBR

Interface PBR applies only to packets received from other devices, but not to locally generated
packets such as local ping packets.
Implementation
Interface PBR is implemented based on the redirect action configured in a traffic behavior and
takes effect only on the inbound packets. By default, a device forwards packets to the next hop
found in the routing table. If interface PBR is configured, the device forwards packets to the
next hop specified by interface PBR.
When the device forwards packets to the next hop specified by interface PBR, the device triggers
ARP learning if it has no ARP entry corresponding to the IP address of the specified next hop.
If the device cannot learn this ARP entry, it forwards packets to the next hop found in the routing
table. If the device has this ARP entry, it forwards packets to the next hop specified by interface
PBR.
12.2.3 Smart Policy Routing

Smart policy routing (SPR) allows devices to select routes based on link quality and requirements
for link quality.
Background
As network service requirements vary widely and service data is stored in a centralized manner,
network services increasingly depend on high link quality. Users stress more importance on
service availability, service response speed, and service quality than network connectivity.
Diversified service requirements pose a challenge to per-hop-based routing protocols. Devices
that use per-hop-based routing protocols are unaware of link quality and service requirements,
so they cannot deliver satisfying service experience. Even though routes are reachable, low link
quality may cause a packet forwarding failure. SPR resolves this problem. SPR selects optimal
links to forward packets based on link quality and service requirements. This mechanism
prevents network black holes and flappings.
Service Classification
SPR classifies services based on the following attributes:
l Protocol types: IP, TCP, UDP, GRE, IGMP, IPINIP, OSPF, and ICMP
l Packet applications: DSCP, TOS, IP precedence, fragment, VPN, and TCP-flag
l Packet fields: source IP address, destination IP address, protocol, source port, destination
port, source IP prefix, and destination IP prefix
Different services have different requirements for link quality indicators: delay, jitter, packet
loss rate, and composite measure indicator (CMI). If services are insensitive to a link quality
indicator, no threshold needs to be configured for this indicator.

Routers
NOTE
l On a device, the maximum delay is 5000 ms, the maximum jitter is 3000 ms, and the maximum packet
loss rate is 1000. These maximum values are also the default values. Smaller values of the preceding
indicators indicate better link quality.
l The CMI is calculated using the following formula: CMI = 9000 cmi-method. The default value of
cmi-method is the sum of delay (D), jitter (J), and packet loss rate (L).
l The cmi-method parameter is configurable. For example, if cmi-method is set to D+10*J, the delay
is 1000 ms, and the jitter is 10 ms, then the CMI is calculated as follows:
CMI = 9000 (D + 10 * J) = 9000 (1000 + 100) = 7900
l In the CMI calculation formula, if there is a coefficient before a link quality indicator (delay, jitter,
or packet loss rate), the product of the link quality indicator and the coefficient must be less than
or equal to the maximum value of the indicator. For example, if cmi-method is set to 10*D+10*J
+10*L, the delay is 1000 ms, the jitter is 100 ms, and the packet loss rate is 10, then the CMI is
calculated as follows:
CMI = 9000 (5000 + 1000 + 100) = 2900
In the preceding formula, 10*D is 10000, which exceeds the maximum value of 5000. Therefore,
the delay takes the maximum value 5000.
Detection Link and Link Group

SPR uses detection links to implement intelligent route selection. Each detection link has a
unique probe, which is a network quality analysis (NQA) test instance. If an NQA test fails, the
corresponding detection link is unavailable. A probe obtains quality indicators of the
corresponding detection link. Then SPR selects an optimal link based on the link quality
indicators.
SPR uses link groups instead of detection links to measure link quality. A detection link can be
added to different link groups, and a link group can have one or more detection links.
SPR defines three roles for links: active link group, standby link group, and best-effort link.
When no suitable link is available in the active and standby link groups, SPR activates the best-
effort link to forward service data.
A link group can be bound to different services. For example, link group 1 can be used as the
active link group for service 1 and as the standby link group for service 2.
Link Selection
Figure 12-1 shows how SPR selects links for services based on NQA test results.

Routers
Figure 12-1 Link selection by SPR
Obtains NQA test results
Whether find links meeting Yes Select the link with the
requirements on D, J, L, largest CMI value
CMI in the active link
group
No
Whether find links meeting Yes Select the link with the
requirements on D, J, L,
largest CMI value
CMI in the standby link
group
No
Whether find links

meeting the CMI Yes Select the link with the
requirement in the active largest CMI value
and standby link groups
No
Activate the best-effort

link
End
If a link is transmitting services, the probability that this link is selected to transmit new services
is lower. This ensures load balancing among links.
Switchover Timer
SPR uses a switchover timer to control link switchovers when the link quality does not meet
service requirements.

Routers
SPR periodically obtains NQA test results to determine whether a link meets service
requirements. If SPR obtains NQA test results indicating that a link does not meet service
requirements, SPR starts the switchover timer. Before the switchover timer expires:
l If SPR obtains NQA test results indicating that the link meets service requirements, SPR
resets the timer.
l If SPR does not obtain NQA test results indicating that the link meets service requirements,
SPR triggers a link switchover.
Flapping Suppression Timer

When a network is unstable, SPR triggers link switchovers frequently, which degrades service
experience. SPR provides the flapping suppression function to address this problem.
The flapping suppression function is disabled by default, and the flapping suppression period is
configurable. After traffic is switched to a new link, SPR starts the flapping suppression timer.
Within a flapping suppression period, SPR does not perform a link switchover even if it does
not obtain link NQA test results indicating that the link meets service requirements within a
switchover period. After the flapping suppression timer expires:
l If SPR still does not obtain NQA test results indicating that the link meets service
requirements within a switchover period, SPR performs a link switchover.
l If SPR obtains NQA test results indicating that the link meets service requirements within
a switchover period, SPR retains traffic on the link.
12.3 Applications
This section describes the applicable scenario of Policy-based Routing.
Local PBR
As shown in Figure 12-2, RouterA connects to the Internet using two links. To apply PBR to
packets that are generated on RouterA, configure local PBR.
Figure 12-2 Networking diagram of local PBR
Interface1
RouterA Internet
Interface2
Interface PBR
As shown in Figure 12-3, the intranet connects to the Internet using RouterA. RouterA has two
outbound interfaces connected to the Internet. To enable packets of a specified type to be
forwarded through a specified outbound interface, configure interface PBR.

Routers
Figure 12-3 Networking diagram of interface PBR
PC1 PC2
10.10.10.1/24 10.10.10.2/24
Interface1
Interface3
Internet
Interface2
RouterA
10.10.10.3/24
PC3
l Routing based on source addresses: Network administrators can use interface PBR to ensure
that VIP users use the link with a higher rate and other users use the link with a lower rate.
Interface PBR is configured on RouterA to define routing rules and actions. For example,
interface PBR is enabled on Interface3. The interface PBR allows RouterA to send all
packets that are received on Interface3 from PC1 at 10.10.10.1/24 through Interface2 and
send other packets based on their destination addresses.
l Routing based on service classes: Different services have different requirements for the
transmission rate, throughput, and reliability. Interface PBR allows routers to route data
packets based on service classes and network status. For example, routers use high-
bandwidth links to transmit voice and video services and low-bandwidth links to transmit
data services. Assume that the bandwidth of the link for sending packets from Interface1
is higher than that from Interface2. Interface PBR can be configured on Interface3 of
RouterA to enable RouterA to send voice and video services from Interface1 and data
services from Interface2.
SPR
As shown in Figure 12-4, an enterprise branch connects to the enterprise data center over two
ISP networks (ISP1 and ISP2), and a 3G outbound interface is configured on RouterA to provide
a best-effort link. RouterA connects to ISP1 through the link group group1 and connects to ISP2
through the link group group2. ISP1 provides advanced network service at a high cost, while
ISP2 provides common network service at a low cost. The enterprise branch exchanges voice,
video, FTP and HTTP services with the data center. Voice and video services require high link
quality. Therefore, group1 and group2 function as the active and standby link groups respectively
for voice and video services. FTP and HTTP services do not require high link quality. Therefore,
group2 and group1 function as the active and standby link groups respectively for FTP and HTTP
services.

Routers
Figure 12-4 Networking diagram of SPR
Data center
Enterprise branch 1
ro up ISP1 RouterB
RouterA g
gro
up
2
3G best-effort ISP2
RouterC
link
Link group
SPR processes voice and video services as follows:

l When link quality provided by group1 cannot meet voice and video service requirements
but link quality provided by group2 does, SPR switches voice and video services to group2
after the flapping suppression timer expires.
If group1 meets service requirements again, SPR switches services back to group1 after
the flapping suppression timer expires and a switchover period elapses.
If both group 1 and group2 cannot meet service requirements later but group1 provides
better link quality than group2, SPR switches services back to group1 after the flapping
suppression timer expires and a switchover period elapses.
If group2 cannot meet service requirements later but provides better link quality than
group1, SPR continues to use group2 to transmit services.
l When the link quality provided by group1 and group 2 cannot meet voice and video service
requirements but their links are available, SPR selects the link with the largest CMI value
from group1 and group2 to transmit services.
l When all the links in group1 and group2 are unavailable, SPR uses the 3G best-effort link
to transmit services.
12.4 Configuration Tasks

The device supports local PBR and interface PBR based on information such as source addresses
and packet lengths and supports SPR based on the link quality.
When a packet arrives, the system forwards the packet according to the configured PBR. If no
PBR is configured or if PBR is configured but no matching entry exists, the system forwards
the packet according to the routing table.
Table 12-1 lists the PBR configuration tasks.

Routers
Table 12-1 PBR configuration tasks

Local PBR Sends locally generated 12.6.1 Configuring Local PBR

packets, such as ICMP and
BGP packets.
When users want locally
generated packets to be
forwarded through
different interfaces or to
different next hops based
on source addresses or
packet lengths, configure
local PBR.
Interface PBR Forwards only packets 12.6.2 Configuring Interface PBR

received from other
devices.
When users want some
packets received from other
devices to be forwarded to
a specified next hop,
configure interface PBR.
Interface PBR specifies a
next hop to which packets
matching redirect rules are
forwarded. Packets that do
not match redirect rules are
forwarded according to the
routing table. Interface
PBR is used for load
balancing and security
monitoring.
SPR Selects the optimal link for 12.6.3 Configuring SPR

service flows based on link
quality attributes.
When users want service
flows to be transmitted
through links with different
quality levels, configure
SPR.
12.5 Configuration Notes

The SPR function is used with a license.
By default, SPR cannot be used on the router. To use SPR, apply for and purchase one the
following licenses from the Huawei local office:

Routers
l AR150&160&200 data value-added service package for AR150&200 series

l AR1200 data value-added service package for AR1200 series
12.6 Configuring PBR

This section describes how to configure Policy-based Routing.
12.6.1 Configuring Local PBR

Configuring local PBR allows locally generated packets to be sent from a specified outbound
interface.Local PBR applies only to the traffic generated by the local device.
Before configuring local SPR, complete the following tasks:
l Setting link layer protocol parameters for interfaces to ensure that the link layer protocol
status on the interfaces is Up
l Configuring an ACL to match packets
l Creating a VPN instance if you want packets to be forwarded by a VPN instance
NOTE
Local PBR applies only to locally generated packets.
12.6.1.1 Configuring Matching rules of Local PBR
Context
By defining a matching rule of the local PBR, you can determine the type of packets to which
PBR is applied.
Before configuring an ACL of IP packets, create an ACL.
Procedure
Step 1 Run:
system-view
Step 2 Run:
policy-based-route policy-name { deny | permit } node node-id
A policy and a PBR node are created. If a PBR node exists, the local PBR view is displayed.
By default, no policy or PBR node is created for the local PBR.

Routers
NOTE
l The permit parameter indicates that PBR is enabled for matched packets. The deny indicates that PBR
is disabled for matched packets.
l To create multiple PBR nodes for the local PBR, run this command multiple times. The node-id
parameter specifies the sequence number of a PBR node. A smaller number indicates a higher priority
of the corresponding PBR node.
Step 3 Run either of the following commands or both the commands to configure matching rules of IP
packets as required.
l Run:
if-match acl acl-number
An ACL is configured to match IP packets.

By default, no matching rule of IP addresses is configured in the local PBR.
NOTE
l When permit is used in the ACL rule, the system executes the behavior specified in the local PBR
for the packets matching the ACL rule. When the behavior is permit, the system enforces the policy
on the packets matching the rule. When the behavior is deny, the system searches routes for the
packets according to the destination addresses.
l If packets match no ACL rule, the system searches routes for the packets according to the destination
addresses.
l When deny is used in the ACL rule or the ACL does not contain rules, the local PBR referencing
the ACL does not take effect, and the system searches routes for the packets according to the
destination addresses.
l Run:
if-match packet-length min-length max-length
A matching rule of IP packet length is configured to match packets.

By default, no matching rule of IP packet length is configured in the local PBR.
----End
12.6.1.2 Configuring Actions of Local PBR
Context
When configuring actions of local PBR, note the following:
l If two next hops are configured in PBR, the two next hops load balance traffic when
forwarding packets.
l If two outbound interfaces are configured in PBR, the two outbound interfaces load balance
traffic when forwarding packets.
l If two next hops and two outbound interfaces are configured in PBR, only the two outbound
interfaces load balance traffic when forwarding packets.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
policy-based-route policy-name { deny | permit } node node-id
A policy and a PBR node are created. If a PBR node exists, the local PBR view is displayed.
By default, no policy or PBR node is created for the local PBR.
Step 3 Configure actions of the local PBR. A PBR node contains at least one apply clauses.
l Run:
apply output-interface interface-type interface-number
An outbound interface is configured.

By default, no outbound interface is configured in the local PBR.
Locally generated packets matching the PBR node are sent from the specified outbound
interface.
NOTE
l The outbound interface cannot be a broadcast interface, for example, an Ethernet interface.
l If you configure an outbound interface while two outbound interfaces have been configured using
the apply output-interface interface-type interface-number command, the new outbound interface
configuration overwrites the first outbound interface configuration, not the second outbound
interface configuration.
l Run:
apply ip-address next-hop ip-address1 [ ip-address2 ]
A next hop is configured.

By default, no next hop to which packets are forwarded is configured in the local PBR.
When no outbound interface is configured for a PBR node, locally generated packets
matching the PBR node are forwarded to the specified next hop.
NOTE
l The next hop cannot be the local IP address.

l If you configure a next hop while two next hops have been configured using the apply ip-address
next-hop ip-address1 [ ip-address2 ] command, the new next hop configuration overwrites the
first next hop configuration, not the second next hop configuration.
l Run:
apply ip-address next-hop { ip-address1 track ip-route ip-address2 { mask | mask-
length } } &<1-2>
Association between next hop and route is configured in local PBR.

By default, association between next hop and route is not configured in local PBR.
l Run:
apply ip-address backup-nexthop ip-address
A backup next-hop IP address is specified for packet forwarding in local PBR.

By default, no backup next hop is configured for packet forwarding in local PBR.
l Run:
apply ip-address default next-hop ip-address1 [ ip-address2 ]
A default next hop of packets is configured.

By default, no default next hop is configured in local PBR.
NOTE
The default next hop cannot be a local IP address.
l Run:

Routers
apply access-vpn vpn-instance vpn-instance-name &<1-6>
A VPN instance for forwarding packets is configured.

By default, no VPN instance is configured for forwarding packets in local PBR.
l Run:
ip policy-based-route refresh-time [ refreshtime-value ]
The interval at which local PBR updates LSPs is configured.

By default, the interval at which local PBR updates LSPs is 5000 ms.
l Run:
apply ip-precedence precedence
The priority of packets is configured.

By default, the priority of IP packets is not configured in local PBR.
After the configuration is complete, a router sets the priority of locally generated packets that
match the PBR node based on the priority configuration.
The value of precedence ranges from 0 to 7. You can replace the value of precedence with
a keyword. Table 12-2 shows the mappings between the values and keywords.
Table 12-2 Mappings between the values of precedence and keywords
Value Keyword
0 Routine
1 Priority
2 Immediate
3 Flash
4 Flash-override
5 Critical
6 Internet
7 Network
----End
12.6.1.3 Applying Local PBR
Context
This section describes how to apply local PBR. Local PBR applies only to locally generated
packets.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
ip local policy-based-route policy-name
Local PBR is enabled.
By default, the local PBR is disabled.
----End
Procedure
l Run the display ip policy-based-route command to check the applied local PBR on the
local device.
l Run the display ip policy-based-route setup local [ verbose ] command to check the
configurations of the local PBR.
l Run the display ip policy-based-route statistics local command to check packet statistics
of the local PBR.
l Run the display policy-based-route [ policy-name [ verbose ] ] command to check
configurations of created PBRs.
----End
12.6.2 Configuring Interface PBR

Interface PBR can redirect the packets received on an interface from other devices to a specified
next hop address.
Context
By configuring the redirection action, the device redirects the packets matching traffic
classification rules to a specified next hop address or an interface.
A traffic policy containing the redirection action can be only used on an interface in the inbound
direction.
Before configuring interface PBR, complete the following tasks:
l Configuring IP addresses and routing protocols for interfaces to ensure connectivity
l Configuring an ACL if the ACL needs to be used to classify traffic
l (Optional) Uploading a Smart Application Control (SAC) signature file to the router and
storing it to the storage media
NOTE
For the configuration details, see (Optional) Configuring SAC in the Configuration Guide - QoS
Configuration.

Routers
Procedure
1. Configure the traffic classifier.
a. Run:
system-view

b. Run:
traffic classifier classifier-name [ operator { and | or } ]
A traffic classifier is created and the traffic classifier view is displayed.

and indicates that the relationship between rules is AND.
l If a traffic classifier contains ACL rules, packets match the traffic classifier only
when the packets match one ACL rule and all the non-ACL rules.
l If a traffic classifier does not contain ACL rules, packets match the traffic classifier
only when the packets match all the non-ACL rules.
or indicates that the relationship between rules is OR. Packets match a traffic classier
as long as the packets match one rule of the traffic classifier.
By default, the relationship between rules in a traffic classifier is OR.
c. Run the following commands as required.
Matching Rule Command
Outer VLAN ID if-match vlan-id start-vlan-id [ to end-vlan-id ]
Inner VLAN IDs in QinQ if-match cvlan-id start-vlan-id [ to end-vlan-id ]

packets
802.1p priority in VLAN if-match 8021p 8021p-value &<1-8>

packets
Inner 802.1p priority in if-match cvlan-8021p 8021p-value &<1-8>

QinQ packets
EXP priority in MPLS if-match mpls-exp exp-value &<1-8>

packets (AR1200 series,
AR2200 series, AR3200
series)
Destination MAC if-match destination-mac mac-address [ mac-

address address-mask mac-address-mask ]
Source MAC address if-match source-mac mac-address [ mac-address-

mask mac-address-mask ]
DLCI value in FR if-match dlci start-dlci-number [ to end-dlci-number ]

packets
DE value in FR packets if-match fr-de
Protocol type field if-match l2-protocol { arp | ip | mpls | rarp | protocol-

encapsulated in the value }
Ethernet frame header

Routers
All packets if-match any
DSCP priority in IP if-match [ ipv6 ] dscp dscp-value &<1-8>

packets
IP precedence in IP if-match ip-precedence ip-precedence-value &<1-8>

packets NOTE
if-match dscp and if-match ip-precedence cannot be
configured simultaneously in a traffic classifier where the
relationship between rules is AND.
Layer 3 protocol type if-match protocol { ip | ipv6 }
PVC information in if-match pvc vpi-number/vci-number

ATM packets
RTP port number if-match rtp start-port start-port-number end-port

end-port-number
SYN Flag in the TCP if-match tcp syn-flag { ack | fin | psh | rst | syn |
packet header urg }*
Inbound interface if-match inbound-interface interface-type interface-

number
ACL rule if-match acl { acl-number | acl-name }

NOTE
To define a matching rule for traffic classification based on an
ACL, you must create the ACL first.
ACL6 rule if-match ipv6 acl { acl-number | acl-name }

NOTE
To define a matching rule for traffic classification based on an
ACL, you must create the ACL first.
Application protocol if-match app-protocol protocol-name [ time-range

time-name ]
NOTE
l Before defining a matching rule based on an application
protocol, enable Smart Application Control (SAC) and
load the signature file.
l When a traffic classifier contains if-match app-
protocol, the relationship between rules in the traffic
classifier must be or.

Routers
SAC group if-match protocol-group protocol-group [ time-

range time-name ]
NOTE
l Before defining a matching rule based on an application
protocol, enable Smart Application Control (SAC) and
load the signature file.
l You can run the app-protocol protocol-name command
in the SAC group view to add a specified application
protocol to an SAC group.
l When a traffic classifier contains if-match app-
protocol, the relationship between rules in the traffic
classifier must be or.
d. Run:
quit
The traffic classifier view is quitted.

2. Configure a traffic behavior.
a. Run:
traffic behavior behavior-name
A traffic behavior is created and the traffic behavior view is displayed.

b. Run the following commands as required.
l Run:
redirect ip-nexthop ip-address [ vpn-instance vpn-instance-name ]
[ track { nqa admin-name test-name | ip-route ip-address { mask | mask-
length } } ] [ post-nat ]
The device is configured to redirect packets matching traffic classification rules to

the specified next hop address and association between redirection and the NQA
test instance or IP route is configured.
Network quality analysis (NQA) diagnoses and locates network faults. The route
status indicates whether a destination IP address is reachable. Association between
NQA or routing and redirection implements rapid link switchover and ensures
correct forwarding of data traffic when the destination IP address is unreachable.
If the NQA test instance or routing module detects a reachable destination IP
address, packets are forwarded based on the specified IP address and redirection
takes effect.
When the NQA test instance or routing module detects a reachable destination
IP address, redirection is invalid. The device forwards packets based on the
original forwarding path.
NOTE
l The type of the NQA test instance that is associated with redirection must be ICMP.
For details, see Configuring an ICMP Test Instance in the Huawei
AR150&200&1200&2200&3200 Series Enterprise Routers Configuration Guide -
NQA Configuration.
l Redirection is invalid for IPv6 hop-by-hop packets.
l Run:

Routers
redirect ipv6-nexthop ipv6-address
The device is configured to redirect IPv6 packets matching traffic classification

rules to the next hop.
l Run:
redirect interface interface-type interface-number
The device is configured to redirect packets matching traffic classification rules to

a specified interface.
NOTE
l The device only supports redirection to 3G Cellular and dialer interfaces.

l Only an NQA test instance of ICMP can be associated with redirection.
c. (Optional) Run:
statistic enable
The traffic statistics function is enabled.

d. Run:
quit
Exit from the traffic behavior view.

e. Run:
quit
Exit from the system view.

3. Configure a traffic policy.
a. Run:
system-view

b. Run:
traffic policy policy-name
A traffic policy is created and the traffic policy view is displayed, or the existing traffic
policy view is displayed.
c. Run:
classifier classifier-name behavior behavior-name
A traffic behavior is bound to a traffic classifier in a traffic policy.

d. Run:
quit
The traffic policy view is quitted.

e. Run:
quit
The system view is quitted.

4. Apply the traffic policy.
a. Run:
system-view

b. Run:
interface interface-type interface-number [.subinterface-number ]

Routers
The interface or sub-interface view is displayed.

c. Run:
traffic-policy policy-name inbound
A traffic policy is applied to the interface or sub-interface in the inbound or outbound

direction.
Currently, the traffic policy can be applied to only incoming traffic on interfaces.

l Run the display traffic classifier user-defined [ classifier-name ] command to check the
traffic classifier configuration on the device.
l Run the display traffic behavior { system-defined | user-defined } [ behavior-name ]
command to check the traffic behavior configuration on the device.
l Run the display traffic policy user-defined [ policy-name [ classifier classifier-name ] ]
command to check the traffic policy configuration on the device.
l Run the display traffic-policy applied-record [ policy-name ] command to check the
record of the specified traffic policy.
12.6.3 Configuring SPR

Based on the link quality requirement, you can configure SPR to dynamically switch service
transmission links.
Before configuring SPR, complete the following tasks:
l Configuring link layer parameters and IP addresses for interfaces so that the link layer
protocol of the interfaces is Up and the route is reachable
l Configuring ACLs to classify service flows
l Configuring NQA test instances to detect link quality
NOTE
You need to configure the NQA client on the service end and the NQA server on the peer end.
12.6.3.1 Setting SPR Routing Parameters
Context
You can configure SPR routing parameters, including the SPR switchover period, detection link,
and best-effort link.
Before configuring detection links, configure NQA test instances.
Procedure
Step 1 Run:
system-view

Routers
Step 2 Run:
smart-policy-route
An SPR is created and the SPR view is displayed.
Step 3 Set the SPR switchover period, flapping suppression period, a best-effort link, detection links
and link groups.
l Run:
period period-value
The SPR switchover period is set.

The default SPR switchover period is 60 seconds.
l (Optional) Run:
route flapping suppression period-value
The flapping suppression period is set.

By default, the flapping suppression period is not set for SPR.
When a network is unstable, SPR may switch links frequently, reducing service forwarding
efficiency. After the flapping suppression period is set, SPR switches services to another link
after the configured flapping suppression period expires, preventing frequent link
switchovers.
NOTE
l The minimum flapping suppression period is two times the SPR switchover period.
l The shortest interval of SPR switchover is the flapping suppression period plus the SPR switchover
period.
l (Optional) Run:
backup-interface interface-type interface-number [ next-hop-address ]
The best-effort link is specified.

By default, no best-effort link is configured for SPR.
After a best-effort link is configured, SPR allows service flows to be transmitted over the
best-effort link when links in the active and standby link groups are unavailable, ensuring
high-reliability transmission.
NOTE
When the best-effort link is a PPP link, you can specify only the outbound interface but not the next
hop IP address for the best-effort link. If the best-effort link is a non-PPP link, for example, an Ethernet
link, you must specify both the outbound interface and next hop IP address for the best-effort link.
Otherwise, packets cannot be forwarded.
l Configure a detection link, create a link group, and add the detection link to the link group.
1. Run:
prober interface-type interface-number nqa admin-name test-name
A detection link is configured.

2. Run:
link-group name
A link group is created and the link group view is displayed.

By default, no link group is created for SPR.
3. Run:
link-member { interface-type interface-number } &<1-8>

Routers
The specified detection link is added to the link group.

By default, detection links are not added to the link group.
Only interfaces having detection links configured can be added to link groups.
----End
12.6.3.2 Associating SPR with Services
Context
You can configure SPR service parameters, including specifying the service flows to which SPR
is applied, setting link quality parameters, and binding services to detection links.
ACLs for classifying service flows have been configured before binding an ACL to a servce
profile of SPR.
Procedure
Step 1 Run:
system-view
Step 2 Run:
smart-policy-route
An SPR is created and the SPR view is displayed.
Step 3 Run:
service-map name
A service profile of SPR is created and the service profile view is displayed.

description description
The description is configured for the service profile.
This command configures the description of a service profile, helping differentiate service
profiles.
Step 5 Run:
match acl acl-number &<1-10>
An ACL is specified to classify service flows.

Routers
NOTE
SPR differentiates service flows by matching them against ACL rules. The number of ACLs ranges from
2000 to 3999.
l ACLs numbered from 2000 to 2999 are basic ACLs.
l ACLs numbered from 3000 to 3999 are advanced ACLs.
l When permit or deny is used in the ACL rule, the system selects routes for the packets matching the
ACL rule according to link quality.
l If packets match no ACL rule, the system searches routes for the packets according to the destination
addresses.
l When the ACL does not contain rules, the smart policy routing referencing the ACL does not take
effect, and the system searches routes for the packets according to the destination addresses.
Step 6 Set thresholds of link quality indicators and CMI calculation formula based on service
requirements.
l (Optional) Run:
set delay threshold threshold-value
The service delay threshold of SPR is set.

The default service delay threshold of SPR is 5000 ms.
The service delay threshold of SPR is the maximum service delay allowed by services on
a link. If services require a short delay, this threshold needs to be set.
l (Optional) Run:
set jitter threshold threshold-value
The service jitter threshold of SPR is set.

The default service jitter threshold of SPR is 3000 ms.
The service jitter threshold of SPR is the maximum service jitter allowed by services on a
link. If services require a low jitter, this threshold needs to be set.
l (Optional) Run:
set loss threshold threshold-value
The packet loss ratio threshold of SPR is set.

The default packet loss rate threshold of SPR is 1000.
The packet loss rate threshold of SPR is the maximum packet loss rate allowed by services
on a link. If services require a low packet loss rate, this threshold needs to be set.
l (Optional) Run:
set cmi threshold threshold-value
The CMI threshold of SPR is set.

The default CMI threshold of SPR is 0.
If services require a low delay, jitter, and packet loss rate, this threshold needs to be set and
the CMI calculation formula needs to be configured.
l (Optional) Run:
cmi-method cmi-method
The CMI calculation formula is set.

By default, the CMI calculation formula is 9000 [D (delay) + J (jitter) + L (packet loss
rate)].
When services have requirements for delay, jitter, and packet loss rate, set the CMI
calculation formula.

Routers
Step 7 Run:
set link-group name
The active link group is configured.
By default, no active link group is configured for SPR.

set link-group name backup
The standby link group is configured.
By default, no standby link group is configured for SPR.
Different services have different network quality requirements. ISPs provide networks of
different quality levels and services at different costs. For example, ISP1 provides a high-quality
network at a high cost, while ISP2 provides a common-quality network at a low cost. You can
add ISP1 to the active link group and ISP2 to the standby link group for service A that requires
a high-quality network. Service A is switched to ISP2 when the network quality of ISP1 is low.
You can add ISP2 to the active link group and ISP1 to the standby link group for service B that
requires a common-quality network. This plan is cost-effective, and ensures that service B is
switched to ISP1 when the network quality of ISP2 is low.
----End
12.6.3.3 (Optional) Configuring an NQA Server Link
Context
As shown in Figure 12-5, RouterA is configured as the NQA client and RouterB is configured
as the NQA server, and the test result of the NQA test instance is saved on RouterA. RouterA
selects an optimal route based on link quality. To implement intelligent route selection on
RouterB, configure an NQA server link so that link quality data saved on RouterA can be sent
to RouterB. RouterB then selects routes based on received link quality data. This prevent
repeated detection of the same link when RouterA is configured as the NQA server and RouterB
is configured as the NQA client.

Routers
Figure 12-5 Networking for configuring an NQA server link
ISP1
Enterprise
branch 0 /0 GE Data center
/ 1/
1 /0 /
0 GE 1 RouterC 0/1 GE
1/
GE 0/0
RouterA RouterB
GE
2/0
/0 GE RouterD /0 /0
1/0 /0 /1 GE 2
/0 GE 1 ServerA
NQA NQA
ISP2
Client Server
Procedure
Step 1 Configure an NQA client port number.
1. Run:
system-view

2. Run:
smart-policy-route
A smart-policy-route is created and the smart-policy-route view is displayed.

3. Run:
nqa-client interface-type interface-number port port-num
An NQA client port number is configured.
By default, an NQA client port number is not configured.
Step 2 Configure an NQA server link and port number.

1. Run:
system-view

2. Run:
smart-policy-route
A smart-policy-route is created and the smart-policy-route view is displayed.

3. Run:
nqa-server interface-type interface-number
An NQA server link is created.

Routers
By default, no NQA server link is configured.

4. Run:
nqa-server port port-num
An NQA server port number is configured.

By default, an NQA server port number is not configured.
----End
Procedure
l Run the display smart-policy-route command to check the SPR configuration.
l Run the display smart-policy-route service-map [ name ] command to check the service
profile configuration.
l Run the display smart-policy-route link-state [ interface-type interface-number ]
command to check the detection link status.
l Run the display smart-policy-route nqa-server link-state command to check the NQA
server link status.
----End

The section provides several configuration examples of IP unicast PBR, including networking
requirements, and configuration roadmap.
12.7.1 Example for Configuring Local PBR

As shown in Figure 12-6, RouterA and RouterB are connected by two links.
Users want locally generated packets with different lengths to be sent to different next hop
addresses.
l Packets with 64 to 1400 bytes are sent to next hop address 150.1.1.2.
l Packets with 1401 to 1500 bytes are sent to next hop address 151.1.1.2.
l Packets with other lengths are routed based on destination addresses.
Figure 12-6 Networking diagram of configuring local PBR

Loopback0 Loopback0
10.1.1.1/24 10.1.2.1/24
GE1/0/0 GE1/0/0
150.1.1.1/24 150.1.1.2/24
RouterA GE2/0/0 GE2/0/0 RouterB

151.1.1.1/24 151.1.1.2/24

Routers
1. Configure a match rule of IP packet length on RouterA so that locally generated packets
with different lengths match different PBR nodes.
2. Configure actions of the local PBR on RouterA so that locally generated packets with
different lengths are sent to different next hop addresses.
3. Enable local PBR.
Procedure
Step 1 Configure IP addresses for interfaces.
# Configure IP addresses for all interfaces of RouterA.
[RouterA-GigabitEthernet1/0/0] ip address 150.1.1.1 255.255.255.0
[RouterA] interface loopback 0
[RouterA-LoopBack0] ip address 10.1.1.1 255.255.255.0
[RouterA-LoopBack0] quit
# Configure IP addresses for all interfaces of RouterB.

[Huawei] sysname RouterB
[RouterB-GigabitEthernet1/0/0] ip address 150.1.1.2 255.255.255.0
[RouterB] interface loopback 0
[RouterB-LoopBack0] ip address 10.1.2.1 255.255.255.0
[RouterB-LoopBack0] quit

# Configure a static route on RouterA.
[RouterA] ip route-static 10.1.2.0 24 150.1.1.2
[RouterA] ip route-static 10.1.2.0 24 151.1.1.2
# Configure a static route on RouterB.

[RouterB] ip route-static 10.1.1.0 24 150.1.1.1
[RouterB] ip route-static 10.1.1.0 24 151.1.1.1
Step 3 Configure a PBR route.

# Configure a PBR route named lab1.
[RouterA] policy-based-route lab1 permit node 10
[RouterA-policy-based-route-lab1-10] if-match packet-length 64 1400
[RouterA-policy-based-route-lab1-10] apply ip-address next-hop 150.1.1.2

Routers
[RouterA-policy-based-route-lab1-10] quit
[RouterA] policy-based-route lab1 permit node 20
[RouterA-policy-based-route-lab1-20] if-match packet-length 1401 1500
[RouterA-policy-based-route-lab1-20] apply ip-address next-hop 151.1.1.2
[RouterA-policy-based-route-lab1-20] quit
# Enable local PBR.

[RouterA] ip local policy-based-route lab1
Step 4 Verify the configurations.

# Clear interface statistics on RouterB.
<RouterB> reset counters interface gigabitethernet 1/0/0
# View interface statistics on RouterB.

<RouterB> display interface gigabitethernet 1/0/0
GigabitEthernet1/0/0 current state : UP
Last line protocol up time : 2012-07-30 11:23:24
Description:HUAWEI, AR Series, GigabitEthernet1/0/0 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 150.1.1.2/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0819-a6ce-7d4c
Last physical up time : 2012-07-30 11:23:24
Last physical down time : 2012-07-24 16:54:19
Current system time: 2012-07-30 14:57:28
Port Mode: COMMON COPPER
Speed : 1000, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE
Mdi : AUTO
Last 300 seconds input rate 40 bits/sec, 0 packets/sec
Last 300 seconds output rate 0 bits/sec, 0 packets/sec
Input peak rate 7568 bits/sec,Record time: 2012-07-30 12:57:02
Output peak rate 1008 bits/sec,Record time: 2012-07-30 12:42:42
Input: 4 packets, 1543 bytes

Unicast: 0, Multicast: 0
Broadcast: 0, Jumbo: 0
Discard: 0, Total Error: 0
CRC: 0, Giants: 0
Jabbers: 0, Throttles: 0
Runts: 0, Alignments: 0
Symbols: 0, Ignoreds: 0
Frames: 0
Output: 0 packets, 0 bytes

Collisions: 0, ExcessiveCollisions: 0
Late Collisions: 0, Deferreds: 0
Buffers Purged: 0
Input bandwidth utilization threshold : 100.00%

Output bandwidth utilization threshold: 100.00%
Input bandwidth utilization : 0.01%
Output bandwidth utilization : 0.00%

Routers

IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0819-a6ce-7d4d
Mdi : AUTO

CRC: 0, Giants: 0
Frames: 0

Buffers Purged: 0

# On RouterA, ping the IP address of Loopback0 on RouterB and set the packet length to 80
bytes.
<RouterA> ping -s 80 10.1.2.1

0.00% packet loss


Routers

Mdi : AUTO

CRC: 0, Giants: 0
Frames: 0

Buffers Purged: 0

Mdi : AUTO

CRC: 0, Giants: 0

Routers
Frames: 0

Buffers Purged: 0

Compare statistics about interfaces of RouterB before and after you run the ping -s 80
10.1.2.1 command on RouterA. You can find that GigabitEthernet 1/0/0 of RouterB sends five
packets, that is, GigabitEthernet 1/0/0 of RouterB sends five ICMP reply packets to RouterA
after receiving five ICMP requests from RouterA. RouterA determines that the next hop address
is 150.1.1.2 based on the PBR.
# Clear interface statistics on RouterB.


Mdi : AUTO

CRC: 0, Giants: 0
Frames: 0


Routers

Buffers Purged: 0

Mdi : AUTO

CRC: 0, Giants: 0
Frames: 0

Buffers Purged: 0

# On RouterA, ping the IP address of Loopback0 on RouterB and set the packet length to 1401
bytes.
<RouterA> ping -s 1401 10.1.2.1


Routers
0.00% packet loss


Mdi : AUTO

CRC: 0, Giants: 0
Frames: 0

Buffers Purged: 0

Mdi : AUTO

Routers

CRC: 0, Giants: 0
Frames: 0

Buffers Purged: 0

Compare statistics about interfaces of RouterB before and after you run the ping -s 1401
10.1.2.1 command on RouterA. You can find that GigabitEthernet 2/0/0 of RouterB sends five
packets, that is, GigabitEthernet 2/0/0 of RouterB sends five ICMP reply packets to RouterA
after receiving ICMP requests from RouterA. RouterA determines that the next hop address is
151.1.1.2 based on the PBR.
----End
Configuration Files
#
sysname RouterA
#
interface
ip address 150.1.1.1 255.255.255.0
#
interface
ip address 151.1.1.1 255.255.255.0
#
interface
LoopBack0
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.1.2.0 255.255.255.0
150.1.1.2
ip route-static 10.1.2.0 255.255.255.0 151.1.1.2
#
policy-based-route lab1 permit node
10
if-match packet-length 64
1400
apply ip-address next-hop
150.1.1.2
policy-based-route lab1 permit node
20

Routers
if-match packet-length 1401

1500
apply ip-address next-hop 151.1.1.2
#
ip local policy-based-route lab1
#
sysname RouterB
#
interface
ip address 150.1.1.2 255.255.255.0
#
interface
ip address 151.1.1.2 255.255.255.0
#
interface
LoopBack0
ip address 10.1.2.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0
150.1.1.1
ip route-static 10.1.1.0 255.255.255.0 151.1.1.1
12.7.2 Example for Configuring Interface PBR
As shown in Figure 12-7, two departments VLAN 10 and VLAN 20 connect to GE1/0/0 and
GE2/0/0 of RouterA. HOSTA at 192.168.1.2/24 and HOSTB at 192.168.1.3/24 belong to one
department and are located on network segment 192.168.1.0/24. HOSTC at 192.168.2.2/24 and
HOSTD at 192.168.2.3/24 belong to another department and are located on network segment
192.168.2.0/24.
RouterA can connect to the Internet through the link RouterARouterBRouterD or RouterA
RouterCRouterD. The requirements are as follows:
l Packets from the two departments reach the Internet through the two links when the two
links are running properly.
l When a link is faulty, packets from the two departments are forwarded on the other link.
This prevents service interruption for a long time.
l When the link fault is rectified, packets reach the Internet through the two links.

Routers
Figure 12-7 Networking diagram of configuring interface PBR
HOSTB HOSTA
VLAN 10 RouterB
GE1/0/0 GE2/0/0
GE1/0/0
SwitchA GE1/0/0
RouterA GE3/0/0 RouterD GE3/0/0
Internet
GE4/0/0
GE2/0/0 GE2/0/0
SwitchB
GE1/0/0 GE2/0/0
RouterC
VLAN 20
HOSTD HOSTC
Device Interface IP Address
RouterA GE1/0/0 192.168.1.1/24
GE2/0/0 192.168.2.1/24
GE3/0/0 192.168.3.1/24
GE4/0/0 192.168.4.1/24
RouterB GE1/0/0 192.168.3.2/24
GE2/0/0 192.168.5.2/24
RouterC GE1/0/0 192.168.4.2/24
GE2/0/0 192.168.6.2/24
RouterD GE1/0/0 192.168.5.1/24
GE2/0/0 192.168.6.1/24
GE3/0/0 192.168.7.1/24
Association between redirection and an NQA test instance is used to implement PBR. The
configuration roadmap is as follows:
1. Configure IP addresses and routing protocols for interfaces so that users can access the
Internet through RouterA.
2. Configure an NQA test instance to detect whether the links RouterARouterB
RouterD and RouterARouterCRouterD are running properly.

Routers
3. Configure association between NQA and static routes so that traffic can be switched to the
other link when one link is faulty.
4. Configure traffic classifiers and configure matching rules based on the source IP address
of packets.
5. Configure traffic behaviors in which redirection is associated with an NQA test instance.
When the NQA test instance detects that the link RouterARouterBRouterD is running
properly, packets matching the traffic classifier are redirected to 192.168.3.2/24. When the
NQA test instance detects that the link RouterARouterCRouterD is running properly,
packets matching the traffic classifier are redirected to 192.168.4.2/24.
6. Configure traffic policies, bind the traffic classifier and traffic behavior to the traffic
policies, and apply the traffic policies to an interface to implement interface PBR.
Procedure
Step 1 Configure devices to communicate with each other.
# Configure IP addresses for all interfaces of the Router. This example describes the
configuration on RouterA. Configurations of other device are similar to that of RouterA. For
details, see corresponding configuration files.
NOTE
Configure SwitchA and SwitchB so that they can communicate with RouterA.
# Configure static routes.

[RouterD] ip route-static 192.168.1.0 255.255.255.0 192.168.5.2
Step 2 Configure NQA test instances.
# Configure an NQA test instance on RouterA.

Routers
[RouterA] nqa test-instance admin vlan10

[RouterA-nqa-admin-vlan10] test-type icmp
[RouterA-nqa-admin-vlan10] destination-address ipv4 192.168.5.1
[RouterA-nqa-admin-vlan10] frequency 10
[RouterA-nqa-admin-vlan10] probe-count 2
[RouterA-nqa-admin-vlan10] start now
[RouterA-nqa-admin-vlan10] quit
[RouterA] nqa test-instance admin vlan20
[RouterA-nqa-admin-vlan20] test-type icmp
[RouterA-nqa-admin-vlan20] destination-address ipv4 192.168.6.1
[RouterA-nqa-admin-vlan20] frequency 10
[RouterA-nqa-admin-vlan20] probe-count 2
[RouterA-nqa-admin-vlan20] start now
[RouterA-nqa-admin-vlan20] quit
# Configure an NQA test instance on RouterD.

[RouterD] nqa test-instance admin vlan10
[RouterD-nqa-admin-vlan10] test-type icmp
[RouterD-nqa-admin-vlan10] destination-address ipv4 192.168.3.1
[RouterD-nqa-admin-vlan10] frequency 10
[RouterD-nqa-admin-vlan10] probe-count 2
[RouterD-nqa-admin-vlan10] start now
[RouterD-nqa-admin-vlan10] quit
[RouterD] nqa test-instance admin vlan20
[RouterD-nqa-admin-vlan20] test-type icmp
[RouterD-nqa-admin-vlan20] destination-address ipv4 192.168.4.1
[RouterD-nqa-admin-vlan20] frequency 10
[RouterD-nqa-admin-vlan20] probe-count 2
[RouterD-nqa-admin-vlan20] start now
[RouterD-nqa-admin-vlan20] quit
Step 3 Configure association between NQA and static routes.
# Configure association between NQA and static routes on RouterA.

[RouterA] ip route-static 192.168.7.1 255.255.255.0 192.168.3.2 track nqa admin
vlan10
[RouterA] ip route-static 192.168.7.1 255.255.255.0 192.168.4.2 track nqa admin
vlan20
[RouterA] quit
# Configure association between NQA and static routes on RouterD.

[RouterD] ip route-static 192.168.1.0 255.255.255.0 192.168.5.2 track nqa admin
vlan10
vlan20
vlan10
vlan20
[RouterD] quit
Step 4 Configure traffic classifiers.
# Create traffic classifiers vlan10 and vlan20 on RouterA to match packets with source IP
addresses on network segments 192.168.1.0/24 and 192.168.2.0/24.
[RouterA] acl number 2000
[RouterA-acl-basic-2000] rule 10 permit source 192.168.1.0 0.0.0.255
[RouterA-acl-basic-2000] quit
[RouterA] acl number 2001
[RouterA-acl-basic-2001] rule 20 permit source 192.168.2.0 0.0.0.255
[RouterA-acl-basic-2001] quit
[RouterA] traffic classifier vlan10
[RouterA-classifier-vlan10] if-match acl 2000

Routers
[RouterA-classifier-vlan10] quit
[RouterA] traffic classifier vlan20
[RouterA-classifier-vlan20] if-match acl 2001
[RouterA-classifier-vlan20] quit
# Create traffic classifiers vlan10 and vlan20 on RouterD to match packets with destination IP
addresses on network segments 192.168.1.0/24 and 192.168.2.0/24.
[RouterD] acl number 3000
[RouterD-acl-adv-3000] rule 10 permit ip destination 192.168.1.0 0.0.0.255
[RouterD-acl-adv-3000] quit
[RouterD] acl number 3001
[RouterD-acl-adv-3001] rule 20 permit ip destination 192.168.2.0 0.0.0.255
[RouterD-acl-adv-3001] quit
[RouterD] traffic classifier vlan10
[RouterD-classifier-vlan10] if-match acl 3000
[RouterD-classifier-vlan10] quit
[RouterD] traffic classifier vlan20
[RouterD-classifier-vlan20] if-match acl 3001
[RouterD-classifier-vlan20] quit
Step 5 Configure traffic behaviors.
# Create traffic behavior vlan10 on RouterA and associate the NQA test instance admin
vlan10 with redirection to the next hop 192.168.3.2/24. When the NQA test instance detects that
the link is running properly, redirection takes effect. When the NQA test instance detects a link
fault, packets are forwarded along the original path.
[RouterA] traffic behavior vlan10
[RouterA-behavior-vlan10] redirect ip-nexthop 192.168.3.2 track nqa admin vlan10
[RouterA-behavior-vlan10] quit
# Create traffic behavior vlan20 on RouterA and associate the NQA test instance admin
[RouterA] traffic behavior vlan20
[RouterA-behavior-vlan20] redirect ip-nexthop 192.168.4.2 track nqa admin vlan20
[RouterA-behavior-vlan20] quit
# Create traffic behavior vlan10 on RouterD and associate the NQA test instance admin
[RouterD] traffic behavior vlan10
[RouterD-behavior-vlan10] redirect ip-nexthop 192.168.5.2 track nqa admin vlan10
[RouterD-behavior-vlan10] quit
# Create traffic behavior vlan20 on RouterD and associate the NQA test instance admin
[RouterD] traffic behavior vlan20
[RouterD-behavior-vlan20] redirect ip-nexthop 192.168.6.2 track nqa admin vlan20
[RouterD-behavior-vlan20] quit
Step 6 Configure traffic policies and apply the traffic policies.
# Create traffic policies vlan10 and vlan20 on RouterA and bind the traffic classifier and the
traffic behavior to the traffic policy.

Routers
[RouterA] traffic policy vlan10

[RouterA-trafficpolicy-vlan10] classifier vlan10 behavior vlan10
[RouterA-trafficpolicy-vlan10] quit
[RouterA] traffic policy vlan20
[RouterA-trafficpolicy-vlan20] classifier vlan20 behavior vlan20
[RouterA-trafficpolicy-vlan20] quit
# Apply the traffic policy vlan10 to GE1/0/0 in the inbound direction and the traffic policy
vlan20 to GE2/0/0 in the inbound direction.
[RouterA-GigabitEthernet1/0/0] traffic-policy vlan10 inbound
[RouterA-GigabitEthernet2/0/0] traffic-policy vlan20 inbound
# Create traffic policy vlan10 on RouterD and bind the traffic classifier and the traffic behavior
to the traffic policy.
[RouterD] traffic policy vlan10
[RouterD-trafficpolicy-vlan10] classifier vlan10 behavior vlan10
[RouterD-trafficpolicy-vlan10] classifier vlan20 behavior vlan20
[RouterD-trafficpolicy-vlan10] quit
# Apply the traffic policy vlan10 to GE3/0/0 in the inbound direction.

[RouterD-GigabitEthernet3/0/0] traffic-policy vlan10 inbound
# View the interface configuration on RouterA.

[RouterA-GigabitEthernet1/0/0] display this
#
ip address 192.168.1.1 255.255.255.0
traffic-policy vlan10 inbound
#
return
[RouterA-GigabitEthernet2/0/0] display this
#
ip address 192.168.2.1 255.255.255.0
#
return
# View the traffic policy configuration.

[RouterA] display traffic policy user-defined
User Defined Traffic Policy Information:
Policy: vlan10
Classifier: vlan10
Operator: OR
Behavior: vlan10
Redirect:
Redirect ip-nexthop 192.168.3.2 track nqa admin vlan10
Policy: vlan20
Classifier: vlan20

Routers
Operator: OR
Behavior: vlan20
Redirect:
Redirect ip-nexthop 192.168.4.2 track nqa admin vlan20
----End
Configuration Files
#
sysname RouterA
#
acl number
2000
rule 10 permit source 192.168.1.0

0.0.0.255
acl number
2001
rule 20 permit source 192.168.2.0 0.0.0.255

#
traffic classifier vlan10 operator
or
if-match acl 2000
traffic classifier vlan20 operator
or
if-match acl 2001
#
traffic behavior
vlan10
redirect ip-nexthop 192.168.3.2 track nqa admin
vlan10
traffic behavior
vlan20
redirect ip-nexthop 192.168.4.2 track nqa admin
vlan20
#
traffic policy
vlan10
classifier vlan10 behavior
vlan10
traffic policy
vlan20
classifier vlan20 behavior
vlan20
#
ip address 192.168.1.1
255.255.255.0
traffic-policy vlan10
inbound
#
255.255.255.0
traffic-policy vlan20
inbound
#
255.255.255.0
#

Routers
255.255.255.0
#
ip route-static 192.168.5.0 255.255.255.0
192.168.3.2
ip route-static 192.168.6.0 255.255.255.0
192.168.4.2
ip route-static 192.168.7.0 255.255.255.0 192.168.3.2 track nqa admin
vlan10
ip route-static 192.168.7.0 255.255.255.0 192.168.4.2 track nqa admin
vlan20
#
nqa test-instance admin
vlan10
test-type
icmp
destination-address ipv4
192.168.5.1
frequency 10
probe-count 2
start now
vlan20
test-type
icmp
192.168.6.1
frequency 10
probe-count 2
start now
#
return

#
sysname RouterB
#
ip address 192.168.3.2 255.255.255.0
ip address 192.168.5.2 255.255.255.0
#
ip route-static 192.168.1.0 255.255.255.0 192.168.3.1
ip route-static 192.168.2.0 255.255.255.0 192.168.3.1
ip route-static 192.168.7.0 255.255.255.0 192.168.5.1
#
return

#
sysname RouterC
#
ip address 192.168.4.2 255.255.255.0
ip address 192.168.6.2 255.255.255.0
#
ip route-static 192.168.1.0 255.255.255.0 192.168.4.1
ip route-static 192.168.2.0 255.255.255.0 192.168.4.1
ip route-static 192.168.7.0 255.255.255.0 192.168.6.1
#
return

#
sysname RouterD
#
acl number 3000

Routers
rule 10 permit ip destination 192.168.1.0 0.0.0.255

acl number 3001
rule 20 permit ip destination 192.168.2.0 0.0.0.255
#
traffic classifier vlan10 operator or
if-match acl 3000
traffic classifier vlan20 operator or
if-match acl 3001
#
traffic behavior vlan10
redirect ip-nexthop 192.168.5.2 track nqa admin vlan10
traffic behavior vlan20
redirect ip-nexthop 192.168.6.2 track nqa admin vlan20
#
traffic policy vlan10
classifier vlan10 behavior vlan10
classifier vlan20 behavior vlan20
#
ip address 192.168.5.1 255.255.255.0
ip address 192.168.6.1 255.255.255.0
ip address 192.168.7.1 255.255.255.0
#
ip route-static 192.168.1.0 255.255.255.0 192.168.5.2 track nqa admin vlan10
ip route-static 192.168.3.0 255.255.255.0
192.168.5.2
ip route-static 192.168.4.0 255.255.255.0
192.168.6.2
#
return
12.7.3 Example for Configuring SPR
As shown in Figure 12-8, a financial enterprise's branch connects to the enterprise data center
over two ISP networks (ISP1 and ISP2), and exchange data is saved to ServerA in the data center.
The enterprise wants ISP1 to provide a high-speed active link and ISP2 to provide a standby
link. The link delay needs to be shorter than or equal to 1000 ms to ensure that exchange data
is sent to the data center in a timely manner.

Routers
Figure 12-8 Networking diagram of SPR
ISP1
Enterprise
/0 /0 4 /0 GE GE
2/0 202.1 1/0/0
Data center
branch G E 1 1 .1 .1 /2 G E 1 /0 4 2 /0 . 2. 1
2 . .2 / 2 02
20 .
.1.1 RouterC 1.2.2/
/24
202 24
RouterA RouterB
GE 1 GE RouterD /0
2 1
178 /0/0 78.1.1 /0/0 /0 4
G E 2 1 .2 .2 /2 E 2 /0 /0
.1.1 .2/2 . G
4 178 24
.1/2
4 . 1 . 2 .1 / ServerA
178 196.1.1.1/24
ISP2
1. Configure the NQA client on RouterA and the NQA server on RouterB so that the quality
of the link between the enterprise branch and data center can be detected dynamically.
2. Configure ACLs to classify service flows so that SPR can be applied to packets with the
destination IP address as the ServerA's IP address.
3. Configure SPR routing parameters on RouterA so that detection links are added to a link
group.
4. Configure association between SPR and services on RotuerA so that ISP1 provides the
active link, ISP2 provides the standby link, and the link delay is shorter than or equal to
1000 ms.
Procedure
Step 1 Configure IP addresses for interfaces.
# Configure IP addresses for all interfaces of RouterA.

# Configure IP addresses for all interfaces of RouterB.

Routers
[Huawei] sysname RouterB
# Configure IP addresses for all interfaces of RouterC.

[Huawei] sysname RouterC
[RouterC-GigabitEthernet1/0/0] ip address 202.1.1.2 255.255.255.0
[RouterC-GigabitEthernet2/0/0] ip address 202.1.2.2 255.255.255.0
# Configure IP addresses for all interfaces of RouterD.

[Huawei] sysname RouterD
[RouterD-GigabitEthernet1/0/0] ip address 178.1.1.2 255.255.255.0
[RouterD-GigabitEthernet2/0/0] ip address 178.1.2.2 255.255.255.0
# Configure a static route on RouterA.

# Configure a static route on RouterB.

Step 3 Configure NQA test instances.
# Configure the NQA client on RouterA.

[RouterA] nqa test-instance admin nqa1
[RouterA-nqa-admin-nqa1] test-type jitter
[RouterA-nqa-admin-nqa1] destination-address ipv4 202.1.2.1
[RouterA-nqa-admin-nqa1] destination-port 10000
[RouterA-nqa-admin-nqa1] hardware-based enable
[RouterA-nqa-admin-nqa1] frequency 10
[RouterA-nqa-admin-nqa1] source-interface gigabitethernet 1/0/0
[RouterA-nqa-admin-nqa1] start now
[RouterA-nqa-admin-nqa1] quit
[RouterA] nqa test-instance admin nqa2
[RouterA-nqa-admin-nqa2] test-type jitter
[RouterA-nqa-admin-nqa2] destination-address ipv4 178.1.2.1
[RouterA-nqa-admin-nqa2] destination-port 10001
[RouterA-nqa-admin-nqa2] hardware-based enable
[RouterA-nqa-admin-nqa2] frequency 10
[RouterA-nqa-admin-nqa2] source-interface gigabitethernet 2/0/0
[RouterA-nqa-admin-nqa2] start now
[RouterA-nqa-admin-nqa2] quit
# Configure the NQA server on RouterB.

Routers
[RouterB] nqa-server udpecho 202.1.2.1 10000

[RouterB] nqa-server udpecho 178.1.2.1 10001
Step 4 Configure ACLs to classify service flows.
# Configure ACL 3000 on RouterA to apply SPR to data flows with destination address
196.1.1.1.
[RouterA] acl 3000
[RouterA-acl-adv-3000] rule permit ip destination 196.1.1.1 0.0.0.0
[RouterA-acl-adv-3000] quit
Step 5 Set SPR routing parameters on RouterA.

[RouterA] smart-policy-route
[RouterA-smart-policy-route] period 50
[RouterA-smart-policy-route] route flapping suppression 100
[RouterA-smart-policy-route] prober gigabitethernet 1/0/0 nqa admin nqa1
[RouterA-smart-policy-route] prober gigabitethernet 2/0/0 nqa admin nqa2
[RouterA-smart-policy-route] link-group group1
[RouterA-smart-policy-route-link-group group1] link-member gigabitethernet 1/0/0
[RouterA-smart-policy-route-link-group group1] quit
[RouterA-smart-policy-route] link-group group2
[RouterA-smart-policy-route-link-group group2] link-member gigabitethernet 2/0/0
[RouterA-smart-policy-route-link-group group2] quit
Step 6 Set SPR service parameters.

[RouterA-smart-policy-route] service-map map1
[RouterA-smart-policy-route-service-map-map1] match acl 3000
[RouterA-smart-policy-route-service-map-map1] set delay threshold 1000
[RouterA-smart-policy-route-service-map-map1] set link-group group1
[RouterA-smart-policy-route-service-map-map1] set link-group group2 backup
[RouterA-smart-policy-route-service-map-map1] quit
[RouterA-smart-policy-route] quit
# View the NQA test results of the detection links on RouterA.

[RouterA] display smart-policy-route link-state
--------------------------------------------------------------------------------
link-name Delay Jitter Loss
--------------------------------------------------------------------------------
GigabitEthernet1/0/0 5000 3000 1000
GigabitEthernet2/0/0 5000 3000 1000
--------------------------------------------------------------------------------
# View routing information about service map1 on RouterA.

[RouterA] display smart-policy-route service-map map1
--------------------------------------------------------------------------------
Match acl : 3000
DelayThreshold : 1000
LossThreshold : 1000
JitterThreshold : 3000
CmiThreshold : 0
GroupName : group1
BackupGroupName : group2
Description :
Cmi-Method : d+l+j
CurLinkName :
--------------------------------------------------------------------------------
----End

Routers
Configuration Files
#
sysname
RouterA
#
acl number
3000
rule 5 permit ip destination 196.1.1.1
0
#
interface
255.255.255.0
#
interface
255.255.255.0
#
nqa1
test-type
jitter
202.1.2.1
destination-port
10000
hardware-based
enable
frequency
10
source-interface
start
now
nqa2
test-type
jitter
178.1.2.1
destination-port
10001
hardware-based
enable
frequency
10
source-interface
start
now
#
smart-policy-
route
period
50
route flapping suppression
100
prober GigabitEthernet1/0/0 nqa admin
nqa1
prober GigabitEthernet2/0/0 nqa admin
nqa2
link-group

Routers
group1
link-member
link-group
group2
link-member
service-map
map1
match acl
3000
set delay threshold
1000
set link-group
group1
set link-group group2
backup
#
ip route-static 202.1.2.0 255.255.255.0
202.1.1.2
ip route-static 178.1.2.0 255.255.255.0
178.1.1.2
#
#
sysname RouterB
#
interface
255.255.255.0
#
interface
255.255.255.0
#
nqa-server udpecho 178.1.2.1
10001
nqa-server udpecho 202.1.2.1
10000
#
ip route-static 202.1.1.0 255.255.255.0
202.1.2.2
ip route-static 178.1.1.0 255.255.255.0
178.1.2.2
#
#
sysname RouterC
#
interface
255.255.255.0
#
interface
255.255.255.0
#

Routers
#
sysname RouterD
#
interface
255.255.255.0
#
interface
255.255.255.0
#
12.8 References
This section lists references of Policy-based Routing.
None


AR150&200&1200&2200&3200 V200R003C01 Configuration Guide-IP Routing 04 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

AR150&200&1200&2200&3200 V200R003C01 Configuration Guide-IP Routing 04 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Huawei AR150&200&1200&2200&3200 Series

Configuration Guide - IP Routing

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 04 (2014-01-16) Huawei Proprietary and Confidential i

About This Document

This document is intended for:

l Data configuration engineers

Indicates an imminently hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Issue 04 (2014-01-16) Huawei Proprietary and Confidential ii

NOTE Calls attention to important information, best

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

# A line starting with the # sign is comments.

Interface Numbering Conventions

Issue 04 (2014-01-16) Huawei Proprietary and Confidential iii

Changes in Issue 04 (2014-01-16)

The following information is modified:

Changes in Issue 03 (2013-04-25)

The following information is modified:

Changes in Issue 02 (2013-03-10)

The following information is modified:

Changes in Issue 01 (2013-01-31)

Issue 04 (2014-01-16) Huawei Proprietary and Confidential iv

About This Document.....................................................................................................................ii

2 Static Route Configuration........................................................................................................17

Issue 04 (2014-01-16) Huawei Proprietary and Confidential v

Issue 04 (2014-01-16) Huawei Proprietary and Confidential vi

3.5.3.2 Configuring Poison Reverse...................................................................................................................................68

Issue 04 (2014-01-16) Huawei Proprietary and Confidential vii

4.1 Introduction to RIPng.................................................................................................................................................106

Issue 04 (2014-01-16) Huawei Proprietary and Confidential viii

5.2.4 OSPF GTSM............................................................................................................................................................140

Issue 04 (2014-01-16) Huawei Proprietary and Confidential ix

5.6.6.2 Configuring Equal-Cost Routes............................................................................................................................187

Issue 04 (2014-01-16) Huawei Proprietary and Confidential x

5.6.12.5 Suppressing an Interface from Receiving or Sending OSPF Packets................................................................217

6 OSPFv3 Configuration............................................................................................................. 266

Issue 04 (2014-01-16) Huawei Proprietary and Confidential xi

6.4 Default Configuration.................................................................................................................................................284

Issue 04 (2014-01-16) Huawei Proprietary and Confidential xii

6.5.8.2 Enabling the Helper of OSPFv3 GR.....................................................................................................................308

7 IPv4 IS-IS Configuration..........................................................................................................321

Issue 04 (2014-01-16) Huawei Proprietary and Confidential xiii

7.5.2.2 Configuring Area or Domain Authentication.......................................................................................................375

Issue 04 (2014-01-16) Huawei Proprietary and Confidential xiv

7.7.5 Example for Configuring IS-IS Fast Convergence..................................................................................................427

8 IPv6 IS-IS Configuration..........................................................................................................465

Issue 04 (2014-01-16) Huawei Proprietary and Confidential xv

8.5.4.2 Configuring IS-IS to Import External Routes.......................................................................................................489

Issue 04 (2014-01-16) Huawei Proprietary and Confidential xvi

9.4 Default Configuration.................................................................................................................................................545

Issue 04 (2014-01-16) Huawei Proprietary and Confidential xvii

9.5.7.1 Enabling BGP Tracking........................................................................................................................................584